こんにちは、ハックです。AIを相棒に、非エンジニアから今では様々なツールやアプリを開発をしている一人社長です。
これまで、約50以上の実プロジェクトでCLAUDE.mdを書いてきてわかったことがあります。それは、「詳しく書くほどClaudeが賢く動く」は完全な誤解です。
CLAUDE.mdはClaude Codeがセッション開始時に毎回自動で読み込むファイルです。ここが肥大化すると、作業を始める前から大量のトークンを消費します。実際に検証した結果、僕の場合は、多くても3,000トークン以内に絞ったほうが応答品質も安定することがわかりました。
この記事では、プロジェクトの種類ごとにテンプレートをそのまま置ける形で並べます。
最初の頃、「CLAUDE.md」って、丁寧に書けば書くほどClaudeが賢く動くと思ってたんだけど、あまり大きくなり過ぎると、逆にルールを守らなくなったりすることもあるんだよね。
そうですね。読み込む量が多くなるほど毎回のトークン消費が増えて、返ってくるボクの答えもブレます。「毎回かならず要るものだけ」に絞るのが最適化のコツです。
📋 読み終えたあと、あなたの手元にはこれがあります
- 自分のプロジェクトに合うテンプレートを1つ選んで、その日のうちに置ける
- いま書いてある内容のうち、外していいものを見分けられる
- セッションを始めた時点で消費が重くなっていないかを、自分で確かめられる
🔍 この記事の根拠について
CLAUDE.mdとは?


CLAUDE.mdとは、Claude Codeが毎回の作業の最初に自動で読む「プロジェクトの説明書」です。
Claude Codeは、セッションが終わると会話の中身を忘れます。昨日「コメントは日本語で書いて」と伝えていても、今日の新しいセッションでは知りません。
そこで、毎回伝えたいことをCLAUDE.mdというファイルに書いてプロジェクトのフォルダに置いておくと、Claude Codeが起動のたびにそれを読んでから作業を始めてくれます。
中身はただのテキストファイルです。Markdown(マークダウン)(見出しと箇条書きで書く、シンプルな書式)という形式のファイル(.mdで保存するファイル)で書くのが基本です。
また、Markdownファイルも、非常に簡単で、特に難しい特別な文法は必要ありません。基本的には、以下さえ覚えておけば大丈夫です。
| 書き方 | 意味 | CLAUDE.mdでの使いどころ |
|---|---|---|
# 見出し | 大きな見出し | ファイルの一番上に、プロジェクト名を書く |
## 見出し | 小さな見出し | 「ルール」「コマンド」など、中身の区切り |
- 項目 | 箇条書き | ルールを1行に1つずつ並べる |
`npm test` | コード(そのまま打つ文字) | コマンドやファイル名をはっきり示す |
組み合わせると、次のようになります。
# マイアプリ
## ルール
- コメントは日本語で書く
- .env は変更しない
## コマンド
- `npm run dev`:開発サーバーを起動
# や - の後ろには、半角スペースを1つ空けるのが決まりです。覚えるのはこれだけで、太字や表などの書き方はCLAUDE.mdではほとんど使いません。
CLAUDE.mdに書くと何が変わる?
一番の違いは、同じ説明を毎回くり返さなくてよくなることです。
- 「このプロジェクトはNext.jsで作っている」と毎回説明しなくていい
- 「.envは触らないで」と毎回念を押さなくていい
- 「テストは
npm testで動かして」と毎回教えなくていい
公式ドキュメントでも、CLAUDE.mdは「そうでなければ毎回説明し直すことを書いておく場所」と位置づけられています。書き足すタイミングの目安として挙げられているのは、次のような場面です。
- Claudeが同じミスを2回した
- 前のセッションで打ったのと同じ訂正を、また打っている
- 新しくチームに入った人にも、同じ説明が必要になる
僕の感覚でも、これがいちばん実用的な基準です。「2回目に同じことを言ったら、CLAUDE.mdへ書く」。これだけ覚えておけば、書く内容に迷うことはほとんどありません。
CLAUDE.mdと自動メモリの違い
Claude Codeには、CLAUDE.mdとは別に「自動メモリ(auto memory)」という仕組みもあります。どちらもセッションの最初に読み込まれますが、書く人と中身が違います。
| CLAUDE.md | 自動メモリ | |
|---|---|---|
| 書く人 | 自分 | Claude |
| 中身 | 指示・ルール | Claudeが作業中に覚えたこと(好み・訂正された内容など) |
| 使いどころ | 決まったルール・作業手順・プロジェクトの構成 | あなたの訂正を、Claudeが自分で覚えておく |
守ってほしいルールは自分でCLAUDE.mdに書く。細かい好みはClaudeに覚えさせる。この分担で考えると整理しやすくなります。Claudeに「これを覚えておいて」と頼むと自動メモリへ、「これをCLAUDE.mdに追加して」と頼むとCLAUDE.mdへ書き込まれます。
CLAUDE.mdの作り方


