CLAUDE.mdの雛形をコピペで作る｜最初の30行に何を書くか

「CLAUDE.md、作ったほうがいいらしい」とは聞く。でも、空のファイルを前にして手が止まる。何を書けばいいのか、誰も具体的な雛形を見せてくれないからです。

僕も最初はそうでした。とりあえず技術スタックを羅列して、注意書きを足して、気づけば200行。そして肝心の「ここは触るな」を、Claude Codeに平気で無視されました。

逆だったんです。長く立派なCLAUDE.mdより、短くて具体的な30行のほうが守られる。公式ドキュメントも「具体的で簡潔な指示ほど一貫して従われる」と明言しています。今日は、その30行に何を書くかを、コピペできる形で全部出します。

この記事の要点

• 最初のCLAUDE.mdは「プロジェクト概要・コマンド・触ってよい範囲・やってほしくない事・完了条件」の5項目だけでいい。
• 下に置いた雛形をコピペして、自分のスタックに合わせて単語を差し替えれば、その日から動く。
• CLAUDE.mdは「お願い」であって強制力はない。本当に止めたい操作はsettingsやhookで支える(→ 権限の実用レシピ)。
• 粒度の原則・何を消すかは別記事へ(→ CLAUDE.mdは「何を書かないか」で決まる)。
• 完璧な1枚を最初に作らない。最初の3タスクで使い、抜けを1行ずつ足して育てる。

そもそもCLAUDE.mdって何をするファイル？

Claude Codeは、セッションが変わるたびに記憶を失います。昨日「migrationsは触らないで」と伝えても、今日の朝には忘れている。毎回ゼロから説明し直すことになります。

その「毎回の説明」を1枚に固定しておくのがCLAUDE.mdです。公式のメモリのドキュメントによれば、CLAUDE.mdはセッション開始時に毎回読み込まれる指示書として扱われます。プロジェクトの前提・コマンド・ルールを、起動のたびに自動で頭に入れてくれる、という仕組みです。

置き場所はプロジェクトのルートにあるCLAUDE.md、または.claude/CLAUDE.md。チームで共有したいならGit管理に含めます。自分専用のメモはCLAUDE.local.mdに分けて、.gitignoreに入れておく。これも公式が示している使い分けです。

ひとつだけ、最初に釘を刺しておきます。CLAUDE.mdは「指示」であって「強制」ではありません。公式の言葉では context であって enforced configuration ではない。「本番にデプロイしないで」と書いても、許可すればツールは動きます。だから、本当に止めたい操作は別の仕組みで支えます。そこは後で触れます。

最初に書くのはこの5項目だけ

空のファイルを前に固まる原因は、「全部書かなきゃ」と思うからです。違います。最初は次の5項目で十分。これ以外は、必要になってから足せばいい。

項目	何を書くか	例
プロジェクト概要	何のプロジェクトで、技術は何か	Astro製のブログ、TypeScript
コマンド	開発・ビルド・検索の決まり文句	npm run dev、rg "語" src
触ってよい範囲	編集していい場所、ダメな場所	src/はOK、.envはダメ
やってほしくない事	勝手にやられると困る操作	削除・本番デプロイ・コミット
完了条件	「終わった」と判断できる状態	ビルドが通る、リンク健在

ポイントは、全部「YesかNoで確認できる」言葉にすることです。「品質を高く」「いい感じに」は、読めても検証できません。「npm run buildを実行する」「reports/を編集しない」「descriptionは120文字以内」。この粒度に落とすと、Claude Codeも人間も迷いません。

なぜこの5項目なのか。僕の経験では、事故が起きるのはだいたい「範囲」「禁止」「完了条件」の3つが曖昧なときだからです。概要とコマンドは道案内、残り3つが安全帯。最小構成でも、この5つがあれば足場として機能します。

コピペで使えるCLAUDE.mdの雛形

ここが本題です。まずは汎用の最小テンプレート。これをプロジェクトルートのCLAUDE.mdに貼って、自分のスタックに合わせて単語を差し替えてください。

# CLAUDE.md

## プロジェクト概要
- 何のプロジェクトか: （例）社内向けの在庫管理Webアプリ
- 技術スタック: （例）Next.js / TypeScript / Prisma / PostgreSQL
- メインのコード: src/
- 方針: 既存の書き方に合わせる。勝手に流儀を変えない。

## コマンド
- 依存インストール: npm install
- 開発サーバー起動: npm run dev
- ビルド確認: npm run build
- テスト: npm test
- 高速検索: rg "キーワード" src
- 変更確認: git status --short

