CLAUDE.mdの書き方｜配置・テンプレート・効かない原因まで

CLAUDE.mdの置き場所と読み込み順、最小テンプレート、/contextによる確認方法を解説。rules・Skills・auto memoryとの使い分けと、指示が効かない場合の診断表を掲載。

Claude Codeを、実際の業務で使える形に。株式会社PLaiでは、自社の資料を活かしたナレッジの構築から、AI社員の導入・運用までを支援しています。

結論：CLAUDE.mdは、Claude Codeへ毎回伝えたい作業上の前提を保存するMarkdownファイルです。短い指示を置き、読み込みと出力を別々に確認して育てます。

最初はプロジェクト直下に1枚。実際に読み込まれたかは /context で確認します。
会社紹介を増やすより、実行するコマンド・参照先・完了条件を具体的に書きます。
自然文の禁止事項だけではアクセスを強制制限できません。権限設定とは役割を分けます。

対象読者：CLAUDE.mdを初めて作る方、指示が効かない・長くなった・チームで内容がずれると感じる方

読了後にできること：置き場所を選び、最小テンプレートを作り、効かない原因を順番に調べられます。

「同じ説明を繰り返している」「担当者によってファイルの置き場所が変わる」。こうした場面では、依頼のたびに文章を足す前に、共通の前提をファイルへ切り出すと管理しやすくなります。ただし、書いたルールが必ず守られるわけではありません。この記事では、書く内容だけでなく、読み込まれた証拠と成果物の確認方法まで扱います。

CLAUDE.mdとは：毎回伝える前提を、見直せるファイルにする

たとえば「テストはどのコマンドで動かすか」「文章の下書きはどこへ保存するか」「確定済みの資料はどれか」を毎回説明しているなら、その情報が候補です。会話だけに残すと探し直す必要がありますが、ファイルにすれば差分を確認し、チームで共有できます。

CLAUDE.mdの内容は、Claudeが判断するための文脈として扱われます。ファイル操作を禁止する設定そのものではありません。厳密に止めたい操作は、権限設定・フック・実行環境の制限を別に設計してください。

公式資料：CLAUDE.mdとauto memoryの違い（確認日：2026年10月6日）

公式資料：Claude Codeの権限設定（確認日：2026年10月6日）

置き場所と読み込みタイミングを先に決める

置き場所	用途	チーム共有の考え方
~/.claude/CLAUDE.md	自分の全プロジェクトに共通する好み	個人設定。会社固有の事実を混ぜすぎない
プロジェクト/CLAUDE.md または .claude/CLAUDE.md	そのプロジェクトの作業手順や構成	共有するルールを置く
プロジェクト/CLAUDE.local.md	自分だけのプロジェクト設定	Gitへ含めない設定を確認する
子フォルダ/CLAUDE.md	特定領域でだけ必要な前提	共通ルールを重複させず、違いだけを書く

起動位置から上の階層にある指示と、これから作業する子フォルダの指示では読み込みのタイミングが異なります。前者は起動時に読み込まれ、後者はその領域のファイルを扱う際に読み込まれます。複数ファイルの内容は文脈に加えられるため、「子の指示を書けば親の矛盾した指示が消える」と考えないでください。

公式資料：配置場所と読み込み順（確認日：2026年10月6日）

例：ブログだけ文体を変えたい

プロジェクト全体では「日本語で報告する」、articles配下では「本文はですます調、表は簡潔な体言止め」と分けます。全体に「すべて常体」と書いたまま、子に「ですます調」を足すと衝突します。まず親側の適用範囲を明確にし、それから子へ必要な差分を書きます。

作り方：初期案、手直し、読み込み確認の3段階

1. 作業フォルダと対象を確認する

ターミナルでプロジェクトへ移動してClaude Codeを起動します。初めて試す場合は、顧客データや公開先の認証を含まない練習用フォルダを使うと、結果を確かめやすくなります。

cd "/path/to/your-project"
claude

2. /initの初期案を自分の作業に合わせる

