AIエージェント

AP2とACPの違い：エージェント決済の権限と承認の設計

2026/9/30 （更新: 2026/10/13）

🤖 AIを使用して執筆

AP2は、範囲との比較をエージェントに任せない

AP2で、エージェントに任せる支払いの範囲や取引の内容を書くデータが、Mandateである。Mandateは、購入の内容を書くものと支払いの内容を書くものの2種類で、中身はエージェントが組み立てる³。利用者は、AIエージェントが操作しない画面でその内容を確かめて同意し、同意したMandateが署名される。仕様はこの画面をTrusted Surfaceと呼ぶ。エージェントが渡すMandateのうち、購入のMandateは加盟店が照合し、支払いのMandateは資格情報の提供者・決済網・加盟店の決済処理事業者が照合する³。Mandateを受け取って照合する側を、以下では検証側と書く。

利用者がTrusted Surfaceで同意したMandateに署名する鍵は、利用者本人の資格情報の鍵か、検証側が信頼するエージェント提供者の鍵かのどちらかである。エージェント提供者は、エージェントを提供する事業者を指す。提供者の鍵で署名する場合、提供者は、エージェントがその鍵にアクセスできないようにしなければならない⁵。

範囲との比較を誰がどう行うかについて、仕様は二つを定める。一つは、検証を決定的なコードで行うことである³。決定的なコードは、同じ入力に必ず同じ結果を返すプログラムを指す。もう一つは、同意を取るTrusted Surfaceを、エージェントに担当させないことである³。金額の比較は決定的なコードが行い、エージェントの説明は比較の入力に入らない。検証側はMandateそのものを照合するので、エージェントが途中で何を主張しても、署名された範囲を超える取引は通らない³。

二つの定めの理由を、AP2は仕様に書いている。仕様が想定する攻撃は、エージェントが読む文章に偽の指示を混ぜて、エージェントを従わせるものである。この攻撃をプロンプトインジェクションと呼ぶ。仕様は、プロンプトインジェクションを防ぐことは不可能だと仮定し、すべてのLLMとエージェントを潜在的な攻撃者とみなす⁶。攻撃を受けていないエージェントも、同じ入力に同じ結果を返すとは限らない。このため仕様は、人間の利用者に求める以上に、エージェントの挙動を強く制約する必要があると書く⁵。

人が居ない場面では、範囲のMandateと取引のMandateを組にして照合する

利用者が範囲だけを承認し、取引の確定には立ち会わない場面を、仕様は人が居ない場面（Human Not Present）と呼ぶ。Googleは、この場面を扱う版のv0.2を、2026年4月28日に公開した⁵。利用者が確定した購入内容をその場で承認する場面については、仕様は、加盟店とTrusted Surfaceが直接やり取りする従来のECの流れに置き換えられることが多いと注記する³。

この場面では、Mandateが二段になる。範囲だけを書いたMandateを、仕様は開いたMandateと呼ぶ。確定した取引を書いたMandateを、閉じたMandateと呼ぶ³。開いたMandateには、金額と日付のほかに、加盟店・支払先・品目の一覧も制約として書ける³。

二つのMandateは、署名する主体が違う。開いたMandateは、利用者がTrusted Surfaceで範囲を確認して承認したあとに署名される。署名するのは、利用者か、検証側が信頼する一覧に載ったエージェント提供者である³。閉じたMandateには、エージェントが自分の鍵で署名する³。

検証側がエージェントの鍵を信頼できるのは、開いたMandateがその鍵を指定しているからである³。開いたMandateはエージェントの公開鍵を含み、その鍵を持つエージェントしか、有効な閉じたMandateを作れない⁶。閉じたMandateは、開いたMandateのハッシュ値を含み、どの開いたMandateに基づくかを示す⁶。検証側は両方を受け取り、閉じたMandateが開いたMandateの制約を満たすかを照合する³。範囲の上限を超える金額の取引は、この照合で通らない。加盟店の決済処理事業者は、支払いの資格情報がその取引に絞られていることも確かめる³。

ACPの条件が制限するのは、加盟店である

ACPが書く利用条件は、確定した取引の側の条件で、仕様はこれをallowanceと呼ぶ。allowanceは、1回限りの利用・上限額・通貨・有効期限に、使ってよい加盟店とチェックアウト（1回の購入手続き）の識別子を加えた利用条件である²。条件を付ける対象は、支払いに使う情報である。allowanceを付けて預けられる情報は、今日はカードだけなので²、この記事ではカード情報と書く。

カード情報をallowance付きで預けるAPIを、ACPはDelegate Paymentと呼ぶ。このAPIでは、エージェントを動かすサービス（ChatGPTなど）が、利用者のカード情報とallowanceを、加盟店が使う決済代行事業者（PSP）の保管基盤へ送る²。PSPは、預かったカード情報の代わりに使うトークンを返す。エージェントがトークンを加盟店へ渡し、加盟店は自分のPSPを通して、allowanceの範囲内でだけトークンを使う²。決済や清算、コンプライアンスへの対応は、加盟店が既に使っている決済の仕組みが担う²。

ACPでも、取引が通るかは先に書いた条件との比較で決まる。Delegate Paymentを定める文書は、トークンがallowanceの範囲内でしか使えないと定め、利用の種類は1回限り（one_time）でなければならないと定める²。同じトークンでの2回目の請求や、上限額を超える請求は通らない。ただし現行の仕様では、決済手段ごとの定義（handler）がDelegate Paymentを使うかを宣言し、使うことは推奨の既定である²。ウォレットの提供者のトークンが既に制約を持つ流れのように、この形が合わない手段は外してよい²。

