CLAUDE.mdとは？Claude Codeのメモリ管理と書き方を徹底解説

CLAUDE.mdは、AnthropicのClaude Codeが各セッションの開始時に自動で読み込む、プロジェクト固有の指示を記述するマークダウンファイルです。
毎回同じ前提条件を伝え直す手間を解消し、コーディング規約・ビルドコマンド・アーキテクチャ方針をAIに「記憶」させたうえで作業を進められます。

本記事では、CLAUDE.mdの基本から4種類の配置スコープ・読み込みの仕組み・自動メモリとの違い・.claude/rulesでの分割管理・チーム運用までを、2026年6月時点の公式ドキュメントに基づき整理します。
あわせて/init・/memoryコマンドの操作手順、CLAUDE.mdが効かない時のトラブルシュート、Claude Codeの料金プランと利用条件まで、実務で必要な論点を一気通貫で解説します。

✅2026年6月9日、AnthropicがMythos-class初の一般公開モデル「Claude Fable 5」を発表しました。Opus 4.8の上位に位置する新最上位モデルの詳細はこちら。
▶︎Claude Fable 5とは？Mythos 5との違いや料金、使い方を解説

CLAUDE.mdとは？Claude Codeのメモリ管理を支える基幹ファイル

CLAUDE.mdは、AnthropicのClaude Codeが各セッションの開始時に自動で読み込む、プロジェクト固有の指示を記述するマークダウンファイルです。

公式ドキュメントはこれを「Claudeに永続的なコンテキストを与えるための指示ファイル」と位置づけ、ビルドコマンド・コーディング規約・アーキテクチャの決定をセッションをまたいで保持させる仕組みとして定義しています。

本セクションでは、CLAUDE.mdの位置づけを「自動メモリ」「Skills」「.claude/rules/」といった隣接概念と並べて整理し、AGENTS.mdとの関係まで含めて全体像を示します。

CLAUDE.mdが解決する課題——「毎回伝え直す手間」を恒久化する

Claude Codeを業務で常用する開発者がまず突き当たるのが、「同じ前提条件を毎セッション最初に伝え直す」摩擦です。

「このプロジェクトはTypeScriptを使っている」「テストはJestで書く」「ビルドコマンドはnpm run buildである」——こうした前提を毎回入力するコストは、1日に何度もセッションを切る開発者にとって無視できない負荷になります。

公式は「CLAUDE.mdは『そうでなければ再度説明する場所』として扱え」と明確化しています。具体的には次の4つが、CLAUDE.mdを書き始めるべきタイミングの典型です。

• Claudeが2回目に同じミスを犯す
• コードレビューで「Claudeはこれを知っておくべきだった」と指摘される
• 前回のセッションで入力した修正や説明を、また入力している
• 新しいチームメンバーに同じコンテキストを毎回説明している

「人間向けのプロジェクト案内」がREADMEだとすれば、CLAUDE.mdは「AI向けのプロジェクト案内」です。一度書いておけば、新しいセッションが立ち上がるたびにClaudeはその内容を踏まえた状態で作業を始められます。

自動メモリ（Auto memory）との違い——「誰が書くか」が分岐点

Claude Codeのメモリ管理は、CLAUDE.mdと自動メモリ（Auto memory）という二系統で構成されています。両者は補完関係にありますが、誰が何を書くかで明確に役割が分かれます。

以下の表で、両者の違いを整理しました。

CLAUDE.mdが「あなたが明示的に書きたい要件」を保持するのに対し、自動メモリは「Claudeが観察・学習したあなた固有のパターン」を保持します。

実務での使い分けは、「同じ修正を2回求めた→CLAUDE.mdに書く」「Claudeが自然に学んだ前提を確認したい→自動メモリのMEMORY.mdを開く」という分け方が現実的です。自動メモリの詳細仕様は後段の「自動メモリ（Auto memory）の仕組みと監査方法」セクションで扱います。

Skillsとの使い分け——常時ロード vs 呼び出し時ロード

CLAUDE.mdと混同しやすいもう一つの仕組みが、Claude CodeのSkillsです。Skillsは .claude/skills/<skill-name>/SKILL.md 形式で配置する、Claude Codeの拡張機能パッケージです。

両者の違いは読み込みのタイミングに集約されます。

• CLAUDE.md
  全セッションでコンテキストウィンドウに常時読み込まれる。短く具体的な「ルール・規約・前提」に向く
  
  

• Skills
  スキルが呼び出されたときのみ本体が読み込まれる（説明文だけは常時表示）。長いリファレンス資料・複数ステップの手順・専用コマンドに向く
  
  

公式は「同じプレイブック、チェックリスト、または複数ステップの手順をチャットに何度も貼り付けるとき、またはCLAUDE.mdのセクションが事実ではなく手順に成長したとき」にSkillsを作るよう示しています。

例えば「デプロイ手順」「コードレビューの標準フロー」のように内容が手順として定型化したルーチンは、CLAUDE.mdから切り出して .claude/skills/deploy/SKILL.md のような独立スキルにする方が、毎セッションのコンテキスト消費を抑えられます。

AI総合研究所で大規模リポジトリの導入支援に入る際も、CLAUDE.md・Skills・サブエージェントの3層で役割分担を整理するところから始めるケースが増えています。

.claude/rules/との関係——CLAUDE.mdの分割管理

CLAUDE.mdが200行を超えてきたとき、.claude/rules/ ディレクトリへの分割が公式推奨の対処です。

.claude/rules/ 配下のマークダウンファイルはデフォルトで .claude/CLAUDE.md と同じ優先度で常時読み込まれますが、YAML frontmatterで paths を指定すれば「該当ファイル操作時のみ読み込み」の条件付きルールにできます。

つまり、CLAUDE.mdは「プロジェクト全体に常時適用するルール」、.claude/rules/ は「トピック別・パス別に整理した条件付きルール」という棲み分けです。詳細な仕様は後段の「.claude/rulesと@importで分割管理する」セクションで扱います。

