2分で Claude が変わる。CLAUDE.md に書くべき21の指示【コピペ保存版】

毎回 Claude に自己紹介してませんか？

Claude を仕事で使っていて、こんな経験ありませんか？

• 新しい会話を開くたびに「僕の仕事は◯◯で、文体はカジュアル目で、専門用語は避けて……」と書き始めている

• 同じ指摘を3回しても、また同じやらかしを繰り返される

• 「これ前に直したよね？」というやり取りが、月に何回も発生する

僕も最初の数ヶ月はこの状態でした。Claude が悪いんじゃなくて、Claude は会話をまたいで人間を覚えていない、というだけの話。毎回ゼロから始まる新人スタッフに、毎日同じオリエンテーションをやっているようなものです。

これを ファイル1個 で解決するのが CLAUDE.md です。

「これ開発者向けでしょ？」と思った人、半分正解で半分間違いです。たしかに CLAUDE.md の発祥は Claude Code という開発者向け CLI ツール。でも書ける中身は どの職種の人にも効く 指示テンプレートで、ライター・マーケター・経営者・リサーチャー・士業の方が使っても効果が出ます。

ChatGPT の「カスタム指示」を使ったことがある人は、「これと何が違うの？」と思うかもしれません。違いは2つあります。

1つ目は 読み込みタイミング：CLAUDE.md は「そのフォルダで作業するとき」だけ読まれるので、業務用と趣味用で指示を分けられる。

2つ目は 書ける情報の質と量：カスタム指示の数百〜千文字制限と違って、CLAUDE.md は実質無制限です。Claude Code 公式は CLAUDE.md を「常時メモリー」と表現していて、要は会話のたびに毎回先頭にコピペされるシステムプロンプトだと思えば正確です。だから「言ったはず」が起きない。

CLAUDE.md は 日本語で書いて問題なく効きます。だからこの記事では英語原文は載せず、そのまま CLAUDE.md にコピペできる日本語の指示文 と、「なぜ効くのか」「どこで使うと刺さるのか」の解説、各 Part 末尾の 中級・上級者向けコラム の3層でまとめました。

長いので、最初に「最低限これだけ入れときゃ8割は変わる3項目」だけ抜粋しておきます。

関連記事：【vibe coding入門】コードが書けない人がClaudeでアプリを作る6ステップ。週末で内製化できる時代になった

先出し：最低限これだけ3項目スターター

ここだけコピペしても、明日からの Claude との会話が変わります。理由は本文で説明します。

# 私の CLAUDE.md（スターター版）

## 1. 話し方
- "Great question!" "もちろん!" などの前置きは禁止。最初の1文から答えを書く
- 結論を先に出す。理由はその後

## 2. 私について
- 名前: ◯◯
- 仕事: ◯◯（具体的に）
- 得意: ◯◯
- 苦手・補足が必要な領域: ◯◯
- 文体の好み: カジュアル / 「ですます」/ 一人称は「僕」

## 3. 大きな変更の前に確認する
- 私が書いた文章を「改善」しようとする前に、何を変えるか先に説明して、確認を取ること
- 私が頼んでいない箇所は、たとえ改善できると思っても触らない
- 「もっと良くなると思ったから」は変更の許可ではない

これだけで、Claude の応答の8割が改善します。あとは下の21項目から、自分の刺さるところだけ追加していけば OK。

2分で CLAUDE.md をセットアップする

1. 仕事で使うフォルダ（書類フォルダでもデスクトップの専用フォルダでも OK）を1個決める

2. その中に 新規テキストファイル を作る

3. ファイル名を CLAUDE.md（大文字、拡張子は .md）にする

4. テキストエディタ（メモ帳・TextEdit・VS Code・なんでも）で開いて、指示を書く

5. 保存して閉じる

それだけ。Claude Code を使っている人は、そのフォルダで claude コマンドを叩いた瞬間に自動で読み込まれます。Claude Desktop / Cowork で使っている人は、フォルダを「接続」するときに同じ仕組みで読み込まれます。