allowanceが縛るのは、トークンを使う加盟店である。エージェントがどの取引を選ぶかを縛らないことは、この文書が扱う範囲から分かる。リクエストに署名するのは、エージェントを動かすサービスの鍵である。利用者がエージェントに何を許したかは、この文書の範囲にない²。エージェントが利用者の望まない品を選んでも、その取引の金額を上限にしてallowanceを付ければ、加盟店の請求は通る。allowanceは、選ばれた品が利用者の望んだものかを見ない。ACPの別の文書は、3D Secure（カード決済で本人確認を追加する仕組み）のような認証が要る取引では、クライアントが認証を試みて結果を返さなければならないと定める²。

署名の前の誤りと範囲の内側の誤りは、比較では止まらない

比較で止まらない誤りについての記述は、AP2の仕様と独立の分析の両方にある。仕様が書くのは、失う金額に上限があることである。分析が書くのは、範囲の内側の誤りが見つからないことと、範囲そのものが署名の前に広げられうることである。

AP2の仕様は、プロンプトインジェクションによってエージェントが悪意ある商品を選ぶ脅威を挙げる。そのうえで、閉じたMandateの検証で制約を評価すれば「最悪の場合の金銭的・論理的な影響は厳密に有界になる」と書く⁶。有界は、上限があるという意味である。金額については、1回の取引で失う額が、開いたMandateに書いた上限額を超えない。範囲に品目の一覧を書いた場合は、加盟店が閉じたMandateを制約と照合する段階で、一覧に無い品の取引も通らない³。

仕様には、範囲を狭く保つための定めもある。開いたMandateの有効期限は、エージェントが作業を完了できる最小の値にするよう推奨する³。同じ開いたMandateで複数の承認を得させないため、前の開いたMandateが拒否されたことを示す受領書を受け取るまで、エージェントが次の開いたMandateを提示することを禁じる³。

ただし、1回分の範囲に閉じるかは別の定めによる。仕様は、攻撃を受けたエージェントが同じ開いたMandateで複数の取引を承認しようとする脅威を挙げる。これを止める定めは、エージェント自身への禁止と、資格情報の提供者や決済網が重なるMandateを拒否してよいという許可である。禁止の根拠になる受領書は、エージェントのLLMから保護しなければならない⁶。範囲の繰り返し利用を許す制約もあり、そのときは回数と総額の上限を別に書く³。

独立の分析は、Avivらが2026年8月に公開した、AP2 v0.2の安全性の分析である⁴。分析は、署名されたMandateが守るのは、署名後の取引データが書き換えられていないことだと書く。承認の前に取引の内容を左右するエージェントのやり取りと外部からの入力は、その保護の外に残るとも書く⁴。分析の結論は、署名の前にエージェントが受け取った情報が操作されると、Mandateの署名が有効でも、取引が利用者の意図を反映するとは保証されない、というものである⁴。

分析が挙げた脅威は、五つの攻撃系統にわたる48件である。分析はそのうち8件を、少なくとも一つの構成で危険度が高いと判定した⁴。この8件を覆う五つの実証は、公開の完全なAP2実装が無かったため、著者らが組んだ試験用の環境で行われた。著者ら自身、実証で示した失敗が第三者の実装で変わらず現れるとは言い切れないと断る⁴。

実証の一つは、範囲そのものを署名の前に広げる。利用者は、50ドル以下でカメラを1台買うようエージェントに頼んだ。加盟店のツールが50〜80ドルの見積もりを返し、エージェントはそこから上限80ドルの範囲を組み、支払先の制限も書かなかった。この実証は、承認の前に範囲を利用者の頼みと比べる下位のエージェントを置いた環境を前提にする。下位のエージェントの規則は本来、上限を超える金額や頼んだ制限の欠落を利用者へ差し戻すが、プロンプトだけの更新で、取引の文脈が正当化するように見えれば逸脱を受け入れる形に変わっていた⁴。Trusted Surfaceは、80ドルの上限と支払先の制限が無いことを購入手続きの余裕として示し、利用者は、同意の手順が警告を出さないことと加盟店の説明に頼って範囲を承認した⁴。分析は、この実証に署名された欄を隠す必要は無いと書く⁴。加盟店はのちに同じカメラの80ドルの取引を作った⁴。80ドルの取引は、署名された範囲に収まる。分析が示す緩和の一つは、差し戻しの規則をモデルの外の決定的な方針で強制することである。もう一つは、署名の前にTrusted Surfaceが上限の値そのものを示して支払先の制限の欠落を明示し、利用者の上限を超える範囲や、利用者が明示的に許していない欠落を拒むことである⁴。加盟店の商品情報やツールの出力は取引のデータとして扱い、上限を上げたり制限を外したりする理由にしない、という緩和も示す⁴。

分析は、署名がMandateを覆っても、エージェントがMandateを組み立てるもとになったコンテキストは署名の対象に含まれないことがあると書き、その例に商品の探索での選択、途中のカートの状態、ツールの出力、検証側への開示を挙げる⁴。プロトコルが取るべき対応は、次のどちらかだと分析は書く。署名の前にエージェントが受け取った情報を発行するデータに結びつけるか、結びつけを作らない実行の経路を拒否するかである⁴。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。