CLAUDE.mdの書き方｜置き場所・行数の目安・コメントアウト【2026年9月】

2026年3月16日

このトピックの全体像Claude Code 完全ガイド｜料金・使い方・法人導入の全体像機能・設定の記事

公開日: 2026年3月16日最終更新: 2026年9月29日

公式ドキュメント・公式発表などの一次情報を確認したうえで、株式会社Nexaが執筆・更新しています。AIツールの仕様や料金は変わることがあるため、導入判断の前に各公式サイトの最新情報もご確認ください。運営会社について

CLAUDE.mdは、Claude Codeがセッションの開始時に毎回読み込む指示ファイルです。1ファイル200行未満を目安に、コードを読んでも分からないルールだけを、確認できる具体さで書きます（2026年9月29日に公式ドキュメントで確認）。

置き場所: 組織の管理ポリシー、ユーザー（~/.claude/CLAUDE.md。いわゆるグローバル）、プロジェクト、ローカルの4つ。複数あっても上書きされず、すべて結合して読み込まれる
長さ: 公式の目安は1ファイル200行未満。長いファイルほどコンテキストを消費し、指示が守られにくくなる
コメントアウト: ブロック単位のHTMLコメント（）は、Claudeに渡る前に取り除かれる。コードブロックの中のコメントは残る

対象: Claude Codeを業務で使い始めた方、CLAUDE.mdを書いたのに指示が守られないと感じている方

今日やること: /initでCLAUDE.mdの下書きを作り、/contextの「Memory files」で読み込まれたことを確認する

この記事の著者

株式会社Nexa 代表取締役川島陸

一橋大学経済学部卒業後、フォーティエンスコンサルティング株式会社（旧株式会社クニエ）にて法人向けAI導入支援等を経験。独立後、AI系メディア運営やDify/n8nの導入支援を経て、株式会社Nexaを創業。法人向けAI研修・AI導入支援・AI関連メディア運営を手掛ける。

詳しく見る AI顧問の無料相談

CLAUDE.mdは、Claude Codeに毎回読ませたい指示を書いておくMarkdownファイルです。ビルドのコマンド、チームの決まり、やってはいけない操作を書いておけば、会話のたびに同じ説明をする必要がなくなります。

一方で、置き場所が複数あること、長く書くほど守られにくくなること、コメントの扱いに決まりがあることは、あまり知られていません。この記事では、Anthropicの公式ドキュメント「Claudeがプロジェクトを記憶する方法」を2026年9月29日に開いて確認した内容をもとに、書き方・置き場所・長さ・コメントアウト・例文をまとめます。

先に、よく検索される疑問への答えを一覧にします。

知りたいこと	答え（公式ドキュメントの記載）
どこに置くか	プロジェクト用は`./CLAUDE.md`または`./.claude/CLAUDE.md`。すべてのプロジェクトに効かせる個人用は`~/.claude/CLAUDE.md`
複数あるとどうなるか	上書きではなく結合。範囲の広いものから順に並び、起動した場所に近い指示が最後に読まれる
長さの目安	1ファイル200行未満。4MiBを超えるファイルは読み込まれない
コメントアウト	ブロック単位のHTMLコメントは取り除かれる。コードブロックの中のコメントは残る
ほかのファイルの取り込み	`@パス`と書くと取り込まれる。取り込みの連鎖は最大4階層
読み込まれたかの確認	`/context`を実行し、「Memory files」の一覧を見る

Claude Codeそのものの概要はClaude Codeとは？何ができるか・仕組み・料金を整理をご覧ください。

CLAUDE.mdとは？Claude Codeが毎回読み込む指示ファイル

Claude Codeのセッションは、毎回まっさらなコンテキストウィンドウから始まります。公式ドキュメントは、セッションをまたいで知識を引き継ぐ仕組みとして、CLAUDE.mdと自動メモリの2つを挙げています。

CLAUDE.mdは人が書く指示、自動メモリはClaudeが自分で書くメモです。どちらも会話の開始時に読み込まれますが、公式は、強制される設定ではなく文脈として扱われる、と説明しています。Claudeの判断にかかわらず必ず止めたい操作は、CLAUDE.mdではなくフックや権限の設定で止めます。

CLAUDE.mdと自動メモリの違い