AGENTS.mdとの関係——Claude CodeはAGENTS.mdを直接読まない

近年、複数のAIコーディングエージェントで共通利用できる規約ファイルとして AGENTS.md が広がっています。Cursor・Aider・OpenAI Codexなどが対応していますが、Claude CodeはAGENTS.mdを直接読み込みません。

ただし、CLAUDE.mdから @AGENTS.md 構文でインポートすれば、両ツールが同じ指示を重複なしに参照できます。

@AGENTS.md

## Claude Code

`src/billing/` 配下の変更にはPlan Modeを使用する。

シンボリックリンクで対応する方法もあります。

ln -s AGENTS.md CLAUDE.md

Claude固有の指示を追加する必要がないなら、シンボリックリンクが最も保守コストが低い選択です。既にAGENTS.mdを使っているプロジェクトでも、/init を実行すれば自動的にAGENTS.mdの内容を取り込んだCLAUDE.mdが生成されるため、移行コストはほぼゼロで済みます。

CLAUDE.mdの配置スコープと読み込みの仕組み

CLAUDE.mdは置き場所によって適用範囲が変わる4種類のスコープを持ち、起動時のディレクトリツリー上方探索とサブディレクトリの遅延読み込みで構成されます。

仕組みを理解すると、「個人設定はどこに書くか」「チーム共有はどこに置くか」「組織標準はどう配布するか」の3層を切り分けて運用できるようになります。

本セクションでは、4スコープの定義・読み込み順序・モノレポでの除外設定までを、公式ドキュメントの内容に沿って整理します。

4種類の配置スコープ

公式が定めるCLAUDE.mdの配置場所は以下の4つです。読み込み順は「広いスコープ→狭いスコープ」で、後から読まれた内容ほどClaudeが優先して認識する設計になっています。

4種類のうち最も使うのは「プロジェクト指示」と「ユーザー指示」の2つで、「ローカル指示」は個人のサンドボックスURL・テストデータなど共有したくない情報用、「管理ポリシー」は組織全体に強制したい規約用、と整理すると役割が明確になります。

「管理ポリシー」は個別の設定で除外できない最上位の指示で、組織横断のコンプライアンス要件やセキュリティポリシーを徹底したい時に使います。詳細は後段の「チーム・組織でのCLAUDE.md運用」セクションで扱います。

ディレクトリツリーの上方探索とLazy Load

Claude Codeは起動時に現在のワーキングディレクトリから親方向へ再帰的にCLAUDE.mdを探索し、見つかったファイルをすべて連結してコンテキストに読み込みます。

例えば monorepo/packages/frontend/ で claude を起動すると、以下の順序でCLAUDE.mdが読まれます。

1. monorepo/CLAUDE.md（祖先）
2. monorepo/packages/CLAUDE.md（途中）
3. monorepo/packages/frontend/CLAUDE.md（起動位置）

後に読まれたものほど直近の文脈として扱われるため、リポジトリルートに共通ルール、各サブディレクトリに個別ルール、という階層配置が自然に効きます。

一方、起動位置より下のサブディレクトリにあるCLAUDE.mdは「Lazy Load」として扱われます。Claudeがそのサブディレクトリ内のファイルを読むタイミングで初めて読み込まれるため、起動時のコンテキストは肥大化しません。

モノレポでpackages/frontend/CLAUDE.mdとpackages/backend/CLAUDE.mdを別々に置いておけば、Claudeがフロントエンドのコードを触るときだけフロントエンド用ルールが読まれる構造になります。

claudeMdExcludesでモノレポで除外する

大規模なモノレポで作業していると、他チームのCLAUDE.mdが祖先ディレクトリから自動で読み込まれてしまい、自分のタスクに無関係な指示でコンテキストが汚れる問題が起きます。

公式はこの対処として claudeMdExcludes 設定を用意しています。.claude/settings.local.json に以下のように記述すると、指定パスのCLAUDE.mdをスキップできます。

{
  "claudeMdExcludes": [
    "**/monorepo/CLAUDE.md",
    "/home/user/monorepo/other-team/.claude/rules/**"
  ]
}

パターンはグロブ構文で絶対パスに対して一致します。設定はユーザー・プロジェクト・ローカル・管理ポリシーのどのレイヤーでも可能で、配列はレイヤー間でマージされます。

ただし管理ポリシーCLAUDE.mdは除外できません。これは組織横断の指示を個別設定で骨抜きにできないようにするための設計判断です。

導入判断で詰まりやすいのは「個人の設定（CLAUDE.local.md）か、プロジェクトの設定（CLAUDE.md）か」の切り分けです。チーム全員に守らせたいルールはCLAUDE.md、自分のサンドボックスURLや個人的なメモはCLAUDE.local.mdに分けるのが原則で、これを最初に徹底すると後の運用が安定します。

/init・/memoryでCLAUDE.mdを操作する

CLAUDE.mdをゼロから手書きするのは現実的ではないため、Claude Codeにはコードベースを解析して雛形を生成する /init と、メモリファイルを参照・編集する /memory という2つのコマンドが用意されています。セッション中に思いついた追記は、Claudeに直接「CLAUDE.mdに追加して」と依頼する運用も公式が示しています。

本セクションでは、それぞれの使い分けと2026年に追加された対話式の /init 新フローまでを整理します。

/init で雛形を自動生成する

CLAUDE.mdの初稿は、/init コマンドで自動生成するのが標準ルートです。プロジェクトのルートディレクトリで claude を起動し、セッション内で /init と入力するだけで、Claudeがコードベースを解析して雛形を出力します。

cd your-project
claude
> /init

Claudeは以下を解析して、CLAUDE.mdに反映します。

• package.json の scripts 欄からビルド・テストコマンドを抽出
• Makefile から開発タスクを取り込み
• 既存の README.md から概要を取り込み
• ディレクトリ構造から主要なモジュール配置を整理
• Gitフックや設定ファイルの存在を補足情報として記録

