エージェントコマースにおけるIDレイヤーの必要性：Visa TAP、Google AP2、Mastercard Agent Pay

主なポイント

• Visa Trusted Agent Protocol (TAP)、Google Agent Payments Protocol (AP2)、Mastercard Agent Payはすべて、エージェント主導の購入をより安全にしますが、信頼性の問題の異なる部分を解決します。
• TAPは、マーチャントが承認されたエージェントを認識し、署名された商取引の意図を確認するのに役立ちます。AP2は、ユーザーが承認した内容の証拠を作成します。Agent Payは、登録されたエージェント、トークン化された支払い資格情報、同意、およびネットワークの可視性を組み合わせます。
• これらのメカニズムのいずれも、人間またはビジネスが誰であるかを証明し、リスクをスクリーニングし、管轄区域固有の管理を適用し、監査証跡を保持する必要性を排除するものではありません。
• Diditは、カードネットワークや決済会社ではなく、IDと不正対策のためのニュートラルなインフラストラクチャです。そのホスト型Model Context Protocol (MCP) サーバーは、11のカテゴリにわたる115のツールを公開し、Representational State Transfer (REST) Application Programming Interface (API) は組み込みの運用フローをサポートします。
• フル Know Your Customer (KYC) バンドルは0.33ドルで、すべてのアカウントには毎月500回の無料検証が含まれており、MCPサーバー自体は無料です。

エージェントコマースは、人工知能 (AI) エージェントが製品の推奨以上のことを行うときに始まります。オファーを比較し、カートを組み立て、支払い方法を選択し、個人またはビジネスによって設定された制限内で購入を完了する場合があります。この変化は、同時にいくつかの信頼性の問題を引き起こします。どのエージェントがリクエストを行ったのか？誰がそれを承認したのか？その背後にある人間または法人エンティティは誰なのか？取引は許可されているのか？そして、購入が紛争になった場合、どのような証拠が存在するのか？

新興の決済標準は、そのシーケンスの重要な部分に答えます。すべてが同じ部分に答えるわけではなく、互換性があるものとして扱われるべきではありません。開発者にとって有用な質問は、どのブランドが「勝つ」かではありません。それは、すべての信頼できるアーキテクチャの下で、どの管理が必要なまま残るかということです。

3つの標準、3つの信頼境界

Visa TAP：マーチャントはこのエージェントを認識し、信頼できるか？

Visa Trusted Agent Protocolはマーチャント向けです。その主要な役割は、マーチャントが承認されたコマースエージェントを通常のクローラー、悪意のあるボット、または未知の自動化と区別するのを助けることです。エージェントは、時間制限があり、目的固有の資格情報でリクエストに署名します。マーチャントまたはその保護プロバイダーは署名を確認し、ブラウジング、チェックアウト、またはより狭いアクションを許可するかどうかを決定できます。

TAPは3つの関連するシグナルを記述しています。エージェント認識署名、リンクされ署名された消費者またはデバイスID、およびリンクされ署名された支払いコンテナです。これは有用な分離です。エージェント認識は、どの承認されたエージェントが存在するかを確立します。署名された意図は、どのような種類のインタラクションが要求されているかを確立します。消費者シグナルは、マーチャントが既存の顧客を認識するのに役立ちます。

その消費者シグナルは、自動的に新しい本人確認に相当するものではありません。Visaのモデルには、上流のIDプロバイダーの役割が含まれていますが、マーチャントは新しいまたは高リスクの顧客に対して依然としてポリシーを必要とします。どのような証拠がチェックされたか、保証の強度はどれくらいか、KYCが必要か、再検証がいつ必要かなどです。TAPは、すべての管轄区域のオンボーディング決定を規定することなく、信頼できるID情報を伝達できます。

Google AP2：ユーザーはエージェントに何を購入する権限を与えたか？

Google Agent Payments Protocolは、承認と証拠に焦点を当てています。署名された委任状を使用して、ユーザーの意図、チェックアウト内容、および支払いを結びつけます。オープンな委任状は、マーチャントの制約や支出制限など、エージェントに限定的な裁量を与えることができます。クローズドな委任状は、特定のカートと金額に承認を拘束します。領収書は証拠チェーンを完成させます。

