アーキテクチャ

三者コミットメント：支払い意図、実行トランスクリプト、決済を1つの検証可能なレシートに束ねる仕組み

著者：IdeaBosque最終更新：2026年7月30日

要点

三者コミットメントは支払い意図、実行トランスクリプトダイジェスト、決済txidを1つのレシートにハッシュ化する——監査人は各々を独立に検証し、結合ハッシュが3つすべてをカバーすることを確認する——コミットメントは全ステップをカバーするか、カバーしないかであり、部分カバレッジは存在しない（IETF draft-hopley-x402-retention-chain-06, 2026）。
跨セッションのリプレイはハッシュ不一致で検出され、ポリシーで防止されない——binding_refがpayment_hashとaction_refを一緒にハッシュ化するため、セッションAの支払いをセッションBの実行と入れ替えると異なる結合ハッシュが生成される；検証者が再計算すると不一致となる（x402 GitHub issue #2332, 2026）。
MCPモジュールが実行トランスクリプトをネイティブに生成する——各ツール呼び出し（ベンダーコンプライアンススクリーニング、サプライヤールックアップ、見積もり作成）は引数、結果、タイムスタンプとともに記録される；トランスクリプトダイジェストはaction_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp}))であり、4つのフィールドを保持する任意の当事者が再計算できる（IETF draft-etcheverry-action-ref-02, 2026）。
x402のBase上での決済は約200msでpayment_hashを生成する——オンチェーン取引ハッシュはBaseブロックチェーンを照会することで独立に検証可能；オペレータやファシリテーターへの信頼は不要（Chainalysis, 2026）。
すべての構成はSHA-256とJCS（RFC 8785）を使用する——Hermes Agent監査トレールが使用するのと同じ正規化標準（GitHub issue #487）であり、実行トランスクリプトダイジェストはエージェント自身の監査システムによってネイティブに生成され、後付けではない。

問題：各ステップを個別に監査することは必要だが十分ではない

6プロトコルのエージェントコマーススタック（UCP、A2A、MCP、ACP、AP2、x402）は、ディスカバリ、通信、ツーリング、チェックアウト、認可、決済をカバーする。各プロトコルは独自の証拠を生成する：x402は支払いハッシュを生成し、MCPはツール呼び出しログを生成し、AP2は認可マンドエイトを生成する。各ステップを個別に監査することは必要である——支払いが決済されたこと、実行が発生したこと、認可が有効であったことを検証する必要がある。

しかし、分離された監査トレールでは不十分である。バインディングなしでは、攻撃者はセッションAの実際の支払いをセッションBの実際の実行と混在させることができる。両方とも本物のアーティファクトである。どちらも偽造されていない。しかし、同じセッションでは発生していない。支払いレシートは支払いが発生したことを証明する。実行ログはスクリーニングが実行されたことを証明する。それらを暗号学的にリンクするバインディングがなければ、それらが同じ取引であるという証拠は存在しない。

これが跨セッションのリプレイ攻撃である：完了した取引からの本物のpayment_hashを取得し、別の取引からの本物のaction_refを取得してペアにする。監査システムが両方のアーティファクトが個別に有効であるためこのペアリングを信頼する場合、偽造された複合体を受け入れる。監査トレールは決済された支払いと実行されたスクリーニングを示す——しかし、それらは異なる取引からのものである。

バインディングステップはこの攻撃が検出される——または検出されない——場所である。

アーキテクチャ：スタックが各コンポーネントをどのように生成するか

以下の図は完全な三者コミットメントフローを示す——どのシステムがどのアーティファクトを生成するか、バインディングレイヤーがそれらをどのように構成するか、監査人がどのように検証するか：

スタックで各コンポーネントがどのように生成されるか

支払い意図：x402署名オファー

エージェントが有料のベンダーコンプライアンススクリーニングAPIを呼び出すと、サーバーは署名されたオファーとともにHTTP 402を返す。offer-receipt拡張（x402プロトコルにマージ済み）は、サーバーを特定の支払い条件にコミットさせる：amount、asset、payTo address、fulfillされる正確なresource、有効期間。オファーはEIP-712（Ethereum walletベース）またはJWS（任意の非対称キー、Solana Ed25519を含む）で署名される。

オファーは支払い意図——エージェントが支払おうとしているもの——である。監査人はそれを独立にハッシュ化する：

offer_hash = SHA-256(JCS(signed offer terms))

