claude.md 書き方ガイド｜コピペできるCLAUDE.mdテンプレと悪い例

この記事は、Claude Code に毎回同じ説明をしている実務担当者、個人事業主、少人数チームの責任者に向けた書き方ガイドです。読み終えると、個人用、プロジェクト用、業務チーム用の CLAUDE.md を作り、init 後の下書きを残す、削る、逃がすで整理できる状態になります。

CLAUDE.mdの役割と置き場所を最初に決める

Claude Code に作業を頼むたび、プロジェクトの目的、触ってよい場所、禁止事項、確認してほしいコマンドを毎回説明しているなら、先に置き場所を決める段階です。説明が会話に散るほど、次の依頼で同じ確認が戻ってきます。

前提1：CLAUDE.mdは毎回伝える文脈を置く

Claude Code Memory ドキュメントでは、CLAUDE.md は会話開始時に読み込まれるメモリとして説明されています。作業前に毎回渡したい文脈は、同じ入口から確認できる形にそろえます。

• プロジェクトの目的：何を達成する作業場所かを最初に固定する。
• 禁止事項：触ってよい範囲と避ける操作を短く書く。
• 確認コマンド：完了時に返してほしい確認結果を置く。
• 参照先：詳しい説明を別ファイルへ逃がし、入口だけ残す。

公開用に一般化した運用知見では、行動原則、必読、禁止事項、参照先を案内板にまとめ、詳細は別ファイルへ分けています。

前提2：個人用とプロジェクト用を分ける

置き場所は、個人の口調や好みを置く場所と、チームで共有する作業ルールを置く場所に分かれます。個人のファイルに共有ルールを入れると、他の人の Claude Code から見えない文脈になります。共有ファイルに個人メモを混ぜると、チーム全体の文脈が濁ります。

前提3：強制したい安全境界は権限設定に分ける

Claude Code Permissions ドキュメントで扱う deny、ask、allow や permission mode は、実行前に止めるための仕組みです。CLAUDE.md に「本番操作は避ける」と書く価値はありますが、止めたい操作は Claude Codeの法人セキュリティで確認する権限設定 側に分けます。文章ルールと制御設定を混ぜないことが、業務利用の最初の安全策です。

前提4：AGENTS.mdはCLAUDE.md側から参照する

AGENTS.md を使う環境では、Claude Code に読ませる入口を CLAUDE.md に置き、そこから @AGENTS.md を参照します。この記事では AGENTS.md との細かい比較には広げず、Claude Code に読ませる入口を CLAUDE.md に固定します。

次の表は、最初に迷いやすい置き場所だけをまとめたものです。行を選んで、自分のルールをどこへ置くか照合してください。

表を読むと、個人の口調はユーザー側、共有ルールはプロジェクト側、端末固有の事情はローカル側へ分ける形になります。止めたい操作は CLAUDE.md に背負わせず、permissions や hooks 側へ逃がすと、次の案内板も軽く保てます。

先に完成テンプレを選んで到達点を見る

白紙から書こうとすると、最初の一文で止まります。先に完成形を選び、自分の業務に合わない行を削る方が進みます。ここでは自社の案内板型ファイル、領域別上書き、pointer-only の運用から、公開できる形に抽象化した 3 つのテンプレを置きます。

テンプレ1：個人用CLAUDE.md

個人用は、口調、確認の癖、勝手に進めてほしくない行動を置く場所です。案件名や顧客名を入れず、どの作業でも繰り返す自分の好みだけに絞ります。

# 個人用 CLAUDE.md

## 口調
- 日本語で簡潔に答える
- 結論、要約、詳細の順で書く
- 不明点は推測せず、確認が必要な点として分ける

## よく使う確認
- 変更前に対象ファイルを読む
- 既存の書き方に合わせる
- 最後に実行した確認コマンドを書く