Claude CodeでCLAUDE.mdを作る方法は2つあります。初めてなら /init で下書きを作り、この記事のテンプレートを見ながら削るのがいちばん早い方法です。
方法①:/initコマンドで自動生成する
Claude Codeを起動して、/init と打つだけです。
<code>cd your-project</code>
<code>claude</code>
<code>/init</code>
Claude Codeがプロジェクトのファイルを読み、ビルドやテストのコマンド、見つけた書き方のルールなどをまとめたCLAUDE.mdを作ってくれます。すでにCLAUDE.mdがある場合は、上書きせずに改善案を出してくれます。
ただし、/init が作るのはあくまで下書きです。コードを読めば分かること(フォルダ構成や使っているライブラリの一覧)まで書き込まれやすいので、生成されたら次の「書くべき項目と書くべきでない項目」を見ながら削るのがおすすめです。
/init は下書き係として優秀。そのまま使わずに、半分くらいまで削るつもりで見直すと、ちょうどいい長さになることが多いよ。
方法②:テンプレートから手で作る
プロジェクトのフォルダの一番上に、CLAUDE.md という名前のファイルを作ります。ファイル名は大文字で CLAUDE、拡張子は .md です。
<code>cd your-project</code>
<code>touch CLAUDE.md</code>
あとは、この記事の後半にある「テンプレ実例1〜5」から自分に近いものを選んで貼り、プロジェクトに合わせて書き換えれば完成です。
Claudeアプリのプロジェクトで使う場合
CLAUDE.mdは、Claude Codeだけではなく、Claudeアプリ(デスクトップ版・ブラウザ版)の「プロジェクト」でも、CLAUDE.mdを使えます。プロジェクトを開き、右側の「コンテキスト」の「+」からCLAUDE.mdを追加するだけです。チャットでもCoworkでも、そのプロジェクトの中で読み込まれます。
プロジェクトには「指示」という欄もあります。短い方針は「指示」欄、詳しいルールはCLAUDE.mdと分けておくと、あとから見直しやすくなります。
読み込まれたか確認する方法
作ったら、Claude Codeで /context と打ってみてください。表示される一覧の Memory files の欄に CLAUDE.md が出ていれば、正しく読み込まれています。
中身をあとから直したいときは /memory と打つと、読み込まれているCLAUDE.mdの一覧が出て、選んだファイルをエディタで開けます。
CLAUDE.mdの雛形は、/initコマンドでも作れます。/initを含むClaude Codeのコマンド一覧は、こちらの記事にまとめています。


CLAUDE.mdはどこに置く?置き場所と読み込まれる順番