ちなみに Claude.ai（Web版）には CLAUDE.md という名前のファイル機能はないですが、代わりに「Project Instructions」と「Profile Preferences」がほぼ同じ役割を果たします。書ける内容も中身もこの記事と同じ考え方で OK。Cowork で「フォルダを選択」した場合は、Claude Code と同じくフォルダ直下の CLAUDE.md が読まれます。

Part 1. Claude の話し方を直す（4項目）

ここから本編。21項目を5パートに分けます。Part 1 は「Claude の話し方」、つまり 応答の表面 をコントロールする4項目です。これが一番ストレスを減らしてくれる部分なので、まずここから入れるのがおすすめ。

項目1. 前置きの「ナイス質問！」を永久に殺す

【あるある】 質問するたびに「素晴らしい質問ですね！」「もちろんです！」「お任せください！」から始まる。中身ゼロの社交辞令を毎回読まされて、本題に入るまでに数秒の無駄が積み重なる。

【CLAUDE.md にこう書く】

【効きどころ】 1日に Claude と50往復するなら、削減できる時間は地味に効きます。それ以上に「中身に集中している応答」が返ってくる体感が変わる。Claude は親切に振る舞うよう訓練されているので、これは明示的にオフにする必要があります。

項目2. 手を動かす前に選択肢を見せる

【あるある】 「この段落を直して」と頼んだら、Claude が勝手にトーンを大幅変更。「リライトして」と言ったら、構成まで根本から組み直された。あなたが頼んでいないところまで変わってしまう。

【CLAUDE.md にこう書く】

【効きどころ】 これを入れると、Claude は「A: 全面リライト / B: 部分修正 / C: 構成だけ変える」のように選択肢を出してくれます。後戻りの工数が大幅に減る。

項目3. 分からないときは正直に分からないと言う

【あるある】 日付・統計・引用・固有名詞などを、それっぽい顔をして堂々と書いてくる。後で確認したら、まるごとデタラメだった。

【CLAUDE.md にこう書く】

【効きどころ】 これは効果絶大で、入れた瞬間に「この数字は2024年時点の推定で、最新情報は要確認です」のような注釈が自然につくようになる。リサーチ用途なら必須。

項目4. 長さは中身に合わせる

【あるある】 「OK？」と聞いただけで4段落返ってくる。逆に複雑な要件を投げたら骨組みだけのスカスカな回答が来る。

【CLAUDE.md にこう書く】

【効きどころ】 「項目1」と組み合わせると効果倍増。冒頭の前置き＋末尾のまとめ繰り返しが両方消えるので、本文だけが残ります。

Part 2. Claude の暴走を止める（4項目）

Claude は親切すぎて、頼んでいないことまで「より良くしてあげよう」とやってしまう傾向があります。この Part はそれを止める安全装置です。

項目5. 大きな変更の前に確認する

【あるある】 「この段落を直して」と頼んだら、文章全体がリライトされていた。「短くして」と言ったら、必要だった部分まで削られた。

【CLAUDE.md にこう書く】

【効きどころ】 スターター3項目に入れた理由は、これ一発で「やりすぎ問題」が9割解決するから。文章編集を任せる場面では特に効きます。

項目6. 頼まれたことだけやる

【あるある】 1個直してと頼んだら、ついでに5箇所が「改善」されていた。元のままで良かった文章まで書き換えられて、差分を探すだけで時間が溶ける。

【CLAUDE.md にこう書く】

【効きどころ】 項目5とセットで運用するのが鉄板。これがないと、差分レビューに時間を吸われ続けます。

項目7. 変えた箇所を報告させる

【あるある】 作業が終わった後、何が変わったのか分からない。全文読み比べるしかなく、結局やった意味があったのか判断できない。

【CLAUDE.md にこう書く】

