エージェント経済と相互運用プロトコル

エージェントにカード情報の生データを渡す代わりに、暗号署名された検証可能クレデンシャル（verifiable credential）形式のマンデートの連鎖を通じて、エージェントが開始する購入を承認する。Intent Mandate はユーザーが事前に定めた制約（上限価格、許可された販売者、有効期限）を捕捉し、ユーザー不在時でもエージェントが購入できるようにする。Cart Mandate は販売者が署名しユーザーが連署するもので、正確な商品と価格を対象とし、「見えているものがそのまま支払額になる（what-you-see-is-what-you-pay）」ことを保証する。そして Payment Mandate は決済ネットワークと共有される。署名された連鎖は否認不可能な監査証跡を形成し、自律的な支出に関する承認・真正性・説明責任を解決する。また決済レールに依存せず、暗号資産レール向けの A2A-x402 プロファイルを備える。authenticated-delegation とは異なる。あのパターンはエージェントに行動するための限定された権限を付与するのに対し、AP2 は個々の具体的な購入を、決済ネットワークが独立して検証できる署名済みマンデート連鎖に結び付ける。

Stripe と OpenAI が共同開発したオープン標準（Apache-2.0、2025年9月）で、販売者（merchant of record であり続ける）に対して購入を完了させるためのもの。販売者は商品フィードの上に、エージェント向けの REST または MCP エンドポイント（チェックアウトの作成・更新・完了・キャンセル）を公開する。エージェントは、単一の販売者とカート合計額に限定された Stripe 発行の Shared Payment Token で支払うため、購入者のカード認証情報を一切目にすることはない。これは Etsy の出品者や Shopify の販売者とともに提供される ChatGPT Instant Checkout を支える標準として登場した。`model-context-protocol` とは異なる。MCP が汎用的なツール呼び出しのトランスポートであるのに対し、ACP は MCP あるいは素の REST の上で動作しうる、特定のチェックアウト契約である。

2025年に Coinbase が策定し、現在は Linux Foundation 傘下の x402 Foundation が運営するオープンな決済標準で、これまで休眠状態だった HTTP 402 Payment Required ステータスを、リクエスト単位課金のレールとして復活させたもの。サーバーは機械可読な支払い要件とともに 402 を返し、クライアント（人間またはエージェント）は署名済みのステーブルコイン支払いを HTTP ヘッダーで返送する。ファシリテーターがペイロードを検証し、その送金をオンチェーン（EVM チェーン、Solana ほか）で決済する。これらはすべて単一のリクエスト内で完結し、アカウント・セッション・API キーを必要としない。鍵不要でサブセント単位のエージェント対サービスのマイクロペイメントや、従量課金のツール・データアクセスのためのネイティブなレールであり、AP2 の A2A-x402 拡張が参照する暗号資産プロファイルでもある。`agentic-commerce-protocol` とは異なる。ACP が merchant of record を介したカードベースの小売チェックアウトであるのに対し、x402 は呼び出しごとにオンチェーンで決済される機械向けの支払いである。

ハードコードされた設定ではなく、実行時にエージェントとツールサーバーが互いを見つけられるようにする発見（discovery）レイヤー。これを実現するのは、収束しつつある3つの仕組みである。まず A2A Agent Cards は、/.well-known/agent-card.json（RFC 8615）で提供される自己記述型の JSON マニフェストで、エージェントのスキル、エンドポイント、認証方式、ストリーミング機能を公表する。次に公式の MCP Registry（2025年9月プレビュー）は、MCP サーバーを公開・検索するためのフェデレーション型の公開カタログと API であり、企業のプライベートなサブレジストリで拡張できる。そして MIT Project NANDA のような分散型ネーミングの提案があり、その NANDA Index は暗号的に検証可能な AgentFacts レコードをエンドポイントへ解決し、エージェントのための DNS と位置づけられている。共通のパターンは、署名済みのケイパビリティレコードを公開し、それを well-known URI またはレジストリ照会によって解決し、公表された認証方式を検証したうえで、エージェントを動的にバインドすることである。`a2a-protocol` とは異なる。あちらはピアが判明した後のメッセージトランスポートを扱うのに対し、こちらはそもそもそのピアを見つけて精査することを扱う。

レンダリング済みの HTML をスクレイピングさせる代わりに、サイトのコンテンツをエージェントへ直接公開する供給側の取り決め。llms.txt（Jeremy Howard、2024年）は /llms.txt に置かれるキュレーションされた Markdown 索引と、.md のシャドウページから成り、推論時に LLM へ高密度でナビゲーション不要のコンテンツを提供する。Microsoft NLWeb（2025年、Schema.org 共同開発者の R.V. Guha が主導）はさらに踏み込み、自然言語の /ask エンドポイントを備え、サイト自身の Schema.org データに基づいた構造化 JSON を返す。しかも NLWeb の各インスタンスは MCP サーバーも兼ねる。両者はあいまって、エージェント可読なサイト、すなわちエージェント型ウェブにおける robots.txt の読み取り経路版を定義する。

台頭しつつある IETF ドラフト標準（Cloudflare と Google）で、RFC 9421 の HTTP Message Signatures を用いて、エージェントがウェブサイトに対して自らの身元を暗号的に証明できるようにする。エージェントは各送信リクエストを Ed25519 鍵で署名し、公開鍵を /.well-known/http-message-signatures-directory に JWKS 鍵ディレクトリとして公開し、Signature-Agent ヘッダーでそれを指し示す。オリジンはそのディレクトリを取得して署名を検証し、当該トラフィックを許可・拒否・レート制限・課金のいずれにするかを判断する。これは壊れやすい IP レンジや User-Agent の許可リストを置き換えるものであり、Cloudflare の Signed Agents はこれをエッジで製品化している。authenticated-delegation とは異なる。あちらはユーザーからエージェントへの権限を証明するのに対し、Web Bot Auth はその逆で、エージェントがウェブサイトに対して自らの出所を証明する。

中央のゲートキーパーを介さずに、エージェントが見知らぬエージェントに対するカウンターパーティリスクをどう値付けするかに関する、大半がドラフト段階の新興標準。ドラフトの EIP である ERC-8004「Trustless Agents」は、3つのオンチェーンレジストリを定義する。すなわち Identity（オフチェーンのエージェントメタデータへ解決される ERC-721 ハンドル）、Reputation（署名済みのフィードバックシグナル）、そして Validation（ステークで担保された再実行や TEE オラクルといったバリデーターコントラクトによる証明）であり、支払いとアプリケーションロジックは意図的にオフチェーンに保たれる。付随する信頼モデルの分類法は、メカニズムを brief・claim・proof・stake・reputation・constraint の6カテゴリに分類し、単一のメカニズムでは不十分で、階層的な組み合わせが必要だと論じる。これは黎明期にあり、まだ定まっていない。ERC-8004 はドラフトの EIP であり、ツール群の多くも萌芽段階にある。authenticated-delegation とは異なる。あちらは委任された権限と識別に関わるのに対し、こちらは経済的なピア間で値付けされるレピュテーションに基づく信頼である。