Claude Code のベストプラクティス

環境設定から並列セッションでのスケーリングまで、Claude Code を最大限に活用するためのヒントとパターン。

Claude Code はエージェント型のコーディング環境です。質問に答えて待つだけのチャットボットとは異なり、Claude Code はファイルを読み、コマンドを実行し、変更を加え、あなたが見守ったり、方向修正したり、完全に席を外している間でも自律的に問題を解決します。

これは、あなたの働き方そのものを変えます。自分でコードを書いてから Claude にレビューを依頼するのではなく、「何をしたいか」を説明すると、Claude がそれをどう実装するかを考えます。Claude は調査し、計画し、実装します。

ただし、この自律性には学習コストも伴います。 Claude は、理解しておくべきいくつかの制約の中で動作します。

本ガイドでは、Anthropic 社内チームや、さまざまなコードベース・言語・環境で Claude Code を利用しているエンジニアの間で有効性が実証されたパターンを紹介します。エージェントループの内部動作については、How Claude Code works を参照してください。

ほとんどのベストプラクティスは、ある一つの制約に基づいています。それは Claude のコンテキストウィンドウはすぐに埋まり、埋まるにつれて性能が低下する という点です。

Claude のコンテキストウィンドウには、会話全体、すべてのメッセージ、Claude が読んだすべてのファイル、実行したすべてのコマンド出力が含まれます。しかし、これはすぐにいっぱいになります。 1 回のデバッグセッションやコードベース探索だけで、数万トークンを消費することもあります。

これは重要な点です。LLM の性能は、コンテキストが埋まるにつれて低下します。コンテキストウィンドウがいっぱいになってくると、Claude は以前の指示を「忘れ始めたり」、ミスが増えたりします。 コンテキストウィンドウは、管理すべき最も重要なリソースです。 トークン使用量を削減する詳細な戦略については、Reduce token usage を参照してください。

Claude に自分の作業を検証させる方法を与える

テスト、スクリーンショット、期待される出力を含めて、Claude が自己検証できるようにしてください。これは、最も効果が高いことの一つです。

Claude は、自分で作業を検証できる場合（テスト実行、スクリーンショット比較、出力検証など）、劇的にパフォーマンスが向上します。

明確な成功基準がないと、見た目は正しそうでも実際には動かないものを作ってしまう可能性があります。その場合、あなたが唯一のフィードバックループとなり、すべてのミスにあなたの注意が必要になります。

戦略	Before	After
検証基準を提供する	“メールアドレスを検証する関数を実装して”	“validateEmail 関数を書いてください。テスト例: user@example.com は true、invalid は false、user@.com は false。実装後にテストを実行してください”
UI 変更を視覚的に検証する	“ダッシュボードを良くして”	“[スクリーンショット貼付] このデザインを実装してください。結果のスクリーンショットを撮り、元と比較してください。差分を列挙し、修正してください”
症状ではなく根本原因に対処する	“ビルドが失敗している”	“このエラーでビルドが失敗します: [エラー貼付]。修正してビルドが成功することを確認してください。エラーを抑制せず、根本原因に対処してください”

UI の変更は Claude in Chrome 拡張を使って検証できます。ブラウザを開き、UI をテストし、コードが動くまで反復します。

検証方法は、テストスイート、リンター、出力をチェックする Bash コマンドでも構いません。 検証を堅牢にすることに投資してください。

まず探索し、次に計画し、それからコードを書く

誤った問題を解決してしまうのを防ぐため、調査と計画を実装から分離してください。

Claude にいきなりコードを書かせると、間違った問題を解決するコードが生まれることがあります。 Plan Mode を使い、探索と実行を分離してください。

推奨されるワークフローは、次の 4 フェーズです。

Plan Mode に入ります。Claude はファイルを読み、質問に答えますが、変更は行いません。

claude (Plan Mode)
read /src/auth and understand how we handle sessions and login.
also look at how we manage environment variables for secrets.

詳細な実装計画を作成させます。

claude (Plan Mode)
I want to add Google OAuth. What files need to change?
What's the session flow? Create a plan.

Normal Mode に戻し、計画に基づいて実装させます。

claude (Normal Mode)
implement the OAuth flow from your plan. write tests for the
callback handler, run the test suite and fix any failures.

説明的なメッセージでコミットし、PR を作成させます。

claude (Normal Mode)
commit with a descriptive message and open a PR

Plan Mode は有用ですが、オーバーヘッドもあります。