すでにCLAUDE.mdが存在する場合は、/init は上書きせず改善提案を出す動きに変わります。既存ファイルを壊さないので、運用開始後の見直しでも安心して使えます。

CLAUDE_CODE_NEW_INIT=1 の対話式マルチフェーズ

2026年から、より精緻な雛形を作る対話式フローが追加されました。CLAUDE_CODE_NEW_INIT=1 環境変数を設定して /init を実行すると、以下の流れに変わります。

1. どのアーティファクトを設定するかをClaudeが尋ねる（CLAUDE.md・skills・hooksなど）
2. サブエージェントでコードベースを探索
3. フォローアップ質問でギャップを埋める
4. ファイルを書く前に確認可能な提案を提示

従来の一発生成と異なり、対話の中でプロジェクト固有の暗黙知を引き出してから書き出すため、出力の質が大きく上がります。新規プロジェクトの初期セットアップや、既存プロジェクトの大幅見直し時には対話式の方が有利です。

ただし、いずれの方式でも生成された雛形をそのまま使い続けるのは避けるべきです。/init はコードベースの構造的情報には強い一方、「このディレクトリのファイルは自動生成なので手動で編集しない」「APIエラーレスポンスは標準フォーマットを守る」といったチーム内の暗黙知や設計上の意図は捕捉できません。雛形は出発点として扱い、人間側で加筆していく工程を必ず挟みます。

/memory でメモリファイルを参照・編集する

セッション中に /memory と入力すると、現在のセッションに読み込まれているCLAUDE.md・CLAUDE.local.md・rulesファイルの一覧が表示されます。

ここから任意のファイルを選択すると、システムのデフォルトエディタ（VS Codeやvimなど）で開かれます。読み込まれている内容の確認・新しい指示の追記・不要な記述の削除をエディタ上で完結できる仕組みです。

/memory は次のような場面で特に有効です。

• CLAUDE.mdの内容を大幅に見直したい
• どのファイルが実際に読み込まれているか確認したい
• 自動メモリのMEMORY.mdを開いてClaudeが何を学んだか確認したい

自動メモリのオン/オフ切り替えもこのコマンドからアクセスできます。

Claudeに直接「CLAUDE.mdに追加して」と依頼する

セッション中に思いついたルールを素早く反映したい時は、Claudeに直接「これをCLAUDE.mdに追加して」と依頼するのが公式が示す運用です。

たとえば「常にnpmではなくpnpmを使うことを覚えておいて」「APIテストはローカルRedisが必要だと覚えておいて」のように依頼すると、Claudeが内容を保存します。

なお、こうした依頼は文脈次第で自動メモリ側に保存されることもあります。確実にCLAUDE.mdに入れたい場合は「CLAUDE.mdに追加して」と明示するか、/memory 経由でエディタを開いて手動で書き加える方が確実です。

実務的な使い分けは、「ガッツリ書き直す→/memory」「軽く追加だけ依頼→Claudeへ直接依頼」「初稿生成→/init」の三段構えで覚えておけば迷いません。

CLAUDE.mdの効果的な書き方

CLAUDE.mdは何を書くかと同じくらい、どう書くかが重要です。公式は「CLAUDE.mdの内容はシステムプロンプト自体の一部ではなく、システムプロンプトの後のユーザーメッセージとして配信される」と明示しており、Claudeはこれを「強制」ではなく「コンテキスト」として扱います。

つまり、指示が曖昧だったり矛盾していたりするとClaudeはそれに従わない可能性があり、書き方の精度が遵守率を左右します。

本セクションでは、公式が推奨する5つの執筆ルールを整理します。

200行以下に収める

公式は「CLAUDE.mdファイルあたり200行以下を目標にする」と明記しています。

理由は二つあります。第一に、長いファイルはコンテキストウィンドウをより多く消費し、他の情報を圧迫します。第二に、長いファイルではClaudeの遵守率が下がります。指示が膨大になるほど、個々のルールが薄められてしまうためです。

200行を超えそうな場合の対処は3パターンあります。

• 不要なルールを削減する（プロジェクトで使わなくなったライブラリの記述など）
• .claude/rules/ への分割でトピック別に切り出す
• パススコープルールで「該当ファイル操作時のみ読み込み」に変える

@import でファイルを分割する方法もありますが、インポートされたファイルは起動時にコンテキストに読み込まれるためコンテキスト削減にはならない点に注意が必要です。インポートは「整理のため」、.claude/rules/ のパススコープは「コンテキスト削減のため」と役割を分けて使います。

具体的で検証可能な指示を書く

CLAUDE.mdの指示は具体的で検証できるレベルで書くのが鉄則です。

公式が示している置き換え例は以下のとおりです。

抽象的な指示は「何をすればルールを満たしたことになるか」がClaudeにも人間にも分かりません。検証可能な水準まで具体化すると、Claudeの遵守率が上がるだけでなく、人間のコードレビューの基準にもなります。

加えて、ポジティブとネガティブの両方を書くことも公式が強調しています。「never commit .env」「no class components」のような禁止事項を書かないと、Claudeは「自分が学習した中で最も一般的なパターン」を選んでしまい、それが自社の規約と一致しないケースが頻発します。

マークダウンで構造化する

CLAUDE.mdはマークダウン見出しと箇条書きで構造化します。公式は「Claudeは読者と同じ方法で構造をスキャンする」と明示しており、密集した段落より整理されたセクションの方が遵守されやすい設計になっています。

推奨される構成例は以下のとおりです。

# プロジェクト概要
Next.js 14（App Router）+ TypeScriptで構築されたコンテンツ管理システム

# コマンド
- ビルド: npm run build
- テスト: npm run test
- リント: npm run lint

# コーディング規約
- インデント: 2スペース
- 命名規則: 変数はキャメルケース、コンポーネントはパスカルケース
- インポート順: 外部ライブラリ → 内部モジュール → 型定義