項目	CLAUDE.md	自動メモリ
書く人	利用者	Claude
内容	指示とルール	作業の中で得た気づきやパターン
範囲	プロジェクト・ユーザー・組織	リポジトリごと（ワークツリー間で共有）
読み込み	毎回のセッション	毎回のセッション（索引ファイルの先頭200行または25KBまで）
向いている内容	コーディングの決まり、作業の流れ、プロジェクトの構成	利用者の好み、受けた修正、コードからは分からない事情

自動メモリは既定で有効です。保存先は~/.claude/projects/<project>/memory/で、索引のMEMORY.mdと、話題ごとのファイルに分かれます。オンとオフは/memoryで切り替えられます。保存されるのはその端末の中だけで、ほかの端末やクラウドの環境とは共有されません。

Claudeに「覚えておいて」と頼んだ内容は、自動メモリに保存されます。CLAUDE.mdに入れたい場合は、「CLAUDE.mdに追加して」と頼むか、/memoryからファイルを開いて自分で編集します。なお、入力の先頭に#を付けて記録する方法は、2026年9月29日時点の公式ドキュメントには記載がありません。

指示と設定を置くファイルの一覧

CLAUDE.mdの周辺には、役割の近いファイルがいくつかあります。

ファイル	役割	読み込まれるタイミング
`CLAUDE.md`	プロジェクトや個人の指示	セッションの開始時
`CLAUDE.local.md`	そのプロジェクトでの自分だけの指示	セッションの開始時（CLAUDE.mdの後）
`.claude/rules/*.md`	話題ごとに分けたルール	開始時。パスを指定したルールは、該当するファイルを読んだとき
自動メモリ	Claudeが書くメモ	開始時に索引の先頭部分
`.claude/settings.json`	権限・フック・環境変数などの設定	Claude Code本体が読み取って適用

CLAUDE.mdとsettings.jsonの違い

名前が並んで出てくる2つのファイルですが、役割は別です。

項目	CLAUDE.md	settings.json
形式	Markdown（自然な文章）	JSON
役割	Claudeへの指示。文脈として渡される	動作の設定。Claude Code本体が適用する
例	「テストはコミットの前に実行する」	「特定のコマンドやファイルの読み取りを拒否する」
コメント	ブロック単位のHTMLコメントが使える	厳密なJSONのため`//`のコメントは構文エラーになる

「どう振る舞ってほしいか」を伝えるのがCLAUDE.md、「何を許可し、何を拒否するか」を決めるのがsettings.jsonです。settings.jsonの書き方はClaude Code 設定｜settings.jsonの場所・優先順位・permissionsの書き方で説明しています。

実務ポイントCLAUDE.mdに書くのは指示・ルール・背景の知識です。APIキーやパスワードなどの機密情報は書かないでください。プロジェクトのCLAUDE.mdはGitでチームに共有されるため、そのまま漏えいにつながります。

CLAUDE.mdを置ける4つの場所と読み込まれ方

CLAUDE.mdは、置く場所によって効く範囲が変わります。公式ドキュメントは次の4つを挙げています。表は読み込まれる順で、上ほど範囲が広く、下ほど限定されます。

種類	置き場所	用途	共有される相手
組織の管理ポリシー	macOS: `/Library/Application Support/ClaudeCode/CLAUDE.md` Linux・WSL: `/etc/claude-code/CLAUDE.md` Windows: `C:\Program Files\ClaudeCode\CLAUDE.md`	情報システム部門が管理する、組織全体の指示	組織の全利用者
ユーザー	`~/.claude/CLAUDE.md`	すべてのプロジェクトに共通する個人の好み	自分だけ（全プロジェクト）
プロジェクト	`./CLAUDE.md`または`./.claude/CLAUDE.md`	チームで共有するプロジェクトの指示	バージョン管理を通じてチーム全員
ローカル	`./CLAUDE.local.md`	そのプロジェクトでの個人的な指示	自分だけ（そのプロジェクト）

グローバル設定（~/.claude/CLAUDE.md）

「グローバルのCLAUDE.md」と呼ばれているのは、ホームディレクトリの.claudeフォルダに置くファイルです。公式の呼び方は「ユーザーの指示」で、その端末で開くすべてのプロジェクトに読み込まれます。

