エージェンティックコマースがついに日本へ——MUFG×Googleが示す実装フェーズの現実

こんにちは、仕様書を書かないPM@カイです。

toA連載で何度か「来る来る」と書いてきた地殻変動が、ついに日本で起きました。

2026年5月7日。

MUFGとGoogle Cloudがリテール領域で戦略的提携を発表した日付を、私はしばらく覚えていると思います。

1年前からtoAを追いながら「日本に来るのはいつか」と自問してきた問いの答えが、この日に出たからです。

単なる金融×AIの提携じゃありません。

日本最大規模の金融グループが、AP2・UCP・A2Aという3プロトコルを同時採用すると明言した——それはエージェンティックコマースの「概念検証フェーズ」が「実装フェーズ」に切り替わった宣言です。

「PMの皆さんに正直に話すと、最初は『また新しいプロトコルか』と思ったんですよね」——でも資料を読み込んでいくと、これは違う。

この記事では、toA連載で確立してきた「discovery→authorization→payment」の3層フレームに、今回のMUFG×Googleが採用した3プロトコルを当てはめて読み解きます。

読み終えたら、あなたのプロダクトが「エージェンティックコマース対応」かどうか、月曜朝から動ける形でわかるようにしてあります。

MUFG と Google のリテール領域における戦略的提携について | Google Cloud 公式ブログ

cloud.google.com

MUFGが動いた——エージェンティックコマース、日本の実装フェーズ開始

エージェンティックコマースという言葉は、2025年からじわじわと業界内で使われるようになりました。

AIエージェントが商品を探し、決済まで自律的に支援する——そういう購買体験の総称です。

ただ、ここまでは「アメリカでは動いてるけど、日本はまだ先」という温度感だったんですよ。

それが今回の発表で、一気に変わりました。

2026年5月7日の発表で何が変わるのか

提携の中身を整理するとこうなります。

• MUFGとGoogle Cloudが「リテール領域」で戦略的提携
• Agentic Commerce / Agentic Paymentsを軸にした次世代決済インフラをGoogle Cloud上に構築
• 採用プロトコルはAP2、UCP、A2Aの3セット
• 2026年度中にPoC（概念実証）を実施・完了し、2027年度に正式サービス開始
• 周辺サービスとしてYouTube Premium 3ヶ月無料、Google Fitbit、Moneytreeアプリ連携も含む

AIに「これ買っておいて」で決済から家計簿記録まで完結　MUFGがGoogleとの提携で目指す自律型金融サービス

MUFGはGoogleと提携し、AIエージェント時代の購買、決済を担う次世代基盤の構築を目指す。AIエージェントが商品選択から購買、決済、家計データの可視化まで実行するサービスの開発を予定している。

www.itmedia.co.jp

注目してほしいのは、採用プロトコルの組み合わせです。

「AP2を採用しました」「UCPを採用しました」という単発の発表ならこれまでもあった。

でも、AP2+UCP+A2Aの3つを同時に採用すると明言した日本の金融機関は、私の知る限り今回が初めてです。

PM視点で読むと、これは「ある程度の実装パスが見えてきた」という宣言なんですよね。

プロトコルを1つだけ試すなら「とりあえず触ってみる」段階。

3つを組み合わせるとなると、ユースケース全体を設計しに行ってる証拠です。

「粉ミルク撮影→AI決済完結」が示すエージェンティックコマースの世界観

具体的なユースケースとして発表で示されたのが、これです。

1. ユーザーが粉ミルクの缶をスマホで撮影
2. AIエージェントが画像検索で同一商品を特定
3. 複数の販売チャネルから最安値を発見
4. ポイント還元やクーポンを加味した最適な決済方法を提案
5. ユーザーの承認のもと、AI支援で決済を完結

ちょっと想像してみてください。

子育て中の深夜、粉ミルクが残り少ないことに気づく。

スマホで缶を撮影するだけで、AIが最安値を探して、ポイントを計算して、「これで買いますか?」と聞いてくる。

「はい」と答えるだけで、決済まで完結する。

このフローを連載読者の皆さんと一緒に分解してみましょう。

商品を「撮影」して「特定」する——これがdiscovery層。

