30年ぶりに決済プロトコル戦争が帰ってきた──SETからAIエージェント決済へ

最終確認：2026年9月26日

1995年、Visa・Mastercard・Microsoft・Netscapeは、Web上でカードを安全に使うための共通仕様をめぐって競い合いました。同時代のInternet-Draftには、実際に“Protocol Wars”という見出しが残っています。

30年後の2026年、今度はAIエージェントが人間に代わって購入するための標準化が進んでいます。焦点はカード番号そのものではなく、「このAIは、誰から、何を、どこまで買う権限を与えられたのか」を機械が検証できるようにすることです。

本稿では、STT・SEPP・SETからAP2・ACP・Visa TAP・Verifiable Intent・EMVCo Intent Servicesまでを一次資料でつなぎ、30年前と現在で何が同じで、何が変わったのかを整理します。決済史シリーズ全体は「決済の歴史としくみ」Hubから確認できます。

この記事で出てくる主要用語

用語	役割	時期
STT	VisaとMicrosoftが進めたInternet card-payment protocol	1994–95
SEPP	Mastercard・IBM・Netscape等が進めた別系統の仕様	1995
SET	STT / SEPPを統合したPKIベースのカード決済仕様	1996–97
AP2	AIへの委任・mandateを扱うsecurity / coordination layer	2025–
ACP	AIと加盟店のcommerce / checkout interactionを標準化	2025–
Visa TAP	加盟店側でtrusted agentを認識する仕組み	2025–
Verifiable Intent	人間の委任をportableな暗号学的証拠にするtrust layer	2026–
EMVCo Intent Services	consumer-authorised intentの共有状態を扱うdraft concept	2026–

STT / SEPP / SETと、AP2 / ACP / TAP / Verifiable Intent / Intent Servicesは役割と時代が異なる。特に2026年の各initiativeは同一レイヤーの直接代替ではない。

30年の流れ

年	出来事	意味
1994–95	Visa / Microsoft STT、Mastercard側SEPP	Web決済の非互換仕様が競合
1995年12月	共同標準化へ合意	二重実装コストと相互運用性が統合圧力に
1996–97	SET	強いsecurityと引き換えに大きなdeployment burden
2025年	Agent Pay / Visa Intelligent Commerce / AP2 / ACP / TAP	AI agent向けのcommerce・trust・credential層が登場
2026年3–5月	Verifiable Intent / FIDO標準化 / 日本production事例	「委任の証拠」が独立した標準化テーマに
2026年9月	EMVCo Agentic Payments Framework DRAFT	Intent Servicesという共有・相互運用layerを提案

1995年の非互換なWeb決済仕様から、2026年の委任・Intentを扱う複数レイヤー型の標準化までを対比する。

1995年11月、インターネット技術者が書いたInternet-Draftに、少し物騒な見出しが登場する。

“Protocol Wars”――プロトコル戦争。

そこで名指しされていたのは、VisaとMicrosoftが進めていたSTT（Secure Transaction Technology）と、MasterCard、IBM、Netscape、CyberCashなどが進めていたSEPP（Secure Electronic Payment Protocol）だった。

当時、Webは急速に広がっていた。しかし、そこでカード番号を入力し、見知らぬ加盟店へ送ることを人々が本当に信用するのかは分からなかった。

問題は単に「暗号化すればよい」ではなかった。

誰がカード会員を認証するのか。誰が加盟店を認証するのか。どのソフトウェアがその処理を行うのか。銀行やカード会社の既存システムへどう接続するのか。そして、その仕組みを世界中のWebサイトとPCへ誰が配るのか。

30年以上たった2026年、よく似た問いが再び現れている。

今度の主役はブラウザではない。AIエージェントである。

人間が「Buy」ボタンを押さず、AIが商品を探し、条件を比較し、場合によっては人間が画面の前にいないまま購入する。そのとき決済システムは、カード番号だけでなく、もっと難しい問いに答えなければならない。

「このAIは、本当にこの人から、ここまで買ってよいと頼まれたのか。」

1995年のProtocol Warsと、2026年のagentic commerce。二つを並べると、決済の次の主戦場が見えてくる。

