アーキテクチャ

実行証明のない決済は有料のブラックボックス：エージェント決済監査ループを閉じる

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

主要ポイント

x402は初年度にBase上で1億6,900万件のエージェント決済を処理したが、payment_hashが証明するのは取引が決済されたことのみ——エージェントが何をしたかではない——レシート拡張（OMA3/x402、プロトコルに統合）は誰が支払ったか、どのサービスにアクセスしたか、いつ支払ったか、および支払い参照を記録するが、サーバー側でどのスクリーニングバージョン、ポリシールール、モデルバージョンが実行されたかは記録しない（Chainalysis, 2026; OMA3, 2026）。
IETF action_refドラフト（draft-etcheverry-action-ref-02, 2026年7月）はコンテンツアドレス識別子を定義する——agent_id、action_type、scope、timestampの正規JSONに対するSHA-256——発行者を信頼せずに監査人が再計算できる——ポリシーバージョンの監査可能性のためのオプションフィールドを含み、監査人はルール7が発火したことだけでなく、その瞬間にアクティブだったルール7のバージョンも特定できる。
IETF x402-retention-chainドラフト（draft-hopley-x402-retention-chain-06, 2026年6月）は構成を形式化する：Settlement-Action Binding（binding_ref）がpayment_hashとaction_refを1つのレシートにバインドする——加えてPolicy Binding（policy_bound_ref）がgoverningポリシーバージョンをアクションにバインドし、Compliance Gate Binding（gate_ref）がALLOW/REFER/DENY判定をポリシー参照にバインドする。
すべての構成はSHA-256とJCS（RFC 8785）のみを使用し、レシートを保持するどの当事者も発行者に連絡せずに検証できる——MiCA第80条、DORA第14条、AMLR第56条の監査証跡要件を満たす（IETF draft-hopley-x402-retention-chain-06, 2026）。
実行証明のない決済は有料のブラックボックス；決済のない実行証明は検証不可能な主張；エージェントには信頼ループを閉じるために両方が必要——x402は交換を決済し、action_refは実行コンテキストをバインドし、binding_refがそれらを1つの監査可能なレシートに構成する。

問題：6つのプロトコル、ゼロの実行レシート

エージェント取引スタックは2026年に収束した：UCP（発見）、A2A（通信）、MCP（ツール）、ACP（チェックアウト）、AP2（認可）、x402（決済）。6層、60以上のローンチパートナー——Google、Shopify、OpenAI、Stripe、Visa、Coinbase。すべての購入はカバーされている：エージェントは発見し、交渉し、ツールを使い、チェックアウトし、認可を受け、支払う。

1つを除いて：エージェントが実際にすべきことを行ったという証明。

x402は支払いを決済する。payment_hashは取引がBase上で約200msで完了したことを証明する。x402レシート拡張（OMA3/x402コラボレーション経由でプロトコルに統合）は署名付きのポータブルな購入証明を追加する——誰が支払ったか、どのサービスにアクセスしたか、いつ、支払い参照。このレシートはサービスによってデジタル署名され、改ざん防止であり、普遍的に検証可能である。

サービス内部で何が起きたかを記録しない。レシートはエージェントが支払ったことを証明する。どのスクリーニングバージョンが実行されたか、どのポリシールールが発火したか、どのモデルバージョンが決定を生成したかは証明しない。ベンダーコンプライアンスチェックについて、レシートはエージェントがスクリーニングAPI呼び出しの代金を支払ったことを証明する。どのバージョンのスクリーニングロジックが実際に実行されたかは証明しない。

規制対象の調達——EU AI Act第12条、2026年8月2日施行、FCA SYSC 9.1、SOC 2 CC7.x——にとって、そのギャップはコンプライアンスのブロッカーである。ログは書き換え可能である。実行にバインドされない支払いレシートは有料のブラックボックスである。

解決策：決済と実行を構成する2つのIETFドラフト

action_ref — コンテンツアドレス実行識別子

IETF action_refドラフト（draft-etcheverry-action-ref-02, 2026年7月23日）はエージェントアクションの決定的なコンテンツアドレス識別子を定義する。識別子は以下として計算される：

action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp}))

JCSはJSON Canonicalization Scheme（RFC 8785）であり、任意のJSON値に対して一意のバイトシーケンスを生成する。4つの前像フィールド：

フィールド	捕捉する内容
`agent_id`	委譲解決後の末端実行者（A→B→Cチェーンでは、agent_idはC）
`action_type`	セマンティックラベル（`payment.send`, `compliance.screen`, `oracle.signal`）
`scope`	アクション時点のエージェントの要求インテントスコープ
`timestamp`	RFC 3339 UTC、正確に3ミリ秒桁

設計目標はオペレーター独立性：4つのフィールドを保持する検証者は、発行者のインフラを呼び出さずにaction_refを再計算できる。ドラフトにはポリシーローテーション監査可能性のためのオプションフィールドが含まれる——監査人はルール7が発火したことだけでなく、その瞬間にアクティブだったルール7のバージョンも特定できる。

x402-retention-chain — バインディング層

IETF x402-retention-chainドラフト（draft-hopley-x402-retention-chain-06, 2026年6月24日）は7つの暗号論的構成を定義する。3つが支払い → 決済 → 監査ループに直接関連する：

