TL;DR

CLAUDE.mdは、人間が書くプロジェクトの永続的な指示であり、強制設定ではない
初心者はプロジェクトルートの./CLAUDE.mdから始めると適用範囲を理解しやすい
作業ディレクトリと上位階層のファイルは、ファイルシステムのルート側から作業場所側の順で連結される
矛盾する指示は確実に上書きされず、Claudeが任意の一つを選ぶ可能性がある
常時必要な前提はCLAUDE.md、特定パスは.claude/rules/、必要時の長い手順はSkills、強制処理はHooksへ分ける
1ファイル200行未満が公式の目安だが、短さだけで指示遵守は保証されない

本記事は、2026年9月1日にClaude Code公式ドキュメントで確認した仕様を整理したものです。特定バージョンでの実機比較、精度測定、トークン測定は行っていません。

対象読者と確認範囲

対象は、次のような状況にあるClaude Code利用者です。

セッションごとに同じテスト方法や禁止事項を説明している
CLAUDE.mdをどこへ置けばよいか分からない
CLAUDE.mdとAuto Memoryの違いが曖昧
指示ファイルが長くなり、RulesやSkillsへ分割したい

確認したのは、公式ドキュメントに記載された配置、読み込み、コンテキスト、Auto Memory、Rules、Skills、Hooksの仕様です。

次の内容は検証していません。

導入前後の回答精度
作業時間、トークン、コストの変化
OSやClaude Codeバージョンごとの画面差
サンプル設定の実プロジェクトでの実行結果

確認環境

確認日：2026年9月1日
情報源：Claude Code公式ドキュメント
実機OS：未指定。本記事ではOS共通の概念と、公式に掲載されたWindowsの管理パスを扱う
Claude Codeバージョン：特定バージョンでの実行検証なし
公式上の要件：Auto MemoryはClaude Code 2.1.59以降、/doctorによるCLAUDE.md整理提案は2.1.206以降

利用中のバージョンはclaude --versionで確認してください。本記事のサンプルコマンドは実行結果を伴わない説明用です。

`CLAUDE.md`の役割

Claude Codeの各セッションは、新しいコンテキストから始まります。

CLAUDE.mdは、人間が書いたプロジェクト固有の指示を、対象セッションのコンテキストへ読み込むためのMarkdownファイルです。

公式ドキュメントでは、次のような情報の保存先として案内されています。

ビルド、テスト、Lintのコマンド
コーディング規約
プロジェクト構成
アーキテクチャ上の判断
命名規則
共通ワークフロー

CLAUDE.mdがなくても、Claude Codeのファイル探索、編集、コマンド実行は利用できます。

ただし、コードから推測できないプロジェクト固有の前提は、プロンプトまたは別の仕組みで渡す必要があります。CLAUDE.mdはモデルの能力を変更するのではなく、毎回必要な前提を同じ場所から渡します。

CLAUDE.mdはコンテキストであり、強制設定ではありません。アクセス制御や確実なブロックが必要な場合は、権限、サンドボックス、PreToolUse Hookなどを検討します。

配置場所と適用範囲

主な配置場所は次のとおりです。

スコープ	場所	用途
組織管理	Windowsでは`C:\Program Files\ClaudeCode\CLAUDE.md`	IT・管理者が配布する組織共通規則
ユーザー	`~/.claude/CLAUDE.md`	全プロジェクトで使う個人の好み
プロジェクト	`./CLAUDE.md`または`./.claude/CLAUDE.md`	チーム共有する規約、コマンド、設計判断
ローカル	`./CLAUDE.local.md`	個人用のプロジェクト設定。通常は`.gitignore`へ追加

一案件だけの規則をユーザースコープへ入れると、無関係なプロジェクトにも適用されます。

最初は、チームで共有すべき内容をプロジェクトルートの./CLAUDE.mdへ置き、個人だけの設定を./CLAUDE.local.mdへ分けると理解しやすくなります。

読み込み順と下位ディレクトリの扱い

たとえば、次の構成を考えます。

work/
├── CLAUDE.md
└── client-a/
    ├── CLAUDE.md
    └── web-app/
        ├── CLAUDE.md
        ├── src/
        └── tests/

work/client-a/web-app/からClaude Codeを開始すると、現在の作業ディレクトリと上位階層のCLAUDE.md、CLAUDE.local.mdが読み込まれます。

公式仕様では、ファイルシステムのルート側から作業ディレクトリ側の順でコンテキストへ連結されます。

ここで「後に読まれた指示が必ず勝つ」と考えるのは危険です。

複数ファイルに矛盾する指示がある場合、Claudeが任意の一つを選ぶ可能性があります。上位の規則を下位で打ち消すのではなく、上位には全案件で共通する内容だけを置きます。

作業ディレクトリより下にあるCLAUDE.mdは、起動時にすべて読み込まれません。Claudeがその配下のファイルを読むときに読み込まれます。

実際に現在のセッションへ読み込まれたファイルは、/contextの「Memory files」で確認できます。

HTMLコメントはコンテキスト投入前に除去される

コードブロック外にあるHTMLのブロックコメントは、CLAUDE.mdがコンテキストへ投入される前に除去されます。

<!-- 2026年10月の移行完了後にこの項目を見直す -->

人間の保守担当者向けメモを、通常のコンテキストコストなしで残せます。

ただし、ClaudeがReadツールでCLAUDE.md自体を開く場合はコメントも見えます。コードブロック内のコメントも除去対象ではありません。