「最安値を発見」して「最適決済を選定」する——これがauthorization層の前段（条件評価）。

最後に「承認のもと決済完結」——これがauthorization+payment層です。

つまり、MUFGのデモは私がtoA連載で「3層プロトコルが必要だ」と書いてきた構造そのままなんですよ。

過去のtoA連載で「Cloudflare+Stripeでエージェントが顧客になった」という記事を書いたことがあります。

あの時点では海外の話でした。

でも今回のMUFG発表で、日本の銀行口座を持つ一般ユーザーが、AIに「粉ミルクの最安値で買って」と頼むだけで決済まで完結する未来が、PoCとして実際に動き始める。

PMの実務に翻訳するとこうなります。「あなたのプロダクトの商品データ、AIエージェントが取得できる形で公開されていますか?」

次のセクションが、いよいよ本題です。

3つのプロトコルを整理する——AP2・UCP・A2Aは何を解決するか

ここでカイのフレームを使います。いよいよこれが効いてくるパートです。

toA連載で繰り返し書いてきた「discovery→authorization→payment」の3層プロトコル。

AIエージェントがユーザーの代わりに買い物をする時、必要になる機能を3つに分解したフレームワークです。

MUFGが採用した3プロトコルは、このフレームに綺麗に対応してるんですよね。

A2A（Agent2Agent Protocol）はこの3層をつなぐ通信プロトコルとして機能します。

MCP（LLMとツール）の1階層上で、エージェント同士が会話するためのレイヤーですね。

それぞれ見ていきましょう。

discovery層 - UCP（AIエージェントが店舗を見つける仕組み）

UCPはGoogleとShopifyが2026年1月に発表したプロトコルです。

共同開発者としてEtsy、Wayfair、Target、Walmart、推進パートナーとしてMastercard、Stripe、Visa、Best Buy、Home Depot、Macy'sなど、小売の主要プレイヤーがほぼ揃ってる。

Universal Commerce Protocol - Shopify

An open standard for integrating commerce with agents. Commerce is complex—UCP provides the core capabilities for what’s common and extensions for everything else.

www.shopify.com

核心の設計はシンプルで、マーチャント側が.well-known/ucpというエンドポイントにJSON形式のプロファイルをホストするだけ。

AIエージェントは登録なしでそのエンドポイントにアクセスして、店舗の商品カタログ、API仕様、決済オプションを取得できます。

「.well-known/」って見覚えありませんか?

robots.txtやsitemap.xmlと同じ系譜の、Web標準の発見メカニズムです。

これが選ばれた意味は大きい。

中央集権的なディレクトリサービスじゃなくて、店舗側が自律的にAIエージェントへ自己紹介するという設計思想なんですよね。

PM実務に落とすと、discovery層の対応は次の3点になります。

• 自社の商品カタログをマシンリーダブル（JSON-LDなど）にする
• .well-known/ucpエンドポイントを準備する
• API/A2A/MCPの3経路のうち、最低1つで商取引を完結できる状態にする

UCPの面白いところは、API・A2A・MCPの3つの統合経路すべてに対応してることです。

「うちはAPI整備が進んでないけど、MCPサーバーは作れる」という会社でも、入り口を作れる。

これ、設計思想として優秀です。

authorization層 - AP2 Mandate（暗号委任状とは何か）

次がAP2（Agent Payments Protocol）。

Googleが2025年9月に発表したプロトコルで、PayPal、Mastercard、American Express、JCB、UnionPay、Adyen、Worldpay、Revolut、Coinbase、Salesforce、ServiceNowなど60社以上が共同推進しています。

新しい Agent Payments Protocol（AP2）で AI コマースを強化 | Google Cloud 公式ブログ

Agent2Agent（A2A）を基盤とするオープン プロトコル、Agent Payments Protocol（AP2）について詳しく説明します。AP2 は、Google が大手決済企業やテクノロジー企業と共同で開発したもので、エージェント主導の決済をプラットフォーム間で安全に開始、実行できます。

cloud.google.com

AP2の核心はMandateという概念です。

日本語で訳すと「暗号署名されたデジタル委任状」。

PM視点で言うと、これが超重要なんですよ。

AIエージェントがユーザーに代わって決済をする時、店舗側からすると「このエージェント、本当にユーザーから委任を受けてるの?」が最大の不安なわけです。

