GitHubが即日対応した理由
GitHubが、新しいMCP（Model Context Protocol）仕様への対応を発表した。
発表内容だけを見れば、実に地味なアップデートである。
- セッション開始時の
initializeが不要になる - セッションIDを管理しなくてよくなる
- セッションIDを保存・取得するデータベースアクセスが不要になる
- ステートレスな通信へ移行する
これだけを見ると、「通信が少し速くなる」「実装が少しシンプルになる」という程度の話に思える。
しかし、GitHubが仕様公開と同日に対応版をリリースしたことを考えると、この変更は単なる最適化ではない。
巨大なサービスほど、セッション管理は地味にコストがかかる。
セッション情報を書き込み、読み出し、有効期限を管理し、場合によってはRedisなどの共有ストアを用意する。ロードバランサーもスティッキーセッションを考慮しなければならない。
ステートレス化によって、こうした仕組みが不要になる。
サーバは毎回のリクエストだけを見て処理できるようになり、どのサーバへリクエストを振り分けても問題ない。クラウド時代のインフラとしては、理想的な形だ。
だからGitHubは迷わなかったのだろう。
運用コストが下がり、構成もシンプルになる。巨大サービスであればあるほど、その恩恵は大きい。
しかし、この変更を眺めていて、私は別のことに気付いた。
今回変わったのは、通信方式だけではない。
MCPという技術そのものの役割が変わったのである。
MCPは主役ではなくなった
MCPが登場した当初、多くの人はこんな未来を想像していたのではないだろうか。
AI
↓
MCP
↓
サービスAIはMCPを通じてGitHubやSlack、Stripe、Shopifyと会話する。
MCPはAI時代の共通言語となり、あらゆるサービスをつなぐ”窓口”になる。
私もそう考えていた一人だ。
だから最初にステートレス化の話を聞いたときは、「サーバ実装が少し楽になるのだな」くらいにしか思わなかった。
しかし、仕様を読み進めるうちに印象が変わった。
MCPは、自ら主役を降りようとしている。
ステートレス化によって、MCPは状態を持たなくなった。
ユーザー情報を持たない。
ワークフローを持たない。
会話の途中経過も持たない。
ショッピングカートも持たない。
つまり、「AIとサービスの間で何が起きているか」を覚えないのである。
これは技術的には「セッションを廃止した」という一文で済む。
しかし、その意味はもっと大きい。
MCPは「AIの実行基盤」になることをやめ、「AIとサービスをつなぐ配管」になる道を選んだのだ。
この変化は、HTTPの歴史によく似ている。
私たちは毎日Webを使っているが、「HTTPを使っている」という意識はほとんどない。
HTTPはWebの主役ではない。
しかし、HTTPがなければWebは成立しない。
TCP/IPも同じだ。
USBも同じである。
本当に普及した標準規格ほど、人々の意識から姿を消していく。
今回のステートレス化を見ていると、MCPもまさにその方向へ舵を切ったように思える。
世界中のAIが利用するインフラになるために、自ら前面に立つことをやめた。
それは一見すると地味な変更だが、実はMCPという技術の立ち位置を大きく変える、一つの転換点なのかもしれない。
ステートレスが意味するもの
技術者にとって、ステートレス化とは「セッションがなくなった」という話で終わるかもしれない。
しかし、本質はそこではない。
私が感じたのは、
「責任が移動した」
ということだ。
これまでMCPは、多少なりとも状態を抱え込む存在だった。
クライアントと接続し、セッションを開始し、その後のやり取りを継続する。
つまり、「途中経過」をMCPが知っていた。
ところがステートレス化によって、その役割はなくなった。
毎回のリクエストは独立し、MCPは「今この瞬間」だけを見て処理する。
すると当然、一つの疑問が生まれる。
では、状態は誰が持つのか。
例えば、ChatGPTにこう頼んだとする。
「牛乳と卵を買っておいて。」
さらに、
「やっぱり牛乳は2本にして。」
「チーズも追加。」
「クーポンがあれば使って。」
この一連の流れは、一つの会話であり、一つの作業だ。
しかし、MCPはもう途中経過を覚えていない。
では誰が、
- 牛乳をカートへ入れたこと
- 数量を変更したこと
- チーズを追加したこと
- クーポン適用待ちであること
を管理するのだろうか。
答えはシンプルだ。
AIクライアントである。
ChatGPTやClaude、CursorのようなAIは、今後ますます「状態」を管理する存在になっていく。
会話。
タスク。
ワークフロー。
プロジェクト。
ユーザーの意図。
こうした情報を抱え込みながら、必要な場面でだけMCPを通じてサービスへアクセスする。
つまり、MCPは責任を放棄したのではない。
本来あるべき場所へ責任を返したのである。
ユーザーとの対話はAIクライアントが持つ。
注文や決済の正本はサービスが持つ。
MCPは、その二者を結ぶ通信だけを担当する。
この役割分担は、とても自然だ。
実際、GitHubのIssueやPull RequestをMCPが保持する必要はない。
Stripeが決済情報をMCPへ保存する理由もない。
データの正本は、もともとサービス側に存在している。
だからMCPは、それを毎回取得し、毎回操作するだけで十分なのだ。
そう考えると、今回のステートレス化は単なる通信仕様の変更ではない。
AIクライアント、MCP、サービス。
三者の責任範囲を整理し直した、アーキテクチャ全体の再設計なのである。
AIクライアントはますます巨大になる
この責任の移動によって、一つ確実に言えることがある。
AIクライアントの実装は、これまで以上に大きくなる。
例えば画像生成AIであれば、この変化はほとんど影響しない。
「画像を一枚生成してください。」
この要求は、一回のリクエストで完結する。
状態を持つ必要はない。
しかし、エージェントは違う。
例えば旅行を予約するAIを考えてみよう。
ユーザーはこう話しかける。
「来月、大阪から札幌へ二泊三日で旅行したい。」
その後、
「やっぱりホテルは駅の近くがいい。」
「飛行機は午前便で。」
「レンタカーは不要。」
「予算はあと2万円下げたい。」
この会話は、一つひとつは単純でも、全体としては一つのワークフローになっている。
航空会社。
ホテル。
決済。
クーポン。
ポイント。
保険。
それぞれ別のサービスと連携しながら、AIは「旅行プラン」という一つの状態を維持し続けなければならない。
MCPはもう、その状態を覚えてくれない。
つまり、AIクライアント自身が巨大な状態管理システムになるのである。
これはChatGPTだけの話ではない。
Claude。
Cursor。
Codex。
Gemini。
将来登場するあらゆるAIエージェントが、同じ課題に直面するだろう。
会話履歴だけでは足りない。
プロジェクト。
ワークフロー。
一時的なタスク。
途中保存。
失敗時の再開。
外部サービスとの整合性。
こうしたものを管理できるAIほど、使い勝手が良くなる。
私は以前、「MCPがAI時代の中心になる」と考えていた。
しかし今は逆だ。
MCPは薄くなる。
その代わりに、
AIクライアントそのものが、新しいOSのような存在へ進化していく。
AIは単なるチャット画面ではなくなる。
ユーザーの作業を理解し、複数のサービスをまたぎ、一つの仕事を最後までやり遂げる。
そのための責任を背負うのが、これからのAIクライアントなのだ。
サービスは再び主役になる
ここまで考えてきて、私はある誤解に気付いた。
AIが進化すると、多くのSaaSは価値を失う。
そんな話を、この一年ほど何度も目にしてきた。
しかし、それは半分だけ正しい。
AIが代替するのは、画面（UI）であって、サービスそのものではない。
例えばGitHubを考えてみよう。
AIはコードを書き、レビューし、Issueを読み、Pull Requestを作成する。
すると、一見するとGitHubの画面を開く機会は減るかもしれない。
しかし、コードの正本はどこにあるのか。
Pull Requestはどこにあるのか。
Issueはどこが管理しているのか。
答えは変わらない。
GitHubである。
Stripeも同じだ。
AIが決済処理を代行するようになっても、実際の決済履歴や返金情報、不正利用の判定はStripeが持っている。
Shopifyも同じである。
AIが商品を探し、カートへ入れ、購入まで代行したとしても、
商品情報。
在庫。
注文履歴。
配送状況。
返品情報。
これらの正本はShopify側に存在する。
つまり、AIが賢くなればなるほど、
サービスそのものの価値は失われない。
むしろ、より重要になる。
MCPが状態を持たなくなったことで、この構図はさらに明確になった。
MCPはデータを保存しない。
MCPはユーザーを管理しない。
MCPは注文も保持しない。
だから最終的な責任は、サービス自身が負うことになる。
これは少し意外だった。
私は以前、MCPがAI時代の新しい窓口になると思っていた。
しかし実際には逆だった。
MCPは一歩後ろへ下がり、
サービス自身が再び表舞台へ戻ってきた。
AIはサービスを置き換えるのではない。
サービスを操作する。
そしてサービスは、自らが持つデータを管理し続ける。
この役割分担が見えたとき、私はGoogleが発表したUniversal Cartを思い出した。
Universal Cartで見えたこと
GoogleがUniversal Cartを発表したとき、私は最初こう考えた。
「GoogleはECの入口だけではなく、購買そのものも支配しようとしているのではないか。」
AIが商品を探し、そのまま購入まで完了する。
そんな世界になれば、Googleが新しいショッピングモールになるようにも見えた。
しかし、MCPのステートレス化を見ているうちに、その考えは少し変わった。
Googleが持とうとしているのは、ECそのものではない。
もっと正確に言えば、
購買という体験を横断するための共通モデルである。
例えば、ある商品を購入するとしよう。
Googleは、
「この人は何を探しているのか。」
「どの商品を比較しているのか。」
「どのタイミングで買おうとしているのか。」
という入口の情報を持っている。
一方、Shopifyは、
「どの商品が存在するのか。」
「在庫はいくつあるのか。」
「実際に注文されたのか。」
という店舗側の情報を持っている。
さらにStripeは、
「決済は成功したのか。」
「返金されたのか。」
「不正利用ではないか。」
という金融の情報を持っている。
誰も、全部は持っていない。
そして、全部を持つ必要もない。
Universal Cartは、その間をつなぐ共通の器なのだ。
これはMCPとよく似ている。
MCPはサービスを支配しようとはしていない。
Universal CartもECを支配しようとしているわけではない。
どちらも目指しているのは、
異なるサービス同士が、同じ言葉で会話できる世界である。
もちろん、その共通化は非常に重要だ。
しかし、本当に価値があるものは、その先にある。
Googleが何十億件もの検索から蓄積した購買意図。
Shopifyが何百万もの店舗から集めた販売実績。
Stripeが何十億件もの決済から学習した信用情報。
これらは、プロトコルを標準化しただけでは手に入らない。
その瞬間、ようやく腑に落ちた。
標準化とは、データを共有することではない。
標準化とは、
「誰のデータを、誰が責任を持って管理するのか」を明確にすることでもあるのだ。
だからUniversal Cartの本当の価値は、カートのJSON形式ではない。
MCPの本当の価値も、通信フォーマットではない。
どちらも、AI時代の責任分界点を定義するためのインフラなのである。
本当に争っているもの
ここまで考えてきて、ようやく今回の一連の流れが一本につながった。
MCP。
Universal Cart。
GitHubの即日対応。
一見すると、まったく別の話である。
しかし、本質は同じだった。
最初は私も、
「標準規格の争い」
だと思っていた。
MCPが勝つのか。
UCPが広がるのか。
どのプロトコルが世界標準になるのか。
しかし、それは少し違う。
本当に争っているのは、プロトコルではない。
JSONでもない。
APIでもない。
通信方式でもない。
データそのものである。
もっと正確に言えば、
長年積み上げられてきた信用データだ。
例えばShopifyには、
何が売れたのか。
どんな店舗があるのか。
返品率はどうか。
という実績が蓄積されている。
Stripeには、
決済履歴。
チャージバック。
不正利用。
加盟店ごとの信用。
という金融データがある。
GitHubには、
コードだけではない。
コミット履歴。
レビュー。
Issue。
Pull Request。
開発プロジェクトそのものの歴史が存在する。
Salesforceには、
企業の営業活動そのものが記録されている。
どれも簡単には真似できない。
だからGoogleがUniversal Cartを標準化したとしても、
Shopifyの販売実績はGoogleのものにはならない。
MCPが世界標準になったとしても、
GitHubのコード資産がMCPへ移るわけではない。
標準化されるのは、
会話の方法だけだ。
データの所有権は変わらない。
むしろ、標準化が進むほど、その価値は際立っていく。
なぜなら、AIはどのサービスにも接続できるようになるからだ。
すると最後に差になるのは、
「誰が一番賢いプロトコルを持っているか」
ではない。
誰が一番価値あるデータを持っているか。
そこが競争になる。
私は以前、「AIがSaaSを食べる」という議論を何度も目にした。
しかし今は、少し違う景色が見えている。
AIが食べるのは、SaaSではない。
SaaSの画面である。
人間がブラウザで操作していた部分は、AIが代わりに操作するようになる。
しかし、その裏側でデータを持ち続けるサービスは、むしろ以前より重要になる。
AIは、そのデータなしには何も判断できないからだ。
だからAI時代の競争は、モデル性能だけではない。
それ以上に、
「誰が信用データを持っているのか」
という、静かな主権争いが始まっているのである。
MCPはHTTPになる
私は最初、MCPはAI時代の「主役」になる技術だと思っていた。
AIとサービスをつなぐ共通プロトコル。
あらゆる企業がMCPサーバを公開し、AIはそれを利用して仕事をする。
そんな未来を想像していた。
もちろん、その未来は今も変わらない。
ただ、一つだけ大きく見方が変わった。
MCPは、主役になろうとしていない。
今回のステートレス化は、その意思表示だったように思う。
状態を持たない。
ユーザーを持たない。
ワークフローを持たない。
サービスの責任も持たない。
MCPは、自らの役割を極限まで小さくした。
これはどこかで見た構図だ。
TCP/IP。
HTTP。
USB。
どれも世界中で使われている。
しかし、「HTTPを使っているからこのサービスを選ぶ」という人はいない。
USBが好きだから、このマウスを買う人もいない。
標準規格とは、本来そういう存在なのだ。
意識されない。
しかし、なくなると世界が止まる。
MCPも、おそらく同じ道を歩む。
AIエージェントが増えれば増えるほど、MCPを意識する人は減っていくだろう。
ChatGPTで買い物をする人は、「今MCPを使っています」とは考えない。
Claude CodeでGitHubを操作する人も、MCPを意識することはない。
彼らが意識するのは、
「AIがちゃんと仕事をしてくれるか」
それだけだ。
そして、その裏側で静かにMCPが動き続ける。
私は今回の仕様変更を見て、一つ確信した。
MCPは表舞台へ出ることをやめた。
だからこそ、世界標準になれる可能性がある。
標準規格とは、自らを主張しない技術だからだ。
おわりに
MCPは主役になることをやめた。
その代わりに、AIクライアントはより賢くなり、サービスは自らのデータに責任を持ち続ける。
GoogleがUniversal Cartで目指しているものも、GitHubが即日対応した理由も、その延長線上にある。
標準化が進めば進むほど、プロトコルの価値は均一化していく。
最後に競争力を生むのは、プロトコルではない。
長年積み重ねられた信用データである。
AI時代の競争は、モデル性能だけではない。
誰が最も価値あるデータへの扉を持っているのか。
そして、そのデータへ最も自然にたどり着けるAIクライアントを作れるのは誰なのか。
その競争は、もう静かに始まっている。
GitHubが即日対応した理由
GitHubが、新しいMCP（Model Context Protocol）仕様への対応を発表した。
発表内容だけを見れば、実に地味なアップデートである。
- セッション開始時の
initializeが不要になる - セッションIDを管理しなくてよくなる
- セッションIDを保存・取得するデータベースアクセスが不要になる
- ステートレスな通信へ移行する
これだけを見ると、「通信が少し速くなる」「実装が少しシンプルになる」という程度の話に思える。
しかし、GitHubが仕様公開と同日に対応版をリリースしたことを考えると、この変更は単なる最適化ではない。
巨大なサービスほど、セッション管理は地味にコストがかかる。
セッション情報を書き込み、読み出し、有効期限を管理し、場合によってはRedisなどの共有ストアを用意する。ロードバランサーもスティッキーセッションを考慮しなければならない。
ステートレス化によって、こうした仕組みが不要になる。
サーバは毎回のリクエストだけを見て処理できるようになり、どのサーバへリクエストを振り分けても問題ない。クラウド時代のインフラとしては、理想的な形だ。
だからGitHubは迷わなかったのだろう。
運用コストが下がり、構成もシンプルになる。巨大サービスであればあるほど、その恩恵は大きい。
しかし、この変更を眺めていて、私は別のことに気付いた。
今回変わったのは、通信方式だけではない。
MCPという技術そのものの役割が変わったのである。
MCPは主役ではなくなった
MCPが登場した当初、多くの人はこんな未来を想像していたのではないだろうか。
AI
↓
MCP
↓
サービスAIはMCPを通じてGitHubやSlack、Stripe、Shopifyと会話する。
MCPはAI時代の共通言語となり、あらゆるサービスをつなぐ”窓口”になる。
私もそう考えていた一人だ。
だから最初にステートレス化の話を聞いたときは、「サーバ実装が少し楽になるのだな」くらいにしか思わなかった。
しかし、仕様を読み進めるうちに印象が変わった。
MCPは、自ら主役を降りようとしている。
ステートレス化によって、MCPは状態を持たなくなった。
ユーザー情報を持たない。
ワークフローを持たない。
会話の途中経過も持たない。
ショッピングカートも持たない。
つまり、「AIとサービスの間で何が起きているか」を覚えないのである。
これは技術的には「セッションを廃止した」という一文で済む。
しかし、その意味はもっと大きい。
MCPは「AIの実行基盤」になることをやめ、「AIとサービスをつなぐ配管」になる道を選んだのだ。
この変化は、HTTPの歴史によく似ている。
私たちは毎日Webを使っているが、「HTTPを使っている」という意識はほとんどない。
HTTPはWebの主役ではない。
しかし、HTTPがなければWebは成立しない。
TCP/IPも同じだ。
USBも同じである。
本当に普及した標準規格ほど、人々の意識から姿を消していく。
今回のステートレス化を見ていると、MCPもまさにその方向へ舵を切ったように思える。
世界中のAIが利用するインフラになるために、自ら前面に立つことをやめた。
それは一見すると地味な変更だが、実はMCPという技術の立ち位置を大きく変える、一つの転換点なのかもしれない。
ステートレスが意味するもの
技術者にとって、ステートレス化とは「セッションがなくなった」という話で終わるかもしれない。
しかし、本質はそこではない。
私が感じたのは、
「責任が移動した」
ということだ。
これまでMCPは、多少なりとも状態を抱え込む存在だった。
クライアントと接続し、セッションを開始し、その後のやり取りを継続する。
つまり、「途中経過」をMCPが知っていた。
ところがステートレス化によって、その役割はなくなった。
毎回のリクエストは独立し、MCPは「今この瞬間」だけを見て処理する。
すると当然、一つの疑問が生まれる。
では、状態は誰が持つのか。
例えば、ChatGPTにこう頼んだとする。
「牛乳と卵を買っておいて。」
さらに、
「やっぱり牛乳は2本にして。」
「チーズも追加。」
「クーポンがあれば使って。」
この一連の流れは、一つの会話であり、一つの作業だ。
しかし、MCPはもう途中経過を覚えていない。
では誰が、
- 牛乳をカートへ入れたこと
- 数量を変更したこと
- チーズを追加したこと
- クーポン適用待ちであること
を管理するのだろうか。
答えはシンプルだ。
AIクライアントである。
ChatGPTやClaude、CursorのようなAIは、今後ますます「状態」を管理する存在になっていく。
会話。
タスク。
ワークフロー。
プロジェクト。
ユーザーの意図。
こうした情報を抱え込みながら、必要な場面でだけMCPを通じてサービスへアクセスする。
つまり、MCPは責任を放棄したのではない。
本来あるべき場所へ責任を返したのである。
ユーザーとの対話はAIクライアントが持つ。
注文や決済の正本はサービスが持つ。
MCPは、その二者を結ぶ通信だけを担当する。
この役割分担は、とても自然だ。
実際、GitHubのIssueやPull RequestをMCPが保持する必要はない。
Stripeが決済情報をMCPへ保存する理由もない。
データの正本は、もともとサービス側に存在している。
だからMCPは、それを毎回取得し、毎回操作するだけで十分なのだ。
そう考えると、今回のステートレス化は単なる通信仕様の変更ではない。
AIクライアント、MCP、サービス。
三者の責任範囲を整理し直した、アーキテクチャ全体の再設計なのである。
AIクライアントはますます巨大になる
この責任の移動によって、一つ確実に言えることがある。
AIクライアントの実装は、これまで以上に大きくなる。
例えば画像生成AIであれば、この変化はほとんど影響しない。
「画像を一枚生成してください。」
この要求は、一回のリクエストで完結する。
状態を持つ必要はない。
しかし、エージェントは違う。
例えば旅行を予約するAIを考えてみよう。
ユーザーはこう話しかける。
「来月、大阪から札幌へ二泊三日で旅行したい。」
その後、
「やっぱりホテルは駅の近くがいい。」
「飛行機は午前便で。」
「レンタカーは不要。」
「予算はあと2万円下げたい。」
この会話は、一つひとつは単純でも、全体としては一つのワークフローになっている。
航空会社。
ホテル。
決済。
クーポン。
ポイント。
保険。
それぞれ別のサービスと連携しながら、AIは「旅行プラン」という一つの状態を維持し続けなければならない。
MCPはもう、その状態を覚えてくれない。
つまり、AIクライアント自身が巨大な状態管理システムになるのである。
これはChatGPTだけの話ではない。
Claude。
Cursor。
Codex。
Gemini。
将来登場するあらゆるAIエージェントが、同じ課題に直面するだろう。
会話履歴だけでは足りない。
プロジェクト。
ワークフロー。
一時的なタスク。
途中保存。
失敗時の再開。
外部サービスとの整合性。
こうしたものを管理できるAIほど、使い勝手が良くなる。
私は以前、「MCPがAI時代の中心になる」と考えていた。
しかし今は逆だ。
MCPは薄くなる。
その代わりに、
AIクライアントそのものが、新しいOSのような存在へ進化していく。
AIは単なるチャット画面ではなくなる。
ユーザーの作業を理解し、複数のサービスをまたぎ、一つの仕事を最後までやり遂げる。
そのための責任を背負うのが、これからのAIクライアントなのだ。
サービスは再び主役になる
ここまで考えてきて、私はある誤解に気付いた。
AIが進化すると、多くのSaaSは価値を失う。
そんな話を、この一年ほど何度も目にしてきた。
しかし、それは半分だけ正しい。
AIが代替するのは、画面（UI）であって、サービスそのものではない。
例えばGitHubを考えてみよう。
AIはコードを書き、レビューし、Issueを読み、Pull Requestを作成する。
すると、一見するとGitHubの画面を開く機会は減るかもしれない。
しかし、コードの正本はどこにあるのか。
Pull Requestはどこにあるのか。
Issueはどこが管理しているのか。
答えは変わらない。
GitHubである。
Stripeも同じだ。
AIが決済処理を代行するようになっても、実際の決済履歴や返金情報、不正利用の判定はStripeが持っている。
Shopifyも同じである。
AIが商品を探し、カートへ入れ、購入まで代行したとしても、
商品情報。
在庫。
注文履歴。
配送状況。
返品情報。
これらの正本はShopify側に存在する。
つまり、AIが賢くなればなるほど、
サービスそのものの価値は失われない。
むしろ、より重要になる。
MCPが状態を持たなくなったことで、この構図はさらに明確になった。
MCPはデータを保存しない。
MCPはユーザーを管理しない。
MCPは注文も保持しない。
だから最終的な責任は、サービス自身が負うことになる。
これは少し意外だった。
私は以前、MCPがAI時代の新しい窓口になると思っていた。
しかし実際には逆だった。
MCPは一歩後ろへ下がり、
サービス自身が再び表舞台へ戻ってきた。
AIはサービスを置き換えるのではない。
サービスを操作する。
そしてサービスは、自らが持つデータを管理し続ける。
この役割分担が見えたとき、私はGoogleが発表したUniversal Cartを思い出した。
Universal Cartで見えたこと
GoogleがUniversal Cartを発表したとき、私は最初こう考えた。
「GoogleはECの入口だけではなく、購買そのものも支配しようとしているのではないか。」
AIが商品を探し、そのまま購入まで完了する。
そんな世界になれば、Googleが新しいショッピングモールになるようにも見えた。
しかし、MCPのステートレス化を見ているうちに、その考えは少し変わった。
Googleが持とうとしているのは、ECそのものではない。
もっと正確に言えば、
購買という体験を横断するための共通モデルである。
例えば、ある商品を購入するとしよう。
Googleは、
「この人は何を探しているのか。」
「どの商品を比較しているのか。」
「どのタイミングで買おうとしているのか。」
という入口の情報を持っている。
一方、Shopifyは、
「どの商品が存在するのか。」
「在庫はいくつあるのか。」
「実際に注文されたのか。」
という店舗側の情報を持っている。
さらにStripeは、
「決済は成功したのか。」
「返金されたのか。」
「不正利用ではないか。」
という金融の情報を持っている。
誰も、全部は持っていない。
そして、全部を持つ必要もない。
Universal Cartは、その間をつなぐ共通の器なのだ。
これはMCPとよく似ている。
MCPはサービスを支配しようとはしていない。
Universal CartもECを支配しようとしているわけではない。
どちらも目指しているのは、
異なるサービス同士が、同じ言葉で会話できる世界である。
もちろん、その共通化は非常に重要だ。
しかし、本当に価値があるものは、その先にある。
Googleが何十億件もの検索から蓄積した購買意図。
Shopifyが何百万もの店舗から集めた販売実績。
Stripeが何十億件もの決済から学習した信用情報。
これらは、プロトコルを標準化しただけでは手に入らない。
その瞬間、ようやく腑に落ちた。
標準化とは、データを共有することではない。
標準化とは、
「誰のデータを、誰が責任を持って管理するのか」を明確にすることでもあるのだ。
だからUniversal Cartの本当の価値は、カートのJSON形式ではない。
MCPの本当の価値も、通信フォーマットではない。
どちらも、AI時代の責任分界点を定義するためのインフラなのである。
本当に争っているもの
ここまで考えてきて、ようやく今回の一連の流れが一本につながった。
MCP。
Universal Cart。
GitHubの即日対応。
一見すると、まったく別の話である。
しかし、本質は同じだった。
最初は私も、
「標準規格の争い」
だと思っていた。
MCPが勝つのか。
UCPが広がるのか。
どのプロトコルが世界標準になるのか。
しかし、それは少し違う。
本当に争っているのは、プロトコルではない。
JSONでもない。
APIでもない。
通信方式でもない。
データそのものである。
もっと正確に言えば、
長年積み上げられてきた信用データだ。
例えばShopifyには、
何が売れたのか。
どんな店舗があるのか。
返品率はどうか。
という実績が蓄積されている。
Stripeには、
決済履歴。
チャージバック。
不正利用。
加盟店ごとの信用。
という金融データがある。
GitHubには、
コードだけではない。
コミット履歴。
レビュー。
Issue。
Pull Request。
開発プロジェクトそのものの歴史が存在する。
Salesforceには、
企業の営業活動そのものが記録されている。
どれも簡単には真似できない。
だからGoogleがUniversal Cartを標準化したとしても、
Shopifyの販売実績はGoogleのものにはならない。
MCPが世界標準になったとしても、
GitHubのコード資産がMCPへ移るわけではない。
標準化されるのは、
会話の方法だけだ。
データの所有権は変わらない。
むしろ、標準化が進むほど、その価値は際立っていく。
なぜなら、AIはどのサービスにも接続できるようになるからだ。
すると最後に差になるのは、
「誰が一番賢いプロトコルを持っているか」
ではない。
誰が一番価値あるデータを持っているか。
そこが競争になる。
私は以前、「AIがSaaSを食べる」という議論を何度も目にした。
しかし今は、少し違う景色が見えている。
AIが食べるのは、SaaSではない。
SaaSの画面である。
人間がブラウザで操作していた部分は、AIが代わりに操作するようになる。
しかし、その裏側でデータを持ち続けるサービスは、むしろ以前より重要になる。
AIは、そのデータなしには何も判断できないからだ。
だからAI時代の競争は、モデル性能だけではない。
それ以上に、
「誰が信用データを持っているのか」
という、静かな主権争いが始まっているのである。
MCPはHTTPになる
私は最初、MCPはAI時代の「主役」になる技術だと思っていた。
AIとサービスをつなぐ共通プロトコル。
あらゆる企業がMCPサーバを公開し、AIはそれを利用して仕事をする。
そんな未来を想像していた。
もちろん、その未来は今も変わらない。
ただ、一つだけ大きく見方が変わった。
MCPは、主役になろうとしていない。
今回のステートレス化は、その意思表示だったように思う。
状態を持たない。
ユーザーを持たない。
ワークフローを持たない。
サービスの責任も持たない。
MCPは、自らの役割を極限まで小さくした。
これはどこかで見た構図だ。
TCP/IP。
HTTP。
USB。
どれも世界中で使われている。
しかし、「HTTPを使っているからこのサービスを選ぶ」という人はいない。
USBが好きだから、このマウスを買う人もいない。
標準規格とは、本来そういう存在なのだ。
意識されない。
しかし、なくなると世界が止まる。
MCPも、おそらく同じ道を歩む。
AIエージェントが増えれば増えるほど、MCPを意識する人は減っていくだろう。
ChatGPTで買い物をする人は、「今MCPを使っています」とは考えない。
Claude CodeでGitHubを操作する人も、MCPを意識することはない。
彼らが意識するのは、
「AIがちゃんと仕事をしてくれるか」
それだけだ。
そして、その裏側で静かにMCPが動き続ける。
私は今回の仕様変更を見て、一つ確信した。
MCPは表舞台へ出ることをやめた。
だからこそ、世界標準になれる可能性がある。
標準規格とは、自らを主張しない技術だからだ。
おわりに
MCPは主役になることをやめた。
その代わりに、AIクライアントはより賢くなり、サービスは自らのデータに責任を持ち続ける。
GoogleがUniversal Cartで目指しているものも、GitHubが即日対応した理由も、その延長線上にある。
標準化が進めば進むほど、プロトコルの価値は均一化していく。
最後に競争力を生むのは、プロトコルではない。
長年積み重ねられた信用データである。
AI時代の競争は、モデル性能だけではない。
誰が最も価値あるデータへの扉を持っているのか。
そして、そのデータへ最も自然にたどり着けるAIクライアントを作れるのは誰なのか。
その競争は、もう静かに始まっている。
参照
