既存のMCPサーバーを運用していると、セッション管理や負荷分散の設計を今後どう見直すべきか気になっている方も多いのではないでしょうか。2026年7月28日に公開されたModel Context Protocol (MCP) のリリース候補では、MCP AppsやTasks、拡張可能なプロトコルフレームワーク、認可・トランスポート機能の改善など、開発者がMCPで実現できる範囲を大きく広げる変更が加えられました。

しかし、その中でも1つの設計変更こそ、今後何年にもわたって企業のAIシステムの構築方法を左右する可能性を持っています。本記事では、身近な例を交えながらこの変更の意味を解説します。

Model Context Protocolはステートレスになる

MCPの公式発表では、プロトコル変更の詳細が説明されています。今回のリリースで加わった変更点を一通り押さえておきたい方は、MCPサーバーの6つの変更点まとめもあわせてご覧ください。本記事ではあえて少し違う角度から、ステートレス化という1点に絞ってこの変更を見ていきます。

着目するのは何が変わったかではなく、なぜそれが重要なのかという点です。特に、業務システムやデータと連携するAIアプリケーションを構築している企業にとって、この変更がどんな意味を持つのかを掘り下げます。

AIが実験段階から本番運用へ移るにつれ、設計の重要性はモデルの性能と肩を並べつつある。

「ステートレス」とは、実際何を意味するのか？

「ステートレス」は、実態より難しく聞こえがちな技術用語の1つです。身近な例で考えると、理解しやすくなります。

身近な例で考える

例: コーヒーの注文 毎朝行きつけのコーヒーショップに立ち寄る場面を思い浮かべてください。バリスタはあなたの顔を覚えていて、名前も好みのドリンクも、オーツミルクとエスプレッソ追加が好きなことも把握しています。あなたはただ笑顔で「いつもの」と言うだけです。

バリスタが過去の来店情報を覚えているからこそ、次回以降のやり取りは短く、個別対応もしやすくなります。これがステートフルなやり取りです。

一方、スマホアプリで注文する場合はどうでしょうか。

注文のたびに、名前・ドリンクの好み・受け取り場所・支払い情報がすべて含まれます。注文の処理に必要な情報がリクエスト自体に含まれているため、どのバリスタが対応してもコーヒーを用意できます。誰もあなたの前回の来店を覚えておく必要がありません。これがステートレスなやり取りです。

技術的な視点で見る

ソフトウェアの世界では、ステートフルなプロトコルはクライアントとサーバー間の過去のやり取りの情報を保持します。以降のリクエストはその保存された文脈に依存することが多く、接続そのものがアプリケーションの状態の一部になります。

一方、ステートレスなプロトコルは、すべてのリクエストを独立したものとして扱います。各リクエストには、過去のやり取りに頼らずサーバーが処理するために必要な情報が含まれています。

ステートレスは「記憶を持たない」という意味ではありません。 アプリケーション側では、会話履歴・認証情報・ワークフロー・ユーザー設定などを引き続き保持できます。違いは、その状態をプロトコルが暗黙的に管理するのではなく、アプリケーションが明示的に管理する点です。

現代のWebアプリケーションの多くがREST APIを通じてこの設計を採用しているのも、スケーリングや負荷分散、耐障害性がシンプルになるためです。突き詰めれば、考え方はいたってシンプル。

「ステートフルなシステムは過去のやり取りを記憶する。ステートレスなシステムは、処理に必要な情報をすべて含めることで、各リクエストを独立したものとして扱う」

なぜ重要なのか

企業が営業・カスタマーサポート・エンジニアリング・オペレーションといった領域にAIエージェントを展開するにつれて、AIアプリケーションと業務システム間のやり取りは急速に増えていきます。

ステートレスなプロトコルであれば、こうしたやり取りをクラウドインフラ全体に効率よく分散できます。結果として、水平スケールと障害復旧のしやすさを兼ね備え、本番環境でもよりクリーンに動作するAIアプリケーションが実現します。

