GitHub MCP Server がステートレス化 — 自作 MCP サーバを 2026-07-28 仕様へ移す棚卸しと検証手順

2026年7月23日、GitHub の公式 MCP サーバが、7月28日に確定する新仕様へ先回りで対応した。変更の中身は「セッションを持つのをやめた」というもので、実装では Redis によるセッション保持がまるごと消えている。自作の MCP サーバを持っている人にとっては、他人の移行結果を先に見られる珍しい機会になった。

7月28日の仕様改訂で消えるもの
「利用側は無改修」を鵜呑みにしない
自作サーバの棚卸しから始める
1. 書き換えの形
旧クライアントと新クライアントの両方から叩いて確かめる
1. 移行で見落としやすい箇所
2. 移行の順番を間違えると戻せなくなる
Roots / Sampling / Logging の扱い
筆者ならこう進める
1. よくある疑問
まとめ

7月28日の仕様改訂で消えるもの

MCP の 2026-07-28 改訂は、プロトコル層からセッションの概念を取り除く。接続を確立するための initialize ハンドシェイクも無くなり、クライアントのメタデータ・機能・プロトコルバージョンは、毎回のリクエストの _meta フィールドに載って運ばれる。

項目	これまで	2026-07-28 以降
接続開始	`initialize` で握手	握手なし。最初のリクエストがそのまま本番
セッションID	`Mcp-Session-Id` ヘッダで維持	プロトコル層から削除
クライアント情報	初期化時に1度だけ送る	毎リクエストの `_meta` に同梱
サーバの形おすすめ	状態を持つインスタンス＋共有ストア	ステートレスなインスタンスをLBの後ろに並べるだけ
ロードバランサ	スティッキーセッションが必要	設定を外せる

GitHub 側の実装変更は、この仕様変更をそのまま反映している。initialize 時のデータベース書き込みが無くなり、呼び出しごとの読み取りも消えた。リクエストの中身を深く覗いて判断していた処理をやめ、HTTP ヘッダから必要な値を読む形に変えている。tier 1 の SDK はいずれも後方互換を保っているため、利用側の改修は不要というのが GitHub の説明だ。

「利用側は無改修」を鵜呑みにしない

筆者は外部APIの仕様変更を、まず疑ってかかることにしている。過去に、廃止予定の機能を全経路に組み込んだまま運用して、ある日いっせいに動かなくなった経験があるからだ。あのときは代替経路を用意していなかったので、復旧まで手が止まった。

今回の「無改修で動く」は、後方互換を維持している SDK を使っている場合の話になる。自前で HTTP を組み立てているクライアントや、ゲートウェイでヘッダを付け替えている構成は、その外側にいる。Mcp-Session-Id をルーティングのキーに使っていたら、そこは自分で外す必要がある。

自作サーバの棚卸しから始める

移行作業の実体は、コードの書き換えより先に「セッションに何を置いていたか」の洗い出しだ。置いていたものは、だいたい次の3種類に分かれる。

セッションに載せていたもの	移行先	注意点
認証情報（トークン・ユーザーID）	毎リクエストのヘッダ	失効の確認をリクエストごとに行う設計へ
ページングのカーソル位置	リクエスト引数（カーソルを返して受け取る）	サーバ側で覚えない。カーソルは不透明な文字列にする
ユーザーごとの設定・作業中の状態	アプリ層の永続ストア	プロトコルの都合と業務データを混ぜない

3つ目が曲者で、「接続中だけ覚えておけばいい」と思って置いた値ほど、後から業務ロジックが依存している。筆者が自分のサーバを見直したときも、一時的なつもりの値が2箇所ほど残っていた。

書き換えの形

セッションから読んでいた箇所を、リクエストから読む形に置き換える。Python で書いた例を挙げる。

# 変更前: 初期化時に作ったセッションから読む
def handle_search(session_id, params):
    sess = redis.hgetall(f"mcp:sess:{session_id}")   # 毎回のDB読み取り
    token = sess["token"]
    return search(token, params["q"], cursor=sess.get("cursor"))

# 変更後: リクエストが自己完結している
def handle_search(request, params):
    token = request.headers["Authorization"].removeprefix("Bearer ")
    cursor = params.get("cursor")          # クライアントが持ち回る
    result = search(token, params["q"], cursor=cursor)
    return {"items": result.items, "next_cursor": result.next_cursor}

カーソルをクライアントに返して持ち回らせる形にすると、サーバ側は次の呼び出しがどのインスタンスに届いても同じ答えを返せる。スケールの話に見えて、実際にはローカル開発でも効く。プロセスを再起動しても会話が途切れない。

旧クライアントと新クライアントの両方から叩いて確かめる

移行が終わったかどうかは、コードを読んでも分からない。両方の形式で実際にリクエストを投げて、同じ答えが返るかを見る。

# 旧仕様: セッションIDを付けて呼ぶ（無視されて正常応答が返るのが正解）
curl -s -X POST http://127.0.0.1:8080/mcp \
  -H "Content-Type: application/json" \
  -H "Mcp-Session-Id: legacy-12345" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | jq '.result.tools | length'

# 新仕様: 握手なし・_meta 同梱でいきなり本番リクエスト
curl -s -X POST http://127.0.0.1:8080/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list",
       "params":{"_meta":{"protocolVersion":"2026-07-28",
                          "clientInfo":{"name":"curl-check","version":"1"}}}}' | jq '.result.tools | length'

確認する点は3つある。両方が同じツール数を返すか、旧仕様のリクエストがエラーにならないか、サーバを再起動した直後でも2回目以降の呼び出しが通るか。3つ目は、状態がどこかに残っていないかを見るための確認になる。