~/.claude/CLAUDE.md  ← すべてのプロジェクトに読み込まれる

プロジェクトに関係なく毎回伝えたいことを書きます。

回答に使う言語（例: 回答は日本語で書く）
コードの書き方の好み（例: インデントは半角スペース2つ）
いつも使う道具（例: パッケージの管理にはpnpmを使う）

プロジェクト設定（./CLAUDE.md）

プロジェクトの指示は、ルートのCLAUDE.mdか、.claudeフォルダの中のCLAUDE.mdに書きます。どちらに置いても読み込まれます。

your-project/
├── CLAUDE.md        ← チームで共有する指示
├── CLAUDE.local.md  ← 自分だけの指示（Gitには入れない）
├── src/
└── package.json

ビルドとテストのコマンド、コーディングの決まり、設計上の判断、命名の決まりなど、そのプロジェクトで作業する全員に当てはまる内容を書きます。自分だけの設定（検証用のURLや、よく使うテストデータなど）はCLAUDE.local.mdに分け、.gitignoreに追加してコミットされないようにします。

サブディレクトリ設定とモノレポでの活用

複数のパッケージを1つのリポジトリで管理するモノレポでは、パッケージごとにCLAUDE.mdを置けます。

monorepo/
├── CLAUDE.md              ← リポジトリ全体の決まり
├── packages/
│   ├── frontend/
│   │   └── CLAUDE.md      ← フロントエンドだけの決まり
│   └── backend/
│       └── CLAUDE.md      ← バックエンドだけの決まり

読み込まれ方は、Claude Codeを起動した場所で変わります。

作業ディレクトリと、その上の階層: 起動時にすべて読み込まれる
作業ディレクトリより下の階層: 起動時には読み込まれず、Claudeがそのディレクトリのファイルを読んだときに読み込まれる

たとえばpackages/frontend/で起動すると、そのフォルダのCLAUDE.mdとルートのCLAUDE.mdが読み込まれ、packages/backend/の指示は入りません。ほかのチームのCLAUDE.mdを読み込ませたくない場合は、設定のclaudeMdExcludesでパスを指定して除外します（公式: モノレポと大規模なコードベース）。

複数のCLAUDE.mdは上書きされず、結合して読み込まれる

見つかったCLAUDE.mdは、どれか1つが選ばれるのではなく、すべて結合されてコンテキストに入ります。公式ドキュメントには、互いに上書きするのではなく連結される、と書かれています。

範囲の広いものから順に並ぶ（組織 → ユーザー → プロジェクト → ローカル）
ディレクトリの階層では、上の階層から作業ディレクトリへ向かって並ぶ。起動した場所に近い指示が最後に読まれる
同じディレクトリの中では、CLAUDE.local.mdがCLAUDE.mdの後に追加される

後ろに並んだ指示が前の指示を打ち消す、という決まりはありません。公式は、2つのルールが食い違っている場合、Claudeがどちらかを任意に選ぶことがあるとしています。矛盾する指示を残さないことが、複数のファイルを使うときの前提になります。

図1: 置き場所が複数あっても上書きはされず、範囲の広いものから順に結合される

CLAUDE.mdのコメントアウト：書き方と、読み込まれるかどうか

CLAUDE.mdのコメントは、HTMLコメントの書き方（）で書きます。公式ドキュメントには、ブロック単位のHTMLコメントは、内容がClaudeのコンテキストに入る前に取り除かれると書かれています。人が読むためのメモを、コンテキストを消費せずに残せます。

# 開発の決まり

<!-- 担当者向けのメモ: この節は四半期ごとに見直す -->

- テストはコミットの前に実行する
- インデントは半角スペース2つ

<!--
- 一時的に外している指示は、このように囲んでおく
-->

公式に書かれている範囲を、表に整理します。

書き方・場面	Claudeに渡るか	根拠
ブロック単位のHTMLコメント	渡らない（取り除かれる）	公式に記載あり
コードブロックの中に書いたコメント	渡る（そのまま残る）	公式に記載あり
ClaudeがReadツールでCLAUDE.mdを直接開いたとき	コメントも見える	公式に記載あり
文の途中に入れたHTMLコメント	不明	公式は「ブロック単位」とだけ書いており、記載なし

