MCPサーバーのテスト｜本番前に確認する7項目

はじめに

MCP（Model Context Protocol）サーバーを試作すると、最初の成功は分かりやすい。AIクライアントからツール一覧が見え、引数を渡すと結果が返る。デモとしては成立する。

しかし本番で問われるのは、その次だ。閲覧だけを許可した利用者が更新ツールを呼べないか。存在しない顧客IDを渡したとき、モデルは修正できるエラーを受け取れるか。通信が切れた登録処理を再実行しても、データが二重にならないか。誰が何を実行したか後から追えるか。

MCPを接続方式としてだけ捉えると、従来APIで決めていた認可、例外、再試行、監査が抜けやすい。MCPサーバーのテストは、プロトコル準拠の確認と、業務として許される挙動の確認を分ける必要がある。

ここでは、MCPサーバーを本番へ出す前に確認する7項目を、問い合わせ管理ツールを例に整理する。

まず固定する3つのテスト層

テストケースを書く前に、対象を3層へ分ける。

MCPのTools仕様は、tools/listとtools/call、入力スキーマ、結果、エラーの形を定めている。ただし、仕様どおり応答することは、業務上正しいことと同義ではない。たとえばupdate_customerが正しい形式で成功しても、他部署の顧客を変更できるなら不合格だ。

この3層を混ぜると、「Inspectorで動いたから完了」「API側の単体テストが通ったから完了」という誤判定が起きる。

MCPサーバーのテストで確認する7項目

1. 接続と能力交渉を確認する

最初は正常な接続だけでなく、起動失敗、タイムアウト、切断、再接続を試す。クライアントとサーバーが対応するプロトコル版・能力を合意できること、未対応の要求を曖昧に成功させないことを確認する。

公式MCP Inspectorでは、接続後にResources、Prompts、Toolsなどを確認し、CLIからtools/listも実行できる。手動確認には有効だが、受け入れ条件は画面の見た目ではなく応答として残す。

• サーバー停止中は所定時間内に失敗を返す
• 未対応機能は明示的なエラーになる
• 再接続後に古いセッションや権限を引き継がない
• ツール一覧の変更を扱う場合は、クライアントが再取得できる

接続試験は「一度つながるか」ではなく、「壊れた状態から安全に戻れるか」までが範囲である。

2. ツール名・説明・入力スキーマを検証する

AIは説明文とスキーマを手掛かりにツールを選ぶ。人間には似て見えるget_customerとsearch_customersでも、適用条件が曖昧ならモデルは取り違える。

各ツールについて、正しい選択と誤選択の両方を試す。

正常値だけでなく、空文字、過大な文字列、未知の列挙値、桁あふれ、別形式の日付を入れる。モデルが引数を生成するからこそ、入力は「たぶん正しい」ではなく境界値で検査する。

3. 出力をモデルと人の両方が判定できる形にする

成功結果が長い文章だけだと、モデルはIDや状態を取り違えやすい。逆に構造化データだけでは、利用者が結果を確認しにくい。

問い合わせ更新なら、少なくとも対象ID、変更前後の状態、実行時刻、追跡IDを構造化して返す。表示用の短い説明を併記してもよい。機密項目は、呼出者が閲覧できる範囲だけに絞る。

テストでは次を確認する。

• 一覧が0件、1件、上限件数のときに形が崩れない
• ページネーション後も重複・欠落がない
• null、未設定、削除済みを区別できる
• 個人情報や内部トークンが結果へ混入しない
• 実行対象を一意に照合できるIDが返る

出力は次のAI判断への入力になる。曖昧な成功文は、後続の誤操作を生む。

4. 認証ではなく「対象ごとの認可」を試す

ログインできることと、その顧客を更新できることは別だ。MCPサーバー側では、呼出者、操作、対象データの3点を毎回照合する。

MCPの認可仕様はHTTP transportでOAuth 2.1に基づく流れを定め、トークンの対象リソース確認を求めている。加えて業務側では、本人分、担当部署分、全社分といったデータ範囲を検査する。