# アーキテクチャ
- src/app/ 以下はApp Routerのルーティング
- src/components/ には再利用可能コンポーネント
- src/lib/ にはAPIクライアントやユーティリティ

# 注意事項
- public/generated/ 以下はビルド時に自動生成されるため手動編集禁止
- APIキーは環境変数で管理し、コードにハードコードしない

見出しで分類し、箇条書きで簡潔にまとめると、Claudeが必要な情報を効率的に参照できるようになります。テキストの密度を上げすぎず、各項目を1〜2行に収めるのがコツです。

HTMLコメントで人間用メモを残す

CLAUDE.mdはブロックレベルのHTMLコメント（<!-- 〜 -->）をClaudeのコンテキスト注入前に削除します。これは2026年に明文化された比較的新しい仕様で、トークンを消費せずに人間のメンテナー向けのメモを残せる仕組みです。

<!--
このCLAUDE.mdは2026年6月に大幅改訂。
旧版はgit logで確認可能。レビュー担当: @maeda
-->

# プロジェクト概要
...

ファイルの履歴・改訂理由・レビュー担当者などはHTMLコメントに記述しておけば、Claudeのコンテキストを汚さずに人間側のメタ情報を保持できます。

ただしコードブロック内のコメントは保持される点に注意してください。意図的にClaudeにも見せたい情報はコードブロックの外、人間専用情報はHTMLコメント内、と書き分けます。

矛盾と一貫性を定期的に見直す

CLAUDE.mdの遵守率を下げる最大の要因は、ファイル内の矛盾です。

「テストはJestで書く」と「テストはVitestを使う」のように互いに矛盾する指示が混じっていると、Claudeはどちらかを任意に選んでしまいます。プロジェクトの方針が変わったタイミングで古いルールを削除し忘れた、というケースで頻発します。

公式は「CLAUDE.mdファイル、サブディレクトリ内のネストされたCLAUDE.mdファイル、および .claude/rules/ を定期的に確認して、古い指示または矛盾する指示を削除する」よう推奨しています。

実務的には、四半期に一度CLAUDE.mdをレビューする運用を組み込むのが現実的です。プルリクエストでCLAUDE.mdに変更を入れる際にチームレビューを通すルールにすると、矛盾が混入する前に潰せます。

.claude/rulesと@importでCLAUDE.mdを分割管理する

CLAUDE.mdが200行を超えてきたら、.claude/rules/ ディレクトリへの分割と @import 構文による外部ファイル参照の2つの仕組みで肥大化を解消します。

両者は似ているようで適用場面が異なります。.claude/rules/ は「トピック別・パス別に整理しつつ、条件付きで読み込みたい時」、@import は「整理目的で複数ファイルに分割しつつ、全て常時読み込みたい時」と覚えると使い分けが明確になります。

本セクションでは、それぞれの仕様と運用パターンを整理します。

.claude/rules/の基本構造

.claude/rules/ 配下のマークダウンファイルは、Claude Codeがプロジェクトメモリとして自動的に検出して読み込みます。すべての .md ファイルが再帰的に発見されるため、サブディレクトリで整理しても問題ありません。

典型的なディレクトリ構成は以下です。

your-project/
├── .claude/
│   ├── CLAUDE.md           # メインプロジェクト指示
│   └── rules/
│       ├── code-style.md   # コードスタイル
│       ├── testing.md      # テスト規約
│       ├── security.md     # セキュリティ要件
│       └── frontend/
│           ├── react.md    # React固有
│           └── styles.md   # CSS固有

paths frontmatterを指定しないルールは、.claude/CLAUDE.md と同じ優先度で起動時に読み込まれます。1つの巨大なCLAUDE.mdを保守する代わりに、トピックごとに分割されたファイルで管理できるため、更新や確認が容易になります。

paths frontmatterで条件付きルールを作る

.claude/rules/ の最大の特徴は、特定のファイルパスにのみ適用される条件付きルールを設定できる点です。

YAML frontmatterで paths フィールドを指定すると、Claudeが該当パターンに一致するファイルを操作している時のみ、そのルールが読み込まれます。

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

# API開発ルール

- すべてのAPIエンドポイントは入力検証を含める
- 標準エラー応答形式を使用する
- OpenAPIドキュメンテーションコメントを含める

paths フィールドではグロブパターンが利用できます。代表的なパターンを以下にまとめました。

ブレース展開を使えば、複数の拡張子をまとめて指定することもできます。

---
paths:
  - "src/**/*.{ts,tsx}"
  - "lib/**/*.ts"
  - "tests/**/*.test.ts"
---

パススコープルールはコンテキスト消費を抑える最も効果的な手段です。フロントエンド固有のルールはフロントエンドのファイル操作時のみ、API固有のルールはAPI操作時のみ、というように読み込みを絞れます。

@import構文で外部ファイルを取り込む

CLAUDE.mdは @path/to/file 構文で外部ファイルをインポートできます。

プロジェクト概要は @README を参照してください。
利用可能なnpmコマンドは @package.json を確認してください。

# 追加の指示
- gitワークフロー @docs/git-instructions.md
- 個人的な好み @~/.claude/my-project-instructions.md

相対パス（インポートを含むファイルからの相対）、絶対パス、ホームディレクトリ起点パス（@~/...）のいずれも使えます。インポートは再帰的に解決され、最大4ホップまで展開可能です。

注意点として、インポートされたファイルは起動時に全て読み込まれ、CLAUDE.mdと同じくコンテキストを消費します。.claude/rules/ のパススコープと違い、コンテキスト削減効果はありません。@importは「組織的に分割したい」「README・package.jsonの内容を取り込みたい」時に使い、「コンテキストを減らしたい」時には .claude/rules/ のパススコープを選びます。

また、コードブロックやコードスパン（バッククォート）内に @ が出てきても、それはインポートとして評価されません。コード例の中で @ を使っても意図しない読み込みが発生する心配はない設計です。

シンボリックリンクでルールを共有する

