tool interface design

Tool interface designはCCA-F（Claude Certified Architect — Foundations）試験においてDomain 2で最も集中的に攻略されるサーフェスだ。タスクステートメント2.1 — 「明確な説明と境界を持つ効果的なtool interfaceを設計する」 — はドメインウェイト18%を持ち、Customer Support Resolution Agentシナリオ全体がアーキテクトがtool interface designはスキーマ記述の演習ではなくroutingの演習であると理解しているかどうかに依存するため、ヒートスコアは0.73である。標準的なサンプル問題は、最小限の説明を持つanalyze_content対analyze_documentを対比させてmis-routingを修正するよう問い、間違いの答えは「few-shotの例を追加する」や「2つのツールを統合する」に偏り、正しい答えは常に「明確な境界を含むよう説明を拡張する」だ。tool interface designを誤解するとDomain 2の半分とDomain 1の重要な一部を誤読することになる。

この学習ノートでは、CCA-F候補者が習得を求められるtool interface designの全体像を説明する。ツールスキーマ（名前・説明・input_schema）が選択シグナルにどう分解されるか・説明フィールドがLLMがツール選択に使用する主要メカニズムである理由・「purpose-specific」が意味することとジェネリックツールを定義されたinput/outputコントラクトを持つpurpose-specificツールに分割することが統合より優れている理由・ツールの名前変更（analyze_content → extract_web_resultsパターン）が重複を排除する方法・システムプロンプトのキーワード感度がツール説明をオーバーライドできる場合・そして893/1000の合格レポートと650/1000の不合格レポートを区別する正確な試験トラップ。すべてのセクションはCustomer Supportシナリオに紐付けられている。それが試験当日に最小限の説明が最も劇的なtool interface designの失敗を引き起こす場所だからだ。

Tool Interface Designが重要な理由 — 説明がSelectionを駆動する

ClaudeはIDEでツールを参照するのと同じ方法でツールを見ない。各ターンの開始時にシステムコンテキストに挿入されたJSONオブジェクトのフラットなリストとして見る（それぞれがname・description・input_schemaを持つ）。Claudeのagentic loopがstop_reason: "tool_use"を生成する場合、どのツールを呼び出すかの選択は、ユーザーの意図を各登録済みツールのdescriptionテキストとパターンマッチングすることによってほぼ完全に行われる。Tool interface designは、シナリオの曖昧さやプロンプトドリフトの下でも、Claudeを正しいツールに明確に誘導する説明を書く規律だ。

CCA-F試験ガイドは「routing mechanismとしてのtool descriptions」を基礎的なコンピテンシーとして明示的に挙げており、コミュニティの合格レポート（Kishor Kukreja 893/1000、Rick Hightower 985/1000）は一貫して説明品質をDomain 2問題で最も高いレバレッジのあるレバーとして挙げている。2つのツールが重複した説明を持つ場合、Claudeは推測する。1つのツールの説明が別のものより曖昧な場合、Claudeはより具体的な方にルーティングする（それが間違いであっても）。Tool interface designは装飾的なものではなく、ステアリングホイールだ。

3フィールドのツールスキーマ

Claude ToolDefinition（直接APIでもMCPホストでも）はすべて選択ウェイトを持つ3つのフィールドに分解される：

1. name — 短い識別子（snake_case）。ツールの呼び出しとログに使用される。説明が薄い場合に弱く選択に貢献する。
2. description — 約100〜500トークンの自然言語文字列。主要な選択シグナル。目的・input・output・例・境界を含まなければならない。
3. input_schema — 必須と任意のパラメーターを説明するJSON Schema。ツールがどのように呼び出されるかを制約するが、呼ばれるかどうかは制約しない。

CCA-F試験は候補者がこれら3つのフィールドの非対称なウェイトを理解しているかどうかを問う。よく書かれたdescriptionは弱いnameを補うことができる。完璧なinput_schemaは弱いdescriptionを補うことができない。

タスクステートメントに「明確な境界」が現れる理由

