- AI ⚙️
- 技術 💻
CLAUDE.mdの書き方|何を書くか・置き場所・育て方【テンプレートつき】
CLAUDE.mdとは、Claude Codeが毎回の作業の最初に読み込む、プロジェクトの説明書です。ビルドやテストのコマンド、コーディングの規約、ディレクトリの構成など、「毎回説明し直していること」を書いておくと、AIが最初からプロジェクトのルールに沿って作業できるようになります。
ただし、長く書けばよいわけではありません。公式ドキュメントでは、1ファイルあたり200行以内を目安にしています。この記事では、何を書き、何を書かないか、置き場所と読み込まれる順番、長くなったときの分け方、スキル・フック・設定との使い分けまで、公式ドキュメントに沿って解説します。記事の最後に、そのまま使えるテンプレートも紹介します。
CLAUDE.mdの早見表
| 項目 | 内容 |
|---|---|
| 役割 | 毎回のセッションの最初に読み込まれる、プロジェクトの指示書 |
| 置き場所(プロジェクト) | ./CLAUDE.md または ./.claude/CLAUDE.md(Gitでチームと共有) |
| 置き場所(自分だけ) | ~/.claude/CLAUDE.md(全プロジェクト共通)、./CLAUDE.local.md(このプロジェクトだけ・Gitに含めない) |
| 長さの目安 | 1ファイル200行以内 |
| 最初の作り方 | Claude Codeで /init を実行すると、コードを調べてひな形を作ってくれる |
| 編集・確認 | /memory でファイルを開く、/context で読み込まれているかを確認 |
| 長くなったら | .claude/rules/ に分割し、paths で対象のファイルを絞る |
| 必ず実行させたいこと | CLAUDE.mdではなく、フック(hooks)で設定する |
本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。
(記載例)出典:株式会社RJC「CLAUDE.mdの書き方|何を書くか・置き場所・育て方【テンプレートつき】」
CLAUDE.mdに書くこと
公式ドキュメントでは、次のようなときにCLAUDE.mdに追記するよう勧めています。
- Claudeが同じ間違いを2回したとき
- コードレビューで、このプロジェクトなら知っておくべきことを指摘されたとき
- 前回のセッションと同じ訂正を、また入力したとき
- 新しく参加したメンバーにも同じ説明が必要なとき
つまり、CLAUDE.mdは「毎回説明し直していること」を書き留める場所です。具体的には、次の5つが中心になります。
| 書く内容 | 例 |
|---|---|
| コマンド | ビルド・テスト・リントの実行方法(pnpm test:unit など) |
| コーディングの規約 | 「default exportではなくnamed exportを使う」「日付はdayjsで扱う」 |
| 構成 | 「APIのハンドラーは src/api/handlers/ に置く」 |
| プロジェクト固有の注意点 | 「Webhookは必ず署名を検証する」「テストにはローカルのRedisが必要」 |
| 作業の進め方 | 「コミットの前に npm test を実行する」「ブランチ名は feature/チケット番号-内容」 |
CLAUDE.mdに書かない方がいいこと
| 書かない内容 | 理由と代わりの方法 |
|---|---|
| コードを読めばわかること | Claudeは必要に応じてコードを読める。書くと情報が重複し、古くなりやすい |
| 言語の一般的な書き方 | Claudeはすでに知っている。プロジェクト固有のルールだけを書く |
| リンターやフォーマッターで検査できるルール | インデントや引用符の種類は、ESLint・Prettier・Ruffなどに任せる方が確実 |
| 長いAPIの仕様書 | @docs/api.md のように別ファイルに分け、必要な場面で読ませる |
| 特定の作業だけの手順 | 「リリースの手順」のような複数ステップの手順は、スキルにする |
| 頻繁に変わる情報 | 担当者や締め切りなどは、すぐに古くなる |
迷ったときは、「この1行がなかったら、Claudeは間違えるか」を考えます。答えが「いいえ」なら、その行は削除して構いません。
書き方のコツ:具体的に、確認できる形で
CLAUDE.mdは、強制される設定ではなく、Claudeが読んで従おうとする指示です。そのため、書き方で守られやすさが変わります。公式ドキュメントでは、確認できるくらい具体的に書くことを勧めています。
| あいまいな書き方 | 具体的な書き方 |
|---|---|
| コードをきれいに整形する | インデントはスペース2つ |
| 変更をテストする | コミットの前に npm test を実行する |
| ファイルを整理して置く | APIのハンドラーは src/api/handlers/ に置く |
| エラー処理をきちんとする | 外部APIの呼び出しは、必ずタイムアウトを指定し、失敗時はログに request_id を出す |
ほかにも、次の点を意識します。
- 見出しと箇条書きで整理する:長い文章より、まとまりごとに区切った方が読み取られやすい
- 矛盾する指示を書かない:2つのルールが食い違うと、どちらに従うかが定まらない
- 定期的に見直す:古くなった指示や、複数のファイルで食い違う指示を削除する
置き場所と読み込まれる順番
CLAUDE.mdは、置き場所によって適用される範囲が変わります。
| 範囲 | 置き場所 | 用途 | 共有 |
|---|---|---|---|
| 組織全体 | 管理者が配布する場所(Linuxなら /etc/claude-code/CLAUDE.md) |
会社のコーディング規約、セキュリティの方針 | 組織の全員 |
| 自分(全プロジェクト) | ~/.claude/CLAUDE.md |
個人の好み(説明は日本語で、など) | 自分だけ |
| プロジェクト | ./CLAUDE.md または ./.claude/CLAUDE.md |
構成、規約、作業の流れ | Gitでチームと共有 |
| プロジェクト(自分だけ) | ./CLAUDE.local.md |
自分の検証環境のURL、テスト用のデータ | 自分だけ(.gitignore に追加する) |
読み込みのルールは次のとおりです。
- 作業ディレクトリと、その上の階層にある CLAUDE.md・CLAUDE.local.md は、起動時に読み込まれる
- 下の階層(サブディレクトリ)にある CLAUDE.md は、Claudeがそのディレクトリのファイルを読んだときに読み込まれる
- 見つかったファイルは、上書きではなく、すべてつなげて読み込まれる。作業ディレクトリに近いものほど後に読まれる
たとえば、フロントエンドとバックエンドが1つのリポジトリにある場合は、次のように分けられます。
my-app/
├── CLAUDE.md # 全体の構成、共通のコマンド
├── frontend/
│ └── CLAUDE.md # Reactの規約(frontendのファイルを読んだときに読み込まれる)
└── backend/
└── CLAUDE.md # APIとDBの規約(backendのファイルを読んだときに読み込まれる)
最初の作り方:/init から始める
Claude Codeで /init を実行すると、Claudeがコードを調べ、ビルドのコマンド、テストの方法、見つかった規約をもとにCLAUDE.mdのひな形を作ります。すでにCLAUDE.mdがある場合は、上書きせずに改善案を提案します。
ひな形ができたら、Claudeがコードから読み取れない情報を追記していきます。
- なぜその設計にしたのか(「在庫の計算は、必ず
InventoryServiceを通す。直接DBを更新すると、履歴が残らないため」) - 過去に起きた問題と、その対策
- チームの作業の進め方
長くなったときの分け方
@ で別のファイルを読み込む
@ファイルのパス と書くと、そのファイルの内容を読み込めます。
プロジェクトの概要は @README.md 、使えるコマンドは @package.json を参照。
# 追加の指示
- Gitの運用ルール @docs/git-instructions.md
- パスは、そのCLAUDE.mdがある場所から見た相対パスでも、絶対パスでも書ける
- 読み込まれたファイルが、さらに別のファイルを読み込むこともできる(最大4階層まで)
@で読み込んだファイルも起動時にすべて読み込まれるため、分けても量は減らない。整理のための機能と考える- 読み込ませずにパスを書きたいときは、
`@README`のようにバッククォートで囲む
.claude/rules/ でテーマごとに分ける
規約が増えてきたら、.claude/rules/ にテーマごとのファイルを置きます。
my-app/
└── .claude/
├── CLAUDE.md
└── rules/
├── code-style.md # コードの書き方
├── testing.md # テストの規約
└── security.md # セキュリティの要件
さらに、ファイルの先頭に paths を書くと、対象のファイルを扱うときだけ読み込まれるようになります。
---
paths:
- "src/api/**/*.ts"
---
# APIの開発ルール
- すべてのエンドポイントで入力値を検証する
- エラーは共通のエラー形式で返す
- OpenAPIのコメントを書く
paths がないルールは、CLAUDE.mdと同じく毎回読み込まれます。特定の領域だけに関係するルールは paths で絞ると、ほかの作業のときに余計な指示が混ざりません。
人向けのメモはHTMLコメントで
<!-- 2026年9月 決済APIの移行が終わったら、この項目を削除 --> のようなHTMLのコメントは、Claudeに渡される前に取り除かれます。保守する人向けのメモを残しても、AIの読み込む量は増えません。
スキル・フック・設定との使い分け
CLAUDE.mdだけですべてを管理しようとすると、長くなり、守られにくくなります。目的に応じて使い分けます。
| 目的 | 使うもの | 例 |
|---|---|---|
| 毎回知っておいてほしい事実・規約 | CLAUDE.md | コマンド、構成、命名の規約 |
| 特定のファイルを扱うときだけの規約 | .claude/rules/(paths つき) |
APIのルール、テストのルール |
| 特定の作業の手順 | スキル | リリースの手順、障害報告書の作り方 |
| 必ず実行させたい処理 | フック(hooks) | ファイル編集のたびにフォーマッターを実行、コミット前にテスト |
| 禁止したい操作 | 設定(permissions.deny) |
本番の設定ファイルの読み取りや、特定のコマンドを禁止 |
CLAUDE.mdは「お願い」、フックと設定は「仕組み」と考えるとわかりやすくなります。「絶対に守らせたいこと」をCLAUDE.mdに書いて守られなかった、という場合は、フックや設定に移すのが確実です。
そのまま使えるテンプレート
# プロジェクト概要
- 社内の受発注を管理するWebアプリ(Next.js + NestJS + PostgreSQL)
- 詳細は @README.md
# コマンド
- 開発サーバー:`pnpm dev`
- 単体テスト:`pnpm test:unit`(変更したファイルに関係するテストだけでよい)
- E2Eテスト:`pnpm test:e2e`(コミット前に必ず実行)
- 型チェック:`pnpm typecheck`
# 構成
- `apps/web/` 画面(Next.js App Router)
- `apps/api/` API(NestJS)
- `packages/shared/` 画面とAPIで共有する型
# 規約
- exportはnamed exportを使う(default exportは使わない)
- 日付は `dayjs` で扱い、DBにはUTCで保存する
- 金額は整数(円)で扱い、浮動小数点を使わない
# 注意点
- 在庫の更新は必ず `InventoryService` を通す(直接更新すると履歴が残らない)
- `packages/shared/` の型を変えたら、webとapiの両方で型チェックを実行する
- 外部APIの呼び出しには必ずタイムアウトを指定する
# 作業の進め方
- ブランチ名:`feature/チケット番号-内容`
- コミットメッセージ:Conventional Commits(feat: / fix: など)
- 1つのプルリクエストは1つの目的に絞る
ポイントは、Claudeがコードを読むだけではわからないことに絞っている点です。このテンプレートでも50行程度で、200行の目安には十分な余裕があります。
指示が守られないときの確認方法
| 確認すること | 方法 |
|---|---|
| そもそも読み込まれているか | /context を実行し、「Memory files」の一覧にCLAUDE.mdがあるか確認する |
| 置き場所は正しいか | 起動したディレクトリより上、または作業中のファイルがあるディレクトリにあるか |
| 指示が具体的か | 「きれいに」「ちゃんと」のようなあいまいな言葉を、確認できる形に書き直す |
| 矛盾する指示がないか | 複数のCLAUDE.mdや .claude/rules/ で、同じことに違う指示を書いていないか |
| 必ず実行させたいことか | 必ず実行させたい処理はフックに移す |
また、会話の中で伝えた指示は、長い会話を要約する /compact の後に失われることがあります。プロジェクトのルートにあるCLAUDE.mdは、/compact の後にも読み込み直されます。繰り返し使う指示は、会話ではなくCLAUDE.mdに書いておきます。
チームで育てる運用のコツ
- Gitで管理し、レビューを通す:CLAUDE.mdの変更も、コードと同じくプルリクエストで確認する
- 「2回目の訂正」を追記のきっかけにする:同じ指摘を2回したら、CLAUDE.mdに1行足す
- 定期的に削る:半年に一度など時期を決め、使われなくなった指示を削除する
- 個人の好みは分ける:チームのルールは
CLAUDE.md、個人の好みは~/.claude/CLAUDE.mdやCLAUDE.local.mdに書く - 他のAIツールと共有する:リポジトリに
AGENTS.mdがある場合は、CLAUDE.mdから@AGENTS.mdで読み込むと、同じ規約を複数のツールで使える
よくある質問
Q. CLAUDE.mdは英語で書くべきですか? A. 日本語で問題ありません。チームのメンバーが読みやすい言語で書くことが大切です。コマンドやパスなどは、そのままの表記で書きます。
Q. 自動メモリー(auto memory)との違いは何ですか? A. CLAUDE.mdは人が書く指示、自動メモリーはClaudeが作業の中で学んだことを自分で書き留めるメモです。チームで共有したいルールはCLAUDE.mdに書き、個人の作業の中での細かな好みは自動メモリーに任せる、という使い分けができます。
Q. 200行を超えるとどうなりますか?
A. 読み込み自体はされますが、読み込む量が増え、指示が守られにくくなります。.claude/rules/ への分割や、スキルへの移動を検討します。
Q. 秘密の情報を書いてもいいですか?
A. 書かないでください。プロジェクトのCLAUDE.mdはGitで共有されます。APIキーなどは環境変数で管理し、CLAUDE.mdには「.env.example を参照」のように書き方だけを示します。
まとめ
- CLAUDE.mdは、毎回説明し直していることを書き留める、プロジェクトの説明書
- 書くのはコマンド・規約・構成・固有の注意点・作業の進め方。コードからわかることは書かない
- 1ファイル200行以内を目安に、確認できるくらい具体的に書く
- 置き場所で範囲が変わる。チームは
./CLAUDE.md、個人は~/.claude/CLAUDE.mdやCLAUDE.local.md - 長くなったら
@の読み込みや.claude/rules/(pathsつき)で分ける - 必ず実行させたいことはフック、禁止したいことは設定で管理する
- 守られないときは
/contextで読み込みを確認し、指示を具体的に書き直す
本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。
(記載例)出典:株式会社RJC「CLAUDE.mdの書き方|何を書くか・置き場所・育て方【テンプレートつき】」
株式会社RJCでは、AIを使った開発の進め方を、実際のプロジェクトの中で仲間と工夫しながら磨いています。こうした知識を共有しながら、一緒に成長を楽しんでいます。
株式会社RJC ― SI事業・SES事業・AI駆動開発。未経験からエンジニアに育てるのが得意な会社です。
WE ARE HIRING
RJCで一緒に開発しながら、
成長を楽しみませんか?
RJCは、Web・モバイル・AIを活用した開発プロジェクトで、テックリードやPM・PMOも活躍するシステム開発会社です。会社を知る、待遇を確かめる、話を聞いてみる。気になるところ見てみてください!
- 127日年間休日
- 12時間平均残業時間
- 毎日ガチャ遊びココロも大切にする福利厚生。アマギフなどの賞品ラインナップ!
ほかにも、チケットレストラン、書籍読み放題、2年ごとの慰労報奨(休暇 or 金一封)、11期連続の黒字決算。