CLAUDE.mdの書き方【2026年】精度を上げる構成と/init活用のコツ

Claude CodeのプロジェクトメモリCLAUDE.mdの書き方を、非エンジニア目線で解説。/initでの生成、ユーザー/プロジェクトの階層、書くべき内容、200行未満に保つ分割術まで。指示の再現性を高めて出力精度を底上げするコツをまとめました。

Claude Codeは毎回まっさらな状態でセッションが始まります。前回の会話は覚えていないので、「うちのプロジェクトはこういう方針」「この書き方はやめて」といった前提を毎度説明するのは大変です。それを一度書いておけば毎回自動で読んでくれる仕組みがCLAUDE.md（プロジェクトメモリ）です。

そもそもCLAUDE.mdとは

Claude Codeが知識をセッションを跨いで持ち越す仕組みは2つあります。

• CLAUDE.md … 人が書く指示（ルール・前提・方針）
• auto memory … Claudeが作業しながら自動で書き足す学習の記録

どちらも毎セッションの冒頭で読み込まれます。auto memoryは既定でオンになっていて、/memory で閲覧・編集やオン/オフができます。この記事で扱う「書き方」は、人が主導する前者のCLAUDE.mdが中心です。

💡 イメージは「新しく来た優秀な助っ人に、毎朝最初に渡す作業マニュアル」。毎回同じ説明をしなくて済むように、要点だけ紙に書いておく感覚です。

ひとつ、公式ドキュメントが明言している大事な前提があります。「CLAUDE.mdはコンテキスト（文脈）であって、強制ではない」ということです。Claudeは読んで従おうとしますが、100%の遵守が保証される仕組みではありません。「勝手にコミットしない」のように確実に止めたい操作は、PreToolUseフック（ツール実行前に処理を差し込む仕組み）で機械的にブロックするのが公式の案内です。

auto memory（Claudeの学習ノート）も知っておく

CLAUDE.mdの相棒として、auto memoryの仕組みも押さえておくと運用がしやすくなります。

• Claudeが自分で書く：ビルドコマンドやデバッグで得た気づきなど、「次回も役立ちそうなこと」をClaudeが作業しながら自動でメモします。既定でオンです。
• 保存場所はプロジェクトごと：~/.claude/projects/<プロジェクト>/memory/ に、目次役の MEMORY.md とトピック別ファイルが作られます。
• 読み込まれるのはMEMORY.mdの先頭部分：毎セッション冒頭で読み込まれるのは 先頭200行または25KBまで（どちらか早い方）。トピック別ファイルは必要になったときにClaudeが読みに行きます。
• 中身はただのMarkdown：/memory からいつでも閲覧・編集・削除でき、オン/オフの切り替えもここでできます。

使い分けはシンプルで、ルールや前提は人がCLAUDE.mdに書き、Claudeが学んだことはauto memoryに溜まる、という分担です。「pnpmを使って、と毎回直している」ような修正は、Claudeに「覚えておいて」と頼むとauto memory側に保存されます。

まずは/initで雛形を作る

ゼロから書く必要はありません。プロジェクトのフォルダで起動し、スラッシュコマンドを打つだけです。

cd /path/to/your/project
claude
/init

/init はコードベースを解析して、技術スタックやよく使うコマンドなどを含む雛形を自動生成してくれます。既にCLAUDE.mdがある場合は上書きせず、改善提案の形になります。まずはこの下書きを土台に、自分の運用ルールを足していくのが早道です。

CLAUDE.mdに書くべき内容

正解は一つではありませんが、「毎回説明したくなること」を書くのが基本です。よく効くのは次のような項目です。

書き方のコツはシンプルです。

• 箇条書きで短くまとめる（長い散文より読み取りやすい）
• 「〜してほしい」より「必ず〜する／〜しない」と具体的に
• 抽象論ではなく、実際のコマンドやパスを明記する
• 分かりきった一般論は省く（詰め込むほど焦点がぼやける）

やってはいけないことは「効くだろう」と全部盛りにすること。守ってほしいことだけに絞るほど、指示は素直に効きます。

階層（置き場所）を使い分ける

CLAUDE.mdは置く場所によって適用範囲が変わります。読み込みは広い範囲から狭い範囲の順で、作業ディレクトリに近いものほど後に（＝優先的に効くように）読まれます。