Domain 2.1は「明確な説明と境界を持つ効果的なtool interfaceを設計する」と表現されている。2つの名詞であり1つではない。説明はClaudeにツールが何をするかを伝え、境界はClaudeにツールが何をしないかを伝える。「コンテンツを分析する」と言うanalyze_contentというCustomer Supportツールには説明があるが境界がない。「このツールはsearch_webから返されたウェブ検索結果にのみ使用する。顧客がアップロードしたドキュメントには使用しないこと — 代わりにanalyze_documentを使用する」と追加すると境界が導入され、サンプル問題を悩ませているmis-routingが排除される。

Customer Supportシナリオ — 最小限の説明が失敗する場所

Customer Support Resolution Agentは6つのCCA-F試験シナリオの1つであり、tool interface designの失敗が露呈する正規の舞台だ。シナリオは通常、いくつかのツールで設定されたエージェントを提示する：

• search_knowledge_base — 内部のポリシーとFAQ記事を取得する。
• search_web — 外部情報のために公共ウェブを検索する。
• analyze_content — 最小限に「コンテンツを分析する」と説明されている。
• analyze_document — 最小限に「ドキュメントを分析する」と説明されている。
• create_ticket — 人間のエージェントにエスカレーションする。

顧客が「Anthropicの最近の利用規約の変更を確認してもらえますか？」と尋ねると、Claudeはsearch_webを正しく呼び出し、ウェブ結果を受け取り、その後analyze_contentとanalyze_documentのどちらかを選ばなければならない。両方のツールが1行の説明を持つため、Claudeは推測する。試みの半分で、inputがドキュメントではなくウェブ結果であるにもかかわらずanalyze_documentを選び、ツールはサイレントに失敗するかinput schemaの不一致がアップストリームで捕捉されなかったために不正な出力を返す。

最小限の説明の失敗モード

最小限の説明はこのように見える：

{
  "name": "analyze_content",
  "description": "Analyzes content.",
  "input_schema": { ... }
}

Claudeはこれを「コンテンツに何かをするツール」として見る。兄弟ツールのanalyze_documentが同様に最小限の説明を持つ場合、Claudeには両者を区別する原則的な方法がない。選択はユーザーの最新メッセージの表面的なキーワードとどちらの名前がより一致するかによって重み付けられたコインフリップになる。ユーザーのプロンプトの「document」は、実際に流れるデータがウェブ検索結果であってもanalyze_documentに傾く。

拡張された説明による修正

拡張されたバージョンは目的・input・output・例・明示的な境界を含む：

{
  "name": "extract_web_results",
  "description": "Extracts structured information from web search results returned by search_web. Accepts an array of SearchResult objects (title, url, snippet). Returns a summary paragraph plus a list of cited URLs. Use this tool whenever you need to synthesize information from the public web. Do NOT use this tool for customer-uploaded documents — use analyze_document for that purpose.",
  "input_schema": { ... }
}

2つの改善が重なる。まず、名前がanalyze_contentからextract_web_resultsに変更され、analyze_documentとのキーワードの重複が排除された。次に、説明がツールが消費するもの・生成するもの・使用すべき時・そして最も重要なことに使用すべきでない時を含むようになった。

主要な選択メカニズムとしてのTool Description

4つのシグナル、1つが支配的

Claudeがツールを選択するとき、4つのシグナルが競合する：

1. 説明テキスト（支配的） — 目的とスコープの最も豊かな自然言語説明。
2. ツール名（セカンダリ） — 弱いキーワードシグナル。説明が類似している場合に役立つ。
3. Input schema（ターシャリ） — コンテキストから必須パラメーターを設定できないツールを排除する。
4. システムプロンプトのヒント（条件付き） — 選択にバイアスをかけることができるが、明確に境界設定された説明をオーバーライドできない。

CCA-F試験は候補者がこのランキングを理解しているかどうかを問う。「より多くのシステムプロンプト指示を追加する」がmis-routingへの答えだと信じる候補者はCustomer Supportシナリオで失点する。説明を書き直す候補者は合格する。

説明品質のルーブリック

本番グレードのツール説明は6つすべての基準を満たす：

• 目的声明 — ツールが何をするかについての1文。
• Inputコントラクト — ツールが期待するデータ（型と起源）。
• Outputコントラクト — ツールが返すもの（形状）。
• ポジティブな例 — 1〜2つの呼び出し例（「ユーザーがXと尋ねる場合に使用する」）。
• ネガティブな境界 — 明示的な「Yのときには使用しないこと；代わりにZを使用する」。
• エッジケースのノート — エラー条件・レート制限・前提条件の状態。

