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ツールずつトラフィックを段階開放するのが安全です。障害発生時の切り戻し対象が明確になり、原因分析時間を大幅に短縮できます。

Claude Codeに「このファイルのバグを直して」と言うと、勝手にファイルを読み、修正し、保存してくれます。 また、「天気を教えて」と言えば、外部APIを叩いて答えてくれます。

まるで魔法のようですが、裏側では非常に論理的なプロセスが動いています。

本記事では、エンジニア向けに**「Claude CodeでSKILLS（スキル）が発動する仕組み」**を徹底的に解剖します。

ここを理解すれば、あなたはClaude Codeを「ただ使う人」から「自在に操る人（ツール開発者）」になれます。

1. 全体像：発動までの4ステップ

Claude Codeがスキルを実行する時、内部では以下の4段階のプロセスが走っています。

1. ツール定義の読み込み (Tool Definition)
2. 意図の検出 (Intent Detection)
3. 引数の生成 (Argument Generation)
4. 実行と結果のフィードバック (Execution & Feedback)

それぞれ詳しく見ていきましょう。

Step 1. ツール定義の読み込み

Claude Codeが起動する時、設定ファイルや MCP (Model Context Protocol) サーバーから、「自分は何ができるか」というリストを読み込みます。

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

{
  "name": "read_file",
  "description": "指定されたパスのファイルを読み込む",
  "parameters": {
    "type": "object",
    "properties": {
      "path": {
        "type": "string",
        "description": "読み込むファイルの絶対パスまたは相対パス"
      }
    },
    "required": ["path"]
  }
}

Step 2. 意図の検出 (Intent Detection)

ユーザーが「src/main.py の中身が見たい」と発言したとします。

Claudeの脳内（推論プロセス）では、以下のような思考が行われます。

ユーザーはファイルの中身を知りたがっている。 私の持っている道具リストの中に、それを叶えるものはあるか？ …あった。read_file だ。 この道具を使おう。

これが Function Calling（関数呼び出し） のトリガーです。

Step 3. 引数の生成 (Argument Generation)

道具を使うと決めたら、次は「どう使うか」を決めます。

定義書の parameters に従って、必要な情報を会話履歴から抽出します。

• ユーザーの発言: “src/main.py の中身…”
• 引数 path: "src/main.py"

Claudeは以下のような特殊なトークン（またはJSON）を出力します。

<tool_use>
  <name>read_file</name>
  <parameters>
    {"path": "src/main.py"}
  </parameters>
</tool_use>

Step 4. 実行と結果のフィードバック

ここが重要です。Claude自身がファイルを読むわけではありません。

Claudeが出力した上記のJSONを、Claude Codeのランタイム（実行環境） が受け取ります。 そして、PythonやNode.jsで書かれた実際のプログラム（open() 関数など）が実行されます。

実行結果（ファイルの中身）は、再びテキストとしてClaudeに返されます。

<tool_result>
  import os
  print("Hello World")
</tool_result>

これを見て初めて、Claudeは「ファイルの中身はこうなっていました」とユーザーに回答できるのです。

2. MCP (Model Context Protocol) とは？

最近話題の MCP は、この「ツールの渡し方」を標準化した規格です。

これまで、Claudeに独自のツールを追加するには、複雑な設定が必要でした。 しかしMCPを使えば、「MCPサーバー」 を立ち上げるだけで、Claude Codeが勝手にツールを認識してくれます。

仕組み

1. MCPサーバー: ツール（関数）の実装を持つプロセス。
2. MCPクライアント: Claude Code本体。

クライアントとサーバーが通信し、「使えるツール一覧」と「実行リクエスト」をやり取りします。 これにより、ローカルのデータベース操作や、社内APIへのアクセスが安全かつ簡単に実装できるようになりました。

まとめ

Claude Codeの「SKILLS」は、魔法ではありません。 「定義を読む」→「選ぶ」→「JSONを作る」→「実行結果を読む」 という、非常に泥臭いテキスト処理のループです。

しかし、この仕組みを理解していれば、あなたはClaude Codeを 「ただの話し相手」から 「手足となって働く最強のパートナー」 に進化させることができます。

ぜひ、自分だけのカスタムスキルを作ってみてください。