MCP

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 の中身が見たい」と発言したとします。 ...

Claude Codeに「自分専用スキル」を追加する方法（MCP活用術） はじめに Anthropic社のClaude 3、特にコーディング能力に優れたclaude-3-opus-20240229モデルは、多くの開発者にとって強力な相棒となりつつあります。コード生成、リファクタリング、デバッグ支援など、その能力は多岐にわたります。 しかし、こんな風に感じたことはありませんか？ 「Claudeに社内のデータベースへアクセスさせて、最新の売上データを分析させたい…」 「GitHubリポジトリの最新のIssueを要約させたり、新しいチケットをJIRAに起票させたりできたら最高なのに…」 「特定の計算や、自作のコマンドラインツールを実行するよう指示できれば、作業が劇的に効率化されるはずだ…」 標準のClaudeは、学習データに含まれる一般的な知識しか持っておらず、あなたの会社のプライベートな情報や、リアルタイムの外部情報にアクセスすることはできません。これまでは、開発者が手動でAPIを叩き、その結果をコピー＆ペーストしてClaudeに与える、という手間のかかる作業が必要でした。 もし、Claudeに**「あなた専用のスキル」**を自由に追加できたらどうでしょう？まるで優秀なアシスタントに新しい能力を教え込むように、独自のツールやAPIと連携させることができたら。 この記事では、Anthropicが提供する**「Tool Use（ツール使用）」機能を活用し、Claudeをあなただけの最強コーディング・アシスタントへと進化させる具体的な方法を、詳細なコード例とともに解説します。この記事で言うMCP（Multi-turn Conversational Platform）活用術**とは、まさにこのTool Use機能を駆使して、対話型AIの能力を最大限に引き出す実践的なテクニックを指します。 この記事を読み終える頃には、あなたはClaudeに独自の「スキル」を授け、開発ワークフローを根本から変革する力を手に入れているはずです。 なぜ今、「Tool Use」が重要なのか？ LLM（大規模言語モデル）は、単に質問に答えたり文章を生成したりするだけの存在から、外部の世界と対話し、能動的にタスクを実行する**「エージェント」**へと進化しつつあります。その中核をなす技術が、ChatGPTにおける「Function Calling」であり、Claudeにおける「Tool Use」です。 この技術がなぜゲームチェンジャーとなり得るのか、その背景にある課題と合わせて見ていきましょう。 従来のLLMが抱えていた課題 知識の陳腐化と非公開情報へのアクセス不可: LLMの知識は、学習データがカットオフされた時点のものであり、リアルタイムの情報（今日の天気、最新の株価など）を知りません。また、社内DBや個人のファイルなど、インターネット上に公開されていない情報には当然アクセスできません。 手動による連携の非効率性: 開発者が外部APIから取得したデータをLLMに渡す場合、手動でのコピー＆ペーストが必要でした。このプロセスは手間がかかるだけでなく、ヒューマンエラーの温床にもなります。 プロンプトの複雑化と再現性の低さ: 複雑なタスクを指示しようとすると、プロンプトが非常に長大かつ複雑になりがちです。「まずこのAPIを叩いてJSONを取得し、その中のitems配列をループして、各nameとpriceを抽出し、マークダウンのテーブル形式で出力して…」といった詳細な手順を毎回プロンプトに記述するのは現実的ではありません。 「Tool Use」がもたらす解決策 ClaudeのTool Use機能は、これらの課題をエレガントに解決します。その仕組みは、LLMと開発者が協調して動作するフレームワークです。 Tool Useの基本的なフロー sequenceDiagram participant User as ユーザー participant App as 開発者のアプリケーション participant Claude as Claude participant Tool as 外部ツール/API User->>App: 「東京の天気は？」 App->>Claude: ユーザーの質問と利用可能なツール定義を渡す Claude->>Claude: 質問を解釈し、「get_weather」ツールが使えると判断 Claude->>App: 「get_weather(city='Tokyo')」を実行してほしい、とJSON形式で要求 App->>Tool: 実際に天気APIを呼び出す Tool-->>App: 天気データ（JSON）を返す App->>Claude: ツール実行結果（天気データ）を渡す Claude->>Claude: 実行結果を解釈し、自然言語の回答を生成 Claude->>App: 「東京の天気は晴れです。」 App->>User: 最終的な回答を表示 このフローが示すように、Tool Useは以下の役割分担によって成り立っています。 ...