これまでのMCPはどう動いていたのか

7月28日のリリース候補より前、MCPはクライアントとサーバー間の通信を維持するためにプロトコルレベルのセッションに依存していました。

AIクライアントがMCPサーバーに接続すると、サーバーはやり取りの間ずっとそのセッション情報を保持していました。以降のリクエストは、確立されたそのセッションに依存する形になっていたのです。

この方式は一部のワークフローをシンプルにする一方で、デプロイ規模が大きくなるにつれて運用上の課題を生んでいました。主な課題は次の通りです。

• リクエストが同じサーバーインスタンスに戻る必要があることが多い

• ロードバランサーがスティッキーセッションを維持しなければならない

• サーバー障害が進行中の会話を中断させてしまう

• 水平スケーリングには、セッション状態を保持・共有するための追加インフラが必要になる

これらはどこか見覚えのある課題ではないでしょうか。REST APIが主流の設計スタイルになる前、多くのWebアプリケーションはサーバー側のセッションに依存しており、同じようなスケーラビリティの制約に直面していました。MCPサーバーの基本的な仕組みや構築・運用の流れを一から確認したい方は、MCPサーバーの構築・運用ガイドが参考になります。

例: 銀行のカスタマーサポート 銀行のカスタマーサポートに電話をかけた場面を想像してください。口座について話す前に、担当者は口座番号・生年月日・セキュリティコードで本人確認を求めます。確認が済めば、担当者がそのやり取り（セッション）を覚えているため、情報を繰り返すことなく複数の質問ができます。

これもステートフルなやり取りです。会話は、通話の冒頭で確立された文脈に依存しています。

7月28日のリリースで何が変わったのか？

ステートレスな設計への移行は、単なるプロトコルのアップデートにとどまりません。MCPのクライアントとサーバーが通信し、文脈を管理し、分散環境で動作する方法そのものを変えるものです。

1. 接続時のハンドシェイクが不要になった

身近な例で考える

例: ホテルのチェックイン 毎朝ホテルに入るたびに、フロントでのチェックインが欠かせない場面を思い浮かべてください。タオルの交換や道順を尋ねる前に、まず本人確認をし、予約を確認し、部屋の情報を受け取る必要があります。

スマートフォンにデジタルルームキーを持っていたら、どうでしょうか。何か必要なときは、ルームキーを見せるだけです。ホテル側はすぐにあなたが誰かを把握でき、チェックインの手続きを一から繰り返すことなく対応できます。

MCPで起きた変化も、本質的にはこれと同じです。

技術的な視点で見る

これまでのMCPでは、実質的な処理を始める前に initialize と initialized のハンドシェイクが必要でした。このやり取りの中で、クライアントとサーバーはプロトコルバージョンをすり合わせ、クライアント情報を交換し、それぞれの機能を通知していました。

リリース候補では、この手順が不要になりました。

代わりに、プロトコルバージョンとクライアント情報はすべてのリクエストの _meta フィールドに含まれるようになります。クライアントがサーバーの機能を知りたい場合は、新しい server/discover メソッドを必要なときに呼び出せます。

なぜ重要なのか

すべてのリクエストが自己完結型になるため、接続管理のオーバーヘッドが減り、やり取り自体もシンプルで壊れにくいものになります。

2. プロトコルレベルのセッションがなくなった

身近な例で考える

例: 荷物の配送 全国規模の荷物配送を例に考えてみましょう。これまでは、集荷から配達まで同じ配送ドライバーが担当する必要がありました。荷物に関するすべての情報をそのドライバーが覚えていたからで、対応できない場合は荷物をスムーズに届けられませんでした。

一方、すべての荷物に届け先・内容物・配送指示を記した配送ラベルが貼られているとしたら、どうでしょうか。対応可能などのドライバーでも、途切れることなく集荷・配送を引き継げます。これが、ステートフルなプロトコルとステートレスなプロトコルの違いです。

技術的な視点で見る