.claude/rules/ ディレクトリはシンボリックリンクをサポートしています。

複数のプロジェクトで共通するルールがある場合、共有ディレクトリへのシンボリックリンクを作成すれば、ルールを一元管理しつつ各プロジェクトで利用できます。

ln -s ~/shared-claude-rules .claude/rules/shared
ln -s ~/company-standards/security.md .claude/rules/security.md

ディレクトリ単位でもファイル単位でもリンクが張れます。循環シンボリックリンクは検出されて適切に処理されるため、複雑な共有構造でも安全に運用できます。

加えて、ユーザーレベルのルールとして ~/.claude/rules/ に個人的なルールを配置すれば、マシン上のすべてのプロジェクトに適用できます。プロジェクトルールよりも先に読み込まれ、プロジェクトルールに高い優先度を譲る設計なので、個人の好みとプロジェクトの規約が衝突した場合はプロジェクト側が勝ちます。

自動メモリ（Auto memory）の仕組みと監査方法

自動メモリ（Auto memory）は、Claudeが手動の介入なしにセッション間で学習を蓄積する仕組みです。CLAUDE.mdが「あなたが書く要件」を保持するのに対し、自動メモリは「Claudeが観察して書く学習」を保持します。

両者は補完関係にあり、両方をうまく活用するとClaudeの応答精度が継続的に向上していきます。

本セクションでは、自動メモリのストレージ・読み込みルール・カスタマイズ方法・監査手順までを整理します。

自動メモリのストレージ場所とMEMORY.md

自動メモリは、プロジェクトごとに ~/.claude/projects/<project>/memory/ ディレクトリに保存されます。<project> パスはGitリポジトリから派生するため、同じリポジトリ内のすべてのワーキングツリーとサブディレクトリは1つの自動メモリディレクトリを共有します。

ディレクトリ内の典型的な構造は以下です。

~/.claude/projects/<project>/memory/
├── MEMORY.md          # インデックス（すべてのセッションに読み込まれる）
├── debugging.md       # デバッグパターンの詳細メモ
├── api-conventions.md # API設計の決定
└── ...                # Claudeが作成するその他のトピックファイル

MEMORY.md がエントリポイントで、メモリディレクトリの内容を追跡するインデックスとして機能します。Claudeはセッション中にこのディレクトリ内のファイルを読み書きし、新しく学んだことを MEMORY.md に追記しつつ、詳細は別のトピックファイルに切り出していきます。

なお自動メモリはマシンローカルで、マシン間やクラウド環境では共有されません。チームで学習を共有したい場合はCLAUDE.mdに移し替える運用が必要です。

200行・25KBの起動時ロード制限

自動メモリには読み込み上限があります。

• MEMORY.md の最初の200行、または最初の25KB（いずれか先に来る方）
• 上限を超えた部分は起動時には読み込まれない
• 個別のトピックファイル（debugging.md など）も起動時には読み込まれない

つまり、自動メモリで起動時に常にアクセスされるのは MEMORY.md の冒頭部分のみで、それ以外はClaudeが必要に応じてセッション中に読み込む構造です。

この制限はCLAUDE.mdには適用されません。CLAUDE.mdはサイズに関係なく全文が読み込まれますが、その分コンテキストを消費するので、200行以下を目標にする推奨が別途あります。

Claudeはこの制限を踏まえて、MEMORY.md を簡潔に保ち詳細を別ファイルへ移動する判断を自律的に行います。あなたが手動でメモリを整理する必要は基本的にありませんが、不要なエントリが溜まったら /memory 経由で開いて削除できます。

autoMemoryDirectoryで保存先をカスタマイズする

2026年に追加された機能として、自動メモリの保存先をカスタマイズできる autoMemoryDirectory 設定があります。

settings.json に以下のように記述すれば、デフォルトの ~/.claude/projects/<project>/memory/ ではなく任意のディレクトリを使えます。

{
  "autoMemoryDirectory": "~/my-custom-memory-dir"
}

値は絶対パス、または ~/ で始まる必要があります。指定できるスコープはユーザー設定（~/.claude/settings.json）・ポリシー設定・--settings フラグの3つに限定され、プロジェクト設定（.claude/settings.json）やローカル設定（.claude/settings.local.json）からは受け付けられません。自動メモリの保存先は個人またはマシン全体の判断で決める設計になっているため、プロジェクト側からは制御できない仕様です。

同一マシン上で複数プロジェクトの自動メモリを束ねたい時に有効です。なお自動メモリはマシンローカル設計で、Claude Code公式にマシン間同期機能はありません。Dropbox等の外部同期ディレクトリに保存先を向けることは可能ですが、その場合は別マシンとの編集競合や機密情報の取り扱いに自己責任で注意する必要があります。

なお、自動メモリ自体の有効・無効も autoMemoryEnabled 設定または CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 環境変数で切り替えられます。自動メモリにはClaude Code v2.1.59以降が必要なので、古いバージョンでは利用できません。

/memoryコマンドで内容を確認・編集する

自動メモリはClaudeが自動的に書くため、何が記録されているかが見えにくい問題があります。

セッション中に /memory と入力すれば、現在のセッションに読み込まれているCLAUDE.md・rulesファイルに加えて、自動メモリのオン/オフトグルと自動メモリフォルダを開くリンクが表示されます。

Claudeが「これを覚えておく」と言ったとき、または「常にnpmではなくpnpmを使う」のような恒久ルールを依頼したとき、その内容は自動メモリに保存されます。記録内容はプレーンマークダウンなので、エディタで開けば自由に編集・削除できます。

実務では、定期的に /memory で自動メモリを開いて、意図しない学習が記録されていないか確認するのが安全です。Claudeが誤って解釈した内容が記録されていると、後のセッションで同じ間違いを繰り返す原因になります。

CLAUDE.mdに移し替えたい内容を見つけたら、その場でCLAUDE.mdへ転記しておけば、チーム全体に共有できる形に格上げできます。

チーム・組織でのCLAUDE.md運用

