Coinbaseがx402を中立に推進 StripeはMPP外で両側に賭ける

著者：Charlie Liu、Generative Venturesパートナー

最近agentic commerceに注目している人がどんどん増えていますが、さまざまなプロトコルやプレイヤーも登場してきて、誰が何をしているのかますます分かりにくくなっています。

とりわけ先週は、みんながStripe / TempoのMPPを理解しようとしていたばかりなのに、あっという間にStripeが、競合企業であるCoinbaseのx402 Foundationに参加したのです。

しかもCloudflareは現在、両方をサポートしています。Googleもこの流れの中にいますが、Google自身にはAP2とUCPもあります。

Visa、Mastercardも参入していますが、彼らが来たのは明らかにステーブルコインを後押しするためではありません。

Linux Foundationは公開の場でx402を、中立で業界が共同統治する「拠点」として明確に定義しています。一方でCloudflareは、x402とMPPの両方を自社のAgents SDKに同時に入れると明確に打ち出しています。Stripeもまた、MPPとx402の両方をサポートしていることを公開しています。

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

ただ、ここ数日見ているほど、逆にこう感じています。この「ごちゃごちゃ」は、市場に方向性がないからではなく、市場がすでにとても明確だからです。そして、私が以前言及したように、これは最初の日から、単一のプロトコルが一度にすべてを統一する話ではありません。

むしろインターネット基盤でよくある状況に近い——異なるレイヤーが同時に育ち、異なる会社がそれぞれのレイヤーに賭け、最後は相互運用性によって、最終的に全体が先に動き始める。

本当の戦略ストーリーは、agentic web上でpaid machine accessのデフォルトとなる制御レイヤーを誰が定義するのか、ということです。そして主要なプレイヤーは明らかにmulti-homeしています。みんな、将来の真のボトルネックがどこに落ちるのか——認可（authorization）なのか、配信（distribution）なのか、それとも決済（settlement）なのか——まだ賭けているからです。

一、Coinbaseがなぜ手放してx402基金会をLinuxに渡したのか？

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

これは「政治的に正しい」といった言い方ではなく、現実的な標準化ロジックです。

Linux Foundationの今回の表現は非常に明確で、強調しているのはサービス事業者の中立性、コミュニティによるガバナンス、共有基盤であって、「ある会社がプロダクトの新機能を出した」という話ではありません。

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

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

この裏にある含みは、実はとてもシンプルです。

x402がずっとCoinbaseのプロダクト機能の顔（たとえば現在のBase）のような状態で伸びているなら（そう見えているなら）、クラウド事業者、決済会社、カード組織、プラットフォーム型のプレイヤーは、技術的に接続したいとしても政治的にはためらいます。

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

この点は実はとても重要です。多くの人が基金会のような動きを、PRやオープンソースの姿勢とだけ見てしまいがちだからです。

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

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

逆に言えば、もし将来x402がある種のHTTP-nativeなpaid accessのベースラインになれるのだとしたら、それは「コードが一番きれい」だからではなく、ほかの案よりも早く、政治的コストを引き下げられたからかもしれません。

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

二、Stripeの左右の「読み合い」は結局何をしているのか？

今回いちばん注目すべきプレイヤーは間違いなくStripeです。なぜなら、Stripeの動きが一番人を混乱させやすいからです。

一方では、3月18日にMPPsを大々的に打ち出し、それを「機械支払いのためのオープン標準」としてパッケージ化しています。

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

Cloudflareのドキュメントはさらに直接的で、はっきりとこう書いています。MPPはx402のコアとなる支払いフローに対してbackward-compatibleであり、MPP clientは既存のx402サービスをそのまま消費できる、と。

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

しかし、視点をもう少し引き上げると、このやり方にはむしろビジネス上のロジックがあります。

なぜならStripeが本当に守ろうとしているのが、402 handshakeそのものとは限らないからです。

Stripeが本当に守ろうとしているのは、handshakeのその上にある数層です。credentials、compliance、risk、reporting、tax、refunds、そしてmerchant integrationです。

Stripeは、単一のプロトコルの「本当の信者」であるようには見えません。むしろ、「最終的にどのhandshake標準が勝っても、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を発行し、制限額を設定し、突合（accounting）を行い、それから支払い権限を処理する。

人間にとってもすでに面倒です。ましてagentにとってはもっと不自然です。

x402の一番の魅力は、それがよりcryptoだからでも、よりAIだからでもありません。「有料アクセス」をHTTP本体に再び押し戻し、入場制御と支払い交渉が普通のrequest-responseのように起きるようにしようとしているからです。

サーバーが402を返し、「今回のリクエストはいくらです」と教えてくれます。クライアントが支払いを済ませたら、その支払いの凭證を使って同じリクエストを再試行します。

このモデルをB2Bソフトやmachine-to-machine accessの観点で見ると、小売の観点で見るよりずっと自然です。

そして、B2B側に寄れば寄るほど、x402の優位性はよりはっきりし、欠点もそれほど致命的ではなくなります。

