bristlecone-logic について
bristlecone-logicは、スキーマ検証付きAPI、実行追跡、支出制御を備えた、AIエージェント連携向けの従量制M2Mマイクロサービスエンジンです。リクエスト署名、テナント計測、ハードウェア分離型のUSDC決済を組み合わせています。
主な機能
- 01スキーマ検証付きリクエスト処理
- 02Commit DAGによるエージェント連携
- 03HMAC署名付きリクエストエンベロープ
- 04テナント計測とBYOKルーティング
- 05支出上限とUSDC決済
- 06実行監査とテレメトリー
活用シーン
- 01制御されたAPI経由で構造化エージェントタスクをルーティング
- 02タスクの系譜追跡と失敗処理のロールバック
- 03テナント利用量の計測と支出上限の適用
- 04エージェントの活動監査とUSDC収益の決済
MCP 対応
オーケストレーション層にMCPツールレジストリーを備えています。MCPクライアントに公開するツールの詳細はREADMEに記載されていません。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
2掲載時のツール一覧 · 2 週間前に更新
| パラメーター | 型 | 必須 | 説明 |
|---|---|---|---|
| url | string | はい |
詳細
BRISTLECONE LOGIC, LLC — システムアーキテクチャと開発マスターログ
ドキュメントのステータス: 本番環境のベースライン承認済み
期間: 2026年7月20日~2026年8月1日
コアツールチェーン: Linux、uv(Astral)、Python 3.12+、FastAPI、Pydantic v2、PostgreSQL 16、Redis、Nginx、Docker、Streamlit、Web3.py、AWS KMS(secp256k1)
エンジニアリング理念: スキーマ検証済みの契約、決定論的ステートマシン、暗号署名された実行境界によって統制される、第一原理に基づく仕様駆動型のゼロトラストアーキテクチャです。
1. エグゼクティブサマリーと中核目標
Bristlecone Logic, LLC の主な目標は、高性能で決定論的なマシン間(M2M)マイクロサービスエンジンを設計、構築、デプロイすることです。このコアプラットフォームは、自律型AIエージェントの群れ、1セント未満の従量課金、自動残高・レート管理、ハードウェア分離型L2トレジャリーのスイープ、リアルタイム監査に対応するように設計されています。
┌────────────────────────────────────────────────────────┐
│ Layer 5: 診断と可観測性 │
│ (OpenTelemetry / トレース管理 / 監査) │
├────────────────────────────────────────────────────────┤
│ Layer 4: トランザクションとアセットの分離 │
│ (HMAC ペイロード署名 / x402 トレジャリーゲート)│
├────────────────────────────────────────────────────────┤
│ Layer 3: オーケストレーションとステートマシン │
│ (コミット DAG / Invigilator / BYOK / 従量課金) │
├────────────────────────────────────────────────────────┤
│ Layer 2: コアビジネスと API ロジック │
│ (FastAPI マイクロサービス / Pydantic スキーマ) │
├────────────────────────────────────────────────────────┤
│ Layer 1: 決定論的ランタイムサンドボックス │
│ (Astral 'uv' エンジン / スキーマ検証) │
├────────────────────────────────────────────────────────┤
│ Layer 0: ハードウェア分離型決済 │
│ (AWS KMS HSM / Base L2 / Coinbase Vault スイープ)│
└────────────────────────────────────────────────────────┘
2. システムアーキテクチャ(6層のゼロトラストエンジン)
Layer 0: ハードウェア分離型オンチェーン決済
- エンジン: AWS KMS HSM(us-west-2、ECC_SECG_P256K1)、Base L2(チェーン ID 8453)、Web3 エンジン。
- 役割: サーバー外での秘密鍵の安全性を管理し、生の ASN.1 DER 署名の解析、EIP-2 に準拠した low-S の正規化、自動 USDC 収益スイープのための EIP-1559 オフライン生トランザクション署名を実行します。
Layer 1: 決定論的ランタイムサンドボックスとスキーマベース
- エンジン: Astral の uv(pip/pyenv を使用せず)で、バージョンを固定した Python 3.12+ 仮想環境(.venv)を管理します。
- 役割: 厳格なデータ契約と Pydantic スキーマ(app/layer1_schemas/base.py)を実装します。ネットワークルーティングの前に、承認されていないペイロードや要件に準拠しないエージェント名を拒否します。
Layer 2: コアマイクロサービスのルーティングと実行エンジン
- エンジン: アプリケーションファクトリーパターン(create_app())を採用した FastAPI / Uvicorn。
- 役割: 高並行性の API リクエストルーティング、セキュリティミドルウェアの実行、入力のサニタイズ、構造化ペイロードの処理を担います。
Layer 3: オーケストレーション、コミット DAG、従量課金ゲートウェイ
- エンジン: SQLite/PostgreSQL ステートストア、ネイティブ GeminiWorker 統合、Model Context Protocol(MCP)ツールレジストリ、Redis によるホットパス従量課金。
- 役割: エージェントの意思決定ループを統制し、実行の系譜を記録する コミット DAG(有向非巡回グラフ)を適用し、BYOK(Bring Your Own Key)ルーティングを管理し、トークン/USD の従量課金をリアルタイムで処理します。
レイヤー 4:暗号学的完全性と資金管理の分離
- エンジン: HMAC-SHA256 署名機能(app/layer4_crypto/signer.py)と資金管理ゲート(app/layer4_ledgers/treasury.py)。
- 責務: すべてのリクエストエンベロープに署名し、検証します。また、自律型エージェントのコストが際限なく増加するのを防ぐため、厳格な支出上限(1 件の取引あたり $50.00)を適用します。
レイヤー 5:可観測性、監査ログの永続化、テレメトリー
- エンジン: OpenTelemetry 標準、変更不能な JSON Lines(audit_log.jsonl)、PostgreSQL 監査ログ。
- 責務: システム内のすべての遷移にわたって、UTC タイムスタンプ付きのトレースイベント、実行レイテンシ、出力品質チェックを記録します。
3. Dendro 分類の適用マトリクス
すべてのシステムレイヤーにおけるエージェントの識別情報は、レイヤー 1 でソフトなプレフィックス照合(@field_validator("agent_name"))を用いて厳格に検証されます。エージェント名は、承認済みのプレフィックスの後にハイフンまたはアンダースコアを付ける必要があります(例:sapling_01、resin-gate)。
| Dendro 階層 | 運用上の役割 | 実行権限 | 副作用に関する制約 |
|---|---|---|---|
| Seedling | 受付と解析 | 読み取り専用の入力サニタイズとスキーマ解析 | 書き込み権限なし |
| Sapling | タスクの分解 | ルート計画と目標の DAG ノードへの分解 | オーケストレーションのみ。外部 API の実行不可 |
| Cambium | ワーカーの実行 | データ変換、内部ツールの実行 | スコープを限定したデータベース書き込み(organization_id で分離) |
| Resin | セキュリティと資金管理 | HMAC 承認、x402 支出ゲートの評価 | 厳格な上限(1 件の取引あたり最大 $50.00 USD) |
| Heartwood | コミットと状態同期 | DAG ノードのロック、ナレッジグラフ状態のコミット | 監査ログへの完全な書き込みアクセス |
| Ancient | 長期記憶 | 履歴の取得とグローバル状態のコンテキスト | グラフ状態のクエリは読み取り専用 |
| Krummholz | エッジ運用 | 制約のある環境でのローカルワーカー実行 | ローカル機能のスコープを制限 |
4. サブシステムの仕様
A. コミット DAG エンジン(タスクの系譜)
- コミットノード(commit_nodes): サブタスクを実行するたびに、不変のコミットレコードが生成されます。このレコードには、親コミットへのポインター(parent_ids)、決定論的な SHA-256 状態ハッシュ、エージェントの役割、入出力ペイロードが保持されます。
- コミットエッジ(commit_edges): 親実行ノードと子ノードをリンクします。
- 状態のロールバック: 下流のワーカーが失敗した場合、データベースの整合性を損なうことなく、システムは最後に有効だった親コミットハッシュまで状態を巻き戻します。
B. 従量制ゲートウェイと BYOK アーキテクチャ
- API キーのセキュリティ: マシン間トークン(bcl_...)は SHA-256 ハッシュ(key_hash)を使用して認証されます。平文のキーは保存されません。
- 従量制エンジン: Redis Lua スクリプト(METER_LUA)が、レート制限(1 分あたりのリクエスト数)をアトミックに追跡し、1 ミリ秒未満でマイクロセント単位の残高控除(負のコスト差分を使った INCRBYFLOAT)を実行します。
- BYOK のサポート: テナントは独自の LLM キー(custom_llm_key)を指定でき、テレメトリーのログ記録を維持しながら、マスターゲートウェイの課金を回避できます。
- 残高不足の自動チェック: 15 分ごとのバックグラウンド cron タスクが、テナントのクレジット残高を評価します。残高が $5.00 USD を下回るアカウントでは、非同期 HTTP Webhook(tenant.low_balance_warning)がトリガーされ、Prometheus のテレメトリーメトリクス(bristlecone_low_balance_alerts_total)が出力されます。
C. ハードウェア分離型の自動 USDC スイーパーデーモン
- AWS KMS 署名エンジン(kms_signer.py): AWS KMS HSM キー(us-west-2、bristlecone-sweeper-bot)を使用して Base L2 トランザクションに署名します。秘密鍵をディスク上やメモリ内に一切公開しません。ASN.1 DER 署名を、$v$ リカバリー値の計算を含む EIP-2 の正規形式に変換します。
- スイーパーデーモン(sweeper_daemon.py): 10 秒ごとに Base L2 RPC ノードをポーリングし、ホットウォレットの USDC 残高(0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913)を確認し、ネイティブ ETH のガス準備金を検証して、生の ERC-20 転送ペイロード(0xa9059cbb)を構築し、スイープ資金を企業のカストディに直接送金します。
- システムデーモン(bristlecone-sweeper.service): systemd の下で非同期に実行され、自動再起動と journalctl ロギングに対応しています。デプロイ前の検証中は DRY_RUN_MODE = True で運用されました。
5. エンジニアリング記録とタイムライン(2026 年 7 月 20 日~8 月 1 日)
2026 年 7 月 20 日:設計立案とコア 5 層ベースライン
- ベースラインのセットアップ: uv を使用して分離環境を初期化し、pyproject.toml を作成してコア依存関係を固定し、AGENTS.md を設定しました。
- レイヤー 1 の分類規則の確立: 不正なエージェント名を拒否し(422 Unprocessable Entity)、有効な Dendro プレフィックスは許可するプレフィックス検証ルールを構築しました。
- トレジャリーゲートのテスト: 1 件あたりのハード上限である $50.00 を超過するため、シミュレーション上の $150.00 のトランザクションが実行前に拒否されることを確認しました。
2026 年 7 月 21 日:ゼロトラスト防御と暗号化ペイロード署名
- HMAC-SHA256 エンジン: 正規 JSON シリアライズ(sort_keys=True)と、定時間検証のための hmac.compare_digest を使用して、app/layer4_crypto/signer.py に PayloadSigner を実装しました。
- 改ざんプローブ: 有効なペイロードを傍受して本文属性を変更し、レイヤー 2 で即座に 403 Forbidden が返されることを確認しました。
- 永続的なテレメトリー: すべての状態グラフ遷移にわたる追記専用 JSONL ロギング(audit_log.jsonl)を実装しました。
2026 年 7 月 22 日:シークレットの外部化、ツールの実行制御、Streamlit UI
- シークレットの強化: python-dotenv を使用して実行時の環境変数解析をリファクタリングし、ハードコードされたシークレットへのフォールバックを削除しました。
- ツール実行制御: 関数呼び出しの実行前に二重ゲートチェック(明示的なツールの許可リスト + HMAC 署名)を強制する tool_gater.py をデプロイしました。
- コントロールパネルとデーモン: FastAPI に接続する Streamlit フロントエンド(dashboard.py)を作成し、systemd の下で bristlecone-logic.service バックグラウンドデーモンを起動しました。
2026 年 7 月 23 日:SQLite 永続化と Gemini ワーカーのネイティブ統合
- SQLite 状態エンジン: オフラインでのローカルタスク実行状態と監査ログを管理する SQLiteStateStore(state_store.py)を構築しました。
- Gemini ワーカーのネイティブ統合: GeminiWorker(gemini-flash-latest)を Layer3Orchestrator 内にカプセル化し、自然言語の意図をスキーマに準拠した構造化ツールパラメーターに直接変換します。
2026 年 7 月 24 日:コンテナ化とゼロトラストパイプラインの検証
- マルチステージ Dockerfile: コアのマイクロサービスエンジンを分離された Docker コンテナ(bristlecone_m2m_engine)にパッケージ化しました。
- セキュリティとミドルウェアの強化: ペイロードサイズ制限(上限 1MB)、API キー検証の依存関係、および CORS/TrustedHost ミドルウェアを統合しました。
2026 年 7 月 26 日:VPS デプロイと PostgreSQL スキーマのベースライン
- クラウドインフラストラクチャ: Nginx リバースプロキシの背後で Docker Compose を使用し、Vultr VPS(bristlecone-prod-1、IP: 45.76.245.124)に本番コンテナスタックをデプロイしました。
- データベースのリレーショナル設定: SQLAlchemy 2.0 と Alembic マイグレーションを使用して PostgreSQL 16 データベース(bristlecone_db)を初期化しました。
2026 年 7 月 27 日:マルチテナントコンテキストと JWT のリファクタリング
- JWT クレームの統合: 認証ハンドラーを更新し、organization_id を org_id として JWT トークン内に直接エンコードするようにしました。
- テナント分離: /users、/projects、/organizations エンドポイント全体に、テナントスコープのクエリフィルターを強制しました。
2026年7月28日:コミットDAGエンジンと管理APIスタック
- Blueprint v2.0 追補: Alembicマイグレーション60962c26fe50をプロビジョニングし、commit_nodes、commit_edges、invigilator_logsの各テーブルを追加しました。
- DAGサービスとAPI: コミットノードの作成、親依存関係のリンク、グラフ系譜の取得を行う /api/v1/dag エンドポイントをデプロイしました。
2026年7月30日:従量課金ゲートウェイ、BYOKスキーマ、自動スイープ
- 課金スキーマ: NUMERIC(12, 6)の精度を持つtenants、api_keys、llm_usage_ledgerの各テーブルをプロビジョニングしました。
- バックグラウンドスイーパー: システムcron(/etc/cron.d/bristlecone-sweep)を設定し、15分ごとに残高不足チェックを自動実行するようにしました。
2026年7月31日:並行処理の最適化とシステムベンチマーク
- Swarmベンチマーク: 150リクエストの負荷テスト(同時実行ワーカー50)を実施し、処理成功率100%を達成しました(従量課金対象のHTTP 200が136件、レート制限によるHTTP 429が14件、接続切断が0件)。残高も正確に照合されました。
2026年8月1日:AWS KMS HSM署名機能、Base L2 USDCスイーパー、KYB申請
- AWS KMS HSMのプロビジョニング: us-west-2にAWS KMSキー(ECC_SECG_P256K1)を設定し、制限付きIAMアイデンティティbristlecone-sweeper-botに紐付けました。運用署名用ホットウォレットアドレス0x1B4309CFdbCEee7618a7fBDc5b145691F9246D67を導出しました。
- オフライン署名エンジン(kms_signer.py): 生のASN.1 DER署名の解析、EIP-2に準拠したlow-S正規化、オフラインでのEIP-1559トランザクション構築を実装し、秘密鍵をローカルに保存せずにBase L2トランザクションへ署名できるようにしました。
- Base L2 USDCスイーパーデーモン(sweeper_daemon.py): Base L2(Chain ID 8453)上のネイティブUSDC(0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913)をポーリングし、ETHガスのしきい値を確認して、コントラクト送金を自動実行するバックグラウンドサービスを構築しました。
- Systemdへの登録とGit同期: bristlecone-sweeper.serviceデーモンをDRY_RUN_MODE = Trueでデプロイしました。コードベース全体をステージング、コミットし、GitHub(Bristlecone2026/bristlecone-logic、コミット95cc197)にプッシュしました。
- Coinbase BusinessのKYB申請: Coinbase Businessに法人オンボーディング書類を正式に提出しました。W-9税務自己証明(単一メンバーLLC/非課税事業体)を完了し、州の公印入りIdaho Certificate of Organization(B1137-4347.pdf、File # 0006897706、2026年7月13日提出)を添付しました。申請は標準的なコンプライアンス審査の対象としてシステムによりフラグ付けされました。
6. 主要な標準ディレクトリツリー
bristlecone-logic/
├── app/
│ ├── api/
│ │ ├── deps.py # 依存性注入(認証、DB、キー)
│ │ └── v1/
│ │ ├── admin.py # キーのプロビジョニング、クレジットの補充、スイープ
│ │ ├── agent.py # エージェント実行の中核ルーター
│ │ ├── billing.py # 残高照会と Webhook の設定
│ │ ├── dag.py # コミット DAG グラフのエンドポイント
│ │ └── router.py # メインの v1 ルーターアグリゲーター
│ ├── core/
│ │ ├── config.py # Pydantic 環境設定
│ │ └── security.py # パスワードのハッシュ化、JWT、API キーの検証
│ ├── database.py # 非同期 SQLAlchemy エンジンとセッションメーカー
│ ├── layer1_schemas/
│ │ └── base.py # 中核となる Pydantic コントラクトと分類バリデーター
│ ├── layer2_microservices/
│ │ └── router.py # FastAPI ルーターの実装
│ ├── layer3_orchestration/
│ │ ├── gemini_worker.py # カプセル化された Gemini LLM ワーカー
│ │ ├── orchestrator.py # ゼロトラストの実行境界
│ │ └── tool_gater.py # ホワイトリストと HMAC 署名の適用
│ ├── layer4_crypto/
│ │ └── signer.py # HMAC-SHA256 ペイロードの署名と検証
│ ├── layer5_telemetry/
│ │ └── evaluator.py # 品質メトリクスとテレメトリのログ記録
│ ├── middleware/
│ │ └── rate_limiter.py # トークンバケット方式のレート制限ミドルウェア
│ ├── models/
│ │ ├── __init__.py # 一元管理されたモデルレジストリ
│ │ ├── dag.py # CommitNode、CommitEdge、DendroRole モデル
│ │ └── domain.py # Tenant、User、Organization、Project モデル
│ ├── schemas/
│ │ └── dag.py # DAG 系譜の Pydantic レスポンスモデル
│ └── services/
│ ├── dag_service.py # 状態ハッシュの計算とノードの作成
│ └── notifications.py # 残高不足時のスイープと Webhook ワーカー
├── alembic/ # データベース移行スクリプト
├── nginx/
│ └── nginx.conf # Keepalive プーリングを備えたリバースプロキシ
├── dashboard.py # Streamlit 管理ダッシュボード
├── docker-compose.yml # 本番環境のコンテナーサービススタック
├── Dockerfile # マルチステージエンジンビルド仕様
├── kms_signer.py # AWS KMS HSM secp256k1 オフライン EIP-1559 署名者
├── main.py # API の最上位エントリーポイント
├── pyproject.toml # uv で管理されるプロジェクト依存関係
├── README.md # アーキテクチャの主要リファレンスドキュメント
├── sweeper_daemon.py # Base L2 USDC 自動トレジャリースイーパー
├── uv.lock # ロック済み依存関係マニフェスト
└── worker.py # バックグラウンド Redis Stream -> PostgreSQL ワーカー
7. 本番データベーススキーマリファレンス
┌──────────────────────┐ ┌──────────────────────┐
│ tenants │ │ projects │
├──────────────────────┤ ├──────────────────────┤
│ id (UUID) │◄──┐ │ id (INT) │◄──┐
│ name │ │ │ organization_id (INT)│ │
│ credit_balance_usd │ │ │ name │ │
│ rate_limit_rpm │ │ └──────────────────────┘ │
└──────────────────────┘ │ │
│ ┌──────────────────────┐ │
┌──────────────────────┐ │ │ commit_nodes │ │
│ api_keys │ │ ├──────────────────────┤ │
├──────────────────────┤ │ │ id (UUID) │ │
│ id (UUID) │ │ │ organization_id (INT)│ │
│ tenant_id (UUID) │───┼─┐ │ project_id (INT) │───┘
│ key_hash (VARCHAR) │ │ │ │ agent_role (ENUM) │
└──────────────────────┘ │ │ │ state_hash (VARCHAR) │
│ │ │ payload (JSONB) │
┌──────────────────────┐ │ │ └──────────────────────┘
│ llm_usage_ledger │ │ │
├──────────────────────┤ │ │ ┌──────────────────────┐
│ id (BIGSERIAL) │ │ │ │ commit_edges │
│ tenant_id (UUID) │───┘ │ ├──────────────────────┤
│ api_key_id (UUID) │─────┘ │ parent_id (UUID) │
│ input_tokens (INT) │ │ child_id (UUID) │
│ output_tokens (INT) │ └──────────────────────┘
│ billed_cost_usd │
└──────────────────────┘
8. Swarm のパフォーマンスとベンチマーク
============================================================
🚀 BRISTLECONE M2M SWARM 負荷テスト結果
対象: https://bristlecone\_proxy/api/v1/keys/test-metered
同時実行数: 50 ワーカー
合計リクエスト数:150 リクエスト
============================================================
📊 実行内訳
------------------------------------------------------------
合計時間: 2.971 秒
スループット: 50.48 リクエスト/秒
平均レイテンシ:831.53 ミリ秒
P95 レイテンシ:2037.22 ミリ秒
HTTP レスポンスステータス:
[HTTP 200](従量課金成功): 136
[HTTP 429](Redis によるレート制限):14
[HTTP 500/502](システムエラー): 0(失敗率 0.0%)
非同期永続化監査:
Redis Stream の記録数: 136 / 136
PostgreSQL ログ同期数: 136 / 136(取り込み率 100%)
テナントの初期残高: $100.000000
テナントの最終残高: $98.640000(一致)
============================================================
9. 現在のデプロイ状況、KYB 審査のクリア状況、運用収益化ロードマップ
2026年8月1日現在、Bristlecone Logic LLC の中核となる技術インフラは100%完成しており、セキュリティ強化済みで、本番ハードウェア上で稼働しています。5層のゼロトラスト API マイクロサービスエンジンはコンテナ化され、Vultr VPS(bristlecone-prod-1)にデプロイされています。PostgreSQL 16 による状態ストレージ、Redis によるホットパス計測、キープアライブ接続プーリングを備えた Nginx リバースプロキシがこれを支えています。金融セキュリティ面では、レイヤー0のハードウェアキー分離が完全に稼働しています。us-west-2 の AWS KMS が EIP-1559 トランザクション署名を生成し、sweeper_daemon.py は systemd(bristlecone-sweeper.service)の管理下で起動できる状態にあります。管理面では、IRS W-9 の自己証明書や、州の公印が押された Idaho Certificate of Organization の正式書類(B1137-4347.pdf、File # 0006897706)を含む、すべてのコンプライアンス書類を Coinbase Business に提出済みで、現在、標準的な手動 KYB 審査中です。
現在の本番稼働準備完了状態から、本番稼働と収益($$$)の創出へ直接移行するため、Coinbase のコンプライアンス審査が完了したら、次の4つの手順を直ちに実施します。
- Coinbase Business アカウントの有効化と保管先の紐付け: KYB 審査の承認後、Coinbase Business ポータルから専用の Base L2 USDC 入金アドレスを取得し、/opt/bristlecone/bristlecone-logic/.env の SWEEP_DESTINATION_ADDRESS に設定します。
- ガス用資金の補充: トランザクションのガス用資金を確保するため、運用ホットウォレット 0x1B4309CFdbCEee7618a7fBDc5b145691F9246D67 に、Base のネイティブ ETH を3.00~5.00ドル相当送金します。
- 自動スイーパーの起動: sweeper_daemon.py を更新して DRY_RUN_MODE = False に設定し、systemctl restart bristlecone-sweeper を実行して、受信した USDC を企業保管先へリアルタイムで自動ルーティングします。
- エンドポイント公開と商用利用開始: 早期導入の M2M クライアントや外部の自律型エージェント群向けに商用 API キー(bcl_...)を発行し、従量課金制の FastAPI エンドポイントを公開して、呼び出しごとの USDC マイクロペイメントを受け取り、Mercury の法人銀行口座へ自動決済します。
AWS KMS 署名、Redis による従量計測付きレート制限、Base L2 のトレジャリー統合を備えた6層のゼロトラストマイクロサービスエンジンを2週間足らずで構築できたことは、大きな節目です。インフラを予定どおりコンテナ化、テストし、本番環境へ投入できたことで、今後の構築に向けた極めて強固な基盤が整いました。
実際のお金と自律型エージェントの実行を扱う場合、運用計画と安全策はコードベースと同じくらい重要です。
ここでは、本番稼働後にシステムを監視、管理し、緊急停止する方法を説明します。
1. 監視の頻度とヘルスチェック
ヘッドレスの M2M エンジンを運用するには、自動バックグラウンドテレメトリと短時間の手動監査を組み合わせる必要があります。
| 頻度 | 対象/メトリクス | 方法/ツール | 運用上の対応 |
|---|---|---|---|
| リアルタイム(24時間365日) | コンテナとデーモンの状態 | systemd watchdog + Docker Healthchecks | 失敗したサービスを自動再起動し、システムログのアラートを出します。 |
| リアルタイム(24時間365日) | API の受信とレート制限 | レイヤー5 JSONL / OpenTelemetry(audit_log.jsonl) | 遅延の急増、HTTP 429 のレート制限、403 の署名拒否を記録します。 |
| 毎日(2分) | ホットウォレットのガス用資金 | Base RPC / BaseScan | ガス料金に備え、0x1B43... の ETH 残高が 2.00~3.00ドルを下回らないようにします。 |
| 毎週(10分) | 照合と台帳監査 | PostgreSQL llm_usage_ledger と Coinbase Ledger の比較 | マイクロセント単位の API 使用量がオフチェーンのクレジット残高および USDC の送金額と一致することを確認します。 |
2. 緊急キルスイッチ(即時停止する方法)
何らかの障害が発生した場合、RPC ノードがダウンした場合、または異常なエージェントの動作が発生した場合は、実行を直ちに停止する仕組みが必要です。3つの異なるサーキットブレーカーを用意しています。
レベル 1:デーモンの停止(トレジャリーのスイープを停止)
- シナリオ: Base ネットワークで異常なガス代の急騰が発生した場合、または対象のボールトアドレスが変更された場合。
- 実行: sudo systemctl stop bristlecone-sweeper を実行します。
- 効果: オンチェーンの USDC 自動スイープを直ちに一時停止します。M2M API の通信は通常どおり継続し、USDC はホットウォレットコントラクト内に安全に保管されます。
レベル 2:API ゲートウェイのロックアウト(M2M の受信を停止)
- シナリオ: 不正なエージェントの群れ、予期しないコードエラー、またはプロンプトインジェクションの試みがあった場合。
- 実行: /opt/bristlecone/bristlecone-logic/.env で MAINTENANCE_MODE=True に切り替えて再読み込みするか、Nginx を一時停止します(sudo systemctl stop nginx)。
- 効果: すべての受信 API リクエストを HTTP 503 応答で入口で拒否します。データ変換も LLM トークンの費用も一切発生しません。
レベル 3:AWS KMS 認証情報の失効(緊急の鍵停止)
- シナリオ: サーバーが侵害された場合、または Vultr VPS で root アクセスが突破された場合。
- 実行: AWS IAM コンソールにログインし、キー AKIAZ6J5P3YSONVJZAOG を無効化します。
- 効果: 秘密鍵は AWS KMS の HSM ハードウェアに保存され、サーバーのディスク上にもメモリ上にも決して存在しないため、IAM 認証情報を失効させると、サーバーはオンチェーン取引に署名できなくなります。
3. 脅威マトリックスと自動保護策
[ 受信攻撃/障害 ]
│
▼
┌──────────────────────┐
│ Layer 1: Schema Check│ ──(無効なペイロード)──► 拒否(422 Unprocessable)
└──────────────────────┘
│
▼
┌──────────────────────┐
│ Layer 4: HMAC Signer │ ──(改ざんされたヘッダー)─► 拒否(403 Forbidden)
└──────────────────────┘
│
▼
┌──────────────────────┐
│ Layer 4: Treasury Gate│──(Req > $50 上限)──► 拒否して凍結
└──────────────────────┘
- エージェントの暴走ループ: Layer 4 Treasury Gate は単一取引の上限を $50.00 に設定し、Redis Lua Metering Gate は1分あたりのリクエスト数(RPM)を制限します。エージェントが暴走ループでクレジットを使い果たすことはありません。
- 不正なコード実行/データ破損: Commit DAG Engine(commit_nodes と commit_edges)は、実行ノードごとに決定論的な SHA-256 状態ハッシュを生成します。後続のワーカーが失敗した場合、データベースを破損させることなく、システムは最後に有効だった親コミットまで巻き戻します。
Coinbase の KYB 審査が完了し、ライブボールトを設定したら、ドライランのチェックリストを一緒に一通り確認できます。
自動リアルタイムアラート(例:ガス残高の低下、エラー率の上昇)を最初に設定する通知チャネルはどれがよいですか? Discord webhook、Telegram bot、それとも Twilio SMS でしょうか?
記録しておきました、Josh。個人口座と事業用口座を分けることは、法人格の独立性を維持し、Bristlecone Logic LLC の賠償責任を保護するうえで不可欠です。
事前チェックリスト:Bristlecone Logic LLC の法務・運用の分離
本番コマンドを実行する前に、すべてのサービスが明示的に Bristlecone Logic LLC の所有であり、同社名義で請求されていることを監査・確認します。
- [x] AWS(KMS と署名): Bristlecone Logic LLC 名義のアカウントです。
- [x] Vultr(サーバーインフラストラクチャ): Bristlecone Logic LLC 名義のアカウントです。
- [x] GitHub(リポジトリホスト): Bristlecone Logic LLC 名義のアカウントです。
- [x] Coinbase Business: LLC の KYB 申請は現在、最終審査中です。
- [ ] Google Cloud / AI Studio(API キー): 個人アカウントから、Bristlecone Logic LLC 専用の Google Cloud プロジェクトに移行し、API 利用料金の請求用に法人名義の Mercury Bank カードを登録して、法人用の GEMINI_API_KEY を発行します。
- [ ] チャットワークスペースへのアクセス(会話型 AI): Bristlecone Logic LLC 用の Google Workspace アカウント(@bristlecone...)を Gemini と連携して設定します。これにより、戦略計画の会話、コードレビュー、エンジンの作業をすべて、企業の法的保護の下で安全に行い、エンタープライズ向けデータプライバシーを確保します。
すべて記録しています。Coinbase の審査が完了したら、このチェックリストを項目ごとに確認し、すべてのコード行、API リクエスト、資金が LLC 内に厳密に分離されていることを確かめます。
使用するシードプロンプト:
私は Bristlecone Logic LLC の創業者、Joshua Simpson です。すべてのインフラストラクチャ、システム運用、エンジニアリングに関する議論を、企業の法的保護の下で厳密に行っています。
あなたは「Jim」です。私と直接やり取りする、客観的な AI エンジニアリング協力者です。中核となる運用指針は次のとおりです。
1. 客観的で対等な姿勢を保ちます。誇張、お世辞、不要な謝罪を避け、率直で地に足のついた分析、解決策、技術的なフィードバックを提示します。
2. すべてのプロジェクトに関する議論、アーキテクチャ、戦略を通じて、一貫性を厳格に保ちます。
3. 実行と計画のあらゆる側面で、客観的かつ事実に基づき、正確であり続けます。
プロジェクトの背景とシステムアーキテクチャ:
6 層のゼロトラスト M2M エンジンを自動化して構築・運用しています。主な仕様は次のとおりです。
- インフラストラクチャ:AWS KMS(HSM トランザクション署名)、Vultr クラウドホスティング、GitHub、Redis によるレート制限、Base L2 での実行。
- テレメトリーとアラート:リアルタイムアラート(スイープ、ガス、エラー)用の Discord Webhook ブリッジ。
- ガードレール:運用資金としての ETH 50 ドル分の上限、および 3 段階の緊急キルスイッチ戦略(デーモン停止、API ゲートウェイのロック、KMS の失効)。
添付のコンテキスト:
以下または添付の資料は、本番環境の Blueprint 3.0 の Markdown ドキュメントです。システムアーキテクチャ、環境仕様、運用ワークフローの全体を記載しています。
タスク:
このフレームワークを確認し、ここに示した厳密なガードレールに従って「Jim」(Gemini にちなんだ名前)のペルソナを採用し、初期化が完了し、Bristlecone Logic LLC の作業を引き継ぐ準備ができていることを確認してください。
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。