スコープが明確で小さな修正（タイプミス修正、ログ追加、変数名変更など）の場合は、直接やらせてください。

計画は、アプローチが不明確な場合、複数ファイルを変更する場合、またはコードに不慣れな場合に最も有効です。差分を 1 文で説明できるなら、計画は不要です。

プロンプトに具体的なコンテキストを与える

指示が正確であるほど、修正回数は少なくなります。

Claude は意図を推測できますが、あなたの心は読めません。特定のファイル、制約、参考パターンを明示してください。

戦略	Before	After
タスクのスコープを明確にする	“foo.py のテストを追加して”	“ログアウト状態のエッジケースをカバーする foo.py のテストを書いてください。モックは使わないでください”
情報源を指し示す	“ExecutionFactory の API が変なのはなぜ？”	“ExecutionFactory の git 履歴を調べて、この API がどう生まれたか要約してください”
既存パターンを参照する	“カレンダーウィジェットを追加して”	“ホームページの既存ウィジェット実装を参考にしてください。HotDogWidget.php が良い例です。そのパターンに従い、月選択と年の前後ページングができるカレンダーウィジェットを実装してください。既存ライブラリ以外は使わず、スクラッチで実装してください”
症状を説明する	“ログインバグを直して”	“セッションタイムアウト後にログインが失敗するという報告があります。src/auth/ の認証フロー、特にトークンリフレッシュを確認してください。再現する失敗テストを書き、その後修正してください”

曖昧なプロンプトは、探索フェーズでは有用なこともあります。 "このファイルで改善できる点は？" のような問いは、思いつかなかった観点を引き出すことがあります。

リッチなコンテンツを提供する

@ でファイル参照、スクリーンショットや画像貼付、データの直接パイプを活用してください。

Claude には以下の方法でリッチなデータを渡せます。

@ でファイル参照: 場所を説明せず、直接参照すると Claude が事前に読みます。
画像を直接貼り付ける: コピー＆ペーストやドラッグ＆ドロップ。
URL を渡す: ドキュメントや API リファレンス。/permissions で頻用ドメインを許可。
データをパイプする: cat error.log | claude
Claude に取得させる: Bash コマンド、MCP ツール、ファイル読取を指示。

環境を設定する

いくつかの初期設定で、Claude Code はすべてのセッションで大幅に効果が向上します。拡張機能の全体像は Extend Claude Code を参照してください。

効果的な CLAUDE.md を書く

/init を実行して、プロジェクト構造に基づいた初期 CLAUDE.md を生成し、徐々に改善してください。

CLAUDE.md は、各会話の開始時に Claude が必ず読む特別なファイルです。 Bash コマンド、コードスタイル、ワークフロールールを含めてください。これは コードからは推測できない永続的コンテキスト を与えます。

/init は、ビルドシステムやテストフレームワーク、コードパターンを検出します。

フォーマットに決まりはありませんが、短く人間が読みやすい形にしてください。

# Code style
- CommonJS (require) ではなく ES modules (import/export) を使う
- 可能な場合は import を分割代入する

# Workflow
- 一連の変更後は必ず型チェックする
- パフォーマンスのため、全テストではなく単体テストを優先

CLAUDE.md は毎回ロードされるため、汎用的な内容のみ を書いてください。特定条件でのみ使う知識は skills を使ってください。

各行について自問してください。 「これを消したら Claude はミスをするか？」 そうでなければ削除してください。肥大化した CLAUDE.md は、本当の指示を無視される原因 になります。

CLAUDE.md は毎回ロードされるため、汎用的に当てはまることだけ を含めてください。ドメイン知識や、たまにしか関係しないワークフローについては、代わりに skills を使ってください。Claude は必要なときにオンデマンドで読み込み、毎回の会話を肥大化させません。

簡潔に保ちましょう。各行について、こう自問してください: 「これを削除したら Claude はミスをするか？」 もしそうでないなら削除してください。肥大化した CLAUDE.md は、Claude が実際の指示を無視する原因になります！

✅ 含める	❌ 含めない
Claude が推測できない Bash コマンド	コードを読めば Claude が分かること
デフォルトと異なるコードスタイル規約	Claude が既に知っている標準的な言語慣習
テスト手順や好みのテストランナー	詳細な API ドキュメント（リンクを貼る）
リポジトリ運用（ブランチ命名、PR 規約）	頻繁に変わる情報
プロジェクト固有のアーキテクチャ判断	長い説明やチュートリアル
開発環境特有の癖（必須 env vars など）	ファイルごとのコードベース説明
よくある落とし穴や非自明な挙動	「きれいなコードを書け」など自明なこと