【効きどころ】 これ入れると、レビューの時間が3分の1くらいになります。Claude の作業ログを Claude 自身に書かせる、というシンプルだけど強い設計。

項目8. 勝手にアクションを起こさせない

【あるある】 カレンダーやメールに繋いだ Claude が「言ってましたよね？」と勝手にスケジュールを入れたり、下書きを送信したりする。AI が外部ツールと繋がる時代に、この種の「やりすぎ事故」は増えています。

【CLAUDE.md にこう書く】

【効きどころ】 Cowork や MCP（外部ツール連携の規格）で各種サービスに繋いでいる人は、絶対に入れた方がいい1項目。

Part 3. あなたの文脈を教え込む（3項目）

Part 1・2 は「話し方」と「振る舞い」のチューニング。ここから先は あなた自身の情報 を Claude に渡す Part です。これがあるかないかで、出力が一気に「自分専用」になります。

項目9. あなたが何者かを書く

【あるある】 Claude は初対面なので、毎回「専門用語の説明レベル」を間違えてくる。エキスパートなのに小学生向けに説明されたり、初心者なのにフルスタック前提で語られたり。

【CLAUDE.md にこう書く】

【効きどころ】 僕は AI顧問・X運用代行をやっているので、ここに「マーケティング・LLM・SaaS 業界の用語は説明不要、税務・法律は補足必要」と書いています。これだけで応答の前提が一気に揃う。

項目10. 今やっている仕事の文脈を書く

【あるある】 セッションごとに「いまこのプロジェクトでは…」を説明するのが面倒。毎回ゼロから状況説明。

【CLAUDE.md にこう書く】

【効きどころ】 僕の場合は「note記事ドラフト時：読者は非エンジニア起業家、トーンはカジュアル、専門用語は初出時に注釈」と書いている。これを書くと、毎セッション「想定読者は誰でしたっけ」を聞かれない。

項目11. 文体・口調を固定する

【あるある】 Claude が書いたものを毎回「自分の文体」に直してから公開している。直す工数の方が、ゼロから書くのと変わらない。

【CLAUDE.md にこう書く】

【効きどころ】 ここに僕は「一人称は『僕』」「AI がよく使う決まり文句は禁止語リストとして列挙」「ある種の強い副詞は1記事につき1回まで」「em ダッシュは原則使わない」など、自分のブランドボイス・ルールを全部書いています。これがあるとリライト工数が劇的に減る。

ちなみに僕の CLAUDE.md は AI顧問業務用と X運用代行業務用で2つに分けています。それぞれ違うフォルダに置いていて、Claude Code でフォルダを開いた瞬間に該当の指示が読み込まれる。

AI顧問側には「提案書を書く前に顧問先の業種・規模・課題を必ず確認」と書いてあるし、X運用代行側には「投稿前にクライアントの過去30投稿のトーンに合わせる」「文末絵文字なし」「自社宣伝は3投稿に1回まで」と書いてあります。

複数クライアントの文体を切り替える必要があるので、フォルダ別 CLAUDE.md は本当に効きます。副次効果として、自分が何を大事にしているかが半年単位で残っていく。これは予想してなかった副産物でした。

Part 4. 記憶と継続性をつくる（4項目）

Claude はセッションをまたいで会話を覚えていません。でも ファイルは残ります。これを使って疑似的な記憶を作るのがこの Part のテーマ。

項目12. メモリーファイルを作らせる

【あるある】 「前にこう決めたよね」が通用しない。意思決定の履歴が全部、人間側の頭の中にしか残らない。

【CLAUDE.md にこう書く】

【効きどころ】 これ入れると Claude が「セッション開始時に MEMORY.md を読みました」と最初に報告してくれます。意思決定の継続性が一気に取れる。

ちなみに MEMORY.md も ERRORS.md も、Claude が公式に自動読み込みするファイル名 ではありません。これらは「CLAUDE.md の中で『セッション開始時に MEMORY.md を読め』と書いているから読みに行く」という二段構えの仕組み。CLAUDE.md 側の指示が曖昧だと「読み忘れ」が起きるので、文言は強めに書くのがおすすめ。さらに踏み込んだ @import 構文や肥大化対策は、巻末の「上級者向け補足」にまとめました。

