Evervaultが「Browser Tokens」を発表、AIエージェントにカード番号を渡さず既存ECサイトで決済させる仕組みとPCI DSS
EvervaultのBrowser Tokensは、AIエージェントに本物のカード番号を見せずに既存サイトで決済させる仕組みです。トークン化の方式、PCI DSSの範囲、Visa・Mastercardとの違い、EC事業者の確認点を解説します。
この記事のポイント
- 決済データ基盤のEvervaultが2026年10月20日、AIエージェントに本物のカード番号やパスワードを渡さずに既存のECサイトで決済やログインをさせる「Browser Tokens」を発表しました
- VisaやMastercardのエージェント向けトークンはイシュアと加盟店の双方の対応が前提だが、Browser Tokensは加盟店側の改修なしで動くネットワーク非依存の互換レイヤーとして位置づけられています
- エージェントの通信を通常のブラウザに見せる設計のため、EC事業者にはエージェントと判別できない注文が増える可能性があり、ボット対策と不正検知の方針を見直す材料になります
Money20/20で発表された「代わりのカード番号」
EvervaultのBrowser Tokensにより、AIエージェントは実際のカード情報やパスワードを見ることなく、加盟店サイトで支払いやログインができるようになります。
thepaypers.comラスベガスで開かれた決済業界の展示会Money20/20の会期中、EvervaultはBrowser Tokensの提供開始を発表しました。AIエージェントやブラウザ自動化ツールが、カード番号、パスワード、個人情報を一度も目にしないまま、購入やログインを完了できるようにする製品です。
Evervaultは2019年創業で、機密データを暗号化したまま処理する開発者向け基盤を提供し、Ribbit Capital、Sequoia、Indexが出資しています。Browser Tokensの最初の利用企業として名前が挙がったのは、法人カードのRampとNaturalの2社です。製品はすでに既存顧客向けに稼働しており、新規の開発者も無料で試せます。公式ブログによると、テスト用のサンドボックスは無料で、本番利用はProプランでカード1セッションあたり0.25ドル、パスワードなどカード以外のデータは1セッションあたり0.05ドルからです。Proプラン自体の基本料金や、日本での提供条件は発表に含まれておらず未開示です。
ブラウザエージェントは決済フォームで立ち止まる
選択も入力も終えたエージェントが、支払いフォームの前で止まる。EvervaultのCEO、Shane Curran氏がブログの冒頭で描いたのはそうした場面です。理由は単純で、ユーザーのカード番号をエージェントに渡すのが危険だからです。モデルに渡した情報は、ログや他社のサーバーに残る可能性があります。エージェントをだますために作られたWebページ（プロンプトインジェクション）に読み取られる恐れもあります。
もう一つの壁がPCI DSSです。カード業界が定めたセキュリティ基準で、カード会員データを保存、処理、送信するシステムはすべて審査の対象範囲に入ります。エージェントに生のカード番号を持たせると、エージェントのコード、利用するAIモデルの提供元、ヘッドレスブラウザ（画面を持たないブラウザ）の事業者、ログ基盤まで範囲が広がります。Evervaultのドキュメントは、モデル提供元やブラウザ自動化基盤の多くはPCI DSSに準拠しておらず、この方法は現実的ではないと指摘しています。
これまでの回避策にも代償がありました。ブラウザ事業者の保管庫に預ければプロンプトには出ませんが、ブラウザ事業者が機密データの経路に入り、Chrome DevTools Protocol経由で値が漏れる余地が残ります。バーチャルカードを使えば、ユーザーは自分のカードのポイントを失います。
仕組み：トークンはブラウザの外で本物に戻る
Browser Tokensの発想は、エージェントには最後まで偽物だけを扱わせ、本物への差し替えはネットワークの上で行うというものです。中心にあるのがフォーマット保持型トークンと、Evervaultが運営するブラウザプロキシの組み合わせです。
流れを追ってみます。まず、ユーザーのカード情報をEvervaultのカード入力部品で受け取って暗号化し、開発者のデータベースには暗号化済みの値だけを保存します。次に、エージェントの作業が始まる直前に、暗号化済みの値と「どのホストに本物を渡してよいか」というルールをAPIに送り、トークンを発行します。
返ってくるトークンは、本物と同じ形をした別の番号です。カード番号のトークンは桁数とBIN（カード番号の先頭6桁で、ブランドや発行会社を示す部分）を保ち、チェックサムであるLuhnの検算も通ります。加盟店の決済フォームは正しいブランドのカードとして受け付けます。CVVも桁数を保ち、有効期限は通常そのまま渡します。
エージェントはこのトークンをフォームに入力し、普段どおり送信します。ブラウザの通信はEvervaultのプロキシを経由する設定になっており、許可リストに載ったホスト宛てのリクエストだけ、トークンが本物の値に置き換えられて送り出されます。加盟店やその決済代行会社は、本物のカード番号を受け取って通常どおりオーソリを行います。
許可リストにないホストへ送られた場合、プロキシは通常の中継に徹し、値を差し替えません。悪意あるページがエージェントをだましてカード番号を送らせても、そのページに届くのは使い道のない代わりの番号です。
設計上の要点はさらに3つあります。
一つ目は、Evervault側にトークンと本物の対応表を持たないことです。暗号化された値は期限付きのJWE（JSON Web Encryption）に埋め込まれてプロキシの認証情報となり、プロキシはそこから、どの値をどのホストにいつまで渡せるかを読み取ります。侵害される保管庫そのものがないという主張です。
二つ目は、権限の固定です。許可するホスト名、有効期限（既定は15分）、扱うデータの種類はトークン発行時に決まり、後から開発者のコードもエージェントも広げられません。値の開示と拒否はセッションごとに記録されます。
三つ目は、パスワードにも使える点です。エージェントに代わりのパスワードを渡して加盟店サイトの会員アカウントにログインさせ、そこに保存済みのカードで支払わせる使い方が想定されています。
ただし、通信の中身を書き換える以上、ブラウザ側には準備が要ります。HTTPS通信の途中で値を差し替えるため、EvervaultのCA証明書をブラウザの信頼済みルート証明書に登録する必要があります。対応環境はChromium系で、PlaywrightやBrowserbaseなど開発者向けのブラウザ基盤が挙げられています。一般消費者向けのAIブラウザへの対応は、今回の発表には含まれていません。
ネットワークトークンやSPTとの違い
エージェント決済で「カード番号を見せない」仕組みは、Browser Tokensが初めてではありません。違いは、誰がトークンを発行し、加盟店に何を求めるかにあります。
| 方式 | トークンの発行元 | 加盟店に求めるもの | 主な制約 |
|---|---|---|---|
| Browser Tokens（Evervault） | Evervault（本物と同じ形式の代替値） | 改修不要 | ブラウザにEvervaultのCA証明書を登録する必要がある。利用上限額などの統制機能は開発中 |
| Visa Intelligent Commerce / Mastercard Agent Pay | カードネットワーク | 加盟店とイシュアの対応 | Evervaultの説明では現状の対象は米国の個人向けクレジットカード。ブランドごとに個別の統合が必要 |
| Shared Payment Token（Stripe・ACP） | Stripe | ACPへの対応 | 特定の加盟店とカート金額に紐づけて発行される |
| バーチャルカード | カード発行事業者 | 改修不要 | ユーザーは自分のカードのポイントを失う。利用地域は発行事業者の対応範囲に限られる |
| ブラウザ事業者の保管庫 | なし（ブラウザ事業者が本物の値を保持） | 改修不要 | ブラウザ事業者が機密データの経路に入り、Chrome DevTools Protocol経由の漏えい余地が残る |
Visa Intelligent CommerceやMastercard Agent Payは、カードネットワーク自身がエージェント購入用のトークンを発行する方式です。Evervaultはブログで、これらはユーザーの銀行と加盟店の双方が対応していなければ使えず、現状の対象は米国の個人向けクレジットカードだと説明しています。ただし、これは代替手段を売る側からの評価である点には注意が必要です。
StripeとOpenAIが共同開発したAgentic Commerce Protocol（ACP）では、Stripeの発表によると、Shared Payment Token（SPT）が特定の加盟店とカート金額に紐づいて発行され、エージェントはそのトークンを加盟店にAPIで渡します。安全性の考え方は近いものの、加盟店がACPに対応して注文を受け取る仕組みを用意する必要があります。
Browser Tokensは、加盟店にもネットワークにも何も求めない点で性格が異なります。Curran氏は「エージェント決済は、ただの決済だ」と述べ、加盟店が新しい規格を採用するのを待たずに、今あるカードとWebサイトのまま動くことを強調しています。裏返せば、加盟店が何の協力もしないまま、エージェントによる決済が成立する仕組みでもあります。
加盟店から見えない買い物客という論点
この製品には、EC事業者として見過ごせない一面があります。Evervaultのブログは、加盟店から見れば通常のログインと通常のカード決済にしか見えず、Evervaultが関与したことを加盟店は知らないと説明しています。
通信そのものも人間の買い物に見えるよう作られています。ドキュメントによれば、プロキシはTLSとHTTPのクライアント偽装技術でJA4などのネットワーク指紋を通常のブラウザと一致させます。ブログも、住宅用プロキシを使えば加盟店の不正チェックにエージェントがはじかれないと書いています。
業界の別の流れとは、向きが逆です。Visaは2025年10月、Cloudflareと共同開発したTrusted Agent Protocolを公開しました。エージェントが暗号署名で身元と購入意図を示し、加盟店が正規のエージェントと悪意あるボットを区別できるようにするもので、VisaはこれをVisa Intelligent Commerceに組み込むとしています。Cloudflareの発表によれば、MastercardもAgent PayにWeb Bot Authを組み込み、加盟店が信頼できるエージェントを識別できるようにしています。
この対比を突いたのが、エージェント経済を扱うメディアForkastの論評です。金融機関が懸念しているのはカード情報の盗難そのものより、検証できる購入意図がないことであり、エージェントを人間に見せかける機能はむしろ負債になりうると論じています。
統制機能がまだそろっていない点も留保に値します。製品ページでは、利用上限額、人による承認の閾値、セッションの強制停止、加盟店業種の制限が「開発中」とされており、提供時期は未開示です。ドキュメントも、トークンは使い捨てではなく有効期限内なら複数回使えること、取引の承認はあくまでイシュアと決済代行会社に委ねられることを明記しています。3Dセキュアの追加認証やMFAが求められた場合は、人が介入する必要があります。
PCI DSSの範囲縮小も無条件ではありません。連携先のBrowserbaseのドキュメントは、自動的に準拠になるわけではなく、範囲はログやスクリーンショットを含む実装全体で決まると注意を促しています。
EC事業者が今確認しておきたいこと
Browser Tokensの利用者は、エージェントを開発する事業者です。EC事業者は導入する側ではなく、その注文を受け取る側に立ちます。そのうえで、確認しておきたい点が三つあります。
まず、自社のボット対策が何を止めているかです。ネットワーク指紋や住宅用IPまで人間に近づけたエージェントは、従来の判定では見分けにくくなります。エージェント経由の注文を受け入れるのか、どの条件で止めるのかという方針を、技術任せにせず決めておく必要があります。
次に、不正検知とチャージバックの扱いです。Browser Tokens経由の注文では、エージェントが関与した事実が加盟店側の記録に残りません。ユーザーが後から購入を認めていないと申し立てても、加盟店はそれを確かめられない構造です。高額商品では、配送先や購入頻度など既存のルールがどこまで機能するかを点検しておきたいところです。
最後に、エージェントが身元を名乗って入ってくる経路を用意することです。Trusted Agent ProtocolやACPに対応すれば、見えない注文と名乗る注文を分けて扱えるようになります。会員アカウントへの代理ログインを利用規約でどう扱うかも、あわせて整理しておきたい論点です。
まとめ
Browser Tokensは、カードネットワークの対応を待たずに今のWebでエージェント決済を成立させる、実務寄りの解決策です。カード情報をエージェントから切り離す設計としては筋が通っています。
一方で、エージェントを名乗らせる方向と、人間に見せる方向という二つの流れが同時に進んでいることも浮き彫りになりました。利用上限額などの統制機能がいつ提供されるか、そしてネットワーク側の識別プロトコルとどう折り合うかが、次に注目すべき点です。
