重要なポイント
Claude Codeでは、新しいチャットは毎回空のコンテキストから始まります。CLAUDE.mdは、Claudeがすべての新しいセッションに自動で読み込む唯一のファイルです。これがないと、エージェントは初出勤のインターンのように、あなたの事業やスタイル、ルールを何も知りません。ファイルがあれば、2年目の社員のように働きます。
以下は、私が数十のプロジェクトで試したテンプレートです。ファイルは約80〜120行に収まり、Anthropicが目安として推奨する200行未満に収まります。このテンプレートを使うと、エージェントは最も筋の通った結果を出します。
```markdown
# [PROJECT NAME] - project navigation
This document is the project map. Read it at the start of every session
to understand where things are and how to work with them.
## What this project is
**[NAME]** - [one sentence: what it is and who it’s for].
[1-2 sentences: what problem it solves and how].
Details are in `business/INDEX.md`.
## Reading order at the start of every session
1. `about-me/INDEX.md` - who I am and how I think
2. `business/INDEX.md` - what we do (product, audience, economics)
3. `CLAUDE.md` (this file) - repo rules, tools, navigation
4. Task area: the relevant file from `business/`, `plans/`,
`mastery/` or the feature folder in the code
Principle: layer 1 (about me) comes before layer 2 (business) for a reason.
First, **who** is thinking, then **about what**.
## Repository structure
[NAME]/
├── CLAUDE.md ← this file, navigation
├── about-me/ ← digital projection of you (how you think, what you value)
│ └── INDEX.md
├── business/ ← the business’s second brain
│ ├── INDEX.md
│ ├── audience/ ← customer profile
│ ├── products/ ← products, prices
│ ├── goals/ ← goals, metrics
│ └── economics/ ← unit economics, revenue
├── plans/ ← technical plans (one plan = one feature)
├── retrospectives/ ← reflections after each session
└── (project code)
### Where to find things
| What you need | Where to look |
|---|---|
| Why we’re building the project, and for whom | `business/INDEX.md` |
| Target customer, pains, desires | `business/audience/` |
| Product, plans, prices | `business/products/` |
| Goals and metrics | `business/goals/` |
| Economics | `business/economics/` |
| Technical plans | `plans/` |
## Tools
[INSERT TOOLS - for example: Next.js 14, TypeScript, Tailwind CSS, Prisma + PostgreSQL].
## Repo rules
1. Never hardcode dynamic data (prices, dates, figures) -
get everything from files in `business/` and the LIVE marker.
2. Don’t publish without my explicit command.
3. Before `git push`, run `npm run build` and check that it
builds without errors or warnings.
4. Add files by name with `git add`. Never use `git add .` or `git add -A`.
5. Don’t read `.env` in full. To check a variable, use
`grep "^VAR=" .env`.
## Big features = a plan in `plans/`
Any task lasting more than an hour must be written up as a plan in the `plans/` folder:
1. Filename: `YYYY-MM-DD-feature-name.md`.
2. Divide the plan into phases. Mark each phase `[ ]` or `[x]`.
3. At the end of the plan, add a summary: whether it was fully implemented and what remains.
## End-of-feature cycle
After each feature is complete, go through these 5 steps:
1. Find errors → prove them with an example → fix them.
2. What was missed (edge cases, input validation, error handling).
3. Is this a real problem in our project? Check `business/` and `plans/`.
4. Take a fresh look: reread the diff as if you’re seeing it for the first time.
5. Security review. Especially: personal data and third-party materials.
## End-of-session reflection
In `retrospectives/YYYY-MM-DD_short-name.md`, record:
1. What the task was.
2. How it was solved.
3. Whether it was solved - yes / no / partially.
4. What could have been done better.
5. What was learned about the user or project.
## Language
Always respond in the user’s preferred language. Use hyphens only, not em dashes.
```
Claudeにこのテンプレートを使ってプロジェクト用のファイルを自動入力させるには、このプロンプトを渡してください。Claudeはコンテキストを読み、角括弧内の項目を埋めます。
プロンプト：プロジェクト用のCLAUDE.mdを埋める
```
Create a CLAUDE.md file at the project root using this template:
[INSERT THE ENTIRE TEMPLATE FROM ABOVE]
Proceed as follows:
Read about-me/INDEX.md and business/INDEX.md to understand the project context and me as the author.
Fill in all the square-bracketed fields in the template based on what you find in those folders.
If some information is missing, ask me clarifying questions one at a time, with 3-4 answer options.
Aim to keep the resulting CLAUDE.md under 200 lines. If it is longer, review duplication and move detailed procedures to linked files. Preserve essential planning, reflection, and repo rules, then test them on representative tasks.
Show me the final file and ask what should be revised.
Always respond in the user’s preferred language.
```
重要なポイント
Claude Codeの`/init`コマンドは、プロジェクトをスキャンしてツールやビルドコマンドを列挙し、基本的なCLAUDE.mdを自動で作成します。よい出発点ですが、事業のコンテキストや原則がなければ、技術的で一般的なファイルになります。最初の手順として`/init`を使い、その後、手動で追加してください。
プロンプト：CLAUDE.mdのストレステスト
```
I have a CLAUDE.md. Tomorrow I’ll be building a feature based on it.
Your task is to stress-test it. Find 10 reasons we could potentially fail:
where CLAUDE.md is ambiguous and you, as an agent, might misunderstand it
where there are gaps that would force you to make things up
where rules contradict one another
where I overestimate how much can be done in one day
where I underestimate things (this is even worse)
Don’t hold back. Criticize it harshly. I want to find these issues now, not in production.
At the end, give me a list of specific changes: what to change and how, so these problems don’t happen.
```
Claude Codeの各ウィンドウでは、いくつかの層がコンテキストに読み込まれます。Anthropicのシステムプロンプト（数万トークンと推定）、CLAUDE.md、`@`でインポートしたファイル、MEMORY.md、現在のチャット履歴、Claudeが開くファイルの内容です。すべてをモデルのコンテキスト（Sonnetは200Kトークン、Opusは1Mトークン）に収める必要があります。
CLAUDE.mdが大きいほど、現在の作業に使える領域は少なくなります。1,000行のファイルは約8,000トークンで、各セッションに繰り返し読み込まれます。（私の経験では）1日あたり「重い」プロンプトが約10〜12回のProサブスクリプションでは、利用可能量が4分の1減ります。
コストだけが問題ではありません。指示が長い、無関係、または互いに矛盾する場合は、遵守の質が落ちることがあります。確実に従える指示数に普遍的な基準はありません。重要なルールを使う代表的なタスクをいくつか試し、失敗を記録して、対象を絞った編集の前後で比較してください。
私のCLAUDE.mdには、短いセクションがあります。
```markdown
## Self-learning
At the end of every session, check:
- Have I learned anything new about the user or how to work with them?
- Did I break any rule that should now be recorded?
If so, create or update a file in `about-me/feedback/` in this format:
Rule (one-line rule) → Why (why it was added)
→ How to apply (when it applies).
I don’t write the rules by hand - I say, “not like that, because this is how,”
and you put it into a file.
```
このセクションをCLAUDE.mdに追加すると、Claudeは各セッションの最後に「新しく記録する価値のあることはありましたか」と尋ねるようになりました。あれば、ルール案を提示し、私が補足してからファイルを作成します。
この方法で2か月間作業した結果、`about-me/feedback/`に2ダース以上のファイルができました。特定の間違いから学んだルールです。各ファイルは「ルール→理由→適用方法」という形式の1ページです。このフォルダーは、私個人の好みやタブーを記録する「第2の記憶」になりました。
間違いがルールになることで繰り返されなくなり、ルール同士が蓄積して互いを補強します。6か月後には、1か月の休みから戻った私よりも、Claudeのほうが私のプロジェクトをよく知っています。
## 法務、マーケティング、運用のルールをCLAUDE.mdに追加する方法
プロンプト：チェックリストに沿ってCLAUDE.mdを監査する
```
Read my CLAUDE.md and compare it with the checklist below. For each item, say: yes / no / partly, and what specifically to fix.
Checklist:
Compact enough for the task; review around 200 lines without treating it as a hard ceiling
Project description in the first 5 lines
Tools listed explicitly
Repository structure diagram included
“Question → file” table included
Principles section with rules included
Every rule is specific and verifiable
“Update at the end of the session” rule included
“Reflect at the end of the session” rule included
Critical prohibitions included in .claude/settings.json
No duplicates of the same rule in different sections
No dangling links to files that no longer exist
After the audit, give me a list of specific changes that will make the file living.
```