VisaとMicrosoftは、何を作ろうとしていたのか
Mastercard側はSEPPで対抗した
SETは「負けた技術」だったのか
そして30年後、今度はAIが「Buy」を押す
AP2が作っているのは「AIの委任状」
ACPは「加盟店を作り直さない」
Visaはmerchantに「そのAIを信用してよいか」を伝える
Verifiable Intentは「本人の意思」をportableな証拠にする
2026年、AP2とVerifiable IntentはFIDOへ
EMVCoも「Intent Services」という共通レイヤーを提案した
日本では「本番」「商用」「準備」を分けて見る必要がある
30年前との最大の違い
次の決済の主戦場は「決済網（rail）」ではなく「委任」かもしれない
主要出典
1. 1994–2001：Internet payment Protocol Wars
2. 2025–2026：Agentic Commerce
あわせて読みたい
1. 関連

VisaとMicrosoftは、何を作ろうとしていたのか

1994年11月、VisaとMicrosoftはInternet上のカード取引を安全に行う技術の共同開発を発表した。翌1995年4月16日の両社のSTT Agreementを見ると、その狙いは「セキュリティ向上」だけではなかったことが分かる。

契約書でVisaは、electronic commerceにおけるVisaのpositionを維持・強化すること、Visa製品を有利にpositioningすること、そしてVisaと加盟金融機関のpayment-services leadershipを強めることを目的に掲げていた。

Microsoft側にも、secure network financial transactionsでのbrand recognition、incremental revenue、Microsoft systems/softwareの競争力強化という目的が並ぶ。

つまり両社が作ろうとしていたのは、単なる暗号化方式ではない。

Visaはカードネットワークを持ち、MicrosoftはPCのソフトウェア配布力を持つ。その二つを組み合わせ、Internet commerceのcard-payment interfaceを標準化しようとしていた。

ただし「Microsoft専用の秘密プロトコル」だった、と単純化するのも正しくない。契約上、STT specification自体はplatform-independentで、software vendorが実装できるopen specificationを意図していた。一方で、MicrosoftはConsumer Client、Merchant Server、Payment ServerなどのSTT準拠softwareを開発し、初期実装ではWindows 95 / Windows NTが中心だった。

open specificationと、実装・配布を握る企業の経済利益は両立していた。

この構図は、後のInternet標準を考えるうえで非常に重要である。

Mastercard側はSEPPで対抗した

MasterCard側が問題視したのは、カードブランドの対立だけではなかった。

2001年の米連邦地裁判決が整理した当時の経緯によると、MasterCard CEOのEugene Lockhartは、STTが本当にopenなのかを疑問視していた。WindowsのAPIが十分に公開されず、結果としてMicrosoft applicationが有利になるのではないかという懸念だった。

そこでMasterCardはIBM、Netscape、CyberCash、GTEなどと別の仕様、SEPPを進める。

1995年11月のUniversal Payment PreambleというInternet-Draftは、この状況をそのまま“Protocol Wars”と呼び、STTとSEPPが互換性を持たないことを問題にした。

これは後世のライターが面白くするためにつけた名前ではない。同時代のInternet-Draft自体が、非互換な決済protocolの併存を“Protocol Wars”と表現していた。

しかし二つの規格が併存すると、困るのはカード会社だけではなかった。

VisaとMasterCardの両方を扱う銀行は二つの規格を実装しなければならない。加盟店も二種類に対応する。consumer softwareも両方を理解する必要がある。

2001年の連邦地裁判決は、このduplicate costが業界に大きな圧力をかけたと認定している。

そして1995年12月、VisaとMasterCardはSTTとSEPPの個別開発を停止し、共同標準を作ることに合意した。

それがSET（Secure Electronic Transaction）である。

STTがSEPPに勝ったのでも、SEPPがSTTを倒したのでもない。

二重実装コストは統合圧力の重要な一因となり、STTとSEPPは共同標準化へ向かった。

SETは「負けた技術」だったのか

SETは、技術としては非常に野心的だった。

カード会員と加盟店にはdigital certificateを持たせ、Certificate Authorityを使って相手を認証する。payment gatewayを介し、カード番号などのpayment informationを加盟店へ不必要に見せずに済む。order informationとpayment informationを暗号学的に結び付ける仕組みも持つ。