初期案を作る場合はClaude Code内で /init を実行できます。出てきた内容をそのまま会社の正本にせず、存在しないコマンド、古い構成、個人だけの事情が混ざっていないかを読みます。手書きで始めても構いません。

/init

3. /contextと小さな依頼で確認する

ファイルを保存したら、新しいセッションで /context を開き、Memory filesの一覧を確認します。その後「指定の保存先へ下書きを作る」など、結果を見て判定できる依頼を1つ試します。ファイルが一覧にあることと、依頼した行動が正しいことは別の確認です。

/context

公式資料：初期化と読み込みの確認（確認日：2026年10月6日）

確認対象	確かめること	失敗したら
読み込み	意図したファイルが一覧にある	名前・位置・起動ディレクトリを調べる
内容	参照先が存在し、矛盾がない	古いパス・重複ルールを直す
行動	出力先・形式・必要な確認が合っている	曖昧な一文を具体的な判定条件へ変える

手書きで作るときは、ファイル名と保存形式を確認する

CLAUDE.mdはプレーンテキストで保存するMarkdownファイルです。見出しには #、箇条書きには - を使えます。文字装飾を持つ文書形式ではなく、実際のファイル名がCLAUDE.mdになっていることを確認します。拡張子が非表示の環境でCLAUDE.md.txtと保存していないかも見てください。

そのまま書き始められる最小テンプレート

以下は、社内文書の下書きを作るプロジェクト向けの例です。実在の会社情報は含めていません。パスやコマンドは自分の環境に合わせて置き換え、使わない行は削ってください。

# プロジェクトの前提
このフォルダでは社内文書の下書きを作る。外部への公開は行わない。

## 最初に確認する資料
- docs/index.md: 資料の一覧と正本へのリンク
- templates/report.md: 報告書の見出しと記入例

## 作業の進め方
- 依頼された範囲の資料を読み、参照したファイル名を示す。
- 資料にない数値や日付は推測せず「未確認」と書く。
- 新しい下書きは drafts/ に保存する。
- 確定済み文書を変更する場合は、先に変更案と差分を示す。

## 完了前の確認
- 依頼された項目がそろっているか確認する。
- 出典のファイルを開き、数値と日付を照合する。
- 未確認事項が残る場合は、完成した部分と分けて報告する。

この例の狙いは、AIに長い自己紹介を読ませることではなく、資料・出力先・完了条件を明確にすることです。「丁寧に作る」だけでは合否を判定できませんが、「すべての数値に出典を付ける」なら確認できます。外部公開を止める文章は作業上の指示であり、公開権限を無効にする設定の代わりにはなりません。

テンプレートの項目	残す理由	自分用に直すポイント
資料の案内	探す順番と正本を示す	存在するパスだけを載せる
未確認の扱い	推測で空欄を埋めるのを避ける	未確認を誰が確認するか決める
下書きの保存先	原本と作業中の文書を分ける	実在する出力先にする
完了前の確認	完成の意味をそろえる	見た目だけでなく内容の合否を定義する

参照先も含めて試す例：docs/index.mdには「練習資料は meeting.txt。原文だけを根拠にする」、templates/report.mdには「決定事項／未決事項／確認先」という3見出しを置きます。meeting.txtに「草案期限は10月15日、担当は未定」と書き、drafts/へ報告を作らせます。3見出し、期限、担当未定がそろうことを照合し、存在しない参照先を指定した場合は想像で埋めず不足を報告するかも試します。架空資料での確認例です。

開発用なら、存在するテストコマンドを記載する

文書業務の例を開発プロジェクトへ転用するときは、言語の一般論より、実際の検査方法を残します。次はpackage.jsonに各スクリプトが定義されていると仮定した記入例です。未定義のコマンドは自分の環境のものへ置き換えてください。

# 構成
- src/：アプリケーションのコード
- tests/：動作の確認用テスト

## 変更後の確認
- テスト：npm test
- 型の検査：npm run typecheck
- 実行した検査、結果、未確認事項を報告する。
- 検査が失敗した場合は、変更による失敗か既存の問題かを確認する。

「品質を高くする」だけの指示を、確認できる行動へ変えた例です。テストが通ったことと、依頼された機能が画面で使えることも分けて確認します。

