AIの道具連携は、つながりっぱなしでなくていい。
AIに検索、社内データ、決済、ファイル操作などの道具を渡すとき、裏側では「どのサーバーにつながっているか」を覚えておく必要がありました。
2026年7月28日、Model Context Protocol（MCP）の新仕様が公開されました。接続を一度つないで維持する設計から、リクエスト一つで完結する設計へ。見た目は地味ですが、AIの道具を増やし、利用者を増やすときに効く変更です。
same request
以前のMCPでは、HTTPで道具を呼び出す前に初期化のやり取りをし、サーバーから受け取ったセッションIDを次の通信でも送り返す流れが一般的でした。小さな検証では問題ありません。利用者とリクエストが増えると、そのセッションをどのサーバーで持つかが運用上の仕事になります。
MCPは、AIが外部の道具を使うための共通口
たとえばAIに「社内の予定を調べて」「このデータベースを検索して」「このファイルを要約して」と頼む場面があります。MCP（Model Context Protocol）は、AIと外部サービスの間で、どんな道具があり、何を入力し、どんな結果が返るかをそろえる共通の接続方法です。
今回の中心は、道具の種類が増えたことではありません。道具を呼び出す通信の土台が変わりました。
セッションを持つ
最初に握手をして、サーバーが発行したIDを後続リクエストで使います。負荷分散には固定接続や共有ストレージが必要になりやすい。
リクエストを自己完結
各リクエストにプロトコルの版、クライアント情報、能力を含めます。必要なら server/discover で事前に道具の情報を取得できます。
新仕様では initialize / initialized の交換と Mcp-Session-Id が新しい通信方式の必須条件ではなくなりました。古いクライアントとの互換性は、実装側が旧方式へ戻れるようにして保ちます。
便利になるのは、AIの回答よりも「裏側の増やしやすさ」
一台のサーバーで試す限り、セッションの有無は見えにくいものです。複数台に増やし、地域をまたいで配置し、ツールの一覧を何度も取得する段階で差が出ます。
どのサーバーでも受けやすい
一回のリクエストが自己完結していれば、ロードバランサーが空いているサーバーへ振り分けやすい。特定のサーバーにセッションを戻す仕組みや、全台で状態を共有する仕組みを減らせます。
ゲートウェイで判断しやすい
メソッド名やツール名をHTTPヘッダーで扱えるようになり、途中のゲートウェイが「どの道具への依頼か」を見てルーティングや認可を設計しやすくなります。
道具の一覧を再利用しやすい
ツール一覧のレスポンスにはキャッシュの手がかりと決定的な順序が追加されました。頻繁に変わらない一覧を毎回ゼロから取り直す負担を抑えられます。
確認を求めるAIにも、長い接続はいらない
「この操作を実行していいですか？」とAIが利用者に確認する場面では、サーバーからクライアントへ質問を返す必要があります。以前は接続を開いたまま待つ仕組みが中心でした。
MRTR（Multi Round-Trip Requests）は、質問を一つの長い接続に押し込めず、途中状態を示すトークンを使って複数回の往復に分ける考え方です。削除、支払い、権限変更の前に確認を挟むような道具に向きます。
7月28日に、いきなり全部壊れたわけではない
ここは大事です。新仕様は互換性を変える内容を含みますが、対応していないクライアントが当日突然使えなくなる、という意味ではありません。AWSの公式説明でも、旧版と新版を同時に広告する場合、旧版を選ぶクライアントの動作は変わらず、新版を選んだ通信だけ新しい挙動になります。
TypeScript SDK v2の移行ガイドでは、通常の接続は従来方式が初期値で、新方式は明示的な設定で選ぶ案内になっています。
公式Go SDKの対応版は `2026-07-28` を実装し、旧版へ自動的にネゴシエーションできます。まずテスト用サーバーで両方のクライアントを確認します。
ステートレスは「サービスが状態を持てない」という意味ではありません。買い物かごIDやジョブIDのように、継続に必要なIDを自分のデータとして明示的に渡します。
セッションIDを前提にした認証、キャッシュ、進捗通知、ユーザーごとの分離が見つかれば、移行時の論点になります。新仕様に切り替えることは、設定値を変えるだけの作業とは限りません。
「ステートレス＝安全・万能」ではない
接続状態が減ると運用は軽くなります。ただし、AIに道具を使わせる危険が消えるわけではありません。
状態を消すのではない
会話や処理の継続に必要な情報は、明示的なIDと権限管理を通じてアプリ側で保持します。IDを推測されにくくし、他ユーザーの状態へ届かない検証が必要です。
認証の設計は残る
新仕様ではOAuthの発行者確認など認証の強化も含まれますが、MCPサーバーを公開すれば安心ということではありません。接続元、道具ごとの権限、監査ログを分けて考えます。
古い機能はすぐ消えない
Roots、Sampling、Loggingや旧HTTP+SSEは非推奨になりました。少なくとも12か月の移行期間が示されていますが、新規実装で古い仕組みに依存する理由は減っています。
今日試すなら、仕様書より先に接続の棚卸しをする
まだMCPサーバーを運用していない人は、対応SDKのサンプルを一つ動かせば十分です。すでに運用している人は、次の三つだけ記録すると移行の輪郭が見えます。
最初の問いに戻ると、サーバーを増やしたいだけなのに接続を覚えておく必要があったのは、道具の通信がセッションを前提にしていたからです。MCP 2026-07-28は、その前提を外す選択肢を標準に近づけました。AIが何でもできるようになる変更ではない。AIが使う道具を、普通のWebサービスのように増やしやすくする変更です。