CLAUDE.mdは何行までが目安？200行以内でも起動時の文字数は増える

出典: 【保存版】Claude Codeで一番大事なのはCLAUDE.md。書いてないなら意味がない。置く場所・作り方・使い方を初心者〜中級者向けに徹底解説《自動メモリとの違い、環境構築講座 第2回》

CLAUDE.mdに書けば、必ずそのとおりに動く。そこまでの強制力はありません。私なら、仕事の前提を伝える物として使います。

チャエンさんの説明は、毎朝まっさらで出社してくる優秀な人。能力は高いのに、昨日伝えた仕事の決まりは覚えていない。だから、仕事の前に渡しておく引き継ぎメモが要る、という話です。

チャエンさん（動画の中で・自動字幕・4:06〜）

「毎朝記憶を失って、出社してくる優秀な人ですと。能力は最高。でも昨日教えたことを全く覚えていないと。」

この例えは、そのとおりだと思います。毎回説明する必要がある前提を、仕事を始める前に読める形で置く。そのための1枚。

ただし、動画のスライドには「命令ではなく『お願い』」とあります。Claude Codeは、書かれた内容を強制される設定ではなく、文脈として扱うんですね。

チャエンさん（動画の中で・自動字幕・4:34〜）

「ただ命令書ではないのであの強制力は少ないんですよね。」

「メールを送らない」と書くことと、送信できないようにすることには違いがあります。チャエンさんは、徹底して止めたいことを権限とフックの仕事にしています。

権限は、できる操作を制限する設定。フックは、操作の前後などに決めた処理を動かす仕組みです。禁止の文章を強くするだけで、操作の制限まで済んだことにはしない。

私の作業場所で最初から読む指示書は、46枚で合計79,346文字でした。

引き継ぎを伝えるにも、読む量がある。私なら「何を書くか」と一緒に、「仕事を始める時に何文字読むのか」を数えます。お願いを増やす前に、毎回渡している全体を確かめたい。

→ 禁止の点検

CLAUDE.mdから、実際に止めたい操作を1つ選ぶ。文章でお願いしている状態なのか、権限やフックで止める設定まであるのかを、Claude Codeに確認させます。

作業フォルダのCLAUDE.mdだけを数えても、最初に読む量は分かりません。私なら、開いた場所から上にある指示書までたどります。

チャエンさんが示した置き場は、広い範囲から狭い範囲へ4つ。会社が配布する管理ポリシー、自分の全案件用、プロジェクト用、その案件で自分だけが使うローカル用です。

管理ポリシーは組織全員に関係し、個人設定では消せない物。個人で始めるなら、まず自分の全案件用の ~/.claude/CLAUDE.md が入口になります。

チームで共有する決まりは ./CLAUDE.md に置き、変更履歴を共有するgitに入れる。自分だけの案件設定は ./CLAUDE.local.md に置き、共有対象から外す。誰に関係する決まりかで場所を選びます。

読み方にも決まりがある。上書きではなく足し算で、作業を始めた場所に近い物ほど後に読まれる。後の指示が強く効くという説明です。

チャエンさん（動画の中で・自動字幕・5:30〜）

「上書きはされずに足算[足し算]というイメージでございまして」

「で、打った場所に近いものほど後に読まれるっていうところでございます。」

下のフォルダへは、起動時に降りていきません。案件の下に置いた指示書を最初から読ませたいなら、その階層でClaude Codeを開く必要があります。

チャエンさん（動画の中で・自動字幕・8:34〜）

「基本あの下の回層[階層]は起動時には読まれませんっていうのがあるので下の回層[階層]のMD[CLAUDE.md]を読ましたかったら下の回層[階層]で開かないといけないというところでございます。」

動画の実例が、この違いをはっきり見せています。チャエンさんの動画フォルダにはCLAUDE.mdが1枚もない。それでも、起動時には28,902文字。

共通分は23,431文字で、内訳はCLAUDE.mdの5,252文字と、ルール9本の18,179文字です。そこへプロジェクト用2,330文字と、自動メモリ3,141文字が加わる。開いたフォルダが空でも、上から読む物があるんですね。

