Visa TAPとは？AIによる買い物を店が見分ける仕組み

買い物を頼まれたAIが通販サイトに来ても、店には迷惑な自動アクセスとの区別がつきにくい場合があります。Visa TAPは、AIが送る電子署名を店が検証し、Visaのプログラムで認められたAIからのアクセスかを判断するための仕組みです。商品を調べるアクセスを受け入れる材料になりますが、署名の確認だけで購入の許可や決済成功まで確定するわけではありません。[1][2]

この記事は、日本の通販サイトでAIからのアクセスをどう扱うか検討する担当者向けの基礎解説です。2026年9月10日時点の公式資料を使い、店が確認できることと、注文・決済側に残る仕事を説明します。参照した仕様本文には版番号・公開日を確認できないため、同日の新発表や日付付き確定版としては扱いません。

調べること	確認できた状態と根拠	現時点で判断できること
AIの認識方法	Visaの仕様に署名項目と検証の流れがあります。[2]	店やサイト保護サービスが何を検証するか分かります。
製品の提供段階	紹介ページに開発・展開中との記載があります。[3]	掲載された機能を、全店舗で使えるとは扱えません。
日本の店舗の利用条件	公式資料では対象国や申込手順を確認できません。	管理画面からすぐ導入できるとは案内できません。

まず、公開仕様があることと、自店の契約サービスで利用できることを分けて読む必要があります。以下は導入手順ではなく、採用を検討するための仕組みの説明です。

1. 店が知らないAIにも、署名を確かめる入口を作る

Visa TAPの主な役割は、店が初めて受け取ったAIのアクセスに、検証できる情報を添えることです。 正式名称はTrusted Agent Protocolです。Visaの案内は、Visaが承認したAIを認識したい店舗や、サイトを保護する事業者を対象にしています。[1][2]

AIは、自分だけが持つ秘密鍵で通信の一部に署名します。店は、信頼できる鍵の保管先から取得した公開鍵を使って、その署名を確かめます。公開鍵は署名の検証に使う鍵であり、利用者のクレジットカード情報ではありません。[2]

店にとっての利点は、AIを名乗る文字列や接続元のIPアドレスだけに頼らず、承認されたAIからのアクセスかを判断できることです。買い物のための閲覧を一律に遮断せず、必要な範囲だけ通す判断に使えます。ただし、誤遮断や不正が何件減るかという実測値は、公式資料では確認していません。[2][3]

この検証は、店のサーバーでも、サイトの前段で通信を扱う保護サービスでも行えます。どちらの場合も、検証結果を受けて何を許可するかは店側に残ります。署名を確認したAIに、管理画面や全商品への無制限の操作権限を渡す仕組みではありません。[2]

図はTAPのうち、AIから届いた通信を認識する部分を示しています。TAPには顧客情報や支払い情報を署名で結びつける仕組みもあります。商品を見つけてもらう経路、在庫や送料を返す機能、注文の保存は別途必要です。[2]

2. 一つの買い物で、TAPの担当範囲を見る

ここからは、マグカップを1個買う説明用の架空例で追います。商品IDはMUG-001、通貨はJPY、税込商品価格は2,800円、送料は500円です。配送先を確認できた場合の合計は3,300円とし、実際の販売条件や通信記録ではありません。

購入者はAIに「このマグカップを1個、送料込み3,500円以内で探して」と頼んだとします。この例では、検索サービスなどを通じてAIが店の商品URLを知っており、購入前には本人が最終確認する前提です。商品発見や本人への確認画面を、TAPが提供するという意味ではありません。

AIが店の商品ページへアクセスするとき、TAPの認識用署名を添えます。店は署名を検証し、商品閲覧として許可するかを判断します。許可した場合、店の商品ページや既存APIが価格・在庫を返します。TAP自体が商品カタログや在庫を返すAPIになるわけではありません。[2]

次に、店の購入手続きが配送先から送料を計算します。この例では店側の購入手続きIDをCHK-001とし、商品1個・合計3,300円を本人に示します。このIDは流れを追うための仮の識別子で、TAPの項目名ではありません。

本人がこの内容を許可した後、AIは購入を進めます。店は購入用の署名や必要な支払い情報を検証し、既存の決済処理へ渡します。決済結果を受け、店の注文処理が注文を成立させた場合に限り、別の注文IDORD-001を返す想定です。署名検証の成功、購入手続きの作成、注文成立は、それぞれ違う結果です。[2]

3. 署名ヘッダには、何が入っているか

