Architecture

MCPサーバー本番設計ガイド：AIエージェント連携を安全・安定に運用するアーキテクチャ MCP（Model Context Protocol）は、LLM と外部ツールを接続する強力な仕組みです。便利な一方で、本番運用では「権限の過剰付与」「監査不能」「障害時の暴走」が起きやすく、設計を誤ると一気にリスクが跳ね上がります。 本記事では、MCP サーバーを業務利用する前提で、安全性・可観測性・運用性を満たす設計パターンをまとめます。PoC から本番へ上げる際のチェックリストとして使える構成にしています。 1. MCP本番運用で先に決めるべきこと 最初に決めるべきは、技術スタックではなく「権限境界」です。 どのエージェントが、どのツールを使えるか 書き込み系操作（作成・更新・削除）の承認方式 外部送信（メール、投稿、通知）の監査ルール 失敗時の停止条件（fail-open か fail-closed か） ここを決めずに実装を始めると、あとから制約を入れられず、結果として運用停止になります。 2. 推奨アーキテクチャ：Control Plane と Tool Plane の分離 MCP 構成は最低でも2層に分けると安全です。 Control Plane: 認証、認可、監査、レート制御 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 の場合も必ず監査ログに記録し、試行の痕跡を残します。 ...

「魔法」の裏側を知りたくないですか？ Claude Codeに「このファイルのバグを直して」と言うと、勝手にファイルを読み、修正し、保存してくれます。 また、「天気を教えて」と言えば、外部APIを叩いて答えてくれます。 まるで魔法のようですが、裏側では非常に論理的なプロセスが動いています。 本記事では、エンジニア向けに**「Claude CodeでSKILLS（スキル）が発動する仕組み」**を徹底的に解剖します。 ここを理解すれば、あなたはClaude Codeを「ただ使う人」から「自在に操る人（ツール開発者）」になれます。 1. 全体像：発動までの4ステップ Claude Codeがスキルを実行する時、内部では以下の4段階のプロセスが走っています。 ツール定義の読み込み (Tool Definition) 意図の検出 (Intent Detection) 引数の生成 (Argument Generation) 実行と結果のフィードバック (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 の中身が見たい」と発言したとします。 ...