項目13. セッション終了時にまとめを書かせる

【あるある】 2日空けて Claude に戻ってきたとき、「どこまで進んだんだっけ」を思い出すのに15分かかる。

【CLAUDE.md にこう書く】

【効きどころ】 これと項目12をセットで使うと、Claude が「自動でログを残し、次回開始時に自分で読み返す」というループが完成します。

項目14. 失敗ログを残させる

【あるある】 3週間前に試行錯誤して辿り着いた解決策。今日また似た問題に直面したら、Claude はまた同じ失敗から再挑戦してくる。

【CLAUDE.md にこう書く】

【効きどころ】 このファイルが半年分溜まると、Claude は あなたの過去の躓きを学習している 状態になります。実質的な「個人専用の AI」に近づく。

項目15. 永遠に変わらない事実リストを作る

【あるある】 「あ、それは契約上できないんですよ」「うちの会社では◯◯は禁止です」を、毎セッション説明している。

【CLAUDE.md にこう書く】

【効きどころ】 僕は「個人事業主として◯◯のフレームワークでクライアント請求書を発行している」「税理士は◯◯先生」「freee 連携の API キーは環境変数で管理」など、業務上の動かない前提をここに書いています。

Part 5. Claude Code を使う人へ（6項目）

項目16. 頼まれた範囲だけ触る（コード版）

【あるある】 「このバグ直して」と頼んだら、Claude がついでに3ファイルをリファクタ（コードの整理・書き直し）して、変数名を変えて、import 文を並び替えていた。動いていたコードまで壊れる事故が起きる。

【CLAUDE.md にこう書く】

項目17. 後戻りできない操作の前に確認する

【あるある】 Claude Code がうっかりファイル削除・DB レコード削除・コード上書きを実行。Undo はない。

【CLAUDE.md にこう書く】

項目18. 絶対に許可なしでやらせないこと（ハードストップ）

【あるある】 本番デプロイ。本番 DB のマイグレーション（構造変更）。外部 API の呼び出し（メール送信、決済、Slack 投稿）。これらが「気軽に」実行される世界線は怖い。

【CLAUDE.md にこう書く】

【補足】 本物の防御は、CLAUDE.md だけでなく Claude Code の settings.json の permissions セクションで deny リストを書くことです。CLAUDE.md は「指示」、settings.json は「実行可否の最終ゲート」。両方使う。

項目19. 技術スタックを固定する

【あるある】 Claude が「人気だから」という理由で、あなたが使っていないフレームワーク・ライブラリを提案してくる。導入して気づくと、社内の誰も知らない技術スタックになっている。

【CLAUDE.md にこう書く】

項目20. 変えたファイルを報告させる（コード版）

【あるある】 作業終了後、git diff を見るまで何が変わったか分からない。

【CLAUDE.md にこう書く】

項目21. Karpathy の4ルール（深掘りは次章で）

【元記事の主張】 Andrej Karpathy（元 Tesla AI 部門ディレクター、OpenAI 創業メンバー）が、Claude Code がコーディングタスクで失敗する4つの典型的な振る舞いを特定した。ある開発者がそれを4つの指示文に蒸留した CLAUDE.md が GitHub Trending 1位になり、コーディング精度が65%から94%に向上した。

4ルール：

1. Ask, don't assume：不明点があれば、1行書く前に質問する。暗黙の想定で進めない

2. Simplest solution first：動く最もシンプルな解を最初に実装する。依頼されていない抽象化を足さない

3. Don't touch unrelated code：現タスクに直接関係しないファイルは触らない、絶対に

4. Flag uncertainty explicitly：確信が持てないなら、進める前に明示する。不確かさを隠した自信は、足りない情報を認めるよりずっと害が大きい