Settlement-Action Binding（binding_ref）——x402のpayment_hashをaction_refに1つのレシートでバインドする。決済証明は支払いが発生したことだけでなく、それがどの検証済みエージェントアクションに対応するかも証明するようになった。レシートを保持する監査人はpayment_hashからaction_refを経てアクション記録までチェーンをたどり、発行者に連絡せずに両方を確認する。
Policy Binding（policy_bound_ref）——governingポリシーのコンテンツアドレススナップショットをアクションにバインドする。スクリーニング決定は、それが行われた時に有効だった正確なポリシーバージョンに対して検証可能である。ポリシーローテーションは再計算によって検出可能——ポリシーが変更されるとハッシュが変わり、監査人は移行を見る。
Compliance Gate Binding（gate_ref）——ALLOW/REFER/DENYコンプライアンス判定とPIIなしの支払人参照をポリシー参照にバインドする。スクリーニング結果はそれを生成したルールバージョンに証明可能にバインドされ、バインドされた記録に個人データは含まれない。

すべての構成はSHA-256とJCSのみを使用する。外部インフラ不要。発行者への連絡不要。レシートを保持するどの当事者も検証できる。

監査ループ：支払い → 決済 → 監査可能ログ

規制対象のエージェント取引の完全なループ：

支払い——エージェントは有料API（ベンダーコンプライアンススクリーニング、サプライヤー検証、製品ルックアップ）を呼び出す。サーバーはHTTP 402と支払い条件を返す。
決済——エージェントは認可に署名し、PAYMENT-SIGNATUREで再試行し、ファシリテーターが検証してBase上で約200msで決済する。サーバーはpayment_hashを含む決済レシートと共にリソースを返す。
実行——エージェントはアクション（スクリーニング、ルックアップ、決定）を実行する。action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp}))を発行する——4つの前像フィールドからどの第三者も再計算できるコンテンツアドレス識別子。
バインディング——binding_refがpayment_hashとaction_refを1つのレシートにリンクする。policy_bound_refがgoverningポリシーバージョンをアクションにリンクする。gate_refがコンプライアンス判定をポリシー参照にリンクする。
監査——監査人（規制者、カウンターパーティー、内部コンプライアンス）は構成済みレシートを保持する。4つのフィールドからaction_refを再計算する。payment_hashをBaseブロックチェーンに対して検証する。policy_bound_refをチェックしてスクリーニングが正しいポリシーバージョン下で実行されたことを確認する。gate_refをチェックして判定が一致することを確認する。オペレーターへの呼び出しなし。信頼不要。

ループは答える：支払い決済済み、この特定のスクリーニングバージョンが実行された、このポリシーバージョン下で、このタイムスタンプで、この判定と共に。2層、1つのレシート。

なぜ各層単独では不十分か

下の図は完全なループ——支払い、決済、実行、バインディング、監査——と各層単独でなぜ不十分かを示す：

実行証明のない決済は有料のブラックボックスである。レシートはエージェントがコンプライアンススクリーニングの代金を支払ったと言う。どのバージョンのスクリーニングロジックが実行されたか、ポリシーが最新か、判定が正しかったかは言わない。規制者が「このベンダーを2026年7月の制裁リストでスクリーニングしたか、6月のリストか？」と尋ねても、payment_hash単独では答えがない。

決済のない実行証明は検証不可能な主張である。エージェントはベンダーをスクリーニングしたと言う。スクリーニングを決済済み取引にバインドする支払いレシートがなければ、スクリーニングが実際に発生した経済的証拠がない。主張は無料ででき、監査には価値がない。

組み合わせが信頼ループを閉じる。決済は経済的イベントをアンカーする——資金が移動した証明。実行証明はセマンティックイベントをアンカーする——何がされたかの証明。バインディングがそれらをリンクする。監査人は1つのレシートから両方を検証し、チェーンのどの当事者も信頼せずにハッシュを再計算する。

B2Bビルドにおける意味

注文を出し、支払いを認可し、ベンダーをスクリーニングする調達エージェントは、その監査証跡に完全なループを必要とする。アーキテクチャ：

x402は決済を処理する。エージェントはベンダーコンプライアンスAPIから402レスポンスを受け取り、Base上でUSDCで支払い、payment_hashを含む決済レシートを受領する。
action_refは実行識別子を処理する。エージェントは各コンプライアンススクリーニングアクションに対してaction_refを発行し、agent_id、action_type（compliance.screen）、scope（ベンダーIDとスクリーニングタイプ）、timestampを記録する。
binding_refがそれらを構成する。決済レシートは1つのエンベロープでpayment_hashとaction_refを運ぶ。policy_bound_refはどのポリシーバージョンがスクリーニングをガバンしたかを記録する。gate_refはALLOW/DENY判定を記録する。
監査証跡は構成済みレシートチェーンである。監査人は4つのフィールドからaction_refを再計算し、payment_hashをオンチェーンで検証し、ポリシーバージョンハッシュをチェックし、判定を確認する——すべてエージェントオペレーター、支払いファシリテーター、スクリーニングサービスへの連絡不要。

規制業界——製薬GMPコンプライアンス、航空宇宙ITARスクリーニング、金融サービス制裁チェック——にとって、これは監査可能なエージェントとコンプライアンスリabilityエージェントの違いである。EU AI Act第12条記録保持要件（2026年8月2日施行）はAIシステム決定のトレーサビリティを要求する。MiCA第80条は取引記録を要求する。DORA第14条は運用レジリエンスの監査証跡を要求する。binding_ref構成は1つのレシートから3つすべてを満たす。