MCPサーバー本番設計ガイド：AIエージェント連携を安全・安定に運用するアーキテクチャ

MCP（Model Context Protocol）は、LLM と外部ツールを接続する強力な仕組みです。便利な一方で、本番運用では「権限の過剰付与」「監査不能」「障害時の暴走」が起きやすく、設計を誤ると一気にリスクが跳ね上がります。

本記事では、MCP サーバーを業務利用する前提で、安全性・可観測性・運用性を満たす設計パターンをまとめます。PoC から本番へ上げる際のチェックリストとして使える構成にしています。

1. MCP本番運用で先に決めるべきこと

最初に決めるべきは、技術スタックではなく「権限境界」です。

  • どのエージェントが、どのツールを使えるか
  • 書き込み系操作（作成・更新・削除）の承認方式
  • 外部送信（メール、投稿、通知）の監査ルール
  • 失敗時の停止条件（fail-open か fail-closed か）

ここを決めずに実装を始めると、あとから制約を入れられず、結果として運用停止になります。

2. 推奨アーキテクチャ：Control Plane と Tool Plane の分離

MCP 構成は最低でも2層に分けると安全です。

  1. Control Plane: 認証、認可、監査、レート制御
  2. Tool Plane: 実際のツール実行（DB、GitHub、Browser、Messaging）

2-1. なぜ分離するのか

Tool 実装に認可ロジックを埋め込むと、ツール追加のたびにセキュリティ品質がブレます。Control Plane で一元化すれば、ポリシー変更時も1箇所で反映できます。

2-2. リクエストフロー例

1
2
3
4

Agent -> MCP Gateway(Control Plane)
      -> Policy Engine (allow/deny, scope check)
      -> Tool Adapter (Tool Plane)
      -> Audit Logger

deny の場合も必ず監査ログに記録し、試行の痕跡を残します。

3. 認可設計：RBACだけでは足りない

本番では RBAC（役割）に加えて ABAC（属性）を使うと事故が減ります。

  • RBAC: writer, reviewer, admin
  • ABAC: 時間帯、環境（prod/staging）、対象リポジトリ、操作種別

例:

  • staging では write 可、prod は read のみ
  • 23:00〜08:00 の外部送信を自動 deny
  • delete は人間承認トークン必須

このルールを YAML 等で宣言的に持つと、監査とレビューが容易になります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

policies:
  - name: deny-night-send
    when:
      action: message.send
      time_between: ["23:00", "08:00"]
    effect: deny

  - name: allow-read-docs
    when:
      action: docs.read
      env: ["prod", "staging"]
    effect: allow

4. 書き込み操作のガードレール

削除や公開投稿など不可逆操作は、二段階に分けます。

  1. Planフェーズ: 何を変更するか差分提示
  2. Applyフェーズ: 承認トークン付きで実行

4-1. Git操作の安全化

  • main 直 push 禁止（PR 経由のみ）
  • commit message に実行主体IDを埋め込む
  • 重要ディレクトリは CODEOWNERS レビュー必須

これにより「誰が」「なぜ」「どの差分を」適用したか追跡できます。

5. 可観測性：最低限必要な監査ログ項目

MCP の障害は、アプリログだけでは追えません。次を構造化ログで保存します。

  • request_id
  • agent_id / session_id
  • tool_name
  • action（read/write/delete/send）
  • policy_decision（allow/deny）
  • latency_ms
  • result（success/failure）
  • redacted_input_hash

入力本文を丸ごと保存すると個人情報漏えいリスクが高いので、ハッシュ化・マスキングが原則です。

6. 障害設計：MCPが壊れても全体を止めない

6-1. Circuit Breaker を必ず入れる

下流ツール（例: GitHub API）が遅延した際、MCP 全体が巻き込まれないようにします。

  • 連続失敗 N 回で open
  • cool-down 後に half-open
  • 成功確認後に close

6-2. タイムアウト予算

MCP リクエストは複数ツールを跨ぐため、全体予算を先に決めます。

  • 全体: 10 秒
  • 認可: 500ms
  • ツール実行: 7 秒
  • ログ書き込み: 1 秒

予算超過時は中断し、部分成功を明示するレスポンスを返すほうが、黙って待つより運用しやすいです。

7. 実運用チェックリスト（導入前に必須）

セキュリティ

  • デフォルト deny（明示 allow のみ）
  • 外部送信系に承認フローあり
  • APIキー/トークンのローテーション手順あり
  • 監査ログの改ざん防止（WORM/署名）

信頼性

  • タイムアウト・再試行・サーキットブレーカ設定済み
  • ツールごとのレート制限あり
  • 障害時の degraded mode 定義済み
  • 週次で復旧訓練（ゲームデイ）実施

運用

  • Runbook とオンコール体制がある
  • 重大操作の通知先が明確
  • 監査レポートを定期出力できる
  • ポリシー変更はPRレビュー必須

8. PoCから本番へ上げるときの移行手順

おすすめは次の4段階です。

  1. Read-only段階: 読み取り専用ツールのみ許可
  2. 限定Write段階: staging への書き込みのみ解放
  3. 承認付きProd段階: prod 書き込みは人間承認必須
  4. 自動化段階: 低リスク操作だけ自動承認

この順序なら、事故を起こさず運用知見を溜められます。

まとめ

MCP は「つなげる技術」ですが、本番では「制御する技術」に重心があります。成功する導入の共通点は次の3つです。

  • 権限境界を最初に設計する
  • 監査可能な実行経路を持つ
  • 障害時に安全側へ倒れる設計にする

AI エージェント活用は今後さらに広がります。だからこそ、機能追加より先に運用設計を固めることが、長期的な速度と安全性を両立する最短ルートです。今日から始めるなら、まずは「default deny + 監査ログ項目定義」この2つを先に確定してください。

9. 監査レビューを回すための実務フロー

ログを取って終わりでは意味がありません。週次または隔週で、次の観点で監査レビューを実施します。

  • deny された操作のうち、正当要求だったものはないか
  • 承認付き操作で承認理由が空欄になっていないか
  • 失敗率の高いツールに設計欠陥がないか
  • 夜間・休日の危険操作が発生していないか

監査レビューはセキュリティ部門だけでなく、実際に運用する開発チームが同席することで改善速度が上がります。ポリシーは「守らせるもの」ではなく「運用と一緒に育てるもの」と捉えるのが重要です。

10. 導入初期に決めておくべきSLO

MCP 基盤にも SLO を置くと、感覚論で運用しなくて済みます。例として以下が扱いやすいです。

  • 正常リクエスト成功率: 99.5%以上
  • ポリシー判定レイテンシ p95: 300ms 以下
  • 重大操作の監査ログ欠損率: 0%
  • 障害発生時の検知時間: 5分以内

このSLOをダッシュボード化し、週次で逸脱をレビューするだけで、MCP運用の成熟度は大きく上がります。PoC段階から数値を持っておくと、本番移行時の説得材料としても有効です。

補足として、導入時は「全ツール同時公開」を避け、1ツールずつトラフィックを段階開放するのが安全です。障害発生時の切り戻し対象が明確になり、原因分析時間を大幅に短縮できます。