MCPサーバー更新の互換性を確かめ検証済み構成へ戻す

2026年10月24日2026年10月28日

URLをコピーしました！

公開日: 2026年10月24日

MCPサーバーの更新は、ツールの名前が同じでも、引数、返却値、検索範囲、必要な権限や副作用を変えることがあります。更新前の動作条件を保存し、新版がその条件を満たすかを切替前に確かめます。不一致があれば切替を止め、戻せることを確認した検証済みの構成へ復帰します。復帰先が使えない場合は、更新を強行せず対象の連携を停止します。

この判断には、通信に使うMCPの版と、サーバーの実装版を分けることが欠かせません。プロトコル上の通信が成立しても、業務で期待する意味や権限まで同じとは限らないためです。

変わった場所を複数の版に分ける

MCPはModel Context Protocolの略で、AIアプリケーションと外部の機能・情報を接続するためのプロトコルです。2026年10月19日に確認した現行仕様は2026-07-28で、リクエストごとの版宣言とserver/discoverによる発見が説明されています。2025-11-25以前の版で使われていた初期化時のハンドシェイクを、すべての現行接続の前提にはしません。Versioning

ただし、この日付形式の版だけを記録しても、ツールの挙動を再現する条件は足りません。少なくとも、次の対象を分けて比較します。

比較対象	何を記録するか	同じでも残る変化
MCPプロトコル	要求に用いる版、接続方式、相手の対応状況	個別ツールの引数や業務上の処理
サーバー実装	提供元、リリース、配布物の識別情報	依存先、設定、リモート機能の切替
ツールの定義	名前、説明、入力・出力スキーマ、付加情報	既定値の意味、取得範囲、処理内容
呼出し側	アプリとSDK、変換処理、モデルに渡す定義	古い定義の保持、解釈や選択の変化
下流の条件	API版、権限、索引やデータ、設定	提供元が管理する遠隔の変更

スキーマは、データの型や必須項目などの形式上の約束です。形式が変われば呼出しが失敗し得ますが、形式が同じまま意味が変わることもあります。例えば、検索対象が「指定領域だけ」から「閲覧できる全領域」へ変われば、文字列を受けて文書一覧を返す形が同じでも、業務の許可範囲を外れる可能性があります。

MCPのTools仕様には、ツール一覧の変更、入力・出力スキーマ、結果の検証などが記されています。一覧変更を受け取ったこと自体は、新しいツールや意味の変化を業務利用してよいという承認ではありません。名前や説明、annotationsという付加情報も確認しますが、信頼しないサーバー由来の付加情報を無条件に信用せず、必要な権限と実際の処理を別に確かめます。Tools

必須引数と返却値が変わる例

ここからは架空の文書検索ツールを使います。試験や接続を実施した記録ではありません。AIアプリHが、HTTPで接続するMCPサーバーMを通じて文書庫Dを読み、製品Pの承認済み文書を検索する構成です。利用者U、閲覧できる品質管理領域、検索語「製品P」、対象の文書集合を固定し、更新前後を比べます。外部共有、文書更新、他領域の検索は許可していません。

旧サーバーの実装版を1.4.2、新版を1.5.0と仮定します。この番号は架空の製品リリースであり、MCP仕様の版ではありません。また、番号の見た目から互換性を保証しません。

受渡し	旧版1.4.2の契約	新版1.5.0の候補
ツール名	search_documents	同じ名前
入力	queryを必須とし、検索領域は承認済み設定で品質管理に固定	queryに加えnamespaceが必須
出力	documents配列。要素にid、revision、excerpt	hits配列。要素にdocument_id、revision、excerpt。completeを必須項目として追加
期待する対象	品質管理領域でUが閲覧できる承認済み文書	同じ範囲を明示指定できるか確認が必要

このまま旧アプリを新版につなぐと、namespaceがないため必須引数の条件を満たせません。期待する処理は要求の拒否です。仮に要求が通っても、旧アプリがdocumentsだけを読めば、hitsに結果があるのにゼロ件と表示するかもしれません。どちらも、モデルへの「前と同じように検索して」という指示だけでは解決できません。

修正案は、Hが承認済みの品質管理領域をnamespaceへ明示し、返却されたhitsを検証してから内部形式へ対応付けることです。document_idと旧idが同じ識別体系か、revisionの意味が変わっていないか、completeがどの範囲の取得完了を表すかも照合します。項目名の置換だけで、値の意味が同じとみなしてはいけません。

