Claude CodeのCLAUDE.md書き方｜3つの置き場所と、書いても守られないもの【2026年版】
目次
Claude Codeを使い始めて数週間たつと、同じ注意を何度も打ち込んでいることに気づきます。「日付は今日の日付を取り直して」「その言い方は社外では使わないで」「ファイルは全部まとめてコミットしないで」。毎回言うのが面倒になって、CLAUDE.mdに書き足していく。ここまでは誰でも通る道です。
問題はその先です。書き足すほど、ファイルは長くなり、どこに何を書いたか自分でも分からなくなる。しかも、書いたのに守られないことが起きる。
当社は営業・マーケの定型業務をClaude Codeで回していて、全プロジェクト共通のCLAUDE.mdは172行、このプロジェクト専用のものが48行あります。加えて、会話から残した「メモ」が268件。この記事は、それを育ててきた過程で分かったどこに何を書くかと、書くのをやめて別の仕組みに移したものの記録です。
この記事の要点
- CLAUDE.mdは会話の冒頭で毎回読まれる前提メモ。置き場所は「全プロジェクト共通」「プロジェクト専用」「会話から残すメモ」の3つに分けると、重複と矛盾が減る
- 書くのは毎回効いてほしい前提と判断基準。コードを読めば分かること、一度きりの指示、長い手順の全文は書かない
- 1つのルールは「何を・なぜ・どう当てはめるか」の3点で書く。理由がないルールは、想定外の場面で正しく応用されない
- 長くするほど効かなくなる。当社はメモの目次が232行まで膨らみ、200行目より後ろが読み込まれていなかった
- 「絶対にしない」系のルールは、文章で書いても破られる。破られたら困るものは、実行前に機械が止める仕組みに移す
CLAUDE.mdとは｜毎回の会話の冒頭で読まれる「前提メモ」
CLAUDE.mdは、Claude Codeが作業を始めるときに自動で読み込む指示ファイルです。 新しく入った同僚に最初に渡す「うちのやり方」の紙だと考えると分かりやすいでしょう。毎回口で説明していた前提を、1回書いておけば毎回読んでもらえます。
公式ドキュメントでは、全プロジェクトで読まれるユーザー用のファイル（`~/.claude/CLAUDE.md`）と、リポジトリの直下に置くプロジェクト用のファイル（`./CLAUDE.md`）が案内されています。当社はこれに、会話の中で「これは覚えておいて」と残すメモの置き場所を加えて、3つに分けて運用しています。
| 置き場所 | 書くこと | 当社の例 | 当社の規模 |
|---|---|---|---|
| 全プロジェクト共通（`~/.claude/CLAUDE.md`） | どの仕事でも変わらない前提 | 成果物の保存場所の伝え方／長時間作業の途中経過の残し方／社外文面で使わない言葉 | 172行 |
| プロジェクト専用（`./CLAUDE.md`） | そのリポジトリでだけ効く注意 | 施策を台帳に起票する手順／入れ子になった別リポジトリの扱い／日付は実行時に取得する | 48行 |
| 会話から残すメモ | 仕事を通じて分かった事実・好み・過去の判断 | 「この画面は640px判定では外れる」「この表現は顧客に誤解された」 | 268件 |
ポイントは、同じルールを2か所に書かないことです。当社は9月14日に、プロジェクト専用ファイルに書いていた共通ルールを全体用へ移し、プロジェクト側は「このリポジトリ固有の注意」だけに縮めました。同じルールが2か所にあると、片方だけ更新されて、古い方が読まれる事故が起きるからです。
書くこと・書かないことの線引き
判断基準は「毎回の会話で効いてほしいか」です。 1回しか使わない指示や、ファイルを開けば分かることまで書くと、肝心の前提が埋もれます。
| 書く | 書かない（別の場所へ） |
|---|---|
| 毎回効いてほしい前提（例：日付は必ず実行時に取得する） | 一度きりの指示 → その会話で言えば足りる |
| 判断に迷う場面の基準（例：迷ったらこちらを選ぶ） | コードやフォルダ構成を読めば分かること |
| そのルールを置いた理由 | 長い作業手順の全文 → 手順書やスキルに分けて、CLAUDE.mdからは名前だけ指す |
| 例外の線（例：この2つのときだけ使ってよい） | 「絶対にしない」系の禁止で、破られたら実害が出るもの → 機械のチェックへ（後述） |
当社のプロジェクト専用ファイルにある「日付は実行時に `date` で取得（記憶の日付を使わない）」は、書く側の典型です。AIは会話の流れや以前の記憶から日付を書いてしまうことがあり、日付を扱う作業ではそれがそのまま記録のずれになります。1行で済み、毎回効いてほしく、例外がない。こういうルールはCLAUDE.mdに向いています。
逆に、記事の公開手順やデプロイの確認手順のように数十行にわたるものは、手順書として別ファイルに置いています。CLAUDE.mdに全文を書くと、手順を使わない作業でも毎回それを読むことになり、他のルールが目に入りにくくなります。
1つのルールは「何を・なぜ・どう当てはめるか」で書く
ルールには必ず理由を添えます。 理由がないと、AIは書かれた場面でしか従えず、少し形の違う場面で応用できません。
当社のメモは、1件ごとに「事実」「なぜ（Why）」「どう当てはめるか（How to apply）」の3点で書く形にしていて、268件のうち168件に理由の行が入っています。たとえば次のような書き方です。
ルール：顧客・読者の目に触れる文面で、説明しないと意味が取れない比喩の造語を使わない。
なぜ：社内で作った指標名を改名したのに、改名前に作っておいた予約投稿がそのまま出て、同じ指摘を2回受けた。
どう当てはめるか：言葉を改名したら、その場で予約投稿・下書き・図版の在庫まで洗う。公開済みのものは記録として残し、これから出るものだけ直す。
この例は、実際に当社で起きたことです。9月15日に社内の指標名を言い換えると決め、CLAUDE.mdにも書きました。ところが9月19日に、改名前に予約しておいたX投稿がそのまま公開されました。 CLAUDE.mdが効くのは、これからAIが書くものだけです。すでに作り置かれた予約投稿には効きません。
だから、このルールには理由と当てはめ方まで書きました。禁止語の一覧だけでは、「次に別の言葉を改名したとき、在庫まで洗う」という応用が効きません。 理由が書いてあれば、AIは一覧にない言葉でも同じ動きを選べます。
長くするほど効かなくなる｜当社のメモは200行で切られていた
CLAUDE.mdとメモは、長くするほど1行あたりの効き目が落ちます。 そして当社は、それを実際に踏みました。
会話から残すメモには、全件を1行ずつ並べた目次ファイルがあり、会話の冒頭ではその目次が読み込まれます。当社の目次は232行まで膨らんでいて、ある日の会話の冒頭に「232行のうち、201行目以降の32行は読み込まれていない」という警告が出ていました。後から足したメモほど目次の下の方に並ぶので、いちばん新しい判断から順に、読まれていなかったことになります。
正直に言えば、これはまだ直しきれていません。当社の手元でも、目次の1行に経緯まで詰め込んだ行が残っています。直し方として決めたのは次の3つです。
- 目次は1件1行・200字以内にして、詳しい経緯は各メモの本文に移す
- 同じテーマのメモが3件を超えたら、1件にまとめ直す
- 古くなったメモ（使わなくなった仕組みの説明など）は消す。残すより消す方が、残りのメモが効く
全体用のCLAUDE.mdも同じです。末尾に「いつ・誰の依頼で・何を足したか」の変更履歴を書いているので、棚卸しのときに「この行はなぜあるのか」を辿れます。このプロジェクト専用ファイルは、8月1日から9月18日までの約7週間で14回書き換えました。書き足すたびに、どこか1行を消せないかを確認するのが、長さを保ついちばん手軽な方法です。
書いても守られないものは、機械に移す
「絶対にしない」系のルールは、CLAUDE.mdに書いても破られます。 これはCLAUDE.mdの書き方の問題ではなく、文章で頼むという方式の限界です。
当社でいちばん分かりやすかったのは、ブラウザ操作のルールです。「ブラウザの選択でユーザーに確認の質問をしない」「この操作は呼ばない」とCLAUDE.mdに書いていましたが、ツールの出力に「ユーザーに選ばせてください」と書かれていると、AIはそちらに引っ張られて質問してしまう。そこで9月12日に、実行前にその操作を検知して止める仕組み（フック）を入れました。文章で頼む段階から、実行の手前で止める段階に移したわけです。
役割の分け方は、次のように落ち着きました。
| 仕組み | 向いているもの | 当社の例 |
|---|---|---|
| CLAUDE.md | 判断の基準・理由・好み | 社外文面の言葉選び、成果物の保存場所の伝え方 |
| 手順書・スキル | 決まった順番がある作業 | 記事の公開、商談前のリサーチ |
| 機械のチェック（フック・実行前の確認） | 破られたら実害が出る禁止 | 決められていない操作の阻止、作業終了時の変更の取りこぼし防止 |
注意したいのは、機械に移したあともCLAUDE.mdから消さないことです。CLAUDE.mdには「なぜその操作を止めているか」を残します。 理由が書いてあれば、AIはチェックに止められる前に自分で避けますし、止められたときも別のやり方を正しく選べます。機械のチェックの作り方はClaude Codeは危険か｜実際に起きた4つの事故と、機械で止める設計で詳しく書いています。
「全部CLAUDE.mdに書いておけば安心」への答え
おすすめしません。 書いておけば安心、と思われるかもしれませんが、実際に起きるのは逆です。
- 長くなるほど、新しく足したルールが埋もれる（前述の200行の件）
- 書いた本人も全体を覚えていないので、矛盾したルールが同居する
- 「書いたから大丈夫」と思い込み、守られているかを確かめなくなる
CLAUDE.mdは「書いたら終わり」の設定ファイルではなく、育てて刈り込む文書です。月に1回、全体を頭から読み、「この1か月で効いた場面があったか」を1行ずつ確かめるだけでも、ずいぶん効き目が戻ります。
最初の1枚の作り方｜3日間の口ぐせから始める
白紙から書こうとすると、一般論ばかりの長いファイルになります。 当社がすすめるのは、次の順番です。
- 3日間、Claude Codeに同じことを2回以上言った指示をメモする。 これが最初のCLAUDE.mdの中身です。最初はそれだけで十分です
- それぞれに「なぜ」を1行足す。 理由が書けない指示は、たぶん毎回は要らない指示です
- 全プロジェクト共通か、このプロジェクトだけかで置き場所を分ける
- 2週間後に読み返し、効いていない行を消す。 守られていない行があれば、それは書き方を直すか、機械のチェックに移す候補です
どのモデルに作業させるかも、CLAUDE.mdや手順書に書いておくと揃います。当社の分け方はClaude Codeのモデル使い分けにまとめています。営業・マーケのチームで最初の1枚を一緒に作る支援は、Claude Code導入支援でも行っています。
よくある質問
Q. CLAUDE.mdには何を書けばいいですか？
毎回の会話で効いてほしい前提と判断基準です。目安は「この3日間で2回以上口で言った注意」。コードを読めば分かること、一度きりの指示、長い作業手順の全文は書かず、手順は別ファイルに分けてCLAUDE.mdからは名前だけ指します。
Q. CLAUDE.mdはどのくらいの長さが適切ですか？
決まった上限より、「足すたびに1行消せないか確認する」運用の方が効きます。当社は全体用が172行、プロジェクト用が48行ですが、会話から残すメモの目次は232行まで膨らみ、200行目より後ろが読み込まれていませんでした。長さが効き目を下げるのは確かです。
Q. 全体用とプロジェクト用は、どう使い分けますか？
どの仕事でも変わらない前提（成果物の保存場所の伝え方、社外文面の言葉選びなど）は全体用、そのリポジトリでだけ効く注意（台帳への記録手順、フォルダ構成の注意など）はプロジェクト用に置きます。同じルールを両方に書かないことがいちばん大事です。
Q. CLAUDE.mdに書いたのに守られません。どうすればいいですか？
まず理由が書いてあるかを確認してください。理由のないルールは、少し形の違う場面で応用されません。それでも破られて実害が出るもの（送信・削除・公開など）は、文章で頼むのをやめ、実行前に機械が止める仕組みへ移します。CLAUDE.mdにはその理由だけを残します。
Q. チームで使う場合、CLAUDE.mdは誰が管理すべきですか？
プロジェクト用はリポジトリに入れて、変更履歴が残る形で管理するのが安全です。当社はファイルの末尾に「いつ・誰の依頼で・何を足したか」を書き、棚卸しのときに経緯を辿れるようにしています。足す人は誰でもよく、消す判断を月1回まとめて行う担当を1人決めておくと膨らみすぎません。
---
執筆・監修：佐々木 優希（AIリモートワーカー代表／上場企業 営業統括 兼 AI責任者）
自社の営業・マーケ業務をClaude Codeで運用しており、本記事の行数・件数・事故の記録はすべて自社の運用記録に基づいています。