## 個人の禁止事項
- 許可なく外部サービスへ送信しない
- 機密情報を本文やログに貼らない
- 大きな削除や初期化を提案だけで実行しない

テンプレ2：プロジェクト用CLAUDE.md

プロジェクト用は、次に作業する人が迷う境界を先に固定する場所です。コードを読めば分かる説明を長く書くより、判断に使う項目だけを置きます。

• 目的：このプロジェクトで何を作るか。
• ディレクトリ：作業前に確認する主要な置き場。
• 確認コマンド：完了報告に含める検証結果。
• 編集禁止領域：事故を避けるために触らない場所。
• 完了条件：どこまで終えたら返すか。

# プロジェクト用 CLAUDE.md

## 目的
このプロジェクトは、業務用の記事、資料、運用ログを安全に作成するための作業場所です。

## よく使う場所
- `content/`：公開用の本文
- `templates/`：再利用する型
- `reports/`：確認結果と更新ログ

## 確認コマンド
- `npm test`：変更後の確認
- `npm run lint`：表記と構文の確認

## 編集禁止領域
- `certs/` と `.keys/` は読まない、削除しない
- 本番用の設定ファイルは、依頼があっても提案だけに留める

## 完了条件
- 変更点を3行以内で説明する
- 実行した確認コマンドと結果を書く
- 追加確認が必要な点を分ける

テンプレ3：業務チーム用CLAUDE.md

業務チーム用は、公開や送信の前に守るべき境界をそろえる場所です。自社運用では、root の案内板と領域別の詳細を分けることで、毎回読ませる量を抑えています。

• 送信禁止：顧客、社外、公開先へ勝手に送らない対象。
• 本番操作：実行前に承認や確認を挟む操作。
• 事実確認：出典、日付、担当者を確認する行。
• レビュー導線：誰に何を見せてから進めるか。
• 更新ログ：なぜ追記や削除をしたかの記録。

# 業務チーム用 CLAUDE.md

## 作業原則
- 読者、目的、公開先を確認してから本文を作る
- 事実、推測、未確認を分ける
- 公開前に担当者レビューが必要な箇所を明示する

## 送信禁止
- 個人情報、契約情報、未公開の顧客名を外部サービスへ送らない
- 送信が必要な場合は、送信先、内容、目的を先に確認する

## 本番操作
- 本番環境の削除、上書き、権限変更は実行しない
- 必要な場合は、手順案と影響範囲だけを書く

## 事実確認
- 数字、肩書、料金、仕様は一次情報で確認する
- 確認できない実績や改善率は書かない

## 更新ログ
- 失敗、レビュー指摘、同じ説明の繰り返しを更新理由にする
- 古くなった暫定ルールは削除候補に入れる

使い方1：急ぐ人はテンプレから始める

急ぐ場合は、3 つのうち一番近いテンプレを選び、固有名詞を入れる前に不要な行を削ってください。Claude Code 自体の始め方から確認したい場合は、入口記事の Claude Codeの使い方を業務担当者向けに始める方法 に戻ると、この記事の到達点が見えやすくなります。

手順1 initから下書きを作る

既存プロジェクトの説明を一から書こうとすると、ディレクトリ名やコマンドの棚卸しで止まりがちです。まず init で下書きを出し、その後に業務目線で削ると、作成と整理を分けられます。

手順1：対象フォルダでClaude Codeを開く

対象フォルダは、CLAUDE.md を置きたい作業単位に合わせます。個人メモを整えるならホーム側、プロジェクトの共有ルールなら該当プロジェクトのルートで開きます。ここを間違えると、生成された説明のスコープもずれます。

手順2：initで下書きを作る

公式 Memory docs と Claude Code の仕組みの説明では、init はコードベースを分析し、CLAUDE.md のたたき台を作る入口として案内されています。既存ファイルがある場合は、上書き前提で進めず、提案された改善点を確認してから反映します。

claude
/init

手順3：生成された説明を業務目線で読み替える