これまでのMCPは、プロトコルレベルのセッションを維持するために Mcp-Session-Id ヘッダーに依存していました。セッションが確立されると、リクエストはそのセッションを作成したサーバーインスタンスに紐づいていました。

リリース候補では、プロトコルレベルのセッションが完全になくなりました。

すべてのリクエストが処理に必要な情報を自ら持つようになったため、正常に稼働しているどのサーバーインスタンスでもそのリクエストを処理できます。

なぜ重要なのか

リクエストが特定のサーバーに縛られなくなるため、ロードバランシング・オートスケーリング・フェイルオーバーが大幅にシンプルになります。

3. 状態はなくなったのではなく、明示的になった

身近な例で考える

例: オンラインショッピング オンラインで買い物をする場面はどうでしょうか。Webサイトは、あなたのブラウザ接続をずっと覚えているわけではありません。代わりに、商品をカートに追加すると、アカウントに紐づくショッピングカートやカートIDが発行されます。

以降の操作はすべて、そのカートを参照します。各リクエストが独立していても、買い物の体験そのものは途切れることなく続きます。

技術的な視点で見る

プロトコルレベルのセッションをなくしたからといって、アプリケーションの状態がなくなるわけではありません。状態が管理される場所が、プロトコル層からアプリケーション層に移るだけです。

文脈を保持する必要があるサーバーは、basket_id や browser_id、workflow_id といった識別子を返すだけです。以降のリクエストにその識別子を含めることで、処理を中断したところから続けられます。

これは、REST APIが長年採用してきたのと同じ設計パターンです。

ここで発行するハンドルは中身を推測できないopaqueな値にし、利用者・対象操作・状態のバージョン・有効期限と紐づけておくのが安全です。また、決済や登録のように副作用を伴う操作では、リクエストにidempotencyキーを含めておくことで、再送信が発生しても同じ処理を二重実行せずに済みます。

なぜ重要なのか

状態が明示的になることで、動作の把握やデバッグがしやすくなり、トランスポート層の実装からも独立します。

4. インタラクティブなワークフローが再設計された

身近な例で考える

例: 住宅ローンの申し込み オンラインで住宅ローンを申し込む場面を思い浮かべてください。審査の途中で、銀行から収入証明書のアップロードを求められたとします。

申し込みを一からやり直す必要はありません。銀行は提出内容をいったん保留し、書類の到着を待ってから、止まっていた処理を再開します。

インタラクティブなMCPのワークフローも、今はこれと同じ仕組みで動いています。

技術的な視点で見る

ステートレスなプロトコルであっても、サーバーがリクエストを完了する前に追加情報を必要とする場面はあります。その場合、長時間持続するServer-Sent Events (SSE) 接続を維持するのではなく、サーバーは InputRequiredResult とエンコードされた requestState を返します。

必要な入力を収集した後、クライアントは返された状態とともに元のリクエストを再送信します。必要な文脈がすべてリクエストとともに運ばれるため、どのサーバーインスタンスでも処理を再開できます。

なぜ重要なのか

永続的な接続に頼らずにインタラクティブなワークフローを実現でき、耐障害性とスケーラビリティが向上します。

5. 運用がシンプルになる

身近な例で考える

例: 空港の手荷物の流れ 混雑する空港での手荷物の流れを思い浮かべてみましょう。すべてのスーツケースが同じ見た目だったら、保安担当者は行き先を確認するために1つずつ開けて調べる必要があります。

一方、すべてのスーツケースの外側に行き先・航空会社・優先度・追跡情報がはっきり表示されているとしたら、どうでしょうか。仕分けは劇的に速く、簡単になります。ネットワークトラフィックにも同じ原理が当てはまります。

技術的な視点で見る

リリース候補では、運用面でもいくつかの改善が加えられています。リクエストには Mcp-Method と Mcp-Name のヘッダーが含まれるようになり、ゲートウェイやロードバランサーはリクエストの中身を調べなくてもトラフィックを振り分けられます。

レスポンスには ttlMs と cacheScope を含められるようになり、HTTP Cache-Control に似た標準化されたキャッシュ動作が可能になります。