行の先頭の#は、Markdownでは見出しの記号です。プログラムのコメントのつもりで書いても、コメントにはなりません。また、取り込みの記法（@パス）は、バッククォートで囲んだ部分とコードブロックの中では働きません。

使いどころは、担当者向けのメモと、一時的に外したい指示の退避です。ただし、ファイルを直接開けば読めるため、コメントは機密情報の置き場所にはなりません。

図2: 人向けのメモはHTMLコメントに書ける。開けば読めるため機密情報は書かない

CLAUDE.mdに書く内容と、書かない内容

CLAUDE.mdに決まった書式はありません。公式は「短く、人が読める形に」としたうえで、含めるものと除くものを次のように分けています（公式: ベストプラクティス）。

含めるもの	除くもの
Claudeが推測できないコマンド	コードを読めば分かること
既定と異なるコードスタイルの決まり	Claudeがすでに知っている、言語の標準的な慣習
テストの手順と、使うテストランナー	詳しいAPIの説明（文書へのリンクで足りる）
リポジトリの作法（ブランチ名、プルリクエストの決まり）	頻繁に変わる情報
そのプロジェクトに固有の設計上の判断	長い説明や手引き
開発環境の癖（必要な環境変数など）	ファイルごとのコードの説明
よくある落とし穴、気づきにくい挙動	「きれいなコードを書く」のような当たり前のこと

【必須】コマンドと、既定と異なる決まり

最初に書くのは、Claudeがコードを読んでも分からないコマンドと、チーム独自の決まりです。

良い例:

# 開発コマンド

- 開発サーバーの起動: `npm run dev`
- テスト: `npm test`（コミットの前に必ず実行する）
- 型チェック: `npm run typecheck`

# コーディングの決まり

- インデントは半角スペース2つ
- `any` は使わず、`unknown` を使う
- API のハンドラーは `src/api/handlers/` に置く

悪い例:

# 概要

Webアプリです。きれいなコードを書いてください。

悪い例は、守れたかどうかを確認できません。どのコマンドを使い、どの書き方にするのかが伝わらないためです。

【推奨】リポジトリの作法と設計上の判断

ブランチ名やプルリクエストの決まり、そのプロジェクトで採用した設計の方針を書きます。

# リポジトリの作法

- ブランチ名は `feature/内容` の形式にする
- プルリクエストには、変更の理由と確認した手順を書く

# 設計上の判断

- 画面の状態は1か所で管理し、部品の中に持たせない
- 日時はUTCで保存し、表示するときに日本時間へ変換する

【応用】用語の定義と、やってはいけないこと

業務に固有の用語と、避けたい操作を書きます。

# 用語

- 「顧客」は利用者個人、「取引先」は法人を指す
- 金額は税抜きで保存し、表示するときに税を計算する

# やってはいけないこと

- 本番のデータベースに接続するコマンドは実行しない
- 依存パッケージの追加は、必ず確認を取ってから行う

CLAUDE.mdに書いた禁止は、Claudeへの依頼であって、仕組みとしての遮断ではありません。必ず止めたい操作は、settings.jsonの権限の設定か、フックで止めます。フックの設定はClaude Code Hooksの設定と使い方をご覧ください。

CLAUDE.mdを書くときの5つのポイント

CLAUDE.mdは、多く書くほどよいファイルではありません。セッションのたびに全文が読み込まれ、会話と同じコンテキストを使うためです。公式ドキュメントの記載に沿って、5つのポイントにまとめます。

1. 1ファイル200行未満に保つ

公式の目安は、CLAUDE.md1ファイルあたり200行未満です。長いファイルは多くのコンテキストを消費し、指示が守られる割合を下げるとされています。

推奨の長さを超えたファイルがあると、起動時と/statusの実行時に警告が表示される
4MiBまでのCLAUDE.mdは全文が読み込まれ、それを超えるファイルは読み込まれない
文字数についての目安は、公式ドキュメントに記載がない（目安は行数で示されている）

残すか消すかの判断について、公式は各行に「これを消したら、Claudeは間違えるか」と問うことを勧めています。間違えないなら消します。ルールがあるのに守られない場合は、ファイルが長すぎてルールが埋もれている可能性が高い、とも書かれています。

2. 確認できる具体さで書く

指示は、守れたかどうかを確認できる具体さで書きます。公式の例は次のとおりです。

