夜、作業を終える前にCLAUDE.mdを開いた。
少しだけ直すつもりだった。
でもスクロールしても、終わらない。
ルール、手順、役割、禁止事項。
いつの間にか、全部が1枚に詰まっていた。
そこで気づいた。重くなってきている、と。
CLAUDE.mdを作ったはいいが、何を書けばいいかわからなかった。
ルールを書けばいい、というのはわかっていた。
でも、どんなルールを、どこに、どれくらい書けばいいのか。
それが最初の壁だった。
答えはシンプルだった。
チャットでやりたいことを相談して、Claude Codeに書いてもらえばいい。
そしてその構造を見たとき、20年前に読んだ言葉を思い出した。
——これ、オブジェクト指向じゃないか。
この記事は、Claude Code時代に CLAUDE.md が重くなり、役割ごとのファイルへ分けていった記録である。今のCodex環境では、入口になるルールは AGENTS.md に置き、重くなった仕事は役割ごとのファイルへ分けている。
最初から分ける必要はない。繰り返し使うルールをいつ保存するかは、後の記事「毎回のコピペが面倒になったら、AGENTS.mdに移す」で書いた。
CLAUDE.mdに何を書けばいいか、わからなかった
前の記事で、CLAUDE.mdにルールを書いたら止まるようになった話をした。
確認を取るようになったのだ。
「すぐに実装したいんですが、どうしますか」とチャットで聞いてくる。
最初はそれが新鮮だった。
止まってもらえると、こちらも「何をしたいか」を言葉にする時間ができる。
そこで気づいた。
CLAUDE.mdに何を書けばいいかで詰まっていたが、答えはここにあった。
チャットでやりたいことを話す。
「こういう記事を作りたい」「投稿作業を自動化したい」と相談する。
するとClaude Codeが「じゃあこういうルールはどうですか」と提案してくる。
それをそのままCLAUDE.mdに書けばいい。
難しく考える必要はなかった。
CLAUDE.mdは最初から完璧に書くものじゃない。
使いながら、会話しながら育てていくものだ。
チャットで相談すれば、CLAUDE.mdは自然に育つ。
最初は、全部CLAUDE.mdに書いていた
そうしてルールが増えていった。
最初に書いたのは実装ルールだ。
実装前に確認を取る。
1STEPずつ止めて報告する。
ファイルを勝手に削除しない。
それだけで動いていたのは最初の1週間だ。
使っていくうちに「ここにもルールが要る」という場面が出てくる。
そのたびにCLAUDE.mdに書き足した。
役割のことも書いた。
編集長はこういう仕事をする。
ライターはここまでやったら止まる。
手順も書いた。
記事を書くときはこのステップで。
投稿前にここを確認する。
気づいたら100行を超えていた。
でもまだ大丈夫だと思っていた。
Claudeは全部読んでくれているはずだと。
全部1ファイルに書ける気がしていた。
重くなってきた
行数が200を超えた頃から、おかしくなってきた。
書いたはずのルールが、反映されにくくなった。
前半に書いたルールが無視されることが増えた。
後半に書いた手順は、ほぼ参照されなかった。
それだけじゃない。
俺自身も、どこに何を書いたかわからなくなってきた。
「確認ルールどこに書いたっけ」と自分のファイルを検索する羽目になった。
考えてみれば当たり前の話だ。
人間だって、200行のメモを全部読み返すのは辛い。
Claude Codeも同じだ。
情報が多すぎると、優先度が下がる。
全部1ファイルの限界だった。
CLAUDE.mdが重いので、役割ごとにファイルを分けた
役割ごとにファイルを作ることにした。
編集長には編集長のファイル。
ライターにはライターのファイル。
リサーチャーにはリサーチャーのファイル。
担当者ごとに、指示書を分けた。
これで読み飛ばしが減った。
「編集長として動いて」と言えば、編集長のファイルだけ読めばいい。
200行の全体ファイルを毎回読む必要がなくなった。
俺の場合、まずhenshucho.mdとwriter.mdの2つから始めた。
最初から5つ作ろうとして、逆に混乱した。
2つから始めて、必要になったら増やす。それだけでよかった。
役割を分けると、AIも迷わなくなる。
何を書くかは、チャットで相談して決めた
CLAUDE.mdに何を書けばいいか。
最初からわかっていたわけではない。
むしろ、わからなかった。
「編集長はいろいろ仕事を持っている。記事を書く。ネタを出す。内部リンクを整える。これを1つのworkflow.mdに書くのと、別ファイルに分けるのとで出力に差はあるのか」
そんな相談から始めた。
そこから、少しずつ分かれていった。
ライターは、書く専門でいい。
競合分析は、リサーチャーに渡す。
文体チェックと下書き保存は、コンテンツマネージャー。
公開後のDB登録と目次反映は、実装役。
最初から、きれいな組織図があったわけじゃない。
チャットで相談しながら、
「これはライターの仕事じゃない」
「これは編集長が判断することだ」
「これは実装に渡した方がいい」
と、ひとつずつ分けていった。
だから、CLAUDE.mdに何を書けばいいかわからないなら、いきなり書こうとしなくていい。
まず、チャットで相談すればいい。
「毎回同じ説明をしていて面倒です」
「記事を書く前に何を決めればいいですか」
「ライターに全部やらせている気がします」
そうやって話しているうちに、自分の中のルールが出てくる。
そのルールを、あとからCLAUDE.mdに移せばいい。
CLAUDE.mdは、最初に完璧に書くものではない。
会話の中で見つかった判断を、あとから置いておく場所だ。
__init__.mdとworkflow.mdに分けた
ファイルを分けていくうちに、もう一段気づいたことがある。
1つのファイルに「何者か」と「どう動くか」の両方を書くと、またごちゃごちゃしてくるのだ。
だから各役職のファイルを2つに分けた。
`__init__.md`：この役職は何者か、何をする役か。
`workflow.md`：どう動くか、どの順番で進めるか。
`__init__.md` は定義だ。
「この人はどんな人か」を書く場所。
俺は50行以内に収めるようにした。
`workflow.md` は手順だ。
「この人はどう動くか」を書く場所。
手順は長くなってもいい。でも定義とは別にする。
この2つに分けたら、Claudeが迷わなくなった。
「編集長として起動する」と伝えると、`__init__.md` で役割を把握し、`workflow.md` で動き方を確認する。
俺は何も説明しなくていい。
定義と手順を分けると、ファイルも短くなる。
これはオブジェクト指向だと気づいた
ある日、フォルダ構造を眺めていて気づいた。
“`
henshucho/__init__.md
henshucho/workflow.md
writer/__init__.md
writer/workflow.md
“`
これ、プログラムのクラスと同じ構造じゃないか。
クラスは、設計図に近い。
定義と動作をセットにした構造だ。
俺はプログラマーじゃない。
トラックドライバーだ。
でも気づいたら、クラスと同じことをやっていた。
20年前、オブジェクト指向の本を読んだことがある。
そのときは「ふーん」で終わった。
使える場面が思い浮かばなかった。
それが、AI社員の設計をしていたら突然使える言葉になった。
エンジニアじゃなくても、設計をしていれば同じ発想に辿り着く。
オブジェクト指向を思い出したのは、そういう日だった。
よくある質問
CLAUDE.mdには最初に何を書けばいい？
当時のClaude Code環境では、最初から全部書かなくてよかった。
まずは「実装前に確認する」「勝手にファイルを削除しない」など、怖い作業を止めるルールからでよかった。
何を書けばいいかわからなければ、当時はチャットで「このプロジェクトでClaude Codeに守らせるべきルールは何？」と聞けばよかった。
役割ごとのファイルは最初からたくさん作るべき？
最初から増やさなくていい。
俺は当時、henshucho.mdとwriter.mdの2つから始めた。
動かしてみて、必要になったら増やせばいい。
コメント