CLAUDE.mdに書くべき7項目

何を書けばよいか迷う方のために、書くべき項目を7つに整理しました。まず一覧表で全体を把握してください。

#	項目	書く内容の例
1	会社・チームの前提	事業内容、組織構成、大切にしている価値観
2	絶対ルール	機密情報を外部に送らない、特定の操作は必ず確認を取る
3	用語集	社内の略称、商品名、独自の呼び方の意味
4	ファイル案内図	どのフォルダに何が入っているかの簡単な地図
5	口調・文体	ですます調で書く、絵文字は使わない、ブランドトーン
6	禁止事項	誇大な表現、未承認の数値、使ってはいけない言葉
7	参照先	詳細情報が書かれた別ファイルのパスやリンク

1. 会社・チームの前提

どんな会社で、何を大切にしていて、どんな体制で動いているのかという基礎情報です。ここが書かれているだけで、Claude Codeは依頼の背景を踏まえた提案や成果物を返しやすくなります。事業内容だけでなく、「スピードより正確さを優先する」「対外的な発信は慎重に」といった価値観のレベルまで書いておくと、判断が分かれる場面での挙動が安定します。

2. 絶対ルール

「これだけは絶対に守ってほしい」という一線を明文化する項目です。機密情報を外部サービスに送らない、対外的な送信は必ず人間の承認を経る、破壊的な操作の前には確認を取る、といった安全に関わるルールを作業上の指示としてここに書きます。権限を強制する設定も別途確認します。曖昧な努力目標ではなく、「守れているか・いないか」がはっきり判定できる形で書くのがコツです。

3. 用語集

社内独自の略称やプロジェクトコード名、商品名の略し方などをまとめておくと、指示文が短くて済みます。商品やサービスに独自の略称がある場合は、その定義も候補になります。同音異義語や、部署によって呼び方が違う言葉があるなら、その使い分けもあわせて書いておくと誤解を防げます。

4. ファイル案内図

「請求書のテンプレートはここ」「過去の議事録はここ」といった、フォルダ構成の簡単な地図です。これがあるだけで、Claude Codeが目的のファイルを探す手間が減り、的外れな場所を提案されることも少なくなります。フォルダの数が多い会社ほど、この案内図の有無が作業スピードに直結します。

5. 口調・文体

ですます調で書く、絵文字は使わない、専門用語はかみ砕く、といった文体の指定です。特に対外文書を扱う会社では、ブランドの一貫性に直結するため、早めに明文化しておく価値があります。同じ内容の文章でも、口調が指定されているかどうかで、そのまま使える完成度に差が出ます。

6. 禁止事項

誇大な表現、未承認の実績数値、特定の固有名詞など、「書いてはいけないこと」をリスト化します。ルールが明文化されていれば、AIだけでなく新しく加わった人間のメンバーへの説明にも流用できます。過去に実際に誤って書いてしまった表現があれば、既存の項目と統合し、同じ依頼で再発しないか確認します。

7. 参照先

すべてを1つのCLAUDE.mdに詰め込む必要はありません。「詳しい手順は別ファイルのここを見て」という参照先を書いておけば、CLAUDE.md自体は簡潔なまま、必要な情報にだけ都度アクセスさせられます。参照先が増えてきたら、案件別・業務別にファイルを分けて、CLAUDE.mdはその「目次」として機能させる形に育てていくとうまく回ります。

業種別のCLAUDE.md記載例

7項目の中でも「絶対ルール」と「用語集」は業種によって書く内容が大きく変わります。イメージをつかみやすいように、業種別の記載例を一覧にしました。

業種	絶対ルールの例	用語集の例
マーケティング・広告代理店	クライアント名を他案件の文脈と混同しない	案件コード、社内独自のKPI名
EC・小売	在庫数・価格は必ず最新データを確認してから記載する	商品の型番・略称、セール名の呼び方
SaaS・IT企業	顧客の契約情報や個人情報を外部に出さない	プラン名の略称、社内システムの呼び名
コンサルティング	未公開の分析結果をクライアントの許可なく共有しない	フレームワーク名、プロジェクトの略称
士業・専門サービス	個別の法律・税務判断は必ず有資格者が確認する	業界特有の制度名、書類の正式名称