境界を省略した説明が最も一般的な失敗モードだ。境界の代わりに単一の例を使おうとする説明が2番目に一般的だ。

Purpose-SpecificツールとジェネリックツールTooltips

Split-vs-Consolidateの決定

直感的には、ツールが少ない方が認知負荷が低く、エージェントの設定が単純に見えるかもしれない。CCA-F試験はこの直感を罰する。2つのツールが目的で重複している場合、正しいアーキテクチャ的な動作は、それらをより狭く重複しない説明を持つpurpose-specificツールに分割することであり、動作の和を持つ1つのジェネリックツールに統合することではない。

なぜか？「ウェブ結果・ドキュメント・画像・メールを分析する」という説明を持つanalyzeというStatisticsツールは、Claudeにコンテキストからinput型を推測してから内部的に分岐することを強制する。Claudeはツール選択後にそのツールの実装内で分岐が起こり、選択メカニズムはツールの間の境界でのみ動作するため、これを信頼性高く行うことができない。

名前変更によるDisambiguationパターン

分割に付随するパターンはキーワードの重複を排除するためのツールの名前変更だ。CCA-Fのサンプル問題からの正規の例：

• 変更前：analyze_content + analyze_document（どちらもanalyze_で始まり、どちらも「分析する」と主張する）
• 変更後：extract_web_results + parse_customer_document（共通のプレフィックスなし、共通の動詞なし）

名前変更操作は装飾的ではない。説明が薄いときにClaudeを間違ったツールに傾けた偶発的なトークンの重複を取り除く。拡張された説明と組み合わせることで、名前変更+説明パターンはmis-routingシナリオへのCCA-F標準の答えになる。

InputとOutputのコントラクト

制約としてのInput Schema

input_schemaはJSON Schemaだ。どのパラメーターが必須・オプションか・型・enum制約・値の範囲をClaudeに伝えるのが仕事だ。よく設計されたinput schemaは：

• ツールが実際に必要とするフィールドのみを持つ（台所の流しのようなパラメーターなし）。
• 必須と任意の意味のある区別。
• 閉じたセットがある場合はEnum値（例：priority: "low" | "medium" | "high"）。
• トップレベルオブジェクトだけでなく、ネストされたフィールドへの説明。

タイトなinput schemaはセカンダリ選択シグナルとして機能する：ツールがsearch_query_idパラメーターを必要とするが現在のコンテキストにそのようなIDがない場合、Claudeは説明が一致するように見えてもそのツールを優先順位付けしない。

ハンドオフコントラクトとしてのOutput形状

同様に重要なのはOutput形状だ。{ "result": "..." }を返すツールと{ "summary": "...", "citations": [...], "confidence": 0.87 }を返すツールは、非常に異なるダウンストリームの可能性を生む。2番目の形式はcoordinatorエージェントに構造化された決定（「confidenceが0.7未満ならcreate_ticketを呼び出す」）を可能にし、最初の形式はcoordinatorに非構造化テキストを再パースすることを強制する。

MCPツールの場合、レスポンスエンベロープにはisError・errorCategory・isRetryableフィールドも含まれる（companion topic「Structured Error Responses for MCP Tools」で説明されている）。これらはユーザー向けのcontentの外にあっても、Outputコントラクトの一部だ。

境界定義 — ツールが行わないこと

3部構成の境界条項

本番グレードの境界条項は3つの部分を持つ：

1. ポジティブスコープ — 「[条件Xが成立する場合]にこのツールを使用する。」
2. ネガティブスコープ — 「[条件Yが成立する場合]にはこのツールを使用しないこと。」
3. リダイレクト — 「[条件Yの場合]には代わりに[他のツール名]を使用する。」

Customer Supportシナリオへの適用例：

search_webからの出力を処理する場合はextract_web_resultsを使用する。このツールは顧客がアップロードしたファイルには使用しないこと — それらには代わりにparse_customer_documentを使用する。

