AIエージェントに財布を渡すとは何を渡すことか：決済の公式仕様を、公開文書で確かめる

3行でいうと

公式文書では、カード番号そのものではなく、金額・期限・相手を絞った使い捨ての資格を渡す設計が共通しています。
人の承認は、購入ごとに求める型と、事前に範囲を承認して任せる型があります。後者を手順で詳しく書いていたのは、読んだ範囲ではAP2でした。
誤購入の損失を誰が負うかは、読んだ文書では決まっていません。AP2は判断材料になる証拠を残す仕組みです。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書や論文を読んでまとめたものです。法律や規格にかかわる話は条文・公式資料の紹介で、個別の判断は専門家にご相談ください。投資や購入の助言はしません。

先に結論

公式文書を読んだ範囲では、財布ごと渡す設計は見当たりませんでした。共通しているのは範囲を決めた委任です。上限金額、有効期限、使える販売者、回数を絞った資格を、1回の買い物ごと、または事前に承認した枠の中でだけ渡します。
「カード番号を見せない」が全部ではありません。StripeのLinkでは、エージェントは使い捨てのカード番号そのものを受け取る場合があります（金額は人が承認したもの。SPTやLink Pay Tokenを受け取る場合もあります）。一方、Mastercardの開発者向け文書は、カード番号は見せずトークンを使うと書いています。Visaの手順もエージェント専用のトークンです。
人の承認の位置は仕組みで違います。購入のたびに承認する型（Linkは原則として、Visaの開発者向け手順、AP2の「人がいる」型）と、先に範囲を承認する型（AP2の「人がいない」型）です。x402は、プロトコル自体に承認の手順がありません。
誤購入の損失を誰が負うかは、読んだ文書のどれにも書かれていませんでした。AP2の文書は、責任の割り当てを決めるものではなく、判断の材料になる証拠を残す仕組みとして説明しています。

前提：用語をそろえる

AIエージェント：AIが道具を自分で選び、複数の手順をこなす仕組みです。ここでは買い物の手順まで進めるものを指します。
委任：本人が、決めた範囲に限って、他者に行為を任せることです。財布ごと渡すのと違い、範囲が署名などで残ります。
最小権限：仕事に必要な最小の権限だけを渡す原則です。決済では、金額・期限・相手・回数を絞ることにあたります。
人の承認：実行の前に、人が「はい」と答える手順です。
トークン化（決済）：カード番号の代わりに、そのカードに結びついた別の番号（トークン）を使う仕組みです。盗まれても、使える範囲が限られるのが利点です。
マンデート：AP2の言葉で、人が承認した内容を署名つきで記録した証書です。委任状に近いと考えています（見立てです）。
マーチャント・オブ・レコード：売り手として顧客との取引や支払い処理の相手になる事業者です。エージェント側が売り手になるのか、店が売り手のままなのかが論点になります。

従来のカード決済と、エージェントが買う場合の違い

見立てです。ふつうの買い物では、人が自分でカード情報を入力し、必要なら本人確認を受けます。「誰が操作したか」は、画面の前にいる人だと暗黙に決まっています。エージェントが買うと、この前提が崩れます。

AP2の文書は、問題を3つに分けています。許可（その購入をユーザーが許した、と検証できる証拠はあるか）、意図の真正性（要求が誤りや幻覚ではなくユーザーの望みだと、店はどう確かめるか）、責任（不正や誤りのとき、誰が負うか）です。

Mastercardの開発者向け文書は、店に保存されたカードがあってもエージェントは使えず、エージェント用のトークンが要ると書いています。カード発行会社が、エージェント経由の取引だと識別するためです。

見立てです。仕組みは4つの層に分けると整理しやすいです。

層	問い	公式文書にある例
エージェントの身元	本物のエージェントか	VisaのTrusted Agent Protocol（TAP）
ユーザーの許可	人は何を許したか	AP2のマンデート、Visaのパスキー、Linkの承認
支払いの資格	何で払うか	トークン、Stripeの共有決済トークン（SPT）、使い捨てカード、署名つき送金
買い物の進行	注文までの手順	ACP（OpenAIとStripe）、UCP（Googleらが共同開発とある）

