Coinbaseはx402を中立に推し、StripeはMPP以外で引き続き両側に賭け続ける

著者：Charlie、OSLアメリカ担当、Venture Partner @ Generative Ventures。暗号資産ユニコーンのStrikeで副社長を務め（サルバドルのビットコイン法案に参画し、ラテンアメリカのビットコイン・ライトニング・ネットワークおよびステーブルコイン決済の業務を担当）、1兆級ファンドFranklin Templetonのマクロおよび通貨アナリスト、グローバル決済大手Adyenの初期メンバー。

この記事は著者個人の見解であり、関連する企業の立場を代表するものではありません。

最近agentic commerceに注目する友人がますます増えていますが、さまざまなプロトコルやプレイヤーもますます増えており、みんなが頭を整理しきれなくなっています。

とりわけ先週は、皆がStripe / TempoのMPPを理解しようと忙しかったのに、あっという間にStripeが、競合のCoinbaseのx402 Foundationに参加してしまいました。

さらにCloudflareは、今では両方をサポートしています。Googleもこの流れにいますが、それ自身にはAP2とUCPがあります。

Visa、Mastercardもやって来ましたが、明らかにステーブルコインの“推し”のためではありません。

Linux Foundationは公開の場でx402を、中立で業界が共同統治する“本拠地（大本営）”として定義しました。一方Cloudflareは、x402とMPPの両方を自社のAgents SDKに明確に入れています。Stripeもまた公開して、自社がMPPとx402の両方をサポートしていると書いています。

結局、誰が誰と競争していて、誰が誰とどう重なっているのでしょう？

しかし、この数日よく見ていると、むしろこう感じます。“混乱”は市場に方向性がないからではなく、市場がすでにかなりはっきりしていて、そして以前の私のx402の理解のように、私たちがその本意を誤解している可能性があるからだと。

つまりこの件は、最初の1日目から、1つのプロトコルだけで一気に統一されることはありません。

これは、インターネット基盤でよく見られる状況に近いのです――異なるレイヤーが同時に育ち、異なる会社が異なるレイヤーに賭け、最後は相互運用性によって全体をまず動かす。

本当の戦略ストーリーは、agentic web上のpaid machine accessのデフォルトとなる制御レイヤーを誰が定義するかです。そして主要プレイヤーは明らかにmulti-homeです。なぜなら、将来の本当のボトルネックが、認可（authorization）なのか、ディストリビューション（分配）なのか、あるいは決済（settlement）なのかを、皆がまだ賭けているからです。

一、Coinbaseはなぜ手放して、x402の基金をLinuxへ渡したのか？

もしx402がCoinbaseのプロトコルにすぎないなら、それが業界のデフォルト選択肢になるのは難しいでしょう。

これは「政治的配慮の一文」ではなく、非常に現実的な標準化ロジックです。

Linux Foundationの今回の表現は明確で、強調しているのは、サービス提供者の中立性、コミュニティのガバナンス、共有インフラであって、「ある会社が製品の新機能を出した」という話ではありません。

さらに重要なのは、x402 Foundationのページには現在も「プロジェクトは構築中」で、ガバナンスの仕組みや取締役会もまだ整備中だと書かれていることです。

つまり今回の動きはまず、「プロダクトが成熟した」と宣言するのではなく、「このプロトコルに中立な“家”を与える」と宣言するものです。

その背後の含意は実にシンプルです。

もしx402がずっとCoinbaseの製品機能の顔（たとえば今のBase）をして成長していくなら、クラウド事業者、決済会社、カード組織、プラットフォーム型プレイヤーであっても、技術的に接続したいと思っていても、政治的にはためらうはずです。

誰も、将来のpaid access layerを単一のプラットフォームに渡したくありません。x402をLinux Foundationの下に置くのは、Coinbaseがコントロールしたくないからではなく、むしろそれほどまでにx402を広く採用してほしいからであり、そのためにまず「これはCoinbaseのプロトコルだ」という負担を外す必要があるのです。