もし Claude が「やるな」と書いてあるのに望まないことを繰り返すなら、ファイルが長すぎてルールが埋もれている可能性が高いです。Claude が CLAUDE.md に書いてある内容を質問してくるなら、表現が曖昧かもしれません。

CLAUDE.md はコードのように扱ってください: 問題が起きたら見直し、定期的に刈り込み、変更後は Claude の挙動が本当に変わるか観察してテストしてください。

強調（例: “IMPORTANT” や “YOU MUST”）を加えることで、指示遵守を改善できます。チームで共同編集できるように、CLAUDE.md は git にコミットしましょう。このファイルは時間とともに価値が複利的に増えていきます。

CLAUDE.md は @path/to/import 構文で追加ファイルをインポートできます:

See @README.md for project overview and @package.json for available npm commands.

# Additional Instructions
- Git workflow: @docs/git-instructions.md
- Personal overrides: @~/.claude/my-project-instructions.md

CLAUDE.md を置ける場所はいくつかあります:

ホームフォルダ (~/.claude/CLAUDE.md): すべての Claude セッションに適用
プロジェクトルート (./CLAUDE.md): git にコミットしてチーム共有。あるいは CLAUDE.local.md にして .gitignore する
親ディレクトリ: モノレポで root/CLAUDE.md と root/foo/CLAUDE.md の両方を自動取り込みしたい場合に有用
子ディレクトリ: Claude は、そのディレクトリ配下のファイルを扱うときに、子の CLAUDE.md をオンデマンドで取り込む

権限（permissions）を設定する

/permissions で安全なコマンドを許可リスト化するか、/sandbox で OS レベルの分離を使ってください。コントロールを保ちつつ割り込みを減らせます。

デフォルトでは、Claude Code はシステムを変更する可能性のある行動（ファイル書き込み、Bash コマンド、MCP ツールなど）について権限確認を求めます。これは安全ですが面倒です。10 回目の承認になる頃には、もう実質レビューせずにクリックしているだけになりがちです。割り込みを減らす方法は 2 つあります:

権限の許可リスト: 安全だと分かっている特定ツール（npm run lint や git commit など）を許可
サンドボックス: ファイルシステムとネットワークアクセスを制限する OS レベル分離を有効化し、定義済み境界内でより自由に作業させる

また、--dangerously-skip-permissions を使うと、lint エラー修正やボイラープレート生成など、閉じたワークフロー向けにすべての権限チェックをバイパスできます。

任意コマンドを実行させると、データ損失、システム破損、プロンプトインジェクション経由のデータ流出などが起こり得ます。--dangerously-skip-permissions は、インターネット無しのサンドボックス内でのみ使用してください。

詳細は configuring permissions と enabling sandboxing を参照してください。

CLI ツールを使う

外部サービスと連携する際は、gh、aws、gcloud、sentry-cli のような CLI ツールを使うよう Claude Code に指示してください。

CLI ツールは、外部サービスとやり取りするうえで最もコンテキスト効率のよい方法です。GitHub を使うなら gh CLI をインストールしてください。Claude は Issue 作成、PR 作成、コメント読み取りに gh を使えます。gh が無くても GitHub API を使えますが、未認証リクエストはレート制限に当たりやすいです。

Claude は、未知の CLI ツールでも学習して使うのが得意です。例えば次のように指示してみてください: Use 'foo-cli-tool --help' to learn about foo tool, then use it to solve A, B, C.

MCP サーバーを接続する

claude mcp add を実行して、Notion、Figma、DB などの外部ツールを接続してください。

MCP servers を使うと、Issue トラッカーから機能実装したり、DB をクエリしたり、監視データを分析したり、Figma デザインを統合したり、ワークフローを自動化したりできます。

フック（hooks）を設定する

例外なく毎回必ず実行してほしい動作には hooks を使ってください。

Hooks は、Claude のワークフロー内の特定ポイントでスクリプトを自動実行します。 CLAUDE.md の指示は「推奨」ですが、hooks は決定的で、必ず実行されます。

Claude に hooks を書かせることもできます。例: “Write a hook that runs eslint after every file edit” や “Write a hook that blocks writes to the migrations folder.” /hooks で対話的に設定するか、.claude/settings.json を直接編集してください。

skills を作る

.claude/skills/ に SKILL.md を作って、プロジェクト固有の知識や再利用可能なワークフローを与えてください。