namespaceに適当な既定値を入れたり、全領域を表す値を補ったりする移行は避けます。欠落が見つかったら、利用者の依頼と許可された対象へ戻して値を確定します。必要な領域を特定できない要求は、引数を送る前に保留します。

版固定は何を固定できるかを明示する

ローカルで管理する実装なら、利用するリリースだけでなく、配布物のハッシュなどの識別情報、依存関係、起動設定、呼出し側の版を記録します。使用する配布方式が対応しているなら、変わり得るlatestなどの指定を避け、確認した成果物を特定できる形で固定します。設定を残すときも、秘密のトークン本体を比較資料やテスト結果へコピーせず、管理された参照と必要な権限の情報を分けます。

NISTのSSDF Version 1.1は、配布物の完全性を検証するための情報を取得者へ提供する実践（PS.2）や、取得した第三者のソフトウェア部品が組織の要件に適合するかを確かめる実践（PW.4.4）を挙げています。これは更新時の取得物と依存先を確認する参考になりますが、ハッシュや署名の一致だけでツールの無害性や互換性を証明するものではありません。Secure Software Development Framework Version 1.1

一方、提供元が運用するリモートサーバーでは、手元の設定を固定しても、遠隔の実装や下流サービスが更新される場合があります。旧版接続先、API版の選択、変更通知、復帰のサポート範囲を提供元へ確認します。固定する方法がないなら、その制約を導入条件に含め、手元の設定だけで旧挙動へ戻せるとは約束しません。

公式MCP RegistryのFAQは、更新を新しい版のメタデータとして公開し、版メタデータは不変であると説明しています。ここで固定されるメタデータと、接続先の運用中の挙動は区別します。同じ情報で登録された接続先へ到達できても、検索結果や権限の扱いまで不変であるという根拠にはなりません。FAQは2026年10月19日の確認時点で、Registryがプレビュー段階にあり、一般提供までに互換性のない変更やデータのリセットがあり得るとしています。Frequently Asked Questions

契約テストは正常と拒否の両方を残す

契約テストは、送り手と受け手が約束した入出力や失敗時の扱いを確かめる試験です。更新前のスキーマだけでなく、実際の用途で必要な意味、対象範囲、権限、副作用も期待結果として明示します。旧版で一度返った文章を、そのまま正解として複製する方法にはしません。

この例では、合成した文書D15を品質管理領域に置き、承認済み版r3の抜粋を返すことを期待します。別領域の合成文書D90はUには返してはいけない対象です。同じテスト用データと権限で旧構成と新構成を比較し、差が出た箇所を調べます。次の表は未実行の試験計画です。

確認する条件	入力と比較方法	期待結果と不一致時の対応
正常な検索が保たれる	製品P、品質管理領域、Uの読取り権限を固定	D15/r3と所定の抜粋が返る。不一致ならデータ/処理の差を調べる
旧形式を黙って拡張しない	namespaceを含まない旧要求を新版へ渡す	契約に従い拒否される。全領域検索へ補完したら切替不可
返却形式を正しく読む	新版のhitsとdocument_idを受け取る	対応付け後もD15と版が同じ。documents欠落をゼロ件にしない
未完了を完了にしない	completeがfalseまたは欠落する入力を分ける	部分取得または契約不適合と判断し、全件確認済みにしない
権限外を取得しない	D90を含む条件をテスト用主体で与える	返却と下流取得の境界を確認。漏えいがあれば切替停止
読取りから更新へ広がらない	検索権限だけで更新を要求する	実行前に拒否され文書は不変。阻止できなければ権限を見直す
不明な結果を再送しない	応答不着を模擬し処理状態を不明にする	結果不明を保持し、照会と再送条件へ進む

失敗判定は、警告文が出たかだけで決めません。拒否すべき要求が下流へ届いていないか、許可された文書が返らず過剰に止まっていないかも、対象環境で得られる実行記録へ照合します。正常な仕事が続けられることと、禁止操作が阻止されることの両方が必要です。

completeがfalseなら、契約上の範囲で部分取得と示します。必須と定めたcomplete自体が欠けている場合は、値をfalseとして補わず契約不適合とします。旧版にはこの項目がないため、旧版用の変換と新版用の検証を混ぜないことも確認点です。

型の検査、ツール単体の契約テスト、AIアプリを通した確認は分けると原因を追いやすくなります。モデルに渡る説明が変われば、形式が同じでもツール選択が変わる可能性があります。固定した要求での直接呼出しと、同じ業務依頼からの選択を別に確認し、モデルの設定まで同時に変えてサーバー更新の影響と決め付けないようにします。

