旧クライアントが残るMCP移行で、先に変える構成と残す責任
顧客が使うMCPクライアントの更新を待つ間に、サーバー側の移行をどこまで進めてよいのでしょうか。新構成の利用開始と、旧構成の撤去は別々に判断するのが、本記事の提案です。新しい通信方式を受け付けられても、既存利用者を移せることや、業務処理を安全に再開できることまで確認できたわけではありません。
MCPの2026-07-28仕様を対象に、旧revisionが残る案件で何を確認し、誰の責任を残すかを考えます。以下の責任分担と受入条件は、公開仕様・実装資料をもとにした案件向けの提案です。実環境で検証済みの移行手順を示すものではありません。
サーバーの更新日だけでは移行を決められない
MCPの新仕様は、通信のセッション廃止とアプリケーションの状態管理を分けています。生成AIエージェントが業務ツールを使う構成でも、業務状態を誰が管理するかは引き続き設計の対象です。
ここでは、SIerがMCPサーバーを保守し、顧客や協力会社が接続クライアントを管理する案件を想定します。サーバー担当だけで接続元の更新日を決められないことを、移行計画の出発点にします。
たとえば、顧客の社内クライアントは更新できても、協力会社のクライアントは次の保守期間まで変えられないとします。この場合に必要なのは、各接続元の対応revisionと更新責任者を特定し、残る接続を維持できるかを確かめることです。「サーバーの更新が終わった」を全体の移行完了条件にはしません。
元請けが基盤を更新しても、顧客IdPのトークン検証、業務データの所有権確認、再送時の処理結果の判断は残ります。それぞれの責任者を決めることを、新構成の利用開始条件に含めます。
先に進める変更を、接続元の状況から選ぶ
旧新の共存を確認できる案件では、段階移行を第一候補にします。ただし、共存できるという判断は採用するSDKの版、handler設定、実際のクライアントの組合せについて行います。後述するGo SDKの固定commitでは、statefulなhandlerが新revisionの要求を拒否する分岐を持つため、SDKを更新しただけで新構成を利用開始できるとは判断しません。接続できた一例から、ほかの利用者も同じように移せるとは扱いません。
| 接続元の状況 | 選ぶ移行方針 | 次へ進む条件 |
|---|---|---|
| 旧クライアントが残り、双方の試験ができる | 旧構成を残して新構成の利用を段階的に開始 | 旧新それぞれの接続・認証・業務操作が受入条件を満たす |
| 旧クライアントの更新時期が未確定 | 当面は旧revisionの互換構成を維持 | 利用者、更新責任者、旧構成を終える条件を合意する |
| 新規案件で旧クライアントが存在しない | 新revisionで開始する案を検証 | 採用SDK、IdP、業務操作の確認を完了する |
旧構成を維持する案には、既存利用者の変更を急がずに済む利点があります。一方、保守と後日の移行は残るため、終了条件を持つ暫定策として扱います。新規案件だけで開始する案は旧接続の調整を減らせますが、認証や更新処理の確認まで省けるわけではありません。
仕様と実装から判断に使えること
セッションをなくしても業務状態は残る
公式リリースは、次のように説明しています。
Dropping the protocol-level session doesn’t force your application to be stateless.
プロトコルのセッションをなくしても業務状態は残せるため、移行計画では通信の変更と業務状態の管理を分けます。
たとえば、進行中の業務を指すhandleを使う設計では、通信を終えても参照先の業務データは残ります。ここから導くべき移行上の判断は、handleの管理主体と利用権限の確認を設計に残すことです。セッションがなくなることを、業務状態や権限確認を削除する理由にはできません。
トークンの宛先と業務データの権限を分ける
認可仕様には、次の要件があります。
MCP servers MUST only accept tokens that are valid for use with their own resources.
MCPサーバー自身のリソースに対するトークン検証が必要であり、業務データの所有権確認を省く根拠にはなりません。
案件では、MCPサーバーが受け入れてよいトークンかを検証する責任と、その利用者が指定した業務データを操作してよいかを確認する責任を分けて割り当てます。handleが入力に含まれているというだけで操作を認めず、サーバー側で利用者と対象データの関係を検査する方針です。これは仕様のトークン検証要件を踏まえた業務設計上の提案です。
新revisionを受け付ける設定と、共存の確認を分ける
Go SDKのstreamable.go（固定commit）には、新revisionの要求に対する次のエラー文があります。
this server is stateful; set StreamableHTTPOptions.Stateless = true to accept it
この分岐ではstatefulなhandlerが新revisionの要求を拒否し、StreamableHTTPOptions.Stateless = trueの設定を案内します。SDKの版とhandler設定を組にして確認する理由は、この受理条件にあります。
ただし、この拒否分岐ではdiscover要求が除外されています。探索の応答が返ったことだけで、後続の業務要求も新revisionで受け付けられるとは判断できません。基盤担当は、採用する版に同じ受理条件があるかを確認し、新構成に設定するhandlerと、実際に送る業務要求を試験対象にします。
Statelessを有効にする判断と、旧クライアントを新構成へ移せる判断も別です。このコードの受理条件だけでは、顧客の旧クライアントとの共存や認可、業務更新の成功は証明できません。案件の受入では旧新それぞれの接続元について結果を残し、未確認の組合せを旧構成の撤去条件から外さないことを提案します。
移行後も残す責任を受入条件にする
既存利用者を移す責任
接続クライアントの管理者が対応revisionと更新日を提示し、基盤担当が旧新それぞれの接続結果を記録します。旧構成の撤去は、残る利用者と切戻しの要否を両者で確認してから決めます。
受入記録は「MCP接続成功」だけで終えず、接続元、対応revision、SDKの版と設定、試験結果を組にして残す形を提案します。旧クライアントの確認が未完了なら、新構成の利用開始を判断できても、旧構成の撤去条件はまだ満たしていません。
業務データを操作させる責任
IdP担当と基盤担当が対象MCPリソース向けのトークン検証を確認し、業務システム担当がhandleの利用者・テナント・対象データの関係を検査します。認証の成功だけで業務操作を許可しません。
たとえば、同じテナントの別利用者が持つhandleや、別テナントのhandleを渡した場合を確認対象にします。期待する拒否結果と判定担当を受入条件に書けば、「認証は基盤担当、データは業務担当」という分担の間に権限確認が落ちることを防げます。この試験案は案件固有の認可を確かめるためのもので、SDKの適合試験で済んだとは扱いません。
再送と切戻しを判断する責任
更新系toolの再送で同じ処理が重複しないことを業務担当と確認し、障害時に結果を照合する担当を決めます。旧構成へ戻す手順には、新構成で既に完了した業務処理の扱いも含めます。
更新要求の送信後に応答を受け取れなかった場面を想定します。利用者には失敗に見えても、業務処理が完了していれば、同じ要求を送ることの影響を確認する必要があります。受入試験では再送後の処理結果を照合し、通信構成を戻す作業と、業務データを整合させる作業の担当を明記することを提案します。
この判断をそのまま適用できない条件
旧クライアントの管理者や対応revisionを確認できない案件では、旧構成の撤去を決められません。利用者の確認を移行作業に先行させます。
公式仕様と公開コードの読取りから、顧客IdP、旧新クライアントの混在、負荷、二重更新防止が動作するとまでは言えません。この記事では顧客環境の実行試験を行っていません。
Go SDKの固定commitで確認したのは、statefulなhandlerの新revision拒否とStateless設定の関係です。他の言語のSDKや全機能の対応保証へ広げず、採用するSDKと版を固定した確認が必要です。
managed gatewayへの互換層の外部化は選択肢ですが、製品別の互換性、契約、データ所在地は本記事の根拠では確定していません。顧客の要件に合うかを別途確認する必要があります。
引用したstreamable.goは特定commitのコードです。採用予定のリリースに同じ分岐が含まれるか、設定後に実際の業務要求を受け付けるかは、別途確かめる必要があります。コードの読取りを、顧客環境での試験合格として扱わないでください。
次の移行打合せで合意すること
まず接続元ごとに、対応revision、更新責任者、旧構成を終える条件を記入します。そのうえで、認証・業務権限・再送の確認担当を決め、新構成の利用を開始できる条件と、旧構成を撤去できる条件を別欄で合意するところまでを打合せの成果にします。
Go SDKの固定commitで、新revisionを受け付けるhandler設定を確認する
採用する版とhandler設定を決めたら、旧新クライアントの業務要求、顧客固有の認可、再送時の確認を受入対象に加えます。旧利用者の移行が残る場合は、その責任者と終了条件を残したまま、先に進められる変更だけを選びます。
WRITTEN BY
コメント