**consumer commerceでは、返金、拒否（チャージバック）、merchant-of-record、consumer protection、責任の帰属が、すべて「ハードな問題」**です。一方で、B2BのAPIやツール呼び出しでは、これらの問題の重要性は明らかに下がります。

反対に、「無アカウントで、呼び出しごとに課金され、結果が出たら終わる」が本当のニーズです。

小売はもちろん、より大きく、より熱く、より注目を集めやすいです。しかし、実際に最初にプロトコルがどんな姿になるかを定義するのは、一番にぎやかなシーンではなく、最も早く本当の需要が露出するシーンであることが多い。

今日のagent paymentsに関して言えば、そのシーンはカートではなく、ますます増えるソフトの間、agentの間、ワークフローの間の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の顧客が本当に支払うのは、「唯一正しいプロトコル」ではなく、「多プロトコル環境でも既存システムが動き続けられる能力」です。

このロジックは、まさにinteroperabilityが企業シーンではconsumerシーンよりも、より“強い”理由になっています。

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

この件をレイヤーのstackとして理解すると、もともとごちゃごちゃに見えていた多くの現象が、すぐに整って見えてきます。

いちばん底の層が、paid access handshakeです。

この層が気にしているのは、HTTPリクエストが「ここでは支払いが必要だ」とどう表現するか、そしてクライアントが支払いを済ませた後に、支払いの凭證をどうやって持ち帰るかです。

x402とMPPは主にここで戦っています。MPPは、402をより正式なHTTP authセマンティクスに取り込もうとしています。一方で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 relationship、credential sharing、AI surface integrationといった、より「誰がトラフィックと取引の編成を掌握するか」に近い領域のことです。

UCPとACPは、この層を争っているように見えます。

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

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

この3層を分けて見れば、非常に素朴な事実が見えてきます。そもそも、単一のプロトコルがすべての問題を包むことは期待する必要がないのです。

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

そしてまさにそれゆえに、複数への賭けは迷いではなく理性なのです。

六、x402の本当のリスクは、規制ではなく「並行下の経済学」

もし私たちが「多プロトコルが共存する」という事実を理解するだけなら、まだ十分に深くありません。

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

簡単に言うと、支払いの検証と最終決済が同じでない場合、高並行、重試行、代理層、キャッシュ層などの現実のインターネット環境では「pay once, access multiple times（1回払って複数回アクセスする）」の窓が生まれます。

x402エコシステムも穴を埋めようとしており、たとえばsettlement cache、idempotency extension、payment identifierなどがありますが、まさにそれが「問題は理論上の話ではない」ことを示しています。

この点が、とりわけB2Bの読者にとって気にする価値があるのはなぜでしょうか。

B2Bの世界で最も怖いのは、いつだって「きれいなデモが作れない」ことではありません。エッジケースが多すぎて、結局本番に入れると漏れることです。

API monetizationのようなものは、表面上はリクエストごとに数セント課金するだけで軽そうに見えます。しかし、もしあなたのプロダクトが呼び出しごと、結果ごと、ワークフローごとで課金する形なら、「1回払って1回得る」のか、「1回払ってたくさん得る」のかは、プロダクトの細部ではなく生死線になります。

だから、もし将来x402が本当にB2Bで走り出すなら、重要な前提はnarrativeではなく、これらのdefault-safeな仕組みが、愚直なほど無理なく動くレベルで作り込まれていることです。そうでなければ企業は、本当のトラフィックを安心して接続できません。

七、プロトコルは無料でも、料金所は消えない

もう一点、ここでこの話をしっかりと言語化しておく価値があります。

多くのオープンプロトコルは最後に、よく見慣れた場所へ到達します。プロトコル自体はますます安くなり、無料になることすらある。しかし本当の料金所は、その横に育っていくのです。

x402も同じです。

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

もしx402が成功すれば、価値は主にプロトコルの中に残るのではなく、facilitator、ウォレット、key management、discovery、policy engine、trust wrapperといった隣接レイヤーへ移動します。

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

なぜなら企業の顧客は、新しいプロトコルのために大規模にシステム全体を改造するためにお金を払うわけではありません。彼らが本当にお金を払うのは、複数プロトコル環境の中で、orchestration、policy、risk、compliance、audit、settlement、権限境界といった面倒ごとを片づけてくれる存在だからです。

言い換えると、プロトコルはますます底層言語のようになっていく一方で、その言語を「企業が安心して本番投入できる」能力に翻訳するレイヤーのほうが、新しいプラットフォームになり、新しい料金所になりやすいのです。

だから私は、今日x402を見るとき、Coinbase、Cloudflare、Stripeのどれが「主役っぽいか」だけに注目してはいけないと思うのです。

本当に注目すべきは、これら隣接レイヤーに立てる可能性が誰にあるかです。

Cloudflareには、エッジとトラフィック配分のポジションがあります。Stripeには、支払いインフラと商取引関係のポジションがあります。VisaとMastercardには、凭證、ネットワークtoken、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はこの物語の終わりではありません。

それは私たちに、より早い段階で気づかせてくれただけです。真のテーマはずっと「誰が勝つか」ではなく、この世界はまず相互運用できるようになる運命であり、その後に誰が最も価値のある層を占められるのか、ということだと。