業種が違っても、「何を書くか」の型（会社の前提・絶対ルール・用語集・ファイル案内図・口調・禁止事項・参照先）そのものは共通しています。まずは自社の業種に近い行を参考に、絶対ルールと用語集から埋めていくと着手しやすくなります。

やってはいけないアンチパターン

CLAUDE.mdは便利な仕組みですが、書き方を誤ると逆効果になることもあります。代表的な4つのアンチパターンを紹介します。

長すぎるCLAUDE.md

あらゆる情報を詰め込みすぎると、かえって重要なルールが埋もれてしまいます。CLAUDE.mdは「毎回共通して踏まえてほしい前提」だけに絞り、詳細な情報は前述の「参照先」を使って別ファイルに逃がすのが基本です。読み返してみて、削っても実害がない一文がないかを定期的にチェックする習慣も効果的です。

何でも書こうとする

1回限りのイベント情報や、時間が経てば変わってしまう運用のTipsまで書き込んでしまうと、内容がすぐに古くなり、信頼できないファイルになってしまいます。永続的なルール・前提だけをCLAUDE.mdに残し、一時的な情報は別の場所で管理するという線引きを意識してください。判断に迷ったら「半年後に読んでも通用する内容か」を基準にすると分けやすくなります。

一度書いたら更新しない

CLAUDE.mdは、一度作って終わりのファイルではありません。実際の運用の中でズレや不足に気づいたら、その都度書き加えていく前提の「育てるドキュメント」です。更新を止めた瞬間から、現実の運用との差が広がっていきます。特に、組織変更や新しいルールの導入があったタイミングは、更新を忘れやすいので注意してください。

抽象的すぎる表現でごまかす

「わかりやすく」「丁寧に」といった抽象的な言葉だけでは、Claude Codeにも人間にも解釈の余地が残ってしまいます。「専門用語を使わず、入社初日の新人にも伝わる言葉で」のように、判断基準まで具体化して書くことで、狙ったとおりの出力に近づきます。

CLAUDE.md・rules・Skills・auto memoryの使い分け

内容	置き場所の候補	例
毎回必要な短い前提	CLAUDE.md	テスト方法、正本の位置、共通の完了条件
特定のファイルだけに適用する指示	.claude/rules/の対象指定	記事、API、テストコードで違う書式
呼び出したときに使う作業手順	Skills	週報を集計して出力する一連の手順
セッションで得た学び	auto memory	繰り返し使う好みや補足。内容を確認して管理

詳しいファイルを分ける方法には、単に参照先を書く方法と、@記法でインポートする方法があります。インポートは参照先を自動で文脈へ展開するため、ファイルを分けた分だけ読み込む量が減るわけではありません。いつも必要な短い前提と、作業時だけ必要な詳細を分けることが先です。

Agent・Skills・MCP・実行環境の関係を示す、Anthropicの公式構成図。
出典：Anthropic ↗
この画像の見方
左はエージェントに与える設定、右は実行環境のファイルです。スキルは手順や補助ファイルをまとめ、MCPは外部のサーバーへ接続する役割として描かれています。

公式資料：インポートと対象別ルール（確認日：2026年10月6日）

再利用する仕事の手順はClaude Code Skillsの作り方、外部サービスへの接続はClaude Code MCPの設定で扱っています。

記事フォルダだけに文体を適用するrulesの例

記事だけに必要なルールは、.claude/rules/article-style.mdへ分けられます。次はプロジェクト直下のdrafts/にあるMarkdownを対象とする例です。

---
paths:
  - "drafts/**/*.md"
---

# 記事の文体
- 読者向けの文章は日本語の「です・ます」で書く。
- 書き直す案は「要点」「本文」「確認事項」の見出しで示す。
- 元資料にない日付や実績は足さない。

確認用にdrafts/notice.mdとnotes/decision.mdを作り、短い練習文を入れます。作成時の会話を引き継がない新規セッションで、次のように依頼してください。