私の79,346文字も、内訳を見ると違いが分かります。CLAUDE.mdは3枚で22,208文字。その先頭の1枚が読み込む別ファイル3枚で5,860文字、ルール40本で51,278文字です。

全案件用の1枚は、チャエンさんが5,252文字、私は5,708文字。近い長さです。大きな差は、ルール9本と40本、そしてプロジェクト用2,330文字と16,176文字の所にあります。

チャエンさんの語りでは、100万トークンは日本語でおよそ80万〜90万文字。私の総量をその幅で割ると、全体の約8.8〜9.9%です。動画の28,902文字は、90万文字に対して約3.2%。

数える時は、Claude Codeに読み込み対象をファイル別に挙げさせ、Pythonのlenで文字数と行数を数えさせる。合計だけでなく内訳も出すのが、私なら選ぶ数え方です。

どこを短くするかは、内訳を見て決める。手元の1枚だけを見直すより、毎回読む量の大きい所が分かります。

→ 内訳を出す

「この作業場所で起動時に読む指示書をファイル別に挙げ、Pythonのlenで文字数と行数を数えて。自動メモリを含めるかも明記して」とClaude Codeに頼みます。

200行以内だから、長さの問題はない。その判断で見直しを終えないようにします。私の運用では、短いファイルが多数積み上がっていました。

チャエンさんの画面にある顧客フォルダのCLAUDE.mdは44枚。1枚の文字数は中央値3,614文字、平均23,133文字です。平均と中央値が大きく離れている。

最大の1枚は113,013文字で1,045行。動画で紹介する公式の目安「200行以内」を、大きく超えています。引き継ぎメモ1枚で、それだけの量になる。

起動時の合計も、中央値の顧客フォルダでは41,790文字、最大の顧客では151,189文字。チャエンさんの画面では、20万トークンを想定した容量の約21〜27%、約76〜98%と示されています。

巨大な1枚があると、作業に使う机がほぼ埋まる。動画の説明は、文字を増やすほど読ませたいルールも埋もれる、というものです。

対して、私の手元の指示書46枚は、200行を超える物が1枚もありません。最長はプロジェクト用CLAUDE.mdの154行で、ルール40本の中でも最長は146行でした。

1枚ずつなら短い。それでも合計は7万9千文字を超える。チャエンさんの巨大な1枚と、私の多数の短いファイル。増え方が違うんですね。

私は、行数の目安を守ることと、毎回読む総量を減らすことを両方見ます。ファイルを分けただけで、読む量まで減ったとは判断しません。

増加の速さも、動画では数字になっています。チャエンさんの環境は2日で21,752文字から28,902文字へ増加。増えた7,150文字は、元の21,752文字に対して32.9%です。

チャエンさん（動画の中で・自動字幕・12:49〜）

「ほったらかすと太っと[太って]しまうので、ま、週1回ぐらいはチェックしていただいてもいいかなと。」

この指摘も、そのとおりだと思います。私の側には、9月に指示体系をゼロベースで見直し、CLAUDE.mdを痩せ版にしてルール6本を退避した記録があります。それでも現在は40本。

一度短くしたら終わり、とはいかない。

さらにチャエンさんは、「日本語で出す」と「英語で出す」のような矛盾にも触れています。両方書けば両方守るのではなく、どちらかが選ばれてしまう。

文字数を減らす時には、意味も読む必要があります。重複と矛盾を残したまま、行だけ詰めても困りごとは解消しない。私なら、総量を数えた後で同じ指示が重なっていないかを診断させます。

→ 重なりを探す

今のCLAUDE.mdを渡し、同じ指示の重複と、逆の指示が並んでいる所を挙げさせます。行数だけを詰めず、どちらを残すか判断できる削除案を出させます。

私なら、CLAUDE.mdに残す基準を「消したら間違えるか」にします。文章を立派にするために増やす物ではありません。毎回説明しなければ分からない決まりを残したい。

チャエンさんは、書くのは推測できないことだけ、と話しています。会社名や役割、名前の表記など、仕事固有の前提です。

チャエンさん（動画の中で・自動字幕・13:11〜）