仕組みの比較：誰が何を証明し、人はどこで承認するか

公式の記述を言い換えて並べたものです。優劣の比較ではありません。

仕組み	誰が何を証明するか	人の承認
AP2（Google。FIDO Allianceで標準化中）	ユーザーがマンデートに署名し、店と決済側が検証。店はカートに署名	人がいる型は購入ごと。人がいない型は先に枠を承認
ACP（OpenAIとStripe。ベータ）	店がマーチャント・オブ・レコード。決済は店のPSPのトークン	チェックアウト仕様では、顧客が「Buy」を押す。別のOpenAI文書に明示の確認手順の記述なし
Visa Intelligent Commerce / TAP	TAPは、エージェントが署名で身元を示し店が検証（決済そのものを実行するとは、読んだ頁に書かれていない）	開発者向け手順では、購入ごとにパスキーで認証
Mastercard Agent Pay	エージェントは登録・認証が必要。Verifiable Intentで承認内容を記録	消費者がエージェント側で認証して承認する流れ
Stripe SPT / Link	SPTは販売者と上限を指定。Linkは使い捨てカード、SPT、Link Pay Tokenのいずれかを返す	Linkは原則として購入ごと（定期用カードは、期間ごとの上限額と条件を承認）。SPT自体に承認の手順はない
PayPal（Agent Ready）	ACPでは顧客がPayPalを承認、UCPではGoogle Walletの使い捨てトークン	「監督つき」「自動」の両方に対応と記載。保護の条件は記載なし
x402	支払う側が署名つき支払いデータを送り、サーバーまたはファシリテーターが検証	プロトコルには手順なし（セッションも認証も不要の設計）

権限の絞り方：何を、どう絞るか

相手：SPTは発行時に販売者のプロファイルを指定します。ACPの委任決済にはmerchant_idとcheckout_session_id、AP2には許可する販売者・受取人の制約があります。
金額：SPTとACPのmax_amount、AP2の金額範囲と予算があります。x402では、署名した金額と送り先をファシリテーターが変えられません。
期限：SPTとACPのexpires_at、AP2のexp、x402の有効時間枠があります。Linkの仮想カードは、公式文書の例では作成から約12時間のvalid_untilが付いています（決まった値かは読めていません）。
回数：ACPの委任決済は現時点でone_timeのみ。Linkの仮想カードは既定で1回限りで、対応する顧客には期間ごとの上限額をつけた定期用のカードも作れます。x402の署名は1回限りです。AP2は逆に、定期や回数（max_occurrences）も制約に書けます。
品目：AP2のチェックアウトのマンデートに、買ってよい品目の制約があります。

公式の値と例（SPT、Link、ACP、AP2、x402）

StripeのSPT：発行側がusage_limits（通貨、上限額、期限）と受け取る販売者を指定します。取り消し（revoke）もできます。販売者が受け取る情報は、カードのブランドと下4桁などです。対応国は米国、カナダ、欧州の一部で、一覧に日本は載っていません（2026年10月22日確認）。

公式文書の例です。この記事では、実行していません。

curl https://api.stripe.com/v1/shared_payment/issued_tokens \
  -u "<<YOUR_SECRET_KEY>>:" \
  -H "Stripe-Version: 2026-09-30.preview" \
  -d "payment_method={{PAYMENTMETHOD_ID}}" \
  -d "seller_details[network_business_profile]=profile_xxx" \
  -d "usage_limits[currency]=usd" \
  -d "usage_limits[expires_at]=1798761600" \
  -d "usage_limits[max_amount]=1000"

Linkの支払い依頼：エージェントが金額、店、目的の説明（100文字以上）を添えて依頼し、顧客が承認すると資格が返ります。承認の待ち時間は30分です（確認コマンドの待ち時間の初期値は600秒で、承認の期限より短いと書かれています）。資格は、仮想カードのほか、SPTやLink Pay Token（承認後、最長30分有効）も選べます。1依頼・1日・30日の上限にはper_transaction、daily、thirty_dayの項目があり、値は最小単位（セントなど）で、nullは無制限を意味すると書かれています。具体的な金額は、読んだ頁では確認できませんでした。細かい承認ルールは、link.comのページに「準備中（Coming soon）」とあります。米国とカナダの顧客向けで、売り手は両国の外でもかまいません。

