ハネムーン期3部作のあと、非エンジニアのマネージャーがたどり着いた仕組み化
結論から言うと、CLAUDE.mdを真面目に育てようとすると、1つのファイルでは足りなくなる
前回までの3部作（ハネムーン期の終わり／AutoMode地獄／AIへの暴言）で書いたように、自分がClaude Codeに抱えていた不満の多くは、実は自分の使い方の問題だった。その対策として、繰り返し「CLAUDE.mdを育てる」ということを書いた。
これを本気で実践しようとしたのが、今回の話。結論として、CLAUDE.mdだけでは足りなかった。そしてその先で、Claude Codeには**.claudeというフォルダ全体を"組織"として設計する仕組み**が用意されていることに気づいた。
マネージャー視点で言えば、口頭指示 → マニュアル整備 → 組織設計、という自然な流れだった。そしてこの3段階目に足を踏み入れたことで、ようやく脱出ゲーム開発でのやらかしが構造的に説明できるようになった。同じ立場で育成ゲームを開発している自分の備忘録として、書いておく。
CLAUDE.mdを育てる、をやってみて起きたこと
第2弾の対策で「CLAUDE.mdを育てる」と書いた。「過去にやらかしたミスパターン」をそこに書き溜めていく、というアプローチ。
第4弾では「怒りの原因はドキュメント化する」とも書いた。イライラしたポイントは、その場で怒るのではなくルールとして記録する。
育成ゲームの開発で、これを実際にやった。最初はうまくいっていた。
- 「1ファイル150行を超えたら分割提案する」
- 「freezedは状態管理のメインだけに使う」
- 「Material標準のウィジェットは使わない（世界観が崩れるので）」
- 「パッケージ追加は必ず承認を得てから」
- 「flutter cleanは勝手に実行しない」
こういうルールをCLAUDE.mdに足していった。怒りを生産的な資産に変える、というのは本当に効いた。同じミスが確実に減る。
ただ、しばらく運用していると、また別の問題が見えてきた。
CLAUDE.mdが長くなると、また埋もれる
CLAUDE.mdに書くことが増えていった結果、何が起きたか。
1つのファイルにルールが混在するようになった。画面ファイルに対するルール、状態管理に対するルール、ビルドに対するルール、世界観に対するルール。全部が一箇所に並んでいる。
そしてClaude Codeに画面ファイルを触らせているとき、状態管理のルールまで毎回読み直されることになる。文脈に合わないルールが混ざっていると、ノイズになる。
もっと問題だったのは、ルールが増えるほど、個々のルールの重みが薄まることだ。30個あるルールの中の1個は、5個あるルールの中の1個より、確実に守られにくくなる。
第2弾で自分が書いたのは「プロンプトに書いた指示は会話が進むと埋もれる」という話だった。でもCLAUDE.mdの中でも、同じ"埋もれ"は起きる。量が増えれば効き目が落ちる。これは人間のマニュアルでも同じだ。
気づいたとき、ちょっと落胆した。「CLAUDE.mdを育てる」という対策は正しかったが、それだけでは不十分だった。
.claudeというフォルダが、実は用意されていた
調べていて知ったのは、Claude Codeには**.claudeというフォルダ全体を置ける仕組み**があるということだった。CLAUDE.mdは入口でしかなく、その中には役割別のサブディレクトリがある。
ざっくり整理するとこうなる。
| 場所 | 役割 | マネジメント的に言えば |
|---|---|---|
| CLAUDE.md | プロジェクトの前提。常に参照される | 全社共通のハンドブック |
| rules/ | 対象ファイル別の規約。対象を触るときだけ自動参照 | 部署別の業務手順書 |
| agents/ | 専門の役割を持つサブエージェント | 専門チーム（レビュー担当、検査担当など） |
| hooks/ | 特定のイベントで必ず実行される処理 | 就業規則の強制ルール |
肝心なのは、rules/に置いたルールは、対象のファイルを触ったときだけ自動で参照されるということ。つまり画面ファイルを触っているときに、状態管理のルールが混ざらない。
これを知ったとき、自分がやっていたのは「全社員向けの1冊のハンドブックに、全部詰め込もうとする」行為だったと気づいた。マネジメントで同じことをやったら、誰も全部は読まない。必要なときに必要なページだけ開ける構造にする、というのは組織設計の基本だ。
Claude Codeにはその構造が最初から用意されていた。自分が使っていなかっただけだった。
過去3作の失敗が、ここで全部繋がった
.claudeの構造を知ってから、ハネムーン期3部作で書いた失敗を読み直してみると、全部これで説明がついた。
第2弾：指示が雑になって出力が劣化した話 → 雑になっても守らせたいルールは、プロンプトではなくrules/に置く。対象ファイルを触るたびに自動で読まれる。人間の気合に頼らず、仕組みで維持される。
第3弾：AutoModeに任せて壊された話 → 本当に防ぎたかったのは「規模が大きすぎる変更が無言で進むこと」。hooks/で「大量のファイル変更が検知されたら一旦止まる」を強制できる。判断の自動化と実行の自動化を分ける、という第3弾の結論を、仕組みとして実装できる。
第4弾：暴言で出力が劣化した話 → 第4弾で書いた「怒りの原因はCLAUDE.mdに書き留める」は、正確にはrules/のほうが相性がいい。イライラの原因は大抵「特定のファイル」や「特定の作業」に紐付くから、対象別に整理したほうが効く。
全部、「その場の指示」で解決しようとしていたものを、「恒久的な仕組み」に置き換える話だった。
マネージャー視点で言えば、これは組織設計だった
ここが自分にとって一番腑に落ちたところ。
自分は本業で、チームを持ってマネジメントをしている。その経験からすると、Claude Codeへの向き合い方は明確な3段階に分かれていた。
第1段階：口頭指示 新人にその場で「これやって」と伝える。会話で完結する。 → Claude Codeで言えば、プロンプトに毎回ルールを書く状態。
第2段階：マニュアル整備 よくある業務を文書化する。「入社時に渡す資料」を作る。 → CLAUDE.mdを育てる段階。第2弾・第4弾で書いた対策のレベル。
第3段階：組織設計 役割を分ける。部署を作る。手順書を部門別に管理する。専門チームを置く。守るべき規則を制度として設計する。 → .claude配下を役割別に設計する段階。
本業でチームが5人から20人に増えたとき、口頭で回っていたものがマニュアルになり、マニュアルが増えると部門別の手順書になり、最終的に組織設計に発展した。Claude Codeとの付き合い方も、全く同じ道筋を辿っていた。
気づいたあとで、妙に納得した。これ、エンジニアリングの話というより、組織マネジメントの話だ。非エンジニアのマネージャーだからこそ、辿り着きやすい視点だったのかもしれない。
育成ゲームで、最初から組織設計する
脱出ゲームでは、第1段階（口頭指示）と第2段階（マニュアル）を行ったり来たりしていた。途中でCLAUDE.mdを導入したが、その中に全部詰め込んでいた。
育成ゲームでは、最初から第3段階で設計する。具体的にはこう置く。
CLAUDE.md（全社ハンドブック）
- もふふミルクシリーズの世界観
- Flutter + Riverpodという技術選定の理由
- 「Material標準ウィジェット使用禁止（世界観が崩れるため）」などの基本方針
rules/（部署別手順書）
- 全.dartファイル共通のルール（150行上限、など）
- 画面ファイル向けのルール（独自Widgetを使う、など）
- 状態管理ファイル向けのルール（freezed使用範囲、など）
agents/（専門チーム）
- world-checker：セリフや表現がシリーズの世界観と整合しているかをチェック
- release-checker：リリース前のチェックリスト（AdMob審査、IAPの審査要件、プライバシーポリシー）を機械的に検証
hooks/（就業規則）
- flutter clean実行前の承認要求
- 大量のファイル変更が発生したときの一時停止
第3弾で書いた「AutoModeに丸投げして壊された話」が、ここで構造的に防げるようになる。個人の気合ではなく、仕組みで。
実践する上での優先順位
これから.claudeを整備する人のために、試してわかった優先順位を書いておく。
1. まずCLAUDE.mdに前提だけ置く（効果：大）
いきなり全部作り込まない。Claude Codeに毎回最初に伝えている前提だけを抜き出して、CLAUDE.mdに置く。これだけでセッションごとの説明コストがゼロになる。
2. 繰り返し怒った内容をrules/に移す（効果：大）
第4弾で書いた「怒りの原因はドキュメント化」の進化版。CLAUDE.mdに書いてみて、それが「特定のファイルを触るときだけ必要なルール」だと気づいたら、rules/に移す。
3. リリース前チェックをagents/にする（効果：中）
リリース準備のような「抜け漏れが怖い作業」は、チェックリストを機械に持たせる。人間の記憶で管理しない。
4. hooks/は後回しで良い（効果：中、難易度：高）
これは実装のハードルがやや上がるので、まずは1〜3で運用が回り始めてから触るので十分。
5. ルールの総量ではなく、配置で効かせる（大原則）
第2弾で自分が書いた「指示が雑になる」と同じ構造で、ルールを置きすぎると結局埋もれる。量より配置。どこに置けば自然に効くかで判断する。
振り返って
ハネムーン期3部作で気づいたのは、「AIは鏡」であり、「自分の指示力・マネジメント力が返ってくる」という話だった。
今回の第5弾は、その続きだ。鏡に映った自分の問題を、気合ではなく仕組みで解決する、というフェーズに入った。
- 指示が雑になる自分 → rules/で自動参照される仕組み
- 任せすぎて壊す自分 → hooks/で止まる仕組み
- 感情的になる自分 → 怒りをrules/として資産化する仕組み
全部、自分の弱さを前提にした設計になっている。ここがポイントで、自分が変わろうとするのをやめて、仕組みで変わったように振る舞えるようにするのが、組織設計の本質だと思う。
本業のチームも、実はそうやって回している。「意識の高い社員」を前提にした組織は、たぶん弱い。普通の社員が普通にやれば成果が出る組織のほうが、長期的には強い。Claude Codeとの関係も、同じだった。
おまけ：こんな奮闘を経て、個人開発のアプリもリリースしています
このハネムーン期3部作＋今回の第5弾で書いたような試行錯誤を重ねながら、バイブコーディングで個人開発のアプリを作っています。「AIとどう付き合えば、非エンジニアでもモノが作れるのか」を、自分を実験台にして検証している感じです。
第一弾：もふふミルクとにゃんこ脱出ゲーム 🐾
記事に登場しているミルクは、この個人開発アプリの主人公です。ふわふわの謎を解いて、ミルクと一緒に脱出しよう。
📱 アプリはこちらからダウンロードできます 👉
次回作：育成ゲーム、開発中 🌱
今回の記事で書いた.claudeの組織設計を、最初から適用して作っているのが、次の育成ゲームです。ミルクたちをじっくり育てられるゲームを目指して、現在進行形で開発中。実際に.claudeを整備してみてどうだったかは、育成ゲームがリリースできたら改めて書きます。
興味ある方はフォローしてもらえると嬉しいです！
次回：「.claudeを本気で整備してみたら、育成ゲームの開発が"自分の想定より"早く進んだ話」 を書く予定です。今回の理論編に対する、実践編になります。
これまでのシリーズ
- 「外注500万円」に絶句した私がClaudeCodeで1週間・約2万5千円でアプリをリリースした話
- AIハネムーン期の終わり—Claude Codeに感動していた1ヶ月、そして冷めた話
- Claude CodeのAutoModeに全部任せたら、バグだらけで全部やり直した話
- AIに暴言を吐いたら、本当に出力が劣化した話 — Claude Codeに罵声を浴びせた1週間の記録
- CLAUDE.mdを育てる、の先にあったもの（この記事）
※本記事はnoteからの転載です：https://note.com/natty_yarrow1907/n/ne84fd196c4c1