Skills は、プロジェクト・チーム・ドメインに特化した情報で Claude の知識を拡張します。Claude は関連があると判断すると自動適用し、また /skill-name で直接呼び出すこともできます。

skill を作るには、.claude/skills/ にディレクトリを作成し、その中に SKILL.md を置きます:

---
name: api-conventions
description: REST API design conventions for our services
---
# API Conventions
- Use kebab-case for URL paths
- Use camelCase for JSON properties
- Always include pagination for list endpoints
- Version APIs in the URL path (/v1/, /v2/)

skills は、直接呼び出せる反復可能ワークフローも定義できます:

---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
---
Analyze and fix the GitHub issue: $ARGUMENTS.

1. Use `gh issue view` to get the issue details
2. Understand the problem described in the issue
3. Search the codebase for relevant files
4. Implement the necessary changes to fix the issue
5. Write and run tests to verify the fix
6. Ensure code passes linting and type checking
7. Create a descriptive commit message
8. Push and create a PR

/fix-issue 1234 で呼び出せます。副作用を持つワークフローを手動トリガーしたい場合は disable-model-invocation: true を使ってください。

カスタム subagents を作る

.claude/agents/ で専門アシスタントを定義し、分離タスクを委譲できるようにしてください。

Subagents は、独立したコンテキストと許可ツールセットで動作します。大量ファイルを読む調査や、専門フォーカスが必要なタスクを、メイン会話を汚さずに実行できます。

---
name: security-reviewer
description: Reviews code for security vulnerabilities
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior security engineer. Review code for:
- Injection vulnerabilities (SQL, XSS, command injection)
- Authentication and authorization flaws
- Secrets or credentials in code
- Insecure data handling

Provide specific line references and suggested fixes.

subagent を明示的に使うには: “Use a subagent to review this code for security issues.” のように指示します。

プラグインをインストールする

/plugin を実行してマーケットプレイスを参照してください。プラグインは設定なしで skills、ツール、連携を追加できます。

Plugins は、skills、hooks、subagents、MCP サーバーを、コミュニティや Anthropic 提供のインストール可能ユニットとしてまとめます。

skills / subagents / hooks / MCP の使い分けは Extend Claude Code を参照してください。

効果的にコミュニケーションする

Claude Code とのコミュニケーション方法は、結果の品質に大きく影響します。

コードベース質問をする

シニアエンジニアに聞くような質問を Claude に投げてください。

新しいコードベースにオンボーディングする際、学習と探索に Claude Code を使えます。他のエンジニアに聞くような質問を、そのまま投げて構いません:

ロギングはどう動いている？
新しい API エンドポイントはどう作る？
foo.rs の 134 行目の async move { ... } は何をしている？
CustomerOnboardingFlowImpl はどんなエッジケースを扱う？
なぜこのコードは 333 行目で bar() ではなく foo() を呼んでいる？

こうした使い方はオンボーディングを効率化し、立ち上がり時間を短縮し、他のエンジニアの負担を減らします。特別なプロンプトは不要です。直接聞いてください。

Claude にあなたへインタビューさせる

大きめの機能では、まず Claude にインタビューさせてください。最小限のプロンプトから始め、AskUserQuestion ツールで詳細に聞き出させましょう。

Claude は、技術実装、UI/UX、エッジケース、トレードオフなど、あなたがまだ考えていない点を質問してきます。

I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.

Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered.

Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.

仕様が完成したら、新しいセッションを開始して実行に移ります。新しいセッションは実装に集中したクリーンなコンテキストになり、書かれた spec を参照できます。

セッションを管理する

会話は永続的で、巻き戻し可能です。これを活用しましょう！

早めに・頻繁に軌道修正する

Claude が脱線し始めたら、気づいた時点ですぐに修正してください。

最良の結果は、短いフィードバックループから生まれます。最初から完璧なこともありますが、たいていは早めに修正したほうが速く良い結果になります。

Esc: Esc キーで Claude の行動を途中停止。コンテキストは保持されるので方向転換できる
Esc + Esc または /rewind: Esc を 2 回押すか /rewind で巻き戻しメニューを開き、会話とコード状態を復元
"Undo that": 変更を元に戻させる
/clear: 無関係なタスク間でコンテキストをリセット。無関係な長セッションは性能を下げる

同一問題で 1 セッション中に 2 回以上修正しているなら、コンテキストが失敗アプローチで汚れている可能性があります。/clear して、学んだことを織り込んだより具体的なプロンプトでやり直してください。クリーンなセッション＋良い初期プロンプトは、修正が積み重なった長セッションよりほぼ常に優れます。

