組み込みツールの選択と適用

CCA-F 試験のタスクステートメント 2.5「組み込みツール（Read・Write・Edit・Bash・Grep・Glob）を効果的に選択し適用する」は Domain 2（Tool Design and MCP Integration、18% の比重）内にあり、候補者が与えられたファイルシステムまたはシェル操作に対して、過剰に手を伸ばさずに適切なツールを選べるかをテストする。六つの組み込みツールは外から見ると小さく見えるが、CCA-F シナリオクラスターは大きく依存する：すべてのコード生成・開発者生産性・CI/CD の設問は、暗黙的に Claude が正しい選択・正しいパラメーター・正しい安全姿勢で Read・Write・Edit・Bash・Grep・Glob を呼び出していることを前提とする。ツールの境界を誤読する——Edit が必要なところで Write を使う、Glob で十分なところで Bash を使う、検索に関する問いで Grep の代わりに Glob を使う——ことは高頻度のトラップだ。

本学習ノートは、CCA-F 受験者が選択レベルで認識しなければならない組み込みツールの全領域を解説する：インベントリと目的マッピング、各ツールの正確なコントラクト、試験のフレーミングを支配する Edit 対 Write の判断ルール、Bash のリスクサーフェス、Grep と Glob のコンテンツ対パスの区別、ツール組み合わせパイプライン（コードベースリファクタリング用の Glob → Read → Edit）、大量対ターゲット操作のパフォーマンストレードオフ、そして本番グレードのエージェントと無謀なものを分ける安全確認。最終的なトラップセクションと七問の FAQ は、組み込みツールを最も多く扱う二つのシナリオ——developer-productivity-with-claude と claude-code-for-continuous-integration——にすべての概念を結びつける。

組み込みツールインベントリ — 六つのツール、六つの明確な目的

Claude Code と Claude Agent SDK は六つの標準的な組み込みツールを搭載している。各ツールは意図的に狭くスコープされている：狭いスコープにより選択が明確になり、Claude があるツールを別のツールと混同する可能性が低くなり、試験がテストするクリーンなサーフェスが得られる。CCA-F は各ツールを単一の主な目的に対応付け、そのツールが何のためではないかを知ることを求める。

• Read — 特定のファイルのコンテンツをコンテキストにロードする。オプションの行範囲。検索ツールではない。
• Write — まったく新しいファイルを作成するか、既存のファイルを完全に上書きする。外科的編集ツールではない。
• Edit — 既存のファイル内での外科的なインプレース置換。ファイル作成ツールではない。
• Bash — 任意のシェルコマンドを実行する。組み込みセット内で最も強力で最も危険なツール。
• Grep — 多くのファイルにわたってパターン（正規表現またはリテラル）でファイルのコンテンツを検索する。ファイル名検索ではない。
• Glob — パスパターン（グロビング：**/*.ts・src/**/test_*.py）でファイルを発見する。コンテンツ検索ではない。

六つのツールは CCA-F 試験のクローズドセットを形成する：ファイルまたはシェル操作を中心としたすべてのシナリオはこれら六つのうちの一つにマッピングされる。シナリオが「config.json のコンテンツを読む」を説明している場合、答えは Read だ。「legacy_auth をインポートするすべてのファイルを見つける」を説明している場合、答えは Grep だ。「api/ ディレクトリ以下のすべての .proto ファイルを一覧する」を説明している場合、答えは Glob だ。シナリオの作成者は、境界を知っている受験者と推測する受験者を分けるために意図的に準同義語的な言葉を使用する。

Bash とは別に組み込みツールが存在する理由

Bash は技術的に、ファイルの読み取り・書き込み・編集・検索・グロビングが可能だ。原理的には Bash ツールだけでエージェントを実行し、Read・Write・Edit・Grep・Glob が達成することのほとんどを実現できる。Anthropic が Bash の隣に五つの専門ツールを公開している理由は、専門ツールが生のシェルより安全で、より観察可能で、Claude が推論しやすいからだ。Read ツール呼び出しは「Claude がこのファイルのこれらの行番号をこの時刻に読んだ」という構造化メタデータを記録する。cat file.txt の Bash 呼び出しはシェル文字列のみを記録する。専門ツールは各アクションの爆発半径を縮小する——Read は何も削除できず、Edit は新しいファイルを作成できず、Glob は状態を変更できない——そしてエージェントの軌跡を監査可能にする。CCA-F は「専門ツールが存在する場合は Bash よりも専門ツールを使用する」をベースラインの設計要件として扱う。

Read ツール — 行範囲パラメーターでファイルコンテンツをコンテキストにロードする

Read ツールは指定されたファイルのコンテンツを Claude のコンテキストウィンドウにロードする。Read はデフォルトのファイル取り込みプリミティブだ：エージェントがファイルの内側を見る必要があるとき——ソースコード・設定・ドキュメント・ログ——Read が正しいツールだ。

Read ツールのパラメーター

試験シナリオが利用する主なパラメーター：

• file_path — 絶対パス。相対パスはほとんどの Agent SDK 設定でサポートされていない。
• offset — オプション；読み始める行番号。大きなファイル内のウィンドウを読むために使用する。
• limit — オプション；読む行数。コンテキストウィンドウへの負荷を制限するために offset と組み合わせて使用する。

offset/limit のペアはコンテキストウィンドウの圧力を解決するために存在する：50,000 行のログファイルは一回の呼び出しで読んではならない。関連する 200 行のみを引き出すエージェントはコンテキストウィンドウを溢れさせることを避け、実際のタスクへの注意を保持する。

Read を使う場合

