AIエージェントから外部ツールや社内データへ接続する標準として、Model Context Protocol（MCP）の採用が広がっています。しかし、ローカル環境で動かす段階では問題にならなかった「セッション管理」が、クラウド上で大規模運用すると大きなボトルネックになっていました。
2026年7月28日版のMCP仕様では、この課題へ対応するため、プロトコルの中核がステートレス化されました。従来必要だった初期化ハンドシェイクやMcp-Session-Idが削除され、各リクエストが単独で処理できる構造へ変わっています。
この変更により、一般的なHTTPロードバランサー、Cloud Runなどのサーバーレス環境、Kubernetesの水平スケーリングを利用しやすくなります。一方で、状態管理が不要になったわけではありません。セッション状態をプロトコル層からアプリケーション層へ移す変更であり、長時間処理やユーザー確認を含む処理では新しい設計が必要です。
本記事では、2026年7月28日版MCP仕様の変更点を、AIエージェント基盤を設計・運用するSEの視点で整理します。
先に押さえたい結論
MCPのステートレス化は、単なる通信仕様の変更ではありません。リモートMCPサーバーを本番運用するためのインフラ設計を大きく簡素化する変更です。
- セッション固定なしで通常のラウンドロビン負荷分散を使いやすくなる
- Podやコンテナが再起動しても、次のリクエストを別インスタンスで処理できる
- アイドル時にゼロスケールするサーバーレス構成を採用しやすくなる
- Gatewayでツール単位のルーティング、監査、レート制限を行いやすくなる
- 長時間処理や確認待ちは、MRTRやTasks拡張を使う設計へ移る
ただし、2026年8月6日時点では、主要SDKの対応はベータ版を含みます。既存システムを一度に切り替えるより、互換性を確認しながら段階的に移行するのが現実的です。
MCPとは何か
MCPは、AIアプリケーションやAIエージェントが外部のツール、データ、プロンプト、リソースへ接続するための共通プロトコルです。
たとえば、AIエージェントが次のような操作を行うときに利用されます。
- GitHubのIssueやPull Requestを取得する
- 社内データベースを検索する
- ファイルストレージから資料を読む
- 業務システムへデータを登録する
- 外部APIを呼び出して処理を実行する
MCPを採用すると、AIアプリケーション側が接続先ごとに独自連携を実装する必要を減らせます。ツール提供側も、共通仕様のMCPサーバーとして機能を公開できます。
初期のMCPは、1台のPC上でクライアントとサーバーを接続するstdio利用と相性の良い設計でした。しかし、MCPサーバーをHTTP経由でクラウドへ配置し、多数のユーザーからアクセスさせる段階になると、セッション管理が問題になります。
従来のMCPでセッションが問題になった理由
従来のHTTPベースMCPでは、クライアントが最初にinitializeを送り、サーバーがMcp-Session-Idを返す方式が使われていました。その後のリクエストは、同じセッションIDを付けて送信します。
この仕組みでは、サーバーがセッション情報をメモリに持っている場合、同じクライアントからのリクエストを同じPodやコンテナへ送る必要があります。
ラウンドロビンで「Session Not Found」が起こる
3台のPodでMCPサーバーを構成した場合、初回リクエストがPod Aへ入り、セッション情報がPod Aのメモリへ保存されたとします。次のリクエストが通常のラウンドロビンでPod Bへ送られると、Pod Bには該当セッションがありません。
その結果、セッションが見つからないエラーが発生します。一般的なWeb APIでは簡単な水平分散が、従来のMCPではそのまま使いにくい状態でした。
スティッキーセッションが必要になる
回避策として、ロードバランサーで同じ利用者を同じPodへ振り分けるスティッキーセッションを設定できます。ただし、特定Podへ負荷が偏りやすくなり、オートスケールの効率が下がります。
新しいPodを追加しても、既存セッションは元のPodへ固定されます。負荷の高いPodだけを柔軟に逃がすことが難しくなります。
Pod再起動でセッションを失う
Podやコンテナが再起動すると、メモリ上のセッション情報は失われます。デプロイ、障害、スケールインのたびに利用中の会話や処理が中断する可能性があります。
可用性を高めるためにRedisなどへセッションを保存する方法もありますが、読み書きの遅延、運用コスト、障害点が増えます。MCPサーバー自体より、セッション基盤の設計が複雑になるケースもあります。
2026-07-28仕様で変わったこと
初期化ハンドシェイクが削除された
2026年7月28日版仕様では、従来のinitializeとinitializedによるハンドシェイクが削除されました。クライアントとサーバーの接続開始時に、プロトコル用セッションを確立する必要がなくなります。
Mcp-Session-Idが削除された
論理セッションを示していたMcp-Session-Idヘッダーも削除されています。各リクエストは、特定のサーバーインスタンスへ固定されません。
各リクエストが自己完結する
従来は初期化時に交換していたプロトコルバージョン、クライアント情報、クライアントの対応機能などを、各リクエストの_metaへ含める方式になりました。
各リクエストだけを見れば、その処理に必要な情報が分かります。どのPodが受け取っても処理できるため、HTTPインフラとの相性が良くなります。
ステートレス化で得られる実務上のメリット
通常のロードバランサーを使いやすい
任意のMCPサーバーインスタンスが任意のリクエストを処理できるため、一般的なラウンドロビン負荷分散を採用しやすくなります。
Kubernetesでは、ServiceやIngressの標準的な分散方式を利用できます。セッションアフィニティを前提にした特殊な構成を減らせるため、運用担当者の負担も軽くなります。
水平スケーリングしやすい
アクセスが増えたときにPodを追加し、減ったときに削減する構成を取りやすくなります。特定セッションが残っていることを理由に、負荷の低いPodを停止できない問題も減ります。
社内向けAIエージェントでは、始業直後や会議前後など特定時間に利用が集中することがあります。ステートレスなMCPサーバーは、こうした変動に合わせてスケールしやすい設計です。
サーバーレスへ配置しやすい
Googleの公式解説では、Cloud RunやCloud Functionsのようなサーバーレス環境への配置が利点として挙げられています。
常時接続や固定セッションを持たないため、利用がない時間帯はインスタンスをゼロまで減らせます。利用頻度が低い社内ツールや、顧客ごとに分離したMCPサーバーでは、固定サーバーを常時稼働するよりコストを抑えられる可能性があります。
ただし、コールドスタートが許容できるかは検証が必要です。対話中に毎回大きな初期化処理が走る実装では、ステートレス化しても応答時間が悪化します。
障害や再デプロイに強くなる
特定Podへセッションを固定しないため、Podが停止しても次のリクエストを別Podへ送れます。ローリングアップデートやオートスケールを、利用者へ意識させず実施しやすくなります。
障害耐性が自動的に完成するわけではありません。外部APIへの書き込み途中で失敗した場合の再実行、重複実行防止、冪等性はアプリケーション側で設計する必要があります。
Redisの用途を減らせる
プロトコルセッションを維持するためだけにRedisを使っていた構成では、その保存処理を削減できる可能性があります。
ただし、非同期タスクの状態、ワークフローの進行状況、ユーザーごとの業務データまで不要になるわけではありません。後述するTasks拡張などでは、共有データストアが必要になるケースがあります。
HTTPヘッダーの標準化で何が変わるか
新仕様では、Streamable HTTPのPOSTリクエストに次のようなヘッダーを持たせます。
Mcp-Protocol-Version：MCPのプロトコルバージョンMcp-Method：実行するJSON-RPCメソッドMcp-Name：呼び出すツール、プロンプト、リソース名
これらの値はJSON-RPC本文にも含まれます。ヘッダーと本文が一致しない場合は、エラーとして拒否する仕様です。
Gatewayで本文を解析せずに制御できる
従来、API Gatewayやプロキシが「どのツールを呼んでいるか」を判断するには、JSON本文を解析する必要がありました。新仕様ではツール名やメソッドがHTTPヘッダーへ出るため、本文を深く解析せずに制御できます。
想定される使い方は次のとおりです。
- 危険度の高いツールだけ厳しいレート制限をかける
- 読み取りツールと更新ツールを別バックエンドへ振り分ける
- 特定ツールの呼び出し回数を監査ログへ残す
- 利用部署や契約プランごとに許可ツールを変える
- 障害中のツールだけ一時的に遮断する
業務システムでは、AIエージェントが何を実行したか追跡できることが重要です。ヘッダーだけでツール単位の監査や制御をしやすくなる点は、企業導入で大きな意味があります。
キャッシュ機能の追加
新仕様では、ツール一覧やリソース結果などへttlMsとcacheScopeを設定できる仕組みが導入されました。
ttlMsは、結果を何ミリ秒キャッシュしてよいかを示します。cacheScopeは、複数ユーザー間で共有できるキャッシュか、利用者単位に分離すべきかを示すために使われます。
ツール一覧が頻繁に変わらない場合、毎回MCPサーバーへ問い合わせる必要を減らせます。多数のエージェントから同じMCPサーバーへ接続する環境では、通信量とサーバー負荷の削減につながります。
ただし、権限によって表示可能なツールが異なる場合は注意が必要です。ユーザー固有の一覧を共有キャッシュへ保存すると、権限のないツール情報が見える可能性があります。キャッシュ範囲は認証・認可設計と合わせて決めるべきです。
ユーザー確認を扱うMRTR
ステートレス化すると、サーバーからクライアントへ確認を求める処理が難しくなります。従来はSSE接続を開いたままにして、サーバーから追加質問や確認要求を送る方法がありました。
新仕様のMulti Round-Trip Requests（MRTR）は、この処理を複数の独立リクエストへ分割します。
たとえば、AIエージェントが3件のファイルを削除しようとした場合、MCPサーバーは処理を実行せず、確認が必要であることとrequestStateを返します。クライアントは利用者へ確認し、その回答とrequestStateを付けて再度リクエストします。
requestStateに再開に必要な情報を含めるため、最初のリクエストと同じサーバーインスタンスへ戻る必要がありません。
実装時の注意点
requestStateを改ざんされない仕組みが必要- 有効期限を設定し、古い確認結果を再利用させない
- 確認前後で対象データが変わった場合の再検証が必要
- 同じ確認応答が複数回送られた場合の重複実行を防ぐ
- 削除や決済では、対象件数や金額を再表示する
ステートレスだから安全になるわけではありません。状態をクライアントとの往復データへ移すため、署名、暗号化、有効期限、冪等性がより重要になります。
長時間処理を扱うTasks拡張
データベースのバックアップ、CRM同期、大量ファイル解析など、数十秒以上かかるツール処理では、HTTP接続を開いたまま待つ設計は不安定です。
Tasks拡張では、長時間処理を開始した時点でtaskIdを返し、処理をバックグラウンドで継続します。クライアントはtasks/getやtasks/updateなどを使って進捗と結果を確認します。
これにより、AIエージェントは利用者との会話を止めず、「処理を開始しました。完了後に結果を確認します」と返せます。
プロトコルはステートレスでも業務タスクはステートフル
ここは誤解しやすい点です。MCPの通信がステートレスになっても、長時間処理の状態はどこかへ保存する必要があります。
taskId、進捗、結果、エラー、開始者、権限、再試行回数などは、データベースやRedisなどの共有ストアで管理します。削減できるのは「通信セッションを維持するための状態」であり、業務処理の状態ではありません。
セキュリティ面の変更
Issuer Verification
パブリッククライアントは、認可レスポンスのissパラメータを検証する必要があります。複数の認可サーバーやMCPサーバーを扱う環境で、別の発行元から返されたレスポンスを誤って受け入れるリスクを減らします。
Resource Indicators
アクセストークンをどのMCPサーバー向けに発行するのか明示します。あるサーバー向けのトークンを別のサーバーへ転用される「confused deputy」問題への対策です。
JSON Schema 2020-12
ツールの入力スキーマで、oneOf、anyOf、allOf、ローカル$refなどを利用できます。入力条件を詳細に表現でき、サーバー側で厳格に検証しやすくなります。
AIモデルが生成するツール引数は、常に正しいとは限りません。型だけでなく、許可値、条件分岐、必須項目をスキーマで制約し、ツール実行前に検証することが重要です。
非推奨になる機能
2026年7月28日版仕様では、初めて正式な非推奨ポリシーが導入されました。機能はActive、Deprecated、Removedの段階で管理され、原則として最低12か月の移行期間が設けられます。
今回、次の3機能が非推奨となりました。
- Roots：明示的なツール引数、リソースURI、サーバー設定へ置き換える
- Sampling：LLMプロバイダーAPIを直接呼び出す方式へ置き換える
- Logging：stdioでは標準エラー、クラウドではOpenTelemetryなどへ置き換える
既存MCPサーバーがこれらへ依存している場合、すぐに停止するわけではありませんが、今後の削除を見据えた移行計画が必要です。
既存MCPサーバーの移行で確認したいこと
SDKの対応状況
Googleの2026年8月5日付解説によると、TypeScript、Python、Go、C#のTier-1 SDKには、2026-07-28仕様へ対応するベータ版が用意されています。
ベータ版は仕様変更や不具合修正が入る可能性があります。本番環境へ導入する場合は、利用しているクライアントとサーバーの両方が同じ仕様へ対応しているか確認します。
セッション依存コードの洗い出し
次のような実装がある場合は、ステートレス化の影響を受けます。
- セッションIDをキーにメモリへ情報を保存している
- 初期化時に権限や設定を確定している
- SSE接続へ確認要求をプッシュしている
- 特定Podへ固定される前提で一時ファイルを保存している
- クライアント情報を初期化時にだけ検証している
各リクエストで検証すべき情報と、外部ストアへ保存すべき業務状態を分けて整理します。
冪等性の追加
障害時に別インスタンスへ再送しやすくなる一方、同じ処理が複数回届く可能性も考慮する必要があります。
データ更新、メール送信、決済、ファイル削除などは、リクエストIDや業務キーを使って重複実行を防ぎます。ロードバランサーやクライアントの再試行設定も確認します。
監視項目の見直し
セッション数を中心に見ていた監視から、次のような指標へ変える必要があります。
- ツール別の呼び出し回数と失敗率
- 処理時間の分位点
- 再試行率と重複排除数
- 非同期タスクの滞留数
- コールドスタート回数
- 認証・認可エラー
- ヘッダーと本文の不一致エラー
フリーランスSEが提案時に注意したい点
MCPの新仕様を顧客へ提案するときは、「Redisが不要になる」「サーバーレスにすれば安くなる」と断定しない方が安全です。
実際には、利用するツールの処理時間、同時実行数、データ保存、認証、監査、外部APIの制限によって必要な構成が変わります。
提案前に最低限確認したい項目は次のとおりです。
- MCPサーバーを社内限定にするか外部公開するか
- 同時利用者数とピーク時の呼び出し数
- 読み取りだけか、更新・削除・決済も行うか
- ユーザー確認が必要な操作があるか
- 10秒以上かかる長時間処理があるか
- 再実行時に重複すると困る処理があるか
- 監査ログを何年間保存するか
- 利用するSDKの正式版待ちが可能か
小規模な社内検索ツールと、外部顧客向けの業務エージェントでは求められる設計が大きく異なります。プロトコルの新しさだけで採用を決めず、業務上のリスクを基準に判断する必要があります。
移行は段階的に進める
既存のMCP環境を移行する場合は、次の順序が現実的です。
- 現在利用しているMCP仕様とSDKバージョンを確認する
- 初期化、セッションID、SSEに依存する箇所を洗い出す
- 読み取り専用ツールで新仕様の検証環境を作る
- 複数Podへ分散し、連続リクエストが正常に動くか確認する
- Pod停止中のフェイルオーバーを確認する
- MRTRとTasks拡張が必要な業務を分類する
- 認証、監査、冪等性を追加する
- 一部利用者から段階的に切り替える
検証では正常系だけでなく、タイムアウト、二重送信、Pod再起動、古いクライアントからのアクセス、ヘッダー改ざんも確認します。
向いているケースと慎重に進めたいケース
新仕様への移行効果が大きいケース
- リモートMCPサーバーを複数Podで運用している
- スティッキーセッションやRedisの管理が負担になっている
- 利用者数の増減が大きい
- Cloud Runなどのサーバーレスへ移行したい
- Gatewayでツール単位の制御と監査を行いたい
- 複数テナントへMCP機能を提供したい
慎重な検証が必要なケース
- 既存クライアントが古い仕様に固定されている
- SSEを使った独自の双方向処理が多い
- 決済や削除など失敗時の影響が大きいツールを持つ
- ベータSDKを本番利用できない
- セッションメモリへ大量の業務状態を保存している
- 複数バージョンのクライアントを長期間共存させる必要がある
まとめ
2026年7月28日版MCP仕様のステートレス化は、リモートMCPサーバーをクラウドで運用するうえで大きな転換点です。
初期化ハンドシェイクとMcp-Session-Idが削除され、各リクエストが自己完結することで、通常のロードバランサー、水平スケーリング、サーバーレス、Pod障害時の切り替えを利用しやすくなりました。
一方で、状態そのものが消えるわけではありません。ユーザー確認はMRTR、長時間処理はTasks拡張、業務状態は共有データストアで管理する必要があります。再試行による重複実行を防ぐ冪等性や、ツール単位の認可・監査も欠かせません。
既存環境では、セッション依存コードを洗い出し、読み取り専用のツールから段階的に検証するのが安全です。2026年8月6日時点ではベータSDKを含むため、仕様とSDKの更新を確認しながら移行してください。
参考情報
- Google Developers Blog：Scaling AI Agent Infrastructure with the MCP Stateless updates
- Model Context Protocol Specification 2026-07-28
※本記事は2026年8月6日時点の公開情報を基にしています。MCP仕様、SDKの対応状況、ベータ版の導入方法は変更される可能性があります。実装前に最新の公式仕様と利用SDKのリリースノートを確認してください。
コメント