Claude Code ベストプラクティス｜公式7分野を15項目に整理【2026年9月】

2026年3月16日

このトピックの全体像Claude Code 完全ガイド｜料金・使い方・法人導入の全体像その他の記事の記事

公開日: 2026年3月16日最終更新: 2026年9月29日

公式ドキュメント・公式発表などの一次情報を確認したうえで、株式会社Nexaが執筆・更新しています。AIツールの仕様や料金は変わることがあるため、導入判断の前に各公式サイトの最新情報もご確認ください。運営会社について

Claude Code のベストプラクティスは、Anthropic公式ドキュメントでは7つの分野に分けて説明されています。この記事では、その内容を日本語で15項目に整理しました（2026年9月27日に公式ページで確認）。

土台: 公式は「コンテキストウィンドウはすぐに埋まり、埋まるほど性能が落ちる」という制約を、ほとんどの推奨の前提に置いています
最初の一歩: 公式が最初に挙げるのは、テスト・ビルド・スクリーンショットなど、Claudeが自分で合否を確認できる手段を渡すことです
CLAUDE.md: 公式の目安は1ファイル200行未満。長くなるほど指示が守られにくくなります

対象: Claude Codeを使い始めた方、社内での使い方をそろえたい開発者・DX推進担当者

今日やること: CLAUDE.mdの各行に「これを消したらClaudeが間違えるか」を問い、不要な行を削る

この記事の著者

株式会社Nexa 代表取締役川島陸

一橋大学経済学部卒業後、フォーティエンスコンサルティング株式会社（旧株式会社クニエ）にて法人向けAI導入支援等を経験。独立後、AI系メディア運営やDify/n8nの導入支援を経て、株式会社Nexaを創業。法人向けAI研修・AI導入支援・AI関連メディア運営を手掛ける。

詳しく見る AI顧問の無料相談

Claude Code のベストプラクティスは、Anthropic公式ドキュメントの「Claude Code のベストプラクティス」にまとまっています。実践項目は7つの分野に分かれ、最後に失敗パターンが5つ挙げられています。

ただ、公式ページは分量が多く、機能の追加に合わせて内容も書き換えられています。2026年3月時点の版と現在の版を比べると、権限設定、検証の方法、並列実行の選択肢が変わっていました。

この記事では、公式の7分野を日常の作業で使いやすい15項目に整理し、3月から変わった点もあわせて説明します。記載内容は2026年9月27日に公式ページを開いて確認したものです。

Claude Code ベストプラクティスの全体像

15項目は、公式の7分野を「設定」「プロンプト」「ワークフロー」の3つのカテゴリに並べ直したものです。15という数は公式の数え方ではなく、この記事での整理です。

公式が前提に置く1つの制約

公式ページは冒頭で、ほとんどのベストプラクティスは1つの制約に基づくと述べています。Claudeのコンテキストウィンドウはすぐにいっぱいになり、満杯に近づくほど性能が落ちる、という制約です。

コンテキストウィンドウには、会話のすべてのメッセージ、Claudeが読んだファイル、コマンドの出力が入ります。埋まってくると、Claudeは以前の指示を忘れたり、間違いが増えたりします。この記事の15項目の多くは、この制約への対策です。

公式の7分野と15項目の対応

公式の分野	主な内容	この記事の項目
Claude に自分の作業を検証する方法を与える	テスト・ビルド・スクリーンショットなど、合否が分かる確認手段を渡す	BP6
最初に探索し、次に計画し、その後コーディングする	プランモードで調査と計画を実装から分ける	BP7
プロンプトで具体的なコンテキストを提供する	対象ファイル・制約・参考にするパターンを指定する	BP5
環境を設定する	CLAUDE.md、権限、CLIツール、MCP、フック、スキル、サブエージェント、プラグイン	BP1〜4、BP12、BP13
効果的にコミュニケーションする	コードベースについて質問する、Claudeに質問させて仕様を固める	BP8
セッションを管理する	早めの軌道修正、コンテキスト管理、サブエージェント、巻き戻し、再開	BP9〜11
自動化とスケール	非対話モード、並列セッション、一括処理、autoモード、レビューの追加	BP14、BP15

3つのカテゴリ

