エージェンティックWeb実装ガイド　第5回：取引を任せる ― 委任と決済、エージェントが財布を持つ時代のプロトコル

第4回で、サイトの操作をエージェントに開いた。ツールとして公開するのは「意図の範囲だけ」 ―― それが操作の層の結論だった。

この回は、その一段上に登る。操作の次は取引だ。エージェントが問い合わせ、操作するだけでなく、約定し、支払う。

主語も変わる。第2回から第4回まで、主語は一貫して「あなたのサイト」だった。構造化データを書くのもツールを公開するのも、サイト側の仕事だ。取引の層では、主語がエージェント同士の関係に移る。あなたのエージェントと相手のエージェントが会話し、片方がもう片方に支払う。サイトは舞台の一つになり、プロトコルが主役になる。

前回の末尾で「名前の紛らわしい二つのプロトコル」と予告した。本題に入る前に、まずその紛らわしさから片付ける。そして、この回を貫く一文を先に置いておく ―― 意図より広い委任は、そのまま事故になる。第4回の「意図より広い露出は、そのまま脆弱性になる」と対になる原則だ。露出のズレは操作の事故を生み、委任のズレは金の事故を生む。

一枚の地図 ― 4つのプロトコルはどこで働くか

取引の層に登場するプロトコルは、A2A、AP2、ACP、UCPの4つ。名前が似ていて役割が違うので、先に一枚の地図に置く。

下から読む。A2Aはエージェント同士の通信 ―― 発見し、依頼し、進捗を受け取る共通言語。AP2はその上に載る決済の委任 ―― 「誰が、何を、どこまで許したか」を暗号署名付きで運ぶ。ACPとUCPは商流の面 ―― 商品の発見からカート、注文、購入後の対応まで、商取引の全体を覆う標準で、いま2つの系統が再編の途上にある。

そして予告した紛らわしさの正体がこれだ。「ACP」という略称のプロトコルは二つあった。本稿で扱うACPはAgentic Commerce Protocol ―― OpenAIとStripeが作った商取引の標準だ。もう一つのACP、IBM発のAgent Communication Protocol（エージェント間通信）は、2025年8月にA2Aへ統合され、独立したプロトコルとしては存在しない。つまり通信の座はA2Aに一本化されており、いま「ACP」と言えば商取引のほうを指す。本稿でも以降、ACPは決済・商取引のAgentic Commerce Protocolだけを意味する。

地図は引けた。あとは一段ずつ登るだけだ。

A2A ― エージェント同士が任せ合う

何を解くプロトコルか

MCPとWebMCP（第4回）は、エージェントが道具を使うためのプロトコルだった。A2Aは、エージェントが相手に頼むためのプロトコルだ。agent-to-toolとagent-to-agent ―― この一対で覚えるのが早い。

自社の購買エージェントが、取引先の受注エージェントに見積を依頼する。相手がどのフレームワークで作られていても、A2Aという共通言語があれば会話が成立する。依頼はTask（作業単位）として渡り、進捗が流れ、成果物（Artifact）が返ってくる。詳しい仕組みと業種別のシナリオはA2A連載（全5回）で書いた。

サイト側の接点はAgent Cardだ。/.well-known/agent-card.json に、自分のエージェントが何をできるか（スキル・入出力・認証）を記した名刺を置く。第2回のllms.txtがサイトの地図なら、Agent Cardはエージェント窓口の名刺 ―― どちらも「機械に読ませる自己記述」という同じ系譜にある。

2026年7月の現在地 ― v1.0 stableという節目

A2Aは2025年4月にGoogleが発表し、同年6月にLinux Foundationへ移管された。そして2026年4月の1周年発表で、150超の組織が支持し、主要クラウドでの本番運用が始まったことが公表された。AWS、Cisco、Google、IBM、Microsoft、Salesforce、SAP、ServiceNowが技術運営委員会に並び、SDKは5言語。Microsoft Copilot Studio、Azure AI Foundry、Amazon Bedrock AgentCoreが対応している。

技術面の節目はv1.0 stableだ。目玉はSigned Agent Cards ―― Agent Cardに暗号署名を付け、「この名刺は本当にそのドメインの持ち主が発行したか」を検証できるようにした。署名のない世界では、偽の名刺を立てて他のエージェントを誘い込む攻撃が成立してしまう。分散したエージェントが互いを発見して信頼する、その土台がv1.0で整った。ほかにマルチテナンシー、JSON-RPCとgRPCの複数バインディング、v0.3からの後方互換を保証するバージョンネゴシエーションが入った（仕様、GitHub）。

