Mastercard Agent Payとは？AIの支払いと店の役割

「AIが買い物を代行するなら、店はMastercardに商品を登録するのでしょうか」。Mastercard Agent Payは、商品を掲載する窓口ではなく、AIによる支払いを安全に扱うための仕組みです。購入者には支払いをAIに任せやすくする利点があります。店側では、対応する連携を通じてAIや購入者の意思を確認する材料を得られます。受け取れる情報は接続方式によって異なります。[1][2]

日本の通販サイトで連携を検討する担当者に向けて、商品情報・本人の許可・決済の役割を分けて説明します。AIが商品を探せることと、店がAIによる支払いを受けられることは、別々の準備です。

2026年9月10日時点では、仕組みの公式説明は確認できますが、日本の個別店舗が利用を始める条件までは確認できていません。 この記事は、2025年10月14日の受け入れ枠組みの説明と、2026年6月10日のAP4M発表などを基にした基礎解説です。今日の新着ニュースではなく、参照した資料には実装仕様の版番号が示されていません。[1][2][3]

1. 商品を見つける仕組みではなく、支払いを支える仕組みです

Agent Payが担う中心は、人に頼まれた作業を進めるAIが、信頼できる形で支払いに参加することです。Mastercardは、登録されたAIによる取引、ネットワークトークン、本人の意思と明確な同意を柱に挙げています。[1]

購入者が毎回カード情報を入力したり、支払い操作を細かく指示したりする負担を減らすことが期待されます。一方、店は「このアクセスは認められたAIか」「購入者はこの買い物を許可したか」を判断する必要があります。受け入れ枠組みは、その確認を支えるものです。売上増加や問い合わせ削減を実測した結果として紹介するものではありません。[2]

例えば、購入者がAIにコーヒー豆を注文してもらう場面を考えます。AIが商品を知るには、検索、商品情報の連携、店の商品ページなど、別の経路が必要です。商品登録をしただけでAgent Payによる決済が使えるわけでも、Agent Payを受け入れたら商品がAIに掲載されるわけでもありません。

以下の図では、商品を知る経路と、支払いを支える役割を分けています。商品情報と注文処理もそろって初めて、買い物全体がつながります。

Agent Payを検討する場面は、商品を見つけてもらった後の購入手続きです。ただし、AIの確認は決済の直前だけでなく、サイトへアクセスする段階にも関係します。公式説明には、サイトの手前で通信を扱うCDNを使った確認方法もあります。[2]

2. 登録されたAI・本人の許可・トークンは役割が違います

AIが認められた参加者であることと、その買い物を本人が許可したことは別です。さらに、その二つを確認できても、支払いの成功が決まるわけではありません。

登録されたAIかを確かめます

Mastercard Agent Pay Acceptance Frameworkは、店がAIの取引を受け入れるための枠組みです。公式説明では、AIを登録・確認してから、Mastercardのネットワーク上で取引できるようにします。AIごとに識別できるようにし、取引にAIが関与していることを認識する土台を作ります。[2]

ここでの登録は、店の商品登録でも、購入者の会員登録でもありません。「どのAIが取引するのか」を扱う仕組みです。承認されたAIからのアクセスだと分かっても、それだけで任意の商品を買う権限が与えられるわけではありません。

本人が何を許可したかを確かめます

公式説明のPurchase intent dataは、購入者の意思を伝えるデータです。カートの内容、取引の上限、許可が有効な期間などを含むと説明されています。店が購入者との異議申し立てに対応する際、経緯をたどる材料になり得ます。[2]

ただし、すべての店の管理画面に、この情報が表示されるとは確認できていません。どの情報を受け取り、保存できるかは、採用する接続方法の確認が必要です。また、許可の記録があることを、返金や異議申し立てが起きない保証とは扱えません。

トークンで支払い情報を扱います

ネットワークトークンは、カード情報をそのまま扱う代わりに使う支払い用の情報です。Agent Payの説明では、登録されたAIとトークンを使い、取引を追跡・確認できるようにする考え方が示されています。[1][2]