【CLAUDE.md にこう書く】

【効きどころ】 4ルール全部、Part 5 の他の項目と内容が重なります。重要度の証左でもあるし、「これだけ書けば Part 5 の他は省略可能」とも言える。

Karpathy 4ルールを一次裏取りした結果

ここはこの記事で 僕が一番丁寧に書いたパート です。元記事 Mayank Agarwal の投稿は、Karpathy の4ルールを「GitHub Trending 1位、精度65%→94%」と紹介していて、これがバズの最大の燃料になりました。

僕自身、ここをそのまま日本語訳で流すのが怖くて、WebSearch で一次ソースを当たりました。結果は以下です。

確認できた事実

• Karpathy 本人の発信は2026年1月26日の X 投稿（status/2015883857489522876）に存在する。タイトルは「A few random notes from claude coding…」。ただし4ルールを「本人がリストとして宣言した」わけではなく、観察として書いた内容を Forrest Chang という開発者 が4項目に蒸留したのが実態

• GitHub リポジトリは実在する：forrestchang/andrej-karpathy-skills（および mirror multica-ai/andrej-karpathy-skills）。2026年1月27日作成、スター9万〜13万超、GitHub Trending 1位は事実

• 「65% → 94%」の出典は Pebblous というベンチマーク に紐づくが、これは「4ルールへの 遵守率」の改善であって、 コーディング精度の改善ではない とする批判記事が複数ある

• さらに同ベンチマークの内訳には「Fundraising Skill 70→94%、Sales Skill 65→91%」のような コーディングと無関係な Skill 評価値が混在 している

結論（中級・上級者向け）

元記事 Mayank Agarwal の主張は 半分は本当、半分は誇張または誤読 です。

• リポジトリの実在とバイラル化：事実

• Karpathy 本人が「4ルールを特定した」：表現が強すぎる（観察を述べただけ）

• 「コーディング精度65→94%」：ベンチマーク数値の文脈が違う（遵守率の話 + Skill 評価値の混在）

ただし、これは Mayank Agarwal の文章が低品質という話ではなく、英語圏のバイラル投稿でよくある「数字の文脈を圧縮して強い主張にする」パターン だと思います。日本のメディアでもよく見る現象。

4ルール自体は、Claude Code を業務で使っている僕の体感としても 本当に効きます。出典の誇張があるからといって価値が落ちるルールではない。むしろ、出典を知った上で「ルール単体としての有用性」と「数字の盛り」を分けて評価できる方が、AI 関連情報の付き合い方として健全だと思います。

引用元：

• forrestchang/andrej-karpathy-skills (GitHub)

• multica-ai/andrej-karpathy-skills (GitHub mirror)

• Karpathy X post (2026-01-26): x.com/karpathy/status/2015883857489522876

• byteiota.com の「94% accuracy claim」解説

• pasqualepillitteri.it の Pebblous ベンチマーク言及

コピペ用：フル版日本語テンプレート（保存版）

ここまでの21項目を、そのまま自分の CLAUDE.md にコピペできる日本語版にまとめました。<> の中身を自分の情報に置き換えるだけで使えます。

# CLAUDE.md

このファイルは、私とのすべてのセッション開始時に自動で読み込まれます。
ここに書かれた指示は、すべての応答・タスクに適用してください。

## Part 1. 話し方

1. 「素晴らしい質問」「もちろん」「お任せください」などの前置きは禁止。最初の1文から答えに入る
2. 大きなタスクの前に、必ず2〜3通りのアプローチ案を見せて、私の選択を待つ
3. 事実・統計・日付・引用に自信がないときは、書く前に「自信がない」と明示する。推測でファクトを作らない
4. 応答の長さはタスクの複雑さに合わせる。直前の内容を繰り返すまとめや締め文で水増ししない

## Part 2. 暴走防止