この1文で最小限の説明バージョンのmis-routing失敗モードが排除される。

ツールファミリー間の境界

境界は混同される可能性のあるツール間でペアごとに書かれるべきだ。create_ticketとextract_web_resultsの間に境界条項は必要ない。どんな合理的なユーザーの意図もどちらにもルーティングしないからだ。しかしanalyze_documentとextract_web_resultsの間には絶対に必要だ。両方がテキストを消費し、両方がサマリーを生成するからだ。

システムプロンプトのキーワード感度とツール説明

システムプロンプトが選択にバイアスをかける場合

システムプロンプトが「あなたはドキュメント分析エージェントです」と言い、ユーザーが一般的な質問をすると、Claudeは説明に「ドキュメント」が含まれるツールにバイアスがかかる。実際のユーザーの意図がウェブ検索であっても。このキーワード感度が、ツール説明が薄い場合にシステムプロンプトを慎重に書かなければならない理由だ。

しかし修正はシステムプロンプトからキーワードを削除することではない。ツール説明を強化して、ツール間の境界がシステムプロンプト誘発のバイアスに対してロバストになるようにすることだ。

説明ファーストのルール

CCA-F試験シナリオで正しい診断順序は：

1. まず、ツール説明を調べる。最小限か？重複しているか？境界が述べられているか？
2. 説明がすでに本番グレードである場合のみ、キーワードバイアスのためにシステムプロンプトを調べる。
3. 両方が正しい場合のみ、tool_choiceのオーバーライドを検討する。

この順序を逆にする候補者（最初にシステムプロンプトを責める）はmis-routing問題で一貫して間違った答えを選ぶ。

やさしい解説: Tool Interface Design

抽象的なスキーマの議論は、物理的な比喩に基づいて定着する。CCA-Fのtool interface designの全範囲をカバーする3つの異なる比喩を紹介する。

Analogy 1: ラベルの付いた仕切りのある工具箱

大工の工具箱を想像してほしい。中のツール（ハンマー・ドライバー・レンチ・ノミ）は、大工がプレッシャーの下で素早く適切なものを選べる場合にのみ有用だ。すべての仕切りが単に「工具」とラベルされていると、大工は各仕切りを開ける時間を無駄にする。ラベルが「釘には​ハンマー、ネジには使わないこと — ネジにはドライバーを使う」と言えば、大工は薄暗い光の中でも常に正しく選ぶ。

Claudeのツールレジストリも同じように機能する。descriptionフィールドが仕切りのラベルだ。最小限の説明（「コンテンツを分析する」）は「工具」とラベルされた仕切り、つまり役に立たない。境界のある説明（「ウェブ検索結果から構造化データを抽出する；顧客がアップロードしたファイルには使わないこと — それにはparse_customer_documentを使う」）は「釘にはハンマー、ネジには使わない」とラベルされた仕切り、つまり明確だ。

この比喩はすべてのtool interface designの概念にマッピングされる：

• ツール名は仕切りの前面の短いステッカーだ。
• ツール説明は下の完全なラベルだ。
• ツール境界はラベルの「使わない場合...」の付記だ。
• Purpose-specificツールは単一目的の仕切りだ（1つの仕切りに1つのもの、「すべての固定具」ではない）。
• Input/outputコントラクトは仕切りのマッチした形状だ。ドライバーの仕切りにレンチを入れることはできない。

Analogy 2: 病院のトリアージデスク

病院の救急病棟には複数の専門医がいる（心臓病専門医・整形外科医・神経科医・小児科医）。入口のトリアージ看護師は各患者を適切な専門医に振り分ける。看護師のルーティング案内が「スミス先生は患者を診る」と「ジョーンズ先生は患者を診る」（最小限の説明）と書かれていれば、看護師は推測して患者が誤ってルーティングされる。案内が「スミス先生は胸痛・息切れ・心臓血管の緊急事態を診る；小児科または整形外科のケースではない — それらはジョーンズ先生かリー先生へ」と書かれていれば、看護師は正しくルーティングする。

Claudeがトリアージ看護師だ。各ツールが専門医だ。ツール説明がルーティング案内だ。案内に明示的な境界がなければ、看護師（Claude）は確実にルーティングできない。境界があれば（「条件Xのときはこの専門医を使用；Yのときは使わない；Yにはspecialist Zを使う」）、ルーティングは境界線上のケースでも確定的になる。