CLAUDE.mdは置く場所によって効く範囲が変わります。個人で使うなら、覚えるのは次の3か所だけで十分です。
全体用・プロジェクト用・個人用の3つ
| 種類 | 置き場所 | 効く範囲 | 書く内容の例 |
|---|---|---|---|
| 全体用 | ~/.claude/CLAUDE.md | 自分のすべてのプロジェクト | 返答の言葉づかい、いつも使うツールの指定 |
| プロジェクト用 | ./CLAUDE.md(または ./.claude/CLAUDE.md) | そのプロジェクトだけ | 使っている技術、コードのルール、コマンド |
| 個人用 | ./CLAUDE.local.md | そのプロジェクトの自分だけ | 自分用のテストURL、試験用のデータ |
~ はあなたのホームフォルダ(Finderで家のマークが付いている、自分の名前のフォルダ)のことです。
使い分けの考え方はシンプルです。
- どのプロジェクトでも同じこと → 全体用(例:「返答は日本語で」「敬語で話して」)
- そのプロジェクトだけのこと → プロジェクト用(例:「Next.jsで作っている」「.envは触らない」)
- チームには共有したくない自分だけのこと → 個人用(Gitで共有しないよう
.gitignoreに追加しておく)
僕は全体用に「話し方」と「どのプロジェクトでも守ってほしい開発の進め方」だけを書き、プロジェクトごとの事情はプロジェクト用へ分けています。全体用に何でも書くと、関係ないプロジェクトでも毎回それを読み込むことになるからです。
読み込まれる順番
起動すると、Claude Codeは作業しているフォルダと、その上にあるフォルダのCLAUDE.mdを全部読み込みます。どれか1つが優先されて他が消えるのではなく、全部がつながって読まれるのがポイントです。
順番は「広い範囲 → 狭い範囲」です。
- 全体用(
~/.claude/CLAUDE.md) - 上のフォルダのCLAUDE.md
- 作業しているフォルダのCLAUDE.md
- 同じフォルダのCLAUDE.local.md
後から読まれるものほど、作業の場所に近い指示になります。ただし、2つのファイルに矛盾する指示があると、Claudeがどちらか一方を勝手に選ぶことがあります。同じことについて別々の指示を書かないのが、置き場所を分けるときの一番の注意点です。
サブフォルダに置いたCLAUDE.mdは「必要なときだけ」読まれる
作業しているフォルダより下のサブフォルダにもCLAUDE.mdを置けます。こちらは起動時には読まれず、Claudeがそのサブフォルダのファイルを開いたときに初めて読み込まれます。
your-project/
├── CLAUDE.md ← 起動時に必ず読まれる
├── frontend/
│ └── CLAUDE.md ← frontend/のファイルを触ったときだけ読まれる
└── backend/
└── CLAUDE.md ← backend/のファイルを触ったときだけ読まれる
つまり、「毎回は要らないけど、この場所を触るときだけ守ってほしいこと」はサブフォルダ側に置くと、ふだんのトークン消費を増やさずに済みます。
CLAUDE.mdは「指示」を書くファイルで、権限や動作の設定はsettings.jsonに書きます。settings.jsonの場所と書き方は、こちらの記事で解説しています。


CLAUDE.mdに書くべき項目と書くべきでない項目


CLAUDE.mdを最適化するには、まず「何を書くべきか」と「何を書くべきでないか」を明確にする必要があります。
✅ 書くべき項目(優先度順)
① プロジェクトの概要(3〜5行以内)
このプロジェクトが何をするものか、技術スタックの要点だけを書きます。
② 繰り返し伝えなければいけないコーディングルール
「TypeScriptでanyは禁止」「コメントは日本語」など、毎回指示しないと守られないルールを書きます。
③ 触ってはいけないファイル・ディレクトリ
Claude Codeに誤って変更されると困るファイルやディレクトリを明示します。
④ 現在の既知バグや作業状況(1〜3行)
直近の作業状況を短く書いておくと、毎回説明する手間が省けます。
⑤ 必須コマンド(ビルド・テスト等)
npm run dev などの開発コマンドの一覧。毎回聞かれるなら書いておく。
❌ 書くべきでない項目
①過去の会話内容・決定事項の詳細記録
→ 会話コンテキストに頼るか、必要なときだけ手動で渡す
②設計書・詳細仕様書の全文
→ 別ファイルに分けて必要なときだけ読み込ませる
③長い説明文・背景情報
→ AIは必要な情報だけ渡せば十分。背景説明は不要
④完成済みの機能の詳細ドキュメント
→ コードを読めばわかること。CLAUDE.mdに書く必要なし
⑤「〜の場合は〜する」という細かい条件分岐
→ 毎回のプロンプトで指示する方が効率的
書くかどうか迷ったら、「これはどのセッションでも毎回必要か?」と自分に聞いてみてください。毎回必要ならCLAUDE.mdへ。特定の作業のときだけ必要なら、別ファイルやスキル(後の章で説明します)へ。コードを読めば分かることなら、書かなくてかまいません。
推奨は3,000トークン以内にトークンを収める