Read は既知のファイルの特定のコンテンツがエージェントに必要なときに正しい。Read にマッピングされる典型的な試験の言い回し：

• 「エージェントが config/database.yml の現在の値を調べる必要がある。」
• 「エージェントは既存の実装を理解するために src/parser.ts の 200〜250 行を見なければならない。」
• 「エージェントはどのスクリプトを実行するか判断する前に package.json をロードする必要がある。」

Read を使わない場合

Read はファイル発見ツールでもコンテンツ検索ツールでもない。シナリオが「エージェントはどのファイルに...が含まれているかを知らない」で始まる場合、答えは Grep（コンテンツ向け）または Glob（名前パターン向け）であり、Read ではない。シナリオの誤答の選択肢は頻繁に、根本的な操作が実際には検索である場合に Read をもっともらしい誤答として提示する。

Write ツール — 新しいファイルの作成または全体上書き、使ってはならない場合

Write ツールは指定されたパスに新しいファイルを作成するか、既存のファイルのコンテンツを完全に置き換える。Write はオールオアナッシングの操作だ：ファイル全体が一回の呼び出しで書かれる；部分書き込みの概念はない。

Write ツールのパラメーター

• file_path — 絶対パス。ファイルが存在する場合、そのコンテンツは完全に上書きされる。存在しない場合、作成される（SDK 設定によっては親ディレクトリも含めて）。
• content — 書き込む完全なテキストコンテンツ。

Write が正しい場合

Write は正確に二つの状況で正しい：

1. まったく新しいファイルの作成 — まだ存在しないファイルが作成されている。例：新しいマイグレーションファイルのスキャフォールディング・新鮮な設定の生成・前身のないまったく新しいテストファイルの作成。
2. 意図的な全体置換 — 既存のファイルが完全に置き換えられており、置換が以前のコンテンツの外科的編集ではない。例：ロックファイルの再生成・ビルド成果物の上書き・プレースホルダーテンプレートを実際のコンテンツで上書き。

Write が誤りの場合

Write は誤りだ——これがタスク 2.5 で最もテストされるポイント——操作が既存のファイルの変更である場合は常に。既存のファイルを変更するとは、新しいコンテンツが古いコンテンツの関数であることを意味する：「この関数の戻り型を変更する」「この構造体に新しいフィールドを追加する」「インポートの legacy_client を new_client に置き換える」。これらの操作は Edit を必要とする。それらに Write を使用することは、安全でなく（完全なコンテンツを送信しなければならず、転写エラーがあるとコードが静かにドロップされる）、試験での不適切なツール選択を示す。

全体上書きがリスキーな理由

既存のファイルを上書きする Write 呼び出しは、Claude が保持したいすべての行を再発しなければならない。Claude が忘れた行・圧縮した行・微妙に言い換えた行は静かに失われる。2,000 行のソースファイルでは、完璧な再現の確率は本番システムで信頼できるほど高くない。Edit は変更されていない行が決して送信されないためより安全だ——それらはファイルシステムにあるまま残る。この非対称性が試験がインプレース変更に Edit を主張する理由だ。

Edit ツール — 外科的なインプレース変更、既存ファイルには Write より推奨

Edit ツールは既存のファイル内での外科的なインプレース置換を実行する。Edit は「before」スニペットと「after」スニペットのみを送信する；ファイル内の他のすべてはファイルシステムによってそのまま残る。

Edit ツールのパラメーター

• file_path — 絶対パス。ファイルはすでに存在しなければならない；Edit はファイルを作成しない。
• old_string — 置換する正確なリテラルスニペット。空白とインデントが一致しなければならない。
• new_string — 置換スニペット。
• replace_all — オプションのブール値；true の場合、すべての出現を置換する。false（デフォルト）の場合、old_string はファイル内でユニークでなければならず、そうでなければ呼び出しが失敗する。

Edit を使う場合

Edit は変更をbefore/afterの文字列スワップとして表現できる既存のファイルのあらゆる変更に対して正しい。典型的な試験の言い回し：

• 「config.yml の timeout の値を 30 から 60 に更新する。」
• 「parser.ts のすべての定義で関数名 processData を normalizeData に変更する。」
• 「ハンドラー内の非推奨の request.Legacy() 呼び出しを request.V2() に置き換える。」

ユニーク性の要件

replace_all が false の場合、old_string はファイル内に正確に一度だけ現れなければならない。スニペットがあいまいな場合（handle() という名前の三つの関数）、Edit 呼び出しが失敗し、エージェントは明確化しなければならない——通常は old_string により多くの周辺コンテキストを含めることで（関数シグネチャと特徴的な最初の行）。このユニーク性要件は安全機能だ：同じトークンを含む無関係な行を意図せず破壊しないようにする。

Edit は関係のないコンテンツを保持する

Edit はデルタのみを送信するため、ファイルの残りは Claude が行を省略・言い換え・再インデントすることで破損することができない。これが Edit が変更に対して Write より安全な構造的理由だ。Edit を「既存のファイルの変更に対する安全な選択」とフレームする試験の答えは、Anthropic の文書化された選択ルールと一致する。

Edit vs Write の判断ルール — ファイルが存在する場合は Edit、まったく新しい場合のみ Write

Edit と Write の選択はタスク 2.5 で最も高頻度の判断だ。CCA-F シナリオはルールを内面化した受験者を報い、「ファイルに書き込んでいるから Write に違いない」とパターンマッチングする受験者をペナルティにするよう特別に構築されている。

一行でのルール

ファイルがすでに存在し、操作がその一部を変更する場合は Edit を使用する。まったく新しいファイルまたは意図的な全体置換の場合にのみ Write を使用する。