この比喩はなぜ統合が間違いなのかを理解するのに特に役立つ。心臓病学と整形外科学を単一の「一般専門医」に統合してもトリアージ看護師の役には立たない。専門医が内部で再トリアージすることを強制し、これはagentic systemが信頼性高くできないことだ。

Analogy 3: 専門司書がいる図書館のレファレンスデスク

大きな大学図書館には複数のレファレンス司書がいて、それぞれが専門分野を持つ（理系・人文系・貴重書・デジタルアーカイブ）。利用者が質問を持って近づく。デスクには各司書を説明したカードが置かれている。

カードに「レファレンス司書」（最小限の説明）とだけ書かれていれば、利用者（またはルーティングする係員）は推測しなければならない。カードに「貴重書司書 — 1900年以前の印刷物と写本を担当；デジタルのみの資料は担当しない — それはデジタルアーキビストに尋ねてください」と書かれていれば、ルーティングは明確だ。

拡張されたカードが何をするかに注目してほしい：ポジティブスコープ（「1900年以前の印刷物」）・ネガティブスコープ（「デジタルのみは担当しない」）・リダイレクト（「デジタルアーキビストに尋ねる」）を与える。これがClaudeのツール説明の3部構成の境界条項パターンそのものだ。

試験当日にどの比喩を使うか

• ツール説明の品質と境界についての質問 → 工具箱の比喩。
• ルーティングの曖昧さとmis-selectionについての質問 → 病院のトリアージの比喩。
• Purpose-specificツール対ジェネリックツールと名前変更によるdisambiguationパターンについての質問 → 図書館のレファレンスデスクの比喩。

Description-vs-Few-Shotのトラップ — 説明が勝つ

これはCCA-F Domain 2で最も頻繁に問われるトラップであり、独自のセクションが必要だ。

シナリオが2つのツール間のmis-routingを提示する。4つの答えの選択肢：

• (A) 代表的なユーザークエリに対する正しいツール選択を示すfew-shotの例をシステムプロンプトに3〜5個追加する。
• (B) ツール説明を拡張してポジティブスコープ・ネガティブスコープ・リダイレクト条項を含める。
• (C) 2つのツールを内部分岐を持つ1つのジェネリックツールに統合する。
• (D) 要求の前にルーティングする小さなClassifierを訓練する。

正しい答えは(B)だ。なぜか？

• システムプロンプトのfew-shotの例 (A) は局所的で脆弱だ。例のケースでは機能するが、新しい言い方では劣化する。また毎ターンのトークン使用量も増加する。
• 拡張された説明 (B) はグローバルだ。すべてのターン・すべての言い方・すべての新しいケースに適用される。AnthropicのTool use公式ドキュメントに従った意図されたメカニズムでもある。
• 統合 (C) はツールの選択境界ではなくツールの内部でClaudeにinput型を推測させることで問題を悪化させる。
• 外部Classifier (D) は新たな障害点を追加してagentic architetureを完全に回避する。

ツール粒度 — 合成可能な細かい粒度 vs モノリシックな多機能

関連するアーキテクチャ的な決定はツールの粒度だ。関連するケーパビリティのファミリーが与えられた場合、modeパラメーターを持つ1つの大きなツールを公開するか、それぞれが1つのことをするいくつかの小さなツールを公開するか？

モノリシックアプローチ

1つのツール、多くのモード：

{
  "name": "analyze",
  "description": "Analyzes content. Pass mode: 'web' for web results, 'document' for documents, 'email' for emails.",
  "input_schema": {
    "type": "object",
    "properties": {
      "mode": { "enum": ["web", "document", "email"] },
      "content": { "type": "string" }
    }
  }
}

合成可能なアプローチ

複数のツール、目的ごとに1つ：

[
  { "name": "extract_web_results", "description": "..." },
  { "name": "parse_customer_document", "description": "..." },
  { "name": "summarize_email_thread", "description": "..." }
]

CCA-Fでどちらが勝つか

合成可能なアプローチが特にCustomer SupportのほとんどのCCA-Fシナリオで勝つ。理由：