なりすましだったら銀行リスク、過剰購入だったらユーザークレーム、不正利用だったら警察沙汰。

Mandateはこの不安を、暗号署名+Verifiable Credentials（VC）で解決します。

• ユーザーがAIエージェントに「3000円までの粉ミルクを買って良い」と委任
• ユーザーの秘密鍵で署名されたMandateが発行される
• AIエージェントはこのMandateを持って店舗にアクセス
• 店舗は署名を検証して「本物の委任である」ことを確認
• 委任範囲（金額・商品カテゴリ・有効期限）の中でのみ決済が成立

この仕組みのうまさは、リアルタイム購入（人間が介在）と委任購入（人間不在の自律決済）の両方に同じプロトコルで対応できることです。

リアルタイム購入は「Aさん、この商品でよろしいですか?」とユーザーに最終確認するパターン。

委任購入は「事前に決めた条件に合致したら勝手に買っていい」というパターン。

後者が将来的に主流になるはずで、その時にMandateが「どこまで委任したか」の証拠として機能します。

失敗談を共有すると、私が前にtoA連載で書いた「Cloudflare+Stripeでエージェントが顧客になった」という記事の時点では、authorization層の標準プロトコルがまだ固まってなかった。

各社が独自の認証スキームを作っていて、PMとしては「結局どれに賭けたらいいの?」状態だったんです。

それがAP2 Mandateという形でWeb標準級の合意が形成されてきた。

これは大きな前進です。

payment層 - AP2のAIエージェント決済実行とStripe/PayPal連携

3層目がpayment、つまり実際の決済処理。

ここが意外と誤解されやすいんですけど、AP2はクレジットカードのオーソリやネットバンキングの送金処理を直接やるプロトコルではないんですよ。

AP2は信頼レイヤー、つまり「この決済は本物の委任に基づいている」という証明を運ぶプロトコルです。

実際の決済処理は、Stripe、PayPal、各銀行、各カードブランドの既存インフラが担当します。

AP2はその上に「委任の証明書」を載せて運ぶ、という関係性です。

2026年4月時点の実装例として、PayPal×Google Cloudの会話型コマースエージェント、Mastercard Agent Pay×PayPal連携などが既に動いています。

MUFGの場合は、自社の決済インフラ（口座振替・カード決済）にAP2の信頼レイヤーを載せていく形になるはずです。

PM実務として理解しておくべきポイントはこれです。「自社の既存決済インフラを置き換えるプロトコルではなく、その上に乗せる信頼レイヤー」という位置づけ。

だから既存のStripe連携やカードブランド連携をスクラップする必要はない。

むしろAP2に対応することで、AIエージェント経由のトラフィックが追加される、という発想が正解です。

ここまでで3層プロトコルの整理が終わりました。

次は実務で必ず聞かれる質問——「AP2とACPって結局どっちなの?」に答えていきます。

AP2とACPは競合するのか——PMが知るべきプロトコル選定の基準

ここからが現役PMにとって一番モヤモヤするゾーンです。

結論を先に言います。両方残ります。

エコシステムが違うので、どちらかに統一される可能性は低い。

ただ、その前提でどう選ぶかの判断軸は持っておく必要があります。

AP2の話をすると必ず「ACPはどうなの? Stripe×OpenAIが先に発表してたよね?」と聞かれる。実際、競合する別陣営のプロトコルが存在します。

Google陣営（AP2+UCP）vs OpenAI×Stripe陣営（ACP）の勢力図

整理するとこんな構図です。

Developing an open standard for agentic commerce

Today, we announced that Stripe is powering OpenAI’s new commerce experience, Instant Checkout in ChatGPT, and we released the Agentic Commerce Protocol, a new open standard that enables programmatic commerce flows between AI agents and businesses.

stripe.com

ACPは2025年9月にStripeとOpenAIが発表したプロトコルです。

ライセンスはApache 2.0、つまりオープンソース。

核心技術はShared Payment Token（SPT）で、購買資格情報（カード情報など）を公開せずに決済を起動できる仕組みです。

ChatGPTのInstant Checkout機能を通じて、すでに実環境で動いています。