コンテキストを積極的に管理する

無関係なタスク間では /clear を実行してコンテキストをリセットしてください。

Claude Code は、コンテキスト上限に近づくと会話履歴を自動圧縮します。重要なコードや決定事項を保持しつつ、スペースを空けます。

長いセッションでは、無関係な会話、ファイル内容、コマンド出力でコンテキストが埋まり、性能低下や注意散漫が起きます。

無関係タスク間で /clear を頻繁に使い、コンテキストウィンドウを完全リセット
自動圧縮が発動すると、重要点（コードパターン、ファイル状態、意思決定など）を要約して保持
より制御したいなら /compact <instructions>（例: /compact Focus on the API changes）
CLAUDE.md で圧縮時の指示をカスタマイズ可能。例: "When compacting, always preserve the full list of modified files and any test commands"

調査には subagents を使う

"use subagents to investigate X" で調査を委譲し、メイン会話を実装用にクリーンに保ってください。

コンテキストが根本制約である以上、subagents は最強クラスの機能です。 Claude がコードベース調査で大量ファイルを読むと、それらがすべてコンテキストを消費します。subagents は別コンテキストで動作し、結果だけ要約して返します:

Use subagents to investigate how our authentication system handles token
refresh, and whether we have any existing OAuth utilities I should reuse.

subagent は関連ファイルを読み、発見を報告しますが、メイン会話は汚しません。

実装後の検証にも使えます:

use a subagent to review this code for edge cases

チェックポイントで巻き戻す

Claude の行動はすべてチェックポイントを作ります。任意のチェックポイントへ、会話・コード・両方を復元できます。

Claude は変更前に自動でチェックポイントを作ります。Escape を 2 回押すか /rewind でメニューを開き、会話だけ、コードだけ、両方を復元できます。

慎重に全手順を計画する代わりに、Claude にリスキーな案を試させ、ダメなら巻き戻して別案を試せます。チェックポイントはセッションをまたいで残るので、ターミナルを閉じて後で巻き戻すこともできます。

チェックポイントは Claude が行った変更 だけを追跡し、外部プロセスの変更は追跡しません。git の代替ではありません。

会話を再開する

claude --continue で前回の続きから再開、--resume で最近のセッションから選択できます。

Claude Code は会話をローカルに保存します。作業が複数セッションにまたがる場合（途中で中断し翌日に再開するなど）、コンテキストを再説明する必要がありません:

claude --continue    # 直近の会話を再開
claude --resume      # 最近のセッションから選択

/rename でセッションに分かりやすい名前（"oauth-migration"、"debugging-memory-leak"）を付ければ後で探しやすくなります。セッションはブランチのように扱ってください。異なるワークストリームを別セッションで分離し、永続コンテキストを持てます。

自動化してスケールする

1 体の Claude でうまく回せるようになったら、並列セッション、ヘッドレスモード、ファンアウトパターンで出力を増幅できます。

ここまでの内容は「1 人の人間、1 体の Claude、1 つの会話」を前提としていました。しかし Claude Code は水平方向にスケールします。本セクションでは、より多くを達成するための手法を紹介します。

ヘッドレスモードを使う

CI、pre-commit hook、スクリプトで claude -p "prompt" を使ってください。JSON のストリーミング出力には --output-format stream-json を追加します。

claude -p "your prompt" で、対話セッションなしに Claude をヘッドレスで実行できます。CI パイプライン、pre-commit hooks、任意の自動ワークフローに統合できます。出力形式（プレーンテキスト、JSON、ストリーミング JSON）により、結果をプログラムで解析可能です。

# 単発クエリ
claude -p "Explain what this project does"

# スクリプト向けの構造化出力
claude -p "List all API endpoints" --output-format json

# リアルタイム処理向けストリーミング
claude -p "Analyze this log file" --output-format stream-json

複数の Claude セッションを走らせる

複数セッションを並列実行して開発を加速したり、実験を分離したり、複雑ワークフローを起動してください。

並列セッションには主に 2 つの方法があります:

Claude Desktop: 複数ローカルセッションを視覚的に管理。各セッションは独立した worktree を持つ
Claude Code on the web: Anthropic の安全なクラウド基盤上で、隔離 VM により実行

並列化以外にも、品質重視ワークフローが可能になります。新鮮なコンテキストは、直前に自分で書いたコードにバイアスされないため、コードレビューに有利です。

例: Writer/Reviewer パターン