今読んでも、よく考えられている。

では、なぜSETはWeb決済の標準にならなかったのか。

2001年の米連邦地裁判決は、SETがwide-scale implementationに至らないcommercial failureだったことを記録し、その主要因の一つとしてSSLの成功を挙げている。

SSLなら、consumerとmerchantはissuer、acquirer、card association全体を新しいcertificate infrastructureへ移行させなくても、ブラウザとWeb server間の通信を暗号化できた。

銀行や加盟店から見れば、SETのために新しいwallet、certificate、CA、gatewayへ投資しても、そのコストをfraud削減や売上増で回収できるかは分からない。

ここで重要なのは、

SETが広がらなかった理由は、securityの弱さよりdeployment burdenにあった。

ということである。

少なくとも決済標準の普及では、技術的に最も精緻な仕組みがそのまま広がるとは限らない。

既に存在するbrowser、server、merchant systemへどれだけ小さい追加コストで接続できるか。SETの事例は、cryptographyだけでなくinstalled baseとdistributionが普及に大きく影響することを示している。

そして30年後、今度はAIが「Buy」を押す

2025年から2026年にかけて、決済業界で再びprotocolやframeworkが相次いで登場した。

2025年4月29日にMastercardはAgent Payを発表。翌30日、VisaはVisa Intelligent Commerceを発表した。

9月にはGoogleがAgent Payments Protocol（AP2）、OpenAIとStripeがAgentic Commerce Protocol（ACP）を公開する。10月にはVisaがTrusted Agent Protocol（TAP）を発表した。

なおAP2の正式名称には版による表記差がある。2025年9月16日のv0.1 releaseは Agent Payments Protocol と表記する一方、現行v0.2 specificationの見出しは Agentic Payment Protocol である。本稿では略称AP2を用い、名称の違いを同一版のものとして混同しない。

一見すると、30年前と同じ「決済標準戦争」に見える。

しかし、ここで重要な違いがある。

AP2とACPとVisa TAPとMastercard Agent Payは、同じものを奪い合う四つの規格ではない。

2026年のagentic commerceでは、かつてSETが一体で解こうとした問題が、複数のlayerへ分解され始めている。

大まかにはこうなる。

図1　Agentic Commerceは一つの規格ではなく、複数レイヤーで動く

Human intent
人間が何を許可したか

↓

Commerce / Checkout
ACP・UCP

↓

Delegation / Mandate
AP2

↓

Intent Evidence
Verifiable Intent

↓

Agent Recognition
Visa TAP など

↓

Payment Credential / Rail
既存tokenization・PSP・card / account rail

各initiativeは同じ層の直接代替ではない。2026年の競争は、複数の層をどう相互運用させるかが中心になっている。

この違いを理解すると、2026年の決済競争がかなり見やすくなる。

AP2が作っているのは「AIの委任状」

Googleが公開し、2026年4月にVerifiable IntentとともにFIDO Allianceへ初期提案（initial contribution）として提供されたAP2 v0.2は、自らをCommerce Protocolの中で動くsecurity featureと定義している。

つまり商品検索やcart APIそのものを標準化するprotocolではない。

AP2の中心にあるのはMandateである。

Checkout Mandateは「何を、どの条件で購入するのか」を表す検証可能なmandate。

Payment Mandateは「そのcheckoutに対して、どの金額・手段・条件で支払うのか」を表すmandateである。

二つはcryptographic hashで結び付けられる。

そしてAP2が特に面白いのは、取引を二つに分けていることだ。

一つはHuman Present。人間が画面の前にいて、具体的なcheckoutを確認して承認する。

もう一つがHuman Not Present。人間が事前に条件を指定し、その後はAIが人間不在のまま購入する。

たとえば、

「この靴が100ドル以下になったら買ってよい」

「コンサートのチケットを1000ドル以内で、できるだけステージに近い席なら購入してよい」

といった指示である。

このとき人間は最初にopen mandateへ署名し、AIはその条件に合う具体的な取引を見つけるとclosed mandateを作る。

決済システムが確認するのは「AIが賢いか」ではない。

