CLAUDE.md — 会話をまたいで前提を引き継がせる

AIは前回の会話を覚えていないため、日を改めて作業を頼むたびに、同じ前提を説明し直すことになる。この章を読むと、一度書いておけば以降の会話すべてで自動的に読み込まれる仕組みが分かる。何を書き、どこに置き、どう書けば守られるかまで決められるようになる。

章	タイトル
1	CLAUDE.mdとは
2	CLAUDE.mdのメリット
3	CLAUDE.mdに何を書くか
4	CLAUDE.mdの置き場所と効く範囲
5	CLAUDE.mdの書き方のコツ
6	CLAUDE.mdの具体例

1. CLAUDE.mdとは

CLAUDE.md という名前のファイルを作っておくと、Claude Codeは会話の開始時に必ずそれを読む。

中身はただのテキストである。特別な書式は要らない。

# このプロジェクトについて

初心者向けの学習資料を作っている。

## 書き方のルール

- 専門用語は初出時に説明を付ける
- 一文を短くする
- 断定を避けた曖昧な表現にしない

これを置いておけば、毎回説明し直す必要がなくなる。

2. CLAUDE.mdのメリット

AIは、前回の会話を覚えていない。 作業を終えてClaude Codeを閉じ、翌日また開いて話しかけると、前日に伝えたことは残っていない。同じ日でも、「基本的なコマンド — 会話の整理と状態確認をスラッシュコマンドで行う」で見た /clear を打てば同じことが起きる。

そのため、毎回同じ説明をすることになる。

【前回】
自分:この資料は初心者向けだから、専門用語には説明を付けて
AI :承知しました
（作業する)

（日を改めて開く)

【今回】
自分:この資料を直して
AI :（専門用語をそのまま使って直す)
自分:初心者向けだから説明を付けて…    ← また同じ説明

作業のたびに前提を伝え直すのは面倒であり、伝え忘れれば結果もぶれる。

CLAUDE.mdに書いておけば、この繰り返しが無くなる。会話が切り替わっても、書いた前提は引き継がれる。 書くのは一度だけで、以降の会話には自動的に効く。伝え忘れによる結果のぶれも防げる。

3. CLAUDE.mdに何を書くか

書くとよいこと

AIが見ても分からないことを書く。

種類	例
方針	「初心者向け。専門用語には説明を付ける」
書き方の決まり	「見出しは3階層まで」「箇条書きは中黒を使う」
用語の統一	「"ユーザー"ではなく"読者"と書く」
やってほしくないこと	「既存の見出し構成は変えない」
手順	「新しい記事を追加したら、目次にも追記する」

書かなくてよいこと

AIが自分で調べれば分かることは書かない。

書かなくてよい	理由
フォルダの中身の一覧	見れば分かる
ファイルが何行あるか	読めば分かる
各ファイルの要約	開けば分かる

書いても害は少ないが、無駄に長くなる。長さは5章「CLAUDE.mdの書き方のコツ」の通り不利に働く。

追記する判断基準

迷ったときの目安は1つでよい。

同じ説明を2回したら書く。

1回目は偶然かもしれない。2回言ったなら、3回目も言うことになる。その時点でCLAUDE.mdに移す。

会話の中で「これは毎回言っているな」と気づいたら、その場でAIに頼めばよい。

今の指示をCLAUDE.mdに追記して

4. CLAUDE.mdの置き場所と効く範囲

CLAUDE.mdは複数の場所に置ける。よく使うのは次の2つになる。

置き場所	効く範囲	何を書くか
プロジェクトの `CLAUDE.md`	そのプロジェクトでの作業	プロジェクト固有のルール
`~/.claude/CLAUDE.md`	すべての作業	自分の好み・共通の方針

プロジェクト側は、その直下に置く。

資料/
├── CLAUDE.md      ← ここ
├── 企画.md
└── 名簿.csv

~ は自分のユーザーフォルダを指す。ここに置いたものは、どのフォルダで作業していても読み込まれる。

使い分けの考え方は次の通りである。

その資料だけの決まり → プロジェクト側
自分がいつもそうしたいこと → ユーザーフォルダ側

たとえば「です・ます調で書く」が自分の一貫した好みなら、ユーザーフォルダ側に置く。「この資料は初心者向け」はプロジェクト固有なので、プロジェクト側に置く。

両方ある場合は両方とも読み込まれる。どちらかが無視されることはない。

5. CLAUDE.mdの書き方のコツ