「書くのは推測できないことだけ書いてくださいと。」

動画で示された全案件用CLAUDE.mdは、5,252文字、96行、12セクション。紹介されている200行の目安に対し、96行に収まっています。

中身には、本人名を正しく表記する決まりがある。文字起こしで「茶園」に誤変換されるからです。「名前を正しく」とだけ書くより、間違える箇所と正しい表記が分かる。

メール送信は下書きまで、カレンダー招待を勝手に送らない。チャエンさんの説明では、どちらも勝手に送られた経験が理由になっています。

図解は白背景で、3秒で理解できる形にする。これも、ダーク背景の図解が出た日に追加した決まりです。好みの指定にも、書いた理由があるんですね。

Notionの表には、12セクションの一覧と「なぜ書いたか」、制定日が並んでいます。後で見直す人にも、追加した時の判断が残る形。

バックアップがないMacという前提には、撮り直せない原本を消されたら取り返せないという理由が付く。コードブロックの記号についても、Slack下書きの記号が相手に見えた経験が説明されています。

チャエンさん（動画の中で・自動字幕・15:19〜）

「未来のそのAIが読んだ時にあ、もういらないかなって判断できたりするじゃないですか。そういった意味で理由とかも書いていただくといいかなと思ってたりもしてます。」

理由があると、文だけを読んで削除するのを避けられます。防ぎたい間違いが続いているのか、決まりを置いた時の前提が変わったのか。消してよいかを考える材料になる。

私のルール40本のうち29本には「事故」の節があり、その29本のうち27本には日付が付いています。AIが、何があったか、原因、やることを書き足してきた記録です。

チャエンさんの制定日と理由に、同じ型があります。私の側にも、指示の背景を残す形はある。

だから私は、短くするために事故の理由から消す方法を選びません。本文を読んで必要性を判定する時、その理由も一緒に使います。何を防ぐ指示なのかを確かめたい。

新しく作る人向けのプロンプトも、基準は具体的です。「消したら間違えること」だけを書き、当たり前のことは書かない。項目ごとにWhyを1行添える。

私なら、禁止文の強さより、判断に必要な前提が残っているかを見る。後で短くできるように、残す理由も消す理由も考えられる材料を指示書に持たせます。

→ 理由を添える

残したい決まりを1項目選び、「これを消すと何を間違えるか」を確認します。確かめられる理由と制定日を添え、後で見直す時にも必要性を判断できる形にします。

私なら、指示の役目に合わせて置き場を選びます。長い物を別ファイルへ移すだけでは、毎回読む量は減らないからです。

チャエンさんのスライドには、CLAUDE.mdへ詰め込まない物と、その行き先が3つ並んでいます。手順の多い作業、一部の仕事だけに関係する決まり、実際に止めたい操作です。

手順の多い物はスキルへ。スキルは、必要な作業で読む手順書です。動画では動画編集を例に、長い手順を毎回のCLAUDE.mdに入れないと説明しています。

特定のファイルだけに関係する決まりは、paths付きルールへ。対象ファイルの条件を指定し、その条件に合う仕事の時に読む形です。

ファイルの先頭に書く paths: の例には、"**/Slack下書き*" や "**/*slack*.md" が出ています。Slack下書きという名前を含むファイルを触る時だけ、その決まりが関係する。

販売や申し込みにつなげるページであるLP、スライド、ロゴ素材を触る時の例もあります。その時だけ「ロゴを自作するな」という指示を読む。文字だけの仕事へ、ロゴの決まりまで毎回渡さないんですね。

同じ別ファイル化でも、@ は働きが違います。チャエンさんは、分割すると整理にはなるが、トークンの節約にはならないと話しています。分けた先も読むからです。

チャエンさん（動画の中で・自動字幕・16:07〜）

「整理にはなるんですけども、トークンの節約にはなりませんっていうところでございます。」

私の全案件用CLAUDE.mdにも、@ で読み込むファイルが3本あり、合計5,860文字が毎回読まれます。書く場所は分かれていても、読む量には入っている。

一方、ルール40本のうち、先頭にpathsを付けた物は0本。どの仕事でも40本すべてを読む形です。私なら、この条件の付け方を見直します。

