2026.06.29

MCPがv2になったら動かなくなった——初心者がステートレス化の変更点でハマった記録と対応方法

#MCP
#v2
#ステートレス
#変更点

2026年7月28日、MCPのプロトコルが静かに変わる。ステートレスファーストへの移行だ。技術系の記事はたくさん出ているが、どれも「サーバーを実装している開発者向け」に見える。「とりあえずClaude CodeにMCPをつないで使っているだけ」の自分には、何を・いつ・どこを直せばいいのかがどこにも書いていなかった。この記事は、その答えを探してたどりついた記録だ。先に言うと、大半の初心者はほぼ何もしなくていい——ただし、一部の設定だけは要注意だ。

図解：MCP v2移行タイムライン——あなたは今どこにいるか

flowchart LR
    subgraph 過去["📅 〜2026年6月（旧仕様）"]
        A["ステートフル設計\nセッションID必須\nスティッキーセッション前提"]
    end
    subgraph 現在["📍 2026年6月29日（今ここ）"]
        B["RC版公開中\n猶予：約29日\n確認・準備のタイミング"]
    end
    subgraph 移行["🎯 2026年7月28日（正式版）"]
        C["ステートレスコアへ\nセッションID不要に\n通常のHTTP LBで動作可能"]
    end
    過去 --> 現在 --> 移行

    style A fill:#e8e8e8,stroke:#aaa
    style B fill:#fff3cd,stroke:#ffc107
    style C fill:#d4edda,stroke:#28a745

猶予は約29日ある。「壊れてから対処」ではなく、今のうちに確認しておけば間に合う。

そもそもMCPって何か、v2でいちばん変わるのはどこか

MCPとは、AIモデル（ClaudeやChatGPTなど）に外部のツールやデータソースをつなぐための「共通の接続規格」だ。Claude Codeがファイルを読んだり、GitHubを操作したりできるのは、このプロトコルを介しているから。

v2でいちばん大きく変わるのは、「ステートレスコア」への移行だ。

少しだけ丁寧に説明する。

旧仕様のMCPサーバーは「ステートフル」だった。ステートフルとは「前のやり取りを覚えている」状態のこと。クライアント（Claude Codeなど）とサーバー（MCPツール）がつながると、セッションIDという「この会話のID票」が発行され、同じIDを持つリクエストは常に同じサーバーに届くよう管理されていた。これを「スティッキーセッション」と呼ぶ。

v2では、このセッションIDへの依存を取り除く方向になる。サーバーはリクエストが来るたびに「新しいリクエスト」として扱う——これがステートレスだ。公式ブログ（blog.modelcontextprotocol.io）の発表では、これによって通常のHTTPロードバランサーが使えるようになり、スケーリングが格段に楽になると説明されている。

セッションIDがなくなること自体は仕様上の変化だが、それがどこに影響するかは「どう使っているか」によって全然違う。そこが混乱の核心だった。

最初の異変：何かがおかしい

ある日、いつも通りClaude Codeを立ち上げてMCP経由のツールを呼ぶと、レスポンスが帰ってこない。ログを確認すると、見慣れないエラーが出ている。接続はできているのに、ツールの実行が止まる——あるいは空のレスポンスが返ってくる。

「MCPのアップデートが来た」「7月28日に何かが変わる」というのは薄々知っていた。でも、どのドキュメントを見ればいいのかがわからない。技術系の記事を検索しても、コードが並んでいて「自分には関係ないかも」と感じる。それでも「何かしなくていいのか」という不安が残る。

この状態から抜け出すために必要だったのは、技術の詳細ではなく「自分はどの立場か」を確認することだった。

混乱した数日間：「全部書き直し」は誤解だった

公式ブログのRC版発表を読んで最初に思ったのは「えっ、全部変わるの？」という驚きだった。

「ステートレスコア」「セッションID廃止」「Breaking Changes」——これだけ並ぶと、今まで設定したものが全滅するように見える。技術系の解説記事を読み進めると、「ハンドル引き回し」「LB対応」「Extensions追加」という言葉が続き、混乱はさらに深まる。

「Claude Desktopの設定ファイルも書き直さないといけないのか？」「JSONを全部見直さないといけないのか？」——そういう疑問が積み上がる。

でも、落ち着いて整理してみると、最終的にわかったのはシンプルなことだった。

「全部書き直し」は誤解だ。影響を受けるのは、セッション状態に依存した実装を自分で書いた人だけだ。

ブレイクスルー：「使うだけの人」と「少し自作した人」では話が全然違う

影響の有無は、自分がどこまでMCPに関わっているかで決まる。

MCPを「使うだけ」の初心者：ほぼ影響なし

Claude DesktopやClaude Codeの設定ファイルにMCPサーバーのパスを書いて使っているだけ、という人はサーバー側の更新を待つだけでいい。

ファイルシステム・GitHub・Slack・Notionなど、コミュニティや公式が配布しているMCPサーバーを使っているなら、そのサーバーの開発者がv2対応を行う。公式発表では、Tier 1 SDKについては10週以内にRC対応を予定していると案内されている（出典：MCP公式ブログ。正式版リリースまでに変更が入る可能性もあるため、最新情報は公式で確認してほしい）。

あなたがやることはたった1つ： 使っているMCPサーバーのGitHubやドキュメントを確認して、v2対応済みリリースが出ていればアップデートする。設定ファイル（JSON）の変更は、そのサーバーのアップデート手順に従う。

MCPを「少し自作・カスタマイズした」初心者：ここだけ要チェック