ChatGPT規模のユーザーベース（週間アクティブユーザー約9億人、2026年2月時点）にアクセスできる、というのがACP最大のアセットです。

UCP/AP2はGoogle検索とGeminiから流入するユーザーをカバー。

ACPはChatGPT経由のユーザーをカバー。

エンドユーザーから見ると、AIエージェントの選択肢が複数あって、それぞれが異なるプロトコルで決済する、という未来になる可能性が高い。

だから「どちらが勝つか」ではなく「自社はどちらから優先するか」が正しい問いです。

AP2 vs ACP——コスト・ユーザーベース・エコシステムで選ぶプロトコル選定の判断軸

実務でプロトコルを選定する時に使える判断軸を、私のフレームで3つに整理します。

判断軸1: コスト

公開情報ベースの試算ですが、UCP経由の取引コストは約3.2%、ACP経由は約7.2%という数字が出ています。

これは決済手数料+プラットフォーム手数料を含んだ実効コストです。

倍以上の差がある。

PMが経営に提案する時、これは無視できない数字です。

粗利が10%しかない物販事業だと、ACP経由は赤字ラインですからね。

判断軸2: ユーザーベース

ChatGPTのユーザー数 vs Google Search/Geminiのユーザー数、という比較軸です。

一般論で言えばGoogle側のリーチが広いですが、ChatGPTユーザーは「AIネイティブ」な層に偏っていて、新サービスの早期採用率が高い。

「うちのターゲットはアーリーアダプター」という会社はACP、「マスマーケットを狙う」ならUCP/AP2、というのが基本的な棲み分けになります。

判断軸3: エコシステム適合性

既存のシステム連携で考えるパターンです。

• 既にShopifyや主要ECプラットフォームを使っている → UCPが自然
• 主要決済プロバイダー経由でグローバル決済している → AP2に乗りやすい
• 自社プロダクトをChatGPT Plugin/GPTで配信している → ACPが直結

ちなみにMUFGがAP2+UCP+A2Aを選んだのは、判断軸3の「エコシステム適合性」がいちばん効いたんだと思います。

Google Cloud上に決済インフラを構築する以上、Googleの3プロトコルを採用するのが自然な流れです。

それ、AIに壁打ちしました?

自社の現状をAIに整理させて、3つの判断軸で点数化させると、選定議論が一気に進みますよ。

ここまでで概念整理は終わり。次のセクションから、いよいよ「あなたのプロダクトはどうか」という診断パートに入ります。

カイの実装診断——あなたのプロダクトは「エージェンティックコマース対応」か

toA連載の読者から「概念はわかった。で、自分のプロダクトは何ができてないの?」という声をよくもらいます。

なので診断ツールを作りました。

過去のtoA連載で出した「3層プロトコルチェックリスト」を発展させて、エージェンティックコマース時代に必要な5項目に拡張しています。

エージェンティックコマース対応の5項目チェックリスト（discovery / authorization / payment / identity / settlement）

各項目について、自社プロダクトがどこまでカバーできているかをチェックしてみてください。

項目1: discovery — 商品/サービスの自動発見可能性

• 商品カタログがマシンリーダブル形式（JSON-LD等）で提供されている
• API/MCPサーバー/A2A経由でAIエージェントがアクセス可能
• 商品検索のレスポンスがエージェント前提の構造（カテゴリ、価格、在庫、配送条件が標準フィールド）
• .well-known/ucpエンドポイント、または同等の自己記述メタデータが存在

ここがゼロだと、AIエージェントから見えない店舗になります。

Googleのインデックスから外れるよりずっと致命的で、存在自体がなかったことになります。

項目2: authorization — ユーザー委任の検証可能性

• 認証フローでBOTとAIエージェントを区別できる
• ユーザーから委任を受けたエージェントを識別する仕組みがある
• 委任範囲（金額上限、有効期限、商品カテゴリ）を制御できる
• 監査ログでエージェント経由の取引を追跡可能

ここが弱いと、AIエージェント経由の不正取引リスクが跳ね上がります。

「委任されました」を証明する手段がない状態でエージェント決済を受け入れるのは、鍵のかかっていない金庫を開放するようなものです。

項目3: payment — エージェント経由決済の実行可能性

