Arcaeon Adapter

arcaeon-adapter

arcaeon-ledgerは、記録が改ざんされていないことを証明します。しかし、記録が 完全 であることは証明できません。何を書くかを決めるのはエージェントだからです。これは記録を担うペンを移します。

arcaeon-adapterは、MCP クライアントと MCP サーバーの間に置かれるstdioプロキシです。JSON-RPCをバイト単位でそのまま転送し、tools/callのたびに、呼び出されたツール、引数と結果のダイジェスト、成功かエラーか、処理時間を記録したハッシュチェーン付きの1行を独自の台帳に書き込みます。

独立したOSプロセスとして実行されます。エージェントに確認を求めず、エージェントはこれをスキップできず、見ることもできません。

pip install arcaeon-adapter arcaeon-ledger

任意のMCPサーバーのコマンドを、設定を1行追加するだけでコードを一切書かずにラップできます。

{ "mcpServers": {
    "ledger": {
      "command": "python",
      "args": ["-m", "arcaeon_adapter", "--ledger", "seam.log.jsonl", "--",
               "python", "-m", "arcaeon_ledger.mcp_server", "--log", "agent.log.jsonl"]
    }
} }

シェルから直接実行することもできます。

python -m arcaeon_adapter --ledger seam.log.jsonl -- <your mcp server command...>

ログに記録される内容

arcaeon-ledger自身のMCPサーバーをラップして記録した実際の行です（台帳自身が台帳を記録）。幅に合わせて短縮しています。アダプター0.1.0、台帳0.5.7で取得しました。現在の実行では、インストール済みのバージョンがseam_implとledger_backendに記録されます。

{"evt":"session_begin","seam":"mcp-stdio","seam_impl":"arcaeon-adapter/0.1.0",
 "session":"25eda195-70e8-45cb-9035-be9f61cfc759","seq":1,
 "server":"arcaeon_ledger.mcp_server","ledger_backend":"arcaeon-ledger/0.5.7",
 "command":["python","-m","arcaeon_ledger.mcp_server","--log","agent.log.jsonl"],
 "command_digest":"sha256:json-c14n:v1:ec06bd01…","raw_payloads":false,
 "ts":"2026-08-19T14:18:08Z","chain":"0081ec1fe5d98395192f595e553b4133"}

{"evt":"tools_list","seq":3,"tools":["ledger_append","ledger_verify"],"tool_count":2,
 "tools_digest":"sha256:json-c14n:v1:b85c9fce…","status":"ok", …}

{"evt":"tool_call","seq":4,"tool":"ledger_append","rpc_id":"3",
 "args_digest":"sha256:json-c14n:v1:cfb2bb50…",
 "result_digest":"sha256:json-c14n:v1:ba037f70…",
 "status":"ok","ms":144, …}

{"evt":"session_end","seq":6,"reason":"child_exit","exit_code":0,
 "rows_before_end":5,"calls":2, …}

同じ実行で、ラップされたサーバー自身のログ、つまりエージェントがledger_appendを呼び出すのを覚えていたときに残す日誌には、1行しかありませんでした。一方、シームログには6行ありました。この違いこそが、この製品のすべてです。

フィールド	用途
evt	tool_call、session_begin、session_end、mcp_initialize、tools_list
seam	常に"mcp-stdio"です。これは来歴の階層を示します。独立したプロセスがプロトコルレベルでこれを観測しました。下流の検証ツールはこのフィールドを読み取り、インフラストラクチャレベルの記録と、エージェントが単に呼び出さないこともできる協調的なインプロセスコールバックとを区別します。
session / seq	プロキシプロセス1つにつきセッション1つです。seqはその中で密な全順序を示します。session_beginとsession_endが実行を挟むため、レビュー担当者はセッションの開始と終了を対にできます。
args_digest / result_digest	sha256:json-c14n:v1:<hex>です。自己記述型なので、行だけを持つ第三者でも計算を再現できます。
status / ms	ok / error / unansweredと、実時間での所要時間です。errorにはJSON-RPCのerrorと、isError: trueを含むresultの両方が該当します。

