投稿者 投稿日: カテゴリー EC×AI活用
AI購買プロトコルとは、AIエージェントが商品探しから決済までを店舗とやり取りする共通規格のことです。
ACP、UCP、AP2、MCP、そしてカード会社のエージェント認証。2025年秋からの約1年で、AIエージェントに買い物をさせるための規格が少なくとも5系統並ぶ状態になりました。EC事業者からは「どれから対応すればいいのか」「全部に対応する予算はない」という相談が増えています。結論を先に書くと、多くの日本のEC事業者にとっての最初の一手は、どの規格の実装でもなく、全規格に共通して効く商品データの整備です。この記事では、5系統の役割の違いを整理し、事業者のタイプ別に対応の順番と実装コストの考え方を、プロンプト4本つきで解説します。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづいて解説します。
5つのプロトコルはそれぞれ何を担っているのか
5系統は競合しているように見えて、実際には「担当する工程」が少しずつ違います。この違いをつかむと、全部に対応する必要がない理由が見えてきます。
1つ目のACP（Agentic Commerce Protocol）は、OpenAIがStripeと組んで2025年9月に公開した規格です。ChatGPTの中で購入まで完了する「Instant Checkout」の土台で、OpenAIの発表では、店舗が販売者のまま注文・決済・配送を担う設計とされています。担当するのは主にチェックアウト、つまり購入手続きの実行です。
2つ目のUCP（Universal Commerce Protocol）は、Googleが2026年1月に発表した規格で、Shopifyや大手小売と共同で開発されたと報じられています。商品の発見、カタログの参照、カートの作成までを幅広く扱い、店舗側がAPIを公開する分散型の設計が特徴とされています。UCPの詳細はUCPへの対応手順の解説で整理しています。
3つ目のAP2（Agent Payments Protocol）は、Googleが2025年秋に打ち出した決済の規格です。AIエージェントが支払いをするとき、利用者が何をどこまで許可したのかを証明する仕組みを担います。工程でいえば、購入手続きのさらに奥にある「支払いの権限の証明」です。AP2の考え方はAP2の解説記事でまとめています。
4つ目のMCP（Model Context Protocol）は、AIが外部のツールやデータにつながるための汎用の規格で、公式サイトで仕様が公開されています。買い物専用の規格ではありませんが、ShopifyのShop MCPのように、商品検索から決済までをAIエージェントに開く入口として使われ始めています。2026年8月にアリペイが発表した中国のエージェンティックコマース基盤も、店舗の商品やサービスをSkillsとMCPツールに変換する方式を採っています。
5つ目は、カード会社によるエージェント認証の仕組みです。VisaのTrusted Agent ProtocolやMastercardのAgent Payなど、AIエージェントが本物かどうか、どの利用者の代理かを確かめる層を担います。業界の比較記事では、VisaがACPとUCPの両方と歩調を合わせる動きも伝えられています。
工程に並べ直すと、UCPやMCPが「探す・選ぶ」、ACPやUCPが「買う」、AP2とカード会社の仕組みが「払う・確かめる」を担う重ね合わせの構造です。xpayの技術比較など複数の解説でも、1回の購入の中でUCP、ACP、AP2が組み合わさりうると整理されています。本当に重なり合っているのは、主にUCPとACPのチェックアウト部分だと見る向きが多くあります。
なぜ「全部に対応」は現実的でないのか
全部に対応するのが現実的でない理由は3つあります。仕様の変化が速いこと、多くの層は店舗ではなくプラットフォームや決済事業者が実装すること、そして日本の利用者の購買行動がまだ追いついていないことです。
1つ目の仕様の変化について。比較記事の間でも、規格の発表時期や役割の分類が食い違っている状態です。半年前に書かれた実装ガイドが、すでに古くなっていることも珍しくありません。店舗が自前で各規格のAPIを実装すると、仕様の更新のたびに改修が必要になります。
2つ目の実装主体について。AP2やカード会社の認証は、店舗が直接組み込むものではなく、決済代行会社やカード会社の側で処理される部分が大半です。Shopifyのようなプラットフォームを使っている店舗なら、UCPやACPへの対応もプラットフォーム側が吸収する流れにあります。店舗が独自に動くべき範囲は、思っているより狭いのです。
3つ目の購買行動について。米国ではAIを使った買い物が広がりつつありますが、日本の消費者がAIエージェントに決済まで任せる場面はまだ限られています。利用意向と実際の利用のずれは、AIショッピングエージェントの利用意向と実態の解説で整理しています。
一方で、何もしないのも得策ではありません。どの規格が主流になっても、AIエージェントが最初に読むのは店舗の商品データです。価格、在庫、配送条件、返品条件、商品の属性が機械に読める形で整っていなければ、どの規格につないでも推薦の候補に入りにくくなります。だからこそ、最初の一手は商品データの整備になります。
商品データの整備といっても、特別な作業が必要なわけではありません。中心になるのは、JANコードや型番などの識別情報を全商品にそろえること、サイズ・容量・素材・色といった属性を説明文の中ではなく独立した項目として持つこと、送料と発送までの日数を商品単位で明示すること、の3点です。Google Merchant Centerに商品フィードを送っている店舗なら、フィードのエラーや警告をゼロに近づける作業が、そのままAIエージェント向けの準備になります。
食品ギフトを例にとると、内容量、賞味期限の目安、アレルゲン、のしや包装の対応可否が独立した項目になっているかどうかで、AIエージェントが「この条件に合う商品」として選べるかが変わります。説明文の中に埋もれた情報は、人が読めば分かっても、比較の材料としては拾われにくいからです。家電であれば型番と対応規格、アパレルであればサイズごとの実寸と素材の混率が、同じ役割を果たします。
事業者タイプ別の対応順序
対応の順番は、どのカートやプラットフォームで売っているかで大きく変わります。ここでは日本のEC事業者に多い4つのタイプに分けて整理します。
タイプAは、Shopifyで自社ECを運営している事業者です。プラットフォーム側がUCPやACP、Shop MCPへの対応を進めているため、店舗がやるべきことは、管理画面での設定の確認と、商品データの充実が中心になります。順番は、商品データの整備、プラットフォームの対応状況と手数料の確認、対応チャネルの有効化、の3段階が目安です。Shop MCPの中身はShopify Shop MCPの解説を参照してください。
タイプBは、国内のASPカートやパッケージ（futureshop、makeshop、EC-CUBEなど）で自社ECを運営している事業者です。各規格への対応は、カート事業者と決済代行会社のロードマップ次第になります。店舗側では、商品フィード（Google Merchant Centerなどに送る商品データ）の整備を先に進め、カート事業者に対応予定を問い合わせるのが現実的な順番です。
タイプCは、楽天市場、Amazon、Yahoo!ショッピングなどモールが中心の事業者です。モール内の商品がAIエージェントにどう扱われるかは、モール側の方針で決まります。店舗が独自に規格へ対応する余地はほとんどないため、モールの商品登録項目を漏れなく埋めることが、結果として最も効く準備になります。モールの規約上、外部の仕組みへ顧客を誘導する施策は取れない点にも注意が必要です。
タイプDは、自社開発のECサイトを持つ中堅以上の事業者です。このタイプだけが、UCPやACPを直接実装するかどうかの判断を迫られます。売上規模とエンジニアの体制に余裕がある場合でも、まずは1つの規格に絞って実装し、利用状況を見てから広げる段階的な進め方が安全です。カード会社側の仕組みを使って規格ごとの個別対応を減らす方法は、Visa Intelligent Commerce Connectの解説で扱っています。
そのまま使えるプロンプト4本
ここからは、対応の順番を自社に当てはめて決めるためのプロンプトを4本示します。ChatGPT、Claude、Geminiのいずれでも使える書き方にしています。
最初に、自社の状況を入力して、どのタイプに当てはまり、何から始めるべきかを整理します。
プロンプト1：自社のAI購買プロトコル対応の優先順位診断
あなたはEC事業者のシステム戦略を支援するコンサルタントです。
以下の当社の状況をもとに、AI購買プロトコル（ACP、UCP、AP2、MCP、カード会社のエージェント認証）への対応の優先順位を整理してください。
当社の状況：
- 販売チャネルと売上比率：{例：自社EC 40%、楽天市場 35%、Amazon 25%}
- 自社ECのカート・プラットフォーム：{例：Shopify／futureshop／自社開発}
- 決済代行会社：{会社名または種類}
- エンジニアの体制：{社内人数、外注の有無}
- 商品数：{SKU数}
出力してほしいもの：
1. 当社が直接対応すべき規格と、プラットフォームや決済代行会社に任せられる規格の区分
2. 今後6か月で取り組む順番（3段階）と、それぞれの理由
3. いま取り組まなくてよいことの一覧
条件：
- 各規格の仕様について、確認できない内容は「要確認」と明記する
- 推測の工数や費用には「目安」と付ける
次に、カート事業者や決済代行会社に、対応予定を問い合わせる質問状を作ります。タイプBの事業者には特に役立ちます。
プロンプト2：カート事業者・決済代行会社への質問状づくり
あなたはEC事業者の情報システム担当です。
当社が利用しているカート事業者と決済代行会社に、AIエージェント経由の購入への対応状況を問い合わせるメールの文面を作ってください。
聞きたいこと：
1. ACP、UCP、AP2などAI購買の規格への対応予定と時期
2. 対応した場合に店舗側で必要な設定や開発
3. AIエージェント経由の注文の手数料や決済条件
4. AIエージェント経由の注文を、通常の注文と区別して確認できるか
5. 購入者情報（氏名・連絡先・配信同意）が店舗にどう渡されるか
条件：
- 丁寧なビジネスメールの文体で、400字程度
- 回答期限の希望を入れる（{日付}）
- 当社名：{会社名}、担当者名：{氏名}
3本目は、全規格に共通する土台である商品データの不足を洗い出すためのものです。
プロンプト3：AIエージェント向け商品データの不足チェック
あなたはECの商品データ品質を点検する担当者です。
以下は当社の商品マスタから抜き出した{件数}件分のデータです。
AIエージェントが商品を比較・推薦・購入するときに必要な情報が欠けていないかを点検してください。
点検項目：
1. 商品名、ブランド、型番、JANコードなどの識別情報
2. 価格（税込）、送料、在庫数、発送までの日数
3. サイズ、容量、素材、色などの属性
4. 返品・交換の条件
5. 画像の中にしか書かれていない情報の有無（説明文から推測できる範囲で）
出力形式：
- 商品ごとに不足項目を列挙
- 全体で不足が多い項目のトップ5と、補う優先順位
- 値を推測で補わず、不足は不足として示す
商品データ：
{CSVの内容を貼り付け}
最後に、タイプDの事業者が直接実装を検討するときに、工数とコストの見積もりの前提をそろえるためのプロンプトです。
プロンプト4：プロトコル直接実装の見積もり前提を整理する
あなたはECサイトの開発プロジェクトを管理するPMです。
当社の自社開発ECサイトで、AI購買の規格（{UCPまたはACP}）への直接対応を検討しています。
開発会社に見積もりを依頼する前に、前提条件を整理してください。
整理してほしいこと：
1. 実装が必要になりそうな機能の一覧（商品カタログの公開、在庫の照会、注文の受付、決済連携、注文状況の通知など）
2. 既存の受注システム・在庫システムへの影響範囲
3. テストで確認すべき項目
4. 公開後の保守で発生しそうな作業（仕様更新への追随など）
5. 見積もり依頼時に開発会社へ伝えるべき前提と、確認すべき質問
条件：
- 規格の仕様の細部は公式仕様書で確認する前提とし、断定しない
- 工数や費用は書かず、見積もりの比較に使う観点を示す
4本を順に回すと、自社のタイプの確認、外部への問い合わせ、商品データの点検、直接実装の判断材料づくり、という流れで対応の順番が固まります。
失敗しやすいポイントと回避策
1つ目の失敗は、話題になった規格に飛びついて、自前で実装を始めてしまうことです。プラットフォームや決済代行会社が数か月後に対応すれば、自前で作った仕組みは二重投資になります。回避策は、プロンプト2で外部の対応予定を確かめてから、自社でやる範囲を決めることです。
2つ目の失敗は、規格への対応を「システムの話」として情報システム部門だけに任せることです。AIエージェントが読むのは商品データであり、その品質を握っているのは商品登録や運営の担当者です。規格の選定と商品データの整備を同じ会議で扱うと、優先順位のずれが起きにくくなります。
3つ目の失敗は、AIエージェント経由の注文を通常の注文と混ぜて管理することです。チャネルを区別しないと、どの規格からどれだけ売れたのかが測れず、次の投資判断ができません。受注データにチャネルの区別を持たせることは、規格の対応と同時に進めておくべき作業です。
KPI設計と費用・工数の目安
KPIは、準備の進み具合と、実際の流入の2段階で設計します。準備段階では、主力商品のうち必要な属性がそろった商品の割合と、外部事業者からの回答の取得状況を追います。流入段階に入ったら、AIエージェント経由の注文数、その注文の平均単価、問い合わせや返品の発生率を通常の注文と比べます。
費用の目安は、タイプによって大きく異なります。タイプAとCは、商品データの整備にかかる人件費が中心で、追加のシステム費用は小さく済む見込みです。タイプBは、カート事業者の対応次第で追加費用が発生する可能性があるため、プロンプト2の回答を待って判断します。タイプDの直接実装は、規格の範囲と既存システムの状態によって幅が大きく、開発会社に前提をそろえて見積もりを取ることが先決です。
AIツールの費用は、プロンプトを回すだけならChatGPT、Claude、Geminiの個人向け有料プラン（各社とも月額20米ドル前後の価格帯、最新の価格は各社公式で要確認）で足ります。工数は、プロンプト1による診断に半日、外部への問い合わせと回答待ちに2〜4週間、主力商品の商品データ整備に数週間を見込むのが目安です。
今後の展望：規格は収束するのか
規格が1つに収束するかどうかは、2027年にかけての大きな論点です。現時点の見方としては、完全な1本化よりも、工程ごとに役割を分けた重ね合わせの形で落ち着く可能性が高いと判断しています。探す・選ぶ、買う、払う・確かめるという工程の分担は、それぞれに別の事業者の強みが出る領域だからです。
日本市場に固有の論点もあります。楽天市場、Amazon、Yahoo!ショッピングのモールがAIエージェントにどう向き合うかで、日本のEC事業者の対応範囲は大きく変わります。モールが独自のAIエージェントを強化する方向に進めば、モール中心の事業者にとっての主戦場はモールの中にとどまります。逆に、モールが外部のAIエージェントに商品データを開く方向に進めば、モールの商品登録項目の充実がそのままAIでの露出につながります。
中国では、アリペイが決済・本人確認・集客を1社でまとめる形で先行しています。中国の動きはアリペイのエージェンティックコマース基盤の解説で整理していますが、米国型の分業と中国型の一体型のどちらが日本で主流になるかは、まだ見えていません。どちらに転んでも作り直しが少ないのは、やはり商品データの整備です。
よくある質問
AI購買プロトコルとは何ですか
AI購買プロトコルとは、AIエージェントが商品探しから決済までを店舗とやり取りするための共通規格のことです。OpenAIのACP、GoogleのUCPとAP2、汎用のMCP、カード会社のエージェント認証などがあり、それぞれ担当する工程が異なります。
中小規模のEC事業者も規格に対応する必要がありますか
いいえ、規格そのものに直接対応する必要はほとんどありません。多くの層はプラットフォームや決済代行会社が実装するからです。中小規模の事業者が優先すべきなのは、どの規格でも共通して読まれる商品データの整備です。
ACPとUCPはどちらを選ぶべきですか
自社開発のECサイトでない限り、店舗が選ぶ場面はあまりありません。Shopifyなどのプラットフォームを使っている場合は、プラットフォームの対応状況に従うのが現実的です。自社開発の場合は、主な顧客がどのAIサービスを使っているかを基準に、1つに絞って始めるのが安全です。
楽天市場やAmazonの店舗は何をすればよいですか
モールの商品登録項目を漏れなく埋めることが最も効果的な準備です。モール内の商品がAIエージェントにどう扱われるかはモール側の方針で決まるため、店舗が独自に規格へ対応する余地はほとんどありません。モールの規約に沿った範囲で商品情報を充実させてください。
対応しないとAI経由の売上を逃しますか
短期的には大きな影響は出にくいと考えられます。日本の消費者がAIエージェントに決済まで任せる場面は、まだ限られているからです。ただし、商品データの整備には時間がかかるため、今から少しずつ進めておくことが将来の機会損失を防ぎます。
MCPは買い物専用の規格ですか
いいえ、買い物専用ではありません。MCPはAIが外部のツールやデータにつながるための汎用の規格です。ShopifyのShop MCPやアリペイの基盤のように、買い物の入口として使われる例が増えています。
まとめ
AI購買プロトコルは5系統が並んでいますが、探す・選ぶ、買う、払う・確かめるという工程ごとに役割が分かれており、店舗がすべてに対応する必要はありません。多くの日本のEC事業者にとっての最初の一手は、全規格に共通して効く商品データの整備です。そのうえで、自社のカートやプラットフォーム、決済代行会社の対応予定を確かめ、直接の実装は自社開発の事業者だけが段階的に検討する。この順番を守れば、規格の勝敗に振り回されずに準備を進められます。
参考文献
- OpenAI「Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol」
- Model Context Protocol 公式サイト
- xpay Docs：ACP vs UCP vs AP2 — Technical Comparison
- ATXP：Every Agent Payment Protocol Compared（2026）
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
