GitHub MCP Serverが新しいMCP仕様に対応し、sessionsやinitializeが削除されたことで、「現在使っているVS Codeや独自MCPクライアントにも移行作業が必要なのか」と不安に感じる人もいるでしょう。
結論から言えば、一般的なMCPクライアントでGitHub MCP Serverを利用しているだけなら、原則として移行作業は不要です。 GitHubは、Tier 1の公式SDKが旧仕様との後方互換性を維持しており、既存環境のサポートを保つために利用者が行う作業はないと説明しています。(The GitHub Blog)
ただし、MCP通信を独自実装しているクライアント、Mcp-Session-Idに依存するプロキシ、RedisでMCPセッションを管理しているリモートサーバー環境では、設計の見直しや適合テストが必要です。
GitHub MCP Serverが新MCP仕様へ対応、移行と互換性の要点
GitHubは2026年7月23日、GitHub MCP Serverが新しいMCP仕様に先行対応したと発表しました。その後、ステートレスなコアを採用したMCP仕様「2026-07-28」が正式に公開されています。新仕様では、リクエストを単独で処理できる「自己完結型」の通信方式が基本となりました。(The GitHub Blog)
利用形態ごとの移行判断を整理すると、次のようになります。
| 利用形態 | 移行作業 | 最低限行うこと |
|---|---|---|
| VS Codeなどの対応済みMCPホストから利用 | 原則不要 | クライアントを最新版に更新し、再接続を確認する |
| GitHubが提供するリモートMCP Serverを利用 | 原則不要 | ツール一覧取得と読み取り系ツールを試す |
| 公式MCP SDKで独自クライアントを開発 | 緊急対応は通常不要 | SDKの対応バージョンを確認し、更新計画を立てる |
| HTTP通信を直接実装した独自クライアント | 対応が必要になる可能性が高い | initialize、セッションID、HTTPヘッダーの実装を点検する |
| 独自のリモートMCP Serverを運用 | 構成による | Redis、スティッキーセッション、ロードバランサー設定を確認する |
| ゲートウェイでJSON本文を解析 | 見直し推奨 | Mcp-MethodなどのHTTPヘッダーを利用する |
| 独自のelicitation処理を実装 | テストが必要 | 新旧双方の複数ラウンド通信を確認する |
重要なのは、新仕様からinitializeが削除されたことと、GitHub MCP Serverが旧クライアントからのinitializeを直ちに拒否することは同じではないという点です。GitHub MCP Serverが利用する公式Go SDKは複数のMCP仕様を扱えるため、既存クライアントを急いで書き換える必要はありません。(GitHub)
MCPのステートレス化で何が変わったのか
initializeによるハンドシェイクが不要になった
従来のMCPでは、クライアントが最初にinitializeを送信し、次の情報をサーバーと交換していました。
- 使用するMCPプロトコルのバージョン
- クライアント名とバージョン
- クライアントが対応する機能
- サーバーが提供する機能
新しいMCP仕様では、initializeとinitializedによるハンドシェイクがコアプロトコルから削除されています。プロトコルバージョンやクライアント情報、対応機能は、それぞれのリクエストに含まれる_metaで伝達します。
サーバーの機能を事前に確認したい場合は、新設されたserver/discoverを利用できます。(Model Context Protocol Blog)
| 項目 | 従来の仕様 | 2026-07-28仕様 |
|---|---|---|
| 初期接続 | initializeが必要 | 原則不要 |
| クライアント情報 | 接続開始時に送信 | 各リクエストの_metaに含める |
| サーバー機能の確認 | initializeの応答で確認 | 必要に応じてserver/discoverを利用 |
| リクエスト処理 | 接続中のセッション情報に依存 | リクエスト単位で自己完結 |
これにより、ツールを1回呼び出すだけでも事前の初期化通信が必要だった従来方式と比べ、接続処理を簡略化できます。
Mcp-Session-Idとプロトコルセッションが削除された
従来のStreamable HTTPでは、initializeへの応答としてサーバーがMcp-Session-Idを発行する構成がありました。クライアントは、その後のリクエストにも同じセッションIDを付けて送信します。
この方式では、ロードバランサー配下に複数のMCP Serverが存在する場合、同じクライアントを同じサーバーへ転送するスティッキーセッションや、全サーバーで共有するセッションストアが必要になることがありました。
2026-07-28仕様では、Mcp-Session-IdとMCPプロトコルレベルのセッションが削除されています。各リクエストが自己完結するため、どのサーバーインスタンスでも処理できる設計になりました。(Model Context Protocol Blog)
ここで削除された「セッション」は、GitHubへのログイン状態やOAuth、Personal Access Tokenによる認証ではありません。
GitHubのリモートMCP Serverでは、引き続きOAuthまたはPersonal Access Tokenを使って認証します。MCPセッションがなくなったからといって、GitHubの認証設定やトークンを削除する必要はありません。(GitHub Docs)
GitHub MCP ServerからRedisが不要になった理由
GitHub MCP Serverでは、新仕様への対応に伴い、Redisを利用したMCPセッション管理が削除されました。
従来は、initialize時にセッション情報をデータベースへ書き込み、その後のリクエストでもセッション情報を読み出す必要がありました。ステートレス化によって、この書き込みと読み取りが不要になっています。GitHubは、利用者が機能を失うことなく、処理を軽量化できると説明しています。(The GitHub Blog)
主な効果は次のとおりです。
| 改善点 | 効果 |
|---|---|
initialize時のデータベース書き込みを削除 | 接続開始時の処理を削減できる |
| リクエストごとのセッション読み取りを削除 | ツール呼び出しのオーバーヘッドを減らせる |
| Redisへの依存を削減 | 障害点と運用対象を減らせる |
| スティッキーセッションを不要化 | 通常のラウンドロビン構成を採用しやすくなる |
| 任意のサーバーで処理可能 | 水平スケールしやすくなる |
ただし、Redisを使っているからといって、無条件に削除してはいけません。
削除できるのは、Redisの用途が次のようなMCPプロトコルセッションの維持だけである場合です。
Mcp-Session-Idと接続先サーバーの関連付けinitializeで受け取ったクライアント情報の保持- 接続ごとのMCP機能情報の保存
一方、次の用途でRedisを使用している場合は、ステートレス化後も必要になる可能性があります。
- ユーザーごとの処理状態
- ジョブやタスクの進行状況
- レート制限
- キャッシュ
- 一時的な認証情報
- 複数回のツール呼び出しをまたぐ業務データ
MCPのステートレス化は、アプリケーション全体を無状態にする仕組みではありません。複数回の呼び出しで状態を引き継ぐ必要がある場合は、ツールがbrowser_idやtask_idなどの明示的な識別子を返し、次の呼び出しで引数として渡す設計が推奨されています。(Model Context Protocol Blog)
HTTPヘッダー利用で本文の事前解析が不要になった
新しいStreamable HTTPでは、MCPの操作内容をHTTPヘッダーから判別できるようになりました。
代表的なヘッダーは次のとおりです。
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search_issuesMcp-Methodにはtools/callやtools/listなどのメソッド名が入り、Mcp-Nameには対象となるツール名などが入ります。
GitHub MCP Serverでは、ログ記録やシークレットスキャンのためにMCPリクエストの一部情報を読み取る必要があります。従来はSDKへ渡す前にJSON本文を解析していましたが、新仕様では必要な情報をHTTPヘッダーから取得できます。(The GitHub Blog)
これにより、ロードバランサーやAPIゲートウェイで次のような処理を行いやすくなります。
tools/callだけ異なるバックエンドへ転送する- 特定ツールの呼び出し回数を制限する
- ツール名ごとに監査ログを分ける
- リクエスト本文を読み込まずにメトリクスを記録する
- メソッド別にタイムアウトを設定する
新仕様では、HTTPヘッダーとJSON本文の内容が一致しないリクエストをサーバーが拒否する設計です。そのため、プロキシやWAFを利用している場合は、Mcp-MethodやMcp-Nameを削除・書き換えず、そのままバックエンドへ転送できるか確認してください。(Model Context Protocol Blog)
なお、これらはStreamable HTTP向けの変更です。ローカルのGitHub MCP Serverをstdio接続で利用している場合、利用者がHTTPヘッダーを手動設定する必要はありません。
既存のMCPクライアントに移行作業は必要か
一般利用者は原則として設定変更不要
GitHubは、Tier 1の公式SDKが後方互換性を維持しているため、既存サポートを継続する目的で利用者が行う作業はないと案内しています。GitHub MCP Server自体も公式Go SDKを利用しています。(The GitHub Blog)
そのため、次のような利用者は基本的に設定を書き換える必要がありません。
- 対応済みのIDEやMCPホストからGitHub MCP Serverを利用している
- GitHubがホストするリモートMCP Serverへ接続している
- クライアント側のMCP通信を公式SDKに任せている
initializeやMcp-Session-Idを直接扱っていない
実施すべきなのは、大規模な移行ではなく次のような動作確認です。
- MCPクライアントやIDEを最新版に更新する
- GitHub MCP Serverへ再接続する
- ツール一覧が取得できることを確認する
- リポジトリ検索などの読み取り系ツールを1回実行する
- OAuthやPATによる認証が継続していることを確認する
公式SDKを使った独自クライアントも緊急対応は不要
現在のMCP公式SDKでは、TypeScript、Python、C#、GoがTier 1に分類されています。GitHubの発表では、Tier 1 SDKは新仕様への対応と旧仕様との互換性を確保しています。(Model Context Protocol)
公式Go SDKでは、バージョン1.7.0以降がMCP 2026-07-28に対応しながら、次の旧仕様もサポートしています。
- 2025-11-25
- 2025-06-18
- 2025-03-26
- 2024-11-05
したがって、公式SDKを利用している場合は、独自の通信処理を書き換えるよりも、まずSDKを対応バージョンへ更新する方法が安全です。(GitHub)
後方互換性があるからといって、古いSDKを固定したままにするのは避けましょう。今すぐ接続できなくなる可能性は低くても、新仕様の性能改善や適合テスト、将来の拡張機能を利用できません。
独自HTTPクライアントは実装確認が必要
MCP通信を公式SDKに任せず、HTTPリクエストを直接生成している場合は、次の項目を確認してください。
| 確認項目 | 旧仕様への依存例 | 対応方針 |
|---|---|---|
| 初期化処理 | 接続直後に必ずinitializeを送る | プロトコルバージョンごとに処理を分ける |
| セッション管理 | Mcp-Session-Idがないと処理できない | 新仕様ではリクエスト単位で処理する |
| クライアント情報 | 初期化時にだけ送信する | 新仕様では各リクエストの_metaに含める |
| サーバー機能確認 | initializeの応答だけを見る | 必要に応じてserver/discoverを利用する |
| ルーティング | JSON本文からメソッドを抽出する | Mcp-MethodやMcp-Nameを利用する |
| elicitation | SSE接続を保持し続ける | 複数ラウンドのリクエスト方式を実装する |
新旧両方のクライアントをサポートする必要がある場合は、旧コードを一度に削除するのではなく、プロトコルバージョンに応じて処理を切り替える設計が安全です。
elicitationは新旧クライアントの両方に対応
elicitationは、MCP Serverが処理途中で利用者に確認や追加情報を求める機能です。例えば、ファイル削除前に確認を表示したり、GitHubへのログインを案内したりする場面で使われます。
ステートレスな新仕様では、サーバーが長時間接続を保持してクライアントへ要求を送るのではなく、いったん「入力が必要」という結果を返します。クライアントは利用者から回答を受け取り、回答と処理状態を含めて元のリクエストを再送します。
この方式なら、再送されたリクエストを別のサーバーインスタンスが処理しても問題ありません。(Model Context Protocol Blog)
GitHub MCP Serverのstdio版では、ログインを容易にするためURL elicitationが使われています。GitHubは、公式Go SDKのラッパーを利用し、旧方式と新方式の両方で動作するように実装を更新しています。(The GitHub Blog)
そのため、通常の利用者がelicitation方式の違いを意識する必要はありません。ただし、独自クライアントで確認画面やログイン画面を実装している場合は、次の動作をテストしてください。
- 入力要求を正しく検出できる
- 処理状態を保持したまま再リクエストできる
- 利用者がキャンセルした場合に処理を終了できる
- 新旧のプロトコルバージョンで動作する
- 再リクエストが別インスタンスへ転送されても処理できる
公式MCP適合テストで確認する方法
MCPには、クライアントやサーバーの実装が仕様に適合しているかを確認する公式のConformance Test Frameworkが用意されています。
このフレームワークは、テスト用のクライアントまたはサーバーを起動し、MCP通信を記録したうえで、仕様に沿った応答になっているかを検証します。(GitHub)
MCP Serverをテストする
ローカルまたはステージング環境でMCP Serverを起動し、次のように実行します。
npx @modelcontextprotocol/conformance server \
--url http://localhost:3000/mcp特定のシナリオだけを確認する場合は、--scenarioを指定します。
npx @modelcontextprotocol/conformance server \
--url http://localhost:3000/mcp \
--scenario server-initializeserver-initializeのような旧初期化シナリオが残っているのは、2026-07-28仕様でinitializeが復活したからではありません。旧仕様や後方互換性を検証するためです。
MCPクライアントをテストする
独自クライアントは、次の形式でテストできます。
npx @modelcontextprotocol/conformance client \
--command "./my-mcp-client" \
--suite backcompat \
--spec-version 2026-07-28利用可能なテストシナリオを確認するには、次のコマンドを実行します。
npx @modelcontextprotocol/conformance list公式フレームワークには、コア仕様、拡張機能、認証、後方互換性などのテストスイートがあります。GitHub MCP Serverを単に利用するだけのユーザーが実行する必要はありませんが、独自クライアントや独自サーバーを開発している場合はCIに組み込む価値があります。(GitHub)
移行前に確認したいチェックリスト
次の質問に1つでも該当する場合は、単なるクライアント更新ではなく、実装やインフラ構成を確認してください。
initializeの応答内容をアプリケーション内で保存しているMcp-Session-Idがないリクエストを拒否している- RedisにMCP接続単位のセッションを保存している
- ロードバランサーでスティッキーセッションを設定している
- APIゲートウェイがJSON本文を読み、ツール名を判定している
- WAFやプロキシが
Mcp-*ヘッダーを削除している - MCP通信を公式SDKを使わず独自実装している
- elicitationのためにSSE接続を長時間保持している
- プロトコルバージョンを固定値として扱っている
該当しない場合、必要なのはクライアントの更新と基本的な接続確認だけです。
該当する場合は、次の順番で対応すると安全です。
- 現在利用しているMCP仕様とSDKバージョンを記録する
initialize、セッションID、Redisへの依存箇所を洗い出す- 公式SDKを対応バージョンへ更新する
- ステージング環境で新旧クライアントを接続する
- 公式Conformance Testを実行する
- Redisやスティッキーセッションを段階的に外す
- エラー率とツール呼び出し時間を監視して本番へ展開する
ステートレス化で失敗しやすいポイント
Redisをすべて削除してしまう
削除対象は、MCPプロトコルセッションを維持するためだけのデータです。業務処理、キャッシュ、レート制限、非同期タスクにRedisを利用している場合は、そのまま必要になる可能性があります。
旧クライアント対応を先に削除してしまう
新仕様でinitializeが不要になっても、すべての利用者が同時に新仕様へ移行するとは限りません。公式SDKの後方互換機能を利用し、新旧の接続ログを確認してから旧処理を整理するのが安全です。
HTTPヘッダーを認証情報として扱う
Mcp-MethodやMcp-Nameは、ルーティングやログ記録を容易にするための情報です。これらのヘッダーだけを信用してアクセス許可を判断してはいけません。
GitHubへのアクセス権は、引き続きOAuthやPAT、組織ポリシーなどで制御する必要があります。(GitHub Docs)
接続できることだけでテストを終える
接続成功だけでは、次のような問題を検出できません。
- ツール一覧だけ取得できない
Mcp-Nameと本文が一致していない- elicitationの再リクエストに失敗する
- 旧クライアントからだけ接続できない
- プロキシがMCP用ヘッダーを落としている
少なくとも、ツール一覧取得、読み取り系ツール、書き込み前確認、認証更新、旧クライアント接続を確認しましょう。
GitHub MCP Server利用者が次に行うこと
GitHub MCP ServerをVS Codeなどから通常利用している場合、sessionsやinitializeの削除に伴う設定変更は原則不要です。クライアントを最新版へ更新し、GitHub MCP Serverへの再接続とツール実行を確認すれば十分です。
一方、独自クライアントや独自のリモートMCP環境を運用している場合は、次の3点を優先してください。
initializeとMcp-Session-Idへの依存を洗い出す- Redisとスティッキーセッションが本当に必要かを用途別に判断する
- 公式SDKとConformance Testを使って新旧互換性を検証する
今回の変更は、既存クライアントを一斉に切り捨てるものではありません。後方互換性を保ちながら、GitHub MCP Serverをより高速でスケールしやすい構成へ移行するための更新です。
コメント