init の出力は、コードベース説明に寄りやすい下書きです。業務で使うなら、ディレクトリ紹介を増やすより「何を頼む場所か」「触ってよい範囲はどこか」「完了時に何を返すか」へ読み替えます。スラッシュコマンド全体を知りたい場合は Claude Codeコマンドの使い分け に分けて確認してください。

手順4：公開前に揮発しやすい仕様を確認する

init、読み込み順、AGENTS.md import、rules、Skills は仕様が変わる可能性があります。この記事では、公式ページで確認できる範囲に絞って扱います。

このCLAUDE.mdを、業務で毎回読む価値がある情報だけに整理してください。
残すもの、削るもの、Skillsやrulesへ逃がすもの、permissionsやhooksで制御するものに分けてください。
根拠が公式仕様に依存する行は、公開前確認が必要な項目として一覧化してください。

手順2 残す削る逃がすを仕分ける

CLAUDE.md が長くなる典型は、便利そうな情報を全部残すことです。新しい人に説明したいこと、作業手順、安全境界、暫定メモが同じ場所に積まれると、Claude Code が毎回読むべき文脈がぼやけます。

判断1：毎回必要な事実だけ残す

残す基準は、次回の依頼でも同じ説明をするかどうかです。毎回の判断に効く情報だけを CLAUDE.md に戻します。

• 目的：作業場所の到達点を固定する。
• 読者：出力を誰に向けるかをそろえる。
• 編集禁止領域：触らない場所を明確にする。
• 確認コマンド：完了時の検証を再現できる形にする。
• 完了条件：返答前に満たす状態を決める。

担当者の一時メモや、作業が終わった暫定ルールは更新ログに移します。

判断2：コードを読めば分かる内容は削る

ディレクトリの中身をそのまま説明する行は、すぐ古くなります。コードやファイル名から分かる情報は削り、判断に使う境界だけを残します。たとえば「content フォルダに本文があります」より、「公開前レビューが終わるまで content を上書きしない」の方が効きます。

判断3：長い手順はSkillsへ逃がす

Claude Code Skills ドキュメントでは、タスク固有の手順やチェックリストを Skills に分けられます。何度も貼る長い手順が CLAUDE.md に育ってきたら、Claude Code Skillsに逃がす長い手順 へ移します。常時読む文脈と、使う時だけ読む手順を分けます。

判断4：領域限定ルールは別ファイルへ分ける

Claude Code Large Codebases ドキュメントは、大きなリポジトリで root とサブディレクトリの CLAUDE.md を分ける考え方を示しています。記事、開発、経理、営業資料のように領域が違うなら、root は案内板にして、詳細ルールを領域側へ逃がします。

判断5：安全境界は権限設定かhooksへ分ける

本番操作、外部送信、機密情報の参照は、文章で頼むだけだと止めどころが曖昧です。permissions で許可、確認、禁止を分け、より強く検査したい操作は Claude Code hooksで強制する安全ルール へ送ります。CLAUDE.md には、なぜ止めるかという業務文脈を残します。

下書きの情報を見たら、次の表で処理を決めます。表では、毎回読む価値がある情報だけを CLAUDE.md に戻す順で見ます。文字量は、その過程で自然に減ります。

表で逃がし先を決めたら、どの情報を常時読む中心へ戻すかを次の図で確認します。CLAUDE.md に残すのは毎回の判断に使う文脈で、長い手順、安全制御、公開前確認は外側の置き場へ分けます。

このCLAUDE.mdに残した各行について、次回の依頼でも必要な理由を1文で説明してください。
理由が弱い行は、削る、Skillsへ逃がす、rulesへ分ける、permissionsやhooksで制御する、公開前確認に回す、のどれかに分類してください。

手順3 業務ルールを検証できる文に直す

CLAUDE.md に「丁寧に」「慎重に」「いい感じに」と書くと、読んだ瞬間は安心できます。ただ、次の作業で何を確認すれば守れたのかが分かりにくく、レビュー時にも直し方が曖昧になります。