通信の層は、4つの中でいちばん足場が固い。

AP2 ― 決済を委任する

なぜ決済だけ特別扱いか

第4回で扱った操作の多くは、失敗しても取り消せる。カートに入れ間違えたら消せばいい。決済は違う。金が動いた後の巻き戻しは、返金・チャージバック・紛争解決という重い手続きになる。だから決済には、操作より一段厳格な仕組みが要る ―― 事前に、何を許したかを、否認できない形で残す仕組みだ。

既存の決済インフラは「人間が信頼できる画面で自分でボタンを押す」前提で組まれている。エージェントが代わりに押す瞬間、この前提が崩れる。ユーザーは本当にこの購入を許可したのか。エージェントの解釈ミスや暴走ではないのか。事故ったら誰の責任か。AP2（Agent Payments Protocol）は、この三つの問い ―― 認可・真正性・説明責任 ―― に答えるためにGoogleが2025年9月16日、PayPal・Mastercard・American Express・Adyen・Coinbaseなど60超のパートナーと発表したオープンプロトコルで、A2Aの公式拡張として設計されている。

委任状の構造 ― 3つのマンデート

AP2の中核はマンデート（mandate）、直訳すれば委任状だ。W3C Verifiable Credentials ―― 改竄すれば検知できる、暗号署名済みのデジタル文書 ―― として実装され、3種類が役割を分け合う。

Intent Mandate（意図の委任状） ―― 「この条件ならエージェントが買ってよい」という事前の委任。対象、上限額、期限などの制約を記す。人間がその場にいない自律実行（Human Not Present）の根拠になる
Cart Mandate（カートの委任状） ―― 「この商品を、この価格で買う」という確定したカートへの最終承認。人間がその場で署名する（Human Present）
Payment Mandate（決済の委任状） ―― 決済ネットワークと発行体に渡り、「この取引にはAIエージェントが関与している。人間は在席か不在か」を伝える

この設計の要点は、Human Present / Human Not Present を最初から区別していることだ。人がその場で承認する取引と、事前の委任状だけで走る自律取引は、リスクの質が違う。AP2はその違いを曖昧にせず、マンデートの種類と決済網への通知で明示する。以前「合鍵を渡すな、委任状を書け」と書いた。AP2はその委任状が、比喩ではなく暗号署名付きの文書として実装された姿だ。決済スタック全体の構造はAIエージェントに財布を渡せますか（全3回）で掘っている。

委任のズレが事故になる

委任状の書式が決まっても、何を書き込むかは設計者の仕事として残る。そしてここに、この回の核心がある。

マンデートは署名されている。つまり、そこに書かれた範囲内の取引はすべて「本人が許可した正規の取引」として扱われる。上限を書き忘れた委任状は、無制限の購入を正規化する。期限のない委任状は、半年後の想定外の自律購入を正規化する。第4回では、意図より広いツール露出がそのまま脆弱性だと書いた。取引の層では、意図より広い委任がそのまま事故だ。署名の強さは、書いた内容の正しさを保証しない ―― むしろ書き間違いを強力に固定する。

2026年7月の現在地 ― FIDOへの寄贈という転回

実運用は先に始まっている。PayPalのConversational Commerce Agent（2025年10月）、MastercardのAgent Payパイロット、そしてステーブルコイン決済のx402拡張 ―― この最後の系譜はステーブルコインとエージェント決済で書いた通り、機械同士の少額高頻度決済に向かう。

節目は2026年4月28日に来た。GoogleはAP2をFIDO Allianceに寄贈した。パスキーを標準化した、あの団体だ。同日公開のv0.2.0はHuman Not Presentの扱いを強化し、Mastercardと共同開発した改竄不能な承認記録の標準「Verifiable Intent」も併せて寄贈された（FIDO側の発表）。標準化の場がGoogle一社の手を離れ、認証業界の中立団体のワーキンググループに移った。プロトコルが「Googleの仕様」から「業界の標準候補」へ格上げされたと読んでいい。5月19日のGoogle I/Oでは、小売業者を横断するUniversal Cartを支える決済基盤として据えられた。