• カード情報を直接渡さずに決済できる仕組み（トークン化済み）
• 既存のStripe/PayPal/カードブランド決済と整合性が取れる
• 決済完了通知がエージェントに非同期で返せる
• 決済失敗時のロールバック処理がエージェントAPIで設計されている

決済層は既存インフラの拡張として設計するのが現実解です。

項目4: identity — エージェントと人間の区別

• AIエージェント経由のトラフィックを識別するヘッダー/トークンの実装
• レート制限がエージェント前提に設計されている（人間想定の値だと詰まる）
• カスタマーサポート問合わせの主体がAIエージェントの場合の対応設計

意外に見落とされる項目です。

コールセンターにAIエージェントから問合わせが来るケースの対応、考えてますか?

「人間が来る前提」の設計のままだと、エージェント対応で詰まってクレームになります。

項目5: settlement — 取引の事後処理

• 返品/キャンセルがエージェント経由で実行可能
• ポイント還元/クーポン適用がエージェント決済時に正しく計算される
• 取引履歴がユーザー側のAIエージェントから参照できる
• 紛争処理（チャージバック等）でエージェント経由取引を識別できる

「買って終わり」じゃないんですよ。

返品や紛争処理まで含めた取引のライフサイクル全体が、エージェント前提で動くか?が問われます。

5項目すべてに「○」が付くプロダクトは、現時点の日本でほぼ存在しないと思います。

だから今動き出すPMが優位に立てる。

MUFGユースケースから逆引きするPM設計の要件

MUFGが示した「粉ミルク撮影→AI決済完結」のユースケースから逆引きすると、PMが設計すべき要件はこうなります。

PM実務に翻訳すると、自社プロダクトに対して「このステップ、AIエージェントが代行できる前提で設計されてる?」を1つずつ問うていく作業になります。

私がよくクライアント案件で使う設計手順を共有します。

1. 既存ユーザージャーニーを書き出す（5〜7ステップ）
2. 各ステップで「人間が手で操作している部分」を洗い出す
3. その部分をAIエージェントが代行する場合に必要なAPI/プロトコル/委任設計をリストアップ
4. 5項目チェックリストと突き合わせて優先度を決める
5. 月単位のロードマップに落とす

このプロセスをAIに壁打ちさせると、初期叩き台が30分でできます。

あとは意思決定だけ自分でやる。

これがカイ流です。

ここまでで診断は完了。最後のセクションで、「で、月曜朝に何をやるの?」に答えます。

エージェンティックコマース時代にPMが今すぐやること——3つのアクション

連載読者の皆さんに約束してきたとおり、最後は具体アクションで締めます。

「概念はわかった。フレームもわかった。でも明日何から手をつけるの?」——この問いに答える3つのアクションを、優先度順に並べました。

MUFGが2026年度中にPoCを完了させ、2027年度に正式サービスを始める。

このタイムラインを頭に入れた上で読んでください。

アクション1 - .well-known/ucp エンドポイントの準備

最優先はこれです。理由は、コストが小さくリターンが大きいから。

.well-known/ucpエンドポイントは、自社サイトのルートドメイン直下に1つのJSONファイルを置くだけで成立します。

エンジニア工数は1〜3日。

それでAIエージェントから「発見可能な店舗」になります。

JSONプロファイルに含める情報の最小構成はこんな感じです。

{
  "version": "1.0",
  "merchant": {
    "name": "Your Merchant Name",
    "domain": "yourstore.example.com"
  },
  "endpoints": {
    "products": "/api/products",
    "checkout": "/api/checkout",
    "mcp": "/mcp"
  },
  "supported_protocols": ["ucp", "ap2", "a2a"],
  "payment_methods": ["card", "wallet"]
}

これを置いておくだけで、UCP対応AIエージェントから自社カタログを読みに来てくれます。

PM視点で見ると、「やってもどうせユーザー来ないでしょ」と思うかもしれない。

でも逆なんですよ。

Google Search/GeminiがUCPプロファイルを優先的にインデックスする方針を出しているので、「先に対応した店舗」が初期トラフィックを総取りする可能性が高い。

SEOで先行投資が有効だったのと同じ構造です。