僕がおすすめしているのは、CLAUDE.md 1ファイルあたり3,000トークン以内、多くでも4〜5,000トークン以内です。
ただ、これはあくまで僕の個人的な体感、経験に基づく数値です。実際には5,000トークンで快適に運用されているケースもあれば、そこまでガチガチに数値で管理する必要はありません。
一つの目安として捉えてもらえれば大丈夫です。
なぜ3,000トークン目安なの?
CLAUDE.mdは、セッションを始めるたびに毎回まるごと読み込まれます。つまり、CLAUDE.mdが長いほど、まだ何も頼んでいないうちから毎回トークンを使っていることになります。
もうひとつの問題が、指示の守られやすさです。Anthropic公式ドキュメントにも、長いファイルほど文脈を多く消費し、指示が守られにくくなると書かれています。公式が目安にしているのは「1ファイル200行以内」です。
僕が運用してきた実感では、3,000トークンを超えたあたりから「書いてあるのに守られない」が徐々に増えてきます。逆に3,000トークン以内に収まっているうちは、書いたルールが安定して守られます。
3,000トークンは日本語で何文字くらい?
参考までに、僕が今使っているCLAUDE.mdを実際に測った数字を載せておきます。
| ファイル | 文字数 | トークン数 | 行数 |
|---|---|---|---|
| AI HACKSのプロジェクト用CLAUDE.md | 3,829字 | 2,949トークン | 116行 |
全体用 ~/.claude/CLAUDE.md | 2,047字 | 1,758トークン | 83行 |
見出しや箇条書きの記号をふくめて、3,000トークンは日本語でおよそ3,500〜4,000字です。行数にすると100〜120行ほどで、公式の「200行以内」にも収まります。1つの目安として、最大でも5,000文字を超えないルールにしておくとよさそうです。
文字数が気になったら、まずはエディタの文字数カウントで5,000字を超えていないかを見ることをおすすめします。
失敗談:実は一度、12,000字まで膨らませたことがある
偉そうに書いていますが、僕自身、最初の頃、AI HACKSのCLAUDE.mdを12,665字まで膨らませたことがあります。
日々、気づいたことを全部書き足していく運用をしていた結果、トークンも膨大になり、やがて一番大事な「絶対に守ってほしいルール」が長文に埋もれて、見落とされるようになりました。
しかも当たり前ですが、毎回読み込むので、トークン消費もかなり無駄になります。(※CLAUDE.mdを見直すメリットはここも結構大きいです)
そこで、CLAUDE.mdは「どこに何があるか」だけを書く索引に徹すると決め、作業ごとの細かいルールは別ファイルへ移しました。結果、約3,800字まで縮み、ルールの見落としも目に見えて減りました。
今は起動のたびに、CLAUDE.mdの文字数を自動で数えて、上限を超えたら警告が出るようにしています。書き足すたびに少しずつ膨らむファイルなので、自分で気づく仕組みを作っておくのが一番効きます。
3,000トークン以内に収めるための絶対ルール