カテゴリ	内容	対象レベル
設定編（BP1〜4）	CLAUDE.mdと権限の設定。Claudeが毎回読み込む指示と、確認の回数を整える	入門〜中級
プロンプト編（BP5〜8）	指示の出し方の改善。対象・確認方法・計画を先に伝えて手戻りを減らす	入門〜中級
ワークフロー編（BP9〜15）	コンテキスト管理・フック・スキル・並列実行で、長い作業や繰り返し作業に対応する	中級〜上級

レベル別の取り組み方

初めてClaude Codeを使う方は、コンテキスト管理（BP9〜11）とプロンプト編（BP5〜8）から着手することをおすすめします。設定を変えなくても、その日から試せる項目です。

慣れてきたら設定編（BP1〜4）でCLAUDE.mdと権限を整え、ワークフロー編②（BP12〜15）でフックやスキル、並列実行に進んでください。

図1: 管理と指示から試し、設定を整えてから自動化へ広げます。

15のベストプラクティス一覧:

#	ベストプラクティス	カテゴリ	レベル
1	CLAUDE.mdには、コードを読んでも分からない情報だけを書く	設定	入門
2	CLAUDE.mdは200行未満を目安に短く保ち、定期的に削る	設定	入門
3	許可リスト・サンドボックス・autoモードで確認の回数を減らす	設定	中級
4	全プロジェクト共通の指示とプロジェクト固有の指示を置き分ける	設定	中級
5	対象・制約・参考にするパターンを具体的に指定する	プロンプト	入門
6	検証手段をClaudeに与える	プロンプト	入門
7	調査・計画・実装の順に進める（プランモード）	プロンプト	中級
8	大きな機能は、先にClaudeに質問させて仕様書にする	プロンプト	中級
9	無関係なタスクの間で /clear を実行する	ワークフロー	入門
10	/compact は残す内容を指示して使う	ワークフロー	中級
11	調査・リサーチはサブエージェントに委譲する	ワークフロー	中級
12	例外なく実行したい処理はフックにする	ワークフロー	上級
13	繰り返す手順はスキルにまとめる	ワークフロー	中級
14	並列セッションで「書く役」と「見直す役」を分ける	ワークフロー	上級
15	非対話モードで定型作業を自動化する	ワークフロー	上級

【ワークフロー編①】コンテキスト管理で失速を防ぐ（BP9〜11）

Anthropic公式が「管理する最も重要なリソース」と位置づけるのがコンテキストウィンドウです。ほかの項目の前提になるため、先に説明します。

BP9. 無関係なタスクの間で `/clear` を実行する

異なる作業を同じセッションで続けると、無関係な情報がコンテキストに残り、後のタスクの精度を下げます。公式はこれを失敗パターンの1つ目に挙げています。

実践ルール:

1つのタスクが終わり、次が無関係な作業なら /clear でコンテキストをリセットする
同じ問題でClaudeを2回修正しても直らないときは、/clear を実行し、分かったことを盛り込んだ指示で最初からやり直す
後で戻りたいセッションは、/rename で名前を付けておく。claude --resume で一覧から選んで再開できる
セッションをまたいで残したいルールはCLAUDE.mdに書く

BP10. `/compact` は残す内容を指示して使う

Claude Codeは、コンテキストの上限に近づくと会話履歴を自動で圧縮します。公式のベストプラクティスには「使用率が何%になったら実行する」という数値基準は書かれていません。この記事の旧版では70%を目安としていましたが、公式の記述に合わせて改めました。

公式が示しているのは、圧縮を自動に任せきりにせず、残す内容を自分で指定する方法です。

場面ごとの手段:

場面	公式が示す手段
次の作業が今の作業と無関係	`/clear` でコンテキストをリセットする
同じ作業を続けたいが、会話が長くなった	`/compact <指示>` を実行する。例: `/compact Focus on the API changes`
会話の一部だけを圧縮したい	`Esc` を2回押すか `/rewind` でメッセージを選び、「ここから要約」または「ここまで要約」を選ぶ
圧縮のたびに必ず残したい情報がある	CLAUDE.mdに「圧縮時は変更したファイルの一覧とテストコマンドを必ず残す」のような指示を書く
履歴に残す必要のない確認をしたい	`/btw` で質問する。回答は会話履歴に入らない
何がコンテキストを使っているか知りたい	`/context` で確認する。ステータスラインに使用量を常時表示することもできる