5. 私が作ったコンテンツを大きく変える前に、何をどう変えるか先に説明し、確認を取る。「もっと良くなりそう」は許可ではない
6. 私が依頼した箇所だけ変更する。他に気になる点は最後に「指摘」のみ。明示依頼なしには触らない
7. 編集・執筆タスク完了時は必ず末尾に「変えた箇所／触っていない箇所／私の確認待ち項目」を短く報告する
8. 私の代わりにメッセージ送信・投稿・共有・スケジュール登録は、今このメッセージで明示的な「はい」がない限り絶対にしない

## Part 3. 私の文脈

9. 私について
   - 名前: <あなたの名前>
   - 役割: <仕事>
   - 得意分野: <説明不要な領域>
   - 学習中: <補足が必要な領域>
   - この前提に合わせて応答の深さを調整する。すでに知っていることを過剰に説明しない

10. 取り組み中の仕事
    - プロジェクト: <概要>
    - 目的: <ゴール>
    - 対象読者: <誰向け>
    - トーン: <カジュアル/フォーマル>
    - 避けたいこと: <NG>
    - 文脈と合わない依頼があれば、作業前に指摘する

11. 私の文体
    - 一人称: <例：僕>
    - 文の長さ: <短め/長め>
    - 好きな表現: <あれば>
    - 使わない表現: <NG ワード>
    - フォーマット: <箇条書き多用/段落中心など>
    - 私の代わりに書くときは必ずこの文体に揃える。AI のデフォルト文体に戻らない

## Part 4. 記憶と継続

12. `MEMORY.md` を維持する。大きな意思決定があったら「決めたこと／理由／採用しなかった代替案」を1エントリ追記する。各セッション開始時、何かを始める前に MEMORY.md を読む

13. 私が「セッション終了」「ここで一旦止めよう」と言ったら、MEMORY.md にセッション要約を追記する：取り組んだこと／完了したこと／進行中のもの／決定事項／次回拾うべき項目

14. `ERRORS.md` を維持する。あるアプローチが2回以上の試行を要したら「効かなかった方法／効いた方法／次回覚えておくべきこと」を記録する。類似タスクの提案前に ERRORS.md をチェックする

15. 常に真である事実（例外なく適用）
    - <永続的な前提を列挙>
    - これと矛盾する依頼があれば、作業前に指摘する

## Part 5. コードを書くとき（Claude Code 用）

16. 現在のタスクに直接関係するファイル・関数・行だけを変更する。リファクタ・リネーム・「改善」は明示依頼があるときだけ

17. ファイル削除・既存コード上書き・DB レコード削除など、簡単に取り消せない変更前に、影響範囲を列挙して明示確認を取る

18. 以下は例外なく明示確認なしには実行しない
    - 任意の環境へのデプロイ
    - DB マイグレーション
    - メール送信・外部 API 呼び出し
    - 取り返しのつかない外部副作用を持つコマンド

19. 技術スタック（代案は依頼されない限り提示しない）
    - 言語: <例: Node.js>
    - フレームワーク: <例: Next.js>
    - パッケージマネージャ: <例: pnpm>
    - DB: <例: PostgreSQL>
    - テスト: <例: Vitest>
    - Linter: <例: ESLint>

20. コーディングタスク完了時は必ず末尾に：変更ファイル一覧／ファイルごと1行の変更内容／意図的に触っていないファイル／フォローアップ項目

21. Karpathy 4ルール（常時適用）
    1. 不明点があれば、1行書く前に質問する。暗黙の想定で進めない
    2. 動く最もシンプルな解を最初に実装する。依頼されていない抽象化を足さない
    3. 現タスクに直接関係しないファイルは触らない
    4. 確信が持てないなら、進める前に明示する

このまま CLAUDE.md という名前で保存して、仕事用フォルダのルートに置けば、Claude Code / Cowork で開いた瞬間に自動で読まれます。Claude.ai を使っている方は、この内容を Project Instructions に貼ってください。

上級者向け補足：CLAUDE.md の限界とアンチパターン