権限テストは許可ケースより拒否ケースを厚くする。一般担当者で管理ツールを呼ぶ。他部署のcustomerIdへ差し替える。検索結果には見えないIDを直接指定する。期限切れ資格情報で再実行する。すべて、下流APIへ到達する前に拒否できることを確認する。

認可の設計は、MCPのセキュリティで守る5つの境界で整理したトークン、ツール、引数、データ、実行の境界をテストへ変換する作業である。

5. エラーを「直せる失敗」と「止める失敗」に分ける

公式仕様では、未知のツールや不正なJSON-RPC要求はプロトコルエラー、入力検証や下流API失敗などはツール実行結果のisErrorで表現できる。重要なのは、モデルへ再試行の材料を与えつつ、危険な失敗では止めることだ。

「エラーが返った」だけでは合格にしない。モデルが勝手な補完、無限再試行、別ツールへの迂回をしないところまでシナリオで確認する。

6. 更新系は再実行と部分成功を試す

最も事故につながりやすいのは、サーバー側では更新が完了したのに、クライアントが結果を受け取れなかった場合だ。利用者がもう一度依頼すると、コメント、タスク、請求などが重複する。

RFC 9110の冪等性は、同一要求を複数回送っても意図したサーバー上の効果が一度と同じになる性質を定義する。MCPの更新ツールでも、operationKeyや対象IDを使い、再実行時に既存結果を照合できるようにする。

次の故障を意図的に起こす。

1. 下流更新の直後に接続を切る
2. 同じ操作キーで同じ引数を再送する
3. 同じ操作キーで異なる引数を送る
4. 3件中2件だけ成功させる
5. 状態確認APIが一時的に失敗する

合格条件は、同じ処理を二重に作らず、成功済み2件と未完了1件を区別して返せることだ。不明な結果を新しいキーで再送してはいけない。API仕様書の5つの契約と同様に、再試行は実装都合ではなく業務契約として定義する。

7. 監査ログと人への引き渡しを確認する

最後に、結果だけでなく判断経路を追えるかを試す。監査ログには、実行者、依頼時刻、ツール名、対象ID、承認の有無、結果、追跡IDを残す。入力全文を無条件に保存すると個人情報や秘密情報まで残るため、項目ごとのマスキングと保存期間も決める。

人への引き渡しが必要な条件もテストする。

• 宛先や対象の同一性が確定できない
• 権限不足で代替手段がない
• 金額や削除など影響の大きい操作で承認がない
• 再試行上限へ達した
• 下流の結果が不明で読み戻しもできない

このとき「失敗しました」だけでは運用できない。成功済み、未完了、確認に使ったID、次に人が判断する点を返す。

受け入れ表はツール単位で作る

7項目を、ツールごとの一枚にまとめる。

自動テストではスキーマ、境界値、認可、冪等性を繰り返す。Inspectorでは人が説明と結果を確認する。さらに実際のAIクライアントで、曖昧な依頼、悪意あるデータ、途中失敗を含む業務シナリオを通す。三つを代替関係にしない。

AIエージェントの受入テストでも触れたように、ツールより先に合否を固定すると、モデルやクライアントを変更しても同じ基準で比較できる。

本番判定は「安全に失敗できるか」で決める

MCPサーバーの価値は、AIが外部システムを操作できることにある。同時に、接続できる範囲が広がるほど、誤選択、権限超過、重複実行、情報漏えいの影響も大きくなる。

本番判定では、正常系の成功率だけを見ない。誤った入力を拒否できるか。権限外の対象へ届かないか。結果不明から重複せず復旧できるか。人へ渡すべき場面で止まれるか。この4点を優先する。

MCPサーバーのテストは、AIを賢く見せる試験ではない。AIに任せてよい境界を、再現可能な受け入れ条件にする作業だ。

受け入れ条件を業務フローや関連する仕様と一緒に整理する場合は、Kakusillも確認してほしい。MCP連携の要件やテスト項目を整理したい場合は、お問い合わせから相談できる。