Claude Code CLAUDE.md 書き方と記入例

CLAUDE.md って、そもそも何のために使うか分かりますか? Claude Code に作業を頼むたび、同じことを伝えるのは面倒ですよね。
「ルールを書いておくファイル」なのは分かる。
でも、いざ書こうとすると、こんなところで止まりませんか。
- 毎回同じ指示を入れているけど、どこまで CLAUDE.md に移せばいいの?
- 書いたはずのルールが守られない。
書き方が悪い? - あれもこれも足していたら長くなった。
これ、全部必要?
正直、こういう決まりごとは後回しにしがちです。
迷うのは、書き方よりも「何を残して、何を省くか」が決まっていないからだと思っています。
なんとなく分かったつもりで終わらせないよう、備忘録としてまとめました。
Claude Code を使い始めた方に向けて、指示の選び方と短い記入例を載せています。
書いたのに伝わらないとき、どこを見直すかも一緒に考えます。
何を書くかは「毎回必要か」で選ぶ
ファイルを開いたはいいものの、最初の一行で止まりませんか。
プロジェクトの説明を全部書こうとすると、きりがありません。
CLAUDE.md は、Claude に継続して渡す指示を記す Markdown ファイルです。
公式は、コードだけでは分からないコマンドや規約を載せるよう勧めています。
では、どこまで詳しく書けばいいのか。その説明がないと、次の作業でも同じ修正が必要になるかを目安にします。
残す候補 | 省く候補 |
|---|---|
この案件で使うビルド・テストのコマンド | 言語の一般的な文法説明 |
標準とは異なる命名やコードの規約 | コードを読めば分かるファイル一覧 |
プロジェクト固有の設計上の決まり | 頻繁に変わる情報や長いチュートリアル |
「きれいなコードにする」だけでは、何を確認すればよいか曖昧です。インデントや実行するテストなど、確かめられる形まで絞ります。「きれいに」の一言で伝わったら楽なんですけどね。
最初から立派な仕様書にしなくてよいと思っています。
足りないところが見えたら、そのときに直していきます。
まずはプロジェクトのルートに置く
置き場所で迷ったら、まず誰と共有するかを考えます。
同じ案件のメンバーで使うなら、プロジェクトのルートに CLAUDE.md を置けます。
公式には .claude/CLAUDE.md という配置もあります。
初めてなら、ルートの一枚から始めると内容を追いやすいと思います。

作業フォルダと、その上の階層にある指示は起動時に読み込まれます。
下の階層にある指示は、図のように対象ファイルを扱うときに読み込まれます。
複数のファイルがあるときは、上書きで一つに決まるわけではありません。
内容が追加されます。置き場所の違う指示どうしも、矛盾しないようにそろえます。
短い記入例から、自分の案件に合わせる
置き場所が決まったら、中身です。
必須の書式はありませんが、公式には見出しと箇条書きで分ける方法が示されています。
以下は、インデントが半角スペース2個で、ES Modules を使う案件向けの例です。
テストに npm test を使うことも前提にしています。
# コードの規約
- インデントは半角スペース2個にする。
- モジュールは import / export で記述する。
# 作業の確認
- コミット前に npm test を実行する。
貼り付ける前に、案件の決まりと合うかは確認してください。特に、例のコマンドが自分のプロジェクトにもあるとは限りません。
コピペで済ませたい気持ちはあるんですけどね。
「テストする」で終わらせず、いつ、何を実行するかまで書きます。例と異なる運用なら、実際に使うコマンドへ置き換えます。
項目を増やすなら、コードからは読み取れない設計の決まりを優先します。コードを見れば分かることまで、もう一度説明しなくて大丈夫です。
空欄から書けないときは /init を使う
とはいえ、コマンドや規約を拾うところから手が止まることもありますよね。
そんなときは、Claude Code のセッション内で /init を使い、ひな形を作れます。
このコマンドは、コードベースを調べ、開始用の CLAUDE.md を生成します。
見つかった情報を土台にして、足りない指示を人が補います。
- 対象プロジェクトのセッションで
/initを入力します。 - 生成内容を読み、コマンドや規約を実際の運用と照らし合わせます。
/contextを実行し、Memory files の一覧で読み込みを確認します。
生成されたら完成、としたくなりますが、ここでもうひと手間です。Claude がコードから見つけられない決まりこそ、書き足す対象です。生成内容と、実際の運用を照らし合わせてみてください。
指示が伝わらないときは、足す前に見直す
守られない指示があると、注意書きを増やしたくなります。
「念のため」って、いくらでも足せてしまうんですよね。
ただ、長さや曖昧さが原因になる場合もあると、公式は説明しています。
- 使わなくなったコマンドや古いルールを消します。
- 「適切に」などの表現を、確認できる条件に変えます。
- 別の CLAUDE.md と反対の指示がないか確かめます。
公式の目安は、1ファイル200行以下です。上限まで埋める必要はありません。
必要な指示が見つかる短さを保ち、修正後の動きも確認します。
足すだけでなく、使わなくなった指示を消すことも大事です。
書いた指示が読み込まれているか分かると、見直すファイルを探しやすくなります。
Claude Codeで/contextを実行したときのMemory filesが、読み込みを確認する場所です。
この記事の内容は、2026年10月20日時点の公式ドキュメントをもとにしています。
出典
- Claude があなたのプロジェクトを記憶する方法(Claude Code Docs)
- Claude Code のベストプラクティス(Claude Code Docs)
- コマンド(Claude Code Docs)
AIツールを使った開発の進め方や、作ったものを本番のサイトに組み込む作業のご相談は、コーディング代行で承ります。