仕様ではW3C Trace Context標準も正式に採用されており、traceparent・tracestate・baggage を使ってトレース情報をMCP全体に伝播できます。これにより、OpenTelemetry のようなプラットフォームを通じたエンドツーエンドの可観測性が実現します。

なぜ重要なのか

リクエストの振り分けとレスポンスのキャッシュが容易になるだけでなく、分散型のAIシステムの監視とトラブルシューティングが格段に楽になります。エンタープライズでMCPを安全に統制していくための運用体制は、エンタープライズMCPガバナンスガイドもあわせてご確認ください。

早見表: ステートフルなMCPからステートレスなMCPへ

7月28日のリリース候補では、複数のプロトコルレベルの変更が加えられました。これらが組み合わさることで、MCPはステートフルなプロトコルから、現代のクラウドネイティブな設計に自然に合致するプロトコルへと変わります。それぞれの変更にも個別のメリットがありますが、まとめて見るとデプロイのシンプルさとスケーラビリティの両立が実現し、本番環境でのMCP運用がしやすくなります。

なお、initializeハンドシェイクやMcp-Session-Id、旧来のHTTP+SSEストリーミングといった非推奨となった機能には最低12か月の移行猶予期間が設けられており、既存のMCPサーバーがいきなり動かなくなる心配はありません。

これらの変更を総合すると、プロトコル自体がシンプルになり、現代の分散環境でのMCPのデプロイ・スケーリング・運用が格段に容易になります。AIアプリケーションが業務システムと連携し始めると、この設計上のメリットはさらに際立ちます。そこでは、モデルの性能と同じくらい、信頼性・スケーラビリティ・運用面での耐障害性が重要になるからです。

ステートレスは「記憶を持たない」という意味ではない

よくある誤解の1つに、「ステートレスなシステムは何も覚えられない」というものがあります。しかし、それは正しくありません。例で確認してみましょう。

オンラインバンキングのアプリにログインする場面を想像してみてください。口座残高を確認するたびに、サーバーが以前のネットワーク接続を覚えている必要はありません。

代わりに、認証トークンがあなたを識別し、アプリケーションが口座情報・残高・取引履歴を取得できるようにしています。同様に、AIアプリケーションも次のような情報を保持し続けられます。

• 会話履歴

• ユーザー設定

• 認証情報

• 長時間実行されるワークフロー

• 業務コンテキスト

違いは、その情報がどこで管理されるかにあります。状態をプロトコル自体の内部に隠すのではなく、トランスポート層はステートレスのまま、アプリケーション側が状態を明示的に管理する、という点です。

この分離により、設計がすっきりし、インフラがシンプルになり、運用の柔軟性も高まります。

企業向けAIにとって、なぜこれが重要なのか

企業向けのAIアシスタントが、営業担当者の重要な顧客商談の準備を手伝う場面を思い浮かべてください。担当者はシンプルな質問を投げかけます。

「今日の商談の前に、Acme社について知っておくべきことを全部教えて」

この1つのリクエストに答えるために、AIアシスタントは次のような情報を取得する必要があるかもしれません。

• Salesforceの進行中の商談

• JiraやZendeskのサポートケース

• データウェアハウスの製品利用状況

• ERPシステムの請求情報

• SharePointの契約書

• Microsoft Teamsの直近の会議メモ

一見1つの会話に見えても、裏側では数十件もの独立したMCPリクエストが動いている場合があります。ステートレスな設計であれば、1つの長時間セッションに依存することなく、これらのリクエストをそれぞれ利用可能などのMCPサーバーでも処理できます。

営業・カスタマーサポート・エンジニアリング・財務・オペレーションといった領域に、企業が数百、数千ものAIエージェントを展開していくにつれて、この設計上の柔軟性はますます重要になっていくでしょう。本番環境でAIエージェントを安定稼働させるための設計は、Production-readyなエージェント設計ガイドで詳しく解説しています。