Auto Memoryとの違い

CLAUDE.mdとAuto Memoryは、どちらもセッションをまたいで情報を扱いますが、役割が異なります。

項目	`CLAUDE.md`	Auto Memory
主な書き手	人間	Claude
内容	指示、規則、構成、ワークフロー	学び、訂正、デバッグ知識、繰り返し使えるパターン
スコープ	組織、ユーザー、プロジェクト、ローカル	リポジトリ単位。worktree間で共有
共有	プロジェクト版はGitで共有可能	既定では端末内だけ
起動時の読み込み	対象ファイルを読み込む	`MEMORY.md`の先頭200行または25KBまで

Auto Memoryの保存先は、既定では~/.claude/projects/<project>/memory/です。

Claudeが自動で書いた情報にも、古い前提や誤った推測が含まれる可能性があります。/memoryから内容を確認、編集、削除できます。

最小の`CLAUDE.md`例

次は構成例です。実在するコマンドやパスを確認していないため、そのまま動作確認済み設定として使用しないでください。

# Project instructions

## Purpose

このリポジトリは顧客向けWebアプリを開発する。

## Important paths

- `src/`: アプリケーションコード
- `tests/`: 自動テスト
- `docs/`: 確定した要件と設計判断
- `tmp/`: 削除可能な一時ファイル

## Commands

- パッケージ管理には`pnpm`を使う
- 変更後に`pnpm test`を実行する
- 完了前に`pnpm lint`を実行する

## Project rules

- 公開APIの変更前に影響範囲を説明する
- 新しい依存関係の追加前に目的と代替案を提示する
- 既存の未コミット変更を上書きしない

## Safety

- `.env`、顧客データ、秘密鍵を読み書きしない
- 原本を直接編集しない
- 大量の移動・改名・削除は対象一覧と戻し方を先に提示する

## Definition of done

- 関連テストとLintが成功している
- 変更内容、確認結果、未確認事項を報告する

書く候補は、Claudeが毎回知る必要があり、リポジトリから正確に推測しにくい情報です。

反対に、次の内容は除外候補です。

コードやpackage.jsonから分かる長い説明
一般的な言語仕様
「きれいに実装する」のような曖昧な指示
頻繁に変わる一時的な進捗
今回だけの長い作業手順
APIキー、パスワード、個人情報、顧客の秘密情報

`CLAUDE.md`・Rules・Skills・Hooksの選択

内容は「いつ必要か」で分けます。

仕組み	読み込み・実行	適する内容
`CLAUDE.md`	セッション開始時	毎回必要なプロジェクト規約とコマンド
`.claude/rules/`	毎回、または一致するパスのファイルを読むとき	言語・ディレクトリ・ファイル種別ごとの規則
Skills	関連時または明示的な呼び出し時	API資料、デプロイ、レビューなどの知識と手順
Hooks	指定したライフサイクルイベント時	自動検査、監査、特定操作のブロック

パス指定Ruleの構成例は次のとおりです。

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

# API rules

- すべての入力を検証する
- エラー応答はプロジェクトの共通形式を使う
- エンドポイント変更時は関連テストも更新する

このRuleは、Claudeがパターンに一致するファイルを読むときに読み込まれます。

@README.mdのようなインポートは、ファイル整理には使えます。ただし、インポート先も起動時のコンテキストへ入るため、単純な分割ではコンテキスト量を削減できません。

200行は上限保証ではない

公式ドキュメントでは、1つのCLAUDE.mdを200行未満に保つことが目安とされています。

長いファイルはコンテキストを消費し、指示が守られにくくなる可能性があります。ただし、200行未満なら必ず守られるという意味ではありません。

各行について、次を確認します。

削除するとClaudeが実際に間違えやすくなるか
コードから推測できない情報か
すべてのセッションで必要か
他の指示と矛盾していないか
実行結果を確認できる表現か

/doctorには、Gitで管理されたCLAUDE.mdから、コードで分かる説明を削って非自明な注意点を残す整理提案があります。提案を採用する前に差分を確認します。

導入と確認の手順

リポジトリを変更せず、毎回必要で推測しにくい情報を抽出する
目的、重要なパス、検証コマンド、規則、安全境界、完了条件へ分類する
実在するパスとコマンドを人間が確認する
プロジェクトルートへ短いCLAUDE.mdを作る
新しいセッションで/contextを実行し、読み込みを確認する
小さなタスクで期待する行動が選ばれるか確認する
不要な行を削り、特定用途の内容をRulesやSkillsへ移す

本記事では、この手順による精度や時間の改善を測定していません。

制約と公開前の確認事項

Claude Codeのバージョンによって利用できるコマンドや表示が異なる可能性がある
組織の管理ポリシーによって設定可能な範囲が異なる
サンプルのpnpmコマンドは説明用であり、対象リポジトリでの実行結果はない
CLAUDE.mdだけでは危険操作を確実に防止できない
導入効果を示す場合は、同じタスク、同じ環境、同じ評価基準で比較する必要がある

まとめ

CLAUDE.mdは、Claude Codeへ毎回必要なプロジェクト固有の前提を渡す仕組みです。

プロジェクトルートへ短いファイルを置き、推測しにくいコマンド、規則、安全境界、完了条件へ絞ります。

長くなった場合は、単純に分割するのではなく、特定パスのRules、必要時のSkills、強制処理のHooksへ役割を移します。

最後に/contextで読み込みを確認し、小さなタスクで行動が変わったかを検証します。

参考資料