ACPの委任決済の仕様：allowanceに、理由（one_time）、max_amount、通貨、checkout_session_id、merchant_id、expires_atが必須です。支払い方法はカードのみで、応答はvt_で始まる保管庫トークンです。

AP2の支払いマンデート：開いたマンデートの制約に、受取人、支払い手段、金額の範囲、予算（過去の合計に加算）、実行日の範囲、繰り返しの頻度があります。未知の制約は評価失敗として扱います。

x402のexactスキーム（EVM）：送り先と金額が署名に含まれ、有効な時間枠があり、1回限りです。ウォレット全体の使いすぎを防ぐ上限は、読んだ文書には書かれていません。

人の承認はどこに入るか

購入のたびに入る型：Visaの開発者向け手順では、エージェントが購入を勧めるとき承認を求め、ユーザーはパスキーで支払いの指示を認証します。Visaの網側では、認可が正しい店と金額から来たかを確認します。Linkも原則として購入ごとの承認です（定期用カードでは、期間ごとの上限額と条件を承認し、課金の時期は売り手が決めます）。
先に範囲を承認する型：AP2の「人がいない」型では、人が最初に開いたマンデートを承認します。その後、エージェントが条件に合う買い物を見つけ、自分で閉じたマンデートに署名して支払いまで進みます。店や資格の提供者が制約を判定できなければ、unresolved_constraintで「人がいる」型に戻ります。
手順がない型：x402は、承認や上限を使う側のウォレットやアプリで足す前提です（見立てです）。
ブラウザを操作して買わせる場合：OpenAIのAgents APIのコンピュータ操作の文書は、利用者の承認が必要なのは新しいサイトへのアクセスの単位で、個々の操作の確認ではないと書いています。購入のように重い操作は、それを実行できないものに限るか、自分で制御するブラウザ環境を使う、と案内しています。上の決済用の仕組みとは別の話で、承認の位置を自分で設計する必要があります（見立てです）。

失敗と責任：誰が負うのか

AP2：FAQは、証拠を提供して決済網が責任の原則を決める助けにする、と説明しています。紛争では、裁定者がユーザー署名のマンデートと取引内容を照らせます。責任の割り当てをAP2が決めるという記述は、Security、Flows、Implementationの各頁にありませんでした。実装の頁は、紛争に備えて署名つきの証拠を保存することを挙げています。
MastercardのVerifiable Intent：承認の記録（監査の証跡）を残して紛争時に使えるとしますが、責任の所在は読んだ頁にありません。
ACP：OpenAIの文書は、OpenAIはマーチャント・オブ・レコードではなく、注文の受理も拒否も店が行うと書いています。Stripeは、返金と紛争を既存の手順で扱えるとしています。
PayPal：購入者保護の条件は、読んだページになく、確認できていません。

見立てです。損失の負担を決めるのは、各社の利用規約やカード会社の規則など、この記事が読んでいない文書だと思います。AP2はプロンプトインジェクション（AIが読む文章に紛れた指示で操る攻撃）を防げない前提に置き、エージェントも攻撃者になりうるものとして扱います。だから制約の判定をAIの外の決まった処理に置き、最悪の被害を小さくする考え方です。

自分の仕事で試す前の確認点

見立てです。公式文書から組み立てたチェックで、試した結果ではありません。

渡すものは何か：実カード番号か、使い捨て番号か、トークンか、署名か。会話記録やログに残る場所はどこか。Linkの文書は、番号が会話記録に残りうると警告し、ファイルに出力する方法を勧めています。
範囲を設定で絞れるか：金額、期限、相手、回数を、サービス側で絞れるか。AIへの指示文だけに頼っていないか。
承認はどこか：購入ごとか、事前の枠か、なしか。事前の枠が切れた後に何が起きるか。
取り消せるか：SPTのように発行後に取り消せるか。期限で自然に切れるか。
通知と記録：使われたとき通知が来るか。「誰が何を承認したか」の記録が残るか。
地域と状態：SPTの対応国に日本は載っていません。Linkは米国とカナダの顧客向け、Visa Intelligent Commerceは、Visaの頁が「展開中」で、最終版には書かれた機能がすべては入らないかもしれないと断っています、Stripeの一部機能は限定プレビューです。
責任の窓口：誤購入や不正のとき、どこに連絡し、何が補償されるのか。規約を読むまで分かりません。