この点は実は重要です。なぜなら多くの人が、ファウンデーションのような動きをPRやオープンソースの姿勢とだけ捉えがちだからです。

しかしプロトコル戦では、ガバナンスは製品の一部です。

特に、標準がまだ初期で、絶対的なネットワーク効果がまだない段階では、いわゆる「中立で信頼できること」は、技術的な美しさより劣るものではありません。

逆に言えば、x402が将来、本当にある種のHTTP-nativeなpaid accessのベースラインになれるなら、それはコードが最も綺麗だからというより、他の案より先に政治コストを引き下げられたから、という可能性が高い。

言い換えると、ここでのガバナンスは脇役ではありません。ガバナンスそれ自体が成長エンジンなのです。

二、Stripeの“左右の取り合い”は結局何をしている？

今回、最も注視に値するプレイヤーは間違いなくStripeです。Stripeの動きが最も人を混乱させやすいからです。

一方では、3月18日にMPPを大々的に発表し、それを「マシン決済のオープン標準」として包装しました。

他方では、x402 Foundationのfounding contributorでもあり、自社ドキュメントでもx402のmachine paymentsをサポートしています。

Cloudflareのドキュメントはさらに直接的で、さらには明確にこう書いています。MPPのx402におけるコア決済フローはbackward-compatibleであり、MPP clientは既存のx402サービスをそのまま利用できる、と。

「プロトコル競争」という枠組みだけで見るなら、Stripeは左右の取り合いをしているように見えます。

しかし、視点をもう少し引き上げると、このやり方はむしろビジネスとしての筋が通っています。

なぜならStripeが本当に守りたいのは、402のハンドシェイクそのものではない可能性があるからです。

Stripeが本当に守りたいのは、ハンドシェイクの上にあるいくつかの層です：credentials、compliance、risk、reporting、tax、refunds、merchant integration。

Stripeは、どこか特定の単一プロトコルの“本当の信奉者”というよりは、最終的にどのハンドシェイク標準が勝っても、Stripeがagent paymentsのデフォルトとなる抽象化レイヤーであり続けることを確保しているように見えます。

x402をサポートするのは、オープンなエコシステムから欠席しないため。自分でMPPを推すのは、底層のセマンティクス定義に関わるため。そしてさらに上でACPやShared Payment Tokensを押し上げるのは、ワークフローと決済の証跡（支払いのための凭证）という、より厚い価値の層を守るためです。

だからこそ、Stripeが今回“最も怪しく見える”点は、実は“最も正直な点”なのです。

Stripeは、未来にはすぐにプロトコルが1つに収束するふりをしていません。行動でこう伝えているのです：少なくともこの段階では、誰も片側にだけ賭けるべきではない、と。

三、これは実はB2Bのインフラストーリー

私はますます、各種メディアがこの件の焦点をずらしているように感じています。

agent paymentsという話になると、最も簡単に思い浮かぶのは小売です。AIがあなたの代わりに航空券を買い、ホテルを予約し、注文し、checkoutまで通してくれる。

しかし、現にすでに公開され、実際に稼働し始めている“インフラっぽい”シーンを見ると、最初に走り出すのは小売のcheckoutではなく、もっと退屈で、しかしもっと現実的なB2Bのpaid accessです：有料API、有料データ、有料ツール、有料ブラウザセッション、有料のagent workflow。

Cloudflareは今、x402とMPPを使ってHTTPコンテンツ、API、そしてMCP toolsを課金できることを公開サポートしています。

x402の最強の採用ルートは、developer-to-developerのpaid APIsやtoolsです。ここでは「no account + pay-per-request」が単なる売り文句ではなく、実際に運用可能な落とし込みになっているからです。

背後にある変化は実に大きいです。

過去、あるAPIを課金するには、通常は一連の「人間に優しい」プロセスを先に踏む必要がありました。アカウント開設、billingの紐付け、API keyの発行、上限設定、照合、そして支払い権限の処理。

人間にとってもすでに面倒なのに、エージェントにとってはなおさら不向きです。