店は、署名そのものだけでなく、署名の対象・期限・用途も読み取ります。 HTTPヘッダは、ページやAPIへの通信に添える情報です。TAPのAI認識では、Signature-InputとSignatureという二つのヘッダを使います。[2]

Signature-Inputには署名対象と検証用の情報が入り、Signatureには署名値が入ります。公式例のsig2は、両者を対応づけるラベルです。ラベルやヘッダが存在するだけでは確認は終わらず、公開鍵を使った検証が必要です。[2]

項目	店が読み取る内容
@authority・@path	アクセス先のドメイン等と、ページのパスです。
created・expires	署名の作成時刻と、有効期限です。
keyid・alg	検証に使う公開鍵の識別子と、署名方式です。
nonce	通信の関連づけや、再利用の確認に使う識別子です。
tag	商品閲覧か、支払いを進めるアクセスかを示します。

マグカップの商品ページなら、閲覧用のagent-browser-authが用途の目印になります。購入手続きへ進む通信では、支払い用のagent-payer-authが使われます。ただし、この文字列は「3,300円を支払った」という結果ではありません。[2]

公式の閲覧例では、署名対象として@authorityと@pathが挙げられています。たとえば店のドメインと商品ページのパスを結びつけて検証する考え方です。一方、この例だけを根拠に、URLのクエリ、数量、金額、通信本文まで全部が署名対象だとは説明できません。[2]

マグカップの商品ページを読む通信なら、次のように追えます。これはヘッダの説明用抜粋です。ドメイン・商品パス・鍵のID・nonceは架空で、有効な署名値を省略しています。送信して動く完成例ではありません。[2]

GET /products/MUG-001 HTTP/1.1
Host: shop.example
Signature-Input: sig2=("@authority" "@path");created=1789016400;expires=1789016700;keyid="demo-key";alg="Ed25519";nonce="demo-request-001";tag="agent-browser-auth"

店は、署名対象のshop.exampleと/products/MUG-001、時刻、鍵、用途を確認します。この例の期限は作成から300秒後です。検証に通れば、店の商品ページから「MUG-001・1個2,800円・在庫あり」を返す、といった処理へ進めます。商品情報の返し方はTAPの共通APIではなく、店が用意する機能です。

署名が保護するのは、実際に署名対象へ含めた内容です。「通信に署名があるから、注文内容のすべてが改変されていない」と広げて考えないことが大切です。

4. 店は、期限・鍵・署名を順に確かめる

店側の検証では、必要項目を確認し、期限や再利用を調べ、公開鍵で署名を検証します。仕様は、必須項目の欠落、期限の条件違反、鍵の取得失敗や失効、署名検証の失敗などを、通信を遮断する条件として挙げています。[2]

期限については、作成時刻が現在より前、有効期限が現在より後で、両者の間隔が8分以内という規則があります。nonceについては、直近8分の記録を保持している場合、既に記録された値との重複を拒否する説明です。ヘッダを読むだけで、再利用を自動的に防げるわけではありません。[2]

最後に、店は届いた通信からsignature_baseを組み立てます。これは署名の検証対象を決まった形に並べた文字列です。順序や空白も検証に関係するため、見た目の似た文字列を独自に作るのではなく、採用する仕様に合わせる必要があります。[1][2]

検証に通ったら、店は示された用途に限ってアクセスを続けさせられます。マグカップの閲覧として確認できたなら、商品情報を返す一方、購入操作まで自動で許可しない運用が考えられます。[2][3]

TAPの署名がないアクセスは、この方法では承認されたAIとして確認できません。ただし、それだけで悪意があるとは断定できません。仕様も、店が遮断するか、別の方法で継続可否を判断するかを選べるとしています。[2]

5. AIの認識、顧客の照合、支払い情報は別です

TAPの仕様には、AIを認識する署名に加え、顧客の照合に使う情報と、支払い情報を運ぶ仕組みがあります。三つの役割を分けると、署名の確認で分かる範囲が見えます。[2]

仕組み	確認・利用する内容	それだけでは確定しないこと
Agent Recognition Signature	承認されたAIによる通信か、閲覧・支払いのどちらか	個別商品の購入条件や決済成功
Agentic Consumer Recognition Object	店の既存顧客と照合するための情報	店の会員への自動ログイン許可
Agentic Payment Container	支払い用の情報と、その署名	決済会社の承認や注文成立

