この記事のポイント
- Mastercard Verifiable IntentはGoogleと共同開発されたオープンソースの暗号認可フレームワークで、AIエージェント取引における「誰が・何を・どこまで」許可したかを改ざん不能な形で記録する
- SD-JWT委任チェーンと8種類の制約条件により、エージェントの行動範囲を暗号学的に制限し、選択的開示で各関係者に必要最小限の情報だけを共有する
- AP2・UCP・ACPなど既存プロトコルとの統合マッピングを備え、特定の決済ネットワークに依存しない汎用的な信頼レイヤーとして設計されている
Mastercard Verifiable Intentとは何か
2026年3月5日、Mastercardはエージェンティックコマース向けの新たなオープン標準「Verifiable Intent」を発表しました。Googleとの共同開発で、IBM、Worldpay、Fiserv、Adyen、Checkout.com、Basis Theory、Getnetがパートナーとして参画しています。
この発表の背景にある問題は明快です。AIエージェントがユーザーの代わりに商品を購入する時代が到来しつつありますが、「そのエージェントは本当にユーザーから許可を得て動いているのか」を証明する標準的な手段がありませんでした。3Dセキュア認証もSMS確認コードも、画面の向こうに人間がいることを前提としています。エージェントが自律的に購入を完了する場面では、この前提が成り立ちません。
Verifiable Intentが提供するのは、暗号学的に検証可能な認可の証拠です。消費者のアイデンティティ、具体的な購入指示、そしてマーチャントとの取引結果を、単一の改ざん不能なレコードに結合します。推測ではなく、暗号署名された事実に基づいて信頼を構築する仕組みです。
SD-JWT委任チェーン — 技術的な核心
Verifiable Intentの技術的基盤は、SD-JWT(Selective Disclosure JSON Web Token)による階層型クレデンシャルです。これはIETFが標準化を進めるSD-JWT仕様をベースに、エージェント取引に特化した拡張を加えたものです。
3層の委任構造
委任チェーンは3つのレイヤーで構成されます。第1層はクレデンシャルプロバイダ(カード発行会社や銀行など)がSD-JWTを発行し、ユーザーのアイデンティティを公開鍵に紐付けるレイヤーです。cnf.jwk(confirmation JSON Web Key)クレームを通じて、「この鍵の持ち主はこの消費者である」ことを暗号学的に証明します。
第2層では、ユーザーが自身の鍵でエージェントへの委任を署名します。ここで重要なのが制約条件(Constraints)の付与です。「5万円以下」「この加盟店のみ」「3日以内」といった条件を暗号学的に結合し、エージェントの行動範囲を厳密に定義します。
第3層は、エージェントが実際の購入を実行する際に生成する履行クレデンシャルです。マーチャントが署名したチェックアウトオブジェクトと、第2層で定義された制約条件を照合し、エージェントの行動が委任範囲内であることを検証可能にします。
8つの制約タイプ
Verifiable Intentの仕様は、8つの登録済み制約タイプを定義しています。金額上限、加盟店許可リスト、予算キャップ、定期購入条件などが含まれ、検証者はこれらすべてをサポートすることが求められます。
従来の「ユーザーが口頭でエージェントに指示する」モデルでは、エージェントが指示を拡大解釈するリスクが常にありました。意図のドリフトと呼ばれるこの問題に対して、Verifiable IntentはKYA(Know Your Agent)の考え方を取り入れ、制約条件を「ファーストクラスの認可境界」として扱い、機械的に検証可能な境界線に変換します。エージェントが制約を超えた行動を取ろうとしても、暗号学的な検証で即座にブロックされる設計です。
たとえばOpenAIのショッピングエージェントが卵1ダースに31ドルを支払った事例は広く知られていますが、Verifiable Intentの制約条件が適用されていれば、金額上限を超えた時点でトランザクションは拒否されます。これは人間の判断に依存しない、構造的な安全装置です。
選択的開示 — プライバシーと検証の両立
エージェント取引の信頼性を確保するには、関係者間で情報を共有する必要があります。しかし「すべての情報をすべての関係者に見せる」アプローチは、プライバシーの観点から許容されません。Verifiable Intentが採用する選択的開示(Selective Disclosure)は、この矛盾を暗号技術で解決します。
データはデフォルトで非公開です。各関係者には、その役割を果たすために必要最小限の情報だけが開示されます。マーチャントにはエージェントの認可が有効であることを確認するのに十分な情報が提示されますが、消費者の他の購入制約や残予算は見えません。エージェンティック決済の紛争が発生した場合には、紛争解決に必要な範囲で追加情報が開示されます。
この仕組みはSD-JWTの選択的開示機能を活用しています。JWT内の個別クレームをハッシュ化し、開示が必要な場合にのみ元データを提示する方式です。暗号学的なコミットメントにより、「開示された情報が元のクレデンシャルの一部である」ことを第三者が検証できます。
即時モードと自律モードの使い分け
Verifiable Intentは2つの動作モードを定義しています。
即時モード(Immediate Mode)は、ユーザーが購入プロセスにリアルタイムで関与する場面で使われます。エージェントがカートを構成し、マーチャントがチェックアウト内容を確定した後、ユーザーのデバイスが最終承認の署名を行います。AP2のCart Mandateに対応する概念で、短期間有効な第2層クレデンシャルが発行されます。
一方の自律モード(Autonomous Mode)は、ユーザーが事前に制約条件を署名しておき、エージェントがその範囲内で後から独立して購入を実行するシナリオです。「週末のフライトが3万円以下になったら予約して」といった委任型の購入がこれに該当します。AP2のIntent Mandateと対応しており、エージェントは制約条件の範囲内で履行クレデンシャルを生成します。
Visa Trusted Agent Protocolとの比較
Visa・Mastercardのエージェンティックコマース標準化競争において、両社のアプローチは明確に異なります。
| 項目 | Mastercard Verifiable Intent | Visa Trusted Agent Protocol |
|---|---|---|
| アプローチ | SD-JWT委任チェーン + 選択的開示 | エージェント認証 + 決済クレデンシャル伝送 |
| 検証対象 | ユーザーの意図と制約条件 | エージェントの正当性と消費者の紐付け |
| プライバシー設計 | ロール別に開示範囲を制御 | 最小限の情報共有を推奨 |
| プロトコル連携 | AP2・UCP・ACPとの統合マッピング | ACP・x402との連携を表明 |
| オープンソース | 仕様・リファレンス実装を公開 | 開発者ポータルで仕様を公開 |
| 標準基盤 | FIDO・EMVCo・IETF・W3C | EMVCo・FIDO |
Fintech Wrapupの詳細比較分析が指摘するように、両者はスタックの異なる層を最適化しています。Verifiable Intentは「ユーザーが何を許可したか」の暗号証明に焦点を当て、Visaは「エージェントが正当であり、背後の消費者と紐付いているか」の認証に重点を置いています。
では、マーチャントはどちらに対応すべきなのか。現時点での答えは「両方」です。両社とも自社のフレームワークを他のプロトコルと補完的に機能するよう設計しており、Cloudflareが開発するWeb Bot Auth(詳細解説)のように、両フレームワークの基盤となる技術も登場しています。エージェンティックコマースの信頼レイヤーは、単一の規格ではなく複数の補完的なプロトコルの組み合わせで形成される方向に進んでいます。
エコシステムとプロトコル間連携
Verifiable Intentの設計上の特徴として、特定のエージェントプロトコルに依存しないプロトコル非依存性が挙げられます。仕様書には、GoogleのAP2、UCP、OpenAI/StripeのACP(SPTを含む)との統合マッピングが含まれています。
この設計思想は、MastercardがVerifiable Intentを自社の決済ネットワーク専用ツールではなく、業界横断的な信頼レイヤーとして位置づけていることを示しています。PYMNTSの報道によれば、今後数か月以内にVerifiable IntentはMastercard Agent PayのインテントAPIに統合され、パートナー企業との実運用が開始される予定です。
仕様はFIDOアライアンス、EMVCo、IETF、W3Cの既存標準に基づいて構築されています。独自インフラを必要としない設計は、エージェンティックコマースの標準乱立問題に対する一つの解答です。既存の広く採用された仕様の上に構築することで、新たなプロトコルの採用障壁を下げています。
EC事業者が準備すべきこと
Verifiable Intentは2026年3月時点でDraft v0.1の段階にあり、verifiableintent.devとGitHubでオープンソースの仕様とリファレンス実装が公開されています。商用環境での本格運用はこれからですが、EC事業者が今から意識すべきポイントがあります。
まず確認すべきは、自社の決済サービスプロバイダー(PSP)の対応状況です。Fiserv、Checkout.com、Adyen、Worldpayといった主要PSPは既にパートナーとして参画しており、PSP側の対応が進めば加盟店の統合負荷は大幅に軽減されます。
次に、紛争処理の変化への備えです。Verifiable Intentの暗号的監査証跡は、「AIが勝手に買った」というチャージバック申請に対して、エージェントがユーザーの委任範囲内で行動していたことを暗号学的に証明する手段を提供します。紛争解決のプロセスが根本的に変わる可能性があります。
まとめ
Verifiable Intentは、エージェント取引における「信頼の証明」を推論から暗号学に移行させるフレームワークです。仕様のDraft v0.1が公開された段階であり、商用実装はまだ先にありますが、8社のパートナーと複数のプロトコル統合マッピングが示す方向性は、エージェンティックコマースの信頼基盤がどう形成されるかの一つの道筋を描いています。