ここまで読んでくれた方への、最後のおまけ。CLAUDE.md は便利ですが、万能ではありません。実運用で踏みやすい罠を整理しておきます。

1. 長くしすぎるとトークンを食う

CLAUDE.md は 毎セッション、すべての会話で先頭にコピペされる ものだと考えてください。10,000字書いたら、その10,000字分のトークンが会話のたびに消費される。Claude Code の利用上限に響くだけでなく、コンテキストウィンドウ（一度に処理できる情報量）も圧迫します。

公式は具体的なバイト上限を明示していませんが、肥大化したら Skills 化を推奨 すると明言しています（出典: claude.com/blog/skills-explained）。つまり「すべてに毎回効かせたい指示」は CLAUDE.md、「特定タスクのときだけ呼び出したい指示」は Skills に分ける。

2. Skills / Sub-agents との使い分け

Claude Code には CLAUDE.md と並んで Skills（.claude/skills/）と Sub-agents（.claude/agents/）という機能があります。3つの違いは：

機能タイミング配置向いている内容CLAUDE.md常時プロジェクト/ユーザー/Enterprise文体・基本ルール・禁止事項Skillson-demand.claude/skills/PDF生成・議事録要約・特定業務フローSub-agents独立コンテキスト.claude/agents/並列リサーチ・大型タスク・別文脈の処理

「すべてを CLAUDE.md に詰め込む」は初心者あるある。「PDF を作るときだけ使う指示」は Skill、「リサーチを並列で投げたい」は Sub-agent に分ける。

実運用上の落とし穴をひとつ。Sub-agents には Explore / Plan などのビルトイン sub-agent は CLAUDE.md を読み込まない（コンテキストを軽くするため）という仕様があります。なので CLAUDE.md にだけ書いた指示が、Plan モードでは効かないことがある。どうしても全 agent に効かせたい指示は、各 agent の .md ファイル側にも書くか、メインの Claude が sub-agent に投げる prompt 自体に重要な指示を埋め込むのが回避策です（出典: code.claude.com/docs/en/sub-agents）。

3. チーム運用時の Git 管理ポリシー

CLAUDE.md は Git に コミットする のがデフォルトです（プロジェクト全員に効かせたいなら）。ただし、個人専用の設定（名前・MEMORY.md パスなど）は ~/.claude/CLAUDE.md（ユーザー側）に逃がす。

チームで共有する CLAUDE.md には：

• 技術スタックの固定

• 禁止コマンド一覧

• コミットメッセージのルール

• レビュー観点

個人の ~/.claude/CLAUDE.md には：

• 文体・口調の好み

• メモリーファイル運用

• 永続的な事実（自分の情報）

を書き分ける。これでチームのルールと個人の好みが衝突しなくなります。

4. ファイル階層と「サブディレクトリは遅延ロード」

Claude Code 公式ドキュメントに明記されている挙動です。CLAUDE.md は4つの階層で読まれる：

• Enterprise Policy（最優先・組織配布用）

• User: ~/.claude/CLAUDE.md（全プロジェクト共通）

• Project: ./CLAUDE.md（そのプロジェクトだけ）

• Subdirectory: ./<dir>/CLAUDE.md（そのサブディレクトリに入ったときだけ読まれる）

最後の サブディレクトリの CLAUDE.md は on-demand 読み込み（そのフォルダのファイルに触れた瞬間にロード）で、起動時に一括では読まれません。これを知らずに「サブの CLAUDE.md が効いてない」と勘違いするケースは多い。実際は「まだ Claude がそのフォルダに到達していないだけ」のことが多いです（出典: docs.claude.com/en/docs/claude-code/memory）。

5. @import 構文と MEMORY.md の二段構え

本文の項目12でも触れた話の続き。MEMORY.md / ERRORS.md は CLAUDE.md 内で「セッション開始時に読め」と書いてはじめて読まれる二段構えですが、もう一段確実にしたいなら @import 構文 を使う手があります。