ポイントプロジェクト直下のCLAUDE.mdは、圧縮後にディスクから読み直されます。会話の中だけで伝えた指示は圧縮で失われることがあるため、残したい指示はCLAUDE.mdに書いてください（公式ドキュメント: メモリ）。

BP11. 調査・リサーチはサブエージェントに委譲する

仕様の確認やエラーの原因究明など、多くのファイルを読む調査作業は、サブエージェントに委譲します。

サブエージェントは独自のコンテキストウィンドウで動き、要約だけをメインの会話に返します。調査で読んだファイルの中身がメインのコンテキストを埋めずに済みます。

活用例:

「◯◯ライブラリのv3とv4の互換性の違いを調査してください。
 調査はサブエージェントで実施し、主要な差分を5点にまとめて報告してください」

公式は失敗パターンとして、範囲を決めずに「調査して」と頼み、Claudeが数百のファイルを読んでコンテキストを埋めてしまう例を挙げています。調査の範囲を絞るか、サブエージェントに任せるのが対処です。

詳細はClaude Code Agent・サブエージェント完全ガイドをご覧ください。

AI導入に関するお困りごとは、株式会社NexaのAI顧問がサポートします。「何から始めればいいか分からない」という段階からご相談いただけます。

AI顧問の無料相談はこちら →

【設定編】CLAUDE.mdと権限を整える（BP1〜4）

CLAUDE.mdは、Claudeがすべての会話の開始時に読むファイルです。毎回読み込まれるため、書く内容と長さがそのまま結果に影響します。

BP1. CLAUDE.mdには、コードを読んでも分からない情報だけを書く

公式は、CLAUDE.mdに含めるものと除外するものを次のように分けています。

含める	除外する
Claudeが推測できないBashコマンド	コードを読めば分かること
デフォルトと異なるコードスタイルのルール	Claudeが既に知っている標準的な言語規約
テストの指示と、使うテストランナー	詳細なAPIドキュメント（リンクで示す）
リポジトリの決まり（ブランチ名、PRの規約）	頻繁に変わる情報
プロジェクト固有の設計上の決定	長い説明やチュートリアル
開発環境の癖（必須の環境変数など）	ファイルごとのコードベースの説明
よくある落とし穴、分かりにくい挙動	「きれいなコードを書く」のような自明な心がけ

コードスタイルは一律に書かないのではなく、デフォルトと異なるルールだけを書きます。最初の1本は /init で生成できます。/init はコードベースを解析し、ビルドコマンドやテスト方法を含むCLAUDE.mdを作ります。

図2: コードから読み取れない情報を残し、既知の説明は省きます。

BP2. CLAUDE.mdは200行未満を目安に短く保ち、定期的に削る

公式は、CLAUDE.mdを1ファイル200行未満に収めることを目安にしています（公式ドキュメント: メモリ）。長いファイルはコンテキストを多く使い、指示が守られにくくなります。

各行に「これを消したらClaudeが間違えるか」を問い、間違えないなら削る
ルールを書いているのにClaudeが守らない場合は、ファイルが長すぎてルールが埋もれている可能性がある
どうしても守らせたい指示は、その1行だけに「IMPORTANT」などの強調を付ける。多くの行を強調すると、どれも目立たなくなる
たまにしか使わない知識や手順は、CLAUDE.mdではなくスキル（BP13）に移す
gitで管理しているCLAUDE.mdは、/doctor を実行すると、コードから読み取れる内容の削除をClaudeが提案する

公式は、CLAUDE.mdをgitにチェックインしてチームで育てることも勧めています。

BP3. 許可リスト・サンドボックス・autoモードで確認の回数を減らす

Claude Codeは、ファイルの書き込みやコマンドの実行の前に許可を求めます。安全ですが、回数が増えると内容を読まずに承認しがちです。公式が示す手段は3つあります。