判断ツリー

1. ファイルは存在するか？ いいえの場合、Write を使用する。はいの場合、続行する。
2. 意図された変更はファイル全体の意図的な置換か？ はいの場合、Write が許容される。いいえの場合、続行する。
3. 変更はファイルの一部の変更か？ Edit を使用する。

ルールが存在する理由

三つの構造的理由：

• 安全性 — Edit は Claude が再発することを忘れたコンテンツを失うことができない。Write はできる。
• 可観測性 — Edit 呼び出しのdiffは小さく監査可能だ。Write 呼び出しの「diff」はファイル全体であり、ツールが安価にレビューできない。
• コストとレイテンシ — Edit は小さな before/after ペアを送信する。Write は各呼び出しで完全なファイルコンテンツを送信し、大きなファイルのトークンコストを膨らませる。

一般的な誤答の選択肢

試験は変更シナリオに対して Edit の隣に Write を頻繁に提示する。典型的な誤答のフレーミング：

• 「更新されたファイルを書き込む」——誤り；更新には Edit を使用する。
• 「新しいコンテンツでファイルを上書きする」——一部のみが変わっている場合は誤り。
• 「変更を適用した完全なファイルを再発する」——それは Edit を装った Write だ。

変更シナリオの正しい答えは常に Edit だ。

Bash ツール — シェルコマンド実行、リスクサーフェスと安全上の考慮事項

Bash ツールは任意のシェルコマンドをサブプロセスで実行し、stdout・stderr・終了コードを返す。Bash は組み込みセット内で最も強力なツールであり、同じ理由で最も危険だ。CCA-F は Bash を最後の手段のツールとして扱う：専門ツール（Read・Write・Edit・Grep・Glob）が操作を表現できる場合は常に専門ツールが好ましい。

Bash ツールのパラメーター

• command — 実行するシェルコマンド文字列。
• timeout — オプション；呼び出しごとの実経過時間制限。長時間実行するビルドやテストスイートに重要。
• description — コマンドの意図を説明する短い人間が読めるラベル。ログと監査に使用される。

Bash が実際のところ何のためかについて

Bash は、操作が本物のシェルコマンドで専門的な同等物がない場合に正しい選択だ：

• ビルドとテストの実行 — npm test・pytest・cargo build・make lint。
• バージョン管理コマンドの呼び出し — git status・git log・git diff（一部の SDK セットアップはこれらを専用ツールで公開している；リファレンスを確認する）。
• プロセスとサービスの管理 — systemctl・docker compose up・kill。
• Claude Code の同等物がない単発シェルユーティリティ — 内部エンドポイントへの curl・jq 後処理・構造化ログでの awk カラム抽出。
• パッケージマネージャーの操作 — pip install・npm install・apt-get update。

Bash が使ってはならない場合

Bash は同じ操作のための専門ツールが存在する場合には使用すべきでない：

• ファイルの読み取り → cat ではなく Read。
• ファイルの書き込み → echo > file または sed -i ではなく Write または Edit。
• コンテンツの検索 → Bash 経由でシェルアウトした grep ではなく Grep。
• パターンでのファイル一覧 → Bash 経由でシェルアウトした find ではなく Glob。

専門ツールが十分な場所で Bash を使用することは、爆発半径を広げ（Bash は任意のコマンドを実行できる）、可観測性を弱め（意図がシェル文字列に埋もれる）、試験では不適切な設計として扱われる。

リスクサーフェス

Bash コマンドは以下を実行できる：

• ファイルを削除する（rm -rf）。
• 設定を変更する（sed -i・echo >）。
• ネットワークトラフィックを送信する（curl・wget・ssh）。
• 無制限のリソースを消費する（暴走した tail -f または dd）。
• データを流出させる（ローカルファイルを読んで他の場所に送信する任意のコマンド）。

このため、Bash を実行する本番エージェントは、許容可能なコマンドの許可リスト・呼び出しごとのタイムアウト、そして破壊的または無制限の操作には実行前の明示的な人間の承認を組み合わせるべきだ。

Grep ツール — ファイルをまたいだパターン検索、正規表現対リテラル、コンテキスト行

Grep ツールはファイルのコンテンツでパターンを検索する。Grep は一致する行をファイルパスと行番号とともに返す。Grep はコードベース全体で「どのファイルに X が含まれているか」や「このシンボルはどこに現れるか」という問いに対するツールだ。

Grep ツールのパラメーター

典型的なパラメーター（SDK 固有の変形に依存する）：

• pattern — 検索する正規表現またはリテラル文字列。
• path — 検索をスコープするオプションのディレクトリまたはファイル。なければ Grep は作業ディレクトリ全体を検索する。
• output_mode — マッチがどのように返されるか（パス付き行・パスのみ・カウントのみ）を制御する。
• -i / 大文字小文字非感知 — オプションの大文字小文字を区別しないマッチ。
• -n / 行番号 — 各マッチに行番号を含める。
• -A / -B / -C — 各マッチの後・前・周囲のコンテキスト行。周囲の関数またはブロックを見るのに有用。
• glob — パスパターンに一致するファイルに制限する（例：*.ts）。

Grep を使う場合

Grep はその問いが「どの行またはファイルがこのパターンを含むか」の場合に正しい。典型的な試験の言い回し：

• 「コードベース全体で process.env.API_KEY のすべての使用を見つける。」
• 「UserSession インターフェースの定義を探す。」
• 「非推奨の utils/legacy.ts をインポートするすべてのファイルを一覧する。」
• 「エラーメッセージ invalid token が発生している行を見つける。」