デフォルトではペイロードではなくダイジェストを記録します。 行は、シームを通過したバイト列が「どれだったか」を証明しますが、その内容は保持しません。ひそかにすべてのプロンプトと結果のコピーになってしまう監査ログは資産ではなく負債です。人に依存しないコアであれば、何年にもわたって保持しやすくなります。このリスクを引き受けるデプロイ担当者向けに、--rawを指定するとペイロードを埋め込みます。どちらの場合もダイジェストは保持されます。

応答が返らない呼び出しも行として記録されます（status: "unanswered"）。そうしなければ、「呼び出しの途中でサーバーを停止する」ことで、シームに痕跡を残さずアクションを実行できてしまいます。それこそ、この仕組みが塞ごうとしている穴です。

検証する

シームログは通常のarcaeon-ledgerファイルです。

python -m arcaeon_ledger.cli verify seam.log.jsonl

行を編集、削除、並べ替えすると、それ以降のリンクはすべて壊れ、verifyが該当する行を正確に示します。

誠実さの限界

ある接点にアダプターを設置すると、その接点を完全に記録します。それ以外は記録しません。 エージェントは依然として、その外側で動作できます。直接の HTTP 呼び出し、ラップされていない MCP サーバー、シェルコマンドは、このプロキシを通らず、台帳にも記録されません。二重帳簿の問題はなくなりません。どのようなロギング層でも、完全な誠実さを強制することはできません。アダプターが保証するのは、より限定的ながら確かなことです。計装された接点を通過したものはすべて、自動的に記録され、その記録自体が正しさを証明します。 誠実さを強制するのは接点であり、あらゆる場所ではありません。錠前ではなく、近隣のようなものです。

具体的には、以下は把握できません。

• ハーネスに組み込まれたツール（Bash、ファイル編集、ウェブ取得）。これらは MCP に触れません
• ラップしていない MCP サーバー
• エージェントがネイティブに実行する HTTP
• モデルの推論。これはアクションではなく、ワイヤー上に痕跡を残しません
• --max-frame より大きなフレーム（中継は正常に行いますが、session_end で oversize_frames_unlogged として集計・報告されます。記録漏れが黙って発生することはありません）

コンプライアンスについても、はっきり述べておきます。これによって誰かが何らかの規制に準拠できるようになるわけではありません。 EU AI Act の第 12 条のような規制は、提供者または導入者に義務を課すものであり、義務を負うのはライブラリではなく人です。これは、ある接点での記録を任意ではなく自動にする仕組みです。通常なら自分で構築しなければならないものです。保持ポリシー、ログの意味づけ、リスク分類、その他すべての義務は、引き続きあなたの責任です。「コンプライアンスを実現する」パッケージを売り込む人は、作り話を売っています。

設定を管理する人は、ラッパーを取り外すこともできます。これはあらゆるロギング層に共通する限界であり、脚注ではなく、ここに明記しています。

忠実性は P0 の特性です

顧客の JSON-RPC を破損、並べ替え、または遅延させるプロキシは、プロキシがないより悪いものです。そのため、設計では構造的に観測より忠実性を優先しています。

• バイト列を先に転送し、そのコピーを後から観測します。 ここでの解析不具合によって、トラフィックが変更されたり、遮断されたりすることはありません。最悪の場合でも、誤った行が出力されるだけです。
• 最初から最後まで生のバイナリです。 どこにもテキストモードは使いません。Windows では、テキストモードにすると \n が \r\n に書き換えられ、すべてのフレームが気づかないうちに変更されるためです。
• フレームの再構成は一切行いません。 フレームを解析して再出力することはありません。典型的なプロキシの不具合は json.dumps(json.loads(frame)) です。意味は同じでも、バイト列は異なります。
• 各方向につき 1 スレッドを使うため、各方向内の順序は OS によって保たれます。
• 子プロセスの stderr はパイプ接続せず、継承します。 診断情報はラップされていない場合と同じ場所に出力され、正常な実行中にプロキシ自体が何かを出力することはありません。
• 不正なフレームはそのまま中継し、記録しません。 サーバーが stdout に余計な行を出力しても動作し続けます。監査記録に推測を残すのは作り話になるため、推測はしません。
• 子プロセスの終了コードが、プロキシの終了コードになります。