顧客情報を受け取った場合も、店側で自店の会員情報と照合する処理が必要です。仕様にはnonce、idToken、contextualData、kid、alg、signatureが登場します。VisaのID Tokenを使う説明では、ハッシュ化されたメールアドレスなどと既存会員を対応づける表を、店が持つ必要があります。[2]

顧客情報のnonceは、通信ヘッダのものと結びつきます。また、kidは公開鍵の識別子で、ヘッダのkeyidと対応します。これらの照合は、別の通信から持ち込まれた顧客情報を取り違えないための確認です。[2]

支払い情報を運ぶAgentic Payment Containerにも、nonce、kid、alg、signatureがあります。中身は支払い方法によって異なり、カード入力フォーム向けの情報のハッシュや、別方式の支払い情報などが想定されています。一つの共通トークンを受け取れば、どの店でも決済できるという説明ではありません。[2]

既存のカード入力フォームを使う例では、フォームに入った支払い情報から店がハッシュを計算し、受け取った支払い情報のハッシュと一致するかを確かめます。ハッシュは内容を照合するための値です。不一致なら、その支払い情報で処理を進めません。一致しても、それだけで代金を受け取れたわけではなく、決済会社への処理と結果の確認が残ります。[2]

マグカップの例では、AIの署名が正しくても、商品が2個なら当初の数量と違います。同じ送料500円と仮定すると、合計は6,100円で、上限3,500円も超えます。購入条件を確認する仕組みが必要であり、agent-payer-authだけで数量や上限の確認を代用することはできません。

6. 公開資料の例を、そのまま実装には使えません

今回の資料には、規則とサンプルの間で確認が必要な箇所があります。 代表例は有効期限です。検証規則は8分以内ですが、掲載ヘッダ例のcreatedとexpiresは3,600秒、つまり60分離れています。例の値をコピーすると、その規則を満たしません。[2]

表記にも差があります。ヘッダ例の一部はkeyId、必須項目表はkeyidです。顧客情報は表でidToken、例でIdTokenとなっています。また、掲載されたオブジェクト例には、そのままではJSONとして成立しない区切りの欠落があります。[2]

紹介ページは識別情報をクエリパラメータで受け取る説明を含む一方、仕様本文は顧客情報と支払い情報をリクエスト本文に置く説明です。これは公式資料間の違いとして残す必要があります。都合のよい項目だけを組み合わせ、完成した通信例として扱うことはできません。[2][3]

署名方式も、ヘッダ例はEd25519、顧客・支払い情報の例はPS256です。支払い情報のハッシュは例のpaymentCredentialsHashと節名のcredentialHashで名前が異なります。この記事のヘッダ抜粋は閲覧用の例だけに限定しています。支払いまでつなぐ際に、これらを独自に同じ名前や方式へ揃えないようにします。[2]

そのため、本記事では検証済みのリクエストや架空の有効な署名を掲載していません。公式仕様は公開鍵の場所としてhttps://mcp.visa.com/.well-known/jwksを示しています。店はここから鍵の一覧を取得し、通信のkeyidと一致する鍵を選びます。[2]実接続、署名検証、相互接続、実決済も未実施です。

7. Web Bot Authとの関係と、自店での検討範囲

Visaの仕様は、AI認識の署名について、HTTP Message SignaturesのRFC 9421を基にし、Web Bot Authと整合すると説明しています。RFC 9421は通信に署名するための土台として参照され、TAPは買い物の用途や顧客・支払い情報との関連づけを記述しています。同一の規格として扱うことはできません。[2]

また、Visaの紹介ページにある「標準」という表現だけで、TAP全体が標準化団体の最終承認を受けたとは判断できません。仕様本文には提案としての記述があり、紹介ページには開発・展開中で、図示した機能や流れは潜在的なものだという注意があります。[2][3]

日本の店舗の参加条件、利用可能な保護サービス、料金、申込後の設定画面は、今回の公式資料では確認できません。利用経路が存在しないという意味ではなく、この資料だけでは導入を約束できないという範囲です。

自店との関係は、次の三点で考えられます。

• 買い物を進めるAIのアクセスを、署名で確かめて受け入れたい場合は、TAPが関係します。
• AIに商品を掲載したい場合は、商品情報を届ける連携が別途必要です。
• AIからの注文を成立させたい場合は、本人の許可、注文内容、支払い結果を扱う仕組みが別途必要です。

TAPは、店がAIを受け入れる際の確認材料を増やす仕組みです。承認されたAIだと確認することと、その買い物を許可し、代金を受け取り、注文を成立させることを分けると、既存のEC機能に何が残るかを判断できます。[2]