限界も明記しておく。AP2のマンデートはユーザーの署名鍵に紐づくのであって、エージェント自体の身元は範囲外だ ―― エージェントの認証はVisaのTrusted Agent Protocolのような別の層が補完する構図になっている。発行済みマンデートの失効の扱いはまだ薄く、カードネットワークの本番規模での実証もこれからだ。委任状の書式は固まりつつあるが、運用の作法はまだ書かれている途中にある。

ACP / UCP ― 商流の面はどちらへ

ACP ― ChatGPTから始まった商取引標準

ACP（Agentic Commerce Protocol）はOpenAIとStripeが2025年9月29日に発表した。同時に始まったのがChatGPTのInstant Checkout ―― 会話の中で商品を見つけ、そのまま買える体験だ。米国のEtsyセラーから始まり、Shopifyの100万超のマーチャントへ、12月にはInstacartへと広がった。OpenAI側の発表によれば、マーチャントは自社の決済処理を替えずに参加でき（Shared Payment Token / Delegated Payments Spec）、完了取引に対してOpenAIに手数料を払う。

プロトコルとしてのACPは商品フィード、カート、チェックアウト、注文管理までを覆うオープン標準で、Apache 2.0でGitHub公開され、日付ベースで版が刻まれている。最新の2026-04-17版ではカート・フィード・注文・認証に加えてMCP対応が入った。興味深いのは作成者の変化で、Stripeのドキュメントは現在、ACPを「Stripe、OpenAI、そしてMetaが作った標準」と記している。

ただし2026年3月、OpenAIはInstant Checkoutの初版から方向転換した。会話内で完結するチェックアウトを一律に押すのではなく、商品発見＋マーチャント側が制御するチェックアウトへ ―― ベンダーの受け入れ体制や商品情報の精度という、商取引の泥臭い複雑さが理由とされる。プロトコルは生きているが、体験の形は作り直しの途上だ。

UCP ― 1月のローンチ、4月の地殻変動

UCP（Universal Commerce Protocol）はGoogleが2026年1月11日、全米小売業協会（NRF）の年次イベントで発表した。Shopify・Etsy・Wayfair・Target・Walmartとの共同開発で、Adyen、American Express、Best Buy、Mastercard、Stripe、Visa、The Home Depot、Zalandoなど20超がエンドースに並んだ。発見から購入後対応までの商流全体を、AIエージェントが扱える共通の抽象に畳む ―― 狙いはACPと同じ面にある。

地殻変動は4月24日に起きた。Amazon、Meta、Microsoft、Salesforce、StripeがUCPのTech Councilに合流し、ガバナンスは10社体制になった。ここには注意深い読みが要る。「UCPが勝った」と書きたくなるが、事実はもう少し込み入っている。StripeはACPの共同維持者のままUCPのTech Councilに座った。MetaはACPの作成者に名を連ねながらUCPにも加わった。OpenAIはACPを維持し続けている。AmazonはTech Councilには座ったが、自社マーケットプレイスを外部エージェントに開いてはいない ―― Rufus、Alexa+、Buy for Meという独自路線は続いている。

動いたのは勝敗ではなく、ガバナンスの重心だ。商流の面の標準を「どこで議論するか」が、UCPのテーブルに集まった。そしてUCPは決済委任の証跡を自前で発明せず、AP2のマンデート拡張をそのまま採用して互換を取った ―― Linux FoundationのA2A一周年発表が明記している通りだ。商流の面がどちらの系統に転んでも、委任の証跡はAP2に載る。地図の中層が安定しているから、上層の再編を落ち着いて眺めていられる。

2月に書いたACPとUCPの比較の時点では、2系統の並走だった。5か月でここまで動いた。この層の変化速度は、そういうものだと思って読んでほしい。I/O 2026ではUCPチェックアウトのカナダ・オーストラリア展開と英国の予定、そしてSearch・Gemini・YouTube・Gmailを横断するUniversal Cartが発表されている。UCPの初報はこちらでも書いた。

Do ― いま、何をするか

取引の層は「理解と準備のフェーズ」だと最初に言い切っておく。ただし一括りにはできない。層ごとに、動く時期が違う。

A2A / Agent Card ―― 低コストの実験は始めてよい。 /.well-known/agent-card.json の設置自体は軽い。B2Bで問い合わせ・見積・発注のやり取りが多い業種なら、自社の窓口をエージェント可読にしておく意味は先行して立つ。ただし「置けば客が来る」段階ではまだない ―― 相手側のエージェントが探しに来る母数が育っていないからだ。v1.0で署名付きカードという信頼の土台が入った今が、素振りを始める適期だと私は見ている。