あいまいな書き方	具体的な書き方
コードを適切に整形する	インデントは半角スペース2つにする
変更をテストする	コミットの前に`npm test`を実行する
ファイルを整理しておく	APIのハンドラーは`src/api/handlers/`に置く

関連する指示は、Markdownの見出しと箇条書きでまとめます。どうしても守られない指示が1つだけある場合は、その行にだけ「重要」などの強調を付けます。多くの行を強調すると、どれも目立たなくなります。

理由を一言添えておくと、あとで人が見直すときに、残すか消すかを判断しやすくなります（公式の記載ではなく、運用上の工夫です）。

3. /initコマンドで下書きを作る

既存のプロジェクトに初めてCLAUDE.mdを置くときは、/initが使えます。

# Claude Codeの中で実行
/init

Claudeがコードベースを調べ、見つけたビルドのコマンド、テストの手順、プロジェクトの決まりを書いたCLAUDE.mdを作ります。すでにCLAUDE.mdがある場合は、上書きせずに改善を提案します。作られた下書きに、Claudeが自分では見つけられない指示を足していきます。

作ったあとは、セッションの中で/contextを実行し、「Memory files」の一覧にCLAUDE.mdが表示されることを確かめます。

4. ほかのファイルは「@パス」で取り込む

CLAUDE.mdの中に@パスと書くと、そのファイルが取り込まれます。READMEやpackage.jsonなど、すでにある文書を指示の一部として使えます。

プロジェクトの概要は @README を参照。
使えるコマンドは @package.json を参照。

# 追加の指示
- Gitの運用: @docs/git-instructions.md

相対パスと絶対パスのどちらも使える。相対パスは、取り込みを書いたファイルの場所が基準になる
取り込んだファイルが、さらに別のファイルを取り込める。連鎖は最大4階層
取り込んだファイルも起動時に読み込まれるため、分割してもコンテキストの消費は減らない
作業ディレクトリの外にあるファイルを取り込む場合、初回に承認の画面が表示される

読み込む量を減らしたいときは、取り込みではなく、パスを指定したルール（後述の.claude/rules/）を使います。該当するファイルを扱うときだけ読み込まれます。

5. 間違いが出たら足し、古くなったら消す

最初から完成させる必要はありません。公式は、次のようなときにCLAUDE.mdへ書き足すことを勧めています。

Claudeが同じ間違いを2回した
コードレビューで、Claudeが知っているべきだった点を指摘された
前のセッションと同じ訂正や補足を、もう一度入力した
新しく入ったメンバーにも、同じ説明が必要になる

複数の手順からなる作業や、コードベースの一部にだけ関係する内容は、CLAUDE.mdではなくスキルやパスを指定したルールに移します。スキルの作り方はClaude Code Skillsの作り方で説明しています。

見直しには/doctorが使えます。コードから読み取れる内容を削る案を出し、確認を取ってから変更します（v2.1.206以降）。古い指示や、互いに食い違う指示を調べたいときは/doctor prompt-auditを実行します（v2.1.283以降）。どちらも、依頼するまでファイルは書き換えられません。

図3: 最初から完成させず、下書きから始めて間違いが出るたびに足していく

業種別テンプレート：コピペで使えるCLAUDE.md例3選

開発以外の業務でも、CLAUDE.mdの考え方は同じです。毎回伝えている決まりを、確認できる形で書きます。次の3つは書き方の見本です。【】の部分を自社の内容に置き換えて使ってください。

【営業・提案書作成】CLAUDE.mdテンプレート

# このフォルダの用途

営業チームの提案書、メール、商談前の調査を扱う。

# 文書の決まり

- 社外向けの文書は、です・ます調の敬語で書く
- 自社の呼び方は【正式な社名】に統一する
- 金額は税抜きで書き、末尾に「（税抜）」を付ける
- 他社について、否定的な表現を使わない

# フォルダの構成

- 提案書のひな形: `templates/`
- 過去の提案書: `proposals/年度/`

# やってはいけないこと

- 公開されていない価格や条件を、文書に書かない
- 出典を確認していない数字を使わない

【マーケティング・コンテンツ制作】CLAUDE.mdテンプレート

# このフォルダの用途

ブログ記事、SNSの投稿、メールマガジンの原稿を扱う。