回帰テストとして保存するのは、入力、権限、期待する範囲と判定方法です。回帰テストとは、変更後も必要な既存動作が保たれるかを繰り返し確かめる試験を指します。新版が承認されても、その実際の結果と版を記録し、後の更新で同じ条件を再確認できるようにします。成功した一件だけで、他の領域や高影響操作まで確認済みにしません。

正常な移行と切替を止める条件

正常な移行では、Hの入力・出力変換を修正し、Mの新版と組み合わせて前述の確認を満たします。D15/r3の意味と検索領域が保たれ、D90や更新要求が拒否されるなら、その構成を切替候補にできます。試験を実施した担当者が記録を確認し、許可された範囲で段階的に切り替えます。読取り試験で確かめた結果を、送信や更新を含むツールへそのまま流用しません。

拒否すべき移行は、新版が検索のために外部共有や全領域の閲覧権限を追加で求める場合です。旧版で与えた読取りの許可は、その追加権限を承認したことにはなりません。必要性と送信先、対象データを再評価し、必要な承認がなければ権限を増やさず切替を止めます。この例のMはHTTP接続ですが、MCPの認可機能は任意であり、HTTP向け認可仕様をstdioのローカル権限管理へ移し替えないことにも注意します。Authorization

停止する移行は、出力形式は合うものの、D15以外の領域が混じる理由や、completeの意味が確認できない場合です。ここでは原因不明を正常と判定せず、新版への呼出しを止め、保存した下流API、索引、権限、サーバー設定との違いを調べます。原因の候補は複数残してよく、更新の直後だったというだけでサーバーコードの不具合と確定しません。

復帰先と未完了の要求を確認して戻す

復帰は、旧サーバーの版番号を指定し直すだけでは完了しません。旧版用のHの変換処理と設定、Mの配布物、下流Dの対応条件が揃うかを確認します。新版向けのhits変換だけを残してMを旧版へ戻すと、今度はdocumentsを読めない不整合が起こり得ます。検証済みの組合せを復帰単位として記録しておきます。

切替を止めた時点で処理中だった要求も別に管理します。応答不着は未実行の証拠ではなく、新版側で処理が進んでいる場合があります。要求の識別情報と対象状態を照会し、旧版で同じ要求を出し直してよいかを、そのサービスの重複防止と再試行条件に照らして判断します。単にMCPの要求IDがあることだけで、下流処理の二重実行を防げるとは扱いません。Making retries safe with idempotent APIs

この文書検索例では、取得済みの版と残る要求を整理したうえで、許可された読取りを旧構成で再確認します。更新や送信を伴う別のツールなら、プログラムを戻しても生じた副作用は残り得ます。データの移行、外部送信、課金などを取り消せるかは個別に確認し、コードの復帰と業務状態の回復を分けます。

旧版に既知の重大な問題がある、下流APIが旧版を受け付けない、データ形式が不可逆に移行された、提供元が旧接続先を提供しない場合には、復帰できるとは限りません。安全性と必要な権限を確認できない旧版へ無理に戻さず、対象連携を停止し、検証可能な代替手段や修正版を待つ判断を残します。

復帰後は、正常な読取りだけでなく、権限外の取得と禁止更新が拒否されることも再確認します。呼出し先、HとMの組合せ、未完了要求、取得状態が確認できるまで、通常運用へ戻したとは報告しません。復帰試験の記録は次回の更新条件へ反映しますが、実施していない項目を合格として埋めることは避けます。

版を固定すると、更新前後を比べる基準を残せます。固定を続ける間にも、脆弱性や保守終了に対応するための見直しは必要です。検証済み構成、拒否されるべき処理、切替中止条件、復帰不能時の停止を一緒に用意して、更新によって許可範囲や意味が広がっていないかを確かめます。

MCPサーバーを導入前に信頼境界として評価する方法は「MCPサーバーを信頼境界として評価する」で解説しています。

外部ツールの仕様変更後にプロンプトを再評価する手順は「外部ツール仕様変更後にプロンプトを再評価する」で解説しています。

出典・参考資料

Agent・ツール・MCP

よかったらシェアしてね！

URLをコピーしました！

この記事を書いた人

さかっぺ PAP Research運営／ AIガバナンス・アーキテクト／プロンプトデザイナー

ITインフラの実務経験をもとに、AIの安全性と実用性を両立する仕組みを研究。PAP Researchでは、AIモデルの継続観測と、プロンプト・AI技術の実務解説を発信しています。

経歴や研究方法、発信方針は運営者プロフィールで紹介しています。