差分1：曖昧な口調を行動に変える

曖昧な口調は、対象、条件、確認方法へ直します。自社の feedback log でも、技術名から入るより読者の状況と具体ファクトを先に置く修正が繰り返されています。CLAUDE.md でも「どう書くか」より「何を確認するか」まで落とします。

悪い例
- 丁寧に説明する
- 慎重に変更する
- いい感じに整える

良い例
- 変更前に対象ファイルを読み、既存の見出し、語尾、表記へ合わせる
- 削除、上書き、外部送信が必要な場合は、実行前に対象と理由を確認する
- 最後に変更点、確認結果、残った不明点を分けて書く

差分2：禁止事項を対象と条件まで書く

禁止事項は、対象と条件がないと広すぎます。「送信しない」だけでは、どの情報、どの送信先、どの例外が対象なのかが残ります。業務用テンプレでは、対象を行動単位に分けます。

• 個人情報：名前、連絡先、識別できる情報を含む行。
• 契約情報：金額、契約条件、交渉中の内容。
• 未公開の顧客名：公開許可がない社名や案件名。
• 本番設定：公開環境や送信先に影響する設定。

悪い例
- 危ないことをしない
- 本番を触らない
- 情報漏えいに注意する

良い例
- 個人情報、契約情報、未公開の顧客名は外部サービスへ送信しない
- 本番環境の削除、上書き、権限変更は実行せず、手順案だけを書く
- 機密情報を見つけた場合は、値を本文に写さず、ファイル名と確認が必要な理由だけを書く

差分3：定型業務は入力と出力を書く

定型業務は、入力、出力、完了条件をそろえると再利用しやすくなります。たとえば「記事を作る」と頼む場面では、素材、読者、出典台帳を先に渡し、本文、要約、確認点を返してもらう形にします。

## 記事作成の定型業務

入力
- 企画メモ
- 読者と検索意図
- 使用してよい出典台帳

出力
- 本文
- 冒頭の結論
- 確認が必要な未確定事項

完了条件
- 台帳外URLを使っていない
- 推測の数値を書いていない
- 読者が次にやることが分かる

差分4：参照先は正本と更新者を書く

「この資料を読んで」とだけ書くと、資料が増えた時に判断が崩れます。正本、補助資料、更新者を分けておくと、古い説明が残りにくくなります。自社運用では、Brain、episodes、領域別ファイルのように、判断の戻り先を明記しています。

悪い例
- 詳細は関連資料を読む
- 最新情報を確認する

良い例
- 正本は docs/operation-guide.md。判断に迷ったらこのファイルを優先する
- 補助資料は docs/examples/ に置く。正本と違う内容を見つけたら、正本の更新者に確認する
- 更新者は業務責任者。判断理由は更新ログに1行で残す

差分5：失敗時の確認コマンドを書く

失敗時の確認は、精神論より再現手順が効きます。テスト、lint、プレビュー、差分確認のように、作業完了時に返してほしい結果を書いておきます。証拠がない改善率や推奨行数は書かず、確認できる行動へ寄せます。

悪い例
- 失敗したら直す
- 最後に確認する

良い例
- 変更後に npm test を実行し、失敗した場合は失敗したテスト名と原因候補を書く
- 表示変更後にプレビューを開き、崩れた画面、再現手順、未確認箇所を分けて報告する
- 最後に git diff --stat で変更範囲を確認し、触ったファイルだけを要約する

失敗しやすいCLAUDE.mdを修正する

CLAUDE.md を作ったのに効かない時は、内容が足りないより、役割が混ざっていることが多いです。長い案内、止めたい操作、古い暫定メモ、必読ファイルの羅列が同じ場所に積まれると、次の依頼で判断が揺れます。

失敗1：長すぎて毎回読む価値が落ちる