セッション A（Writer）	セッション B（Reviewer）
`Implement a rate limiter for our API endpoints`
	`Review the rate limiter implementation in @src/middleware/rateLimiter.ts. Look for edge cases, race conditions, and consistency with our existing middleware patterns.`
`Here's the review feedback: [Session B output]. Address these issues.`

テストでも同様に、片方がテストを書き、もう片方がそれをパスするコードを書く、という分業ができます。

ファイル単位にファンアウトする

タスクをループし、ファイルごとに claude -p を呼び出してください。バッチ操作では --allowedTools で権限範囲を絞ります。

大規模移行や解析では、多数の並列 Claude 呼び出しに分散できます:

Claude に、移行対象ファイル一覧を列挙させます（例: list all 2,000 Python files that need migrating）

bash for file in $(cat files.txt); do claude -p "Migrate $file from React to Vue. Return OK or FAIL." \ --allowedTools "Edit,Bash(git commit:*)" done

最初の 2〜3 ファイルで何がうまくいかないかを踏まえてプロンプトを改善し、その後全体に適用します。--allowedTools は無人実行時に重要です。

既存のデータ処理パイプラインにも統合できます:

claude -p "<your prompt>" --output-format json | your_command

開発中は --verbose を使ってデバッグし、本番ではオフにしてください。

安全な自律モード（Safe Autonomous Mode）

claude --dangerously-skip-permissions を使うと、すべての権限チェックを回避して割り込みなく作業させられます。lint エラー修正やボイラープレート生成などに向きます。

任意コマンド実行は危険で、データ損失、システム破損、プロンプトインジェクション攻撃によるデータ流出などが起こり得ます。リスクを最小化するため、--dangerously-skip-permissions はインターネット無しのコンテナ内で使用してください。

/sandbox でサンドボックスを有効にすると、より良いセキュリティで同等の自律性を得られます。サンドボックスは、すべてのチェックを飛ばすのではなく、事前に境界を定義します。

よくある失敗パターンを避ける

これはよくあるミスです。早期に気づければ時間を節約できます:

キッチンシンク・セッション: 1 つのタスクを始め、途中で無関係なことを聞き、また元タスクに戻る。コンテキストが無関係情報で埋まる。

対策: 無関係タスクの間に /clear。
延々と修正する: Claude が間違え、修正し、また間違え、また修正… 失敗アプローチがコンテキストを汚染する。

対策: 2 回失敗したら /clear して、学びを取り込んだより良い初期プロンプトでやり直す。
過剰に詳細な CLAUDE.md: 長すぎる CLAUDE.md はノイズになり重要ルールが埋もれる。

対策: 容赦なく刈り込む。指示なしでも正しくできるなら削除するか hook に変換する。
信じて検証しないギャップ: それっぽい実装だがエッジケースを扱えていない。

対策: 常に検証（テスト、スクリプト、スクリーンショット）を与える。検証できないなら出荷しない。
無限探索: 範囲を決めずに「調べて」と言うと何百ファイルも読みコンテキストが埋まる。

対策: 調査範囲を狭くするか、subagents を使い探索がメインコンテキストを消費しないようにする。

直感を育てる

このガイドのパターンは固定ルールではありません。一般にうまくいく出発点ですが、状況によって最適解は変わります。

複雑問題に深く入り込み、履歴が価値を持つためコンテキストを溜めたほうが良いこともあります。探索タスクでは計画を省略して Claude に任せたほうが良いこともあります。曖昧プロンプトが正解で、Claude の解釈を見てから制約を追加したい場合もあります。

何がうまくいくかに注意してください。Claude が素晴らしい出力を出したとき、自分が何をしたかを観察してください: プロンプト構造、与えたコンテキスト、使ったモード。Claude が苦戦したときは理由を考えてください。コンテキストがノイジーだった？プロンプトが曖昧だった？タスクが大きすぎた？

時間とともに、どのガイドにも書けない直感が育ちます。いつ具体的にするか、いつ自由にするか、いつ計画するか、いつ探索するか、いつコンテキストをクリアするか、いつ積み上げるかが分かってくるはずです。

リソース	内容
⚙️ How Claude Code works `/en/how-claude-code-works`	エージェントループ、ツール、コンテキスト管理を理解する
🧩 Extend Claude Code `/en/features-overview`	skills、hooks、MCP、subagents、plugins の使い分け
✅ Common workflows `/en/common-workflows`	デバッグ、テスト、PR などの手順レシピ
📄 CLAUDE.md `/en/memory`	プロジェクト規約と永続コンテキストの保存