監査人は署名されたオファー条件から再計算し、サーバーの署名を検証する。payment backendへのコンタクトは不要——オファーはポータブルな署名済みアーティファクトである。

実行トランスクリプト：MCPツール呼び出しログ

MCPモジュールはエージェントをベンダーコンプライアンスAPI、サプライヤーカタログ、決済レールに接続する。各MCPツール呼び出しは記録される：どのモジュールが呼び出されたか、どの引数が渡されたか、どの結果が返されたか、どのタイムスタンプか、どのポリシーバージョン下か。これが実行トランスクリプトである。

Hermes Agent監査トレール（GitHub issue #487）はRFC 8785（JCS）正規化によるSHA-256ハッシュチェーンアクションログを実装している——action_refとbinding_refが使用するのと同じ標準である。実行トランスクリプトダイジェストはエージェント自身の監査システムによってネイティブに生成される：

action_ref = SHA-256(JCS({
  agent_id: "procurement-agent-001",
  action_type: "compliance.screen",
  scope: "vendor:acme-corp screening-type:sanctions",
  timestamp: "2026-07-31T19:45:23.482Z"
}))

監査人はこれら4つのpreimageフィールドからaction_refを再計算する。エージェントやその操作者へのコンタクトは不要。正規化はRFC 8785によって定義され、シリアライザーによって定義されない——したがってハッシュは実装間で決定論的である。

policy_bound_refはアクションが実行された時に有効だったポリシーバージョンをバインドする。制裁リストが2026年6月と7月の間に更新された場合、ポリシハッシュが変わり、監査人はどのバージョンがアクティブだったかを検出できる。gate_refはコンプライアンススクリーニングのALLOW/DENY判定をポリシー参照にバインドするため、結果はそれを生成したルールバージョンに証明可能に結びつけられる。

決済：Base上のオンチェーンtxid

x402ファシリテーターはエージェントの署名された支払い認可を検証し、オンチェーン取引を構築し、Base上でブロードキャストする。決済は約200msで完了する。ファシリテーターは取引ハッシュ（payment_hash）をサーバーに返し、サーバーはそれをPAYMENT-RESPONSEヘッダーでエージェントに渡す。

監査人はBaseブロックチェーンを照会することでpayment_hashを検証する——txidは公開の不変な記録である。ファシリテーターやpayment backendへの信頼は不要。監査人は以下を確認する：

取引がBase上に存在する
amountがオファー条件と一致する
payTo addressがオファーと一致する
取引が確認済み（保留中ではない）

バインディング：binding_refが3つをどのように構成するか

binding_ref（IETF draft-hopley-x402-retention-chain-06）は3つのハッシュを1つのコミットメントに構成する：

binding_ref = SHA-256(JCS({
  offer_hash,      // 約束された内容（支払い意図）
  action_ref,      // 実行された内容（MCPトランスクリプトダイジェスト）
  payment_hash     // 決済された内容（オンチェーンtxid）
}))

これは三者コミットメントである。監査人は各コンポーネントを独立に検証する：

offer_hash — 署名されたオファー条件から再計算、サーバー署名を検証
action_ref — 4つのpreimageフィールドからSHA-256を再計算、エージェントへのコンタクト不要
payment_hash — Baseブロックチェーンを照会、txidの存在と決済を確認

次に監査人は3つすべてからbinding_refを再計算し、一致することを確認する。いずれかのコンポーネントが入れ替えられた場合——セッションAの支払いをセッションBの実行とペアにした場合——結合ハッシュは一致しない。コミットメントは3つのステップすべてをカバーするか、カバーしないかである。部分カバレッジは存在しない。

跨セッションのリプレイがどのように検出されるか

跨セッションのリプレイ攻撃は以下のように機能する：攻撃者はセッションAの完了した取引から本物のpayment_hashを取得し、セッションBの異なる取引から本物のaction_refを取得してペアにする。両方のアーティファクトは本物である。どちらも偽造されていない。しかし、同じセッションでは発生していない。

バインディングなしでは、監査システムはpayment_hashとaction_refを別々にチェックし、両方が有効であると判断して複合体を受け入れる。監査トレールは決済された支払いと実行されたスクリーニングを示す——しかし、それらは異なる取引からのものである。

