CCAR-F 学習ノート（非公式）合格体験記へ

ツール設計とMCP統合

音声は3本です。

この章でできるようになること

モデルがツールを選ぶ材料を、説明として書ける。失敗を、次の行動が決まる構造で返せる。役割に対してツールが多すぎる状態と、少なすぎて往復が増える状態を分けられる。MCPの設定を、共有するものと個人の実験で置き分け、カタログと操作を混ぜない。コードを読むとき、中身の検索、ファイル名の検索、部分修正、全体の書き直しを取り違えない。

30秒で全体像

モデルはツール名の雰囲気ではなく、説明文を読んで次のツールを選びます。説明が似ていると、注文番号が顧客取得へ流れます。失敗は「失敗しました」では再試行の判断ができません。種類と、再試行してよいかを返します。一致ゼロの成功と、タイムアウトは別です。ツールを増やすほど選択は不安定になります。よくある単純な確認だけ、範囲を切って持たせます。tool_choice は、文章でもよいか、どれかのツールを必須にするか、名前まで固定するかをハーネスが決めます。チームで使うMCPはプロジェクトの .mcp.json に環境変数で秘密を置き、個人の実験は ~/.claude.json です。何があるかはリソース、何をするかはツールです。中身は Grep、パスは Glob、一意な置換は Edit、錨が一意でなければ Read してから Write します。

用語

用語 意味
ツール説明 選択の本文。目的、入力の形、例、端のケース、使わない場合
isError この結果は失敗である、とエージェントに渡すフラグ
errorCategory 失敗の種別。一時的、検証、権限が典型
isRetryable 同じ方針で再試行してよいか。方針違反では否
有効な空結果 問い合わせは成功し、該当が無かった状態
tool_choice: auto ツールを呼ばず文章を返してよい
tool_choice: any どれかはツールを必ず呼ぶ
強制ツール選択 指定した名前のツールを、このターンで呼ぶ
.mcp.json リポジトリで共有するMCPの設定
~/.claude.json その利用者だけの実験用MCP
環境変数展開 設定ファイルに秘密を書かず、実行時に環境変数を埋めること
MCPリソース 課題一覧、文書の階層、スキーマなど、何があるかのカタログ
MCPツール 副作用または取得を行う操作
Grep ファイルの中身をパターンで探す
Glob パスや拡張子でファイルを探す
Edit 一意な文字列を錨にした部分修正
Read / Write ファイル全体の読み書き
Bash シェルコマンド。中身の検索や一意な置換の代わりではない

方針に反する操作は、概念としては一時的な失敗、入力の検証失敗、権限の失敗とは別です。返すカテゴリの例は transient、validation、permission です。方針違反には、再試行しない真偽値と、利用者にそのまま読める説明を付けます。フラグ名は isRetryable と書かれることも、retriable と書かれることもあります。意味は、無駄な再試行を止める真偽値です。

本編

選択の本文は説明である

モデルに渡るツール一覧は、名前、説明、入力のスキーマです。名前が get_customer でも、説明が「情報を取得する」だけなら、注文番号に見える文字列をこちらへ渡します。隣の lookup_order が「詳細を取得する」だと、モデルは両方を同じ道具として扱います。

説明に書くのは四つです。何のためのツールか。入力はどの形式か（顧客IDなのか、注文番号なのか、電話番号は受けないのか）。どんな依頼の例で使うか。似たツールのどちらを使わないか。

「注文番号は A- で始まる。利用者の表示名では呼ばない。顧客の本人確認は get_customer の仕事で、このツールは確認済みIDを前提にしない」まで書くと、表示名だけの依頼は顧客取得へ、番号だけの依頼は注文参照へ分かれます。

説明がほぼ同じ二つの analyze_content と analyze_document は、名前を変えても説明を放置すると揺れます。ウェブの抽出に限るなら、名前を extract_web_results にし、説明も「HTMLから本文とURLを抜く。PDFは受けない」に変えます。名前だけの改名は、モデルが説明を読むので効果が薄いです。

一つの analyze_document に、要点、要約、出典との照合を全部させると、呼び出しごとに返す形が変わります。契約を分けます。extract_data_points は欄を返す。summarize_content は段落を返す。verify_claim_against_source は主張と抜粋と一致可否を返す。呼び出した側は、どの形が戻るかをツール名で知れます。

システムプロンプトの語が説明に勝つことがある