受け入れ枠組みは、AIによる取引に使う支払い用の情報をagentic tokensと呼んでいます。既存の購入フォームには、標準的なカード支払い欄に合うDynamic Token Verification Codeとして送る方式が説明されています。これは支払いに使う情報であり、商品のIDや購入者の許可そのものではありません。技術的な接続を認めるAPI認証とも役割が違います。[2]

3. コーヒー豆の注文で、最初から結果まで追います

ここからは説明用の架空の例です。日本でこの条件の取引が利用可能だと示すものではなく、実際の注文や通信を試した結果でもありません。

購入者は、コーヒー豆の商品ID「BEAN-200」を1袋、送料込み3,500円以内で買うことをAIに任せます。通貨は日本円（JPY）、許可は当日中だけとします。商品ページを読めること、必要な接続先や認証の準備が済んでいることを前提にします。以下のIDや金額は説明用であり、公式APIの項目名ではありません。

店を知り、商品と総額を確認します

AIは、別途用意された検索や商品情報の経路から店を知ります。その後、店の商品ページや接続先から「BEAN-200」の価格と在庫を確認します。今回の資料では、Agent Payが店の一覧や商品検索APIを提供するとは確認できていません。

店は、1袋の税込価格2,400円を示します。AIが配送先を伝え、店が送料600円を加えると、支払い総額は3,000円になります。ここでは税は商品価格に含まれ、追加の費用はない想定です。配送先が未定の段階では、送料込みの金額は確定していません。

店がこの購入手続きを「CHECKOUT-001」として管理するとします。これはまだ注文完了を意味しません。商品情報、配送条件、総額をまとめた購入手続きの記録です。

本人の許可と、今回の注文内容を照らします

AIが支払いに進む前に、商品が「BEAN-200」、数量が1袋、総額が3,000円であることを、本人が許可した内容と照らす必要があります。上限3,500円と有効期間だけでなく、商品や数量も条件です。公式説明のPurchase intent dataは、こうしたカート内容・上限・期間を扱います。[2]

送料が変わって総額3,600円になった場合、当初の許可の範囲には収まりません。総額が上限内でも、数量を2袋へ変えれば、今回の例で許可した注文とは違います。元の許可のまま進めず、条件変更への同意が必要になる場面です。ただし、再同意の画面やエラーの返し方は、今回の資料では未確認です。

支払いと注文結果を別々に確認します

既存フォームを使う方式では、確認されたAIが支払い用のトークン情報をカード入力欄に送る流れが説明されています。その先は店の決済処理につながります。購入者の許可が確認できたことと、支払いが承認されたことは分けて扱います。[2]

説明例として、支払い成功後に店が注文ID「ORDER-001」を確定したとします。購入手続きID「CHECKOUT-001」と注文IDは別です。店からAIへ、注文ID、商品「BEAN-200」1袋、総額3,000円、注文状態を返して初めて、購入者へ結果を知らせる材料がそろいます。

支払いが失敗した場合や、支払い結果が不明な場合は、注文成功と表示してはいけません。再送時の重複注文や、支払い済みなのに注文記録がない状態への対応も必要です。具体的な応答項目や再送の仕様は確認できていないため、この例は買い物の役割を追うためのものです。誰が許可の記録を作り、どのAPIで店へ渡すかまでは、この資料だけでは確定できません。

4. 店の決済会社とサイト側に残る役割

Mastercardが支払いの枠組みを提供しても、店の決済会社や注文システムの仕事は残ります。店の担当者にとって重要なのは、「Agent Pay対応」という一言ではなく、自社の構成で何が提供されるかです。

担当する側	主な役割	混同しないこと
AIを提供する側	本人の依頼に沿って商品を選び、購入処理を進めます	AIの登録だけでは個別の購入許可になりません
Mastercard	AIの登録・確認やトークンを使う支払いの枠組みを提供します	商品掲載や店の受注管理を丸ごと提供する説明ではありません
店の決済会社	店のカード決済を支えます	提携先に名前があるだけでは、自社契約での利用条件は分かりません
店・ECシステム	商品、在庫、送料、注文、発送、返品を扱います	支払いが成功しても、発送や購入後対応は残ります
CDNなどの提供側	枠組みに沿ってAIのアクセスを確認する役割を担えます	アクセスの確認と購入者の同意は別です