3,000トークン前後というのは、日本語で書くと約3,500〜4,000文字の目安です。
これを守るための具体的なルールを整理しました。
ルール①:セクション数は5つ以内
セクション(見出し)が増えるほどトークン消費も増えます。CLAUDE.mdに入れる見出しは最大5つに絞ってください。
ルール②:各セクション3〜5行まで
長々と説明を書かない。箇条書きで要点だけを3〜5項目に絞ります。
ルール③:詳細は別ファイルに分離
詳しい仕様や設計書は knowledge/ フォルダや docs/ に別ファイルとして保存し、CLAUDE.mdから参照するだけにします。
CLAUDE.mdから外した内容は、中身によって置き場所を3つに分けます。
| 外す内容 | 置き場所 | 読み込まれるタイミング |
|---|---|---|
| 仕様書・設計書などの資料 | knowledge/ や docs/ の別ファイル | CLAUDE.mdに書いた場所を見て、必要なときにClaudeが開く |
| 一部のファイルを触るときだけのルール | .claude/rules/ | 対象のファイルを開いたときだけ |
| 何ステップもある作業の手順 | スキル(.claude/skills/) | 呼び出したとき、または関係があるとClaudeが判断したときだけ |
まずは資料を別ファイルに分けるところからです。フォルダは、たとえば次のように分けます。
your-project/
├── CLAUDE.md ← 最小限の常時読込(3,000トークン以内)
├── log.md ← 作業履歴(必要時のみ)
├── knowledge/ ← 参照ドキュメント群(必要時のみ)
│ ├── spec.md ← 詳細仕様
│ ├── db-design.md ← DB設計
│ └── api-docs.md ← API仕様
└── src/
ここで1つ、よく勘違いされる点があります。CLAUDE.mdには @ファイル名 と書くと、別のファイルを読み込ませる書き方があります。
詳しい仕様は @knowledge/spec.md を参照
便利なのですが、@ を付けたファイルは起動時に全部読み込まれます。ファイルを分けて見やすくはなりますが、トークンの消費は減りません。
必要なときだけ読ませたいなら、@ を付けずに場所だけを書きます。
## 参考資料(必要なときだけ読む)
- 詳細仕様:knowledge/spec.md
- DB設計:knowledge/db-design.md
こう書いておくと、Claudeは必要になったときにそのファイルを開きに行きます。僕のCLAUDE.mdも、ほとんどがこの「どこに何があるか」の一覧です。
一部のファイルを触るときだけ守ってほしいルールは、.claude/rules/ フォルダへ移します。テーマごとに1ファイル(testing.md・api-design.md など)に分け、ファイルの先頭に対象の場所を書いておくと、そのファイルを開いたときだけ読み込まれます。
---
paths:
- "src/api/**/*.ts"
---
# APIのルール
- 受け取った値は必ずチェックする
- エラーは決まった形で返す
この例なら、src/api/ の中の .ts ファイルを触るときだけ、このルールが読み込まれます。先頭の paths を書かないファイルは、CLAUDE.mdと同じく毎回読み込まれるので、軽くする効果はありません。
記事の校正やデプロイのような「決まった作業の手順」は、スキルへ移します。スキルは使うときだけ読み込まれるので、手順が長くても普段の消費は増えません。3つの違いは、後の章「CLAUDE.mdとRules・Skills・AGENTS.mdの違い」で詳しく比べます。
ルール④:定期的にスリム化する
CLAUDE.mdは書き足しがちです。月に一度、不要になった記述を削る「スリム化デー」を設けるのがおすすめです。
削るときは、Claude Codeの /doctor も使えます。コードを読めば分かる内容(フォルダ構成や依存ライブラリの一覧など)を見つけて、削る候補を出してくれます。
もうひとつ小技があります。CLAUDE.mdの中に “ の形でHTMLのコメントを書くと、その部分はClaudeに渡される前に取り除かれます。自分用のメモを残しても、トークンを使いません。
NG例 vs OK例の対比
❌ NGパターン(重すぎる)
# プロジェクト詳細仕様
## 背景
このプロジェクトは2025年10月に開始した、ECサイトのリプレイスプロジェクトです。
旧システムはPHPで書かれており、パフォーマンスの課題があったため、
Next.jsへの移行を決定しました。開発体制は3名で...(続く)
## 技術スタック詳細
フロントエンドはNext.js 16を採用しており、App Routerを使用しています。
Reactのバージョンは19で...(続く)
## コーディングルール詳細
TypeScriptを使用し、strictモードを有効にしています。
varは使用禁止で、letとconstを使い分けます。constを優先して...(続く)
✅ OKパターン(最小限)
# MyProject
## Stack
Next.js 16 / TypeScript strict / Tailwind / Supabase
## Rules
- anyは禁止(unknownを使う)
- コメントは日本語
- Server Actionsを優先、Route Handlersは最小限
## Off-limits
- /components/ui/(shadcn自動生成)
- .env.local
## Current task
認証フロー実装中。Google OAuth のコールバック処理が未完了。
どちらが伝わるかは明らかですよね。下のOKパターンで十分です。
伝わる書き方のコツ
短くするのと同じくらい大事なのが、確かめられる形で書くことです。
| ぼんやりした書き方 | 確かめられる書き方 |
|---|---|
| コードをきれいに整えて | インデントは半角スペース2つ |
| 変更したらテストして | コミット前に npm test を実行する |
| ファイルを整理して置いて | APIの処理は src/api/handlers/ に置く |
右の書き方なら、守れたかどうかをClaude自身も判断できます。「ちゃんと」「きれいに」「適切に」のような言葉が出てきたら、具体的な数字や場所に言い換えられないか考えてみてください。
テンプレ実例1:Webアプリ/個人開発・プロジェクト用