正規表現対リテラル

Grep は正規表現パターンをサポートする。アンカリング（^・$）・文字クラス（[A-Z]）・キャプチャグループはすべて動作する。単純なリテラル文字列——例えば正確なファイル名 schema.sql のすべての出現を見つける——には、リテラル検索がより速く、不意の正規表現解釈を避けられる（パターン内のリテラル $ は正規表現として解釈されると行末に一致する）。パターンが正確であることが既知の場合はリテラル形式を使用し、柔軟性が必要な場合は正規表現を使用する。

コンテキスト行は試験で重要

コンテキストフラグ（-A・-B・-C）はしばしば見落とされるが、エージェントがマッチをその周辺ブロックで見るメカニズムだ。マッチする行だけを読むことは、コンテキストなしの判断につながることが多い；-C 3（各側に三行）を読むことが適切なデフォルトであることが多い。エージェントが「マッチを含む関数を理解する」と説明するシナリオ設問は通常コンテキスト行を示唆する。

Glob ツール — パターンでのファイル発見、Bash の find より優先する場合

Glob ツールはパスパターンでファイルを発見する。Glob は一致するファイルパスのリストを返す（通常は変更時刻順、新しい順）。Glob は「すべての .ts ファイルを見つける」や「このディレクトリ以下のすべてのテストファイルを一覧する」のツールだ。

Glob ツールのパラメーター

• pattern — グロブスタイルのパスパターン。標準的なワイルドカード：*（セグメント内の任意の文字）・**（任意の深さのディレクトリ）・?（単一の文字）・文字クラス。例：**/*.ts・src/**/test_*.py・docs/**/*.md。
• path — グロブのオプションのルートディレクトリ。なければ Glob は作業ディレクトリで操作する。

Glob を使う場合

Glob はその問いが「このパターンに一致するパスのどのファイルが存在するか」の場合に正しい。典型的な試験の言い回し：

• 「api/ ディレクトリ以下のすべての .proto ファイルを一覧する。」
• 「プロジェクト内の test_*.py に一致するすべてのテストファイルを見つける。」
• 「docs/ 以下のすべての markdown ドキュメントを発見する。」
• 「リポジトリ内のすべての YAML 設定ファイルを列挙する。」

Glob vs Bash find

Bash の find ユーティリティは Glob が達成するすべてを達成できる。CCA-F が find より Glob を優先する理由は、専門ツールの一般的なルールと同一だ：Glob はより狭く、より安全で、より観察可能で、任意のシェル実行に爆発半径を広げない。find 呼び出しは rm・mv・または他の破壊的なコマンドにパイプできる；Glob 呼び出しはできない。試験では「Bash find を使ってファイルを一覧する」は Glob が正しいツールの場合に意図的に置かれた誤答だ。

Glob vs Grep — コンテンツ/パスの境界

最もテストされる Grep/Glob の区別：

• Grep はファイルのコンテンツ内のパターンを検索する。
• Glob はファイルのパスのパターンを検索する。

「UserSession を言及しているすべてのファイルを見つける」とフレーミングされた問いは Grep だ（コンテンツ）。「user_session.ts と命名されているすべてのファイルを見つける」とフレーミングされた問いは Glob だ（パス）。試験の誤答の選択肢は、受験者が境界を内面化しているかをテストするためにこれら二つを日常的に入れ替える。

ツール組み合わせパターン — コードベースリファクタリングの Glob → Read → Edit パイプライン

組み込みツールは合成されるよう設計されている。CCA-F 試験で最も重要な合成は Glob → Read → Edit パイプラインであり、これは自律コードベースリファクタリングの標準的な形状だ。

標準的なリファクタリングパイプライン