• Purpose-specificツールはより引き締まった境界とより明確な説明を持つ。
• Input/outputコントラクトはツールごとであり、モード間でのUnion形状ではない。
• 選択はツール境界（Claudeが得意）で起こり、ツールの内部（エージェントが弱い）では起こらない。

モノリシックアプローチが正しいのは、モードが本当に同一のinput/outputコントラクトを共有して些細な設定フラグのみで異なる場合のみだ。これは実際には稀だ。

説明のアンチパターン

CCA-F試験ガイドとAnthropicのエンジニアリングブログは説明アンチパターンの短いリストに収束している：

• 曖昧な動詞 — 「分析する」・「処理する」・「扱う」。具体的な動詞に置き換える：「から引用を抽出する」・「のPDFヘッダーをパースする」・「スレッドの返信を要約する」。
• スコープなし — コンテンツの種類を言わずに「コンテンツを分析する」。Input型とソースを追加する。
• 前提条件なし — 事前の状態を必要とするツール（例：最初にsearch_webが呼び出されていなければならない）だが説明にそれが書かれていない。
• ネガティブな境界なし — ツールが何をするかだけを言い、何をしないかを決して言わない説明。
• 過負荷な説明 — 3つのタスクをカバーしようとする単一の説明。3つのツールに分割する。
• コピー&ペーストされた説明 — 1つの名詞だけ異なるほぼ同一の説明を持つ2つのツール。

このリストの各アンチパターンはCustomer Supportシナリオの少なくとも1つの文書化された失敗モードに対応する。

本番前のツール説明のテスト

本番グレードのtool interface designには説明テストのステップが含まれる。アプローチ：

• Selection eval — 予想されるツール名とペアになったキュレーションされたユーザークエリを登録されたツールでClaudeに通し、選択精度を測定する。
• 境界プローブ — 2つのツールの間に位置するよう設計された境界線上のクエリ。境界条項が十分に強いかを測定する。
• アブレーションテスト — 1つのツールの説明フィールドを一時的に削除（まず境界から始める）して精度の低下を観察する。どの説明要素が最も重みを持つかを伝える。

CCA-Fは候補者にこれらのevalを実装することを求めないが、説明品質が評価可能であり、単に審美的ではないことを認識する候補者を評価する。

よくある試験のトラップ — Tool Interface Design

CCA-F試験はtool interface designに紐付けられた6つの繰り返すトラップパターンを積極的に利用する。認識が反射的になるまで各パターンを練習する。

トラップ1：説明拡張の代わりにFew-Shotの例

上で詳しく説明した。mis-routingシナリオが現れると、トラップの答えは「システムプロンプトに例を追加する」と言う。正しい答えは「説明を拡張する」と言う。

トラップ2：分割の代わりに統合

「modeパラメーターを持つ1つのツールに2つのツールを統合する」と言う答えの選択肢はほぼ常に間違いだ。分割がCCA-Fのデフォルトだ。

トラップ3：Selectionをオーバーライドするためにtool_choiceを強制する

「Claudeの選択判断をバイパスするためにtool_choice: forcedを使用する」と言う答えの選択肢は、シナリオが特定の確定的な構造化出力を必要としない限り間違いだ。強制は選択メカニズムをバイパスし、説明が壊れていることを認める。

トラップ4：より良い説明の代わりにより多くのツールを追加する

トラップ：「適切なツールを選んでそれを呼び出すルーターツールを追加する。」これは根本的な説明問題を修正せずに間接性を追加する。正しい答えは依然として既存ツールの説明を修正することだ。

トラップ5：拡張なしの名前変更

微妙なトラップ：答えの選択肢が「analyze_contentをextract_web_resultsに名前変更する」と言うが説明も拡張しない。名前変更だけでは不十分だ。説明がまだroutingシグナルを持っている。正しい答えは名前変更+拡張を組み合わせる。

トラップ6：説明をシステムプロンプトのサーフェスとして扱う

「ツール説明の内容をシステムプロンプトに移動する」と言う答えの選択肢は間違いだ。説明は選択時にClaudeが見るツールごとのメタデータだ。システムプロンプトはセッションレベルの指示であり、バイアスをかけるが説明を置き換えない。

