TL;DR
- Claude Codeは、作業ディレクトリから上位へたどって
CLAUDE.mdを読み込む - 子ディレクトリの
CLAUDE.mdは、配下のファイルへアクセスしたときに読み込まれる -
Globの検索先を省略した場合、現在の作業ディレクトリが基準になる -
--add-dirや/add-dirはアクセス範囲を増やすが、追加先を完全な設定ルートにはしない - 無関係なタスクへ移るときは
/clearでコンテキストを分ける
フォルダ整理でモデル性能そのものが上がるわけではありません。起点ディレクトリによって、最初に与えられる指示、標準の探索範囲、発見される設定が変わるため、同じプロンプトでも結果が変わり得ます。
この記事は2026年8月25日時点の公式ドキュメントを整理したものです。特定バージョンのClaude Codeで、整理前後の精度・速度・トークン数を比較する実機ベンチマークは実施していません。
対象読者と調査範囲
対象は、Claude Codeをプロジェクトのどのディレクトリから起動すべきか迷っている人です。
確認した一次資料は次の5ページです。
- How Claude remembers your project
- Best practices for Claude Code
- Configure permissions
- Tools reference
- Explore the context window
調査日：2026年8月25日
検証環境：公式Webドキュメントのみ。OS、Claude Codeのローカルバージョン、モデルによる比較検証は未実施です。
問題：同じプロンプトでも参照する前提が変わる
たとえば、次のプロジェクトを考えます。
projects/
├── CLAUDE.md
└── client-a/
├── CLAUDE.md
└── web-app/
├── CLAUDE.md
├── src/
└── tests/
projects/client-a/web-appから起動した場合、Claude Codeは現在の作業ディレクトリから上位へたどり、見つかったCLAUDE.mdとCLAUDE.local.mdを読み込みます。
公式ドキュメントでは、内容はファイルシステムのルート側から作業ディレクトリ側の順でコンテキストへ追加されると説明されています。複数ファイルは上書きではなく連結されます。
そのため、起点を変えると次の条件が変わります。
| 条件 | 起点による影響 |
|---|---|
| 起動時の指示 | 作業ディレクトリと上位階層のCLAUDE.mdが変わる |
| ファイル探索 | パス未指定のGlobは作業ディレクトリを基準にする |
| プロジェクト設定 | 多くの設定は作業ディレクトリと親から発見される |
| 会話の文脈 | 同じセッションで読んだファイルやコマンド出力が残る |
CLAUDE.mdの読み込みを分けて考える
起動時に読み込まれるもの
作業ディレクトリと、その上位階層にあるCLAUDE.mdおよびCLAUDE.local.mdが対象です。
プロジェクト用のCLAUDE.mdは、プロジェクトルートの次のいずれかへ置けます。
./CLAUDE.md
./.claude/CLAUDE.md
読み込まれたファイルは、セッション中の/contextにある「Memory files」で確認できます。
子ディレクトリで必要になったときに読み込まれるもの
作業ディレクトリより下にあるCLAUDE.mdは、起動時にすべて読み込まれるわけではありません。Claudeがその配下のファイルへアクセスしたときに読み込まれます。
したがって、「フォルダ階層が深いだけで、全ファイルと全ルールが起動時のコンテキストへ入る」という理解は正確ではありません。
指示が矛盾した場合
複数のCLAUDE.mdは連結されるため、上位と下位で矛盾する規則を書けます。
公式ドキュメントは、矛盾した指示がある場合、Claudeが任意の一つを選ぶ可能性があると注意しています。階層を作るだけでなく、定期的に重複と矛盾を確認する必要があります。
ファイル検索は「名前だけ」ではない
Claude Codeの公式ツールには、次の機能があります。
| ツール | 役割 |
|---|---|
Glob |
パターンに一致するファイルを探す |
Grep |
ファイル内容を正規表現で検索する |
Read |
ファイル本文を読む |
分かりやすいファイル名はGlobや人間の判断に役立ちますが、Claude Codeがファイル名しか見ないわけではありません。
また、Globの検索パスを省略すると、現在の作業ディレクトリが基準になります。このため、プロジェクトから離れた上位フォルダで起動すると検索範囲が広がり、深いサブディレクトリで起動すると必要な周辺ファイルへ届きにくくなる可能性があります。
--add-dirは起点の移動ではない
別ディレクトリをアクセス対象へ追加する公式の方法は、次のとおりです。
claude --add-dir ../shared-config
セッション中は次のコマンドを使えます。
/add-dir ../shared-config
ただし、追加ディレクトリは元の作業ディレクトリと同じ設定ルートにはなりません。
公式ドキュメントによると、スキルなど一部の例外を除き、サブエージェント、フック、出力形式などは元の作業ディレクトリ、その親、ユーザーディレクトリ、管理対象設定から発見されます。
追加先のCLAUDE.mdも、既定では読み込まれません。読み込むにはCLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1が必要です。
実務で採用する3ステップ
1. 変更なしで構成を調査する
ファイルを移動する前に、対象プロジェクトのルートから次のように依頼します。
このフォルダ以下を変更せずに調査してください。
構成を3階層まで整理し、次を指摘してください。
- 役割が分かりにくい名前
- 原本と成果物の区別がつかない場所
- 重複している可能性があるファイル
- 移動するとリンクや設定が壊れる可能性がある箇所
まだ移動、改名、削除はしないでください。
これはプロンプト例であり、本記事では実行結果を測定していません。
2. 読み込まれた指示を確認する
/contextを実行し、「Memory files」に意図したCLAUDE.mdがあるか確認します。
同時に、上位と下位でテストコマンド、編集禁止領域、命名規則が矛盾していないか確認します。
3. 無関係なタスクの文脈を分ける
同じ不具合の調査、修正、テストは一つのセッションで扱えます。
別機能や別案件へ移る場合は、必要に応じて/renameで現在のセッションへ名前を付け、/clearで新しいコンテキストを始めます。後から戻る場合は--resumeを使えます。
最小のCLAUDE.md例
次は構成例であり、特定プロジェクトでの動作確認済みファイルではありません。実際のコマンドとパスへ置き換えてください。
# Project instructions
## Purpose
このリポジトリは顧客向けWebサイトを開発する。
## Important paths
- `src/`: アプリケーションコード
- `tests/`: 自動テスト
- `docs/`: 確定した要件と設計判断
## Commands
- 変更後に`npm test`を実行する
- コミット前に`npm run lint`を実行する
## Safety
- `.env`と顧客データを開かない
- 既存の未コミット変更を上書きしない
- 大量の移動・改名は、先に計画と対象一覧を提示する
公式ドキュメントは、CLAUDE.mdを1ファイル200行未満にすることを目安としています。毎回必要でない長い手順はSkill、特定パスだけに必要な指示は.claude/rules/へ分けます。
制約と未検証事項
- フォルダ整理前後の回答精度を比較していない
- 実行時間、トークン量、コストを測定していない
- OSやClaude Codeのバージョン差を検証していない
- デスクトップアプリの画面操作を検証していない
- サンプルのフォルダ構成と
CLAUDE.mdは説明用である
したがって、「整理すると精度が何％上がる」とは結論づけられません。
確認できるのは、起点ディレクトリによって読み込まれる指示、探索の基準、発見される設定が変わるという仕様です。
まとめ
Claude Codeの起点ディレクトリは、単なるファイル選択ではありません。
起点によって、CLAUDE.md、探索範囲、設定の発見範囲が変わります。無関係なタスクを同じセッションへ詰め込めば、会話側のコンテキストも増えます。
実務では、次の順で確認します。
- 一案件を見渡せるプロジェクトルートから起動する
-
/contextで読み込まれた指示を確認する - ファイル操作前に変更なしの調査と影響範囲の一覧化を行う
- 無関係なタスクへ移るときはセッションを分ける
フォルダ設計はモデルの知能を上げる方法ではなく、Claude Codeへ適切な仕事の境界を渡す設計です。