# 文体の決まり

- です・ます調で書く
- 一文は60字以内を目安にする
- 「今すぐ」「絶対」などのあおる表現を使わない
- 専門用語は、最初に出てきたところで説明を添える

# 読者

- 【想定する読者の役職と関心】

# 確認の手順

- 数字と固有名詞は、出典のページを開いて確かめる
- 原稿は `drafts/` に保存し、公開用のフォルダには直接書かない

【バックオフィス・経理・総務】CLAUDE.mdテンプレート

# このフォルダの用途

請求書、月次の集計、社内向けの手順書を扱う。

# 書式の決まり

- 金額は税込か税抜かを必ず書く
- 日付は「2026年9月29日」の形式で書く
- 数字は3桁ごとにカンマで区切る
- ファイル名は「日付_書類名_版数」にする

# やってはいけないこと

- 氏名、住所、口座番号を含むファイルは、指示があるまで開かない
- 元のデータを上書きしない。作業は複製したファイルで行う

テンプレートは出発点です。使いながら、Claudeが間違えた点を1行ずつ足していくと、自社の業務に合った内容になります。

AI導入に関するお困りごとは、株式会社NexaのAI顧問がサポートします。「何から始めればいいか分からない」という段階からご相談いただけます。

AI顧問の無料相談はこちら →

＼ AI活用の「次の一手」を一緒に考えませんか／

AI顧問の無料相談はこちら

チームでCLAUDE.mdを運用する方法

チームで使う場合は、共有する指示と個人の指示を分け、ルールが増えたら話題ごとのファイルに分けます。

CLAUDE.mdをGitに含めてチームで共有する

プロジェクトのCLAUDE.mdは、Gitにコミットしてチームで共有します。公式も、チームが書き足していけるようにGitへ入れることを勧めています。Gitに入れないのは、個人用のCLAUDE.local.mdだけです。

# .gitignore
# 個人用の指示だけを除外する（CLAUDE.md は除外しない）
CLAUDE.local.md

全員が同じ指示でClaude Codeを使える
指示の変更を、履歴として追える
プルリクエストで、指示の変更を確認し合える

ユーザーのCLAUDE.md（~/.claude/CLAUDE.md）はホームディレクトリにあるため、プロジェクトのリポジトリには含まれません。

.claude/rules/ディレクトリで詳細ルールを分離する

指示が増えてきたら、.claude/rules/に話題ごとのMarkdownファイルを置きます。1ファイルに1つの話題を書き、内容が分かるファイル名にします。

your-project/
├── .claude/
│   ├── CLAUDE.md           ← プロジェクトの主な指示
│   └── rules/
│       ├── code-style.md   ← コードスタイル
│       ├── testing.md      ← テストの決まり
│       └── security.md     ← セキュリティの要件

このフォルダのファイルは自動で見つけられるため、CLAUDE.mdに参照を書く必要はありません。パスの指定がないルールは、起動時に.claude/CLAUDE.mdと同じ扱いで読み込まれます。

ファイルの先頭にpathsを書くと、該当するファイルをClaudeが読んだときにだけ読み込まれるルールになります。

---
paths:
  - "src/api/**/*.ts"
---

# APIの開発ルール

- すべてのエンドポイントで入力を検証する
- エラーの応答は決められた形式にそろえる

個人用のルールは~/.claude/rules/に置くと、すべてのプロジェクトに読み込まれます。

AGENTS.mdと併用する

ほかのコーディングエージェント向けにAGENTS.mdを用意しているリポジトリでは、Claude Codeがそのファイルを読み込めます（v2.1.277以降）。既定では、作業ディレクトリとその上の階層にCLAUDE.mdがない場合にAGENTS.mdを読み、CLAUDE.mdがある場合はCLAUDE.mdだけを読みます。

両方を使いたいときは、CLAUDE.mdの先頭に取り込みを書き、Claude Code向けの指示をその下に足します。

@AGENTS.md

## Claude Code

`src/billing/` 以下を変更するときは、プランモードを使う。

新メンバーのオンボーディング資料として活用する

公式は、CLAUDE.mdに書き足す目安の1つに「新しく入ったメンバーにも同じ説明が必要になること」を挙げています。Claudeのために書いた決まりは、そのまま人への説明にもなります。