AIが、人間から与えられた制約の中で動いたかどうかだ。

これは従来のe-commerceにはなかった新しいauthorization problemである。

ACPは「加盟店を作り直さない」

OpenAIとStripeが共同開発したACPは、別の場所を解こうとしている。

ACPのofficial RFCは、merchantをorders、payments、taxes、complianceのsystem of recordとして残すことを明記する。

payment authorizationとsettlementもmerchantが今使っているPSPで行う。

AI platformはcheckoutをorchestrateするが、merchantの基幹systemやPSPを丸ごと置き換えるわけではない。

さらにdelegated payment tokenは、merchant、checkout session、最大金額、通貨、有効期限などで利用範囲を限定できる。

これはSETとの対比で非常に面白い。

SETはInternet card paymentを成立させるため、cardholder、merchant、gateway、CAなど広いecosystemへ新しい仕組みを要求した。

ACPは逆に、

「今あるmerchant stackとPSPを残したまま、agentが入れるinterfaceを追加する」

方向を強く打ち出している。

もちろんOpenAIやStripeが「SETの失敗から学んだ」と説明しているわけではない。その因果を断定する資料はない。

しかしarchitectureとして見ると、30年前との対照は鮮明である。

Visaはmerchantに「そのAIを信用してよいか」を伝える

VisaのTrusted Agent Protocolは、また別の問題を扱う。

AI agentがmerchant siteへアクセスしたとき、加盟店から見れば、それが正規の購買agentなのか、普通のcrawlerなのか、在庫を買い占めるbotなのか、攻撃者なのかは見分けにくい。

Visa TAPは、既存HTTPの上でRFC 9421のHTTP Message Signaturesを使い、merchantがagentをcryptographically verifyできるようにする。

仕様は三つのsigned objectを中心にしている。

agent recognition signature — これは信頼されたagentか。
consumer/device identity — 誰の代理で動いているか。
payment container — どのpayment informationと結び付いているか。

しかもVisaは、TAPがWeb/APIだけでなくACPやMCPのようなprotocolとも共存できると明記している。

つまりVisaが作ろうとしているのは「Visaだけの新しいInternet」ではない。

公開仕様上、TAPが位置するのは、どのagent interfaceから来ても、merchantとpayment ecosystemが信頼できるagentを認識するagent-recognition layerである。

Verifiable Intentは「本人の意思」をportableな証拠にする

MastercardがGoogleと共同開発し、2026年3月に公開したVerifiable Intentは、さらに興味深い。

Verifiable Intentはidentity、intent、actionを一つのtamper-resistant recordへ結び付ける。

つまり、

「誰がAIへ頼んだのか」

「何を頼んだのか」

「AIはmerchantと何をして、何を買ったのか」

を、後から検証できる形で残す。

MastercardはこれをMastercard networkだけに閉じた仕様ではなく、AP2/UCPと整合し、異なるprotocol、wallet、platform、さらには他のpayment networkでも使えるprotocol-agnostic trust layerとして説明している。

さらにdisputeが起きた場合、関係者が同じaudit trailを使って「何がauthorizedされていたか」を確認できることを狙う。

2026年9月9日にはMastercardがAgent Connectを発表した。merchant、AI agent、digital platform、payment providerを一つのintegrationでつなぐ構想で、secure payment credentialについては特定networkだけに限定せず扱う方針を示す一方、Mastercard Agent PayではVerifiable Intentをconsumer authorizationの証拠として組み込むとしている。

ここは3-D Secureの歴史と比較したくなるところだ。

ただし、現時点では重要な注意がある。

Agentic Paymentsに3DSのようなliability shiftが既に設定された、と確認できる公開一次資料は見つかっていない。

一方、Visaの2026年4月18日付公開Rulesでは、Agentic Platform向けにかなり具体的な要件がすでに置かれている。Agentic Payment Providerは、credentialをtoken化して利用することへのcardholder consentを取得し、cardholderが定めた購入条件・有効期限を明示し、本人確認を行い、agentic providerがcardholderの指示に従って行う行為についてcardholderのacknowledgementを取得することが求められている。