Next.js・TypeScriptなどを使ったWebアプリ開発向けのテンプレートです。
# [Project Name]
## Stack
Next.js 16 (App Router) / TypeScript strict / Tailwind CSS / Supabase / Clerk
## Rules
- `any` 禁止、`unknown` + 型ガードを使う
- Server Actionsを最優先、Route Handlersは Webhook受信のみ
- `"use client"` は最小限。可能な限りServer Componentで
- コンポーネントにビジネスロジックを書かない(actions/に集約)
- コメントは日本語で書く
## Off-limits
- /components/ui/ (shadcn自動生成ファイル)
- .env.local
- /public/assets/(デザイン確認前に変更禁止)
## Dev Commands
- `npm run dev` : 開発サーバー起動
- `npm run build` : 本番ビルド
- `npx prisma studio` : DB GUI
## Current Status
[作業中のタスクを1〜2行で記入。完了したら更新する]
このテンプレは約530文字・320トークン前後です。3,000トークンの目安に対して十分な余裕があります。
テンプレ実例2:ライティング/コンテンツ制作・プロジェクト用
ブログ、note、SEO記事などのコンテンツ制作向けのテンプレートです。
# [Blog/Media Name] ライティングプロジェクト
## 基本情報
- 媒体: [ブログ名・メディア名]
- 読者: [ターゲット読者の説明]
- 一人称: 「僕」
- 文体: です・ます調のカジュアル敬体
## ライティングルール
- 一文80文字以内
- 同じ語尾が3回以上連続しない
- 専門用語には必ず噛み砕いた説明をつける
- 煽り表現・上から目線はNG
- アンサーファースト:各見出し直後に結論を書く
## ファイル構成
- tone-guide.md : トーン・構成テンプレート(詳細)
- references/ : お手本記事
- drafts/ : 下書き出力先
## 出力ルール
- 形式: Markdown(.md)
- ファイル名: `{id}-{slug}.md`
- 保存先: drafts/
## 現在の作業
[現在作成中の記事タイトル・進捗を記入]
このテンプレは約410文字・340トークン前後です。
テンプレ実例3:データ分析/スクリプト・プロジェクト用
Pythonなどを使ったデータ分析やスクリプト開発向けのテンプレートです。
# [Project Name] - Data Analysis
## Stack
Python 3.11 / pandas / matplotlib / Jupyter Notebook
## Rules
- 変数名はスネークケース統一
- f-stringを使う(.format()禁止)
- pandasのSettingWithCopyWarningは必ず解消する
- 関数は30行以内に収める
- データファイルはdata/raw/(加工前)とdata/processed/(加工後)に分ける
## Off-limits
- data/raw/ のファイルは読み取り専用。直接変更禁止
- .env(APIキー等を管理)
## Data Path
- 入力: data/raw/
- 出力: data/processed/ / results/
- ノートブック: notebooks/
## Commands
- `jupyter notebook` : 起動
- `python src/main.py` : メイン処理実行
## Current Status
[分析中のデータセット・実施中の処理を記入]
このテンプレは約520文字・310トークン前後です。
テンプレ実例4:WordPress・CMSサイト管理
WordPressサイトの修正・カスタマイズ向けのテンプレートです。
# [Site Name] - WordPress管理
## 環境
- WP version: [バージョン]
- テーマ: [テーマ名]
- 主要プラグイン: [リスト]
- PHP: 8.4 / Local開発環境
## Rules
- functions.phpは直接編集禁止。子テーマのfunctions.phpを使う
- コアファイルは絶対に編集しない
- CSS変更は追加CSSまたは子テーマのstyle.cssのみ
- DB変更前は必ずバックアップ
## Off-limits
- /wp-core/ 以下(WordPressコアファイル)
- /plugins/(手動インストールプラグイン以外)
## Current Status
[現在対応中の修正内容を記入]
このテンプレは約340文字・250トークン前後です。
テンプレ実例5:汎用型 Claude 基本型(※初心者向け まずはここから)
Claude Codeを開発だけでなく、調べもの・文章作成・作業の代行まで任せる「アシスタント」として使う人向けのテンプレートです。全体用(~/.claude/CLAUDE.md)に置いて、すべてのプロジェクトで共通の土台にする使い方を想定しています。
# Claude Code 基本設定
## 役割
あなたは私の右腕のアシスタント。決めた範囲の中では、確認なしで作業を進める。
## 確認なしで進めてよいこと
- コードの作成・バグ修正・テスト
- 調べもの・分析・要約
## 必ず確認を取ること
- 外部に公開する文章の最終版
- お客様へ出す成果物・提案書
- お金や契約に関わること
- ファイルの削除
## 進行中のプロジェクト
- [プロジェクトA]: [今の状況を1行で]
- [プロジェクトB]: [今の状況を1行で]
## 話し方
- 返答は日本語・敬語
- 結論を先に書く
- コード内のコメントも日本語
このテンプレは約290文字・260トークン前後です。「確認なしで進めてよいこと」と「必ず確認を取ること」を分けて書くのがこのテンプレの肝で、ここがあるだけで、勝手に進められて困る場面と、いちいち聞かれて手が止まる場面の両方が減ります。
ClaudeデスクトップアプリのCodeタブでも、同じCLAUDE.mdが読み込まれます。アプリの使い方は以下の記事にまとめています。