## 作業ルール（触ってよい範囲）
- 編集する前に、必ず対象ファイルを読む。
- 変更は、頼まれた機能・ファイルの範囲にとどめる。
- .env、dist、自動生成物、無関係なファイルは編集しない。
- 親切心で周辺コードまでリファクタしない。やるなら先に提案する。

## やってほしくない事（先に聞く）
- ファイルやディレクトリの削除
- 本番環境へのデプロイ
- データベースのマイグレーション実行
- git push / commit / force push
- 依存パッケージの追加・更新

## 完了条件
- 頼まれたファイルが編集されている。
- npm run build が通る（通らないなら理由を書く）。
- リンクや設定が壊れていない。
- 最後のメッセージに「残っているリスク」を書く。

このまま使えますが、肝は「やってほしくない事」と「完了条件」です。ここを具体的に書くほど、勝手な暴走が減ります。逆に概要やコマンドは、最初は雑でも構いません。

長さの目安は、公式が「200行未満を目標に」としています。最初は30〜40行で十分。長くなってきたら、それは育ちすぎのサインです。

言語・フレームワーク別の差し替え例

スタックが違えば、コマンドと禁止事項が変わります。よく使う組み合わせの「コマンド」と「触らない場所」だけ抜き出しました。上の雛形の該当箇所を、これで置き換えてください。

Python / FastAPI なら、こう書きます。

## コマンド
- 仮想環境: python -m venv .venv && .venv\Scripts\activate
- 依存インストール: pip install -r requirements.txt
- 開発サーバー: uvicorn app.main:app --reload
- テスト: pytest -q
- 型チェック: mypy app

## 触らない場所
- .venv/、__pycache__/、alembic の自動生成リビジョン
- .env と secrets/ 配下

Go なら、テストとビルドの作法が中心になります。

## コマンド
- ビルド: go build ./...
- テスト: go test ./...
- 整形: gofmt -w .
- 静的解析: go vet ./...

## 作業ルール
- go.mod / go.sum を勝手に書き換えない。依存追加は先に相談する。
- 生成コード（*_gen.go、mocks/）は手で編集しない。

Rails なら、DBまわりの事故が一番怖いので、そこを厚くします。

## コマンド
- セットアップ: bin/setup
- 開発サーバー: bin/rails server
- テスト: bin/rails test
- Lint: bundle exec rubocop

## やってほしくない事（先に聞く）
- bin/rails db:migrate / db:rollback / db:reset の実行
- schema.rb の手編集
- config/credentials.yml.enc, config/master.key への変更

共通する考え方はひとつ。「自動生成されるもの」と「壊れると痛いもの」を禁止側に置く。これだけ意識すれば、どの言語でも応用が効きます。

実際に動かして確かめる：雛形を1コマンドで設置する

雛形をコピペするのもいいですが、その場で空ファイルを作って中身を流し込むと早いです。プロジェクトのルートで、次のbashを実行してみてください。最小のCLAUDE.mdがその場ででき、Gitで履歴も残せます。

# プロジェクトのルートで実行
cat > CLAUDE.md <<'EOF'
# CLAUDE.md

## プロジェクト概要
- 何のプロジェクトか: ここに1行で書く
- 技術スタック: ここに書く
- メインのコード: src/

## コマンド
- 開発サーバー起動: npm run dev
- ビルド確認: npm run build
- 高速検索: rg "キーワード" src

## やってほしくない事（先に聞く）
- ファイルの削除 / 本番デプロイ / git push / commit
- .env と無関係なファイルの編集

## 完了条件
- 頼まれたファイルが編集されている
- npm run build が通る
- 残っているリスクを最後に書く
EOF

# できたか確認して、Gitに載せる
git add CLAUDE.md && git status --short

Windowsでcatが使えない場合は、code CLAUDE.mdやnotepad CLAUDE.mdで開いて、上の雛形を貼るだけでも同じです。大事なのは、まず1枚を置いて、空ファイルの呪縛から抜けること。

もうひとつの手は、Claude Code自身に作らせる方法です。プロジェクトの中で/initを実行すると、コードベースを読んでビルドコマンドや構成を拾い、たたき台を生成してくれます。既にCLAUDE.mdがある場合は、上書きせず改善案を出す仕様です。ゼロから書くのが面倒なら、/initでたたき台を出してから、上の雛形に寄せて整えるのが速いです。

最小の1枚から育てる4ステップ

最初から完璧な規約を目指すと、まず続きません。次の順番で、薄く始めて太らせます。

1. 棚卸し：/initか手動で、今の構成・コマンドをざっと書き出す。
2. 削る：上の雛形に寄せて30行くらいに絞る。最初から盛らない。
3. 3タスクで使う：実際に小さい仕事を3つ頼み、Claude Codeが見落とした点を1行ずつ追記する。
4. 本当の境界を固定：削除・本番・コミットなど絶対に止めたい操作は、settingsやhook側で支える。