さらに§4.1.24.10 Agentic Payment Provider – Cardholder Responsibility は、Agentic Transactionの一部としてAgentic Payment Providerが行った行為について、Cardholderは自らそのTransactionを開始した場合と同様にresponsibleであると規定している。

これはagentic commerceが単なる「実証」ではなく、scheme rulesの運用対象になり、少なくともcardholderとagentic providerの関係について責任原則が置かれ始めていることを示す。

ただし、ここは3-D Secureと混同してはいけない。

VisaのCardholder Responsibility条項と、fraud dispute / chargebackにおけるmerchant・acquirer・issuer間のliability shiftは同じ概念ではない。 今回レビューした公開Rules・公開資料からは、3-D Secureのように「所定のagentic authentication/evidenceを満たせばmerchant側のfraud liabilityがissuer側へ自動的にshiftする」という専用mechanismまでは確認できなかった。

AP2やVerifiable Intentが作っているのは、まず「誰が何をauthorizedしたかを判断するための証拠」である。

その証拠を将来のchargeback ruleやscheme liabilityへどう結び付けるかは、今後の重要な観測点になる。

2026年、AP2とVerifiable IntentはFIDOへ

2026年4月28日、FIDO Allianceはagentic authenticationとagent-initiated commerceの標準化作業を発表した。

GoogleはAP2を、MastercardはGoogleと共同開発したVerifiable Intentを初期提案として提供した。

重要なのは、FIDO自身がその後の解説で、二つの役割を明確に分けていることである。

AP2はMandate / Coordination Layer。

Verifiable IntentはEvidence Layer。

AP2が「誰が、誰の代理で、何を、どこまで許可されたか」を定義して伝え、Verifiable Intentがその承認をportableで独立検証可能な証拠にする。

これは2026年のProtocol Warsが、1995年とは少し違う方向へ向かっていることを示している。

30年前はSTTとSEPPという非互換のpayment protocolが並び、最後はSETへ一本化した。

今回は、異なるlayerを分け、RFC 9421のHTTP Message Signaturesのような既存標準部品も再利用しながら、相互運用性を作ろうとしている。

ただし、これを「標準化は終わった」と理解してはいけない。

2026年9月時点でもFIDOはdeveloping specificationsの段階であり、AP2とVerifiable Intentはinitial contributionsである。ACPもofficial repositoryではbetaと表示されている。

勝者はまだ決まっていない。

EMVCoも「Intent Services」という共通レイヤーを提案した

2026年9月1日、EMVCoはEMV Agentic Payments – Framework for Specifications v1.0 DRAFTを公開し、9月30日までpublic reviewを開始した。

ここでEMVCoが着目したのも、人間のintentである。特に定期購入、累積budget、取引後処理のように、委任された意思を一回のtransactionだけでなく時間をまたいで管理するケースでは、複数participantが同じintent stateを参照できる仕組みが必要になる。

そこでdraftが提案するのがIntent Servicesだ。consumer-authorised intentを取引前・取引中・取引後にregister、reference、retrieve、manageする共有・相互運用レイヤーである。EMVCoはこれを、Verifiable Intentなどが提供するcryptographic assuranceを補完するcommon coordination pointとして説明している。

さらに将来の検討対象として、Know Your Agent（KYA）、Agentic Transaction Indicators、EMV 3-D Secure、Payment Tokenisation、Secure Remote Commerce、Digital Payment Credentialとの連携可能性も挙げている。

これは、カードnetwork側の標準化がcredential処理だけではなく、delegated intentをecosystem全体でどう解釈するかという領域へ広がり始めていることを示す重要な一次資料である。

ただし、2026年9月26日時点ではあくまでDRAFT / public review中であり、final EMV specificationでも、liability ruleでもない。

日本では「本番」「商用」「準備」を分けて見る必要がある

日本でもagentic commerceは動き始めている。ただし「本番」と一括りにすると実態を誤る。2026年9月26日時点の一次資料を、成熟度で分けると見え方が変わる。

P1 — 本番取引：Mastercard Agent Pay Japan

Mastercardは2026年5月20日、同社の定義で日本市場初の本番環境（production-site environment）でのagentic transactionを完了したと発表した。