説明を丁寧にしたあとも選択が悪いときは、システムプロンプトに「分析という言葉が出たら analyze_document」のような行が残っていないかを見ます。モデルは説明と、常時の指示の両方を見ます。常時の指示がキーワードでツールを結びつけると、説明の境界が負けます。直す順序は、キーワードの行を消し、説明の境界を残す、です。

最初の一手として、具体例を十件足すのは後です。例はトークンを使い、説明が短いままなら同じ取り違えが新しい言い回しで起きます。発話から正規表現でツールを決める前処理は、モデルが文脈で読める差（「返して」が返金なのか返却なのか）を捨てます。二つのツールをすぐ一つに統合すると、入力の契約が曖昧なまま内部の分岐へ隠れ、失敗の理由も混ざります。説明を直したあとに、まだ契約が一つだと分かってから統合します。

失敗は、次の行動が分岐できる形で返す

isError が立っていない結果を、モデルは成功として読みます。本文に「失敗」と書いてあっても、フラグが無いと成功の文章として扱われることがあります。失敗はフラグと構造の両方です。

種類を分ける理由は、次の手が違うからです。

一律の "Operation failed" は、この四つを同じにします。モデルは再試行するか、謝るか、人へ渡すかを選べません。再試行を選ぶと、権限エラーを十回繰り返します。

一致がゼロ件だった検索は、失敗ではありません。問い合わせは成功し、該当が無かった、です。これを isError にすると、モデルはクエリを変えて無限に再試行します。空の配列を、エラーフラグなしで返します。タイムアウトの空と、成功の空を同じ [] にすると、後段は「記事が無かった」と「記事を取りにいけなかった」を区別できません。後者は穴であり、前者は調査の結論です。

サブエージェントは、一時的な失敗を自分の中で数回まで復旧します。復旧できないものだけを、種類、試したクエリ、取れた部分結果とともに親へ返します。「検索を利用できません」の一文は、親からクエリを変える材料を奪います。空を成功として返すのは、失敗を消します。一つのタイムアウトで調査全体を終了するのは、取れていた部分まで捨てます。

持たせる数と、横断させる例外

ツールが十八個あるエージェントは、説明を読んでもなお、近い二つの間で揺れます。四つか五つに収まる役割へ十八個を渡すと、選択のたびに無関係な説明がノイズになります。統合役にウェブ検索を持たせると、統合の途中で探索を始め、返すべき構造を書きません。

基本は、その役割のツールだけです。例外は、頻度が高く、契約が狭い確認です。統合の八割が「この日付と固有名詞が源泉と一致するか」だけなら、verify_fact を統合役に持たせます。入力は主張とURL、出力は一致、不一致、源泉に記述なし、です。残りの二割の「この分野を調べ直せ」は、親経由で検索役へ戻します。検索ツール一式を統合へ渡すと、例外が役割そのものになります。

汎用の fetch_url は、任意のURLを取りにいきます。文書限定なら load_document にし、許可した文書ホスト以外は検証エラーにします。できることを減らすのは、選択を安定させるためです。

tool_choice は、モデルの自由度をハーネスが一段絞る

モデルは、何も制約されないと、ツールを呼ばずに文章で答えることがあります。抽出の仕事では、その文章は機械が読めません。tool_choice はその自由度の上限です。

flowchart TD
  A[このターンの出力] --> B{構造が必須か}
  B -->|いいえ| C["auto: 文章でもよい"]
  B -->|構造は必須、道具はモデルが選ぶ| D["any: どれかのツール"]
  B -->|この道具を先に通す| E["強制: 名前を指定"]

auto は対話の既定です。方針の説明を文章で返してよいときに使います。抽出なのに auto のままだと、モデルは表を文章で書き、パーサが失敗します。

any は、ツールを必ず一つ呼びます。どれを呼ぶかはモデルです。文書の種類が請求書か納品書か不明で、スキーマが二つあるときに、文章への逃げを止めます。

強制は、名前まで指定します。エンリッチの前に extract_metadata を通したい、という先頭の固定です。後続のツールは次のターンで、結果を見たモデルが選びます。一ターンの強制で全工程を並べる仕組みではありません。強制したツールの結果が履歴に入り、次の auto または any で続きが決まります。

強制を常用すると、モデル主導の利点が消えます。先頭の一段だけに使います。

MCPをどこに置くか