1. Glob — 影響を受ける可能性のあるファイルを列挙する。例：リポジトリ以下のすべての TypeScript ファイルを一覧する **/*.ts。
2. Grep（オプション）— リファクタリングされるシンボルに言及するファイルにリストを絞り込む。これにより無関係なファイルの読み取りを避けてコンテキストを管理可能に保つ。
3. Read — 各候補ファイルのコンテンツをロードする（通常はマッチの周辺の行範囲で）ことで Claude が周辺のコードについて推論できるようにする。
4. Edit — 影響を受ける各領域に外科的な変更を適用する。

パイプラインがモノリシック Bash を凌駕する理由

素朴な代替は単一の Bash 呼び出しだ：find . -name '*.ts' -exec sed -i 's/oldName/newName/g' {} +。これは実経過時間では速いが：

• Claude に候補の出現を検査する機会を与えない。
• 有効な名前変更ターゲットを偽陽性（コメントや文字列リテラルなど）から区別できない。
• 専門ツール呼び出しが作成する監査証跡をバイパスする。

パイプラインバージョンはより時間がかかるが、安全で観察可能であり、はるかに正確だ——本番エージェントが実際に必要とするものと、CCA-F が報いるものに一致する。

パイプライン内の並列 Read

現代の Claude モデルは、ツール呼び出しが独立していると検出すると積極的に並列化する。リファクタリングが五つの候補ファイルを読む必要がある場合、Claude は単一のアシスタントメッセージで五つの Read tool_use ブロックを頻繁に発する。対応する user メッセージは五つの一致する tool_result ブロックを含まなければならない。これらの読み取りを五つの別々のターンにシリアライズする実装はレイテンシを無駄にし、標準パターンに違反する。これはタスク 1.1（agentic loop 設計）に直接つながり、二つのタスクが一緒にテストされることが多い理由を示している。

Grep 先行 vs Glob 先行

対象セットが大きい場合（単一リポジトリのすべての .ts ファイル：何千もある）、Glob より Grep から始める方が良いことが多い——Grep の出力はすでに実際にシンボルを含むファイルに絞り込まれており、Grep はマッチする行番号を含むことができるので、後続の Read 呼び出しが offset/limit を使用して関連するウィンドウのみをロードできる。対象セットが小さい場合（設定ファイルの単一ディレクトリ）、Glob 先行の方がシンプルだ。試験はオーダーを作業セットのサイズに合わせることを報いる。

パフォーマンスの考慮事項 — バルク操作には Bash、検索には Grep、ターゲットロードには Read

組み込みツールは異なるパフォーマンス特性を持ち、操作のスケールに対して誤ったツールを選ぶことはよくある試験のトラップだ。

Read — ターゲット、小規模なロード

Read は単一ファイルの限られた領域のロードのために設計されている。ファイルの 200 行スライスのロードは安価だ；50,000 行のファイルを一回の Read 呼び出しでロードすることは高価でコンテキストを汚染する。ファイルが大きい場合は常に offset と limit で Read をスコープする。リポジトリのすべてのファイルを一つずつスキャンするには Read は誤ったツールだ——パターンは Glob（または Grep）先行で、その後狭いセットの Read だ。

Grep — バルクコンテンツ検索

Grep は多くのファイルをまたいでコンテンツをスキャンするために最適化されている。リポジトリをまたいだ Grep 呼び出しは、各ファイルを Read で読んでインコンテキストで検索するよりはるかに効率的だ。操作が「X を含むファイルを見つける」の場合、Grep は正しい意味論的選択だけでなく正しいパフォーマンス選択でもある。

Glob — バルクパス発見

Glob は一致するファイルパスのリストを素早く返すために最適化されている。10,000 ファイルのリポジトリ内のすべての .ts ファイルを Glob に求めるのは些細なことだ；ディレクトリをイテレートしてファイルを一覧するために Read に求めるのは不可能だ（Read はディレクトリツールではない）。

Bash — 専門ツールのないバルク操作

Bash は同等の専門ツールのないバルク操作に対して正しいツールだ——テストスイート全体の実行・200 の依存関係のインストール・コードジェネレーターの呼び出し。バルク操作が「コンテンツを検索する」または「パターンでファイルを一覧する」の場合、Grep または Glob が正しく Bash は誤りだ。

スケールが答えを反転させる場合

作業セットのサイズが正しいツールを反転させる二つの例：

• 一つのファイルを読む → Read。千のファイルを読む → 通常は絞り込むために Grep 先行、その後選択的に Read。
• 一行を編集する → Edit。何百もの Files にまたがる同じ行を編集する → 緊密な Glob → Read → Edit パイプライン、または制限された場合には人間レビュー付きの単一の Bash コマンド。Edit 中心のパイプラインが CCA-F のデフォルト答えだ。監査可能性を保持するからだ。

安全性と破壊的操作 — Write/Bash 実行前の意図の確認

六つの組み込みツールのうち三つが状態を変更または破壊できる：Write・Edit・Bash。本番エージェントはそれらの実行を読み取り専用ツールより注意深く扱わなければならない。CCA-F シナリオはその注意をエージェントのループに設計しているかをテストする。

三つの変更ツールとその爆発半径

• Write — 全体ファイルの上書き。バージョン管理がキャッチしない限りファイルシステムレイヤーでは回復不可能。
• Edit — インプレース変更。狭い爆発半径（一つの before/after スワップ）だがバージョン管理外では依然として回復不可能。
• Bash — 任意のコマンド。爆発半径はシェルが到達できるすべてのもの——ファイルシステム・ネットワーク・生成されたプロセス。

権限と許可リスト

Claude Code は設定が与えられたコンテキストでどのツールが許可されているかを宣言でき、Bash には許可されるコマンドパターンを宣言できる。CI パイプラインで実行するエージェントは Read/Grep/Glob を自由に許可し、Write/Edit には明示的な承認を必要とし、Bash を npm test・npm run build・git status などの許可リストに制限することがある。このパターン——段階的な権限モデル——は自律エージェントの Anthropic 推奨のデフォルトだ。

破壊的アクションのためのヒューマンインザループ

自動ロールバックが処理できる爆発半径を超える操作——本番データベースへの書き込み・破壊的なシェルコマンド・ライブインフラへのデプロイ——については、エージェントは実行前に人間の承認を一時停止して求めるべきだ。これはプランモード（タスク 3.4）と人間レビューワークフロー（タスク 5.5）に関連するが、機械的な一時停止は Write/Edit/Bash 呼び出しが発火しようとするときに呼び出されるため、組み込みツールの関心事でもある。

ドライランとプランモード

プランモード（タスク 3.4）はエージェントが実際にそれらを実行せずに何をするかを提案できるようにする——どの Write 呼び出し・どの Edit 呼び出し・どの Bash 呼び出し。ユーザーが計画を承認し、そのときのみ実行が始まる。プランモードは自動的により安全な選択ではない（レイテンシを追加し非インタラクティブパイプラインを壊す）が、破壊的なマルチファイルリファクタリングには正しいデフォルトだ。

CI/CD 非インタラクティブモードでの組み込みツール

claude-code-for-continuous-integration シナリオは、人間が見ていない自動化パイプライン内で組み込みツールを扱う。組み込みツールの選択ルールは変わらないが、安全姿勢は変わる。

-p フラグを使った非インタラクティブ実行

Claude Code が CI 内で実行される場合（GitHub Actions・GitLab CI・Buildkite）、非インタラクティブモード（通常 -p フラグ付き）で呼び出される。エージェントは人間の承認のために一時停止することができない。したがって、許可リストモデルが主要な安全メカニズムになる：エージェントが実行を許可されるすべての Bash コマンドパターンは事前に宣言されなければならない；許可リスト外のコマンドは実行を中止する。

読み取り専用検査ジョブ

多くの CI ジョブは読み取り専用だ：リントチェック・セキュリティスキャン・依存関係監査。これらには Read/Grep/Glob のみを許可し Write/Edit/Bash を拒否するエージェント設定が適切だ。狭い権限セット自体が安全機能だ：エージェントが誤動作しても、コードベースを変更することができない。

コード生成 CI ジョブ

コード成果物を再生成するジョブ（.proto ファイルからコードを生成する・生成された SDK を更新する）は正当に Write と時に Edit が必要だ。Bash はコードジェネレーター自体を呼び出すために一般的に必要だ。各変更ツールのスコープを絞るべきだ（Write は generated/ ディレクトリ以下のみ許可、Bash は特定のコードジェネレーターコマンドのみ許可）。

デプロイジョブ

本番にデプロイするジョブは Bash を自由に実行すべきでほぼない。典型的なパターンは正確なデプロイコマンドの許可リスト（例：kubectl apply -f deploy.yaml）であり、それ以外はない。非インタラクティブ CI ではプランモードは利用できず、許可リストが主要なコントロールだ。

可観測性 — 組み込みツール呼び出しのログ記録

すべての組み込みツール呼び出しは本番エージェントがログに記録すべき構造化イベントだ。最小のログサーフェス：

• ツール名 — Read・Write・Edit・Bash・Grep・Glob。
• 入力引数 — file_path・pattern・command など。Bash には完全なコマンド文字列をログに記録；Edit には old_string / new_string ペア（またはプライバシー上の理由から少なくともその長さ）をログに記録。
• タイムスタンプと所要時間 — 呼び出しが発火した時とどのくらいかかったか。
• is_error — ツールが失敗を報告したかどうか。
• 結果のプレビュー — 監査のための戻り値の切り捨てたスナップショット。

Agent SDK の PreToolUse と PostToolUse の hooks（タスク 1.5）は、このログ記録を接続するクリーンな場所だ。Claude Code では設定レベルのログ記録が同じ仕事を扱う。可観測性は組み込みツールの概念そのものではないが、組み込みツールの選択に関するどの CCA-F の答えも、選択したツールの呼び出しが監査可能でなければならないことを認めなければ不完全だ。

やさしい解説: — 組み込みツール選択の三つの類比

六つのツールが同じように責任を分離している物理的なシステムに固定すると、組み込みツールの選択は直感的になる。三つの類比が全サーフェスを解説する。

類比 1: 職人の作業場 — ツールごとに一つの仕事

丁寧に整理された木工職人の作業場を想像してほしい。ペグボードには六つの特定のツールがある：虫眼鏡（Read）・ペン（Write）・消しゴムと鉛筆（Edit）・電動ドリル（Bash）・索引カード（Grep）・書類棚のファインダー（Glob）。注意深い職人はラベルを書くためにドリルを使わず、消しゴムを使ってゼロから新しい引き出しを作らず、虫眼鏡を使って書類棚を検索しない。「設計図を保管した場所は？」と顧客が聞いたとき、職人はドリルではなく書類棚のファインダーに手を伸ばす。「設計図 17 の三ページ目には何が書いてある？」と顧客が聞いたとき、職人はインデックスではなく虫眼鏡に手を伸ばす。電動ドリルは技術的には十分なアタッチメントがあれば何でもできる——しかし有能な職人は専門ツールでは対処できない場合にのみ手を伸ばす。それがまさに CCA-F の選択ルールだ：まず専門ツールに手を伸ばし；他の何もループ形状を表現できない場合にのみ Bash に手を伸ばす。

類比 2: 図書館のカタログ — パス対コンテンツは根本的な分離

研究図書館を歩いてみよう。二つの異なる検索システムがある。一つのカタログはタイトルと請求番号で本をインデックスする——これが Glob だ。もう一つのカタログはテキスト内のキーワードで本をインデックスする——これが Grep だ。「『アルゴリズムへの入門』という本はありますか？」と司書に聞くと、タイトルカタログ（Glob）に案内される。「Dijkstra のアルゴリズムについて論じている本はどれですか？」と聞くと、コンテンツカタログ（Grep）に案内される。これらは互換性がない。タイトル検索は本の内容を教えられない；コンテンツ検索は存在するすべての本を列挙できない。初心者の研究者は二つを混同し、タイトルカタログで「Dijkstra のアルゴリズム」の検索結果がゼロになって途方に暮れる——その正確なフレーズをタイトルに持つ本はないが、それを含む本は何十もあるにもかかわらず。Grep と Glob を入れ替える CCA-F 受験者はまったく同じミスを犯す。Grep は中身を読み；Glob は背表紙を読む。

類比 3: 厨房 — Edit vs Write は既にあるものを保持することについて

完成したソースの味付けを調整しているシェフには二つの選択肢がある。選択肢 A：ソースを味見し、塩が必要だと判断し、ひとつまみ加える（これが Edit だ——小さく、外科的で、他のすべてを保持する）。選択肢 B：鍋全体を捨て、ゼロから新しいソースを作る（これが Write だ——意図的な全体置換）。選択肢 B が正しい場合もある——ソースが実際に壊れていて修復できない場合は最初からやり直す。しかし調味料の調整に選択肢 B はリスキーだ：記憶からレシピ全体を再現しており、小さなミス（スパイスを忘れる・液体を誤計量する）が静かに料理を台無しにする。同じロジックがファイル変更に適用される。一つの関数を変更している場合、ファイル全体を書き直さない；Edit する。以前は存在しなかったまったく新しい設定ファイルを生成している場合、Write する。CCA-F シナリオはまさにこの直感をテストする：既にあるものを保持することが再発するより安全だと受験者は知っているか？

どの類比がどの試験問題に適合するか

• どの組み込みツールを選ぶかに関する設問 → 職人の作業場の類比。
• Grep vs Glob に関する設問 → 図書館カタログの類比。
• Edit vs Write に関する設問 → 厨房の調味料の類比。

一般的な試験トラップ

CCA-F タスク 2.5 は組み込みツール選択に関して六つのトラップパターンを一貫して利用する。すべての六つはコミュニティの合格報告に記録されており、もっともらしい誤答の選択肢として偽装されて登場する。

トラップ 1: 既存のファイルを変更するために Write を使用する

最も高頻度のトラップ。シナリオは既存のファイルへの更新・名前変更・置換・挿入を説明し、四つの選択肢のうちの一つが「新しいコンテンツでファイルを Write する」だ。Write は既存のファイルのあらゆる変更に対して誤りだ。Edit が答えだ。

トラップ 2: 専門ツールが存在するときに Bash を使用する

シナリオは「Bash を使って cat ファイルする」「Bash find を使ってファイルを一覧する」「Bash grep を使ってコンテンツを検索する」をもっともらしく見える選択肢として提示する。操作に対して Read・Glob・Grep が存在する場合、Bash は誤りだ——失敗するからではなく、爆発半径を任意のシェルに不必要に広げるからだ。専門ツールは常に優先される。

トラップ 3: Grep と Glob の入れ替え

Grep はコンテンツを検索する。Glob はパスを検索する。シナリオは意図的にコンテンツ形状の問い（「legacy_auth をインポートするすべてのファイルを見つける」）を説明して Glob を誤答として提示するか、パス形状の問い（「すべての .proto ファイルを一覧する」）を説明して Grep を誤答として提示する。動詞（言及する・含む・インポートする → Grep）またはパターンの形状（*.ts・**/*.py → Glob）に対して設問を一度読んで適切に選ぶこと。