公開されている事例では、プレイド（PLAID）のエンジニアブログ「PR数4倍でも破綻しない、Claude Codeをチーム運用する仕組み」（2026年2月18日公開）が参考になります。同社のチームは、2025年9月と比べてプルリクエストの数が約4倍（月に約150件から約600件）になったと報告しています。指示の実体はAGENTS.mdに集め、CLAUDE.mdには@AGENTS.mdだけを書く構成です。

組織全体に同じ指示を配る

組織で導入する場合は、管理ポリシーの場所にCLAUDE.mdを置くと、その端末のすべてのセッションに読み込まれます。このファイルは、利用者の設定では除外できません。公式は、操作の遮断のような技術的な強制は管理設定で、コードの書き方やデータの扱いの注意は管理ポリシーのCLAUDE.mdで、と使い分けを示しています。

よくある質問

Q. CLAUDE.mdでコメントアウトはできますか？

できます。HTMLコメント（）で囲みます。公式ドキュメントによると、ブロック単位のHTMLコメントは、Claudeのコンテキストに入る前に取り除かれます。コードブロックの中に書いたコメントは残ります。また、ClaudeがReadツールでCLAUDE.mdを直接開いた場合は、コメントも見えます。文の途中に入れたコメントの扱いは、公式ドキュメントに記載がありません。

Q. CLAUDE.mdは何行、何文字までに収めるべきですか？

公式の目安は、1ファイルあたり200行未満です。長いファイルはコンテキストを多く消費し、指示が守られる割合を下げるとされています。文字数の目安は、公式ドキュメントに記載がありません。上限としては、4MiBを超えるCLAUDE.mdは読み込まれません。200行を超えそうなときは、パスを指定したルールに分けるか、毎回は必要のない内容を削ります。

Q. グローバルのCLAUDE.mdはどこに置きますか？

ホームディレクトリの~/.claude/CLAUDE.mdに置きます。公式の呼び方は「ユーザーの指示」で、その端末で開くすべてのプロジェクトに読み込まれます。プロジェクトのCLAUDE.mdがある場合も、どちらか一方が選ばれるのではなく、両方が結合されて読み込まれます。

Q. CLAUDE.mdとAGENTS.mdの違いは何ですか？

CLAUDE.mdはClaude Code向けの指示ファイル、AGENTS.mdは複数のコーディングエージェントで共有できる指示ファイルです。Claude Codeは、v2.1.277以降でAGENTS.mdを読み込めます。既定では、作業ディレクトリとその上の階層にCLAUDE.mdがない場合にAGENTS.mdを読み、CLAUDE.mdがある場合はCLAUDE.mdだけを読みます。両方を使うときは、CLAUDE.mdに@AGENTS.mdと書いて取り込みます。

Q. 会社の機密情報をCLAUDE.mdに書いても安全ですか？

書かないでください。プロジェクトのCLAUDE.mdはGitでチームに共有されるため、個人情報、APIキー、パスワード、公開前の事業の情報を書くと、そのまま広がります。HTMLコメントで囲んでも、ファイルを開けば読めます。書くのは、業務の決まりやコマンドなど、チームの全員が見てよい情報だけにします。

Q. CLAUDE.mdが効いていないと感じたらどうすればいいですか？

次の順に確認します。

/contextを実行し、「Memory files」の一覧に対象のCLAUDE.mdがあるか確認する
ファイルが、そのセッションで読み込まれる場所に置かれているか確認する
指示を具体的にする（「きれいに整形する」ではなく「インデントは半角スペース2つ」）
複数のCLAUDE.mdやルールの間に、食い違う指示がないか確認する

CLAUDE.mdの内容は、システムプロンプトの一部ではなく、その後のユーザーメッセージとして渡されます。公式は、厳密に守られる保証はないとしています。コミットの前など、決まった時点で必ず実行したい処理は、フックとして設定します。

Q. 定期的に更新する必要がありますか？

必要です。公式は、CLAUDE.md、サブディレクトリのCLAUDE.md、.claude/rules/を定期的に見直し、古い指示や食い違う指示を取り除くことを勧めています。Claudeが同じ間違いを繰り返したとき、チームの決まりが変わったとき、使う道具を入れ替えたときが見直しの機会です。/doctorを使うと、削れる内容の案が出ます。