MCPのステートレス化でAIエージェントをCloud Runでスケールさせる

MCP（Model Context Protocol）の2026-07-28仕様で、プロトコルの完全ステートレス化が実現したと記事は伝えている。従来のMCPはHTTP経由で初期化ハンドシェイクを行い、発行されたMcp-Session-Idを後続のすべてのリクエストに紐付ける必要があった。このためロードバランサーでセッションが合わずにエラーが起きたり、スティッキーセッションやRedisを挟んで費用と遅延が増えたり、Podの再起動で会話の文脈が消えたりしていた。新仕様では初期化とセッションIDが撤廃され、各リクエストの_metaに必要な情報をすべて含める自己記述型に変わった。HTTPヘッダーにもMcp-Protocol-Version、Mcp-Method、Mcp-Nameが付くため、ボディを開かずに経路を決められる。ユーザーへの確認が必要な処理は状態をrequestStateとして返し、次のリクエストでそのままエコーバックする。長時間の処理はtaskIdを即時に返すTasks Extensionで扱う。 AIの鬼の視点で言えば、従来のMCPは「店員が客の顔を覚えて、次も同じ店員が対応する」方式だった。新仕様は「客がレシートを持ってくれば、どの店員でも処理できる」方式に変わった、と考えると分かりやすい。店員の記憶をRedisに預ける代わりに、客が毎回レシートを持つ。設計としては見事な転換だが、代償として一回ごとのリクエストは少し重くなり、サーバー側の記憶に頼って作ってきた開発者は作り直しを迫られる。記事は「Cloud Runのまま置くだけで自動でスケールする」と書くが、それは移行の手間を小さく見せすぎている。ベータ版のSDKを本番の基幹に載せるのは、設計思想の話とは別の判断である。 中小企業の実務に落とすなら、社内向けのMCPサーバーを自作している会社はまだ少ないだろう。もし外部のAIツールと社内データをつなぐ試作をしているなら、まず「セッションを覚えさせる仕組みがあるか」「Redisやスティッキーセッションを何のために入れたか」を確認するとよい。利用頻度の低い社内ツールであれば、ゼロスケールの運用は費用を抑えるうえで効きやすい。ただし、TypeScript v2 betaやPythonのmcp==2.0.0b1といったベータ版は、まず検証環境で既存の動作との差分を見る段階にとどめるべきだ。