CLAUDE.mdは強制力のある設定ではない。AIへの指示として渡されるものなので、書き方によって従い方が変わる。

守ることは4つある。

コツ	何をするか
具体的に書く	判定できる書き方にする
短く保つ	200行以内を目安に、使わないルールを削る
別のファイルへ送る	中身は別ファイルへ移し、行き先だけを残す
矛盾させない	追記のとき、既存の記述と衝突しないか確かめる

以降で1つずつ扱う。最後に、書いたものが効いているかの確かめ方を添える。

具体的に書く

判断の余地が無い書き方にする。

曖昧	具体的
読みやすく書く	一文を60字以内にする
きれいに整理する	見出しは3階層まで。それ以上は分割する
丁寧に確認する	変更前に、変更する行数を伝える

左の書き方だと、AIは自分なりに解釈する。その解釈が自分の意図と一致する保証は無い。

「後から見て、守れているかを自分で判定できるか」が基準になる。判定できない書き方は、AIにも守れない。

短く保つ

目安は200行以内である。長くなるほど、書いたことが守られにくくなる。

思いついたことを書き足していくと、すぐ膨らむ。定期的に読み返し、次のものを削る。

使わなくなったルール
一度しか使わなかった決まり
AIが調べれば分かること(3章「CLAUDE.mdに何を書くか」)

別のファイルへ送る

削っても収まらないときは、ルールを別のファイルに分ける。

CLAUDE.mdは会話の最初に全文が読み込まれる。ルールを全部ここに書くと、その日の作業に関係ない分まで毎回入ることになる。図を作らない日でも図のルールが読み込まれ、その分だけAIが扱う情報が増える。

そこで、CLAUDE.mdには入口だけを置く。

## 作業別のルール

- 記事を書く → rule/記事ルール.md を読む
- 図を作る   → rule/図解ルール.md を読む
- 投稿を作る → rule/投稿ルール.md を読む

こう書いておくと、AIは記事を書くときに rule/記事ルール.md だけを開く。図解のルールは読まれない。

中身は別ファイルへ移し、CLAUDE.mdには行き先だけを残す。 ルールが増えてもCLAUDE.md自体は短いままになり、それぞれのルールは分量を気にせず詳しく書ける。

矛盾させない

矛盾した内容が両方書いてあると、AIはどちらかを勝手に選ぶ。

（✕ 矛盾している例)
- 専門用語には説明を付ける
- 説明は冗長になるので付けない

書き足していくうちに起きやすい。追記のときは、既存の記述と衝突しないかを確認する。

6. CLAUDE.mdの具体例

ここまでの内容を1本にまとめる。初心者向けの学習資料を作っているプロジェクトを想定した例になる。

# このプロジェクトについて

初心者向けの学習資料を作っている。
読者はプログラミング経験が無い社会人を想定している。

## 書き方のルール

- 専門用語は初出時に説明を付ける
- 一文を60字以内にする
- 見出しは3階層まで。それ以上は分割する
- 「ユーザー」ではなく「読者」と書く

## やってほしくないこと

- 既存の見出し構成を変えない
- 資料を新規作成する前に、置き場所を確認する

## 作業別のルール

- 記事を書く → rule/記事ルール.md を読む
- 図を作る   → rule/図解ルール.md を読む

## 手順

新しい記事を追加したら、目次にも追記する。

この例が守っていることを、章と対応させて挙げる。

箇所	対応する内容
「初心者向け」「読者はプログラミング経験が無い」	AIが見ても分からない方針(3章)
「一文を60字以内」「見出しは3階層まで」	判定できる具体的な書き方(5章)
「作業別のルール」の2行	入口だけを置き、中身は別ファイルへ(5章)
フォルダ構成やファイルの要約が無い	調べれば分かることは書かない(3章)

全体で30行ほどに収まっている。 ルールが増えても、rule/ 配下へ送る形にしておけば、このファイル自体は長くならない。

CLAUDE.mdで、会話をまたいで前提を引き継がせられるようになった。ただしこれはAIへの指示であり、強制力はない。

次の「設定ファイル — settings.json でツールの動作を決める」では、ツール自体の設定を扱う。こちらはAIの判断を挟まずに効くため、確実に止めたい操作があるときはこちら側に書く。置き場所と優先順位を押さえておくと、以降の章で出てくる設定がどこに書かれるものなのかが分かるようになる。

← ⑨ .claude フォルダー｜次:⑪ 設定ファイル →

目次