ニュースで読んだ話を、公式の文書で確かめた結果

話	確かめられたこと	注意
MetaとSierraがPersonal Agent Protocolを提案	Sierraの2026年10月6日の発表で確認。Meta、Sierraが、Genesys、Instinct、Rocket、Shopify、Stripe、Walmartと開発。OAuthを土台に、読み取りのみか書き込みもかを顧客が決める。v0.1仕様は2026年10月中に公開予定とあり、10月22日に公開済みかは確認できず	決済は将来の拡張で、人の承認は発表文に記載がない
OpenAIがAgents APIにコンピュータ操作	OpenAIの2026年9月29日付のまとめで確認。実行基盤はOpenAI側が運用	承認の仕組みは別の開発者文書にあり、上の通り
MicrosoftがWindowsにエージェントの容器（MXC）	Windows開発者ブログ（2026年6月2日付）で確認。ポリシーで動く実行層で、SDKは早期プレビュー	決済ではなく実行環境の隔離。利用者の同意の記述なし
InMobiが米国ECの36%を測定	一次の発表文を開けず、確認できていません	数字は採用しません
DoubleVerifyがChatGPT広告の計測を開始	DVの2026年10月5日の発表で確認	広告の効果測定で、決済とは無関係

気をつけること

この記事は、実際に使って確かめた記録ではありません。公式文書の記述を、2026年10月9日に読んでまとめ、10月22日に主な頁を取り直したものです。取り直していない頁（Mastercard、Microsoft、DoubleVerify、OpenAIのDevDay、UCP、FIDO、GoogleのAP2発表など）は10月9日の読み取りのままです。
版が動いています。AP2は2026年4月28日にv0.2が出ており、古い解説の「Intent Mandate」「Cart Mandate」と、現在の文書の「開いた／閉じたマンデート」は呼び方が違います。ACPはベータで、ACPの委任決済の仕様は、10月9日にはGitHubのunreleasedの版を読みましたが、10月22日にはリリース済みの2026-04-17の版に同じ項目があるのを読みました。StripeのAPIは2026-09-30.previewの版です（10月22日も同じ表記でした）。
文書どうしで書き方が違う点があります。ACPの作成者は、GitHubではOpenAIとStripeが維持、Stripeの頁ではMetaも挙げられています（10月22日にもStripeの頁で「Stripe、OpenAI、Metaが作った」旨の記述を確認しました。GitHubの頁にはMetaの記載がありませんでした）。
読んだページの要約を使った部分があります。重要な値（SPTの引数など）は別のページでも照合しましたが、すべてではありません。Linkの上限の金額は照合できていません。
PayPalの購入者保護、Visaの消費者向け上限の設定方法、Mastercardの承認手順の細部は、読んだページに書かれておらず、確認できていません。
表は文書の記載を並べたもので、優劣の評価でも、特定サービスの安全性の保証でもありません。業務で使う場合は、社内の担当者や専門家に相談してください。
この記事は、実際に使って確かめた記録ではありません。購入や契約をすすめる記事ではありません。

出典

更新履歴

2026年10月25日 書き方を直しました。
- 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した
2026年10月22日 公式の資料を読み直して、次の点を直しました。
- 前：Linkでは使い捨てカード番号そのものを受け取る → いま：受け取る場合がある。SPTやLink Pay Tokenの場合もある
- 前：Linkは購入ごとの承認 → いま：原則として購入ごと。定期用カードは、期間ごとの上限額と条件を承認
- 前：Linkの承認の待ち時間は10分 → いま：30分（確認コマンドの待ち時間の初期値は600秒）
- 前：Linkの上限は1依頼500ドル、1日500ドル、30日で20,000ドル → いま：項目名はあるが、具体的な金額は確認できなかった
- 前：Linkは米国の消費者向け → いま：米国とカナダの顧客向け
- 前：AP2は責任の割り当てを「対象外」と明記 → いま：そのような記述は見つからず、証拠を残す仕組みと説明されている