AP2は、人間がその場にいるフローと人間がその場にいないフローを区別します。人間がその場にいる場合、クローズドなチェックアウトと支払い委任状を直接承認できます。不在の場合、エージェントは事前に承認された制約内で動作し、最終的なクローズド委任状に署名します。制約が解決できない場合でも、マーチャントまたは資格情報プロバイダーは人間をループに戻すことができます。

この設計は、「この人物は、これらの条件下でこのアクションを承認したか？」という質問に、「この人物はどのように最初に検証されたか？」よりも直接的に答えます。AP2認証フレームワークは、関連する登録とユーザー資格情報が存在することを前提としています。したがって、開発者は、これらの委任状が意味のある保証を伝える前に、本人確認と資格情報ライフサイクルプロセスを依然として必要とします。

Mastercard Agent Pay：ネットワークはエージェント決済を認識し、管理できるか？

Mastercard Agent Payは、決済トークン化に基づいて構築されています。Mastercardの承認フレームワークは、エージェントを登録および検証し、固有のエージェントIDを割り当て、Agentic Tokensを使用して取引を追跡可能にし、支払い資格情報を保護します。マーチャント向けの認識は既存のチェックアウトインフラストラクチャで機能し、より深い統合はより豊富なデータ交換をサポートします。

このモデルはまた、消費者の同意、認証、および発行者、アクワイアラー、マーチャントがエージェントが関与したことを認識する能力を強調しています。これにより、エージェントの活動が、通常のカードなし取引要求と区別できない自動化ではなく、慣れ親しんだカードネットワークのリスクモデル内で可視化されます。

Agent Payは、支払い資格情報のセキュリティ、エージェントの可視性、およびネットワーク管理において最も強力です。本人確認、Know Your Business (KYB)、Anti-Money Laundering (AML) スクリーニング、年齢確認、または強化されたレビューをいつ適用するかを決定するマーチャントの義務を排除するものではありません。これらの決定は、製品、顧客、取引、および管轄区域に依存し、支払いレールのみに依存するものではありません。

標準が重複する場所、そしてIDが依然として適合する場所

これら3つのアプローチはすべて、委任されたコマースを明確にしようとしています。マーチャントは、自動化が関与していることを識別し、エージェントが信頼できることを確認し、アクションをユーザーの意図に接続し、購入を制限し、証拠を保持できる必要があります。彼らの重点は異なります。

• TAP：マーチャント境界でのエージェント認識と署名された意図、オプションのリンクされた消費者および支払いシグナル。
• AP2：ユーザーの意図をチェックアウトと支払い結果に結びつける暗号化された承認アーティファクト。
• Agent Pay：登録されたエージェント、トークン化された支払い資格情報、同意、認証、およびカードネットワーク全体での可視性。

本人確認は、これらの管理の前後に位置します。署名された承認は、資格情報が適切な人物に属している場合にのみ価値があります。承認されたエージェントは、合成、盗難、制裁対象、未成年、またはその他の不適格なアカウントによって指示される可能性があります。トークンは、マーケットプレイスの販売者またはビジネス受益者が必要なデューデリジェンスを通過したことを確立することなく、支払い資格情報を保護できます。

エージェントIDは「どのソフトウェアが行動したか？」に答えます。承認は「何をする許可があったか？」に答えます。本人確認は「その背後には誰がいるか？」に答えます。不正対策とコンプライアンス管理は「このアクションは実行されるべきか？」に答えます。

どの方法が勝っても開発者が構築しなければならないもの

• 登録と証明。再利用可能な資格情報または委任された支出権限を付与する前に、人物またはビジネスを確認します。リスクに応じて、KYC、KYB、生体認証、文書、データベース、または生体認証チェックを適用します。
• 資格情報のバインド。確認された主体を、エージェントフローに参加できるアカウント、デバイス、パスキー、ウォレット、またはその他の資格情報にバインドします。
• スコープ付き承認。マーチャント、カテゴリ、金額、頻度、有効期限、および人間が承認のために戻る必要があるかどうかなどの制限をキャプチャします。
• ランタイムリスクの決定。アクションの瞬間に、人物、ビジネス、ウォレット、および取引をスクリーニングします。Know Your Transaction (KYT) 管理とAMLチェックは、意図が署名されている場合でも関連性があります。
• 取り消しと回復。資格情報が侵害された場合、ユーザーが同意を撤回した場合、またはリスクが変更された場合に、委任された権限を停止します。
• 監査可能性。検証結果、承認アーティファクト、エージェントID、取引決定、タイムスタンプ、および後のレビューアクションを個別の証拠として保持します。

