CLAUDE.md の書き方｜Claude Code を"自分仕様"に育てる設計

この記事の要点（先に結論）

CLAUDE.md は、Claude Code が毎回自動で読み込む「判断基準と前提」の設定ファイル。自然言語で書ける
これを整えると、あなたの仕事・流儀・環境を最初から分かっているエージェントが手に入る（毎回ゼロから説明しなくてよくなる）
コツは自分で1から手書きしないこと。「やりたいこと」を話して、Claude Code 自身に作ってもらうのが速い
毎回読む＝コンテキストウィンドウを消費する。だから盛りすぎは逆効果。核は軽く、詳細は @import で分けて「必要なときだけ読む」状態にする
最重要は、セッション開始時にどこまで読み込ませているかを自分が把握していること

ひとことで言うと、この記事のゴールは「あなたの前提を分かっているエージェントを、設定ファイル1枚から育てられるようになる」こと。これは Claude Code を”自分仕様”に育てる話です。

この記事で出てくる言葉（先に一括で）

先に、後で出てくる言葉をここでまとめて説明しておきます。ここが分かれば本文はスッと読めます。

CLAUDE.md … Claude Code が起動時に自動で読む Markdown ファイル。ルールや前提を書いておく場所
Markdown（.md） … テキストに見出しや箇条書きの印を付けただけの軽い書式。特別なスキルは不要で、書くのは基本 Claude に任せられる
リポジトリ（リポ） … プロジェクトのファイルをまとめたフォルダ、くらいの理解でOK
git … ファイルの変更履歴を記録して、前の状態に戻したり別PCと共有したりする仕組み
GitHub … git のファイルをネット上に置いて、別PCや他のメンバーと共有できるサービス
セッション … Claude Code を起動してから終えるまでの、ひとまとまりの会話
コンテキストウィンドウ … AI が一度に扱える作業範囲。たくさん読み込むほど埋まっていく
トークン … AI が読み書きする文章を細かく区切った処理の単位。読み込ませた文章にも、AI が出力する文章にも消費される。多いほど処理が重く、コストもかかる
@import … CLAUDE.md から別ファイルを参照する書き方。詳細を切り出して分割するのに使う

このあたりの言葉がそもそもピンとこない場合は、Claude Code をどんな環境で動かすかの前提記事（準備中）を先に読むと入りやすいです。

CLAUDE.md とは何か？

CLAUDE.md は、Claude Code がセッションを始めるときに自動で読み込む Markdown ファイルです。プロジェクトのフォルダに置いておくと、毎回の会話の前提として勝手に効いてくれます。

役割をひとことで言うと、「毎回口で言っていた前提を、書いて一度きりにする」もの。人間の新メンバーに渡す業務マニュアルと、チームの暗黙ルールを足して言語化したもの、と考えるとイメージしやすいです。

大事なのは、コードではなく自然言語で書くという点です。「日本語で、結論から答えて」「この言葉が来たらこう動いて」と、普通の言葉でルールを置いていける。だから非エンジニアでもエージェントを”躾ける”ことができます。

CLAUDE.md を整えると、何が手に入る？

答えを先に言うと、あなたの前提を最初から分かっているエージェントが手に入ります。

具体的なシーンで考えると分かりやすいです。CLAUDE.md に自分の仕事の前提・資料の置き場所・よく扱うプロジェクトの情報を書いておくと、「あの件、進捗どうなってる？」と聞くだけで話が通じます。Claude Code はどの件か・どこを見ればいいかを最初から知っているからです。

ChatGPT や Gemini（素の状態の Claude Code も同じ）だと、「あの件、進捗どうなってる？」では「どの件でしょう？」から始まります。背景を一から説明し直すことになる。この差が、毎日の積み重ねでじわじわ効いてきます。

素の Claude Code は、優秀だけどあなたの文脈をまだ何も知らない新人です。だから毎回ゼロから「私はこういう仕事をしていて、こう答えてほしくて、、」と説明する羽目になります。CLAUDE.md は、その説明を一度書けば忘れない装置。効果は素直に2つです。

