はじめに
Claude Codeを使う際、まずCLAUDE.mdを作ると思いますが、プロジェクト共通で読み込む~/.claude/CLAUDE.md、いわばグローバルCLAUDE.mdに皆さんは何を記載しているでしょうか。特に作っていないという人も多いかもしれません。
ここに書いた内容は、どのプロジェクトで作業していても毎回読み込まれる、いわば「個人の共通設定」です。
プロジェクトごとのCLAUDE.mdについては情報が増えてきましたが、このグローバルCLAUDE.mdに何を書くべきかは、意外とまとまった情報がありません。私自身も試行錯誤していたので、Anthropic公式ドキュメントや実践者コミュニティの知見を調べて整理してみました。
この記事では、それらの知見をもとに自分なりにベストプラクティスに従った指示文と、各行を「なぜ入れたのか」「なぜ他は入れなかったのか」をソース付きで解説していきます。
前提知識：メモリ階層とトークンコスト
まず、CLAUDE.mdの仕組みを押さえておく必要があります。Claude Codeのメモリシステムには4つの階層があり、それぞれ役割が異なります。
| 優先度 | 種別 | パス | 用途 |
|---|---|---|---|
| 1 | Enterprise policy | /Library/Application Support/ClaudeCode/CLAUDE.md |
組織全体のポリシー |
| 2 | Project memory |
./CLAUDE.md or ./.claude/CLAUDE.md
|
チーム共有のプロジェクト設定 |
| 3 | User memory | ~/.claude/CLAUDE.md |
全プロジェクト共通の個人設定 |
| 4 | Project local | ./CLAUDE.local.md |
個人のプロジェクト固有設定 |
ここで知っておくべきなのは、すべてのメモリファイルがセッション開始時にコンテキストウィンドウへ自動で読み込まれるということです。グローバルCLAUDE.mdに書いた内容は、どのプロジェクトで作業していても、毎回トークンを消費します。
さらに厄介なのが「指示の希釈効果」です。HumanLayerの解析によると、Claude Codeのシステムプロンプトにはもともと約50個の指示が含まれており、CLAUDE.mdに指示を追加するたびに、すべての指示の遵守率が少しずつ下がっていくそうです。
「指示を増やすほど不安定になる」現象の正体がこれです。グローバルCLAUDE.mdをミニマルに保つべき理由は、単にトークンの節約だけではなく、書いた指示を確実に守らせるためなのです。
フォーマットの原則：なぜ箇条書き・命令形なのか
中身の話に入る前に、「どう書くか」についても触れておきます。
SFEIR Instituteがコンサルティング実績をもとにまとめた定量データが参考になります。
| フォーマット | 効果 |
|---|---|
| 箇条書き vs 散文 | 遵守率が60%向上 |
| 命令形（「〜する」）vs 記述形（「〜している」） | 精度が25%向上 |
| 150行以下 vs それ以上 | 遵守率が25%向上 |
| テーマ別セクション分け | 関連性が30%向上 |
CLAUDE.mdという文書の性質上、読み手は人間ではなくAIです。ブログ記事のように丁寧に書く必要はなく、むしろ箇条書きで端的に命令するほうが効くというのは、考えてみれば自然な話かもしれません。
また、Anthropicの社内利用レポートでは、特に重要な指示に「IMPORTANT」や「YOU MUST」といった強調表現を使っていることが公開されています。ただし全部の指示を強調してしまうと効果が薄れるので、本当に大事なものだけに絞るべきとのことです。
グローバルCLAUD.mdの具体例
以上を踏まえて作成した、グローバルCLAUDE.mdがこちらです。
# コミュニケーション
- 日本語で応答する（コード・変数名は英語）
- 簡潔に回答し、自明な説明は省略する
- 複雑なタスクでは実装前に計画を提示し、承認後に着手する
# コードスタイル
- 関数型アプローチを優先し、副作用を最小化する
- 厳密な型付け（anyは使わずunknownを使う）
- エラーは握りつぶさず、意味のあるメッセージ付きで処理する
# Git規約
- Conventional Commits形式、本文は日本語（例: `feat: ユーザー認証にOAuth2を追加`）
- 確認なしに自動コミット・自動pushしない
# 禁止事項
- README・ドキュメントを勝手に生成・変更しない
- テストコードを確認なしに削除・コメントアウトしない
- 既存の動作するコードを理由なくリファクタリングしない
補足：セッション引き継ぎの指示
私は上記に加えて、最近Xで少し話題となったZara Zhang (@zarazhangrui) さんの/handoverコマンドに関する指示を入れています。
グローバルCLAUDE.mdの記載に関しては、改善記事も参考にしました。
https://dev.classmethod.jp/articles/claude-code-session-handover/
ここからは、各行がなぜこの指示文に入っているのかを解説していきます。
各セクション解説
1. コミュニケーション
日本語で応答する（コード・変数名は英語）
Claude Codeのデフォルトの応答言語は英語です。日本語環境で使うなら、この指示がないと毎回セッションの冒頭で「日本語でお願いします」と伝えることになります。グローバルCLAUDE.mdに書く理由が最も明確な項目のひとつです。
「コード・変数名は英語」という但し書きも地味に大事で、これがないとClaudeが変数名やコメントまで日本語にしてしまうことがあります。
Anthropic社内のProduct Designチームは、応答のパーソナライズ情報（スキルレベルやペルソナなど）をメモリに含めることで応答品質が劇的に改善したと報告しています。応答言語の指定は、その最も基本的な要素にあたります。
簡潔に回答し、自明な説明は省略する
Claudeは親切なので、デフォルトではかなり丁寧に、そして長く応答してくれます。「このコードは〜を行います」「この変更により〜が改善されます」といった説明が続くのですが、慣れた開発者にとってはコードを見ればわかる内容であることがほとんどです。
Shrivu Shankarは大規模なモノレポでの運用記事で、冗長な応答がコンテキストウィンドウを圧迫し、長いセッションになるとパフォーマンスが目に見えて落ちる問題を指摘しています。簡潔さの指示は、読みやすさだけでなくトークンの節約にもつながります。
複雑なタスクでは実装前に計画を提示し、承認後に着手する
これは個人的にも一番効果を実感している指示です。
Anthropic公式のベストプラクティス記事では、「いきなりコーディングに入る」ことを明確にアンチパターンとして挙げており、リサーチ→計画→実装→検証というフェーズ分けを推奨しています。
計画を先に見せてもらうことで、「それ、方向性が違うよ」と早い段階で軌道修正できます。この指示がないと、見当違いの方向に大量のコードを書かれてから手戻りが発生する、という事態が起こりがちです。Teresa Torresも、計画の事前提示をグローバル設定に含めるべき項目として推奨しています。
Mine includes things like:
- Always create a plan for me to review before you start any work
- Give me direct feedback (no hedging, no gentle suggestions)
- Use bullet points for summaries
- Ask clarifying questions one at a time so I can give complete answers
- No emojis unless I explicitly ask for them
Teresa Torres - Give Claude Code a Memory
2. コードスタイル
コードスタイルの指示には、ひとつ重要な線引きがあります。HumanLayerが提唱している原則で、「リンターやフォーマッターで強制できるルールはCLAUDE.mdに書くな」というものです。
セミコロンの有無、引用符の種類、インデント幅。これらはESLintやPrettierで機械的に強制できます。
では何を書くべきか。答えは、リンターでは表現できない設計方針レベルの判断です。
関数型アプローチを優先し、副作用を最小化する
classで書くかfunctionで書くか、状態をミュータブルに扱うかイミュータブルに扱うか。こうした設計思想の選択は、リンターのルールでは強制できません。Claudeはどちらのスタイルでも書けるので、好みがあるなら明示しておく価値があります。
厳密な型付け（anyは使わずunknownを使う）
TypeScriptにおけるanyとunknownの使い分けは、コードの安全性に直結する設計判断です。noImplicitAnyのようなtsconfig設定でもカバーしきれません（開発者が明示的にanyと書くケースは防げないため）。
SFEIRのデータでは、型やバージョンの明示的な指定により互換性エラーが50%減少したとのことです。
エラーは握りつぶさず、意味のあるメッセージ付きで処理する
Claudeはタスクを素早く完了しようとする傾向があり、その過程でエラーハンドリングが甘くなることがあります。空のcatchブロックや、console.error(e)だけで済ませるパターンは頻繁に目にします。この指示はプロジェクトの種類によらず、普遍的に当てはまるものです。
3. Git規約
Conventional Commits形式、本文は日本語（例: feat: ユーザー認証にOAuth2を追加）
Anthropic公式のベストプラクティスでも、コミットメッセージの規約を含む「リポジトリエチケット」はCLAUDE.mdの推奨カテゴリとして挙げられています。
プレフィックス（feat:, fix:, chore:, docs:）は英語のまま、本文は日本語で書く。この組み合わせにすると、git logの視認性と日本語チームでの扱いやすさを両立できます。
コミットメッセージの形式は全プロジェクトで統一したい典型的な個人設定なので、グローバルCLAUDE.mdに置く正当性が高い項目です。
確認なしに自動コミット・自動pushしない
Claude Codeはタスクの完了時に、こちらが頼んでいないのにコミットやpushを行うことがあります。意図しないコミットがヒストリーに混ざるのは困りますし、まだレビュー前のコードがpushされるのはもっと困ります。
Anthropic社内のRL Engineeringチームも、テストの実行方法やコミットの手順といった具体的なワークフローをCLAUDE.mdに明記することで、一貫性を確保していると報告しています。
4. 禁止事項
禁止事項を書くときに意識しておきたいのが、Shrivu Shankarの指摘する「Neverだけ言うのではなく、代替案も示す」という原則です。禁止だけだとClaudeが行き詰まってしまうことがあるためです。
今回のテンプレートでは、代替行動が自明なもの（「勝手にしない」→「確認してからする」）に限定しているので、明示的な代替案の記述は省略して行数を節約しています。代替行動がわかりにくい禁止事項を入れる場合は、必ずセットで書くようにしてください。
README・ドキュメントを勝手に生成・変更しない
Claudeはタスクを完了したあと、「ついでに」READMEを更新したり、新しいドキュメントファイルを生成したりすることがあります。READMEの内容やフォーマットは人間が管理したいことがほとんどです。勝手に書き換えられると、プルリクエストのレビューで余計な差分が増えてしまいます。
Anthropic公式も、Claudeが「やりすぎる」パターンをCLAUDE.mdで抑制することを推奨しています。
テストコードを確認なしに削除・コメントアウトしない
これは実際に遭遇するとかなりヒヤッとする問題です。実装を変更した結果テストが通らなくなったとき、Claudeが「テストのほうを直す」のではなく「テストを消す」ことで対処するケースがあります。
Anthropic社内のRL Engineeringチームも、テスト実行に関する具体的なアンチパターンをCLAUDE.mdに追加し、一貫性が大幅に改善したと報告しています。
既存の動作するコードを理由なくリファクタリングしない
「ついでにリファクタリングしておきました」は、Claudeの最もよくある「やりすぎ」のひとつです。頼んでいない箇所をリファクタリングされると、レビューの差分が膨らむだけでなく、意図せずバグを混入するリスクもあります。
なぜこれ以上書かないのか：削った項目とその理由
テンプレートに「何を書いたか」と同じくらい大事なのが、「何を書かなかったか」です。他のテンプレートではよく見かけるのに、あえて入れなかった項目について説明します。
console.logをデバッグ後に残さない
ESLintのno-consoleルールで検出できます。HumanLayerの「リンターで強制できるルールはCLAUDE.mdに書くな」という原則そのものです。
1関数20行以内 / named importを使う
どちらもリンターの設定で制御可能です（max-lines-per-function、no-default-export等）。プロジェクトの.eslintrcで管理すべき領域であり、グローバルCLAUDE.mdに書くとトークンの無駄になります。
ultrathinkで計画を立てる → 削除
特定のthinkingモードの指定は、セッションごとの判断で決めればよいことです。すべてのセッションに強制するほどではなく、必要なときにプロンプトで指示すれば十分です。
1コミット1論理変更 → 削除
Claudeはデフォルトでこれを概ね守ってくれます。わざわざ書く必要性が低く、Anthropic公式も「Claudeがデフォルトでできることを重複して指示しない」よう推奨しています。
※ただし、上記は好みの問題や実際に使ってみてうまくいかないこともあると思うので、プロジェクト横断をして守らせたい制約事項が見つかったら、臨機応変に追記しCLAUDE.mdを育てていくことをおすすめします。
さらに最適化したい場合：Progressive Disclosureの活用
これでもまだ多いと感じる方、あるいは状況に応じて詳細な指示を出し分けたい方には、Progressive Disclosure（段階的開示）パターンが有効です。
Progressive Disclosureはその名の通り、すべての情報を最初から見せるのではなく、必要になったタイミングで必要な分だけ提示するという考え方です。
最近話題のAgent Skillsも、まさにこの思想で設計されています。SkillはSKILL.mdに手順やスクリプトをまとめておき、Claudeがタスクの内容を見て関連するSkillだけを動的にロードする仕組みです。グローバルCLAUDE.mdでも同じ発想が使えます。
グローバルCLAUDE.mdを「索引」として使い、詳細は~/.claude/rules/ディレクトリの別ファイルに分離します。rules/内のファイルにはYAMLフロントマターでglobパターンを書けるので、該当するファイルを操作するときだけ自動でロードしてくれます。
<!-- ~/.claude/rules/typescript.md -->
---
globs: "**/*.ts,**/*.tsx"
---
# TypeScriptルール
- satisfiesをasより優先する
- anyは使わずunknownを使う
おわりに
グローバルCLAUDE.mdのベストプラクティスを調べてみて分かったのは、「書くべきこと」よりも「書かなくてよいこと」を見極める方が難しいということです。
いろいろな指示や条件を足していくのは簡単ですが、1つ指示を追加するたびにトークンの使用量が増えたり、他の指示の効きが薄くなってしまう可能性があります。CLAUDE.mdに指示を入れる際は、グローバル、プロジェクト関わらず「リンターでも代替できないか？」など本当にその指示が必要かを吟味するようにしましょう。
内容は、使っている言語やフレームワーク、チームの文化によって最適解は変わりますし、Claude Code自体もアップデートで挙動が変わっていきます。大事なのは、「毎セッション読み込まれるコストに見合う指示か？」という判断基準を持っておくことだと思います。
この記事が、CLAUDE.mdを見直すきっかけになれば嬉しいです。
参考記事
一次情報（Anthropic公式）
| 情報源 | URL |
|---|---|
| 公式メモリドキュメント | https://code.claude.com/docs/en/memory |
| 公式ベストプラクティス | https://www.anthropic.com/engineering/claude-code-best-practices |
| 社内利用レポート（PDF） | https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135ad8871e7658.pdf |
二次情報
| 情報源 | URL |
|---|---|
| HumanLayer執筆ガイド | https://www.humanlayer.dev/blog/writing-a-good-claude-md |
| Shrivu Shankar詳細解説 | https://blog.sshh.io/p/how-i-use-every-claude-code-feature |
| SFEIR Institute Tips | https://institute.sfeir.com/en/claude-code/claude-code-memory-system-claude-md/tips/ |
| SFEIR Institute Tutorial | https://institute.sfeir.com/en/claude-code/claude-code-memory-system-claude-md/tutorial/ |