記事サイトなら、最初の3タスクは「1記事の更新」「内部リンク1本の修正」「OGP画像1枚の確認」くらいがちょうどいい。アプリなら「UI文言の修正」「単体テスト1本の追加」「ログ出力の改善」から。いきなり全面リファクタを任せるより、足場の効き目がはっきり見えます。

そして、追記したら理由を1行残す習慣をつけると効きます。たとえば 2026-06-07: 他言語ファイルの巻き込み事故を受けて編集範囲を限定 のように。理由が分かるルールは削られにくく、形だけの規約になりません。何を消すか・どこまで細かくするかの原則は、CLAUDE.mdは「何を書かないか」で決まるに切り分けてまとめました。

僕がやらかした、雛形づくりの失敗3つ

正直に書きます。最初のCLAUDE.mdは、ぜんぶ裏目に出ました。

ひとつ目は、願望リストにしてしまったこと。「品質を高く」「安全に」「読みやすく」。読めるけど検証できない一文を並べたら、Claude Codeは当然なにも変えませんでした。「descriptionは120文字以内」のように、機械でYes/Noを判定できる言葉に直したら、急に守られ始めました。

ふたつ目は、指示と設定を混同したこと。「git push禁止」とCLAUDE.mdに書いて安心していたら、普通にpushされました。前述のとおりCLAUDE.mdは強制力がない。本当に止めたい操作は、settingsのpermissions.denyやPreToolUseフックで止める。CLAUDE.mdは判断の補助、設定は実行のブレーキ、と役割を分けます。具体的な貼り付け例は権限の実用レシピに置きました。

みっつ目は、古いルールを残し続けたこと。Next.jsからAstroへ移ったのにnext buildが残り、Jestをやめたのにnpm testだけ残る。矛盾した指示があると、Claude Codeはどちらかを勝手に選びます。失敗した作業の直後に1行だけ直す。月1回の棚卸しより、その場の1行修正のほうが続きました。

よくある質問

Q. CLAUDE.mdはプロジェクトのどこに置けばいい？ A. プロジェクトのルートのCLAUDE.mdか.claude/CLAUDE.mdです。チームで共有するならGit管理に含め、自分専用のメモはCLAUDE.local.mdに分けて.gitignoreへ。全プロジェクト共通の好みは~/.claude/CLAUDE.mdに置けます。

Q. 何行くらいが適切？ A. 公式の目安は200行未満。最初は30〜40行で十分です。長くなったら、それは載せすぎのサイン。特定のファイル種別だけに効かせたい指示は.claude/rules/に逃がせます。

Q. CLAUDE.mdに書けば、危険な操作は本当に止まる？ A. 止まりません。CLAUDE.mdは context であって強制ではないので、許可すればツールは動きます。確実に止めたいなら、settingsのpermissions.denyかPreToolUseフックを使ってください。

Q. すでにCursorやAGENTS.mdを使っている。共存できる？ A. できます。Claude Codeが読むのはCLAUDE.mdなので、@AGENTS.mdという1行を書いてインポートすれば、両方のツールが同じ指示を共有できます。/initもAGENTS.mdや.cursorrulesを読み取って取り込みます。

Q. ゼロから書くのが面倒。楽な始め方は？ A. プロジェクト内で/initを実行すると、コードを読んでたたき台を作ってくれます。既存ファイルがあれば上書きせず改善案を出す仕様なので、安心して回せます。

まとめ：薄い1枚を、その日から

CLAUDE.mdは百科事典ではありません。次のセッションを迷わせないための、薄い作業板です。

最初に書くのは5項目だけ。プロジェクト概要、コマンド、触ってよい範囲、やってほしくない事、完了条件。上の雛形をコピペして、自分の単語に差し替えれば、もう動きます。完璧を目指して空ファイルの前で固まるより、30行を今日置くほうが、確実に前に進みます。

そのうえで、本当に止めたい操作はsettingsで支える。粒度や「何を消すか」は別記事へ。役割を分けて、薄く保つ。それが一番、長く続きます。

実際、僕のサイト更新で効果が大きかったのは、立派な規約ではなく「触ってはいけない場所」「検証コマンド」「完了条件」のたった3行でした。これだけで、他slugの誤編集も、descriptionの長文化も、CTAリンクの消し忘れも減りました。

雛形の数行を試して手応えがあったら、チェックリストや権限テンプレを集めた教材一覧もどうぞ。チームで権限・レビュー・導入ルールまで一気にそろえたいなら、研修・導入相談のほうが早いです。