baton

🏃 BATON

AI の作業を、受領証付きで引き継ぎます。

AI が作業を完了しました。次の担当者、あるいは次の AI は、ビルドが通っただけでなく、実際に動作することをどう確認すればよいでしょうか？ BATON は AI の作業単位を持ち運び可能なカプセルに封入し、独立した検証者がそれを再実行して、サーバー署名付き検証受領証を発行します。受け手が信頼するのは主張ではなく、観測された証拠です。

受領証のないエージェント間の引き継ぎは、決して信頼しないでください。

BATON は標準的な MCP（Model Context Protocol）サーバーです。MCP 対応ツール（Claude Code、Codex CLI、Gemini CLI、Cursor など）は、1 つの URL で接続できます。作業の作成者と検証者は、異なるモデル、マシン、人物でもかまいません。

なぜこれを選ぶのか。数あるオーケストレーションツールと何が違うのか？

Claude、Codex、Gemini を連携させる仕組み（スウォーム、ルーム、エージェントメッセージング）は、すでに競争の激しい分野です。BATON はそのようなものではありません。ほとんど誰も行っていないのは、引き継ぎ用アーティファクトを、独立した実行証拠と結び付け、偽造を証明できる単一の信頼単位にすることです。 それが受領証です。

Claude did the work
   ↓  baton_pass  → sealed capsule (BTN-H-…)
Codex / a teammate receives it
   ↓  baton_verify → replay in a clean env, observe the real flow
   ↓
🕸️ VERIFIED — signed receipt: who verified · what was observed · in what env · with what artifacts
   ↓
trust  (or reject)

実際の購入者は「Claude から Codex に切り替える自分」（リポジトリを読み直せば済む）ではありません。外注先から社内へ、退職者から後任へ、韓国チームから米国チームへの引き継ぎです。「AI が作ったものは、本当に動くのか？」という問いには、答えを得るために費用を払う価値があります。

受領証（差別化要因）

baton_verify は ✅ のシールを返すのではありません。署名済みの記録を返します。

{
  "kind": "baton.verification-receipt/v1",
  "capsule": "BTN-H-…",              // the handoff this verifies
  "verifier": "receiver-spider",    // WHO verified — independent of the producer
  "environment": { "os": "ubuntu-24.04", "node": "24.2" },
  "observed": [{ "claim": "payment succeeds", "observed": true,
                 "detail": "POST /pay 200 + order row +1" }],
  "artifacts": ["playwright.trace.zip", "network.har"],
  "verdict": "verified",
  "signature": "…hmac-sha256…"       // server-signed → tamper the verdict, break the sig
}

再署名せずに verdict を "verified" に書き換えると、バッジは拒否されます。ビルドに成功しただけでは verified は得られません。verified が認められるのは、観測された E2E のみです（これにより、何も書き込まずに 200 を返すサイレントな upsert を検出できます）。

ツール

グループ	ツール	機能
引き継ぎ	baton_pass baton_receive baton_diff baton_revoke	作業カプセルをコード（BTN-H-…）に封印して引き継ぎ、バージョン間の差分を確認します。本文はコード由来の鍵で暗号化されるため、サーバーは平文を参照できません
検証	baton_verify baton_verify_plan baton_consolidate + spider_* ×6	独立した検証者が再実行し、署名済み受領証を発行します（観測なし、🕸️なし）。consolidate は、多数の引き継ぎを信頼レベルごとに 1 つの結果ボードにまとめます
チームルーム (補助機能)	baton_create_room baton_new_invite baton_join baton_send baton_inbox baton_who baton_leave baton_kick baton_approve baton_close_room	オーナーが管理する永続的なルームです。参加者はローテーション式の招待コード（BTN-R-…、72h、有効期限後に再発行可能）で参加します。オーナーはメンバーの退出、参加承認（任意の参加制限）、ルームの終了を実行できます。参加後のアクティビティは member_id に基づいて管理されます
運用	baton_task_* baton_git_* baton_cost_*	循環安全な非公開タスク DAG、Git のコミット／差分／テスト証拠の紐付け、冪等性を備えたプロバイダー／モデル／タスク別コスト台帳

運用ダッシュボード：/ops.html。タスクのメタデータ、Git の証拠、コスト情報のみを保存します。BATON がリポジトリの認証情報を求めることはありません。

ネットワークダッシュボード：/network.html。Shared Memory はアカウントキーで本文を暗号化し、メタデータのみを検索します。MCP Hub は認証情報を含む URL を拒否します。Marketplace の評価対象となるのは、独立したサーバー署名付き VERIFIED 受領証のみです。

すべての公開画面は韓国語をデフォルトで提供し、/dash.html（協業ルーム）、/board.html（検証結果）、/ops.html（作業・Git・コスト）、/network.html（メモリー・MCP・エージェント）を相互に連携します。

設計原則（セキュリティレビューに基づく）

• コード由来の暗号化。 サーバーに保存されるのは ciphertext + code_hash のみです。コードがなければ、運用者でさえ平文を読めません。これは「利用者を囲い込めない」ことの証明です。
• 署名付き受領証。 判定結果はサーバー側で HMAC 署名されます（BATON_RECEIPT_SECRET）。クライアントが verified を偽造することはできません。
• プロンプトインジェクションの封じ込め。 受信したカプセル／メッセージは信頼できないデータとしてフェンスで囲んで返されます。保存前に秘密情報は自動的にマスキングされます。
• コードは 128 ビット以上の秘密情報です。 使い捨てコードの引き換えはアトミックに処理され、エイリアスのなりすましはブロックされます。
• ビルドの成功 ≠ 動作の保証。 verified には、静的解析だけではなく、観測された副作用が必要です。

実行

npm install
npm test                                      # 15/15 E2E groups pass
node src/server.js                            # stdio (local / any CLI)
BATON_HTTP=1 PORT=8080 node src/server.js      # remote Streamable HTTP

登録（リモート）

claude mcp add --transport http baton https://baton-mcp-production.up.railway.app/mcp

課金／利用制限はデフォルトで無効です（内部テスト段階）。利用制限を再度有効にするには、BATON_BILLING=on を設定してください。詳しくは USAGE.md をご覧ください。

ストレージ

MVP では SQLite（better-sqlite3）を使用します。単一バイナリとしてセルフホストできます。ホステッドサービスでは、src/store.js の最小限のインターフェースに Postgres アダプターを追加します。

ライセンス

MIT