認可まわりの変更も見逃せません。今回のリリース候補ではOAuth 2.0・OpenID Connect (OIDC) への準拠が明確化されており、Microsoft Entra IDやOktaといった企業で使われるID基盤とMCPサーバーを橋渡ししやすくなります。アクセス制御や監査のしやすさという点では、先ほど触れたガバナンス面の運用体制ともつながる部分です。

企業のデータ連携にとって、なぜこれが重要なのか

企業向けAIの価値は、アクセスできるデータの質と範囲に左右されます。

AIアシスタントがモデルの知識だけで質問に答えることは、ほとんどありません。実際には、複数の業務システムからリアルタイムの業務データを取得し、結果を組み合わせて意味のあるインサイトを生成しています。

ここで重要になるのが、企業のデータ連携とデータプレーンの存在です。CRM・ERP・サポートプラットフォーム・データウェアハウス・業務アプリケーションとのやり取りは、そのたびに効率的かつ確実に処理すべきリクエストを生み出します。こうした複数システムをまたぐMCPサーバーをどう設計すべきかは、MCPの設計パターン徹底解説で選定の勘所を確認できます。

ステートレスな設計であれば、こうしたリクエストを複数のサーバーに分散させやすくなり、次のような効果が得られます。

• 水平スケーラビリティ

• 高可用性

• 耐障害性の向上

• シンプルな負荷分散

• クラウドネイティブなデプロイ

• 運用と可観測性の向上

リアルタイムの業務データに依存するAIアプリケーションを構築する企業にとって、こうした設計上の改善は、そのまま信頼性が高く障害に強いシステムにつながります。

なぜこれが現代のクラウド設計と合致するのか

ステートレスな通信への移行は、AI特有の動きではありません。

Kubernetes、サーバーレスプラットフォーム、APIゲートウェイ、オートスケーリングインフラなど、現代のクラウドプラットフォームはいずれもステートレスなサービスを前提に設計されています。デプロイ・監視・復旧・スケーリングがしやすいからです。

同じ設計モデルを採用することで、MCPは特別なデプロイモデルを必要とせず、既存のクラウドネイティブな運用にAIインフラを自然に組み込めるようにします。

企業のエンジニアリングチームにとって重要なのは、インターネット規模ですでに実績のある運用パターンをそのまま活用できるという点だ。

今後の展望

7月28日のMCPリリース候補では多くの重要な機能が追加されましたが、長期的に見て最も大きな変化になるのは、ステートレスな設計への移行かもしれません。

MCP AppsやTasksといった機能は、開発者が構築できる範囲を広げます。一方でステートレスな設計は、そうしたアプリケーションがどれだけ確実にスケールし、障害から復旧し、現代のクラウドインフラに組み込めるかを左右します。

業務アプリケーションやデータプラットフォームと連携するAIエージェントを、企業がますます多く展開していく中で、設計の重要性はモデルの性能と同じくらい増していく。

知性はモデルから生まれます。その知性を企業規模で運用する力は、プラットフォームから生まれます。

参考文献

• Model Context Protocol.「2026年7月28日 MCP仕様リリース候補」

• Model Context Protocol.「認可仕様」

よくある質問（FAQ）

MCPサーバー運用をConnect AIで簡単に

MCPのステートレス化で、AIエージェントが使うMCPサーバーの設計はより重要になります。CData Connect AIなら、400種類以上のデータソースをコード不要でMCPサーバーとして公開でき、セッション管理やインフラの構築・運用にかかる負担を減らせます。認証やアクセス制御も管理画面から一元的に設定できるため、部門をまたいだ展開でもチーム全体で安心して運用できます。実際に、あるAI SaaSプラットフォーム企業では、MCPをAIとエンタープライズシステムをつなぐ標準インターフェースとして採用したことで、データ連携にかかる期間を80%以上短縮できたという導入事例もあります。

Connect AIの14日間無料トライアルを開始して、ステートレスなMCPサーバーをコード不要で構築できることを確かめてください。