Claude Codeを使い始めたとき、最初は何でもうまく動く。しかし数日後には「また同じ指示を繰り返している」「前回教えたことを覚えていない」という壁にぶつかります。この問題を根本的に解決するのがCLAUDE.mdです。
CLAUDE.mdはClaude Codeが毎セッション開始時に自動で読み込むプロジェクト設定ファイルです。コーディング規約・コマンド一覧・アーキテクチャの決定事項を書いておくと、毎回指示しなくてもClaudeがプロジェクトの文脈を理解した状態で動き始めます。
この記事では、CLAUDE.mdの3層設計・@インポートによる分割管理・自動メモリ(Auto Memory)まで、長期的に精度が上がり続ける設計方法を解説します。Claude Code全般の使い方はClaude Code完全ガイドを参照してください。
Claude Codeのメモリ構造を理解する
Claude Codeの記憶は、人が書くCLAUDE.md(グローバル・プロジェクト・ローカル)と、Claudeが自分で書くAuto Memoryの、4つの層で構成されています。
| 層 | ファイルパス | 読み込み範囲 | 主な用途 |
|---|---|---|---|
| グローバル | ~/.claude/CLAUDE.md |
全プロジェクト共通 | 開発スタイル・個人的なルール・よく使うコマンド |
| プロジェクト | CLAUDE.md or .claude/CLAUDE.md |
そのプロジェクトのみ | アーキテクチャ・規約・コマンド・禁止事項 |
| ローカル | CLAUDE.local.md |
そのプロジェクトのみ(自分だけ) | 自分のローカルURLやテストデータなど、共有しない個人のプロジェクト設定 |
| 自動メモリ | ~/.claude/projects/<project>/memory/ |
そのリポジトリ(自分のマシンだけ) | Claudeが自動で記録する修正の学び・選好・決定事項(MEMORY.mdが索引、詳細はトピックファイル) |
Claude Codeは見つけたCLAUDE.mdを上書きせず、すべて連結してコンテキストに読み込みます。ディレクトリ階層では、ルートから作業ディレクトリの順に並び、各階層で
CLAUDE.local.mdがCLAUDE.mdの後に追加されます。グローバルとプロジェクトに矛盾する指示があると、Claudeがどちらかを任意に選ぶ可能性があるため、同じ内容を両方に書かず、矛盾を作らないようにします。詳しい読み込みの仕組みはClaude CodeがCLAUDE.mdを読まない原因|配置場所・優先順位・読み込み範囲を確認を参照してください。CLAUDE.mdの基本構成テンプレート
効果的なCLAUDE.mdには「何を・なぜ・どうやって」が揃っている必要があります。Claudeがファイルを読んだだけで、プロジェクトに新規参加した開発者と同じ理解に達することを目標にします。
# プロジェクト概要 ECサイトのバックエンドAPI。Node.js + TypeScript + PostgreSQL + Prismaで構築。 認証はJWT、外部決済にStripeを使用。 ## よく使うコマンド - `npm run dev`: 開発サーバー起動(port 3000) - `npm test`: テスト実行(Jest、--watchは使わない) - `npm run build`: TypeScriptビルド - `npm run db:migrate`: Prismaマイグレーション実行 - `npm run lint`: ESLint実行 - `npm run typecheck`: 型チェックのみ(ビルドなし) ## アーキテクチャ - `src/routes/`: Expressルーター(ルーティングのみ、ビジネスロジックを含めない) - `src/services/`: ビジネスロジック(ここに実装する) - `src/repositories/`: Prismaを使ったDB操作(直接SQLは書かない) - `src/middleware/`: 認証・バリデーション・エラーハンドリング ## コーディング規約 - TypeScript strict モードを遵守(anyは禁止) - 関数は100行以内に収める - エラーはResult型でハンドリング(例外を使わない) - console.logは本番コードに残さない - すべてのAPIエンドポイントにzodバリデーションを追加する ## 禁止事項 - mainブランチへの直接コミット(PRを通すこと) - ORMを使わない生のSQL(セキュリティリスク) - src/外へのファイル作成(設定ファイルはルートに置く) ## テスト方針 - ユニットテスト必須(新機能・バグ修正どちらも) - テストファイルは対象ファイルと同じディレクトリに配置(.test.tsサフィックス) - モックはRepositoryレイヤーのみ(Serviceのテストは実Repositoryを使わない)
CLAUDE.mdが長くなるほど、Claudeが個々のルールを守りにくくなります。公式ドキュメントでは、1つのCLAUDE.mdを200行未満に保つことが目安とされています。ただし、@インポートで分割しても、インポートしたファイルは起動時にコンテキストへ読み込まれるため、コンテキストの消費は減りません。特定のファイルやディレクトリでしか必要ないルールは、
pathsを指定した.claude/rules/へ移します。@インポート構文:CLAUDE.mdを分割管理する
CLAUDE.mdの内容を整理したいときは@インポート構文で別ファイルに分割できます。@./path/to/file.mdと書くと、そのファイルの内容がCLAUDE.mdに展開されて読み込まれます。インポートしたファイルも起動時にコンテキストへ読み込まれるため、Tokenの消費は減りませんが、テーマ別に整理でき、後から特定のルールだけを見直しやすくなります。Relative Pathはインポートを書いたファイル自身の場所が基準で、インポートしたファイルからさらに別のファイルをインポートすることも、最大4段階までできます。
project/
├── CLAUDE.md ← メインファイル(概要・インポート宣言)
└── docs/
├── architecture.md ← アーキテクチャの詳細
├── testing.md ← テスト規約の詳細
├── deployment.md ← デプロイ手順
└── security.md ← セキュリティルール
# ECサイト バックエンドAPI ## クイックリファレンス - 開発サーバー: `npm run dev` - テスト: `npm test` - DB操作: `npm run db:migrate` ## 詳細ルール @docs/architecture.md @docs/testing.md @docs/deployment.md @docs/security.md
## アーキテクチャルール ### レイヤー構造 - `routes/`: ルーティングのみ(ビジネスロジックを含めない) - `services/`: ビジネスロジック(ここに実装する) - `repositories/`: Prisma経由のDB操作(生SQLは書かない) - `middleware/`: 認証・バリデーション・エラーハンドリング ### 依存関係のルール - routes → services → repositories(この方向のみ) - services間の直接呼び出しは禁止(循環依存防止) - 外部APIアクセスはすべて`services/external/`に集約 ### 命名規則 - ファイル名: kebab-case(例: user-service.ts) - クラス名・インターフェース名: PascalCase - 関数・変数: camelCase - 定数: UPPER_SNAKE_CASE ### 型定義の置き場所 - ドメインモデルは`src/types/`に集約 - リクエスト/レスポンス型はzodスキーマから自動生成(`z.infer<>`) - Prismaの型は直接使用可(Prismaクライアントから)
- メインのCLAUDE.mdは50〜100行以内に収める(概要とインポート宣言のみ)
- インポートファイルは各テーマで100〜150行以内
- チームで頻繁に変更するルールは専用ファイルに分離(変更履歴を追いやすくなる)
- インポートファイル名は内容が分かる具体的な名前にする
.claude/rules/の中のファイルは、@で書かなくても自動で読み込まれます。インポートする対象は、docs/など.claude/rules/の外に置きます
グローバルCLAUDE.mdの設計
~/.claude/CLAUDE.md(グローバル設定)には、すべてのプロジェクトに共通して適用したい個人的なルールを書きます。エディタ設定・コミットスタイル・個人の開発スタイルに関する設定がここに入ります。
# 個人設定 ## 開発スタイル - コードを書く前に必ず既存の実装を読んでから変更を提案する - 変更が大きい場合は先に計画を提示して承認を取ってから実装する - テストを書かずに実装だけ終わらせることを避ける ## コミットスタイル - コミットメッセージは日本語で書く - フォーマット: [種別] 変更内容(50文字以内) - [feat] 新機能追加 - [fix] バグ修正 - [refactor] リファクタリング - [test] テスト追加・修正 - [docs] ドキュメント更新 - 1コミットは1つの変更にまとめる ## 回答スタイル - 長い説明より短い説明を優先する - コードの変更前後を明示する - 「確認してください」という終わり方を減らし、完成したものを提示する ## セキュリティ - APIキー・パスワード・シークレットをコードに書かない - 環境変数は.envファイルで管理し、.gitignoreに追加する
チーム開発でのCLAUDE.md運用
gitで共有するファイルとしないファイルを分ける
チーム開発では、プロジェクトの規約は共有しつつ、個人設定は共有しないのが基本です。適切に分離することでチームの一貫性を保ちながら個人の自由も確保できます。
| ファイル | git管理 | 理由 |
|---|---|---|
CLAUDE.md(プロジェクトルート) |
commit(共有) | チーム全員に適用したいプロジェクト規約 |
.claude/rules/*.md |
commit(共有) | チームで合意したアーキテクチャ・テスト規約 |
CLAUDE.local.md |
gitignore推奨 | 自分だけのプロジェクト設定(共有しない) |
Auto Memory(~/.claude/projects/<project>/memory/) |
リポジトリの外(commit対象外) | Claudeが自動記録する内容は自分のマシンだけに保存され、メンバー間で共有されない |
~/.claude/CLAUDE.md |
gitignore対象外(個人ファイル) | 個人の開発スタイル・ローカル環境設定 |
# 個人用のプロジェクト設定は共有しない CLAUDE.local.md
Auto Memoryは~/.claude/projects/<project>/memory/に保存されてリポジトリの外にあるため、.gitignoreに追加する必要はありません。.claude/rules/はチームで共有するため、コミットします。
チームCLAUDE.mdの更新ルール
CLAUDE.mdはコードと同様にPull Requestでレビューして更新することを推奨します。ルールの変更はチーム全員に影響するため、独断で書き換えないようにします。
## CLAUDE.mdの更新方針 このファイルへの変更はPRを通してチームレビューを受けること。 更新すべきタイミング: - 新しいアーキテクチャパターンを採用したとき - バグや問題が繰り返し発生してルール追加が必要なとき - テスト方針・命名規則が変わったとき 更新してはいけないこと: - 個人の好みによる変更(チームの合意なしに) - 一時的な対処(永続的なルールとしてではなく)
自動メモリ(Auto Memory)を活用する
Claude Code v2.1.59(2026年2月26日リリース)から、Auto Memoryが搭載されています。これは、Claudeが過去のやり取りから学んだことを、自分でメモとして保存する機能です。あなたの修正や好みなどを~/.claude/projects/<project>/memory/に記録し、次のセッションでもその内容が引き継がれます。保存先はリポジトリの外で、自分のマシンだけに保存されます。同じGitリポジトリのworktreeやサブディレクトリでは、同じ場所が共有されます。
Auto Memoryの仕組み
公式ドキュメントでは、Claudeは次の4種類のメモを、自分用に保存するとされています。
- user:あなたの役割・専門性・作業の好み
- feedback:あなたがした修正と、確認したやり方
- project:進行中の作業・期限・コードやGit履歴からは分からない決定事項
- reference:Issue TrackerやDashboardなど、プロジェクト外の情報の場所
毎セッション保存するわけではなく、将来の会話で役立つかどうかをClaude自身が判断します。コードベースから分かること(アーキテクチャ、ファイルパス、デバッグの修正など)や、すでにCLAUDE.mdに書かれていることは保存されません。
~/.claude/projects/<project>/memory/ ├── MEMORY.md # 索引。毎セッション読み込まれる ├── user_role.md # 1つのメモ ├── feedback_testing.md # 1つのメモ └── ... # Claudeが作るその他のトピックファイル
MEMORY.mdは索引で、先頭200行または25KBまでが、毎セッション読み込まれます。詳細なメモは別のトピックファイルに分けて保存され、こちらは起動時には読み込まれず、Claudeが必要になったときに読みます。
手動でメモリを追加する
Claudeに「これを覚えておいて」と頼むと、Auto Memoryに保存されます。CLAUDE.mdに追加したいときは、「これをCLAUDE.mdに追加して」と頼むか、/memoryから自分でファイルを編集します。
# セッション中に > このプロジェクトではAuthorizationヘッダーにBearerトークンを使う。 > このことをメモリに記録しておいて。 # CLAUDE.mdに追加したいときは、そう頼むか /memory から編集する > /memory # CLAUDE.mdやAuto Memoryのファイル一覧が開き、選んだファイルをエディタで編集できる
安定した参照情報はdocs/で管理する
Auto Memoryのトピックファイルは、Claudeが作る詳細なメモで、起動時には読み込まれません。DB設計・API仕様・デプロイ手順のような変わらない参照情報を自分で管理したい場合は、Auto Memoryに任せず、docs/などのテーマ別のMarkdownファイルに置き、必要に応じて@でインポートするか、paths付きの.claude/rules/やSkillで読み込ませるのが確実です。
project/
├── CLAUDE.md
└── docs/
├── database.md ← DBスキーマ・テーブル設計の詳細(安定した参照情報)
├── api-spec.md ← 主要APIのエンドポイント仕様
└── decisions.md ← アーキテクチャの決定記録(ADR)
## アーキテクチャ決定記録(ADR) ### [2026-03-10] 状態管理にZustandを採用 - 背景: Reduxは複雑すぎてチームのキャッチアップコストが高かった - 決定: Zustandを採用。シンプルなAPIでチーム全員が即時使える - 影響: 既存のReduxストアを順次Zustandに移行(完了目標: 2026-Q2) ### [2026-02-20] APIクライアントにtanstack-queryを採用 - 背景: フロントエンドのキャッシュ戦略が複雑になっていた - 決定: tanstack-queryで統一。キャッシュ・リフェッチを自動化 - 影響: カスタムフックでAPIアクセスをラップする規約を追加 ### [2026-01-15] 認証トークンをhttpOnlyクッキーに変更 - 背景: XSS攻撃でlocalStorageのトークンが盗まれるリスクを排除 - 決定: JWTをhttpOnlyクッキーで管理。Refresh tokenローテーションを実装 - 影響: フロントエンドのAuthヘッダー送信が不要に。Cookieが自動送信される
よくある失敗パターンと対処法
| 失敗パターン | 症状 | 対処法 |
|---|---|---|
| 抽象的なルール | Claudeがルールを守るが期待と違う動きをする | 「〇〇する」より「〇〇した場合は△△する」と具体的に書く |
| 長すぎるCLAUDE.md | ルール遵守率が低下、矛盾が増える | 200行未満に収める(特定ファイル用のルールは.claude/rules/とpathsで分ける) |
| 古くなったルール | Claudeが古い仕様で動く | 定期的にCLAUDE.mdをレビューして古い記述を削除 |
| 禁止事項なし | してほしくない変更を繰り返しされる | 「〇〇するな」という明確な禁止事項セクションを作る |
| チームと個人の混在 | チームのCLAUDE.mdに個人設定が入り込む | グローバル設定に移す、またはCLAUDE.local.mdへ移して.gitignoreで除外 |
Claudeが同じミスを繰り返すときの対処
Claudeが同じ間違いを繰り返す場合、それはCLAUDE.mdに追記するサインです。「また同じ修正をした」と気づいたら、その内容をルールとして追記します。Auto Memoryが有効なら、Claudeが学んだ内容を自分で記録しますが、重要なルールはCLAUDE.mdに明示的に書いた方が確実です。
## よくある間違い(修正済み) - **認証ミドルウェアの順序**: `verifyToken`は`rateLimit`の後、`validateRequest`の前に置くこと (理由: レート制限の前にトークン検証すると無効トークンへのブルートフォースを防げない) - **Prismaトランザクション**: 複数テーブルを更新する場合は必ず`prisma.$transaction()`を使うこと (理由: 一部だけ更新されてデータ不整合が起きたことがある) - **型アサーション禁止**: `as SomeType`を使わず型ガードを実装すること (理由: asを使うと型チェックをバイパスしてランタイムエラーの原因になる)
なお、CLAUDE.mdの中のブロックレベルのHTMLコメント(<!-- ... -->)は、Claudeのコンテキストへ入る前に取り除かれます。人間の管理者向けのメモを、Tokenを消費せずに残したいときには使えますが、Claudeへの注意書きとしては使えません(コードブロック内のコメントは保持されます)。
CLAUDE.md設計チェックリスト
以下のチェックリストを使って、CLAUDE.mdが適切に設計されているか確認してください。
- 200行未満に収まっているか(超えていれば
.claude/rules/とpathsで分ける。@インポートではコンテキストは減りません) - プロジェクト概要が1〜3行で書かれているか(技術スタック・目的)
- よく使うコマンドが全部書かれているか(セッションごとに聞かれていないか確認)
- 「してほしくないこと」が明記されているか(禁止事項セクション)
- アーキテクチャの決定事項が書かれているか(なぜそうなったかも含めて)
- チーム設定と個人設定が混在していないか(グローバル設定に移す)
- 繰り返し指摘していることが書かれているか(Auto Memoryまたは手動追記)
- 古くなった記述が残っていないか(四半期ごとにレビュー)
まとめ
CLAUDE.mdはClaude Codeとの長期的な関係を定義するファイルです。最初から完璧にする必要はなく、「また同じことを教えた」と思った瞬間に追記していくスタイルが正解です。そうすることで、使い続けるほど精度が上がり、指示の繰り返しが減っていきます。
まずはコマンド一覧と禁止事項だけ書いたシンプルなCLAUDE.mdから始めましょう。50行でも書いておくだけで、毎セッションの「準備会話」が不要になります。200行を超えそうになったら、特定のファイル用のルールを.claude/rules/へ分け、Auto Memoryと組み合わせることで「学習し続けるAI開発環境」が完成します。
HooksやSubagentsとの組み合わせで、CLAUDE.mdのルールを自動で強制する設定も作れます。Claude Code Hooks完全ガイドとClaude Code Subagents完全ガイドも参考にしてください。
よくある質問
QCLAUDE.mdはどこに置けばいいですか?
AプロジェクトルートのCLAUDE.mdまたは.claude/CLAUDE.mdのどちらでも読み込まれます。チームで共有する場合はリポジトリルートが分かりやすいです。どのプロジェクトでも共通の個人設定は~/.claude/CLAUDE.md(グローバル設定)、そのプロジェクトだけの個人設定はCLAUDE.local.md(.gitignoreに追加)に書いてください。
Q@インポート構文はネストして使えますか?
Aはい。インポートしたファイルの中でさらに@インポートを使うことができ、公式ドキュメント上は最大4段階まで再帰できます。ただし循環インポート(AがBをインポートし、BがAをインポートする)は避けてください。読み込み順が複雑になるため、ネストは2段階以内に収めることを推奨します。
QAuto Memoryはいつ書き込まれますか?
AClaudeが、将来の会話で役立つと判断したときに書き込みます。毎セッション保存するわけではなく、コードから分かる内容やCLAUDE.mdにすでにある内容は保存されません。手動で追加したい場合は「これを覚えておいて」と頼みます。保存されたメモは、/memoryからAuto Memoryのフォルダを開いて確認・編集できます。
QCLAUDE.mdに書いたルールを確実に守らせるにはどうすればいいですか?
ACLAUDE.mdのルールは「強い示唆」として機能しますが、完全な強制ではありません。公式ドキュメントでも、CLAUDE.mdは強制される設定ではなくContextとして扱われ、特定の動作を確実にブロックしたいならHookを使うよう案内されています。PreToolUse Hookはツールの実行前に動き、終了コード2などで実行をブロックできます。この判定は権限モードを問わず(bypassPermissionsでも)有効です。例えば「anyを使ったTypeScriptコードの書き込みをブロックする」のように、判断が機械的に決まるルールは、スクリプトで検査するCommand Hookが向いています。曖昧な判断が必要な場合は、LLMで評価するPrompt Hookも使えます。詳しくはClaude Code Hooks完全ガイドを参照してください。
QCLAUDE.mdに書かない方がいい内容はありますか?
A頻繁に変わる情報(特定のバグの詳細・一時的な作業メモ・個人的なTODO)はCLAUDE.mdに書くのは不適切です。これらはAuto Memoryか、Gitのコメント・Issueで管理しましょう。また、CLAUDE.mdは毎セッション読まれるため、機密情報(APIキー・パスワード)は絶対に書かないでください。
QチームメンバーによってCLAUDE.mdの記述が衝突します。
ACLAUDE.mdのコンフリクトはコードと同様にPRでレビューして解決します。チームの合意ルールのみをプロジェクトCLAUDE.mdに書き、個人の好みは各自のグローバル設定に分離することでコンフリクトを減らせます。また.claude/rules/を役割(フロントエンド・バックエンド等)で分割すると担当範囲が明確になりコンフリクトが起きにくくなります。

