Claude Code を新しいプロジェクトで立ち上げると、まず /init を打って CLAUDE.md を作る方が多いと思います。私もそうしています。ただ、生成された CLAUDE.md をそのまま使い続けて「思ったほど Claude が賢く動いてくれない」と感じた経験はないでしょうか。
私自身、4サイトの個人開発を Claude Code で回す中で何度かこの壁にぶつかりました。結論から言うと、/init の出力は「下書き」であって「完成品」ではありません。ここをきちんと磨き込むかどうかで、その後の数百回のセッションの質が変わってきます。
/init で生成された CLAUDE.md を実用レベルに引き上げるために、私が毎回実施している4つのステップを順番にご紹介します。テンプレ的な解説ではなく、実際の作業順とビフォーアフターの例を交えてお伝えしますので、今日のうちにそのまま手元で試していただけるはずです。
/init コマンドが本当にやっていること
/init は「プロジェクトを読み込んで CLAUDE.md を生成するコマンド」と言われがちですが、実態はもう少し限定的です。Claude Code はリポジトリ直下のファイル一覧、package.json などのマニフェスト、README.md の内容を斜め読みして、「このプロジェクトの典型的な作業手順」を要約したファイルを書き出します。
ここで重要なのは、/init が見ているのは書かれている情報だけということです。コードベースには書かれていない暗黙のルール（例：「PR は必ず main ではなく develop から切る」「DBマイグレーションは別 PR にする」）は当然反映されません。生成直後の CLAUDE.md は、誰が読んでも当たり障りのない「ビルドコマンドはこれです」「テストコマンドはこれです」という内容で埋まりがちです。
つまり /init の出力は、チームに新人が入ったときに渡す紙のオンボーディング資料くらいの粒度です。それ自体は無駄ではありませんが、Claude が「自分の代わりに判断する」ために必要な情報としては足りません。
ステップ1: 「あって当たり前のこと」を削る
最初にやるのは追加ではなく削除です。意外に思われるかもしれませんが、/init が出力した内容のうち、半分くらいは消したほうが Claude の動きが良くなります。
具体的には、以下のような項目はほぼ全削除して構いません。
- 「This project uses TypeScript and Next.js」のような技術スタックの紹介文（
package.jsonを見れば Claude は分かります） - 「ファイル構成」セクションの一般的な説明（
src/public/などの自明な階層） - ビルドコマンドの羅列（
npm run devのような標準的なもの）
CLAUDE.md は Claude が毎回読むファイルなので、自明な情報を載せておくとコンテキストウィンドウを浪費するだけです。私の経験では、生成された CLAUDE.md をまず3〜5割カットしてから後続のステップに進むと、Claude の集中力が目に見えて上がります。
# 生成直後の CLAUDE.md の行数を確認
wc -l CLAUDE.md
# 例: 180 lines
# 思い切って削った後
wc -l CLAUDE.md
# 例: 95 lines（半分弱でも十分）ステップ2: 「やってほしくないこと」を明記する
ここが一番効きます。Claude Code の挙動を制御したいなら、「こうしてください」よりも「これだけはやらないでください」を書いたほうが安定します。
たとえば私は、各サイトの CLAUDE.md にこういう項目を入れています。
## やってはいけないこと
- ワークスペース内の Git リポジトリで `git push` を直接実行しない
→ 権限問題が発生するため、必ず /tmp/repos/ で作業すること
- 既存ファイルを書き直すときに「全文書き直し」を提案しない
→ 必ず Edit ツールで最小差分のパッチを当てる
- API キーをコード例にハードコードしない
→ YOUR_API_KEY のようなプレースホルダーを使うこのセクションを書く前と後で、Claude が同じ間違いを繰り返す頻度が体感で半分以下になりました。「やらない」ルールは抽象的になりがちなので、必ず理由を一行で添えるのがコツです。理由が書いてあれば、Claude はエッジケースで自分で判断できます。
ステップ3: プロジェクト固有の判断基準を足す
/init には絶対書けない情報、つまり「あなた個人がこのプロジェクトをどう運営したいか」を入れていきます。私が実際に書いている例を挙げます。
- 「記事は必ず日本語版と英語版をセットで作成すること」（Dolice Labs の運用ルール）
- 「機能追加より既存機能の安定化を優先する」（このサイトの方針）
- 「テストは振る舞いベース。実装詳細をテストしない」（チーム合意事項）
- 「変更を入れる前に必ず
_backup/に当該ファイルをコピーする」（事故防止）
これらは全部、コードを読んでも分からない情報です。CLAUDE.md にあるかないかで、Claude の提案クオリティが大きく変わります。
書き方のコツは、判断基準を明示することです。「なるべく〜してください」ではなく「Aの場合は X、Bの場合は Y」のような分岐を書くと、Claude は迷わず動けます。
ステップ4: 実例で「型」を示す
最後のステップは、文章ではなくコード例・コミットメッセージ例・ファイル構成例で「型」を見せることです。
たとえば私は、CLAUDE.md の末尾に「お手本となる過去の作業例」を1〜2件貼り付けています。
## お手本: 良い作業例
### Issue #74 の対応（記事HTMLをassets分離）
- 問題: articles.json が62MiBを超えてWorker制限突破
- 対応: HTMLは public/content/ に個別ファイル化、JSONはメタデータのみ
- 学び: Cloudflare Workers の制約は「総バンドルサイズ」で効くため、
動的読み込みできるアセットは可能な限り分離する
この方針は他の容量問題でも適用してください。文章のルールだけだと Claude は曖昧なケースで揺れますが、具体例があると一気に解像度が上がります。私は新しいプロジェクトを始めるとき、最初の1週間で発生した代表的な作業を1つ選んで CLAUDE.md にこの形式で残すようにしています。
CLAUDE.md の設計をさらに深めたい方は、CLAUDE.md デザイン生産性ガイド もあわせてどうぞ。プロジェクト全体を制御する設計の話を扱っています。
私が使っている CLAUDE.md の最小テンプレート
/init の出力を磨く方向性が見えたところで、私が新規プロジェクトで実際に使っている最小テンプレートを共有します。30〜60行程度ですが、これだけで Claude の挙動はかなり安定します。
# {プロジェクト名} — CLAUDE.md
## このプロジェクトについて
（1〜2行：目的とユーザーは誰か）
## やってはいけないこと
- {具体ルール1}
→ 理由: {一行}
- {具体ルール2}
→ 理由: {一行}
## 判断基準
- {状況A} → {こうする}
- {状況B} → {こうする}
- 迷ったら {デフォルト方針}
## ファイル変更ルール
- 既存ファイル編集は Edit ツールで最小差分
- 新規作成は {命名規則}
- {特殊なルール}
## お手本: 良い作業例
（実際の作業1件をビフォー・アフターで記述）このテンプレートは私の4サイトすべてで使っています。最初は短くて不安かもしれませんが、プロジェクトが進むにつれて自然と必要な箇所が増えていくので、足りなくなってから足すほうが結果的に効率的です。
なお、CLAUDE.md と並行して .claude/settings.json でツール権限やコマンド許可も整えておくと、運用がさらに楽になります。詳しくは Claude Code settings.json 完全ガイド を参考にしてください。
全体を振り返って — まず削ることから始めてみてください
/init で生成された CLAUDE.md を磨く4ステップを振り返ります。削る、禁止事項を書く、判断基準を足す、実例で型を示す。この順番で進めるのが、私の経験では一番効率がいいです。
今日のうちに試していただきたいのは、ステップ1の「削る」だけです。生成された CLAUDE.md を半分くらいの長さにしてみてください。それだけで Claude の応答が引き締まるのが分かるはずです。残りの3ステップは、プロジェクトを動かしながら少しずつ足していけば十分です。
Claude Code の出力スタイル自体をプロジェクトに合わせたい場合は、Claude Code 出力スタイルガイド も合わせて読んでみてください。CLAUDE.md と組み合わせると、Claude の「振る舞いの個性」を細かく調整できるようになります。
新しいプロジェクトに /init を打つたびに、今回の4ステップを思い出していただけたら嬉しいです。