手段	内容
許可リスト（`/permissions`）	`npm run lint` や `git commit` など、安全だと分かっている操作を事前に許可する
サンドボックス（`/sandbox`）	OSレベルの分離でファイルシステムとネットワークへのアクセスを制限し、その範囲内ではClaudeが確認なしで動けるようにする
autoモード	別の分類モデルが操作を事前に確認し、依頼の範囲を超える操作や、見知らぬインフラへの操作など、危険に見えるものだけを止める

公式ドキュメント（英語版）によると、Claude Code v2.1.283以降では、対話型のターミナルとVS Codeのセッションはautoモードで始まります。それより前のバージョンでは、Pro・Max・Teamプランに限ってautoモードが開始時の既定でした。

公式は、autoモードは確認の回数を減らすもので、安全を保証するものではないと注意しています。機密性の高い作業では、編集とコマンドを自分で承認するManualモードに切り替えます。Team・Enterpriseプランでは、管理者が組織全体でautoモードを無効にできます。

BP4. 全プロジェクト共通の指示とプロジェクト固有の指示を置き分ける

CLAUDE.mdは置く場所によって、適用される範囲が変わります。

種類	場所	用途
組織の管理ポリシー	macOSは `/Library/Application Support/ClaudeCode/CLAUDE.md` など	会社のコーディング規約、セキュリティポリシー
ユーザー	`~/.claude/CLAUDE.md`	すべてのプロジェクトに共通する個人の好み
プロジェクト	`./CLAUDE.md` または `./.claude/CLAUDE.md`	チームで共有するプロジェクトのルール
ローカル	`./CLAUDE.local.md`	自分だけのプロジェクト設定。`.gitignore` に追加する

CLAUDE.mdからは @path/to/import の書き方で別のファイルを読み込めます。読み込みの入れ子は最大4段までです。

CLAUDE.mdとは別に、Claudeが自分でメモを残す自動メモリもあります。既定で有効で、セッションの開始時に先頭200行または25KBまでが読み込まれます。/memory で有効・無効を切り替えられます。

【プロンプト編】指示の出し方を変える（BP5〜8）

公式は「指示が正確であるほど、必要な修正が少なくなる」と述べています。プロンプト編の4項目は、設定を変えずに今日から試せます。

BP5. 対象・制約・参考にするパターンを具体的に指定する

公式は4つの方法を、改善前と改善後の例で示しています。

方法	改善前	改善後
タスクの範囲を絞る	foo.py のテストを追加する	ユーザーがログアウトしている場合を扱う foo.py のテストを書く。モックは使わない
情報源を指定する	ExecutionFactory のAPIはなぜこんな形なのか	ExecutionFactory のgit履歴を調べて、APIが今の形になった経緯を要約する
既存のパターンを参照させる	カレンダーのウィジェットを追加する	ホームページの既存ウィジェットの実装を見て、同じパターンで新しいカレンダーのウィジェットを実装する
症状を説明する	ログインのバグを修正する	セッションのタイムアウト後にログインが失敗する。src/auth/ の認証フローを確認し、再現するテストを書いてから修正する

材料の渡し方も公式に挙げられています。@ でファイルを参照する、画像を貼り付ける、ドキュメントのURLを渡す、cat error.log | claude のようにデータを直接流し込む、といった方法です。

一方で公式は、探索の段階ではあいまいな指示が役に立つこともあると述べています。「このファイルで何を改善しますか」のような問いは、自分では思いつかなかった点を引き出せます。

BP6. 検証手段をClaudeに与える

公式が7分野の最初に置いている項目です。Claudeは作業が完了したように見えた時点で止まります。合否が分かる確認手段がなければ、間違いに気づく役目はすべて人に回ってきます。

確認手段は、テスト、ビルドの終了コード、リンター、出力を期待値と比べるスクリプト、デザインと見比べるスクリーンショットなどです。公式は、確認をどこまで厳しくするかを4段階で示しています。

段階	方法
1つのプロンプトの中で	「実装後にテストを実行し、通るまで修正する」と同じ指示の中で頼む
セッション全体で	確認内容を `/goal` の条件に設定する。別の評価役が各ターンの後に条件を確認する
決定的なゲートとして	Stopフックで確認スクリプトを実行し、合格するまでターンの終了を止める
第二の意見として	検証用のサブエージェントに、結果への反証を試みさせる