この階層化された設計は、意図的に標準に依存しないものです。チームは、マーチャントエッジでTAPを採用したり、エージェントワークフローでAP2委任状を採用したり、カード決済でAgent Payを採用したり、またはそれらを組み合わせたりすることができます。IDと不正対策の決定は、単一の決済ネットワークに組み込まれていないため、移植可能です。

Diditが現在、IDの半分をどのようにカバーしているか

Diditは、2,000社以上の企業が本番環境で使用しているIDと不正対策のためのインフラストラクチャを提供しています。同じ機能は、エージェント主導の操作のためのホスト型MCPサーバーと、アプリケーション制御フローのためのREST APIを通じて利用できます。より広範なアーキテクチャの概要については、MCPサーバーが本人確認を処理する方法と、MCPがAIエージェントのIDと不正チェックをどのように接続するかを参照してください。

ホスト型MCPエンドポイントはhttps://mcp.didit.me/mcpです。Streamable Hypertext Transfer Protocol (HTTP) を使用し、Open Authorization (OAuth) 2.1、Proof Key for Code Exchange (PKCE)、およびDynamic Client Registrationをサポートしています。ユーザーはDiditビジネスコンソールを通じてサインインし、スコープ付きアクセスを許可します。ホスト型MCPエンドポイントはAPIキー認証を使用しません。

認証後、エージェントは11カテゴリにわたる115のツールを呼び出すことができます。実用的な検証シーケンスでは、以下を使用できます。

didit_context_get
didit_session_create
didit_verify_id
didit_verify_passive_liveness
didit_verify_face_match
didit_session_get_decision

これらのツールは、検証セッションを作成し、選択されたチェックを実行し、構造化された決定を取得できます。その他の実際のツールには、didit_verify_aml、didit_verify_kyb_search、didit_verify_kyb_select、およびdidit_transaction_screen_walletがあります。高リスクの書き込みは、接続されたユーザーの権限と確認動作に引き続き従います。

REST APIはアプリケーションパスをカバーします。バックエンドからセッションを作成し、ホスト型または埋め込み型検証を通じてユーザーを送り、Webhookを使用し、決定を独自のシステムに保存します。RESTサーバー間リクエストはx-api-keyヘッダーを使用します。これはOAuth認証されたホスト型MCP接続とは別です。実装の詳細については、MCP概要、認証ガイド、およびツールリファレンスを参照してください。

価格設定はエージェント決済標準とは独立しています。MCPサーバーは無料です。フルKYCバンドル（ID確認、パッシブ生体認証、顔照合、IP分析）は0.33ドルで、すべてのアカウントには毎月500回の無料検証が含まれています。

標準に依存しない実装パス

ネットワークロゴを選択するのではなく、各アクションに必要な保証を定義することから始めます。低リスクのブラウジングにはエージェント認識のみが必要な場合があります。アカウント作成には検証済みのIDが必要な場合があります。規制された購入には、KYCまたはKYBとAMLスクリーニングが必要な場合があります。暗号通貨の送金には、ウォレットスクリーニングが追加される場合があります。金額の増加やリスクの変更により、人間がループに戻されることがあります。

次に、安定した内部識別子を使用して、支払いアーティファクトをID決定に接続します。エージェント署名、ユーザー承認、検証証拠、および支払い結果を区別して保持し、それぞれが独立して取り消し、レビュー、および標準の進化に合わせてアップグレードできるようにします。

Didit MCP開発者ページを探索するか、公開され、許容的にライセンスされたGitHubリポジトリを調べてください。ClaudeユーザーはDiditコネクタを追加し、OAuthログインを完了できます。

耐久性のあるアーキテクチャは階層化されています。支払い標準はエージェントの参加と承認を証明し、IDと不正対策のインフラストラクチャは関与している人物とアクションが許容されるかどうかを証明します。この区分により、開発者は信頼を単一の標準にハードコーディングすることなく、今日の標準をサポートできます。