x402の最大の魅力は、それがよりcryptoだからでも、よりAIだからでもありません。むしろ、それが「有料アクセス」をHTTPそのものへもう一度押し戻そうとしている点にあります。つまり、入場（アクセス）制御と支払いの交渉を、普通のrequest-responseのように発生させようとしていることです。

サーバーが402を返して、今回のリクエストはいくらの価値があるのかを教える。クライアントは支払いを済ませ、その後は支払いの証跡（凭证）を使って同じリクエストを再試行する。

このモデルは、B2Bのソフトウェアやmachine-to-machine accessの観点で見ると、小売の観点よりずっと自然に見えます。

そして、B2Bに寄って見るほど、x402の優位性はよりはっきりし、短所の致命度は下がっていきます。

なぜならconsumer commerceでは、払い戻し、チャージバック、merchant-of-record、消費者保護、責任の帰属がすべて“難所”だからです。しかしB2BのAPIやツール呼び出しでは、それらの重要性は明確に下がります。

逆に、「無アカウントで、呼び出しごとに支払い、結果が得られたらすぐ離脱する」ことこそが真の需要です。

小売はもちろんより大きく、より賑やかで注目を集めやすい。しかし、真に先にプロトコルの形を定義するのは、しばしば最も賑やかなシーンではなく、最も早くリアルな需要を露出するシーンです。

今日のagent paymentsにとって、そのシーンは、カートではなく、ますます増えるソフトウェア同士、エージェント同士、ワークフロー同士のpaid accessである可能性が高い。

四、業界の発展が、私の以前のinteroperability判断を裏付けた

私の前回の記事で最も重要だった判断は、interoperabilityです。

当時、その判断には「建築上はこうあるべき」という匂いが少しありました。

しかし今見ると、それはますます現実の制約に見えます。なぜなら公開市場が“投票”をしているからです。まさに足で投票しています。

Cloudflareはどちらか一方を選びませんでした。x402とMPPの両方を同時にサポートし、さらに互換マッピングまで明確に実施しています。

Googleは一方でx402に参加しながら、AP2とUCPの推進も継続しています。

VisaとMastercardもまた、「all in one winner」の姿勢で自分たちの戦略を表現していません。片側ではx402に加わりつつ、もう片側ではagent token、身元認証、指令の検証、dispute signalsにさらに力を入れています。

巨大プレイヤーたちの多方向への賭けは、理性的な意思決定であって、商業的な偽善ではありません。

なぜこうなるのでしょう？　それは、これらのプロトコルがそもそも同じレイヤーにないからです。

少なくとも現時点までのところ、x402とMPPの方がpaid HTTP handshakeという層により近く、「支払い能力を伴ってリクエストを戻すにはどうするか」を解決しています。

AP2は、認可（authorization）と信頼できる意図（trusted intent）により近く、「そのagentは本当にその金を使う資格があるのか」を解決します。

UCPとACPは、workflow層や上位での問題をより扱うものに近く、discovery、checkout、加盟店関係、凭证伝達といった、さらに上の論点を処理します。

多くの企業がx402、MPP、AP2、UCPの同時サポートをしているのは、彼らが理解できていないからではありません。最後に勝つのは、アーキテクチャ的にたぶん複数レイヤーをまたいで、複数プロトコルが共同で構成する可能性が高いからです。

なので、私の前回の判断を一言で振り返るなら、今私は、interoperabilityがなければこのエコシステム自体が立ち上がらない、とさらに確信しています。

そして今、市場がまさにその判断を能動的に検証しています。

さらに踏み込むと、この判断はB2Bと小売のどちらに対しても重要です。

なぜなら小売の世界では、本当に少数の大プラットフォームや少数の大ワークフローに吸い込まれてしまう可能性はありますが、B2Bの世界はそうではありません。

企業はそもそも、多クラウド、多様な決済方法、多様なワークフローシステム、多様なアイデンティティと権限システムが共存する現実の中で生きています。

新しいプロトコルで企業スタック全体を一気に作り直そうとする人は、たいてい最初に死にます。

B2Bの顧客が本当にお金を払ってくれるのは、「唯一正しいプロトコル」ではなく、「多プロトコル環境でも既存システムが動き続ける能力」だからです。

