EvervaultのBrowser Tokens。送信先の制限と支出上限は別に確認

自社に関係する？

カード番号をAIに見せない仕組みがあっても、勝手な支出を防ぐ仕組みまでそろうとは限りません。自社でAIの購入導線を作る場合や、外部AIからの注文を受ける場合に、何を制限できるのか確認するための話です。

Evervaultは10月19日付の公式ブログでBrowser Tokensを発表しました。カード番号やパスワードの代わりとなる値をブラウザへ渡し、送信時に本来の値へ置き換える製品です。店舗側が新しい購入用プロトコルを導入せず、既存の画面で利用できると同社は説明しています。個別の店舗での動作保証とは分けて読みます。

情報の送信先を絞る仕組み

公式開発資料では、本来の値を送ってよいホスト名と、有効期限を設定します。たとえば店舗本体と決済代行会社で送信先が異なる場合、実際に情報を受け取る先の確認が必要です。

一方で、有効時間内なら同じトークンを複数回使えるため、使い切りではありません。また、この通信の仕組みが支出上限を強制するわけではなく、取引の承認はカード発行会社や決済処理側に残ります。送信先の制限を、そのまま購入金額や回数の制限として扱いません。

追加認証や費用は別に確認する

公式資料は、3Dセキュアの追加認証や多要素認証では、利用者による操作やブラウザの引き継ぎが通常必要と説明しています。「カード番号を見せない」ことと、「人が関与せず購入が完了する」ことは別です。

製品ページは、テスト用Sandboxを条件付き無料、本番はProプランでカードセッション0.25ドル、認証情報セッション0.05ドルと表示しています。各セッション25MBを含み、住宅回線のプロキシは追加費用としています。注文1件の総費用や、決済手数料を含む価格ではありません。Proプラン全体の契約費用、税、国内向け見積もりは今回未確認です。

国内ECとの関係

立場・機能	確認日2026-10-23時点の区分
日本の販売者 × 商品発見	商品の推薦・フィード登録を提供する発表ではない
日本の販売者 × 決済	既存フォームで使う製品。国内店舗・決済代行会社の受け入れ条件と動作は未確認
日本の購入者 × 商品発見	日本向けの商品検索機能は今回の対象ではない
日本の購入者 × 決済	日本のカード・円決済・追加認証での実動作、利用資格や契約条件は未確認

公式は利用可能と説明していますが、日本向けの一般公開・限定提供・申請制・提供予定は確認できていません。国内の導入実績、需要、購入成功率や売上効果も未確認です。

今やること — 編集部の提案

導入の検討表では、情報を送ってよい先、購入者の承認と支出上限、追加認証への引き継ぎ、店舗の注文受付を別の確認項目にすることを提案します。期限内に再試行する際も、すでに注文が成立していないかを確認する工程が必要です。これは編集部の業務設計の提案で、本製品の動作検証結果ではありません。

自社の決済代行会社や利用規約に照らした受け入れ条件も確認します。BrowserlessとLinkの連携条件には別の地域・金額・承認条件があり、Evervaultへ同じ条件を流用しません。商品情報の準備はEC担当者の準備ガイドも参照できます。

技術的な補足と出典

本来の値への置き換えはEvervaultのプロキシを通る通信で行われます。カード情報が届く範囲を減らす設計と、自社システム全体のPCI DSS対応判断は分けて確認します。本誌は認証、カード入力、注文、取消、規格への適合性を検証していません。

• Evervault公式発表：表示日2026-10-19。公開時刻・JST換算は未確認。確認日2026-10-23。
• 公式製品ページ：提供とセッション単価の表示を照合。確認日2026-10-23。
• 公式開発資料：送信先、有効期限、単回利用との違い、支出・追加認証の制約を照合。確認日2026-10-23。