自社に必要なのは、これらの役割がつながることです。決済会社の対応に加えて、注文情報や本人の許可をどこまで受け取れるかが判断材料になります。[2]

公式説明には、CDNでWeb Bot Authを実装し、店が新しいコードを置かずにAIを確認する方式があります。また、既存の購入フォームを使う方式も示されています。「コードを書かない」は、対応サービスの選択や設定、運用確認まで不要という意味ではありません。[2]

なお、Web Bot AuthとHTTP Message Signatures（RFC 9421）は同一の規格ではありません。2025年10月の説明では、Web Bot AuthはRFC 9421を基盤とする仕組みとして扱われています。今回の資料だけでは、2026年9月時点の標準化段階や実装版は確定できません。[2]

5. AP4Mは、機械が連続して支払う用途を補います

Agent Pay for Machines（AP4M）は、Agent Payの単なる別名ではありません。Mastercardが2026年6月10日に発表した、機械やAIによる高頻度・少額の支払いを支えるサービスです。公式発表は、Agent Payを補う位置づけを明記しています。[3]

Agent Payが信頼できるAIの支払い参加を扱うのに対し、AP4Mは、システム同士が裏側で継続して行う取引に焦点を当てています。組織が支出上限や許可のルールを設け、カード、口座、ステーブルコインなど複数の方法で資金の受け渡しを支えると説明されています。[3]

コーヒー豆を1袋注文する例では、まずAgent Payによる購入代行の支払いが関係します。一方、店の業務を動かすAIが外部のデータや計算資源を繰り返し買うなら、AP4Mが想定する用途に近づきます。これは役割の比較であり、自社ですぐ利用できる構成の提示ではありません。

AP4Mの発表には、用途の検証や共通ルール作りを進める協業先が挙げられています。参加・支援企業に決済会社の名前があっても、その会社の日本の全加盟店へ提供済みとは読めません。料金、対象地域、契約別の提供範囲は、今回の資料では確認できていません。[3]

6. 日本の店は、商品掲載と決済対応を分けて判断できます

調べること	公式資料で確認できたこと	店側が判断できる範囲
Agent Payの用途	登録されたAI、支払い用トークン、本人の意思と同意を扱います	商品掲載ではなく、主に決済の検討対象です
店での受け入れ方	既存の購入フォームを使う方式と、より深く接続する方式が説明されています	全店で設定不要とは判断できません
日本での利用条件	今回の資料では店舗別の対象条件や申込手順は未確認です	自社での本番利用は確定できません
AP4Mとの関係	機械による高頻度・少額の支払いを補うサービスとして発表されています	通常の通販購入と用途を分けて考えられます

今回確認できたのは、Agent Payの製品説明、受け入れ枠組みの説明、AP4Mの発表です。受け入れ枠組みの記事には、Mastercard Developersで共有し、改善のための意見を募る旨があります。ただし、発表からリンクされた開発者向けの案内先は、2026年9月10日の確認で404（ページが見つからない状態）でした。APIの接続先・必須項目・署名形式は、そこで照合できていません。公開APIがないという証拠にはならないため、この記事では実装手順として案内していません。[2]

そのため、公開APIが存在しないとは断定しません。一方で、日本の店向け申込フォーム、参加承認の条件、対応する決済会社の契約、管理画面の操作を確認済みとして案内することもできません。

商品をAIに見つけてもらうだけなら、Agent Payを商品登録先として検討する必要はありません。 AIに支払いまで任せる顧客を受け入れたい場合は、登録されたAIの確認、本人の許可、決済、注文結果がつながるかを検討する話になります。

「Mastercardのカード決済を受け付けている」ことだけで、Agent Payの全機能が使えるとは判断できません。日本向けの対応条件と、自社の決済・ECサービスが提供する範囲が示されたときに、追加対応の要否を具体的に判断できます。現段階では、商品掲載の施策と決済の対応計画を分けられることが、店の担当者にとっての実用的な到達点です。