段階的な調査パターン
Grepでエントリポイントを探し、Readでファイルを読み、Grepで利用箇所を探し、Readで利用側を確認します
「段階的な調査パターン」はCoddyKit上の無料Claude Architectレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはClaude Architect学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Claude Architectコースには全4レッスンが含まれています。
このレッスンの一部はまだ翻訳されておらず、英語で表示されています。
Why Investigate Incrementally
When Claude Code lands in an unfamiliar codebase, dumping every file into context is wasteful and unreliable. Large blobs trigger lost-in-the-middle: the model attends to the start and end of context far more than the middle, so facts buried in a giant paste get missed.
The Incremental Investigation Pattern solves this. Instead of loading everything, Claude follows a deliberate chain that widens understanding one verified step at a time, pulling only the files that matter.
The Four-Step Chain
The canonical loop for built-in tools is:
- Grep entry points — search file contents to locate where a feature begins.
- Read files — load the matched files to understand the definition.
- Grep usages — search for everywhere that symbol is referenced.
- Read consumers — open the call sites to see how it is actually used.
Each step narrows the search space using evidence from the previous step. You never guess which files matter — the codebase tells you.
# Conceptual flow with Claude Code built-in tools
# 1) Grep -> find entry points
# 2) Read -> the matched definition files
# 3) Grep -> usages of the symbol
# 4) Read -> the consumer / call-site filesThe Built-in Tools You'll Use
This pattern leans on Claude Code's built-in tools. Know exactly what each does:
- Glob — find files by name pattern, e.g.
**/*.test.tsx. - Grep — search inside file contents.
- Read — load a single file into context.
- Edit — make a precise, unique-match change.
- Bash — run shell commands.
Incremental investigation is built almost entirely from Grep and Read — search to discover, read to confirm.
Step 1 — Grep the Entry Point
Start by searching for the symbol or string that anchors the feature. You are looking for the definition, not every mention yet. A focused query keeps the result set small and relevant.
Searching contents (Grep) beats opening directories blindly: the match points you straight at the file that defines the behavior you care about.
# Find where the checkout handler is defined
# Grep tool query:
# pattern: "def process_checkout"
# glob: "**/*.py"
# -> returns: billing/checkout.py:42Step 2 — Read the Definition
Open only the file (or files) the Grep surfaced. Now you read the actual implementation: its inputs, return values, and the other symbols it depends on. Those dependencies become the seeds for your next search.
This is the discipline of the pattern — you Read after you Grep, so every file you load is one the evidence already justified.
# Read tool:
# file_path: billing/checkout.py
#
# You learn: process_checkout() calls
# - validate_cart()
# - charge_card()
# These become your next Grep targets.Step 3 — Grep the Usages
Now flip direction. You understand the definition; next find who calls it. Grep for the symbol name across the codebase to enumerate every consumer.
This answers the questions that matter for a safe change: How many call sites exist? Do they pass the arguments correctly? Will an edit here ripple outward?
# Grep tool query:
# pattern: "process_checkout\("
# glob: "**/*.py"
# -> api/routes.py:88
# -> tasks/retry_jobs.py:19
# -> tests/test_checkout.py:55Step 4 — Read the Consumers
Open the call sites the usage-Grep returned. Reading consumers reveals real-world behavior the definition alone can't show: edge cases, error handling, and assumptions each caller makes.
With definition and consumers understood, you now have a complete, evidence-backed picture — without ever loading the whole repository.
# Read tool on each consumer:
# api/routes.py -> HTTP entry, validates auth first
# tasks/retry_jobs.py -> retries failed charges
# tests/test_checkout -> documents expected contract
# Now an Edit is safe and well-scoped.Trim Tool Output as You Go
Grep and Read can return verbose output. Don't let it pile up — trim verbose tool output to the relevant fields before it crowds your context window.
Keeping context lean directly fights lost-in-the-middle: a smaller, sharper context means the facts you gathered stay near the model's attention rather than buried in noise. Each step should add signal, not bulk.
Glob vs Grep — Pick the Right Door
Two discovery tools, two jobs:
- Glob when you know the file shape — "all test files", "every migration" — e.g.
**/*.test.tsx. - Grep when you know a symbol or string inside the code and need to find where it lives or who uses it.
Incremental investigation usually opens with Grep (you're chasing a symbol), and reaches for Glob when you want to scope by file type.
# Glob: enumerate by pattern
# pattern: "src/**/*.controller.ts"
# Grep: enumerate by content
# pattern: "checkout", glob: "src/**/*.ts"Adaptive, Not a Fixed Pipeline
Use a fixed pipeline / prompt chain when the steps are known and sequential. But investigation is open-ended, so this pattern is best run with adaptive decomposition — the model chooses the next Grep or Read based on what the last step revealed.
Drive it through the agentic loop: each tool result returns stop_reason: "tool_use", you append the result to history, and the model decides the next move. Terminate on end_turn — never by scanning text for words like "done".
while True:
resp = client.messages.create(
model="claude-opus-4-1",
max_tokens=2048,
messages=history,
tools=[grep_tool, read_tool, glob_tool],
)
if resp.stop_reason == "end_turn":
break # model decided investigation is complete
# stop_reason == "tool_use": run tool, append result, loop
history.append(run_tools(resp))Scope the Investigation Agent
If you delegate investigation to a subagent, give it a tightly scoped toolset. 4-5 tools per agent is optimal; 18+ degrades selection reliability. An investigator needs little more than Glob, Grep, and Read.
Apply least privilege: a read-only explorer should NOT hold Edit, Write, or Bash. And remember subagents do not inherit the coordinator's history — pass the target symbol, the goal, and any prior findings explicitly in the prompt.
explorer = AgentDefinition(
name="code-explorer",
description="Read-only incremental investigation of a symbol",
system_prompt="Grep entry points -> Read -> Grep usages -> Read consumers. Report findings only.",
allowed_tools=["Glob", "Grep", "Read"], # least privilege, no Edit/Write
)Quick Check
Test your grasp of the pattern's core decision.
Recap — The Investigation Discipline
Key takeaways:
- Grep entry points → Read files → Grep usages → Read consumers. Evidence guides every step.
- Avoid loading whole repos — large context causes lost-in-the-middle; trim tool output to relevant fields.
- Grep finds symbols in content; Glob finds files by pattern.
- Run it as adaptive investigation through the agentic loop; terminate on
end_turn, never on text like "done" or a hard iteration cap. - A delegated explorer stays read-only (Glob, Grep, Read), keeps to 4-5 tools, and gets all context passed explicitly.
Investigate like an architect: search to discover, read to confirm, edit with confidence.
AI チューターと学ぶ Python — 無料
ブラウザでリアルコードを書いて実行し、24/7 の AI チューターから瞬時にサポートを受け、ウェブまたはアプリで続きから学習できます。
- コース
- 26
- レッスン
- 104
よくある質問
「段階的な調査パターン」レッスンは無料ですか？
はい。「段階的な調査パターン」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Claude Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Claude Architectコースには全4レッスンが含まれています。
「段階的な調査パターン」で何を学びますか？
Grepでエントリポイントを探し、Readでファイルを読み、Grepで利用箇所を探し、Readで利用側を確認します ブラウザで直接実行するハンズオンコードでClaude Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
Claude Architectを始めるのに経験は必要ですか？
事前経験は必要ありません。CoddyKitのClaude Architectは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。
「段階的な調査パターン」レッスンにはどのくらい時間がかかりますか？
ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このClaude Architectレッスンでコードを書いて実行できますか？
はい。すべてのClaude Architectレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。