CLAUDE.mdをチームで使う際の核心は、「共有すべき情報」と「個人に閉じる情報」の切り分けです。Gitリポジトリにコミットして全員で共有するファイル、個人のローカル環境固有の情報、組織全体に強制する標準を3層で設計します。

本セクションでは、Git管理戦略・管理ポリシーCLAUDE.mdの配布・運用上の注意点までを整理します。

Git管理の基本戦略

CLAUDE.mdの各ファイルをGit管理に乗せるか否かは、内容のスコープで明確に分かれます。

CLAUDE.local.md は /init で個人用オプションを選んだ場合に .gitignore へ自動追加される運用です。手動で CLAUDE.local.md を作成した場合は、自分で .gitignore に追加して誤コミットを防ぐ必要があります。

加えて、個人のAPIキーやテスト用の認証情報などの機密情報は、CLAUDE.local.md であっても記述を避け、環境変数として管理するのが原則です。「ファイルがgitignoreされている」と「機密情報を書いてよい」はイコールではありません。

管理ポリシーCLAUDE.mdで組織標準を配布する

組織全体に適用したいルールがある場合、管理ポリシー用のCLAUDE.mdを活用します。

OS別の配置場所は以下です。

• macOS: /Library/Application Support/ClaudeCode/CLAUDE.md
• Linux / WSL: /etc/claude-code/CLAUDE.md
• Windows: C:\Program Files\ClaudeCode\CLAUDE.md

このファイルはMDM・グループポリシー・Ansibleなどの構成管理ツールで全開発者のマシンに配布します。

管理ポリシーCLAUDE.mdは個別設定で除外できず常に適用されるファイルとして、ユーザー設定やプロジェクト設定より先にコンテキストへ読み込まれます。組織横断のセキュリティポリシー・コンプライアンス要件・コーディング標準を全社員のClaude Codeに届けたい時に有効です。

ただし、CLAUDE.md自体はClaudeの動作を形作る「行動誘導」であって、ツール拒否やサンドボックス分離のようなハードな技術的強制は別途managed-settings.jsonの permissions などで設定する必要があります。詳細は次節で扱います。

managed-settings.jsonのclaudeMdキー

別ファイルを配布する代わりに、managed-settings.json 内に直接ルールを書き込む方法もあります。

{
  "claudeMd": "常に `make lint` をコミット前に実行してください。\nメインに直接プッシュしないでください。"
}

claudeMd キーは管理ポリシー設定でのみ尊重される専用フィールドで、ユーザー・プロジェクト・ローカル設定では無効です。シンプルなルールを少数だけ展開したい場合は、別ファイルを配布せずに1つのJSONファイルで完結できる点が利点です。

なお、管理ポリシーCLAUDE.mdと管理設定（managed-settings.json）は役割が異なります。

• 技術的に強制したいこと（ツール拒否・サンドボックス分離・APIプロバイダールーティング・認証強制）→ 管理設定の permissions・sandbox・env・forceLoginMethod で実装
• 行動を誘導したいこと（コードスタイル・データ取り扱いリマインダー）→ 管理CLAUDE.mdで実装

設定はクライアント側で強制されるハードな制御、CLAUDE.mdはClaudeの判断を形作るソフトな誘導、と整理して使い分けます。

CLAUDE.md変更時のレビュー運用

チーム共有のCLAUDE.mdは、通常のコードと同じくプルリクエスト経由で変更するのが定石です。

理由は3点あります。

• CLAUDE.mdの変更はチーム全員のClaude動作に影響する
• 既存ルールとの矛盾を、マージ前にレビューで潰せる
• 「なぜそのルールを追加したのか」を変更履歴に残せる

口頭で同意したルールを誰かが直接コミットしてしまうと、後から「いつ・なぜ入ったか」が分からなくなります。CLAUDE.mdは「プロジェクトのコーディング規約」と同じ重みを持つ成果物として扱うのが、運用が壊れないコツです。

また、CLAUDE.mdが大きくなりすぎた時に分割する判断は、PRレビューの場で意思決定するのが現実的です。「200行を超えた」「あるトピックだけ独立して保守したい」のタイミングで .claude/rules/ への分割を提案し、変更を1つのPRにまとめます。

CLAUDE.mdが効かない時のトラブルシュート

CLAUDE.mdは書いた内容をClaudeが確実に守る保証はありません。公式が「CLAUDE.mdはコンテキストであり強制的な設定ではない」と明示しているとおり、書き方の精度・矛盾の有無・配置場所などで遵守率が変動します。

本セクションでは、「ルールが効いていない」と感じた時に確認すべき項目を、優先度の高い順に整理します。

/memoryで読み込み状態を確認する

ルールが効かない時に最初に確認すべきは、そもそも該当のCLAUDE.mdがセッションに読み込まれているかです。

/memory を実行すると、現在のセッションに読み込まれているCLAUDE.md・CLAUDE.local.md・rulesファイルの一覧が表示されます。期待するファイルがリストに含まれていなければ、Claudeはその内容を見ていません。

読み込まれていない場合の典型的な原因は以下です。

• 配置場所が間違っている（.claude/CLAUDE.md ではなく claude/CLAUDE.md になっているなど）
• claudeMdExcludes 設定でスキップされている
• サブディレクトリ内に置かれていて、Lazy Loadの条件（そのディレクトリ内のファイルを読む）が成立していない

配置パスを再確認し、必要に応じて claudeMdExcludes を見直します。

具体性と矛盾を見直す

ファイルが読み込まれていても、指示が曖昧だったり矛盾していたりすると遵守率が下がります。

「コードを適切にフォーマットする」のような抽象指示は、Claudeが解釈に委ねられるため期待と異なる結果になりがちです。先述の「具体的で検証可能な指示」セクションで触れたとおり、「2スペースのインデント」のように検証できるレベルまで具体化します。

