Model Context Protocol 実運用ガイド: サーバー境界、Tool ガバナンス、Transport 戦略

• はじめに
• 最初に決めるべきこと
• Tool と Resource は使い分ける
• Transport 選定: stdio と Streamable HTTP
  • stdio が向いている場面
  • Streamable HTTP が向いている場面
• Tool 設計原則
  • 名前は狭く、意図は明確に
  • 入力スキーマは短く厳格に
  • 結果は次の行動に役立つ形で返す
• トークン予算とコンテキスト浪費
• 認証と権限境界
• 観測性と運用チェックリスト
  • 本番投入前チェック
• アンチパターン
  • 「社内 API を全部 MCP で包めばよい」
  • 「tool が多いほどエージェントは賢くなる」
  • 「ローカルで動いたから本番でも大丈夫」
• まとめ
• References

はじめに

Model Context Protocol, つまり MCP は、AI アプリケーションを外部システムと接続する方法を標準化するための有力なアプローチです。実運用で本当に重要なのは、プロトコルそのものよりも次のような設計判断です。

• 1つの MCP サーバーがどこまでを担当するか
• 何を tool にし、何を resource にするか
• stdio と HTTP のどちらを選ぶか
• 長い tool 説明や巨大なレスポンスでコンテキストを浪費しないようにするにはどうするか
• 誰がどの tool を呼び出したかをどう監査するか

この記事では MCP 公式ドキュメントを軸に、プロダクションで直面する設計と運用の論点を整理します。

最初に決めるべきこと

最もよくある失敗は、社内のすべての API や機能を 1 つの巨大な MCP サーバーにまとめることです。これにより、次の問題が一気に発生します。

• tool 説明が長く重複する
• セキュリティ境界が曖昧になる
• 障害分離が難しくなる
• バージョニングが無関係な機能まで結合される

より良い方法は、ドメインや信頼境界ごとにサーバーを分割することです。

Tool と Resource は使い分ける

公式ドキュメントでも、tool と resource は別の役割を持っています。

• tool
  • 副作用のある操作、変換、構造化された検索など、関数呼び出しに近いもの
• resource
  • ドキュメント、インベントリ、ランブックなど、読む文脈を提供するもの

すべてを tool にすると、モデルは文脈を読むためだけに不要な呼び出しを繰り返します。逆にすべてを resource にすると、アクション境界と監査が弱くなります。

Transport 選定: stdio と Streamable HTTP

transport は単なる実装差ではありません。運用モデルそのものを変えます。

stdio が向いている場面

• ローカル開発ツール
• デスクトップ統合
• 単一ユーザー中心の利用

利点:

• 実装が単純
• ローカル統合をすぐ始められる
• 開発中の試行錯誤に向いている

注意点:

• 中央監査が弱い
• マルチテナント運用に不向き
• クライアントのプロセス寿命に依存しやすい

Streamable HTTP が向いている場面

• 複数クライアントが共有するサーバー
• 中央認証とポリシーが必要な環境
• API gateway や ingress を含む運用標準に乗せたい場合

利点:

• 既存のサービス運用に組み込みやすい
• 認証、ロギング、rate limit をまとめやすい
• クライアント種類が増えても拡張しやすい

注意点:

• 認証境界を明確に設計する必要がある
• 単なる HTTP ラッパーに落ちやすい

Tool 設計原則

名前は狭く、意図は明確に

悪い例:

run_action
manage_item
operate_system

良い例:

list_pull_requests
get_ruleset_status
create_incident_note

モデルはツール名もプロンプトの一部として読みます。名前が曖昧だと選択ミスが増えます。

入力スキーマは短く厳格に

• 必須入力は最小限にする
• enum にできる値は自由入力にしない
• 説明文は短く行動指向にする
• 人向け表示名と内部 ID を混在させない

結果は次の行動に役立つ形で返す

大きな JSON ダンプより、次の判断に必要な構造化結果の方が役立ちます。

{
  "repository": "platform/api",
  "ruleset_status": "blocking",
  "missing_checks": ["lint", "integration-test"],
  "next_actions": [
    "wait_for_required_checks",
    "request_codeowner_review"
  ]
}

トークン予算とコンテキスト浪費

最近の MCP 関連ツールの議論が示している通り、実務ではモデル性能そのものよりコンテキスト浪費の方が問題になることが少なくありません。

よくある浪費パターン:

• tool 説明の重複
• 必要以上に大きい resource 応答
• 常に不要なフィールドまで返す
• 1 サーバーが多すぎる tool を公開する

有効な運用ルール:

1. tool 説明は短く保つ
2. 大きな resource は取得単位を分割する
3. 要約優先、詳細は追加入力で返す
4. 実使用データを見て低利用 tool を整理する

認証と権限境界

MCP サーバーが社内システムに接続された瞬間、主題は利便性ではなく権限管理になります。

事前に決めるべき問い:

• 呼び出し主体はユーザー代理か、サービス ID か
• 読み取り専用 tool と変更系 tool は分離されているか
• 機密 resource は別サーバーに分離すべきか
• 監査ログの最小項目は何か

推奨パターン:

• 読み取り専用と変更系を分離する
• 書き込み可能 tool には idempotency または承認段階を持たせる
• ユーザー、セッション、tool 名、入力要約、結果状態を記録する
• 失敗理由も人が読める形で残す

観測性と運用チェックリスト

MCP サーバーを本番サービスとして扱うなら、少なくとも次を見ます。

本番投入前チェック

• サーバー境界はドメインと信頼境界に沿っているか
• tool 名とスキーマは狭く明確か
• resource が過大な payload を返していないか
• 監査ログは十分か
• 障害時の fallback 動作が定義されているか
• transport の選定理由が文書化されているか

アンチパターン

「社内 API を全部 MCP で包めばよい」

それは多くの場合、モデルが使いやすいインターフェースではなく、単なるプロトコル風のラッパーになります。

「tool が多いほどエージェントは賢くなる」

実際には逆です。tool が増えるほど選択ミスとコンテキスト負荷が増えます。少数で明確な interface の方が強いことが多いです。

「ローカルで動いたから本番でも大丈夫」

ローカル stdio 統合がうまくいっても、中央認証、マルチクライアント、配備、自動監査が入ると別の問題が出ます。本番の MCP は interface 設計と platform 運用の両方です。

まとめ

MCP をうまく導入したチームは、単にモデルを強くしたのではなく、モデルが安全に使える interface を設計しています。成否を決めるのは、プロトコルそのものより、サーバー境界、tool スキーマ、transport、権限モデル、そしてトークン予算です。

まず優先すべきなのは次の二つです。

• ドメインと信頼境界ごとにサーバーを分けること
• 短く明確な tool と resource を設計すること

この二つが整えば、後続の認証、観測性、コスト最適化も大幅にやりやすくなります。

References

• Model Context Protocol Introduction
• MCP Architecture
• MCP Transports
• MCP Tools
• MCP Resources
• MCP Prompts
• MCP Security Best Practices