公式は、Claudeに成功を宣言させるのではなく、テストの出力や実行したコマンドの結果といった証拠を示させることも勧めています。

BP7. 調査・計画・実装の順に進める（プランモード）

いきなり実装させると、間違った問題を解くコードができることがあります。公式が勧める流れは、探索、計画、実装、コミットの4段階です。

入り方: ステータスバーに「plan mode on」と表示されるまで Shift+Tab を押す。claude --permission-mode plan で起動する方法や、プロンプトの先頭に /plan を付ける方法もある
プランモード中: Claudeはファイルを読んで計画を作るが、ソースは編集しない
計画の修正: Ctrl+G で計画をテキストエディタで開き、直接書き換えられる
実装へ: 計画を承認するとプランモードを抜け、実装が始まる

公式は、プランモードには手間も増えると注意しています。誤字の修正や変数名の変更のように、差分を1文で説明できる作業では計画を省きます。計画が役に立つのは、進め方に確信がないとき、複数のファイルを変更するとき、なじみのないコードを触るときです。

BP8. 大きな機能は、先にClaudeに質問させて仕様書にする

大きな機能では、最小限の説明から始めて、Claudeに質問させる方法を公式が勧めています。実装方法、UI、例外的なケース、トレードオフなど、まだ考えていなかった点をClaudeが尋ねます。

「[作りたいものの簡単な説明] を作りたい。AskUserQuestion ツールを使って詳しく質問してください。
 分かりきった質問はせず、私が見落としていそうな難しい部分を掘り下げてください。
 すべて確認できたら、仕様の全体を SPEC.md に書いてください」

仕様書ができたら、新しいセッションを開始して実装します。新しいセッションは実装だけに集中したコンテキストを持ち、参照できる仕様書も手元にあります。

【ワークフロー編②】自動化と並列実行に広げる（BP12〜15）

1つのセッションで安定して成果が出るようになったら、フック・スキル・並列実行で作業を広げます。

BP12. 例外なく実行したい処理はフックにする

フックは、Claudeの作業の特定のタイミングでスクリプトを自動実行する仕組みです。CLAUDE.mdの指示は助言ですが、フックは決定的で、処理が実行されることを保証します。

フックはClaudeに書かせることができます。公式の例は「ファイルを編集するたびに eslint を実行するフックを書いて」「migrations フォルダへの書き込みを止めるフックを書いて」です。

手で設定するときは .claude/settings.json を編集し、/hooks で設定済みのフックを確認します。詳細はClaude Code Hooks完全ガイドをご覧ください。

BP13. 繰り返す手順はスキルにまとめる

スキルは、.claude/skills/<スキル名>/SKILL.md に置くファイルで、Claudeにプロジェクト固有の知識や再利用できる手順を与えます。Claudeが関連する場面で自動的に使うほか、/スキル名 で直接呼び出せます。

通常のセッションでは、スキルの説明文だけがコンテキストに入り、本文は呼び出されたときに読み込まれる。CLAUDE.mdに書くより、毎回のコンテキストを小さく保てる
デプロイのように副作用のある手順は、disable-model-invocation: true を指定して、人が呼び出したときだけ実行されるようにする
以前のカスタムコマンドはスキルに統合された。.claude/commands/ に置いた既存のファイルは引き続き動作する（公式ドキュメント: スキル）

BP14. 並列セッションで「書く役」と「見直す役」を分ける

公式は、新しいコンテキストで見直すとレビューの質が上がると説明しています。書いた本人のセッションは、自分が書いたコードに判断が寄るためです。1つのセッションに実装させ、別のセッションに見直させ、指摘を元のセッションに戻します。

並列で動かす方法として、公式は次の6つを挙げています。

方法	内容
ワークツリー	分離したgitのチェックアウトで別々のセッションを動かし、編集がぶつからないようにする
セッション間のメッセージ	自分で動かしている複数のセッションの間で、調べた結果を受け渡す
デスクトップアプリ	複数のローカルセッションを画面上で管理する
クラウドでの実行	Anthropicが管理する環境でセッションを動かす
エージェントビュー	研究プレビュー。`claude agents` でバックグラウンドのセッションを1つの画面から見守る
エージェントチーム	実験的な機能で、既定では無効。複数のセッションを、共有タスクとチームリーダーで自動的に調整する