チャエンさん（動画の中で・自動字幕・16:12〜）

「本当に軽くなるのはパス[paths]というところです。」

必要な時に読む置き場は、私の側にもあります。~/.claude/rules-ondemand/ に29本、合計142,305文字。全案件用CLAUDE.mdが、必要な場面でファイル名を挙げて指しています。

これは起動時には読まれません。ただし、pathsで対象ファイルに合わせる方法とは違い、指定された物を取り出して読む方式です。必要な時だけ読む、という目的にも複数の形がある。

残る行き先は権限とフック。チャエンさんは、禁止をCLAUDE.mdにも書きつつ、止める仕事はそちらへ置くと説明しています。

チャエンさん（動画の中で・自動字幕・10:55〜）

「絶対禁止も一応僕もMD[CLAUDE.md]に書くんですけども、絶対禁止に関しては権限フックとかに書いていただくといいと思う。」

引き継ぐ前提、作業の手順、ファイル別の決まり、操作の制限。それぞれの役目に合わせて読む物を選ぶ。そのとおりだと思います。

私が欲しいのは、別ファイルが増えたという整理の結果ではありません。今の仕事に必要な指示が読まれること。@ の分割、手作業で読む置き場、pathsの条件を、同じ方法として扱わず選びたい。

必要な記録を残したまま、毎回読む対象を絞る。これが、私なら選ぶ軽くし方です。

→ 行き先を選ぶ

CLAUDE.mdの1項目を、長い作業手順、特定ファイルの決まり、止めたい操作のどれかで判定します。スキル、paths付きルール、権限とフックへの移動案を出させます。

この章では、私のCLAUDE.mdに加え、毎回読むルール、必要な時だけ読む手順書、フックと権限の登録状況を見ます。自分の設定を見直すなら、指示書の長さと、操作を止める仕組みを別々に確かめたい。私の設定は、毎回読む棚が厚く、止める棚の構成は起動のしかたで変わります。

チャエンさんが示した、スキル、paths付きルール、権限とフック。その行き先へ私の設定を当てはめると、文章を整理する仕事と、操作を制限する仕事が見えてきました。

毎回読む棚には、全案件用と、この作業場所のプロジェクト用CLAUDE.mdがあります。仕事の前提を伝える指示書。全案件用は70行、プロジェクト用は154行です。

前者には「正直さ」「完了条件」など、案件をまたいで守る決まりがある。そこに別の参照資料とルールが加わります。読む物を分けても、毎回渡す棚に置けば量は積み上がる。

必要な時だけ読む棚には、作業ごとの手順書であるスキルがあります。私の共通スキル置き場には315本。全部を仕事の開始時に読むのではなく、必要な作業で読む物です。

長い手順の置き場はある。一方、対象ファイルに合わせて読むpaths付きルールへは、ルール40本のうち1本も移っていません。手順を取り出す方法と、条件に合わせて読む方法は別なんですね。

機械で止める棚を見ると、開き方の違いが出ます。私は自作の管理画面「AGI Cockpit」から開く時と、端末から直接開く時があり、読む設定ファイルが別です。

この記事を作っているのは管理画面から開いた作業場所。その管理画面用の設定ファイルには、フックの登録が全部で40件あります（操作の前に走る物は24件）。権限の記述はありません。これだけで、操作の制限がないとは言えない。

端末から直接開く時の設定ファイルには、フックの登録が全部で130件（操作の前に走る物は81件）。この作業場所の設定ファイルにも、フックの登録12件（操作の前は2件）と権限があります。件数が多い方を、そのまま安全とは判定しません。

さらに、作業場所の個別設定には、確認なしで通す許可が561件あります。止める設定だけでなく、何を確認なしで通す設定にしているかも、同じ棚で見る必要がある。

文章側にも差がありました。ルール40本のうち、機械で止める仕組みを示す語がある物は21本、ない物は19本。ただし、語がある21本すべてが、全文を機械で強制しているわけではありません。

表記の統一や図解の余白。語がない側にも、守ってほしい決まりが並ぶ。対して、管理画面で動画・音声を開かない決まりには、開く前に道具が止める仕組みがあります。