同じ指示を毎回くり返さなくて済む
出力のブレが減る（毎回違うトーン・違う形式で返ってくるのが止まる）

素のまま使い続けるのと、育てて使うのとでは、同じツールとは思えないくらい差が出ます。

作り方のコツ — 自分で書かず、Claude Code に作ってもらう

ここがいちばん伝えたいところ。CLAUDE.md は、自分で1から手書きするものだと思わなくて大丈夫です。いちばんのおすすめは、Claude Code 自身に作ってもらうこと。

やり方は、自分の言葉で相談するだけです。

普段やっている仕事と、効率化・自動化したいことを話す — 「こういう作業を毎週やってて、ここが面倒で、、」を素直に伝える
適切なドキュメントに分割してもらう — その作業をどう整理すれば AI が動きやすいか、ファイルの分け方ごと提案してもらう
「それを実現する CLAUDE.md とリポ構造を作って」とお願いする — 設定ファイルもフォルダ構成も、まとめて作ってもらう

これだと「何を書けばいいか分からない」で固まらずに済みます。自分は”やりたいこと”だけ分かっていればよくて、それを形にするのは Claude Code の仕事、、という分担です。手で書ける人も、まず叩き台を作ってもらってから直すほうが速いです。

出来上がりを見る目 — 4つの型

作ってもらったものが筋のいい CLAUDE.md か、見る目があると安心です。だいたいこの4つが入っていれば良い、というチェックの観点として持っておいてください（自分で全部書くための型、ではありません）。

役割・ペルソナ — エージェントを「誰」として振る舞わせるか
守ってほしいルール — 口調、禁止事項、出力の形式
前提・環境 — よく使うフォルダの場所、使うツール
トリガーワード — 「この言葉が来たら、この動きをして」の対応表

実例 — 僕が使っている CLAUDE.md（抜粋・一部伏せています）

参考に、僕自身が仕事で使っている CLAUDE.md を、会社が特定されない形に直して抜粋します。これくらいの粒度から始めれば十分です。

# CLAUDE.md

## 役割
toC向けサービスを運営する会社で、データ分析チームのマネージャーを支える実行パートナー。

## 回答ルール
- 日本語で応答する
- トーン：丁寧なカジュアル
- IMPORTANT: 前置きは不要。結論から述べる
- IMPORTANT: 技術的な提案はコードが書けない前提で説明する（SQL はOK）

## ファイル操作ルール
- ファイル名は `{YYYY-MM-DD}_{内容}.md`。区切りは `_`、スペース禁止
- 新しいファイルを作る前に、既存の似たファイルを確認する

## トリガーワード（この言葉が来たらこう動く）
- 「日報」→ その日の作業ログを集計して下書きを作る
- 「議事録」＋文字起こし → 議事録フォーマットに整える
- 「残タスク」→ 未完了タスクを一覧化して次アクションを提案

## 判断基準・ナレッジ（詳細は必要なときだけ読む）
@decisions/index.md
@wiki/index.md

見てほしいのは2点。ひとつは IMPORTANT: という強調。本当に守ってほしいルールは目立たせると効きが変わります。AI は強調された指示に反応しやすいので、最重要ルールが1〜2行、強めに書かれているかが効き目を分けます。なければ「ここを強調して」とお願いすればいい。

もうひとつは、いちばん下の @import（@decisions/index.md の行）。ここが後半の肝になるので、いったん頭の隅に置いておいてください。

育てかたも同じで、完璧を狙わなくて大丈夫。「あ、また同じこと説明してるな」と気づいたら、その1行を足してもらう。使いながら少しずつで十分です。

いちばん大事な感覚 — 「今どこまで読み込ませているか」

ここが、この記事でいちばん持ち帰ってほしい感覚です。

CLAUDE.md に「いろいろ書いておくと便利」と分かると、人はどんどん詰め込みます。気持ちは分かります。でも、CLAUDE.md はセッションのたびに毎回・全文が読み込まれます。読ませた分だけコンテキストウィンドウが埋まっていく。トークンも消費する。