トラップ 4: Edit をファイル作成ツールとして扱う

Edit はファイルがすでに存在することを必要とする。シナリオは時に Edit をまったく新しいファイル（新しいテストをスキャフォールド・新しい設定を生成）に提示する。新しいファイルでは old_string に一致するものがないため、Edit は置換ロジックが実行される前に失敗する。まったく新しいファイルを作成するための正しいツールは Write だ。

トラップ 5: クロスファイルリファクタリングにモノリシック Bash コマンドを選ぶ

クロスファイルリファクタリングに対して、試験は sed -i を使った単一の Bash 呼び出しではなく Glob → Read → Edit パイプラインを報いる。Bash のワンライナーがより短くても、観察可能性が低く、安全でなく、正確でない。「リファクタリング全体を行う一つの Bash 呼び出し」とフレーミングされたシナリオの答えはほぼ常に専門パイプラインを優先して誤りだ。

トラップ 6: 大きなファイルへの Read で offset と limit を省略する

offset / limit なしに 50,000 行のログファイルを読むことはコンテキストウィンドウを溢れさせ、通常は下流のタスクを失敗させる。大きなファイルへの正しい Read 呼び出しには offset/limit が含まれる（または興味のある行番号を特定するために Grep が先行する）。Read が正しいツールカテゴリである場合でも、大きなファイルへの無制限の Read を実行する答えは不適切な設計として扱われる。