AI agent AgenzoがELifeを通じて送迎予約を行い、三菱UFJニコス発行カードを含むMastercard credentialを使用。tokenized credentialはMastercard Payment Passkeysで認証された。

これは現時点で、日本のcard railにおける最も明確なproduction transaction evidenceの一つである。ただし「日本初」はMastercardの発表範囲に帰属させ、agentic payment全般の客観的な市場初認定とはしない。また一件の本番事例からtransaction volumeや普及率を推定することもできない。

P1/P2 — machine-nativeな実決済：OpenPay x402 + JPYC

もう一つ性質の異なるproduction evidenceが、OpenPayのx402 + JPYCである。

OpenPayは2026年6月28日にx402 facilitatorを本番公開し、AI agentが有料API、データ、コンテンツをJPYCで1 request単位に購入できる仕組みを提供している。代金はseller walletへ直接settleされ、signed receiptも発行される。

さらに同社は、第三者serviceへの実際のx402 purchaseについてon-chain transactionまで公開している。2026年7月の例では、AI assistantがCoo-ICPのconsultationを2 JPYCで購入し、HTTP 402 → JPYC payment → content unlockの一連の流れを外部から検証できる。

これはmass-market retailのカードcheckoutではなく、beta段階の少額machine paymentである。しかし「AIがmachine-readable serviceを実際に買う」という意味では、agent-native paymentのproduction exampleとして重要である。

P2 — 商用agent-originated commerce：uniple checkout

2026年7月21日、unipleはJPYCを使ったuniple checkoutの商用提供を開始した。

WooCommerce、EC-CUBE、Shopify等の既存ECと接続し、Hosted MCPを通じてChatGPTやClaudeが商品検索、比較、送料込み見積もり、checkout生成まで進められる。

ただし、Hosted MCPではAIがprivate keyを持たず、paymentを自動実行しない。最後は購入者本人が内容と金額を確認し、JPYC決済を承認する。

したがってこれは、

agent-originated commerceはproduction、fully autonomous paymentではない

と分類するのが正確である。

P2 — 商用trust / identity layer：DNP CATRINA

DNPは2026年7月24日、デジタルID管理・連携基盤CATRINAをAI agentへ拡張し、利用者から認可されたAI agentを識別して代理購入などに利用できる機能の提供を開始した。

これはpayment transactionそのものではない。

むしろ、「そのagentは誰の代理で、権限を与えられているのか」というidentity / delegation layerのproduction serviceである。DNPはQueue-itとの実証も行い、AP2の考え方も参照している。

P3 — production-ready infrastructure：GMO Payment Gateway

GMO Payment Gatewayは2026年6月、PGマルチペイメントサービス上にUCP仕様を採用したagentic commerce向け決済solutionの構築を完了し、8月6日に公表した。

これは日本の大手PSPがagentic commerceを既存payment infrastructureへ組み込む準備を進めている重要な事例である。

ただし、publicなlive agent transactionの実績とは別である。関連するGMO MakeShopも、発表時点でUCPは日本国内でまだ正式提供されておらず、具体的な機能・提供時期は今後案内するとしている。

したがって現段階ではproduction-ready infrastructure / live adoption未確認と位置付ける。

P4 — controlled production-like testing：Visa Agentic Ready Japan

Visaは2026年4月30日、日本を含むアジア太平洋地域でVisa Agentic Readyを開始した。

第一phaseはissuer readinessが中心で、管理されたproduction-like environmentでagent-initiated transactionをtest・validateする。

これは重要な準備段階だが、公開された本番consumer transactionそのものではない。

このように日本を見ると、「agentic paymentが始まったか、まだ始まっていないか」という二択では捉えにくい。

日本のagentic commerceを成熟度で分ける

成熟度	レイヤー	事例
P1	Card production transaction	Mastercard Agent Pay
P1/P2	Machine-native payment	OpenPay x402 + JPYC
P2	Agent-originated checkout	uniple checkout
P2	Identity / delegation service	DNP CATRINA
P3	PSP production-ready layer	GMO-PG UCP solution
P4	Controlled readiness testing	Visa Agentic Ready

注意：production transaction、商用サービス、production-ready infrastructure、controlled testは同じ成熟度ではありません。