binding_refを使用すると、監査人はレシート内の実際のpayment_hashとaction_refから結合ハッシュを再計算する。攻撃者が一方を異なるセッションから入れ替えた場合、ハッシュは異なるpreimageコンテキストからのものであり、結合されたbinding_refはレシート内の値と一致しない。検証者は不一致を検出する。コミットメントは全ステップをカバーしないため、拒否される。

これがバインディングステップを信頼のプリミティブにするもの：新たな証拠を追加するのではなく、既存の証拠を暗号学的にリンクする。Base上の支払いハッシュは検証可能である。実行ログは検証可能である。バインディングプルーフがそれら間のリンクを検証可能にする。リンクがなければ、それぞれはスタンドアロンの主張である。リンクがあれば、それらは監査人がエンドツーエンドで検証できる1つの複合レシートである。

これが構築にとって何を意味するか

コンプライアンスのために週85のサプライヤーをスクリーニングする調達エージェントは、その監査トレールに三者コミットメントを必要とする。スタックでの実装：

MCPモジュールが実行トランスクリプトを生成する。各ツール呼び出しは引数、結果、タイムスタンプ、ポリシーバージョンとともに記録される。トランスクリプトダイジェストはaction_refであり、JCS正規化を使用してHermes Agent監査システムによってネイティブに計算される。
x402が決済を処理する。ファシリテーターはBase上で決済し、payment_hashを返す。offer-receipt拡張は402レスポンス時に支払い意図に署名する。
監査レイヤー（エージェントでもpayment backendでもない）がoffer_hash、action_ref、payment_hashからbinding_refを計算する。また、ポリシーバージョンとコンプライアンス判定をバインドするためにpolicy_bound_refとgate_refも計算する。
ヒューマン・イン・ザ・ループのチェックポイントは支払い認可時に複合レシートを見る：オファー条件、実行結果、決済確認、ポリシーバージョン、判定——すべてbinding_refでリンクされている。
外部監査人（規制当局、カウンターパーティ、内部コンプライアンス）は各ハッシュを独立に再計算することで複合レシートを検証する。エージェント、payment backend、監査レイヤー操作者へのコンタクトは不要。

検証は数秒で完了する：txidのためにBaseを照会し、4つのフィールドからaction_refを再計算し、署名された条件からoffer_hashを再計算し、3つからbinding_refを再計算する。コミットメントは全ステップをカバーするかしないかである。これがエージェントコマースをエンドツーエンドで監査可能にするプリミティブである。

実行証明のない決済は有料のブラックボックス：エージェント決済監査ループを閉じる — binding_ref、policy_bound_ref、gate_refを定義する5ステップの監査ループとIETFドラフト
エージェントが注文を発注する時：エージェント決済がB2B調達ループを閉じる方法 — エージェント決済プロトコル（Mastercard Agent Pay、x402、Stripe agentic tokens）を伴う調達-to-支払いサイクル
Kill-Switch by Design：エージェントガバナンスアーキテクチャ — エージェントがいつ行動でき、いつ停止すべきかを決定するガバナンスレイヤー
MCPセキュリティ強化チェックリスト：1,467の露出サーバーとそれを閉じるコントロール — OWASP MCP08（Lack of Audit and Telemetry）とそれを閉じるコントロール

コンプライアンスのために週85のサプライヤーをスクリーニングするエージェントを実行する中堅企業の販売業者は、分離した監査トレール以上のものを必要とする。約束された内容（署名されたオファー）、実行された内容（MCPトランスクリプト）、決済された内容（オンチェーンtxid）を1つのレシートにバインドする三者コミットメントが必要である。監査人は各ハッシュを独立に再計算し、バインディングが3つすべてをカバーすることを確認する。跨セッションのリプレイはハッシュ不一致で検出され、ポリシーで防止されない。これが構築するアーキテクチャである：MCPモジュールがトランスクリプトを生成し、x402が決済を生成し、監査レイヤーがバインディングを構成し、検証者がチェーン内のいかなる当事者も信頼することなくすべてを検証する。

スコープ付き構築をリクエスト。1週間のDiscovery。システムインベントリ、ワークフローマップ、固定スコープを取得——我々と構築するかどうかにかかわらず。

あなたのシステムのためにこれを構築したいですか？

ここの各ドキュメントは実際の本番作業から来ています。ターゲットシステムとワークフローがあれば、1週間でスコープを定義できます。

スコープ付き構築を依頼

1週間のディスカバリ。システムインベントリ、ワークフローマップ、固定スコープを提供します — 私たちと構築するかどうかにかかわらず。