使い分けの目安は、「常に日本語で」「口調はこう」のような自分の好みはユーザーへ、「このリポジトリのルール」はチームで共有するプロジェクトへ、というふうに分けることです。組織全体に配る管理ポリシー用の置き場所も別途あり、読み込み順は管理ポリシー → ユーザー → プロジェクト → ローカルの順です（詳細は公式を参照）。

このほか、上位ディレクトリのファイルは起動時に読み込まれ、サブフォルダ用のCLAUDE.mdはそのフォルダのファイルを触るときに遅延読み込みされます。モノレポなど大きな構成でも、範囲ごとにルールを分けられます。

肥大化させないコツ（200行未満）

内容が増えるほど良いわけではありません。むしろ長すぎると読み込みの負荷が増え、焦点がぼやけて精度が落ちます。目安は1ファイル200行未満。超えそうなら分割します。

• @path/to/import の書き方で別ファイルをインポートして読み込ませる（インポート先からさらにインポートも可能で、最大4ホップまで）
• .claude/rules/ にトピック別・パス限定のルールを切り出す（次の節で解説）

「共通の短いルールはCLAUDE.md本体、細かい規約は別ファイル」と分けると、見通しよく保てます。書き換えたら次のセッションから反映されるので、運用しながら少しずつ育てていくのがおすすめです。/memory からCLAUDE.mdやauto memoryを直接編集することもできます。

.claude/rules/ でトピック別に分割する

プロジェクトの .claude/rules/ ディレクトリにMarkdownファイルを置くと、ルールをトピックごとの複数ファイルに分けて管理できます。testing.md（テストの決まり）、code-style.md（書き方の規約）のように、1ファイル1トピックで置くイメージです。

さらに便利なのが、ファイル冒頭のfrontmatterに paths を書く条件付きルールです。

---
paths:
  - "src/api/**/*.ts"
---

# APIのルール
- エンドポイントには必ず入力チェックを入れる

こう書くと、このルールは該当パターンのファイルをClaudeが触るときだけ読み込まれます。常時読み込むCLAUDE.md本体を短く保ちつつ、細かい規約は必要な場面でだけ効かせられるので、コンテキストの節約にもなります。paths を書かないルールは、.claude/CLAUDE.md と同じ扱いで毎回読み込まれます。個人用に全プロジェクトへ効かせたいルールは ~/.claude/rules/ にも置けます。

精度を上げる運用のコツ

• 効かないと感じたら追記より削除：曖昧な文や矛盾を減らすほど素直になります。公式のベストプラクティスも「200行以内・見出し＋箇条書き・検証できる具体性・矛盾の除去」です。
• 具体例を一つ入れる：「良い例／悪い例」を短く添えると意図が伝わりやすい。
• プロジェクト固有の落とし穴を書く：ハマった点を一行残すと再発を防げます。
• 迷ったらユーザーとプロジェクトに分ける：好みと共有ルールを混ぜない。
• 絶対に守らせたいことはフックへ：CLAUDE.mdはコンテキストであって強制ではない、が公式の前提。確実に止めたい操作はPreToolUseフックで。

料金体系や利用条件、コマンドの最新仕様は変わることがあります。最新は必ず公式ドキュメントで確認してください（公式ドキュメントは code.claude.com に移転しています）。使うモデル（最新のClaudeモデル）の切り替えは /model で行えます。

まとめ

• CLAUDE.mdは毎セッション冒頭で読み込まれる常設の指示書。まず /init で雛形を作る。
• 書くのは概要・コマンド・規約・守ってほしいルール・前提。短く具体的に。
• 置き場所で範囲が変わる。好みはユーザー、共有ルールはプロジェクトに分ける。
• 1ファイル200行未満を目安に、@pathや.claude/rules/（pathsで条件付きも可）で分割して育てる。
• 記憶はCLAUDE.md（人が書く）とauto memory（Claudeが書く）の2系統。CLAUDE.mdは強制ではないので、確実に止めたい操作はPreToolUseフックで。

関連記事：Claude Codeの全体像は Claude Codeとは？、他のコマンドは スラッシュコマンドの使い方、外部連携は MCPの設定と使い方、作業の自動化は サブエージェントで自動化する もどうぞ。カテゴリ一覧は AI活用・ノウハウ へ。