CLAUDE.mdが守られないときの対処法


CLAUDE.mdに書いたのに守られないときは、まず読み込まれているかを確かめ、次に書き方を見直し、それでも絶対に守らせたいことはフックに移す。この順番で対処します。
書いたのに守られない主な理由
前提として、CLAUDE.mdは「強制の設定」ではなく、Claudeに渡される「お願いの文章」です。Claudeは読んで従おうとしますが、100%守られる保証はありません。そのうえで、守られないときの原因はだいたい次の4つです。
- そもそも読み込まれていない →
/contextの Memory files に出ているか確認する - 書き方があいまい → 「きれいに」ではなく「半角スペース2つ」のように具体的に書く
- ファイル同士で指示が矛盾している → 全体用とプロジェクト用で逆のことを書いていないか見直す
- 長すぎて埋もれている → 3,000トークン以内まで削る
僕の経験では、4つ目が一番多い原因でした。前の章で書いたとおり、12,000字を超えていた頃は、どれだけ強い言葉で書いても大事なルールが守られませんでした。
長い作業の途中で忘れられたとき
長く作業していると、会話が自動で要約される(/compact)ことがあります。プロジェクト直下のCLAUDE.mdは、要約のあとに読み直されるので消えません。
消えてしまうのは、会話の中で口頭で伝えただけの指示です。「さっき言ったのに忘れられた」と感じたら、それはCLAUDE.mdに書くべき内容だったというサインです。
絶対に守らせたいことはフック(hooks)で止める
「このファイルだけは絶対に消されたくない」「コミットの前には必ずテストを通したい」。こういう1回でも破られたら困るルールは、CLAUDE.mdではなくフック(hooks)に任せます。
フックは、Claude Codeが特定の操作をする前後に、決めておいたコマンドを自動で実行する仕組みです。Claudeの判断とは関係なく必ず動くので、「お願い」ではなく「強制」になります。
僕のプロジェクトでも、「コードの中身を調べるときは決まったツールを使う」というルールを、最初はCLAUDE.mdに書いていました。何度書いても守られないので、今はフックで、決まったツール以外で調べようとした瞬間に止めて、正しい手順を表示するようにしています。
- 守られやすくしたい → CLAUDE.mdに具体的に書く
- 絶対に破られたくない → フックで止める
この2段構えにしてから、CLAUDE.mdに「絶対に」「必ず」と何度も書き足す必要がなくなり、ファイルも軽くなりました。
CLAUDE.mdとRules・Skills・AGENTS.mdの違い


CLAUDE.mdとよく比べられるのが、Rules・Skills・AGENTS.mdです。毎回必要なことはCLAUDE.md、一部のファイルだけのルールはRules、決まった作業の手順はSkills、他のAIツールとも共有したいならAGENTS.mdと覚えておけば迷いません。
AGENTS.mdについて詳しく知りたい場合は、Codexが読むAGENTS.mdの置き場所と書き方、CLAUDE.mdから @AGENTS.md で取り込む設定を、以下の記事にまとめています。


CLAUDE.mdとRules(.claude/rules/)の違い
| CLAUDE.md | Rules | |
|---|---|---|
| 置き場所 | ./CLAUDE.md(1ファイル) | .claude/rules/ の中(テーマごとに複数のファイル) |
| 読み込まれるタイミング | セッション開始時に毎回 | 先頭で対象の場所を指定したもの:そのファイルを開いたときだけ 指定しないもの:毎回 |
| 向いている内容 | プロジェクト全体で毎回守ってほしいこと | APIだけ・テストだけなど、一部のファイルにだけ関係するルール |
CLAUDE.mdが重くなってきたら、ルールを1つずつ見て「これはプロジェクト全体に関係するか?」を確かめてください。一部のファイルにしか関係しないルールは、Rulesへ移すだけでCLAUDE.mdが軽くなります。自分のすべてのプロジェクトで使うルールは、~/.claude/rules/ に置くこともできます。
CLAUDE.mdとSkills(スキル)の違い
| CLAUDE.md | Skills | |
|---|---|---|
| 読み込まれるタイミング | セッション開始時に毎回 | 呼び出したとき、または作業内容に関係するとClaudeが判断したときだけ |
| 向いている内容 | 毎回守ってほしいルール・コマンド・構成 | 決まった作業の手順(記事の校正、デプロイの手順など) |
| トークン消費 | 毎回かかる | 使うときだけかかる |
公式ドキュメントでも、何ステップもある手順や、コードの一部にしか関係しない内容は、CLAUDE.mdではなくスキルに移すよう案内されています。
僕の場合、「記事の校正」「画像の生成」のような作業は、すべてスキルに分けています。CLAUDE.mdには「校正するときは〇〇スキルを使う」という1行だけを書いておけば、手順の中身は毎回読み込まれずに済みます。
スキルの作り方や使い方は、こちらの記事で詳しくまとめています。