実践アンカー — タスク2.1シナリオ問題

tool interface designに紐付けられたCCA-F実践問題はCustomer Support Resolution Agentシナリオを中心に、Developer Productivityシナリオにも集中している。

アンカーA：analyze_content対analyze_documentのMis-Routing

カスタマーサポートエージェントがsearch_web・search_knowledge_base・analyze_content・analyze_documentで設定されている。ユーザーが最近の外部情報について尋ねた際にツールエラーが起きると報告がある。調査でClaudeが時々ウェブ検索結果にanalyze_documentを呼び出すことが判明した。最善の修正は何か？

• (A) ツールへのユーザークエリのマッピングを示すfew-shotの例をシステムプロンプトに追加する。
• (B) analyze_contentをextract_web_resultsに名前変更して、明示的なスコープ・例・「使わない場合...」リダイレクト条項を含めるよう両方の説明を拡張する。
• (C) analyze_contentとanalyze_documentをmodeパラメーターを持つ単一ツールに統合する。
• (D) search_webが呼び出されたときは常にtool_choiceをanalyze_contentにforceする。

正解：(B)。名前変更によりキーワードの重複が排除され、拡張された説明がroutingシグナルを提供し、境界条項が境界線上のケースのmis-routingを排除する。

アンカーB：Developer Productivityエージェントでの最小限の説明

コードアシスタントエージェントにread_file・write_file・search_code・analyze_codeツールがある。「認証を処理するすべての場所を見つける」と尋ねるとsearch_codeとanalyze_codeが交互に選択されると報告がある。根本原因は何か？

正解：両方の説明に「マッチを見つける」（search_code）と「コードの意味論について推論する」（analyze_code）を区別する境界条項がない。 修正は両方の説明にスコープ+ネガティブスコープ+リダイレクト条項を追加することだ。

アンカーC：統合シナリオ

チームが4つのpurpose-specificツール（search_kb・search_web・extract_web_results・parse_customer_document）をsource_typeパラメーターを持つ単一のask_anythingツールに置き換えることを提案する。試験で正しい批評は何か？

正解：統合はツールごとのinput/outputコントラクトとツールごとの説明境界を削除し、ツール境界ではなくツール内部でClaudeに分岐させる。元のpurpose-specificな設計はアーキテクチャ的に健全であり、統合はそれを後退させる。

アンカーD：システムプロンプト対説明の優先度

チームにmis-routingのバグがある。ツール説明を拡張するか、キーワードヒントでシステムプロンプトを調整するかのどちらかを提案する。どちらを最初に行うべきで、なぜか？

正解：まずツール説明を拡張する。説明が主要な選択シグナルであり、システムプロンプトはセカンダリ。説明を修正せずにシステムプロンプトを調整すると、新しいユーザーの言い方で壊れる脆弱なroutingが生じる。

アンカーE：境界条項の構築

重複した目的を持つ2つのツールが与えられた場合、最初のツールの境界条項を書く。期待されるパターン：

「[ポジティブスコープの条件]の場合は<tool_a>を使用する。[ネガティブスコープの条件]の場合には<tool_a>を使用しないこと — 代わりに<tool_b>を使用する。」

この3部構成パターンを生成する候補者はCCA-Fタスク2.1問題で一貫して正しいスコアを取る。

Tool Interface Design よくある質問

CCA-FのためのClaude ToolDefinitionで最も重要なフィールドは何か？

descriptionフィールドだ。登録されたツールの中から選択する際にClaudeが使用する主要な選択シグナルだ。nameは弱く貢献し、input_schemaはツールが呼び出される方法を制約するがどうかを制約しない。CCA-Fはこれら3つのフィールドの非対称なウェイトを明示的に問う。説明を最小限にしながらinput_schema設計に過剰投資する候補者はDomain 2問題で一貫して誤答する。

2つのツールがmis-routeされる場合、システムプロンプトにfew-shotの例を追加するかツール説明を拡張するか？