実際、この記事の作業中にもフックが反応しました。AIに件数を数えるスクリプトを書かせようとした時、設定ファイル名が含まれていたため、保護ファイルの書き換えを防ぐ仕組みが操作を止めた。

中身は読み取りだけでした。AIは別の方法でファイルを作り直して先へ進んだ。同じ日に、公開確認の状態を読むコマンドも、記事の番号と、公開確認を出す時の語が含まれていたため止まりました。

止まった事実はある。でも、止めたい操作を正しく見分けたかは別。書かれた言葉に反応すると、読み取りまで止めることがある。機械へ渡す禁止にも、対象の確かめが要ります。

私が次に見るのは、語がない19本のうち、事故が繰り返された物です。権限やフックで止める置き場へ移せるかを確かめる。毎回読む文章を強くする前に、任せるための止め方を選びます。

→ 止め方を照らす

繰り返し間違えた決まりを1つ選び、今の起動方法で読む設定をAIに確認させます。止めたい操作と、通したい読み取りを並べ、権限やフックで区別できるかを調べます。

私なら最初に /context を開きます。Claude Codeが仕事に使う机に、何が載っているかを見る操作です。減らす対象を、実際の内訳から選びたい。

チャエンさんの画面では、会話のMessagesが65.5k、6.8%。Memory filesが20.7k、2.1%。Skillsが9.9k、1.0%と、容量全体に占める割合が色分けされています。

空きのFree spaceは810.5k、全体の83.8%。指示書だけを見る画面ではなく、会話や道具も含めて何が使っているかを確かめる画面です。

画面の題には /doctor も並んでいます。言うことを聞かない時は、禁止文を足す前に、まず状況を確かめる。私はこの順番にします。

次は、CLAUDE.mdを作るか、今ある物を診断するかです。動画の3歩は、中身を見る、作る、痩せさせる。今の状態に合う方を選べばいい。

新しく作る人向けには、仕事の進め方を5つ質問させ、その答えから50行以内で作るプロンプトが出ています。

チャエンさん（動画の中で・自動字幕・21:42〜）

「私の仕事の進め方5つ質問してその答えを元にMD[CLAUDE.md]を作ってください」

作成条件は「消したら間違えること」だけ。当たり前のことは書かず、1項目ごとにWhyを1行添える。長い指示書を先に用意するより、仕事固有の決まりを答えて作る形です。

今ある人向けの診断も、1行ずつ具体的に進めます。「これを消したら間違えるか」を判定させ、間違えない物は削除案へ。特定のファイルだけの決まりは、pathsのパターン付きで移動案を出させる。

大事なのは、診断の段階では書き換えさせないこと。削除と移動の理由を読んでから、変更を決めます。

効かない原因にも当たりを付けたい。チャエンさんが示す原因には、ファイルが長すぎること、指示の矛盾、サブフォルダの指示が読まれていないことがあります。

会話を圧縮する /compact の後は、深い階層やpaths付きルールが自動では戻らない、という注意もあります。効かなくなった時に、同じ文を足して解決しようとしない。

私が次に分けるのは、ルール40本の中の「どの仕事でも毎回要る物」と「特定の仕事の時だけ要る物」です。全体の診断をAIに頼み、まず1本の行き先を決めます。

最初に直すのは、その1本でいい。何を残すか、いつ読むかまで判断できれば、1枚の診断が具体的な変更につながります。

→ 1枚の診断

/contextで内訳を確認したら、CLAUDE.mdを1枚渡します。「消したら間違えるかを1行ずつ判定し、削除案とpaths付きの移動案を出して。書き換えないで」と頼みます。

最初の1手は、CLAUDE.mdを1枚選び、AIに削除案と移動案を出させることです。「消したら間違えるか」を1行ずつ判定させ、特定の仕事だけで必要な物にはpathsの条件も付けてもらう。書き換えは、その案を読んでから。私なら最初の変更対象は1項目にします。残す理由と読む条件がそろった1項目を選ぶ。指示書全体を一度に変えるより、何を直すかがはっきりします。