次のどれかに当てはまる場合は、自分のコードを確認する必要がある。

自分でPythonやNode.jsなどでMCPサーバーのコードを書いた
テンプレートをコピーして、セッション管理の部分を少し改変した
複数リクエスト間で「前の会話の内容」をサーバー側に持たせていた

実際に壊れやすいパターン3つ

ステートレス化で動かなくなりやすいコードの構造を整理する。自分の実装と照らし合わせてほしい。

パターン①：セッションIDでキャッシュを管理していた

# 旧仕様での典型的な構造（概念例）
session_store = {}

def handle_request(request):
    session_id = request.headers.get("Mcp-Session-Id")  # ← ここが危険
    if session_id not in session_store:
        session_store[session_id] = initialize_context()
    ctx = session_store[session_id]
    return process_with_context(ctx, request)

Mcp-Session-Id ヘッダーを見て状態を引き継ぐ実装は、v2でセッションIDが来なくなると初期化できなくなる可能性がある。Mcp-Session-Id をgrepで検索して引っかかれば要確認だ。

パターン②：複数リクエスト間でサーバー側に会話の文脈を保持していた

「さっきのファイルAについて、続けて処理して」とやり取りするMCPツールで、「さっきのファイルA」という情報をサーバーのメモリ上に保持する実装がこれに当たる。v2のステートレスコアでは、各リクエストは独立したものとして扱われるため、リクエストをまたいだ状態の持ち越しは基本的に設計から外す必要がある。

パターン③：スティッキーセッション前提のロードバランサー設定

複数のMCPサーバーインスタンスをLBで束ねて運用していた場合、スティッキーセッション設定が前提になっていることがある。v2ではその必要がなくなるため、設定の見直しが必要になる可能性がある——ただしこれは自前でインフラを運用している人向けのシナリオだ。

エラーの見え方：こういう状況が出たら疑う

MCPの接続・実行まわりのトラブルとして出やすい症状を挙げておく。ただし、これらは必ずしもv2移行だけが原因ではない。まずバージョンと設定を確認することが先決だ。

ツールが無言でタイムアウトする：サーバーが処理を完遂できず、応答そのものが帰ってこない状態
接続はできるが実行結果が空になる：サーバー側の状態管理の不整合で、空レスポンスが返るケース
いつも動いていたのに突然動かなくなった：サーバーのアップデートが先行してv2対応になったが、クライアント側の設定が追いついていないケース（逆もある）

7月28日より前にこれらが出ている場合は、MCP v2移行以外の原因（ネットワーク・ファイルパス・権限）を先に確認してほしい。

最小限の対応：確認する場所と、しなくていい場所

迷わないよう、行動の優先順位をまとめる。

全員がやること

使っているMCPサーバーのGitHubリポジトリまたは公式ドキュメントを開き、「v2」「2026-07-28」「stateless」などの記述があるか確認する。対応済みのリリースがあればアップデートする。

自作コードがある人の追加確認

# 自分のMCPサーバーディレクトリで実行する
grep -r "session" ./your-mcp-server/
grep -r "Mcp-Session-Id" ./your-mcp-server/

ヒットした箇所が「リクエストをまたいで状態を引き継ぐ」実装に使われていれば、ステートレス化への対応が必要かを判断する。

しなくていいこと

Claude Desktopや Claude Codeのアプリを今すぐ再インストールする（バージョンアップは推奨だが緊急ではない）
MCP設定ファイルのJSONを全部作り直す（サーバー側が対応していれば変更不要のことが多い）
RC段階の今すぐ全移行を急ぐ（正式版は2026年7月28日予定。RC段階はまだ仕様が変更になる可能性もある）

まとめ：7月28日まで約29日、今夜やること

体験をひとつの言葉で整理するなら、こうなる。

「ステートレス化＝全部壊れる」ではない。壊れるのは、セッション状態に依存した自作実装だけだ。使うだけの初心者には、使っているサーバーの対応を確認して更新するだけで済む。

次の一手はシンプルだ。今夜、使っているMCPサーバーのGitHubページを一度開いてほしい。「v2対応済み」のリリースや記述があれば、ひと安心してアップデートするだけでいい。自作コードがあればgrepでsessionを探す。それだけで、7月28日に焦らずに済む。

MCP v2のRC仕様の詳細と最新動向は公式ブログ（blog.modelcontextprotocol.io）で確認できる。RC段階のため、正式版リリースまでに仕様が変更になる可能性がある点はあらかじめ念頭に置いておこう。

セルフチェックリスト（対応済みか確認するための5問）

[ ] 使っているMCPサーバーの名前とバージョンを今週確認した
[ ] そのMCPサーバーのGitHub/ドキュメントに「v2対応」の記述があるか確認した
[ ] 対応済みリリースがあればアップデートした（またはスケジュールに入れた）
[ ] 自作のMCPサーバーコードがあれば、sessionやMcp-Session-Idをgrepして確認した
[ ] 2026年7月28日をカレンダーに追加して最終確認のリマインダーをセットした

参考・出典

MCP v2 RC公式発表：blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
ステートレス移行の技術解説（日本語）：azukiazusa.dev
MCPステートレス化の実装比較・検証：zenn.dev/melonps
MCP概要解説：note.com/sawahotaru

*本記事の情報は2026年6月29日時点のものです。MCP v2はRC段階であり、2026年7月28日の正式版リリースまでに仕様が変更になる可能性があります。最新情報は必ず公式発表をご確認ください。*

← 攻略ガイド一覧へ