このロジックは、企業シーンではconsumerシーンよりも、interoperabilityがより“硬い”ということにきちんと一致します。

五、これは単なるプロトコル競争ではなく、レイヤー後のstack競争

この件をレイヤーのstackとして理解すると、最初はバラバラに見えていた現象が一気に整います。

一番下の層はpaid access handshakeです。

ここで関心があるのは、HTTPリクエストが「ここには支払いが必要だ」をどう表現するか、そしてクライアントが支払いを済ませた後に、支払いの証跡をどう持ち帰るかです。

x402とMPPは主にここで戦います。MPPは402をより正式なHTTP auth semanticsへ取り込もうとしており、x402は402を“プラットフォーム化”するように見えます。つまり、カスタムヘッダー、facilitator、オンチェーン決済の抽象化、エコシステム統合によって、まずそれが動くようにするのです。

標準化されたセマンティクスの道を選ぶのか、プラットフォームのディストリビューションの道を選ぶのか。

次の層はauthority to spend、つまり「誰がその支払いを許可したのか」です。

こここそが、多くの人がまだ十分に意識できていない重要なポイントです。

機械が支払うこと自体は、それほど難しくありません。機械が信頼できる形で、その支払いを行う権限を与えられることが本当に難しい。

AP2が重要なのは、それが単に「どう支払うか」だけでなく、mandates、verifiable credentials、authenticity、accountabilityといったことを解決しているからです。

VisaとMastercardが最近力を入れているagent token、instruction validation、passkeys、dispute signalsも、本質的にはここにあります。

さらに上の層はworkflowとdistributionです。

つまりdiscovery、checkout、加盟店（merchant）関係、credential sharing、AI surface integrationといった、“誰がトラフィックと取引の編成を掌握するか”に近い領域です。

UCPとACPは、この層を巡る競争により近いです。

B2Bにとっては短期的にはそこまで熱くないかもしれませんが、長期的には価値が非常に高くなる可能性があります。

なぜなら、将来的により多くの企業ソフトが、agentによって調整され、呼び出され、調達され、支払われるようになるなら、workflow languageを握った者は単に一度の支払いを管理するだけでなく、ワークフロー全体を管理することになるからです。

この3層を分けて考えると、次の素朴な事実が見えてきます。そもそも、1つのプロトコルですべての問題を包むことを期待する必要はないのです。

より現実的な道は、この3層がそれぞれ先に育ち、相互運用性によってゆっくりと噛み合っていくことです。

だからこそ、多頭賭けは迷いではなく、理性なのです。

六、x402の本当のリスクは、規制ではなく並行性下の経済学かもしれない

「多プロトコルが併存する」という事実を理解しただけでは、まだ十分に深掘りできていません。

x402の最大のリスクは、最初に来るのが規制だとは限らず、verify–settleの2ステップ分離がもたらすtime-of-check/time-of-useの経済学かもしれません。

簡単に言うと、支払いの検証と最終決済が同一ではない場合、高並行・リトライ・代理層・キャッシュ層などの実際のインターネット環境で、「1回支払って、複数回アクセスする」ためのウィンドウが生まれてしまうことです。

x402エコシステムは現在も穴埋めをしています。たとえばsettlement cache、idempotency extension、payment identifierなど。ただ、まさにそれが示しているのは、問題が理論上だけではないということです。

この点が特にB2Bの読者にとって重要なのはなぜでしょう？

B2Bの世界で最も怖いのは、決して“きれいなデモが作れないこと”ではなく、“例外（edge case）が多すぎて、結局本番に入ったら漏れる”ことだからです。

APIのモネタイゼーションは、表向きはリクエストごとに数セント払うだけで軽く見えます。しかし、もしあなたのプロダクトが呼び出し課金、結果課金、ワークフロー課金なら、「1回払って1回だけ」なのか、「1回払って複数回」なのかは、製品の細部ではなく、生死線になります。

