playbooksでCLAUDE.md肥大化を防ぐ 記事アイキャッチ

Claude Codeを本気で運用すると、必ず同じ壁にぶつかります。失敗のたびにルールを追記して、CLAUDE.mdがどんどん膨らんでいく――起動のたびに全部読み込むから動作は重くなり、肝心のルールは埋もれて守られなくなる。FlatWorksがたどり着いた答えは、AIに渡す知識を「毎回読む」「必要な時だけ読む」「キーワードで自動起動」の3層に分けることでした。この記事では、その中でも一番効果が大きかった「playbooks(必要時だけ読む手順書)」の実運用を、実際のファイル12本・発動条件とセットで公開します。

FlatWorks 代表 川満 友樹
FlatWorks 代表 川満 友樹

ルールを足すほどAIが「重く」なる問題

AIの運用は、ルールの蓄積です。「コードを勝手にpushしないで」「数字は出典を付けて」「この口調で話して」――失敗するたびに1行ずつ追記していく。この積み重ね自体は正しい運用です。問題は、その置き場所がCLAUDE.md(AIが毎回最初に読む設定ファイル)1枚に集中することです。

実際、この悩みは弊社だけのものではありません。2026年に入ってから「CLAUDE.mdが1,300行になった」「2,000行近くまで肥大化した」という報告と、その削減記録が技術ブログで相次いで公開されています(出典は記事末尾)。皆さん同じ道を通っているわけです。

肥大化の害は、体感よりも深刻です。

  • 毎回のトークン消費――AIは起動のたびにCLAUDE.md全文を読み込みます。使うかどうかわからない手順書まで毎回読むのは、純粋なコストの無駄です
  • 重要ルールが埋もれる――1,000行の中の1行は守られません。「ルールを足したのに守られない」の原因の多くはこれです
  • 本来の指示に割く余力が減る――AIが一度に扱える情報量(コンテキスト)は有限です。設定で埋めれば、その分だけ作業に使える領域が減ります

外部の削減記録では「CLAUDE.mdは200行以下が目標」という目安も語られています。では、増え続けるルールと手順書をどこに置けばいいのか。

解決の考え方――知識を「3層」に分ける

FlatWorksでは、AIに渡す知識を性質で3つに分けています。ポイントは「全部を毎回読ませる必要はない」という割り切りです。

rules・playbooks・skillsの3層構造図。rulesは毎回読む絶対規律、playbooksは必要な時だけ読む手順書、skillsはキーワードで自動起動する専門知識
FlatWorksの知識3層構造。「毎回読む」のはrulesだけに絞る
読み込み 置くもの
rules/ 毎回読む(常時ロード) 破ったら事故につながる絶対規律。安全規律・口調・gitの扱い・機密値の扱いなど
playbooks/ 必要な時だけ読む 特定の場面でだけ要る手順書。制作前のチェック規範・資料生成のツール使い分けなど
skills/ キーワードで自動起動 分野ごとの専門知識。HP評価の観点・SNS投稿のノウハウなど

振り分けの判断基準はシンプルです。「破ったら事故るか?」ならrules。「特定の作業の品質を上げる手順か?」ならplaybooks。「特定の分野の専門知識か?」ならskills。この基準で仕分けると、実は「毎回読ませる必要があるもの」は思ったより少ないことに気づきます。

rulesとskillsの設計は過去記事(ルールファイル設計編)で詳しく書いたので、今回は真ん中の層――playbooksに絞ります。ここが一番、外部の事例でも語られることが少ない部分だからです。

FlatWorksの実playbooks 12本――「いつ読むか」とセットで公開

弊社で現在運用しているplaybooksは12本、合計約1,250行です。代表的なものを、実際のファイル名と発動条件のまま載せます。

ファイル いつ読むか(発動条件)
anti_ai_look.md HP・SNS・動画など制作系の着手前に必読。「AIが作った感」を排除するための表現規範
document_generation.md 資料・PDF生成の作業時。生成ツールの使い分け基準
long_run_gate.md 30分以上かかるスクリプトの実行前。小さく試してから本実行する規律
handoff_template.md 作業セッションを区切る時。引き継ぎメモの雛形と「完了/未検証」の書き分けルール
fact_check_competitor.md 他社・競合との比較を書く時。記述前の検証手順
project-charter-template.md 新規プロジェクトの立ち上げ時。目的・範囲・成功条件の整理テンプレート

ほかに、週次監査の自己点検手順、データ作業時の保管規律、大型案件の進め方など6本。どれも「その場面が来た時には絶対に参照してほしいが、それ以外の日には1行も要らない」知識です。

見てほしいのは、表の右列が主役だということです。ファイル名ではなく「いつ読むか」を書いておくことで、AIが自分の今の作業と照合して、読みに行くべきか判断できるようになります。手順書の中身がどれだけ充実していても、発動条件が曖昧だと参照されません。

自社のAIに「ルール」と「手順書」を整備したい方へ

FlatWorksのAI活用支援を見る →

@importしない勇気――「コメント行の索引」だけ置く仕掛け

ここが今回の核心です。Claude CodeのCLAUDE.mdには、別ファイルを取り込む@importという仕組みがあります。rulesはこれで毎回読み込ませています。では、playbooksも@importすればいいかというと――それをやると元の木阿弥です。12本・約1,250行が毎セッション強制ロードされ、CLAUDE.mdを分割した意味がなくなります。