チーム全員が使う課題管理サーバーは、リポジトリの .mcp.json です。クローンした人が同じツールを見ます。トークンをそのファイルに書くと、履歴に秘密が残ります。${GITHUB_TOKEN} のように環境変数の名前だけを書き、値は各人の環境に置きます。

個人の実験、まだチームに配りたくないサーバーは ~/.claude.json です。個人の指示が ~/.claude/CLAUDE.md だからといって、MCPの利用者スコープを同じディレクトリの中だと思わないでください。ファイルが違います。ホームのクロード配下に .mcp.json を置いても、利用者が実験用として読む場所にはなりません。

接続すると、設定済みの全サーバーのツールが検出され、同時に並びます。共有と個人の両方を置くと、両方のツールがエージェントから見えます。実験用の危険なツールを個人設定に置いたまま共有リポジトリを開くと、その危険なツールも候補に入ります。実験が終わったら個人設定から外します。

標準的な課題管理のように、すでに広く使われているサーバーがあるなら、自作よりそれを使います。自作は、社内の権限体系や、そのチームだけの操作が必要なときまで残します。自作のサーバーをどこへ配備するかは、エージェントから見た契約の話ではありません。ここでの技能は、設定と、ツールとリソースの境界です。

説明が薄いMCPツールは、高機能でも Grep に負けます。モデルは使い方の想像がつくほうを呼びます。「課題を検索する」より、「未完了の課題を、更新日と担当と要約の三欄で返す。本文全文は返さない」と書きます。

何があるかを知るための連打を減らすのがリソースです。課題の要約一覧、文書ツリー、データベースのテーブル一覧。モデルはまずリソースを読み、必要な操作だけツールで行います。カタログをツールの戻り値として毎回引かせると、同じ一覧が履歴に積み上がります。操作（コメントを書く、行を更新する）はツールのままです。カタログをツールにすると探索が増え、操作をリソースにすると、読むだけで副作用が起きたように見えます。

組み込みツールの選び方

