// ARTICLE · AIツールの使い方
CLAUDE.mdの書き方|置き場所と雛形3種
// この記事を書いた人
株式会社Global Design Factory 代表取締役
高橋 遼
北海道大学工学部でAIによる自然言語処理を研究。P&Gにてビッグデータ解析・消費者分析を担当した後、伊良コーラのマーケティング責任者を経て、現在は株式会社Global Design Factory代表取締役として、中小企業を中心にAIを活用した業務効率化・自動化を支援。

CLAUDE.mdは、Claude Codeがセッションの開始時に毎回読み込む、Markdown形式の指示ファイルです。ビルドやテストのコマンド、コーディング規約、「これだけは必ず守ってほしい」というルールを書いておくと、毎回同じ説明をし直さずに済みます。
結論から言うと、書き方の要点は次の4つです。
- プロジェクト直下に
CLAUDE.md(または.claude/CLAUDE.md)を置き、/initで叩き台を作ってから手直しする - 書くのは「Claudeがコードを読んでも分からないこと」だけにし、1ファイル200行未満に抑える
- 一部のファイルにしか関係しない指示は
.claude/rules/、ときどき使う手順はSkillsへ切り出す - 必ず実行させたい処理はCLAUDE.mdではなくhooksで担保する
ここから、置き場所と読み込み順、作り方、書く内容、コピペで使える雛形3種、AGENTS.mdとの共存、効かないときの見直し方を順に説明します。仕様は2026年10月時点のClaude Code公式ドキュメントのCLAUDE.mdの解説(How Claude remembers your project)に基づいています。
CLAUDE.mdとは?毎回読み込まれる「プロジェクトの申し送り」
Claude Codeのセッションは、毎回まっさらなコンテキストから始まります。前回のセッションで伝えたことは、そのままでは引き継がれません。そこで、セッションをまたいで知識を持ち越すために、公式は2つの仕組みを用意しています。
- CLAUDE.md:あなたが書く指示ファイル。プロジェクトのルールや手順を書きます
- Auto memory(自動メモリ):Claudeが作業中の修正や好みをもとに、自分で書き溜めるメモ
どちらもセッション開始時に読み込まれますが、公式は「強制される設定ではなく、コンテキストとして扱われる」と明記しています。つまりCLAUDE.mdに書いたことは、Claudeが参考にして従おうとする情報であり、100%守られる保証はありません。指示が具体的で簡潔なほど、安定して守られるようになります。
公式が挙げる「CLAUDE.mdに書き足すタイミング」は、次の4つです。
- Claudeが同じ間違いを2回した
- コードレビューで、Claudeが知っておくべきだったことを指摘された
- 前回のセッションと同じ訂正や補足を、またチャットに打ち込んだ
- 新しく入ったメンバーにも同じ説明が必要になる
逆に、複数の手順からなる作業や、コードベースの一部にしか関係しない話は、CLAUDE.mdではなくSkillsやパス指定のルールに置くよう案内されています。Claude Codeそのものの使い方や料金はClaude Codeの使い方と料金で、導入手順はClaude Codeのインストール方法で説明しています。
CLAUDE.mdの置き場所と読み込み順
CLAUDE.mdは1か所に置くだけのものではなく、置き場所によって適用範囲が変わります。公式ドキュメントの一覧を、読み込まれる順(範囲が広いものから狭いもの)に整理すると次のとおりです。
| 種類 | 置き場所 | 用途 | 共有範囲 |
|---|---|---|---|
| 組織管理(Managed policy) | macOS: /Library/Application Support/ClaudeCode/CLAUDE.md<br>Linux・WSL: /etc/claude-code/CLAUDE.md<br>Windows: C:\Program Files\ClaudeCode\CLAUDE.md | 情報システム部門が配布する全社共通の指示 | その端末の全ユーザー |
| ユーザー(グローバル) | ~/.claude/CLAUDE.md | 全プロジェクト共通の個人の好み | 自分だけ(全プロジェクト) |
| プロジェクト | ./CLAUDE.md または ./.claude/CLAUDE.md | チームで共有するプロジェクトのルール | Gitで共有するメンバー |
| ローカル | ./CLAUDE.local.md | そのプロジェクトでの個人用メモ(.gitignore に追加) | 自分だけ(そのプロジェクト) |
このほか、サブディレクトリに置いたCLAUDE.mdも使えます。
読み込みのルールは「上書き」ではなく「連結」
Claude Codeは、起動したディレクトリと、その上にあるすべてのディレクトリから CLAUDE.md と CLAUDE.local.md を読み込みます。たとえば foo/bar/ で起動すると、foo/CLAUDE.md と foo/bar/CLAUDE.md の両方が読み込まれます。
ポイントは、見つかったファイルが互いに上書きし合うのではなく、すべて連結されてコンテキストに入ることです。並び順は次のようになります。
- ファイルシステムのルートに近いものが先、起動したディレクトリに近いものが後
- 同じディレクトリでは、
CLAUDE.mdの後にCLAUDE.local.mdが続く - ユーザーの指示(
~/.claude/CLAUDE.md)の後に、プロジェクトの指示が来る
起動場所に近い指示ほど後で読まれますが、「後に書いたほうが勝つ」という保証はありません。2つの指示が食い違うと、Claudeはどちらかを任意に選ぶことがあると公式は説明しています。階層をまたいで矛盾がないようにしておくことが大切です。
サブディレクトリのCLAUDE.mdは「触ったときに」読み込まれる
起動したディレクトリより下にあるCLAUDE.mdは、起動時には読み込まれません。Claudeがそのサブディレクトリ内のファイルを読む・書く・編集したタイミングで、はじめて読み込まれます。
この仕組みは、モノレポや大きなコードベースで役立ちます。公式の大規模コードベース向けガイドは、ルートの CLAUDE.md には全体に共通するルール(コーディング規約やコミットの作法)を、各パッケージやサブシステムの CLAUDE.md にはその領域だけの規約を書く2段構成を勧めています。
組織管理のCLAUDE.mdと除外設定
組織管理のCLAUDE.mdは、MDMやグループポリシーなどで各端末に配布する想定のファイルで、個人の設定では除外できません。反対に、モノレポで他チームのCLAUDE.mdまで読み込まれて困る場合は、設定ファイルの claudeMdExcludes にパスやglobパターンを書くと、そのファイルを読み込まないようにできます。自分だけに効かせたいときは .claude/settings.local.json に書きます。
CLAUDE.mdの作り方
1. /init で叩き台を作る
いちばん手早いのは、プロジェクトのフォルダでClaude Codeを起動し、/init を実行する方法です。
- ターミナルでプロジェクトのルートに移動し、
claudeを実行します - 入力欄に
/initと入力して実行します - Claudeがコードベースを調べ、ビルドコマンド、テストの手順、見つけた規約を書いた
CLAUDE.mdを作成します - 生成された内容を読み、Claudeが自分では気付けない情報を書き足し、不要な行を削ります
すでにCLAUDE.mdがある場合、/init は上書きせずに改善案を出します。また、Cursorのルール(.cursor/rules/ や .cursorrules)やGitHub Copilotの .github/copilot-instructions.md があれば、その内容も取り込んでくれます。
環境変数 CLAUDE_CODE_NEW_INIT=1 を設定してから /init を実行すると、対話形式の複数段階の流れに変わります。CLAUDE.mdに加えてSkillsやhooksも作るかを尋ね、サブエージェントでコードベースを調べ、質問で不足を補ったうえで、書き込む前に確認用の案を示してくれます。この形式では、個人用の CLAUDE.local.md を作って .gitignore に追加するところまで任せることもできます。
2. /memory で開いて編集する
/memory を実行すると、ユーザー用・プロジェクト用のCLAUDE.mdや CLAUDE.local.md の一覧が表示され、選んだファイルをエディタで開けます。まだ存在しないファイルを選ぶと、その場で作成されます。Auto memoryのオン・オフの切り替えや、Auto memoryのフォルダを開く操作もここからできます。
3. 会話から追記してもらう
作業中に「これは次回も守ってほしい」と思ったら、Claudeに「これをCLAUDE.mdに追加して」と頼むのが手軽です。注意したいのは、「pnpmを使うことを覚えておいて」のように「覚えて」と頼むと、CLAUDE.mdではなくAuto memoryに保存されることです。CLAUDE.mdに残したいときは、ファイル名を指定して頼みます。
なお、古い解説記事には「入力の先頭に # を付けるとメモを追加できる」という方法が載っていますが、2026年10月時点の公式ドキュメントのCLAUDE.mdのページにはこの方法の記載がありません。現在は上の2つの方法を使うのが確実です。
4. 読み込まれたかを /context で確かめる
ファイルを作ったら、セッション内で /context を実行し、「Memory files」の一覧にそのCLAUDE.mdが表示されるかを確認します。ここに無いファイルは、Claudeには見えていません。
CLAUDE.mdに書くべきこと・書かないこと
Claude Code公式のベストプラクティスは、書くものと書かないものを次のように整理しています。
| 書くこと | 書かないこと |
|---|---|
| Claudeが推測できないBashコマンド | コードを読めば分かること |
| デフォルトと異なるコードスタイル | Claudeが既に知っている言語の標準規約 |
| テストの手順と使うテストランナー | 詳しいAPIドキュメント(リンクで済ませる) |
| ブランチ名やPRの作法などリポジトリのルール | 頻繁に変わる情報 |
| そのプロジェクト特有の設計判断 | 長い説明やチュートリアル |
| 必要な環境変数など開発環境の癖 | ファイルごとの説明 |
| 見ただけでは分からない落とし穴 | 「きれいなコードを書く」のような自明な心がけ |
判断に迷ったら、公式が勧める問い「この行を消したら、Claudeは間違えるか?」を1行ずつ当てはめます。答えが「いいえ」なら、その行は削ってかまいません。
検証できる具体的な書き方にする
公式は、確かめられるくらい具体的に書くよう求めています。
- 「コードをきちんと整形する」ではなく「インデントは2スペース」
- 「変更をテストする」ではなく「コミット前に
npm testを実行する」 - 「ファイルを整理する」ではなく「APIハンドラは
src/api/handlers/に置く」
関連する指示は見出しと箇条書きでまとめます。密度の高い段落より、整理された節のほうがClaudeは従いやすいとされています。
強調は1か所だけに使う
特定の指示だけ何度も守られない場合は、その行に「IMPORTANT」などの強調を付けます。ただし公式は、多くの行を強調すると、どれも目立たなくなると注意しています。強調は本当に外せない1〜2行に絞ります。
長さの目安は1ファイル200行未満
公式の目安は「1つのCLAUDE.mdにつき200行未満」です。長いファイルはコンテキストを多く消費し、指示が守られにくくなります。ルールを書いてあるのに望まない動きが続く場合、ファイルが長すぎて肝心のルールが埋もれている可能性が高い、というのが公式の見立てです。
指示ファイルが推奨の長さを超えていると、起動時と /status 実行時に警告が出ます。また、Claude Code本体は4MiBを超えるCLAUDE.mdを読み込まずに飛ばします。
人間向けのメモはHTMLコメントで書く
CLAUDE.md内のブロック単位のHTMLコメント(<!-- メンテナー向けのメモ -->)は、コンテキストに入る前に取り除かれます。「この行を足した経緯」のような人間向けのメモは、コメントにしておけばトークンを消費しません。
@ インポートで別ファイルを取り込む
CLAUDE.mdには、@path/to/import の形で別のファイルを取り込めます。
概要は @README を、使えるnpmコマンドは @package.json を参照してください。
# 追加の指示
- Gitの運用ルール @docs/git-instructions.md
仕様は次のとおりです。
- 相対パスと絶対パスの両方が使えます。相対パスは、作業ディレクトリではなく、インポートを書いたファイルの位置が基準です
- 取り込んだファイルの中からさらに取り込むこともでき、最大4段階までたどります
- パスに空白を含む場合は、空白の前にバックスラッシュを付けます(例:
@Design\ Docs/api-conventions.md)。引用符で囲むと取り込まれません - バッククォートで囲んだコードスパンやコードブロック内の
@は取り込まれません。パスを紹介したいだけのときは、バッククォートで囲みます - プロジェクトのCLAUDE.mdから作業ディレクトリの外(ホームディレクトリなど)を取り込むと、初回に承認ダイアログが表示されます
注意点として、インポートはファイルを整理する手段であって、コンテキストの節約にはなりません。取り込んだファイルも起動時にまとめて読み込まれるためです。行数を減らしたいときは、次の節の .claude/rules/ やSkillsを使います。
コピペで使えるCLAUDE.mdの雛形3種
ここからは、そのまま貼り付けて自分のプロジェクトに合わせて書き換えられる雛形です。コマンド名やディレクトリ名は例なので、実際のプロジェクトのものに置き換えてください。どれも200行よりはるかに短くしてあります。最初は短く始め、Claudeが間違えたときに1行ずつ足していくのが公式の勧める育て方です。
雛形1:Webアプリ(TypeScript・Next.js系)
# コマンド
- 開発サーバー: `pnpm dev`
- 型チェック: `pnpm exec tsc --noEmit`(コード変更のまとまりごとに必ず実行する)
- テスト: `pnpm test -- <ファイルパス>`(全体ではなく関係するテストだけ実行する)
- パッケージ追加は `pnpm add`。npm と yarn は使わない
# コードスタイル
- ES modules(import/export)を使う。CommonJS(require)は使わない
- コンポーネントは `src/components/`、APIハンドラは `src/app/api/` に置く
- 日付処理は `src/lib/date.ts` のヘルパーを使い、新しいライブラリを追加しない
# ワークフロー
- ブランチ名は `feat/` `fix/` で始める
- DBスキーマを変えたら、同じブランチでマイグレーションも生成してコミットする
# 落とし穴
- `.env.local` は本番DBを指している。書き込みを伴うスクリプトを実行する前に確認する
- `src/generated/` は自動生成。直接編集せず `pnpm codegen` を実行する
雛形2:Pythonプロジェクト
# 環境
- 依存関係の追加・実行は uv を使う(`uv add <pkg>` / `uv run <cmd>`)。pip を直接使わない
- 必要な環境変数は `.env.example` を参照。`.env` が無いとテストが失敗する
# コマンド
- テスト: `uv run pytest tests/<対象ファイル>`
- Lint と整形: `uv run ruff check --fix` と `uv run ruff format`
- 型チェック: `uv run mypy src/`
# 規約
- 関数の引数と戻り値には型ヒントを付ける
- 例外は握りつぶさず、`src/app/errors.py` の独自例外に包んで投げる
- DBアクセスは `src/app/repositories/` に集め、ルーティングから直接SQLを書かない
# 落とし穴
- マージ済みのマイグレーションは編集しない。新しいマイグレーションを追加する
- `tests/fixtures/` の大きなJSONは読み込まなくてよい(テスト用の固定データ)
雛形3:チーム共通ルール(ルートのCLAUDE.md)
チームで共有するルートのCLAUDE.mdは、全員・全パッケージに共通することだけに絞り、各領域の細かい規約はサブディレクトリのCLAUDE.mdや .claude/rules/ に任せます。
# このリポジトリについて
- 社内向け受発注システムのモノレポ。`packages/api`(バックエンド)と `packages/web`(画面)がある
- パッケージのスクリプトは、ルートではなく各パッケージのディレクトリで実行する
# コミットとPR
- コミットの件名は先頭にパッケージ名を付ける(例: `api: 在庫引当の上限チェックを追加`)
- main へ直接 push しない。必ずPRを作る
- PRの説明には「変更内容」「確認方法」を書く
# 禁止事項
- `packages/*/generated/` 以下を直接編集しない
- 顧客データを含むファイルをコミットしない
# 詳細
- API設計の規約 @docs/api-conventions.md
個人の好み(応答は日本語で書く、使うエディタなど)は、チームのCLAUDE.mdではなく ~/.claude/CLAUDE.md に書きます。Claudeの応答が英語になってしまう場合の対処はClaudeの日本語設定と英語になるときの対処法で説明しています。
AGENTS.mdとCLAUDE.mdの違いと共存させる方法
AGENTS.mdは、さまざまなAIコーディングエージェントが共通で読める指示ファイルの形式です。CodexやCursorなど複数のツールが対応しており、リポジトリのルートに置く標準的なMarkdownファイルという点はCLAUDE.mdと同じです。Claude CodeとCodexの違いはClaude CodeとCodexの違いで比べています。
Claude CodeはAGENTS.mdを直接読める
Claude Code v2.1.277以降は、AGENTS.mdをプロジェクトの指示として直接読めるようになりました。既定の動作は次のとおりです。
- AGENTS.mdだけがある(作業ディレクトリとその上にCLAUDE.mdもCLAUDE.local.mdも無い):AGENTS.mdを読みます
- AGENTS.mdとCLAUDE.md(またはCLAUDE.local.md)の両方がある:CLAUDE.mdだけを読みます
- CLAUDE.mdの中で
@AGENTS.mdと取り込んでいる:CLAUDE.mdを読み、取り込んだAGENTS.mdも含まれます
注意したいのは、プロジェクトに CLAUDE.md、.claude/CLAUDE.md、CLAUDE.local.md のどれか1つでもあると、AGENTS.mdが読まれなくなる点です。AGENTS.mdで運用しているプロジェクトに、個人用の CLAUDE.local.md を足しただけでもAGENTS.mdは読まれなくなります。一方、~/.claude/CLAUDE.md、組織管理のCLAUDE.md、.claude/rules/ はこの判定に含まれず、AGENTS.mdと一緒に読み込まれます。
両方を読ませたいときの設定
この既定の動作は変えられます。セッション内で /config を実行し、「Project instructions」を次のいずれかにします。
claude-md-or-agents-md:CLAUDE.mdを読み、無いときだけAGENTS.mdを読む(既定)claude-md-and-agents-md:CLAUDE.mdとAGENTS.mdを両方読む。同じAGENTS.mdを二重には読み込まないclaude-md:CLAUDE.mdだけを読むmanaged-only:組織管理のCLAUDE.mdとAuto memoryだけを起動時に読む
1つのファイルを複数ツールで共有する方法
いちばん確実なのは、AGENTS.mdを共通の指示ファイルとし、その隣のCLAUDE.mdで取り込む方法です。Claude Code固有の指示はインポートの下に書きます。
@AGENTS.md
## Claude Code
- `src/billing/` の変更ではプランモードを使う
この方法は、AGENTS.mdを直接読めない環境(v2.1.277より前のバージョンなど)でも動きます。インポートを残したまま新しいバージョンで使っても、AGENTS.mdが二重に読まれることはありません。
Claude固有の内容が不要なら、ln -s AGENTS.md CLAUDE.md でシンボリックリンクを張る方法もあります。ただし、Windowsで作業するメンバーがいる場合は、リンクが普通のテキストファイルとしてチェックアウトされることがあるため、公式は @AGENTS.md のインポートを勧めています。
CLAUDE.md・rules・Skills・サブエージェント・hooksの使い分け
CLAUDE.mdが長くなってきたら、内容をほかの仕組みに移すことを考えます。公式の拡張機能の解説(Extend Claude Code)をもとに、役割を整理します。
- CLAUDE.md:毎回読み込まれます。ビルドコマンドや基本の規約など、常に必要な指示向けです
.claude/rules/:毎回、または該当ファイルを扱うときに読み込まれます。言語別・ディレクトリ別の規約向けです- Skills:呼び出したときや、関係があるとClaudeが判断したときに本文が読み込まれます。参考資料や繰り返し使う手順向けです
- サブエージェント:別のコンテキストで動き、要約だけを返します。大量のファイルを読む調査向けです
- hooks:決まったイベントのたびに必ず実行されます。Lintの実行や危険な操作のブロック向けです
.claude/rules/ でパスごとに指示を分ける
.claude/rules/ に testing.md や api-design.md のようにテーマごとのMarkdownを置くと、指示を分割して管理できます。サブディレクトリに分けても再帰的に見つけてくれます。ファイルの先頭に paths を書くと、そのパターンに合うファイルを扱うときだけ読み込まれます。
---
paths:
- "src/api/**/*.ts"
---
# API開発のルール
- すべてのエンドポイントで入力値を検証する
- エラーレスポンスは共通の形式を使う
paths の無いルールは、.claude/CLAUDE.md と同じ優先度で起動時に読み込まれます。全プロジェクト共通の個人ルールは ~/.claude/rules/ に置けます。
Skillsに移すもの
デプロイの手順書やAPIのスタイルガイドのように、毎回は要らないが必要なときには詳しく知ってほしい内容は、Skillsに向いています。CLAUDE.mdが「常に知っていてほしいこと」、Skillsが「必要なときに取り出す資料と手順」という分担です。作り方はClaude Skillsの使い方で説明しています。
サブエージェントとhooksに任せるもの
調査や検証のように大量のファイルを読む作業は、サブエージェントに任せるとメインの会話のコンテキストを汚しません。詳しくはClaude Codeのサブエージェントの使い方をご覧ください。
一方、「.env を編集しない」のような禁止事項は、CLAUDE.mdに書いてもあくまで「お願い」です。公式は、毎回必ず守らせたいルールは PreToolUse フックでブロックするよう勧めています。「ファイル編集のたびにLintを実行する」「コミット前に必ずテストする」といった処理も、hooksにすれば確実に実行されます。
同じ構成を複数のリポジトリで使い回したくなったら、Skills・hooks・サブエージェントをまとめて配布できるプラグインにする方法もあります。Claude Codeのプラグインの使い方で詳しく説明しています。
CLAUDE.mdが効かないときの見直し方
書いたはずの指示が守られないときは、次の順で確認します。
/contextを実行し、「Memory files」にそのファイルが表示されているか確認します。無ければ置き場所が読み込み対象外です- サブディレクトリのCLAUDE.mdは起動時には読み込まれないため、「Memory files」には出ません。そのフォルダのファイルをClaudeに読ませると、読み込まれたことを示す
Loadedの行が表示されます - 指示が抽象的になっていないか見直します。「きれいに整形する」より「インデントは2スペース」のほうが守られます
- 複数のCLAUDE.mdや
.claude/rules/、~/.claude/CLAUDE.mdの間で、指示が矛盾していないか確認します - コミットやPRのルールを書いている場合は、Claude Code自身が持つGitの指示と競合している可能性があります。設定の
includeGitInstructionsで組み込みの指示を切り、attributionで署名の文言を指定します - ファイルが200行を大きく超えていないか確認し、
.claude/rules/やSkillsに移します
ファイルの整理には、公式の診断機能も使えます。/doctor は、チェックインされたCLAUDE.mdから、ディレクトリ構成や依存関係の一覧のようにコードから導ける内容を削る案を出します。/doctor prompt-audit(v2.1.283以降)は、古いモデル向けの指示、存在しないファイルやコマンドへの言及、ファイル間の矛盾を探して報告します。どちらも、適用を頼むまでファイルは変更されません。
/compact の後に指示が消えたように見える場合
プロジェクトのルートにあるCLAUDE.mdは、/compact の後にディスクから読み直されて、再びセッションに入ります。消えたように見える指示は、会話の中でだけ伝えたものか、サブディレクトリのCLAUDE.md、またはまだ該当ファイルを触っていない paths 付きのルールのいずれかです。会話でだけ伝えた指示を残したいなら、CLAUDE.mdに書き足します。
定期的に棚卸しする
公式の大規模コードベース向けガイドは、CLAUDE.mdの変更もPRでレビューすること、大きなモデルの更新後に見直すことを勧めています。古いモデルの弱点を補うために書いた指示は、新しいモデルでは不要な負担になることがあるためです。Claude Code全般の運用の考え方はClaudeのベストプラクティスでまとめています。
よくある質問
CLAUDE.mdは日本語で書いてもよいですか?
公式ドキュメントには、CLAUDE.mdを書く言語についての決まりはありません。形式にも決まりは無く、短く人間が読みやすいことが求められています。チームの全員が読める言語で、具体的に書くことを優先してください。
グローバルのCLAUDE.mdには何を書けばよいですか?
~/.claude/CLAUDE.md は、どのプロジェクトでも共通する個人の好みを書く場所です。応答の言語、よく使うツールの指定、好みのコードスタイルなどが向いています。プロジェクト固有のルールはプロジェクトのCLAUDE.mdに書き、両者で矛盾が出ないようにします。
CLAUDE.mdとAuto memoryはどう使い分けますか?
CLAUDE.mdは、あなたが意図して書く「指示とルール」の置き場所です。Auto memoryは、Claudeが訂正や好みから学んだことを ~/.claude/projects/<project>/memory/ に自分で書き溜める仕組みで、索引の MEMORY.md の先頭200行(または25KBのうち先に達したほう)が毎回読み込まれます。チーム全員に守ってほしいことはCLAUDE.md、個人の作業の中で覚えてほしいことはAuto memoryに任せるのが自然な分担です。
CLAUDE.mdはGitにコミットしたほうがよいですか?
プロジェクトのCLAUDE.mdはコミットしてチームで共有することが公式で勧められています。メンバーが改善を重ねるほど価値が高まるためです。一方、CLAUDE.local.md は個人用なので .gitignore に追加します。
まとめ
CLAUDE.mdは、Claude Codeが毎回のセッションで読み込む「プロジェクトの申し送り」です。置き場所は組織管理・ユーザー(~/.claude/CLAUDE.md)・プロジェクト・ローカル(CLAUDE.local.md)・サブディレクトリがあり、見つかったものはすべて連結して読み込まれます。
書き方の基本は、/init で叩き台を作り、「この行を消したらClaudeは間違えるか」を問いながら、コードから分からない情報だけを1ファイル200行未満で残すことです。一部のファイルにしか関係しない指示は .claude/rules/、ときどき使う手順はSkills、必ず実行させたい処理はhooksへ移します。AGENTS.mdと共存させるなら、CLAUDE.mdに @AGENTS.md と書いて取り込むのが確実です。まずは今のCLAUDE.mdを /context で確認し、効いていない行を見直すところから始めてみてください。
// RELATED