だから、もし将来x402が本当にB2Bで走り出すなら、重要な前提は“ナラティブ”ではなく、こうしたデフォルトで安全な仕組みが十分に“頭のいい実装”として無理なく作られていることです。そうでなければ企業は、実トラフィックを安心して接続できません。

七、プロトコルは無料かもしれないが、料金所は消えない

もう1つ、ここでしっかり書いておく価値があると思います。

多くのオープンプロトコルは最終的に、どこかで見覚えのある場所へ行き着きます。つまり、プロトコル自体がだんだん安くなり、場合によっては無料になる。しかし実際の“料金所”は横に生えてくるのです。

x402も同様です。

標準自体はもちろん、オープンで中立で、標準内に0 feesが組み込まれていることを強調します。しかしそれは、価値の回収（value capture）が消えることを意味しません。

もしx402が成功しても、価値の主な居場所はプロトコルの中にはなく、facilitator、ウォレット、key management、discovery、policy engine、trust wrapperといった隣接レイヤーへ移っていくでしょう。

これはB2Bにとって特に重要です。

なぜなら企業の顧客は、新しいプロトコルのために大規模なシステム改造をするわけではありません。彼らが本当にお金を払いたいのは、多プロトコル環境でオーケストレーション、ポリシー、リスク、コンプライアンス、監査（audit）、決済、権限境界といった面倒ごとを片づけてくれるのが誰か、です。

言い換えると、プロトコルはますます“基盤言語（底層言語）”のようになりますが、それらの言語を「企業が安心して本番投入できる」能力へ翻訳する、その層のほうが、新しいプラットフォームや新しい料金所になりやすいのです。

だからこそ、私は今日のx402を見るときに、Coinbase、Cloudflare、Stripeのうち誰が“主役”っぽいかだけを見てはいけないと思うのです。

本当に注目すべきは、それらの隣接レイヤーで立てる機会が最も高いのは誰か、です。

Cloudflareはエッジやトラフィック配分のポジションにいます。Stripeは決済インフラと加盟店関係のポジションにいます。VisaとMastercardは凭证（クレデンシャル）、ネットワークトークン、consumer trustのポジションにいます。Googleはworkflowとdiscovery surfaceのポジションにいます。

本当の価値の回収は、「誰が402を定義するか」で起きるとは限らず、「誰が402をより大きな企業システムに接続するか」で起きる可能性のほうが高い。

八、結語

x402 Foundationの件は、x402がすべてのagentic commerceプロトコルで勝っていると宣言することではありません。

それは、この世代のagent paymentsが、初日から単一プロトコルの世界にならないことを、公に認めたものです。

Coinbaseがx402をLinux Foundationに渡したのは、それを独占的なプロダクトではなく、中立な公共レイヤーのようにするためです。

StripeがMPPを推しながらx402にも加わったのは、揺れではなく、今は片側だけに賭けるべきではないと分かっているからです。

Cloudflareが両方を同時にサポートするのは、実際のトラフィックに最も近いからです。

Google、Visa、Mastercard、Adyenといったプレイヤーの動きも、同じことを示しています。まずシステムが相互運用できるようにし、その後に、最終的にどの層を誰が押さえるのかを議論する。

そして、この判断は、視点を小売から外すとさらにスムーズになります。

なぜなら、最初にこれらのプロトコルを必要とするのが、必ずしもカートではないからです。ますます増えるのは、呼び出し課金、タスク課金、結果課金のB2Bソフトウェアやサービスだからです。

小売の方がもちろん大きく、より注目も集めやすい。しかしB2Bは往々にして、より早くリアルな需要を露出し、より早く、インフラが最終的にどんな形になるかを定義します。

私の前回の記事では、interoperabilityを中心に置きましたが、私は今、市場が出している答えは本当に明確だと思います。そう、そして当時考えていたよりもずっと早い段階で。

この意味で、x402 Foundationはこの物語の結末ではありません。

それは、私たちがより早い段階でこう気づくためのものでした。真のテーマはずっと「誰が勝つか」ではなく、「この世界は先に互通する運命にあり、その後に誰が最も価値のある層を押さえるのか」。