知りたいこと 選ぶ 選ばない
関数名、エラー文字列、import の出現 Grep 全ファイルの Read、Bashでの走査
**/*.test.tsx のようなパス Glob Grep（中身は見ないので無駄）
ファイル全体を把握する、または全体を置き換える Read / Write 巨大ファイルへの最初の Read
一意な関数の中身だけ変える Edit 一意でない錨での Edit
Edit の錨が二箇所に一致した Read してから Write 錨を広げずに Edit を再試行し続ける
テストコマンドを実行する Bash Grep の代わりの grep コマンド

コードベースの理解は、最初に全部を Read しません。Grep で入口（ハンドラ名、ルート登録）を見つけ、Read でそのファイルの import をたどります。ラッパー越しに関数の使用箇所を追うときは、ラッパーが公開している名前を先に列挙し、その名前を Grep します。中身の実装名だけを探すと、公開名経由の呼び出しが漏れます。

Edit は、錨の文字列がファイル内で一意であることを要求します。一意でないと、どの出現を変えたかが不定なので失敗させます。失敗したら錨を長くして一意にするか、Read で全体を読んで Write で書き戻します。Bash で sed を使うのは、一意性の検査を自分で捨てるので、この選択基準からは外れます。

モデルが実際に見る一覧

ツールは、会話の横に一覧で渡されます。各要素は名前、説明、入力スキーマです。モデルはこの一覧と、これまでの会話だけを見て、次にどの名前を、どの引数で要求するかを決めます。ハーネスが「たぶん注文だろう」と補完することはありません。説明に無い形式は、スキーマが文字列なら通ってしまい、実行時に検証エラーになります。だから形式は、スキーマ（注文番号はパターンを持つ文字列）と、説明（A- で始まる。表示名は受けない）の両方に置きます。スキーマだけだと、モデルはなぜ拒否されたかを次のターンで知りません。説明だけだと、実行時の検査が無く、表示名がAPIまで届きます。

選択が揺れたログの読み方は、要求された名前と、その直前の利用者の文と、当時の説明の三点です。説明を変えたあとに同じ文で取り違えが減るなら、原因は説明でした。減らないなら、システムプロンプトのキーワードか、入力スキーマが両方のツールで同一（どちらも自由文字列）です。スキーマを分けると、注文ツールは注文番号の形しか受け付けず、顧客ツールは顧客IDの形しか受け付けません。形が違う依頼は、説明を読む前にスキーマで落ちます。

エラーオブジェクトを、次の手が分岐するまで書く

返したい中身は、失敗フラグ、種別、再試行可否、人に読める文、可能なら機械が読む詳細です。タイムアウトなら、種別は一時的、再試行は可、文は「注文サービスが応答しませんでした。少しあとで同じ番号をもう一度見られます」。検証なら、再試行は不可、文は「order_id は A- で始まる番号です。渡されたのは表示名です」。方針なら、再試行は不可、文は「配送から十四日を過ぎているため、このツールでは返金できません。人が例外を見る必要があればその旨を伝えてください」。権限なら、再試行は不可、文は「この認証では他者の注文を読めません」。

人に読める文を開発者向けのスタックトレースにすると、モデルはそのトレースを利用者に話し始めます。利用者向けの文と、ログ向けの詳細は欄を分けます。モデルには利用者向けの文を話させ、詳細はログだけに残します。

子の中の再試行は、一時的なものに限り、回数を小さく固定します。三回でまだタイムアウトなら、四回目をモデルに決めさせず、親へ構造で上げます。モデルに再試行の判断を任せると、同じタイムアウトを会話のターンで繰り返します。

強制のあと、次のターンは自由度を戻す

extract_metadata を強制したターンの結果が履歴に入ったあとも強制のままだと、モデルは毎ターン同じツールしか要求できません。エンリッチは起きません。ハーネスは、先頭のツールが成功した結果を観測したら、次の呼び出しの tool_choice を auto または any に戻します。失敗したなら、同じ強制を維持して取り直すか、検証エラーを結果として返してモデルに引数を直させます。強制を外す条件を「一回呼んだ」だけにすると、失敗の呼出でも次へ進みます。成功を条件にします。

リソースを先に読む一連の動き

課題管理に接続したエージェントが、最初から検索ツールを連打すると、履歴が課題の本文で埋まります。先にリソースの「未完了課題の要約」を読ませると、識別子と一行要約だけが手に入ります。モデルは必要な識別子だけを、コメント追加ツールの引数にします。リソースが無いサーバーでは、ツールの説明に「最初の呼び出しは要約だけを返せ。本文は識別子を指定した二回目で返せ」と書き、戻り値の側で本文を削ります。これは結果を履歴に足す前に切る、コンテキストの章の操作と同じ境界です。

Edit が失敗してから Write するまで

return item.total を置換しようとして、同じ行がファイルに二回あると Edit は失敗します。失敗の結果をモデルが読むので、次の手はモデルが選べます。錨を関数名ごと含めて長くするか、Read で全体を取って Write で戻すかです。ハーネスが失敗を握りつぶして「編集しました」と返すと、モデルは変わっていないファイルを変更済みとして次の説明を書きます。Edit の失敗は、成功の文に変換しません。

同じ依頼が、説明の前後で別のツールへ行く

依頼は「A-19 のヘッドホン、まだ届いていません」です。ツールは get_customer と lookup_order の二つです。

直す前の説明は、どちらも「情報を取得する」です。モデルは A-19 を顧客IDのつもりで get_customer へ渡します。顧客APIは表示名でも番号でもない文字列を受け、検証エラーか、別人の検索になります。

直したあとの注文ツールは、目的が配送状態の参照、入力は A- で始まる注文番号、例は「届いたか」「返金の対象か」、使わない場合は氏名だけ、です。顧客ツールは、目的が本人確認、入力は顧客IDか電話番号、注文番号は受けない、です。同じ依頼は lookup_order に寄ります。

名前だけを fetch_order_status に変えて説明を残すと、寄りの変化は小さいです。モデルは名前の雰囲気より説明を読みます。説明を分けたあとも半分が逆なら、システムプロンプトに「番号が出たら get_customer」が残っていないかを見ます。残っていれば、その行を消してから説明の効果を測り直します。

スキーマも分けます。注文番号は A- に続く数字、顧客IDは C- に続く数字、です。自由文字列のままでは、説明を読み違えた引数がAPIまで届きます。スキーマだけを分けて説明を一文のままにすると、拒否の理由が次のターンに伝わらず、モデルは同じ文字列を別の欄へ入れ替えます。形式はスキーマ、理由は説明、です。

四つの失敗を、同じ「空」から分ける

ログに空の配列が並んでいるとき、次の四つのどれかを先に決めます。

一時的。ステータスはタイムアウト。isError は真、種別は transient、isRetryable は真。利用者向けの文は「注文サービスが応答しませんでした。同じ番号でもう一度見られます」。子はこの種だけ、短い回数を自分で再試行し、それでも駄目なら親へ上げます。

検証。渡されたのは表示名。再試行は偽。文は「order_id は A- で始まる番号です。渡されたのは表示名です」。同じ引数の再試行は、ハーネスがしてもモデルがしても無駄です。

方針。配送から十四日を過ぎている。再試行は偽。文は、利用者にそのまま読める「このツールでは返金できません。人が例外を見る必要があればその旨を伝えてください」。スタックトレースをこの欄に置くと、モデルはトレースを利用者に話します。開発者向けの詳細は別の欄にし、モデルには渡しません。

権限。このトークンでは他者の注文を読めない。再試行は偽。文は「この認証ではその注文を読めません」。一時的と同じ再試行にすると、権限エラーを十回繰り返します。

五つ目として、成功したゼロ件があります。isError は偽、本文は空の配列です。これを失敗にすると、モデルはクエリを変えて再試行し続けます。タイムアウトの空と成功の空を同じ [] にすると、後段は「無かった」と「取りにいけなかった」を区別できません。前者は調査の結論、後者は穴です。

三ターンで、自由度を戻す条件

文書を渡して、先にメタデータ、次に種に応じた抽出、という仕事です。

一ターン目は extract_metadata を強制します。tool_choice は名前の指定です。結果がスキーマを通過したら、ハーネスは次の呼び出しの tool_choice を any に戻します。種が請求書か納品書か不明なので、文章への逃げはまだ許しません。モデルは結果を見て、どちらの抽出ツールを呼ぶかを選びます。

強制を「一回呼んだ」で外すと、メタデータが検証エラーでも次の抽出へ進みます。外す条件は成功です。失敗なら同じ強制を維持するか、検証エラーを結果として返して引数を直させます。

メタデータが要らず、種も一つで、利用者への説明も許す対話なら、最初から auto です。抽出なのに auto のままだと、モデルは表を文章で書き、パーサが失敗します。種が複数で構造が必須なら any、先頭の一段だけ名前を固定するなら強制、です。三つの違いは、文章を許すか、道具の選択を許すか、名前まで固定するか、です。

一つのバグ調査で、組み込みツールを選び直す

症状は、返金の合計が明細と一致しない、です。

最初に全ファイルを Read しません。Grep で refund と total の出現を探し、入口のハンドラを一つに絞ります。パスの一覧が欲しいだけなら Glob です。中身の文字列を Glob で探すことはできません。

ハンドラのファイルは Read で全体を見ます。巨大なら、Grep で関数名の行を先に取り、その範囲だけを読みます。呼び出し元がラッパー越しなら、ラッパーの公開名を先に列挙し、その名前を Grep します。実装の内部名だけを探すと、公開名経由の呼び出しが漏れます。

修正は、一意な関数本体だけなら Edit です。錨の return item.total がファイルに二回あると Edit は失敗します。失敗を「編集しました」に変換すると、モデルは変わっていないファイルを変更済みとして次の説明を書きます。次の手は、錨を関数名まで長くするか、Read してから Write です。Bash の sed は、一意だったかの検査を捨てるので、この失敗の代わりになりません。

テストの実行は Bash です。テストファイルの場所を探すのは Glob、落ちたアサーションの文字列を探すのは Grep、です。シェルの grep を Bash 経由で使うと、組み込みの結果の形（パスと行）を自分で解析することになります。

リソースとツールを、一回の課題更新で分ける

課題の担当を変える仕事で、最初から検索ツールを連打すると、本文が履歴に積み上がります。先にリソースの未完了一覧を読むと、識別子と一行要約だけが手に入ります。モデルは必要な識別子だけを、担当変更ツールの引数にします。

一覧をツールの戻り値として毎回引くと、同じカタログが履歴に重複します。担当変更をリソースにすると、読むだけで副作用が起きたように見えます。何があるかはリソース、何をするかはツール、です。

リソースが無いサーバーでは、ツールの説明に「一回目は要約だけ、本文は識別子を指定した二回目」と書き、戻り値の側で本文を削ります。削る場所は、履歴に足す前です。モデルに読ませたあとで要約させても、全文はすでに窓を使っています。

接続したサーバーのツールは、設定にあれば同時に候補へ入ります。実験用の書き込みツールを ~/.claude.json に残したまま共有リポジトリを開くと、そのツールも選択の候補です。実験が終わったら個人設定から外します。共有の .mcp.json にトークンの値を書くと履歴に残るので、書くのは ${GITHUB_TOKEN} のような参照だけです。ホームの .claude/ に .mcp.json を置いても、利用者が実験用として読む場所にはなりません。

標準的な課題管理は、既存のサーバーを使います。自作が残るのは、そのチームの権限や、社内だけの操作が契約に要るときです。サーバーをどの機械で動かすかは、エージェントから見た説明と設定の話ではありません。

数を減らすことと、一つに潰すことは違う

十八個のツールを四つか五つに減らすのは、無関係な説明を候補から外すためです。統合役に検索一式を持たせない、も同じ理由です。

減らしたあとに、まだ二つの説明が「文書を分析する」なら、統合は早いです。先に契約を分けます。欄を返す、段落を返す、主張と抜粋の一致を返す。呼び出した側は、どの形が戻るかを名前で知れます。契約が一つだと分かってから、一つのツールに畳みます。畳む前に統合すると、入力の形が内部の分岐へ隠れ、失敗の理由が混ざります。

横断させてよい例外は、頻度が高く、入出力が狭い確認です。主張とURLを取り、一致、不一致、記述なし、を返す verify_fact を統合に持たせます。分野の調べ直しは親経由のままです。例外の契約を広げると、例外が役割そのものになります。

どう判断するか

確認

問1

「在庫を見る」と「出荷を止める」の説明がどちらも「在庫を扱う」です。参照のつもりが停止を呼びます。最初の一手はどれですか。

A. 各説明に、入力の形、使う例、呼んではいけない場合を書く
B. 正しい選択の会話例を二十件足す
C. 発話の名詞でツールを決める前処理を先に作る
D. すぐに一つの万能ツールへ統合する

解答

A。選択の本文は説明です。例と前処理と統合は、説明が境界を持ったあとにまだ必要と分かってからで足ります。

問2

検索がタイムアウトしたときと、条件に合う記事がゼロ件のときを、どちらも空配列で返しています。どう分けますか。

A. 両方を end_turn にする
B. タイムアウトは失敗の構造、ゼロ件は成功の空として返す
C. 両方を再試行不可の権限エラーにする
D. 説明文を空にする

解答

B。成功したゼロ件は再試行の対象ではなく、失敗でもありません。

問3

統合のたびに、単純な日付確認のためだけ親経由で検索役を呼び、往復が増えています。確認の大半は単純で、一部だけ追加調査が要ります。どう持たせますか。

A. 統合に、主張とURLだけを取る確認ツールを持たせ、深い調査は親経由のままにする
B. 統合に検索ツールを全部渡す
C. 検索役に、使われそうな情報を先に全部取らせる
D. 統合のツールをゼロにし、すべての確認を人へ渡す

解答

A。全部渡すと統合が探索を始めます。先回りの全取得は、何を確認されるか確定できません。

問4

チーム全員が同じ課題管理のMCPを使い、トークンはリポジトリに残したくありません。どこへ書きますか。

A. プロジェクトの .mcp.json には環境変数の参照だけを書く
B. 各自の ~/.claude/CLAUDE.md にトークンを書く
C. スラッシュコマンドの本文にトークンを書く
D. 個人の ~/.claude.json だけに書き、共有しない

解答

A。指示ファイルは秘密の配布先ではありません。個人設定は実験用で、全員が同じツールを見る要件を満たしません。

問5

ある関数の呼び出し元を、リポジトリ全体から探します。最初のツールはどれですか。

A. Glob
B. Grep
C. 全ファイルの Read
D. 錨が一意でない Edit

解答

B。Glob はパス、Edit は部分修正、全 Read は入口の探し方として広すぎます。

自分で確かめる

用途が近いツールを二つ作り、説明を一文だけにした状態と、入力例と「使わない場合」を書いた状態で、同じ曖昧な依頼を十回ずつ投げ、選択がどちらに寄るかを数えてください。次に、タイムアウトとゼロ件を同じ空で返す版と、フラグで分けた版で、モデルが再試行する回数を比べます。最後に、統合役へ検索を全部渡した版と、verify_fact だけ渡した版で、無関係な探索が始まるかを見ます。

← 1. エージェントアーキテクチャとオーケストレーション3. Claude Codeの設定とワークフロー →