弊社のCLAUDE.mdに書いてあるのは、こういうコメント行だけです。

# オンデマンド参照(playbooks/ に配置・@importしない・必要時のみ読む)
# playbooks/anti_ai_look.md - HP/SNS/動画など制作系の着手前に必読
# playbooks/document_generation.md - 資料/PDF生成の作業時
# playbooks/long_run_gate.md - 30分以上のスクリプト実行時
# playbooks/handoff_template.md - セッションを区切る時
# ...(以下同様に1行ずつ)

コメントなので、AIへの強制力はありません。その代わり毎回読み込まれるのはこの索引12行だけ。AIは「どんな場面で、どのファイルを読むべきか」という地図だけを常に持っていて、該当する作業が来た瞬間に、自分でそのファイルを開きに行きます。

コメント索引方式の動作イメージ。CLAUDE.mdには索引だけを置き、必要な時に手順書の本棚から読みに行く流れ
索引だけ持たせて、本文は必要になった瞬間に読みに行かせる

実測の数字で言うと、弊社のCLAUDE.md本体は116行です。playbooksの約1,250行を@importしていたら10倍超になっていた計算です。ルールの総量は運用とともに増え続けていますが、毎回の読み込み量はほぼ一定に保てています。

この「概要だけ先に見せて、詳細は必要になってから開示する」という考え方は、海外ではProgressive Disclosure(段階的開示)と呼ばれ、Claude Codeの公式機能であるSkillsも同じ思想で設計されています。コメント索引方式は、それを最小の仕組みで自作する方法だと言えます。

運用して分かった効果と失敗

正直に書くと、最初からうまく回ったわけではありません。つまずいたのは主に2つです。

失敗1:読み忘れが起きる。導入初期、索引に「# playbooks/anti_ai_look.md - AIっぽさ排除」とだけ書いていた時期は、制作作業に入っても参照されないことがありました。改善したのは書き方です。「制作系の着手前に必読」のように、タイミング(着手前)と強制度(必読)を発動条件に含めてから、参照率が目に見えて変わりました。それでも読み忘れる重要手順があれば、それはrulesへ昇格させるサインです。

失敗2:置きすぎる。「とりあえずplaybooksに置いておこう」を繰り返すと、今度は索引が肥えていきます。使われていない手順書は索引の中のノイズです。弊社では月次で棚卸しして、実際に使わなくなった1本をアーカイブフォルダに退避させました。「足す」より「捨てる」方が運用では難しい――これはCLAUDE.md本体と同じです。

効果の方は明確でした。起動が軽いまま知識を増やせること以上に大きかったのは、ルールの置き場所を聞かれたら即答できるようになったことです。「これは事故防止だからrules」「これは制作手順だからplaybooks」。分類基準があるだけで、AI運用の整理整頓が習慣になります。

始め方としては、AIに同じ指示を2回したら、それがplaybook候補です。よく繰り返す指示を1本だけファイルに切り出して、CLAUDE.mdには発動条件付きのコメント1行を書く。まずそこからで十分です。

まとめ――「全部覚えさせる」から「索引を持たせる」へ

CLAUDE.mdの肥大化問題の本質は、「AIに常に覚えさせておくべき知識」と「必要な時に参照できればいい知識」の混在です。整理すると、この記事の要点は3つです。

  • 知識は3層に分ける。毎回読むのは「破ったら事故る規律」だけに絞る
  • 場面限定の手順書はplaybooksへ。@importせず、発動条件付きのコメント索引だけをCLAUDE.mdに置く
  • 索引は「いつ読むか」が主役。曖昧なら読まれず、具体的なら自走する

FlatWorksでは、この知識管理の設計まで含めて「AIの組織化」だと考えています。ツールを導入するだけでなく、自社の業務・ルール・手順をAIが参照できる形に整備するところからが、AI活用の本番です。「うちのAI運用、ルールが散らかってきた」という段階のご相談も歓迎です。

参考(外部事例・出典)

  1. 【スキルで分割】1300行のCLAUDE.mdを250行にしてみた(note)— https://note.com/major_elk2890/n/n120fa8c437d7
  2. CLAUDE.md の肥大化を 3 層構造で 83% 軽くした — 実測と試行錯誤の記録(Zenn)— https://zenn.dev/pepabo/articles/claude-code-rules-skills-split
  3. 【Claude Code】CLAUDE.mdが肥大化する問題とその解決策(ENECHANGE Developer Blog)— https://tech.enechange.co.jp/entry/2026/03/24/102016
  4. CLAUDE.mdの肥大化を防ぐ!.claude/rules/で動的にルールを読み込む方法(Zenn)— https://zenn.dev/tmasuyama1114/articles/claude_code_dynamic_rules

本記事のファイル構成・行数(CLAUDE.md 116行、playbooks 12本・約1,250行)は、2026年6月10日時点のFlatWorks社内環境の実測値です。Claude Codeの仕様・機能名は同日時点の情報に基づきます。

関連記事 どのルールファイルを書いたら劇的に変わったか――実際のファイル構造と設計の考え方 社長1人の会社で、Claude Codeを"秘書みたいに"使い始めた話

Contact

AIの知識管理、設計から整えませんか

「ルールが散らかってきた」「AIが指示を守らない」
現状をお聞きして、最短ルートをご提案します。

お問い合わせ