矛盾は特に発見が難しい問題です。複数のCLAUDE.mdファイル間で同じ動作に対する異なる指示が混在していると、Claudeはどちらかを任意に選びます。例えば祖先ディレクトリのCLAUDE.mdに「テストはJest」と書かれていて、起動位置のCLAUDE.mdに「テストはVitest」と書かれていれば、Claudeはどちらに従うか不安定になります。

このときは、/memory でリストアップされた全ファイルを順に確認し、矛盾箇所を整理する作業が必要です。

/compact後の挙動を理解する

長時間のセッションでは、Claude Codeが自動でコンテキストを圧縮（/compact）して古いやり取りを要約することがあります。この圧縮後、CLAUDE.mdの読み込み挙動は2種類に分かれます。

• プロジェクトルートのCLAUDE.md: 圧縮後、Claudeがディスクから再読み込みし、セッションに再注入される
• サブディレクトリのネストされたCLAUDE.md: 自動再注入されない。Claudeがそのサブディレクトリ内のファイルを次に読むまで、再読み込みされない

圧縮後に「ルールが効かなくなった」と感じる場合、ネストされたCLAUDE.mdの再読み込みタイミングが来ていない可能性があります。

恒久的に効かせたいルールはプロジェクトルートのCLAUDE.mdに置くか、.claude/rules/ で起動時から読み込まれる構造にするのが安全です。

Hookや--append-system-promptへの置き換え判断

「特定の時点で必ず実行する必要がある」指示は、CLAUDE.mdの限界を超えています。

例えば「すべてのコミット前にlintを実行する」「ファイル編集後に自動フォーマットを走らせる」のような操作は、CLAUDE.mdに書いてもClaudeが見落とす可能性があります。こうした「固定タイミングで実行が必要」な操作は、Claude Code Hooksに移すのが正解です。

Hookはシステムコマンドとして固定のライフサイクルイベントで実行されるため、Claudeの判断と無関係に確実に発火します。CLAUDE.mdは「Claudeの動作を形作るソフトな誘導」、Hookは「ClaudeのアクションをイベントトリガーでフックするハードC制御」、という役割分担です。

システムプロンプトレベルで強制したい指示には、--append-system-prompt フラグも使えます。ただしこれは対話セッションのたびに渡す必要があるため、対話的な使用よりスクリプトや自動化に向きます。

判断基準は、「Claudeの動作を誘導したい→CLAUDE.md」「特定イベントで確実に実行したい→Hook」「対話の中で常に重視させたい→--append-system-prompt」と覚えると迷いません。

InstructionsLoaded hookで読み込みをログ化する

どのファイルがいつ・なぜ読み込まれたか正確に追跡したい場合、InstructionsLoaded hookが有効です。

このhookはClaude Codeが指示ファイルを読み込んだ瞬間にトリガーされ、読み込まれたファイル名・読み込み理由・読み込みタイミングをログ化できます。

パススコープルールやサブディレクトリ内のLazy Loadファイルなど、通常は読み込みの可視性が低い場面のデバッグに特に有効です。期待するファイルが読まれていない、想定外のファイルが読み込まれている、といった問題を素早く切り分けられます。

トラブルシュートを体系的に進めるなら、まず /memory で表面的に確認し、解決しない場合に InstructionsLoaded hookでログを取って深掘りする、という二段階で進めるのが効率的です。

Claude Codeの料金プランと利用条件

CLAUDE.mdとメモリ機能はClaude Code本体に含まれる機能で、CLAUDE.mdの利用そのものに別途の料金は発生しません。

ただしCLAUDE.mdを使うにはClaude Codeへの認証が必須で、Claude.aiの無料プランではClaude Codeそのものが使えません。サブスクで使う場合はPro以上、サブスクを使わない場合はClaude Consoleアカウント経由のAPI従量課金で利用する2ルートがあります。本セクションでは、2026年6月時点のClaude Codeのプラン体系と利用条件を整理します。

詳細は Claude Codeの料金プラン完全ガイド と Claude Codeの利用制限と対処法 で扱っているため、ここでは概要に絞ります。

個人向けプラン（Pro / Max 5x / Max 20x）

個人向けプランは3段階で、月額と利用枠が変わります。

※ 2026年6月時点。公式: claude.com/pricing

サブスクでClaude Codeを使う場合の最小月額はProプラン（月額$20 / 年払い時$17）で、個人開発者がサブスクでClaude Codeを毎日使うミニマム構成です。サブスクを使わずAPI従量課金で運用するなら、後段の「API・Bedrock・Vertex AI・Foundry経由」で扱うConsoleアカウントルートも選べます。

Max 5xは「フルタイムでClaude Codeに依存する開発者向け」、Max 20xは「複数並行プロジェクトでヘビーユースする上級者向け」という位置づけです。導入判断は「月20時間以上Claude Codeを使うか」を分岐点にして、超えてからMaxへ移行するルートが合理的です。

法人向けプラン（Team Standard / Team Premium / Enterprise）

組織向けにはTeamプラン（StandardとPremiumの2種類のseat）とEnterpriseプランが用意されています。

※ Teamプラン内でStandardとPremiumを混在可能（公式: claude.com/pricing）

Team Standardは2026年1月以降、Claude Codeとドキュメント協業AIのClaude Coworkの両方が含まれるようになり、開発業務とドキュメント業務の境界が曖昧な日本企業でも導入しやすくなりました。

エンタープライズ要件（SSO、SCIM、監査ログ、HIPAA対応など）が必要な場合はEnterpriseプランが必要です。詳細はClaude Codeの企業導入ガイドで扱っています。

API・Bedrock・Vertex AI・Foundry経由

サブスクリプションではなく、APIキー経由でClaude Codeをトークン従量課金で使うルートも用意されています。

• Anthropic API直接: Claude Code CLIから claude auth login --console でConsoleアカウント認証して切り替え
• Amazon Bedrock: AWS環境のセキュリティパイプラインに統合しやすい
• Google Cloud Vertex AI: BigQuery連携などGCPサービスとの併用が前提なら有利
• Microsoft Foundry: M365・GitHub Advanced Securityとの連携を視野に入れるならこちら