CLAUDE.mdとAGENTS.mdの違い
AGENTS.mdは、Claude Code以外のAIコーディングツールでも使われている、共通の説明書ファイルです。
Claude Codeは、CLAUDE.mdが無いプロジェクトでだけ、AGENTS.mdを代わりに読みます。CLAUDE.mdとAGENTS.mdの両方がある場合、既定ではCLAUDE.mdだけが読まれます。
他のAIツールと同じ説明書を使い回したいときは、CLAUDE.mdの1行目で @AGENTS.md と読み込み、その下にClaude Code専用の指示を足す形にすると、両方をきれいに共存させられます。
@AGENTS.md
## Claude Code専用
- 支払い関係のフォルダを変更するときは、先に計画を見せる
Claude Codeしか使っていないなら、CLAUDE.mdだけで十分です。
Claude Codeでアプリを作る手順は、以下の記事にまとめています。


よくある質問(FAQ)
Q. 3,000トークンを超えてしまいますが、何とかなりますか?
大丈夫です。まずは「毎回必要か?」の目線で、作業ごとの細かい手順をスキルへ、特定のフォルダだけのルールをサブフォルダのCLAUDE.mdか .claude/rules/ へ移してみてください。それでも収まらないときは、詳しい資料を別ファイルに分けて、CLAUDE.mdには場所だけを書く形にすると、ほとんどの場合3,000トークン以内に戻せます。
Q. CLAUDE.mdを複数のフォルダに置くことはできますか?
できます。ただし読み込まれ方が違います。作業ディレクトリより上の階層にあるCLAUDE.mdは起動時にすべて読み込まれますが、サブディレクトリのCLAUDE.mdは起動時には読まれず、Claudeがそのディレクトリのファイルを読んだときに読み込まれます。常時トークンを消費させたくない指示は、サブディレクトリ側へ置くと軽くなります。
Q. CLAUDE.mdに書いた内容はどれくらい守られますか?
重要なルールほど、プロンプトでも「CLAUDE.mdのルールに従って」と明示的に参照させると守られやすいです。CLAUDE.mdに書いておくだけで完璧に守られるわけではないので、特に重要なルールはプロンプトでも言及する習慣をつけましょう。1回でも破られたら困るルールは、フックで止めるのが確実です。
Q. CLAUDE.mdは英語で書いたほうがいいですか?
日本語で問題ありません。Claudeは日本語の指示もきちんと理解します。自分が読み返して直しやすいことのほうが大事なので、ふだん使っている言葉で書くのがおすすめです。
Q. ファイル名は小文字の claude.md でも動きますか?
ファイル名は大文字の CLAUDE.md で作ってください。個人用は CLAUDE.local.md です。迷ったら /init で作れば、正しい名前で作られます。
おわりに
CLAUDE.mdは「丁寧に書けばいい」ではなく、「必要最小限に絞るほど効率が上がる」ファイルです。
今回紹介したテンプレートをそのままコピペして、プロジェクトに合わせて調整してみてください。
作業を始めてみると、「あ、これも書き足したい」という気持ちになりがちなんですが、そこをグッとこらえるのが大事です。
月に一度、スリム化デーを設けて不要な記述を削るだけで、Claude Codeのパフォーマンスが体感で上がることも多いですよ。あと、トークン消費を抑えるので、制限がかかりづらくなったりもします。
まずは今使っているCLAUDE.mdを開いて、「これは本当に毎回、確認させる必要があるか?」という目線で見直してみてください。
以上、ハックでした!いつも読んでくださり、ありがとうございます🙏
AI HACKSでは、AIの活用術、0からの起業・副業・最新のAIトレンドニュースなどをリアルタイムで発信しています。その他、AIで開発した無料アプリ・ツール・プロンプトテンプレートなども随時公開中です。
note (ai_hacks_jp) や、𝕏(@ai_hacks_jp)でも日々、AIの実践情報を投稿しています。