AP2 ―― 実装するのは決済側、設計を理解するのは事業側。 マンデートの発行・検証を自前で組む事業者はまれで、実装はウォレット・決済事業者・エージェントプラットフォームが担ぐ。事業者の仕事は、自社の取引が委任される時にどの条件なら受けるかを設計として言語化しておくことだ。上限、期限、対象、Human Presentを必須にする取引の線引き ―― これは次のCheckにそのまま繋がる。

ACP / UCP ―― EC事業者は準備を始める段階。 商流の面は再編中だが、どちらの系統でも要求されるものは共通している。機械が読める正確な商品フィード、在庫と価格の鮮度、そしてチェックアウトのAPI化だ。フィードの正確さは、突き詰めれば第2回で書いた「意味の層」の延長にある ―― 構造化データを誠実に整備してきたサイトは、ここで先行できる。梯子は積み上がる。具体的な段取りはEC事業者の実践ロードマップに書いた。

そして層をまたぐ原則として、委任状設計の4点を置いておく。

範囲 ―― 何の取引を委ねるのかを列挙で書く。「その他」を作らない
条件 ―― 上限額・期限・決済手段を必ず書く。書かない項目は「無制限」と同義になる
確認 ―― どの取引で人間の承認（Human Present）を必須にするかを先に決める。高額、不可逆、初回の相手 ―― 線は事業ごとに違うが、線がないのは設計ではない
記録 ―― 誰が何を委任し、エージェントが何を約定したかを、後から監査できる形で残す

Check ― 確かめること（観点）

Do（実装する）の裏面がCheck（確かめる）だ。取引の層で確かめる観点は3つ。例によって、観点までを示す ―― 合否の閾値や判定手順はここには書かない。

委任範囲の意図適合。 発行しているマンデート・委任設定の集合は、事業として意図した取引の集合と一致しているか。意図より広い委任 ―― 上限のない金額、期限のない有効期間、限定のない対象 ―― が紛れ込んでいないか。なぜ要るか：署名済みの委任状は、その範囲内のすべてを「正規の取引」にしてしまうからだ。事故は不正アクセスの顔をしてこない。正しい手続きの顔をしてやってくる。

約定・決済条件の限定。 実際に走った取引は、委任状に書いた条件の内側に収まっているか。決済手段・金額・相手は、意図した組み合わせに限定されているか。なぜ要るか：委任状が正しくても、それを解釈して動く実装の側がずれることがある。書いた条件と走った取引の突き合わせは、書式の検証とは別の仕事だ。

Human-in-the-loopの確認境界。 人間の承認を必須にすると決めた取引で、確認が実際に入っているか。Human Not Presentで走らせる範囲は、意図して選んだ範囲か ―― 「設定していないから自律で走っている」になっていないか。なぜ要るか：HNPは便利さの核心であると同時に、事故の主経路でもある。確認境界の設計論はHITL設計の現在地で掘った。

一つ付け加えると、マンデートの署名検証やスキーマの妥当性チェックは機械の仕事で、プロトコル側のツールが担っていく領域だ。人間が判断すべきなのはその一段上 ―― この委任条件は、うちの事業の意図と一致しているか。第4回と同じ構図が、ここでも繰り返される。

まとめ ― 委任状は書いて終わりではない

取引の層を一枚にまとめる。通信はA2Aに一本化され、v1.0で足場が固まった。決済の委任はAP2がマンデートという形を与え、FIDOへの寄贈で業界標準への道に乗った。商流の面はACPとUCPが再編の途上にあり、ガバナンスの重心はUCPのテーブルに動いたが、委任の証跡はどちらに転んでもAP2に載る。

そして原則は一つ ―― 意図より広い委任は、そのまま事故になる。委任状の書式はプロトコルが決めてくれた。何を書き込むかは、あなたの設計だ。しかもこの層は5か月で地図が描き換わる速度で動いている。書いた委任状を放置しないこと。プロトコルの再編を観察し続けること。それ自体が、この層の運用だ。

次回は梯子を登り切った先ではなく、全部の段を貫く柱を見る。AIが何を根拠に答えるか（RAG）と、権限をどう絞るか ―― どの層にも効く二つの横断課題、そして第3回で予告したエージェント向けディスカバリーの新しい動きを扱う。

参考情報

この記事をシェアする

X (Twitter) LinkedIn Facebook Bluesky Threads

一枚の地図 ― 4つのプロトコルはどこで働くか