AWS・GCP・Azureに既存のクラウド契約がある組織は、それぞれのクラウド経由で従量課金にした方が経費処理面でのメリットがある場合があります。CI/CDでの自動実行や大量バッチ処理で、サブスク利用枠を超えるユースケースでもAPI従量課金が選ばれます。

Agent SDK creditと2026年6月以降の課金変更

非対話的なClaude Code利用については、2026年6月15日以降に重要な課金変更が予定されています。

公式の発表によれば、Claudeサブスクで利用するAgent SDK・claude -p（プリントモード）・GitHub Actions連携は、通常の対話利用枠とは別の月次「Agent SDK credit」を消費する課金扱いに移行します。

• 対話的なClaude Code利用（通常の claude セッション）は従来通りサブスク枠を消費
• 非対話実行（SDK経由・プリントモード・GitHub Action）はAgent SDK creditを別途消費
• Anthropic Console経由のAPIキー利用はAgent SDK creditの対象外で、従来どおりトークン従量課金で動作

CI/CDでClaude Codeを動かしている組織は、Agent SDK creditの残量管理を運用に組み込む必要があります。Team/Enterpriseでは管理者の spend limit 設定で全体の支出枠を縛る運用も並行で検討します。

CLAUDE.md自体の利用には影響しませんが、CLAUDE.mdを使う前提となるClaude Code本体の運用コスト構造が変わる点を、6月以降は意識する必要があります。

CLAUDE.mdをAI業務全体の起点に育てる

CLAUDE.mdでプロジェクトの規約や運用パターンをAIに渡せるようになると、個別の開発タスクだけでなく業務プロセス全体にAIを組み込む素地ができています。

「同じ説明を毎回繰り返さない」「指示を一箇所で管理する」「組織の暗黙知をAIに継承させる」という考え方は、開発業務以外のドメインにもそのまま応用できます。営業・カスタマーサポート・経理・人事——どの部門でも、繰り返し発生する指示を一箇所にまとめてAIに渡す設計が、AI活用の入口になります。

AI総合研究所では、Microsoft環境を起点に部門横断でAIを業務プロセスに組み込む方法を、220ページのガイドで整理しています。CLAUDE.mdで身につけた「AIにルールを渡す」発想を、自社全体のAI業務自動化に展開する第一歩として活用いただけます。

CLAUDE.mdで磨いた設計思想を業務全体のAI化に活かす

AI業務自動化ガイドで部門横断のAI導入を設計する

CLAUDE.mdでプロジェクト規約をAIに渡せる組織は、業務プロセス全体にAIを組み込む素地もできています。AI総合研究所のAI業務自動化ガイドでは、Microsoft環境を起点に部門別ユースケース・PoC設計・統制設計までを220ページで整理しています。

▶ 無料でダウンロード

まとめ

本記事では、CLAUDE.mdの定義から配置スコープ・コマンド操作・効果的な書き方・分割管理・自動メモリ・チーム運用・トラブルシュート・料金プランまで、2026年6月時点の公式仕様で整理しました。要点を改めてまとめます。

• CLAUDE.mdは「毎回伝え直していた指示」を恒久化する基幹ファイル
  Claude Codeが各セッション開始時に自動読み込みする指示ファイルで、ビルドコマンド・規約・アーキテクチャ方針を一箇所で管理できる。自動メモリ・Skills・.claude/rulesは別系統で、CLAUDE.mdは「常時ロード・あなたが書く・短く具体的」が特徴
  
  

• 配置スコープは4種類、起動時は上方探索・サブディレクトリはLazy Load
  管理ポリシー・ユーザー指示・プロジェクト指示・ローカル指示の4スコープを使い分け、モノレポでは claudeMdExcludes で関係のない他チームのファイルをスキップする
  
  

• /initで雛形生成→具体化が標準ルート
  CLAUDE_CODE_NEW_INIT=1 で対話式マルチフェーズも利用可能。全文編集は /memory、軽い追記はClaudeに「CLAUDE.mdに追加して」と明示依頼するのが場面ごとの使い分け
  
  

• 書き方の核は「200行以下・具体・構造化」
  公式は200行以下を推奨。検証可能な指示・ポジティブとネガティブの両方を書き、定期的に矛盾を見直す。長くなったら .claude/rules/ で分割し、@import で外部ファイル参照を組み合わせる
  
  

• 自動メモリ（Auto memory）はClaudeが書く別系統
  ~/.claude/projects/<project>/memory/MEMORY.md がエントリポイントで、200行・25KBの起動時ロード制限がある。autoMemoryDirectory で保存先カスタマイズ可能（v2.1.59以降）
  
  

• チーム運用はGit管理3層、組織標準は管理ポリシーで配布
  プロジェクトCLAUDE.mdをGitコミット、個人用はCLAUDE.local.md、組織標準は管理ポリシーCLAUDE.mdまたは managed-settings.json の claudeMd キーで配布する
  
  

• 「効かない」時は読み込み確認→具体性→Hook化の順で対処
  /memory で読み込み状態を確認、矛盾と曖昧さを潰し、固定タイミングで実行が必要な指示はHooksへ移す。/compact 後のサブディレクトリCLAUDE.md挙動も理解しておく
  
  

• CLAUDE.mdは追加料金なし、Claude Code本体はPro以上のサブスクかConsoleアカウントが必要
  Claude.aiの無料プランではClaude Code自体が使えない。サブスクなら Pro $20/月、サブスクを使わないならClaude Consoleアカウントの API 従量課金ルートも選べる

CLAUDE.mdを整備する作業は、最初の数時間で完了する小さな投資です。一方で、その投資は「毎回伝え直す手間」を恒久的に消し、チーム全員のClaudeとの協働品質を底上げします。まずは /init で雛形を生成し、プロジェクトの実情に合わせて少しずつ加筆していくところから始めてみてください。