長大化は、root を案内板に戻して直します。自社の pointer-only 型では、root は短い入口にし、詳しい設計や参照資料は別ファイルへ分けています。毎回読むファイルには、判断に必要な入口だけを残します。

失敗2：禁止事項を書いたのに操作が止まらない

禁止事項を書いても、Claude Code の権限境界は別の設定で決まります。止めたい操作は permissions や PreToolUse hook の候補へ分け、CLAUDE.md には業務上の理由と確認先を残します。

失敗3：古い暫定メモが残り続ける

暫定メモは、作業が終わった後も残りやすい情報です。失敗ログや feedback log を正本へ戻さないと同じ指摘が再発する、という自社の失敗知見からも、更新理由と削除判断を一緒に残す必要があります。

失敗4：必読ファイルを読ませただけで判断が変わらない

必読ファイルの列挙だけでは、何を判断に使うかが曖昧です。agent-worldview-injection の内部評価でも、読むだけより、抽出、織り込み計画、セルフチェックまで入れる方が反映されやすいと確認しています。CLAUDE.md では「読んで」より「この観点で判断して」と書きます。

失敗パターンは、修正先を先に決めると直しやすくなります。表の確認方法は、レビューで使える短い言葉に絞っています。

この表では、長すぎる行は案内板へ戻し、止めたい操作は permissions / hooks へ分け、古い暫定メモは更新ログと削除候補で扱います。長大化の修正だけは抽象論で終えず、次の匿名化した案内板型の実例で確認します。

長すぎる時
- 詳細手順は `docs/workflow.md` を参照する。CLAUDE.md には入口だけを残す。

禁止事項が止まらない時
- 本番環境の削除、上書き、権限変更は実行しない。制御は permissions または hooks で別途固定する。

古い暫定メモが残る時
- 暫定ルールは更新ログへ移し、残す理由がなくなったら削除候補に入れる。

読ませるだけで判断が変わらない時
- brand voice を読むだけで終えず、読者の現在地、根拠、次の行動を本文に入れる。

完了判定と更新ログを置く

CLAUDE.md を書き終えた直後は、完成した気になります。けれど実務では、次の依頼で同じ説明が戻ってくるか、レビュー指摘が減るか、止めたい操作が別設定に分かれているかを見て初めて判断できます。

判定1：次回も同じ説明をしなくてよい

一番分かりやすい判定は、次回の依頼文から削れる説明があるかです。目的、読者、禁止事項、確認コマンドを毎回貼っていたなら、それが CLAUDE.md に移っているかを見ます。

判定2：参照先と逃がし先が分かる

root に詳細を抱え込まず、参照先と逃がし先が分かる状態なら合格に近づきます。公式 Large Codebases docs では、root とサブディレクトリの CLAUDE.md を分ける考え方が示されています。

判定3：止めたい操作が権限設定に分かれている

本番操作や外部送信のように止めたい操作は、CLAUDE.md の文章に加えて制御設定へ分けます。permissions、hooks、社内レビューのどこで止めるかを分けておくと、監査時にも説明しやすくなります。

判定4：更新理由を短く残せる

更新ログには、追記した文章より先に変更理由を残します。トリガーを 4 種類に絞ると、なぜ残したかを後から確認できます。

• 失敗：同じ事故や手戻りを減らすために残す。
• レビュー指摘：次回も守るべき判断を正本に戻す。
• 同じ説明の繰り返し：毎回貼っている文脈を入口へ移す。
• 古くなった暫定ルール：削除や逃がし先変更の候補にする。

Anthropic の社内利用事例でも、業務終了時に documentation や workflow instructions を改善する運用が紹介されています。

判定5：公開前に公式仕様を照合できる

Anthropic の社内利用事例と公開 PDF は、CLAUDE.md や workflow instruction を継続的に整える運用の補助根拠になります。自社の CLAUDE.md を公開・社内展開する前には、仕様へ依存する対象行だけ再確認してください。