3年前にAEO（Answer Engine Optimization）に手を出した会社が、今のAI検索で恩恵を受けてるのと同じ。

「準備できてから対応しよう」では遅い。先に旗を立てた店舗が地図に載る仕組みです。

アクション2 - Mandate設計（委任範囲をユーザーに明示するUX）

次に着手するのはAP2 Mandateの設計です。

ここで多くのPMが間違えるのが、「Mandate=技術設計」と思ってエンジニアに丸投げするパターン。

違います。

Mandateは本質的にUX設計なんですよ。

ユーザーに「どこまでAIエージェントに委任するか」を明示してもらうUI、これがすべてのスタートです。

委任範囲は最低でも次の4項目をカバーする必要があります。

• 金額上限（1取引あたり/期間累計）
• 商品カテゴリ（食品のみ可、ガジェットは不可など）
• 有効期限（24時間/1週間/取り消すまで）
• 取消条件（疑わしい取引時の即時キャンセル可否）

これをユーザーに「設定してください」と丸投げすると、誰も使いません。

「初期設定として安全側に倒した推奨値を提示しつつ、上級ユーザーは細かく調整できる」という二段構えのUXが正解です。

PM実務に翻訳すると、ユーザーリサーチで次の問いを設計する必要があります。

• どんな取引なら「自動でやっていい」と思うか?
• 「これは事前確認してほしい」と思う取引の境目は?
• 取消やクレームの導線が見えていれば委任範囲を広げてもいいか?

この問いをAIに壁打ちして仮説を立て、ユーザーインタビューで検証する。

Teresa TorresのOpportunity Solution Treeとセットで使うと整理しやすいです。

アクション3 - プロトコル選定（AP2 / UCP / ACPの優先順位決定）

最後がプロトコル選定。このアクションを後回しにするのは、戦略決定だから時間がかかるためです。

判断のフレームは前のセクションで出した「コスト/ユーザーベース/エコシステム適合性」の3軸。

これを使って、自社の優先順位を決めます。

カイのおすすめは「UCPを最優先で対応、AP2は同時に着手、ACPは様子見」というスタンスです。

理由は3つ。

1. UCPは実装コストが低く、Google検索/Geminiの初期トラフィックを取れる
2. AP2は60社以上が共同推進していて、業界標準として残る確率が高い
3. ACPはChatGPT特化なので、まずGoogle側で土台を作ってから判断しても遅くない

ただしこれは一般論で、業種によって優先順位は変わります。

• ファッション・アパレル → ACPが先行している領域なので併用検討
• 金融・決済 → MUFG事例から見てAP2が事実上の必修
• 旅行・予約 → A2Aの活用が鍵（エージェント間調整が多い）
• 物販EC → UCP+AP2の組み合わせが基本形

自社がどこに該当するかをAIに壁打ちさせて、競合がどのプロトコルにどれだけ投資しているかをリサーチさせる。

これだけで意思決定の8割は前進します。

最後にひとつ。

プロトコル選定は「決め切らないと動けない」と思いがちですけど、PoC段階なら2つ並行で走らせるのが正解です。

UCP対応の.well-known/ucpを置いて、AP2 Mandateの設計を進めて、半年後にACPの動向を見て追加判断する。

これくらいのスピード感で動かないと、MUFGが2026年度中にPoCを完了させ、2027年度に正式サービスを始める世界に追いつきません。

ここまで読んでくれた方、ありがとうございます。

toA連載の第5弾として、MUFG×Googleの発表を「日本のエージェンティックコマース実装フェーズ開始の合図」として読み解きました。

連載で繰り返し書いてきた「discovery→authorization→payment」の3層フレームに、AP2+UCP+A2Aがきれいに収まることを確認できたはずです。

エージェンティックコマースは、PMにとって「対応するか/しないか」を選ぶ段階を過ぎました。

今は「どのプロトコルから、どの順番で対応するか」を決める段階です。

第6弾では、実際にPoCを進めているチームの設計パターンを掘り下げる予定です。

最後にもう一度言います。それ、AIに壁打ちしました?

自社の5項目チェックリストとプロトコル選定、月曜の朝にAIと壁打ちして、来週のスプリントに1個でも乗せましょう。

それが今、PMができる最速の一手です。