このテストでは、スクリプト化されたクライアントを合成 MCP サーバーに直接接続した場合と、プロキシ経由で接続した場合とで実行し、2 つの stdout ストリームがバイト単位で同一であることを確認します。これには、約 64 回のパイプリードにまたがる 4 MB のフレーム、Unicode、埋め込み CRLF、不正な行、ID のない通知、末尾に改行のない最終フレームが含まれます。

チェックが失敗することを証明する

python -m arcaeon_adapter.selftest

一度も失敗したことのない計測器は、何も証明しません。各ケースはクリーンなフィクスチャで GREEN になることを確認した後、変更を加えて同じチェックが RED になることを必須とします。変更が何もしない場合も何も証明しないため、その間に no-op ガードを挟みます。出力は一部省略しています（各 PASS 行の先頭 2 行と末尾をカットしています。drop_byte の長さは実行ごとに 1〜2 バイト異なります）。

PASS passthrough_fidelity GREEN: 2001202 bytes identical byte-for-byte through the proxy
PASS passthrough_fidelity RED on reserialize: corruption detected (length 2001202 vs 2001097)
PASS passthrough_fidelity RED on drop_byte: corruption detected (length 2001202 vs 2001168)
PASS one_row_per_call GREEN: 5 tools/call frames -> 5 tool_call rows, 9 rows total, seq 1..9
PASS one_row_per_call RED on log_on_request: count check caught 10 rows for 5 calls
PASS unanswered_call_logged GREEN: unanswered `quiet` call rowed with args_digest bound
PASS unanswered_call_logged RED on no_flush: dropping the shutdown flush loses the row
PASS tamper_detected GREEN: seam log verifies (ok=True, rows=9)
PASS tamper_detected RED on edited args_digest: first_break='line 4: chain mismatch'
PASS digest_recipe_frozen GREEN: 3 frozen json-c14n:v1 vectors reproduce exactly
PASS digest_recipe_frozen RED on unsorted_keys: drifted canonicalizer produces a different digest

ALL CHECKS PASSED — and every one was observed failing on its own defect.

忠実性の変更はモックではなく、実際のリレーに注入します。これにより、出荷されるコードパスに回帰があった場合、比較でそれを検出できることが証明されます。

オプション

--ledger PATH      seam ledger (required). Keep it SEPARATE from any ledger the
                   wrapped server writes: one file, one writer, clean provenance.
--server NAME      label for the wrapped server in every row (default: derived
                   from the command — `-m pkg.mod` reads as "pkg.mod", not "python")
--session ID       session id (default: a fresh uuid4 per proxy process)
--raw              embed raw argument and result payloads. Off by default.
--max-frame BYTES  frames larger than this are relayed but not logged (default 64 MiB)

インストールと依存関係

実行時の依存関係は標準ライブラリのみです。arcaeon-ledger は想定される書き込みツールで、行の証明可能性を担いますが、意図的に必須依存にはしていません。これは、設定を1行編集するだけで他者の稼働中の MCP サーバーに組み込めるようにするためです。パッケージが見つからないことが原因でサーバーの起動に失敗することは、決してあってはなりません。これがない場合、行はバイト互換のフォールバックによって書き込まれ、session_begin の ledger_backend にその旨が示されるため、レビュー担当者はチェーンの生成にどちらの書き込みツールが使われたのか推測する必要がありません。 （このバイト互換性はここで主張しているだけではなく、テストスイートで検証されています。）

実行時のネットワーク呼び出しはありません。 一切ありません。

pytest -q                            # 146 tests
python -m arcaeon_adapter.selftest   # the mutation harness

ステータス

v0。動作し、テスト済みで、自社の MCP サーバーで実際に使用しています。意図的にまだ実装していない機能は、--authority によるスタンプ付与、--bind-inputs による成果物のバインド、--auto-pin による証人の公開、およびハーネスフック／HTTP ゲートウェイとの接続部です。CHANGELOG.md を参照してください。

MIT。