• Memory：CLAUDE.md、読み込み、配置の扱い。
• Permissions：許可、確認、禁止の境界。
• Hooks：操作前後に止める検査条件。
• Skills：長い手順の逃がし先。
• Large Codebases：root と領域別ファイルの分け方。

## 更新ログ

### YYYY-MM-DD
理由：同じ説明を3回繰り返したため
変更：作業目的と完了条件をCLAUDE.mdへ追加
逃がし先：長い手順は `docs/workflow.md` に移動
削除候補：古い暫定ルールを次回レビューで確認
公式確認：Memory、permissions、hooks の該当行を確認

よくある質問

ここからは、書き方の途中で再検索しやすい疑問だけを短く回収します。読み込み順や AGENTS.md との違いは別ページ向きなので、ここでは手を止めない範囲に絞ります。仕様に触れる回答は、本文中の公式リンクで確認できる範囲に絞ります。

FAQ1：CLAUDE.mdには何を書く

毎回伝える必要がある文脈を書きます。中心になるのは、次回の依頼文から削れる説明です。

• 作業目的：何を達成する場所か。
• 読者：誰に向けた出力か。
• 編集禁止領域：触ってはいけない場所。
• 確認コマンド：完了時に返す検証結果。
• 完了条件：どの状態で返答するか。
• 更新ルール：追記、削除、逃がし先変更の条件。

長い手順、領域限定ルール、安全制御は別の置き場へ分けます。

FAQ2：読み込み順はどこまで覚える

最初は、個人用、プロジェクト用、ローカル用が分かれていることだけ押さえれば十分です。詳細な読み込み順は公式 Memory docs を確認し、記事内では置き場所の判断に必要な範囲だけ使います。

FAQ3：AGENTS.mdとの違いは何を押さえる

Claude Code で使うなら、毎回読ませる入口を CLAUDE.md に固定し、必要に応じて AGENTS.md への参照を置きます。詳細比較へ広げる前に、最初の案内板を決めると実務では迷いが減ります。

FAQ4：何行くらいにする

推奨行数は、根拠がある場合だけ置きます。まず、常に読む価値がある行かを見ます。毎回の説明を減らす行は残し、コードを読めば分かる説明や一時メモは削ります。

FAQ5：hooksやSkillsも最初から必要

最初は CLAUDE.md だけで始めて十分です。長い手順が増えたら Skills、止めたい操作が出たら permissions や hooks の候補にします。必要になった時に逃がす順番で進めます。

次にやることを4個に絞る

ここまで読んだら、CLAUDE.md の仕組みをさらに調べる前に、今の作業場所へ 1 行だけ置く方が進みます。最初から完璧に作るより、次回の説明を 1 つ減らすことを目標にしてください。

次1：1行だけ個人用CLAUDE.mdを作る

まずは「日本語で簡潔に、変更点と確認結果を分けて返す」のように、どの作業でも繰り返す 1 行を個人用に置きます。最初の 1 行があるだけで、次の追記判断が楽になります。

次2：init後に残す削る逃がすで整理する

プロジェクト側は init で下書きを作り、残す、削る、逃がす、公開前確認へ分けます。便利そうな説明を増やすより、常に読む価値のある情報に戻すことを優先します。

次3：業務チーム用テンプレに禁止事項を移す

業務チーム用テンプレへ移す内容は、公開や送信の直前で事故につながる項目です。止めたい操作がある場合は、同時に権限設定や hooks の候補へ分けてください。

• 送信禁止：外部送信前に確認する対象。
• 本番操作：承認なしで実行しない操作。
• 事実確認：出典、日付、担当者の確認。
• レビュー導線：公開前に見る人と見る範囲。

次4：公開前に公式docsで揮発仕様を確認する

仕様へ依存する行だけ、公開前に次の公式ドキュメントで確認します。

• Memory
• Permissions
• Hooks
• Skills
• Large Codebases