Readツールで drafts/notice.md を読んで、記事向けに書き直す案を会話へ出してください。ファイルは変更しないでください。

その後/contextで対象ルールが読み込まれたかを確認し、出力も3見出し・文体・事実の保持という条件で見ます。対象外の確認は別の新規セッションでnotes/decision.mdだけをReadツールで読み、このルールが読み込まれていないかを調べます。同じ会話で続けると、先に読んだルールが文脈へ残り、読み込み条件の比較になりません。

pathsはルールの読み込み条件であり、ファイルへのアクセス権の制限ではありません。対象パターンに一致するファイルへのRead・Write・Editで読み込まれます。ファイルを作ったのに最初から読み込まれる場合は、frontmatterの---やYAMLの字下げも確認します。

公式資料：pathsによる対象指定・frontmatterの解釈（確認日：2026年10月6日）

CLAUDE.mdが効かないときの確認表

症状	最初に調べること	改善の例
読まれていない	起動位置、ファイル名、/context	別フォルダで起動していないか確認する
一部だけ守られない	指示の具体性と相互矛盾	「きれいに」から「見出しと出典を付ける」へ
更新後も古い動きをする	実際に参照したファイルと変更の読込	新規セッションで同じ小さな依頼を試す
長くなり重要な項目が埋もれる	常時必要か、古い一時情報か	手順はSkills、領域固有の指示はrulesへ
禁止した操作が可能	自然文と権限設定の混同	対象ツールや実行環境の制限を確認する

公式文書では1ファイル200行未満が目安として案内されています。200行に収めれば必ず正しく動くという保証ではありません。短くしても「最新版を見て」のような曖昧な指示だけなら、見る先を判断できません。重複を減らしながら、参照先と判定条件は残します。

公式資料：簡潔な指示とトラブルシューティング（確認日：2026年10月6日）

更新は、追記だけでなく統合と再確認まで行う

同じ指摘が続く場合はルール化の候補ですが、その場の事情をすべて永久ルールにしないでください。まず既存の指示に同じ内容がないかを探し、「いつ使うか」「どこまで適用するか」を決めます。1度きりの納期や会議の内容は、案件の資料へ置くほうが管理しやすくなります。

変更理由と困った出力を短く残す。
既存のルールを直すのか、新しい項目が必要かを判断する。
差分を読み、他の指示と衝突していないか確認する。
問題が起きた依頼を再度試し、別の通常依頼も崩れていないか見る。
不要になったルールは履歴を残して整理する。

チームで使う場合は編集する担当を決め、変更をレビューできる場所へ保存します。大切なのは追記の回数ではなく、読者もAIも「現在有効な指示はどれか」を追えることです。

よくある質問

日本語で書いてもよいですか？

日本語で書けます。文章の長さより、対象と期待する行動を具体的にすることを優先してください。コマンド名やパスは実際に使う表記で残します。

AGENTS.mdがある場合もCLAUDE.mdが必要ですか？

v2.1.277以降はAGENTS.mdの直接読込に対応しています。既定では、作業ディレクトリと上位階層にCLAUDE.md・.claude/CLAUDE.md・CLAUDE.local.mdがない場合にAGENTS.mdを読みます。両方ある場合の扱いは /config のProject instructionsで確認します。旧版や対応機能を無効にした環境などでは、CLAUDE.mdから @AGENTS.md をインポートする方法を使います。実際の読込を確認し、同じ説明を複製して別々に保守する状態を避けましょう。

公式資料：AGENTS.mdの対応条件（確認日：2026年10月6日）

パスワードやAPIキーを書いてよいですか？

書かないでください。チーム共有やAIへの入力に混ざるため、認証情報は組織で決めた秘密情報の管理方法を使います。CLAUDE.mdには、必要な認証をどの正規手順で行うかだけを書きます。

毎回全部を読み直させれば解決しますか？

情報量を増やすだけでは矛盾や曖昧さは消えません。読み込みの確認を行ったうえで、問題の依頼に必要な最小の指示に絞って試すと、原因を分けやすくなります。