日本ではcard rail、machine-native payment、checkout、identity、PSP infrastructure、readiness testingが異なる成熟度で並行している。

つまり日本でも、rail、machine payment、commerce、identity、PSP infrastructureという異なるlayerが異なる成熟度で同時に動き始めている。

一方、今回のtargeted primary-source QAでは、JCB、PayPay、楽天ペイ、SB Payment Serviceについて、これらと同等に扱えるagent-initiated paymentのlive production transactionは確認できなかった。これは「存在しない」という断定ではなく、2026年9月26日時点で確認できた公開一次資料の範囲を示すものである。

30年前との最大の違い

1995年と2026年には、よく似た部分がある。

新しいconsumer interfaceが登場し、そのinterfaceからpayment networkへ安全につなぐ共通言語が必要になった。

1995年はWeb browser。

2026年はAI agent。

そしてどちらの時代も、カードネットワークだけでは標準を決められない。software platform、merchant、identity/authentication、PSP、payment networkが同時に参加しなければ、実際には動かない。

しかし最大の違いもある。

1990年代のSETは、payment-specific securityを大きな一体型architectureとして作った。

2026年の主要仕様は、むしろ機能を分解している。

commerceはACP/UCP。

委任はAP2。

証拠はVerifiable Intent。

merchant edgeでのagent recognitionはVisa TAPなど。

credentialとpayment executionは既存tokenization、PSP、card/account rail。

そしてGoogle Payの2026年5月のdeveloper updateは、既存Google Pay backendとMerchant IDをUCPでそのまま使えることを強調している。

現代の設計者がSETを直接教訓にしたと証明できる資料はない。

それでも、歴史を知っていると一つの原則が浮かび上がる。

この比較から少なくとも決済標準について言えるのは、暗号技術の精緻さだけでなく、既存環境へ小さい追加コストで接続できることが普及に大きく効く、という点である。

SETの歴史は、その重要性を具体的に示している。

次の決済の主戦場は「決済網（rail）」ではなく「委任」かもしれない

これまでカード決済の中心的な問いは、

「このcredentialは本物か」

「このtransactionをauthorizationしてよいか」

だった。

AI agentが買い手になると、その一つ前に新しい問いが入る。

「そのtransactionをする権限を、このAIは本当に与えられていたのか。」

金額はいくらまでか。

どのmerchantならよいか。

いつまで有効か。

商品条件は何か。

人間はその場にいたのか。それとも前日にAIへ委任したのか。

そして問題が起きたとき、誰が何を許可したかを証明できるか。

1995年のProtocol Warsが「Webでカードを安全に使う共通言語」を争ったのだとすれば、2026年のagentic commerceが争っているのは、

「人間からAIへ委任された意思を、安全に、機械可読で、監査可能な形で運ぶ共通言語」

なのかもしれない。

30年前、高いsecurityを志向したSETがそのまま広く普及したわけではなかった。

今回も注目すべきなのは、protocol名の勝ち負けではない。

merchant、AI platform、PSP、issuer、payment networkを、どの仕組みが最小の追加コストでつなげるのか。

そして誰が、人間の「委任された意思」を最も広く相互運用できる形で運べるのか。

次の決済インフラの価値は、その場所に生まれる可能性がある。

主要出典

取得日：2026年9月25日（historical packetで確認済みの資料を含む）。AP2 / ACP / FIDO / EMVCo / scheme Rules / 日本事例の公開状態は2026年9月26日に再確認しました。

1994–2001：Internet payment Protocol Wars

U.S. DOJ archive, Visa/Microsoft STT Agreement, executed 1995-04-16.
Visa/Microsoft, VISA AND MICROSOFT PUBLISH OPEN SPECIFICATION…, 1995-09-27, DOJ Exhibit P-0405.
Eastlake / Boesch, Universal Payment Preamble, Internet-Draft, 1995-11-06.
Visa/MasterCard Joint Standard Agreement, 1995-12-20 notation, DOJ Exhibit P-0419.
U.S. District Court, S.D.N.Y., United States v. Visa U.S.A. Inc. et al., decision 2001-10-09.
W3C / CommerceNet, JEPI materials, 1995–1996.