エージェントチームは、CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS を 1 に設定して有効にします（公式ドキュメント: エージェントチーム）。公式のコスト管理のページには、チームメイトがプランモードで動く場合、通常のセッションの約7倍のトークンを使うと書かれています。順番に進める作業や同じファイルを編集する作業では、1つのセッションかサブエージェントのほうが向いています。

完了とみなす前の見直しには、同梱の /code-review スキルが使えます。新しいサブエージェントが現在の差分を確認し、指摘を返します。公式は、指摘をすべて追うと作り込みすぎになるため、正しさと要件に関わる指摘だけを扱うよう注意しています。

BP15. 非対話モードで定型作業を自動化する

claude -p "プロンプト" を使うと、対話なしでClaudeを実行できます。CI、コミット前のフック、スクリプトに組み込むための方法です。

# 1回だけの質問
claude -p "Explain what this project does"

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

多数のファイルに同じ変更をかけるときは、/batch <指示> を使う。Claudeが変更を5〜30個のサブエージェントに分け、それぞれが別のワークツリーで作業する
自分のスクリプトから回すときは、--allowedTools でClaudeに許可する操作を絞る。無人で動かすときほど重要になる
いきなり全件にかけず、最初の2〜3ファイルで試してプロンプトを直してから全体に広げる

図3: 繰り返す処理を整理し、権限を絞って小さく試します。

公式が挙げる失敗パターン5つと対処

公式ページは、よくある失敗を5つ挙げ、それぞれに対処を示しています。15項目のどれが抜けているかを確認するチェック表として使えます。

失敗パターン	起きること	公式が示す対処
何でも詰め込んだセッション	1つのタスクの途中で無関係な質問をし、また元のタスクに戻る。コンテキストが無関係な情報で埋まる	無関係なタスクの間で `/clear` を実行する
修正の繰り返し	間違いを直させても直らず、また直させる。コンテキストが失敗した試みで埋まる	2回直しても直らなければ `/clear` し、分かったことを盛り込んだ指示を書き直す
書き込みすぎたCLAUDE.md	長すぎて重要なルールが埋もれ、Claudeが半分を無視する	思い切って削る。指示がなくても正しくできていることは、削除するかフックに変える
確認なしの信頼	もっともらしい実装が出てくるが、例外的なケースを扱えていない	テスト・スクリプト・スクリーンショットなどの検証を必ず渡す
終わらない探索	範囲を決めずに調査を頼み、Claudeが数百のファイルを読む	調査の範囲を絞るか、サブエージェントに任せる

公式は最後に、これらのパターンは固定の規則ではなく出発点だと述べています。1つの難しい問題に取り組んでいて履歴に価値があるときは、あえてコンテキストを残す判断もあります。

＼ AI活用の「次の一手」を一緒に考えませんか／

AI顧問の無料相談はこちら

2026年3月から変わった公式の推奨

この記事を公開した2026年3月時点の公式ページ（Internet Archiveに保存された2026年3月13日の版）と、2026年9月27日時点の版を比べました。7分野の構成と失敗パターン5つは変わっていません。変わっていたのは次の点です。

項目	2026年3月の版	2026年9月27日の版
権限設定	許可リストとサンドボックスを紹介。隔離された環境向けに `--dangerously-skip-permissions` にも言及	autoモードが中心。v2.1.283以降は対話型のターミナルとVS Codeの開始時の既定。`--dangerously-skip-permissions` への言及はなくなった
検証の方法	テスト・スクリーンショット・期待する出力を渡す	確認の厳しさを4段階で示す（プロンプト内、`/goal`、Stopフック、検証用サブエージェント）。証拠を示させる指示が加わった
並列実行の選択肢	デスクトップアプリ、Web、エージェントチームの3つ	ワークツリー、セッション間のメッセージ、エージェントビューが加わり6つ。エージェントチームは「実験的で既定では無効」と明記
自動化の章	非対話モード、並列セッション、一括処理の3項目	「autoモードで自律的に実行する」「敵対的なレビューを追加する」が加わり5項目
一括処理	`claude -p` をループで回すスクリプト	`/batch` が加わった。5〜30個のサブエージェントに分けて実行する
CLAUDE.md	`/init` で生成し、短く保つ	`/context` での読み込み確認と、`/doctor` による削除の提案が加わった
会話の部分的な圧縮	「ここから要約」	「ここまで要約」も選べるようになった