だから素直にこうなります。書けば書くほどタダで賢くなる、わけではない。ルールを盛りすぎて1ファイルが分厚くなると、本来コードや会話に使えるはずの”頭の容量”を、設定の読み込みが食いつぶします。応答も少し重くなるし、コストも乗る。

ここで効くのが、さっきチラッと出た @import です。やることはシンプルで、@別ファイル.md という形で参照を張り、いつも読ませる本体は軽い「索引」だけにして、詳細は別ファイルに切り出す。

## 判断基準
@decisions/index.md

## ナレッジ
@wiki/index.md

ポイントは、参照を張った時点で全文が読み込まれるわけではないこと。本体には「どんな話題のときに、どの詳細ファイルを読むか」という索引だけ置いておく。すると Claude Code は、その話題になったときに初めて該当ファイルを読みに行きます。

セッション開始時に読み込むのは、軽い本体（＋索引）だけ
分厚い詳細は、必要になったときだけ読み込まれる

この状態を作れると、知識の総量は確保したまま、開始時のコンテキストウィンドウ消費を抑えられます。逆に言うと、「今、開始時点で何を読み込ませているか」を自分が把握していないと、気づかないうちに毎回ぶんぶん重くしてしまう。詰め込みがちな人ほど、ここを意識してほしいです。

@import で指したファイルのパスが間違っていると、当然そのルールは読まれません。効いてないな？と思ったら、まずパスとファイル名を疑ってください。

メモリ機能との使い分け

Claude Code には、その場で「これ覚えて」とサッと足したり、会話から拾って残したりするメモリの仕組みもあります。CLAUDE.md との線引きは、こう考えるとシンプルです。

CLAUDE.md = 最初から効いてほしい、設計した恒久ルール（＝正本）
メモリ = 作業中に気づいた一時的な事実やメモ（＝下書き）

メモリで溜めたものを見直して、定着させたいものを CLAUDE.md に構造化して昇格させる。この「下書き → 正本」の流れができると、ナレッジが腐りにくくなります。

ハマりポイント

最後に、自分がやらかした”あるある”を3つ。

継ぎ足しで肥大化する。 気づいたルールを末尾に足し続けた結果、1ファイルが膨らんで、似たようなルールが2つ並んでいたことがありました。足すより、ときどき整理して「正本は1箇所」に寄せるほうが効きます。
更新されないまま腐る。 書いた当初のルールと、実際の作業のやり方がズレていく。特に新しいプロジェクトを扱い始めたとき、その存在や資料の場所が CLAUDE.md に伝わっていないと、「あの件、進捗どうなってる？」と聞いても通じない。ルールが古くないかだけでなく、今扱っているプロジェクトの参照先・参照情報が合っているかも定期的に確認する習慣を持つと、ズレが溜まりません。
書きすぎて、逆に効かない。 長文のルールは埋もれます。1ルール1行、強調は本当に効かせたい場所だけ。盛るほど効く、ではないんですよね、、。

まとめ — まずは最小の一枚から

CLAUDE.md は、こう始めるのがいちばん挫折しません。

役割を1行
絶対に守ってほしいルールを数行（最重要は IMPORTANT: で強調）
よく使う前提をひとつ

この最小の3点から始めて、育ってきたら @import で本体を軽く保ちながら詳細を別ファイルに分けていけば大丈夫です。完璧な一枚を最初から狙わないこと。そして、開始時に何を読み込ませているかだけは、常に自分が握っておく。

次の一歩は、権限の設定と、コンテキストの管理です（このあたりも順次まとめていきます）。CLAUDE.md が効くようになるほど、「毎回読む＝コンテキストウィンドウを埋める」との付き合い方が問われてくるので、そことセットで覚えると強いです。

非エンジニアの僕でも、ここまでは設定だけでたどり着けました。AI に全部任せてみた体験記は、いま書き直しているので再公開したらここで案内します（準備中）。組織でのAI活用の成果を数字にする話は「AI活用の成果、数字で出して」と言われたらに書いています。