練習アンカー

組み込みツール選択設問は CCA-F の六つのシナリオのうちの二つに集中する。以下をアーキテクチャの背骨として扱うこと。

Developer-Productivity-With-Claude シナリオ

このシナリオ全体の前提は、開発者が Claude 駆動エージェントを使用して大規模なコードベースにわたって作業することだ——バグ調査・マルチファイルリファクタリング・テスト作成・ドキュメント更新。組み込みツールはエージェントとコードベースの間の主要なインターフェースであり、ほぼすべての設問がそれらのうちの一つを扱う。以下をテストする設問を期待すること：

• Glob → Read → Edit リファクタリングパイプライン。
• Grep vs Glob 選択（シンボルの使用を見つける vs パスパターンでファイルを一覧する）。
• Edit vs Write 選択（既存の関数を変更する vs 新しいテストファイルを作成する）。
• ファイル読み取りや検索ではなくビルド/テスト呼び出しのために予約された Bash。
• 大きなファイルには offset/limit を使った Read vs 無制限の読み取り。

Claude-Code-For-Continuous-Integration シナリオ

このシナリオは組み込みツールを自動化された非インタラクティブコンテキストに押し込む。選択ルールは同じだが、安全姿勢は許可リストと狭い権限スコープにシフトする。以下をテストする設問を期待すること：

• CI でのツール権限スコーピング（エージェントが使用を許可されているツール）。
• Bash 許可リスト設計（許可された正確なコマンドパターン）。
• Write/Edit を許可する場合（コードジェネレーターのみ）vs 拒否する場合（リントのみのジョブ）。
• CI 呼び出し用の -p 非インタラクティブフラグと組み込みツール設定の組み合わせ。
• 許可リスト外の破壊的な Bash 呼び出しの検出と拒否。

シナリオの作成者は二つのシナリオをクロスリファレンスすることがある：CI によってトリガーされるリファクタリングは依然として同じツールを使用するが、開発者のインタラクティブセッションより狭い権限セットで行われる。