ツール説明を拡張する。これはCCA-F Domain 2で最も頻度の高いトラップだ。システムプロンプトのfew-shotの例は脆弱（新しい言い方で失敗する）でトークンコストが高く（毎ターンコストがかかる）、根本的な選択メカニズムに対処しない。ツール説明が選択メカニズムだ。正しい修正は両方の説明をポジティブスコープ・ネガティブスコープ・リダイレクト条項で書き直すことであり、多くの場合1つのツールを名前変更してその兄弟とのキーワードの重複を排除することも含む。

「purpose-specificツール」とは何で、なぜCCA-FはジェネリックツールよりもそれをPreferするのか？

Purpose-specificツールはそのinterface（名前・説明・inputコントラクト・outputコントラクト）が単一の明確に定義されたタスクに厳密にスコープされたツールだ（例えばextract_web_resultsはsearch_webの出力のみ）。CCA-Fはpurpose-specificツールをPreferする。なぜならその狭い境界が説明をよりクリーンにし、選択をより確実にし、mis-routingをより少なくするからだ。analyze_contentのようなジェネリックツールはClaudeにツールの選択境界ではなく、ツール内部でinput型を推測させる。これはその決定に間違ったレイヤーだ。

ツール境界とは何で、どう書くか？

ツール境界は、ツールのスコープの限界をClaudeに伝え、スコープが超えられた場合に兄弟ツールにリダイレクトする、説明内の明示的な「使わない場合」条項だ。3部構成で境界を書く：ポジティブスコープ（「条件Xのときにこのツールを使用する」）・ネガティブスコープ（「条件Yのときにはこのツールを使用しないこと」）・リダイレクト（「Yには代わりにtool_zを使用する」）。混同される可能性のあるツール間でペアごとに境界条項を適用する。3部構成パターンはmis-routingを排除するためのCCA-F標準の答えだ。

よく書かれたシステムプロンプトは弱いツール説明によるmis-routingを修正できるか？

いいえ。よく書かれたシステムプロンプトは選択にバイアスをかけることができるが、新しい言い方にわたって弱い説明を確実にオーバーライドすることはできない。CCA-F試験は説明ファーストの診断順序を評価する：まずツール説明を調べ、2番目にシステムプロンプトを調整し、最後にtool_choiceのオーバーライドを検討する。この順序を逆にする候補者はmis-routing問題で一貫して間違った答えを選ぶ。

modeパラメーターを持つ1つのツールに統合すべきか、それともpurpose-specificツールに分割すべきか？

分割する。CCA-Fのデフォルトはジェネリックツールをより引き締まった説明・重複しない境界・ツールごとのinput/outputコントラクトを持つpurpose-specificツールに分割することだ。統合はClaudeにツール境界ではなくツール内部で分岐させる。Claudeが強いのはツール境界での選択であり、ツール内部での分岐ではない。唯一の例外は「モード」が本当に同一のinput/outputコントラクトを共有して些細なフラグのみで異なる場合で、これは実際には稀だ。

ツール名は重要か、説明のみが重要か？

説明が支配的だが、名前は無視されない。2つのツールが類似した説明を持つ場合、名前のキーワードの重複（analyze_content対analyze_document）がClaudeを間違った選択に傾けることがある。CCA-Fの標準的な修正は名前変更+拡張を組み合わせる：名前変更してキーワードの重複を排除し（extract_web_results対parse_customer_document）、説明を拡張して明示的な境界条項を含める。名前変更だけでは不十分であり、拡張だけで十分な場合が多い。両方を行うのが最もロバストなパターンだ。

参考資料

• CCA-F Exam Guide (official PDF): https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Define tools — best practices for tool descriptions and tool_choice: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/implement-tool-use
• Writing tools for agents — Anthropic Engineering Blog: https://www.anthropic.com/engineering/writing-tools-for-agents
• Tool use with Claude — overview and agentic loop: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
• Handle tool calls — tool_result format and error responses: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• Community pass report (Kishor Kukreja, 893/1000): https://medium.com/@kishorkukreja/i-passed-anthropics-claude-certified-architect-foundations-exam-with-a-score-of-893-1000-2206c27efd6c

関連するExamLabのトピック：Structured Error Responses for MCP Tools、Tool Distribution Across Agents and Tool Choice Configuration、MCP Server Integration into Claude Code and Agent Workflows、Built-in Tools Selection and Application。