あわせて、この記事の旧版にあった次の記述を改めました。

「コンテキスト使用率70%で /compact」: 公式ページに使用率の数値基準は書かれていないため、場面ごとの手段に書き換えました
「構造化プロンプトで修正作業を約50%削減」: 公式ページで該当する記述を確認できなかったため、削除しました
「CLAUDE.mdにフォーマット指示は書かない」: 公式は、デフォルトと異なるコードスタイルのルールは含めるとしています。除外するのは標準的な言語規約です
カスタムコマンド: スキルに統合されたため、BP13をスキルの説明に改めました

日本語版の公式ページは、英語版より更新が遅れている箇所があります。2026年9月27日時点で、権限設定の項は日本語版が「Pro、Max、Teamプランではautoモードが開始時の既定」、英語版が「v2.1.283以降はautoモードが開始時の既定」と、記述が異なっていました。変更の多い項目は英語版もあわせて確認してください。

よくある質問

Claude Codeのベストプラクティスは、公式のどこに書かれていますか？

Claude Code公式ドキュメントの「Claude Code のベストプラクティス」（code.claude.com/docs/ja/best-practices）に書かれています。以前Anthropicのエンジニアリングブログで公開されていたベストプラクティスの記事のURLは、2026年9月27日時点で公式ドキュメントの同ページへ転送されます。日本語版は英語版より更新が遅れている箇所があるため、権限設定など変更の多い項目は英語版もあわせて確認してください。

CLAUDE.mdには何を書けばいいですか？

Claudeがコードを読んでも分からない情報を書きます。公式が挙げるのは、推測できないBashコマンド、デフォルトと異なるコードスタイル、テストの実行方法、ブランチやPRの規約、プロジェクト固有の設計判断、開発環境の癖、よくある落とし穴の7種類です。標準的な言語規約や、コードを読めば分かる内容は書きません。公式の目安は1ファイル200行未満です。

/compactはいつ実行すればいいですか？

公式のベストプラクティスには「使用率が何%になったら実行する」という数値基準は書かれていません。Claude Codeはコンテキストの上限に近づくと自動で会話を圧縮します。公式が勧めているのは、無関係なタスクの間で /clear を実行することと、自分で圧縮するときは /compact に残したい内容の指示を添えることです。

HooksとCLAUDE.mdの違いは何ですか？

CLAUDE.mdの指示は助言で、Claudeが参考にして行動します。フックはClaudeの作業の特定のタイミングで必ず実行されるスクリプトです。公式は、例外なく毎回実行したい処理にはフックを使うよう勧めています。覚えておいてほしいルールはCLAUDE.md、確実に実行したい処理はフックと使い分けます。

Claude（チャットやAPI）のプロンプトのベストプラクティスは別にありますか？

あります。Claude Code向けとは別に、Claudeのモデル全般を対象にした「プロンプティングのベストプラクティス」がClaude Platformのドキュメントで公開されています。明確で直接的に指示する、指示の理由や背景を添える、例を示す、XMLタグで構造化する、役割を与える、といった原則がまとめられています。

非エンジニアでもベストプラクティスは使えますか？

使えます。具体的に指示する（BP5）、確認方法を渡す（BP6）、先にClaudeに質問させて仕様を固める（BP8）、無関係な作業の間で /clear する（BP9）の4つは、コードを書かない業務でもそのまま使えます。CLAUDE.mdも、担当業務のルールや注意点を日本語で書くだけで機能します。

Claude Codeのプランモードはどう使いますか？

ステータスバーに「plan mode on」と表示されるまで Shift+Tab を押すか、claude –permission-mode plan で起動します。プランモードではClaudeはファイルを読んで計画を作りますが、ソースは編集しません。計画を承認すると実装に移ります。公式は、差分を1文で説明できるような小さな修正では計画を省くよう勧めています。