CLAUDE.md 内に @MEMORY.md や @path/to/file.md と書くと、そのファイルが CLAUDE.md の一部として展開 されてロードされます。Claude Code 公式は5階層まで再帰展開してくれる。

ただし @import で取り込むと そのファイルの中身が毎セッション常時コンテキスト消費 するので、MEMORY.md が肥大化すると無視できないトークンコストになります。長くなってきたら「直近◯エントリだけ残し、古いものは別ファイル MEMORY-ARCHIVE.md に移す」のような運用ルールも CLAUDE.md に書いておくと良い。

6. CLAUDE.md は「指示」、settings.json は「権限」

最後にもう1つ。CLAUDE.md は 行動指針 であって、実行制限 ではありません。「DB を削除しないで」と CLAUDE.md に書いても、それは「お願い」レベルの安全装置です。

これは LLM の sycophancy（おべっか問題） と関係しています。Claude は「親切なアシスタント」として強化学習されているので、「変えるな」と書いてあっても文脈のニュアンスで揺れる。完全には消えません。

なので実運用では確認プロンプトを 二重化 するのが有効：

• CLAUDE.md レベル：「大きな変更前に止まる」（項目5）

• 会話レベル：プロンプト末尾に毎回「変更点だけ列挙して。実行は次のメッセージで指示するまで待って」を添える

そして本物の安全装置は Claude Code の settings.json の permissions.deny リスト。たとえば：

{
  "permissions": {
    "deny": [
      "Bash(rm -rf*)",
      "Bash(*--force*)",
      "Bash(psql*DROP*)"
    ]
  }
}

これは Claude が「実行しようとしても止まる」最終ゲート。CLAUDE.md と settings.json は 役割が違う ので、両方併用するのが上級者の運用です（このテーマは別記事で深掘りしているので、Claude Code セキュリティ系の note も合わせてどうぞ）。

まとめ：3項目から始めて、3ヶ月で育てる

ここまで読んでくれてありがとうございます。長かったので、最後にエッセンスだけ。

• CLAUDE.md は開発者だけのものじゃない。Claude を仕事で本気で使う全員に効く

• 21項目を全部書く必要はない。「最低限3項目スターター」から始めて、刺さるものだけ追加

• 中級者は「なぜ効くのか」、上級者は「公式仕様と限界」を押さえると運用が安定する

• Karpathy 4ルールの数字は 半分誇張 だけど、ルール自体は本物

• 長くなりすぎたら Skills や Sub-agents への分割を検討する

僕がやってよかった運用は、3ヶ月に1回、自分の CLAUDE.md を見直す こと。半年も使っていると、自分が何を大事にしているか・どこでストレスを感じていたかが、CLAUDE.md の歴史として読み取れます。これは予想していなかった副産物でした。

今日この瞬間にやることは1つだけ：

1. 仕事用フォルダを開く

2. CLAUDE.md という名前のファイルを作る

3. 「最低限3項目スターター」をコピペする

4. 保存する

これで明日からの Claude との会話が変わります。

参考

• 参考記事：Mayank Agarwal (@TheAIWorld22) のX投稿（2026年5月9日、304.5万view） https://x.com/TheAIWorld22/status/2053023798170198453

• Karpathy 原投稿（2026年1月26日） https://x.com/karpathy/status/2015883857489522876

• 4ルール蒸留リポジトリ：forrestchang/andrej-karpathy-skills (GitHub)

• Claude Code 公式 Memory ドキュメント： https://docs.claude.com/en/docs/claude-code/memory

• Claude Code Sub-agents 公式ドキュメント： https://code.claude.com/docs/en/sub-agents

• Anthropic 公式：Skills explained： https://claude.com/blog/skills-explained

CLAUDE.md は1個のファイルで世界が変わるツールです。今日作ってください。

特典

noteやXでは発信できない情報をLINEのオプチャで発信しています。

https://t.co/90omRA4UQ7

よければこちらからご参加ください。