FAQ — 組み込みツール上位 6 問

ファイル変更に Edit と Write をどう決めるか

ファイルがすでに存在し、操作がファイルの一部の変更である場合は常に Edit を使用する。まったく新しいファイルまたは意図的な全体ファイル置換の場合にのみ Write を使用する。Edit はより安全だ。before/after スニペットのみを送信し、ファイルの残りをファイルシステムレイヤーで保持する——Claude は変更していない行を再発する必要がない。既存のファイルへの Write は Claude がすべての行を再現することを強制し、転写で省かれたまたは言い換えられた行は静かに失われる。CCA-F は変更に Edit を正しい答えとして、変更に Write を意図的に置かれた誤答として扱う。

試験での Grep と Glob の違いは何か

Grep はファイルのコンテンツでパターンを検索する；Glob はファイルのパスでパターンを検索する。境界は Grep/Glob ペアで最もテストされる区別だ。典型的な Grep の問いは「X を言及しているまたはインポートしているまたは含んでいるすべてのファイルを見つける」のように聞こえる——動詞はファイルの内側を指す。典型的な Glob の問いは「*.ts と命名されているすべてのファイルを一覧する」または「src/ 以下のすべてのファイルを見つける」のように聞こえる——動詞はパスを指す。パス形状の問いに Grep を使用するか、コンテンツ形状の問いに Glob を使用する答えは、パターンがどのように書かれているかに関わらず誤りだ。

Bash をいつ専門ツールの代わりに使うか

操作が同等の専門ツールのない本物のシェルコマンドである場合——ビルドの実行・テストスイートの実行・パッケージマネージャーの起動・jq のような単発ユーティリティの駆動——Bash を使用する。専門ツールがすでに操作をカバーしている場合は Bash を使用しない。cat file.txt は Read；echo > file.txt は Write；sed -i は Edit；grep は Grep；find は Glob。専門ツールよりも Bash を選ぶことは爆発半径を任意のシェルに広げ、可観測性を弱め（意図がシェル文字列に埋もれる）、試験での不適切なツール選択として扱われる。

正しい old_string と new_string を渡せば Edit は新しいファイルを作成できるか

できない。Edit はファイルがすでに存在することを必要とする。存在しないファイルには一致する old_string がなく、呼び出しは置換ロジックが実行される前に失敗する。まったく新しいファイルを作成するための正しいツールは Write だ。CCA-F シナリオは時に Edit を新鮮なスキャフォールドへの誤答として提示する——境界（Edit は変更、Write は作成）は意図的な試験のゲートだ。

ファイルをまたいで検索する際に Read が Grep より遅いまたは高価な理由は何か

Read は特定のファイルの指定された範囲全体をコンテキストにロードする。多くのファイルをまたいで「検索する」ために Read を使用することは、各ファイルを全体として、トークンごとに読み、Claude がコンテンツについて推論することを意味する。これはレイテンシとコンテキスト圧力の両方で高価だ。Grep は高速なファイルシステムレベルのスキャンを実行し、一致する行のみを返し、エージェントが検索が完了した後に特定のマッチウィンドウに対して offset/limit を使った狭い後続 Read 呼び出しを行えるようにする。「どのファイルが X を含むか」という問いには Grep が正しいツールだ；Read は検索が完了した後の既知のファイルの既知の領域のロードのためのものだ。

本番エージェントで Write・Edit・Bash の呼び出しにどのような安全対策を付けるべきか

三つの層。まず、エージェントが現在のコンテキストで使用できるツールを宣言する権限許可リスト——例えばリントのみの CI ジョブは Read/Grep/Glob のみを許可する。次に Bash には、任意のシェルが実行できないよう正確なコマンドパターンの許可リスト（例：npm test・npm run build）。第三に破壊的または高リスクな操作については実行前の人間承認ゲート——インタラクティブセッションではプランモード経由で、SDK 駆動エージェントでは明示的な承認リクエスト経由で呼び出される。Claude の自己ガバナンスのみに依存する答えよりも、これらの安全コントロールとツール機能を組み合わせた CCA-F の答えが好ましい。

組み込みツールは agentic loop の stop_reason とどのように相互作用するか

すべての組み込みツール呼び出しは、stop_reason: "tool_use" で Claude が発する tool_use ブロック内にある。Agentic loop はツールを実行し（Read がファイルをロード・Bash がコマンドを実行など）、出力を一致する tool_use_id を持つ tool_result ブロックにラップし、その結果を user メッセージとして追加する。Claude が stop_reason: "end_turn" を発するかガードがトリップするまでループは続く。これは組み込みツールの選択がタスク 1.1 と機械的に結合していることを意味する：誤ったツールを選んだエージェント（Edit が必要なところで Write を選ぶ）は依然として同じループ構造に従うが、意味論的な結果が誤りだ。試験は同じシナリオで両方の軸——正しいループ形状と正しいツールの選択——をテストする。

参考資料

• ツールリファレンス — Anthropic 提供の組み込みツール: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/tool-reference
• Claude Code 機能概要: https://docs.anthropic.com/en/docs/claude-code/overview
• Agent SDK 概要: https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-overview
• Claude のツール使用 — 概要と agentic loop: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
• Writing tools for agents — Anthropic Engineering Blog: https://www.anthropic.com/engineering/writing-tools-for-agents

関連 ExamLab 章節: ツールインターフェース設計 — 説明と境界, Claude Code との MCP サーバー統合, CLAUDE.md ファイル — 階層・スコープ・モジュール構成, 大規模コードベース探索のコンテキスト管理.