Claude Code公式ベストプラクティス日本語版
Claude Codeの使い方を検索すると、「使ってみた」「便利だった」という記事はたくさん出てきます。でも、Anthropic自身が「こう使ってほしい」と公式に書いている内容を、まとめて日本語で読める場所はほとんどありません。
この記事では、Anthropicの公式ドキュメントに書かれているベストプラクティスを、専門用語を避けて整理します。「なんとなく使っている」から「意図を持って使う」に変わる内容です。
📌 本記事は2026年8月時点の公式ドキュメントに基づきます。Claude Codeは更新が速いため、細かい仕様は変わる可能性があります。
結論：すべては「コンテキスト管理」に集約される
公式ドキュメントを読んで一番驚くのは、ほぼすべての推奨事項が、たった1つの制約から導かれていることです。
ほとんどのベストプラクティスは1つの制約に基づく — Claudeのコンテキストウィンドウはすぐ埋まり、埋まるほど性能が落ちる
公式は、コンテキストウィンドウを「最も重要な管理対象リソース」と表現しています。
「コンテキストウィンドウ」とは、AIが一度に覚えていられる情報の量のことです。会話が長くなるほど、読み込んだファイルが増えるほど、ここが埋まっていきます。そして埋まるほどAIは賢さを失います。
つまり、Claude Codeを上手に使うとは——
AIの「頭の中」を、きれいに保ち続けること。
これから紹介するテクニックは、すべてこの一点につながっています。
① AIに「自分で答え合わせする手段」を渡す
公式が最も強調しているポイントです。
テスト、ビルド、比較用スクリーンショット — 見ているだけのセッションと、席を外せるセッションの分かれ目
AIに検証手段がないと、「それらしく見える＝完成」で作業を止めてしまいます。そしてあなた自身が検証ループの一部になってしまう。ずっと画面に張り付いて確認し続けることになります。
そこで、合否がはっきり返ってくるものを渡します。
- テストを走らせる
- ビルドが通るか確認させる
- 見た目ならスクリーンショットを撮って比較させる
さらに公式は、こう釘を刺しています。
「成功した」と主張させるのではなく、証拠（テスト出力・実行したコマンドと結果）を出させろ
指示に一言を加えるだけで、AIの動きは変わります。
終わったら、実際にテストを実行して、その出力をそのまま見せてください。
② 探索 → 計画 → 実装 → コミット
公式が推奨する作業の型です。いきなり「作って」と言わない、ということです。
| 段階 | やること |
|---|---|
| 1. 探索（Explore） | まず読ませる。「/src/auth を読んで、ログインの仕組みを理解して」 |
| 2. 計画（Plan） | 「計画を立てて」と指示。まだコードは書かせない |
| 3. 実装（Implement） | 計画を承認してから作らせる。テストも書かせる |
| 4. コミット（Commit） | 「わかりやすいメッセージでコミットして」 |
この1〜2を安全に行うための専用機能がプランモードです。詳しくは「プランモード完全ガイド」で解説しています。
ただし、いつも計画が必要なわけではない
公式は正直にこう書いています。
差分を1文で説明できるなら、計画は飛ばせ
タイプミスの修正、ログを1行足すだけ、変数名の変更——こういう作業に計画は不要です。オーバーヘッドの方が大きくなります。
③ CLAUDE.mdは「削る」ほど効く
CLAUDE.md は、AIが毎回自動で読む「プロジェクトの取扱説明書」です。ここが多くの人がハマるポイントで、公式は明確に警告しています。
肥大化したCLAUDE.mdは、Claudeがあなたの実際の指示を無視する原因になる
「ルールを書いているのに守ってくれない」——その原因は、ファイルが長すぎてルールが埋もれている可能性が高いのです。
公式が勧めるチェック方法がこれです。
各行について「これを消したらClaudeがミスするか？」を自問し、Noなら消す
書くべきこと・書かなくていいこと（公式の対比）
| ✅ 書く | ❌ 書かない |
|---|---|
| AIが推測できない独自コマンド | コードを読めばわかること |
| 標準と違う独自のコード規約 | 一般的な言語の常識 |
| テストの実行手順 | 詳細なAPI仕様（リンクで十分） |
| ブランチ名やPRの作法 | よく変わる情報 |
| 環境の癖（必要な環境変数） | 長いチュートリアル |
| ハマりやすい落とし穴 | 「きれいなコードを書く」等の当たり前 |
作り方は /init コマンドで雛形を自動生成し、そこから育てるのが公式の推奨です。「IMPORTANT」「YOU MUST」と強調すると守られやすくなる、という実務的なコツも書かれています。
💡 たまにしか使わない知識は、CLAUDE.mdではなくスキルに置くのが公式推奨です。→「Agent Skills入門」
詳しい書き方は「CLAUDE.mdファイルの書き方」もあわせてどうぞ。
④ `/clear` を惜しまない
公式でいちばん実践しやすいのがこれです。
- 関係ないタスクに移るとき、毎回
/clear - 同じ問題で2回以上直しを頼んだら
/clear
2つ目が重要です。公式はこう断言しています。
きれいなセッション＋良いプロンプトは、修正が積み重なった長いセッションにほぼ必ず勝つ
修正を重ねるほど、失敗の履歴がコンテキストを汚していきます。2回失敗したら、学んだことを盛り込んだ良い指示文で作り直す方が速い、ということです。
会話が長くなってきたときの対処法は「コンテキスト上限を超えた時の対処法」でも解説しています。
⑤ サブエージェント（AIの部下）を使う
コンテキストが根本的な制約である以上、サブエージェントは最も強力なツールの1つ
調査を部下に任せれば、大量のファイルを読んだ結果ではなく、要約だけが本体に返ってきます。コンテキストが汚れません。
さらに公式が推奨するのが「敵対的レビュー」です。
書いた本人（同じセッション）は自分のコードに甘くなります。新しいサブエージェントは差分と基準しか見ないので、バイアスなくレビューできます。
ただし公式は、ここでも正直な注意を添えています。
「ギャップを探せ」と言われたレビュアーは、健全な成果物でも何か報告してしまう。全部追いかけると過剰設計になる
→ 「正しさや要件に関わるものだけ挙げて」と範囲を絞るのがコツです。
⑥ 公式が名前を付けた「5つの失敗パターン」
自分に当てはまるものがないか、チェックしてみてください。
| 失敗パターン | 症状 | 対策 |
|---|---|---|
| 闇鍋セッション | 1つの会話に無関係な話題を混ぜる | タスクの合間に /clear |
| 修正の無限ループ | 「違う」「そうじゃない」を繰り返す | 2回失敗で /clear して作り直し |
| 盛りすぎCLAUDE.md | 長すぎて半分無視される | 容赦なく削る |
| 信じたら裏切られた | もっともらしいが実は動かない | 検証手段を必ず用意する |
| 無限探索 | 範囲を決めずに数百ファイル読む | 範囲を絞る／部下に任せる |
⑦ 許可の確認疲れをなくす
公式の指摘が鋭いので引用します。
10回目の承認では、もうレビューしていない。クリックしているだけ
毎回「実行していいですか？」を確認するのは安全ですが、慣れると思考停止で押すようになり、かえって危険になります。公式は、よく使う安全なコマンドは許可リストに登録しておく（/permissions）ことを勧めています。
まとめ：明日から変えられる3つ
たくさん紹介しましたが、まずこの3つだけで十分に効果があります。
- タスクが変わったら
/clear— 一番かんたんで、一番効く - 2回直しを頼んだら、作り直す — 粘るより速い
- 「テストを実行して、結果を見せて」と一言足す — AIの自己申告を鵜呑みにしない
最後に、公式ドキュメントの締めくくりの一節を紹介します。
このガイドのパターンは石板に刻まれたものではない
文脈を貯めた方がいい場合も、計画を飛ばした方がいい場合も、曖昧な指示が正解の場合もある——と公式自身が書いています。型は出発点であって、正解ではないということです。
まずは1つ試してみて、自分の作業に合うものを残していってください。
