Tool Design & MCP Integration

ドメインの位置付け

Tool Design & MCP Integration は CCAF 5ドメイン中で 18% を占めるドメインです。 公式ページに記載された範囲としては、「明確な境界を持つツールインターフェース設計」「構造化エラー応答」 「MCP サーバ統合」が中心トピックです。

D1 と組み合わせで出題されやすい領域です。D1（agentic loop）の中で「どんなツールをどう設計するか」が D2、 「ツール呼び出しをどう束ねるか」が D1、という分担。

このドメインで扱う技術概念

ツール定義の構造（公式 API ドキュメントベース）

Claude API におけるツール定義は次の3要素から成ります:

• name — 一意な識別子（モデルが選択時に参照）
• description — モデルがツール選択判断に使う説明文
• input_schema — JSON Schema 形式の入力定義

特に description の質がツール選択の正確性を直接決めます。 似た名前・似た用途のツールを並べる場合、説明の差別化が運用品質を左右します。

MCP（Model Context Protocol）

MCP は、Claude を含む LLM クライアントが外部システム（DB、API、ファイルシステム等）と接続するための 標準プロトコル。Claude Code では .mcp.json でプロジェクト共有設定、~/.claude.json でユーザー個人設定を分けることが推奨されています。

MCP サーバは tools / resources / prompts という3種の機能を提供します:

• Tools: モデルが呼び出す関数（副作用あり・action系）
• Resources: 読み取り専用のコンテンツカタログ（DBスキーマ、ドキュメント階層等）
• Prompts: 再利用可能なプロンプトテンプレート

tool_choice の制御

Claude API では tool_choice パラメータでツール呼び出しの強制度を制御できます:

• auto — モデルがツール使用の要否を判断
• any — 必ず何らかのツールを呼ぶ
• tool + name — 特定ツールの強制呼び出し

構造化エラー応答

MCP ツールがエラーを返す際、単一フラグ（成功/失敗）ではなく構造化されたエラーメタデータを返す設計が推奨されています。 エラーカテゴリ（transient / validation / business / permission）と リトライ可否（retryable boolean）を明示することで、エージェントが適切な復旧判断を行えます。

ビルトインツール（Read, Write, Edit, Bash, Grep, Glob）

Claude Code には標準ビルトインツールがあり、それぞれ役割が異なります:

• Grep — 内容検索（パターンマッチ）
• Glob — ファイルパスのパターンマッチ
• Read / Write — ファイル全体の読み書き
• Edit — 一意な文字列を狙った差し替え（曖昧マッチ時は失敗）
• Bash — シェルコマンド実行

これらの選択判断（いつ Grep を使うか、いつ Glob を使うか）も D2 の範囲です。

このドメインの主題的な問い（Fyveの解釈）

1. ツール説明の質が選択精度を決める
   最小限の description では似たツール間でモデルが迷う。 入力形式・想定クエリ例・境界条件を明示することで信頼性が上がる。
2. 1エージェントに大量ツールを持たせない
   18個のツールを1エージェントに与えるより、4-5個に絞った専門エージェント×複数の方が選択精度が高い。
3. カスタムMCP実装は最後の手段
   既存のコミュニティMCPサーバ（Linear, GitHub, Jira等）があれば活用。 自前実装はチーム固有ワークフロー向けに限定。

このドメインが関わるシナリオ

公式ページ記載のシナリオのうち、D2 が主要トピックとされているのは:

• Customer Support Resolution Agent — MCPツール (get_customer, lookup_order 等) の設計と境界
• Multi-Agent Research System — subagent 群へのツール配布
• Developer Productivity with Claude — ビルトインツール + MCPサーバの統合

学習リソース（公式）

• docs.anthropic.com — Tool use の API リファレンス
• modelcontextprotocol.io — MCP プロトコルの公式仕様
• Anthropic Academy: Introduction to Model Context Protocol — MCP の公式入門コース
• Anthropic Academy: MCP Advanced Topics — sampling、notifications等の応用

Fyveの実戦から見た D2

Claude Code 業務利用30件以上の経験から:

「MCPサーバ選びはコミュニティ既存を優先」。 Linear, GitHub, Slack 等の主要サービスには既にコミュニティMCPサーバが存在します。 Fyveでは案件初期に "このサービスは既存MCPがあるか" を必ず確認してから自前実装を検討します。

「ツール description の調整で精度が劇的に変わる」。 似た用途の自社ツール2つを同じエージェントに持たせていて選択ミスが頻発した案件で、 description に「いつ使うか」「いつ使わないか」を明記しただけで精度が大幅に向上しました。

「環境変数展開を活用する」。.mcp.json に $${GITHUB_TOKEN} のような形で書けば、 シークレットを commit せずにチーム共有できます。