この記事で分かること
Claude CodeのCLAUDE.mdを置いたのに指示が効かない、どこに置けばいいか分からないという方向けに、配置場所の正しい選び方と、効いているかを確認する手順をまとめました。結論から言うと、原因の多くは置き場所の誤りか、ファイルの肥大化によって肝心の指示が埋もれていることにあります。
CLAUDE.mdはプロジェクト直下の./CLAUDE.mdか./.claude/CLAUDE.md、全プロジェクト共通は~/.claude/CLAUDE.mdに置くことができ、毎回の会話の開始時に自動で読み込まれます。この記事では、どの場所に何を書くべきかの判断基準、再現できる確認手順、よくある失敗とその対策を順番に説明します。
配置場所の判断基準
CLAUDE.mdをどこに置くべきかは、その指示を「誰に」「どの範囲で」効かせたいかで決まります。
- 全プロジェクトで共通のルール（例: 自分の口調の好み、よく使うコマンドの好み）は
~/.claude/CLAUDE.md - 特定のプロジェクトだけに関係するルール（例: このプロジェクトの固有名詞の表記、禁止事項）は
./CLAUDE.mdか./.claude/CLAUDE.md
CLAUDE.mdは1ファイル200行未満が目安とされており、同じミスが2回起きたら追記する運用が公式に推奨されています。1回目は偶発的な事故、2回目は指示不足のサインと捉えると、追記するかどうかの判断がぶれません。
初めてCLAUDE.mdを作る場合は、/initでコードベースを解析した下書きを作成できます。ただし下書きのまま放置せず、フォルダ構造から読み取れる内容（ディレクトリ構成の説明など）は削り、AIが推測できないことだけを残すのが実務上の近道です。推測できないこととは、固有名詞の正しい表記、禁止事項、成果物の提出先、過去に起きた失敗とその回避策などです。
再現できる確認手順
CLAUDE.mdが実際に読み込まれているかどうかは、感覚ではなくコマンドで確認できます。
- Claude Codeを起動し、作業したいプロジェクトのフォルダに移動します
- 会話欄で
/contextと入力します - 色付きのグリッドが表示され、CLAUDE.mdが読み込まれているかどうかを含めた文脈の使用量が確認できます
- 設定全体に不安がある場合は
/doctorで設定の点検を行います。/doctorはCLAUDE.mdについて、コードから分かる内容を削る提案も出してくれます - CLAUDE.mdの中身を直接編集したい場合は
/memoryと入力します。/memoryはCLAUDE.mdの編集と、自動メモリのオンオフ切り替えに使えます
この5ステップを実行するだけで、「書いたのに効かない」が「ファイルが読み込まれていない」のか「読み込まれているが指示が曖昧」なのかを切り分けられます。
具体例: 書くべきこと・書かないこと
実際にCLAUDE.mdへ書く内容を迷ったときは、次の基準で仕分けます。
書くべきこと
## 表記ルール
- 社名は「株式会社サンプル」と正式表記する（「(株)サンプル」は禁止）
## 提出前の確認
- 変更後は必ずビルドを通し、エラーが出ていないことを確認してから報告する
## 過去の失敗
- 以前、テストファイルを本番コードと誤認して削除した。testディレクトリ配下は削除前に必ず確認を取る
書かないこと
- フォルダ構成の説明（ソースを見れば分かるため）
- 頻繁に変わる今週の目標やタスク
- 手順が多い定型作業の詳細（これはスキルへ移すのが適切です）
手順が多く繰り返し使う作業は、CLAUDE.mdではなくスキルとして切り出します。スキルはSKILL.mdに手順を書いたもので、~/.claude/skills/<名前>/SKILL.mdかプロジェクトの.claude/skills/<名前>/SKILL.mdに置き、関係する場面でClaudeが自動で使うか/スキル名で直接呼び出せます。SKILL.mdの記述例は次のような形です。
---
name: 週報作成
description: 週次の作業ログから報告用のサマリーを作成する
---
## 手順
1. 対象週のログファイルを読み込む
2. 完了タスクと未完了タスクに分類する
3. 指定フォーマットでMarkdownを出力する
このように、CLAUDE.mdには「常に効かせたい短いルール」だけを残し、手順が多いものはスキル側に逃がすことで、肝心の指示が埋もれるのを防げます。
失敗例と対策
失敗例1: 下位フォルダに置いたのに読み込まれない
深い階層のサブフォルダに置いたCLAUDE.mdが、起動時に反映されないケースがあります。対策として、まず /context でそのファイルが読み込み対象に入っているかを確認し、入っていなければ起動場所をプロジェクトのルートに変えるか、ルールをプロジェクト直下のCLAUDE.mdに統合します。
失敗例2: ファイルが太って指示が無視される
書き足し続けた結果、ファイルが長大になり、本当に守ってほしい指示が埋もれてしまうケースです。対策は、200行未満を目安に定期的に見直し、フォルダ構成の説明など「コードを見れば分かること」を削ることです。/doctorはこうした削れる内容の提案も出してくれます。
失敗例3: 長いセッションで会話を圧縮したら指示の効きが変わった
長時間の作業で文脈が膨らんだときに使う /compactは、ここまでの会話を要約して文脈の空きを作るコマンドで、要約で残す焦点を指示として渡せます。ただし要約は会話の内容を圧縮するものであり、会話とは別に毎回読み込まれるCLAUDE.md自体が消えるわけではありません。挙動に違和感があれば、要約後に /context で読み込み状況を再確認すると安心です。
初心者向けの最小構成
初めてCLAUDE.mdを作る場合は、次の3ステップで十分です。
- プロジェクトのルートフォルダで
claudeを起動し、/initでコードベースを解析した下書きを作る - 下書きから「コードを見れば分かること」を削り、固有名詞の表記・禁止事項・提出先だけを残す
- 作業を進める中で同じ指摘を2回受けたら、そのルールを1行追記する
これだけで、ゼロから書くより早く、かつ無駄のないCLAUDE.mdが用意できます。
中上級者向けの応用
運用に慣れてきたら、次の2点を意識すると文脈の無駄遣いを防げます。
- 関係のない作業に移るときは/clearを使う: /clearは空の文脈で新しい会話を始めるコマンドで、直前の会話は/resumeで戻れます。CLAUDE.mdは次の会話でも自動で読み込まれるため、ルールが消える心配はありません。
- 手順が多い作業はスキルへ移す: CLAUDE.mdに手順を書き込み続けるとファイルが太りますが、スキルは呼ばれたときだけ読み込まれるため、常時の文脈消費を抑えられます。
/compact・/clear・/rewindの使い分け
長時間の作業でセッションが重くなったときに迷いやすい3つのコマンドを比較します。
| コマンド | 何が起きるか | 向いている場面 |
|---|---|---|
| /compact | 会話を要約して文脈の空きを作る。残す焦点を指示できる | 同じ作業を続けながら文脈を軽くしたいとき |
| /clear | 空の文脈で新しい会話を始める。直前の会話は/resumeで戻せる | 全く別の作業に切り替えるとき |
| /rewind | 「コードと会話」「会話のみ」「コードのみ」を選んで巻き戻す。入力欄が空の状態でEscを2回押しても開く | 直前の変更や指示をやり直したいとき |
巻き戻しにはBashコマンドで変更したファイルは対象外という制限があります。スクリプト実行で消したファイルなどは/rewindでは戻らないため、重要なファイルを操作する前にバックアップを取っておくと安心です。
実践で分かったこと
CLAUDE.mdは「書いて終わり」ではなく、日々の運用の中でどう扱うかで実用性が変わります。ここでは実際に続けている運用のうち、この記事のテーマに関係する2点を紹介します。
1. Vaultの最上位にCLAUDE.mdを1つだけ置き、毎回の作業ルールを集約
ObsidianのVault（ナレッジを溜めるフォルダ）の一番上にCLAUDE.mdを置き、Claude Codeを起動するたびに自動で読み込まれる前提で運用ルールを書いています。フォルダごとに別々のCLAUDE.mdを作らず、まず1つの入口に集約しているのは、サブフォルダに置いたCLAUDE.mdは起動時に自動で読み込まれるとは限らないため、読み込み漏れによる「指示が効かない」事故を防ぐためです。これにより、どのフォルダで作業を始めても同じルールが確実に効く状態を保てています。
2. バックアップはGitHubリポジトリへ15分ごとに自動同期
Vault全体を非公開のGitHubリポジトリに15分ごとに自動で同期しています。CLAUDE.mdやナレッジファイルはClaude Codeの作業対象でもあるため、誤って削除や上書きが起きても15分前の状態まで遡って復元できる体制にしているのが理由です。これにより、ローカルの操作ミスでナレッジ全体を失うリスクを防げています。なお、/rewindによる巻き戻しはBashコマンドで変更したファイルには対象外という制限があるため、CLAUDE.md自体のような重要ファイルは、Claude Code側の巻き戻し機能だけに頼らず、別経路のバックアップで補っておくのが安全です。
この図は、CLAUDE.mdを新規作成してから運用に乗せるまでの作業順序を軸に、/initでの下書き作成から見直しまでの流れを示します。矢印の順番通りに進めれば迷わず最小構成を作れるので、まだCLAUDE.mdを持っていない方はこの流れをそのまま最初の作業手順として使ってください。
一般的なやり方と運営者の運用の比較
CLAUDE.mdの運用方法は一通りではありません。一般的に紹介される手順と、実際に続けている運用を比較します。
| 項目 | 一般的な手順 | 運営者の運用とその理由 |
|---|---|---|
| 配置場所 | プロジェクトごとに./CLAUDE.mdを作る | Vaultの最上位に1つだけ置く。サブフォルダのCLAUDE.mdは起動時に自動で読み込まれないため、入口を1つに絞って読み込み漏れを防いでいる |
| ファイルの保護 | /rewindでの巻き戻しに任せる | GitHubリポジトリへ15分ごとに自動同期。/rewindはBashコマンドで変更したファイルを戻せないため、別経路でバックアップを確保している |
| 追記のタイミング | 気づいたときに随時追記する | 同じ指摘を2回受けたタイミングで1行追記する。1回目は偶発的な事故、2回目は指示不足と判断基準を決めている |
この図は、書きたい内容を軸に、CLAUDE.md・paths付きルール・スキルのどれに書くべきかの分岐を示します。自分が今書こうとしているルールがどの分岐に当てはまるかをたどり、該当する置き場所にそのまま書き始めてください。
FAQ
Q. CLAUDE.mdを置いたのに指示が全く反映されません。何から確認すべきですか。
A. まず /context を実行し、CLAUDE.mdが読み込み対象に含まれているかを確認してください。含まれていない場合は、ファイルの配置場所がプロジェクトのルート（./CLAUDE.mdまたは./.claude/CLAUDE.md）になっているかを見直します。含まれているのに効かない場合は、ファイルが長すぎて肝心の指示が埋もれている可能性があるため、/doctor で点検してみてください。
Q. 全プロジェクト共通のルールとプロジェクト固有のルールを両方使えますか。
A. はい。~/.claude/CLAUDE.mdは全プロジェクト共通、./CLAUDE.mdはプロジェクト固有として使い分けられ、両方の内容は上書きではなく追記される形で読み込まれます。共通の好みは上位に、個別プロジェクトの事情は直下に書くとすっきり整理できます。
Q. CLAUDE.mdとスキルはどう使い分ければよいですか。
A. 常に効かせたい短いルール（表記、禁止事項、過去の失敗）はCLAUDE.mdに、手順が多い定型作業はSKILL.mdとしてスキルに切り出し、関係する場面で自動的に、または/スキル名で呼び出すのが基準です。スキルは呼ばれたときだけ読み込まれるため、CLAUDE.mdを太らせずに済みます。
Q. 長時間の作業でCLAUDE.mdの指示が効かなくなることはありますか。
A. CLAUDE.md自体は毎回の会話の開始時に読み込まれる仕組みのため、長時間の作業中に消えるものではありません。ただし文脈全体が膨らんで指示が埋もれて見えることはあるため、/contextで現状を確認し、関係ない作業に移るときは/clearで新しい会話を始めると整理しやすくなります。
まとめ
CLAUDE.mdが効かないと感じたときは、感覚で書き直す前に /context で読み込み状況を確認することが近道です。配置場所は全プロジェクト共通かプロジェクト固有かで決め、書く内容は「AIが推測できないこと」に絞り、手順が多いものはスキルへ逃がすと、ファイルが太らず指示も埋もれません。同じ指摘を2回受けたら1行追記するという基準を持っておけば、CLAUDE.mdは使うほどに積み上がる仕事環境として機能します。
CLAUDE.mdの運用をもっと整えたい方へ、公式LINEで「Claude Code×ひとり起業 10大キット」を無料で受け取れます
コメント