HTMLでプロンプトを作れるようになった。
記事リスト.txtで、Claudeに過去記事を渡せるようになった。
articles.dbで、新しい記事だけを追加できるようになった。
3つのファイルが揃って、
ブログ運営は少しずつ自動で回り始めた。
その中心に置いていたのが、CLAUDE.mdだった。
この記事は、Claude時代に `CLAUDE.md` を分けていったときの記録である。今のCodex環境では、同じ役割を `AGENTS.md` と役割ごとのファイルに分けている。大事なのはファイル名ではなく、全部を一つに詰め込まず、必要なルールだけを読める形にすることだ。
現在のCodexで繰り返し使うルールをどこへ保存するかは、後の記事「毎回のコピペが面倒になったら、AGENTS.mdに移す」で詳しく書いた。
最初は、全部CLAUDE.mdに書いていた
ブログを始めたとき、Claudeに渡すルールをどこに書けばいいのかわからなかった。
調べると、CLAUDE.mdというファイルを作ればいいとわかった。
Claude Codeが起動するたびに読み込む、プロジェクトのルールブックだ。
最初は何でも入れた。
どんなトーンで書くか。
禁止事項は何か。
読者はどんな人か。
記事の文字数はどれくらいか。
SEOをどう考えるか。
投稿後にDBにどう登録するか。
全部、1つのファイルに書いた。
それで動いた。
最初のうちは、それで十分だった。
全部を1つに入れると、とりあえず動く。
CLAUDE.mdが長くなりすぎた
記事が増えるにつれて、CLAUDE.mdも長くなっていった。
ネタ出しのルール。
執筆のルール。
品質チェックのルール。
投稿のルール。
DB登録の手順。
全部が1つのファイルに混在していた。
ある日、長くなったCLAUDE.mdを上からスクロールしながら気づいた。
「ネタを出すとき」と「記事を書くとき」では、必要なルールが違う。
ネタ出しのときに、執筆の文字数ルールは要らない。
記事を書くときに、DB登録の手順は要らない。
でも全部が1つのファイルに入っているから、Claudeは毎回全部を読む。
そして毎回、関係のない情報も一緒に処理している。
これは無駄だ、と思った。
必要なルールだけを渡せれば、AIはもっと動きやすくなる。
サブエージェントという考え方を知った
調べていると、サブエージェントという言葉が出てきた。
メインのAIが、別のAIに仕事を渡す仕組みだ。
それぞれのAIに、専用の役割と専用のルールを渡せる。
これだ、と思った。
そのままサブエージェントを使えばいいのかと思った。
でも調べていくと、
Proプランでは思ったように動かないかもしれない、
という話も出てきた。
そこで一度止まった。
ただ、機能として使えなくても、
考え方は使えると思った。
仕組みが使えなくても、考え方は借りられる。
そのまま使うのではなく、考え方だけを借りた
サブエージェントの機能は使わないことにした。
でも、役割を分けるという発想だけは使った。
ネタを出すAI社員には、ネタ出し専用のルールだけを渡す。
記事を書くAI社員には、執筆専用のルールだけを渡す。
それぞれに専用のファイルを作れば、CLAUDE.mdを分けられる。
機能としてのサブエージェントではなく、
設計としての役割分割だ。
どのAI社員を呼ぶかは、CLAUDE.mdに一行だけ書けばいい。
「ライターのルールはwriter/__init__.mdを読め」
それだけで済む。
設計の考え方は、機能がなくても使える。
これ、学校で学んだオブジェクト指向じゃないか
役割ごとに分ける。
ライターには、書くためのルールだけを渡す。
リサーチャーには、調べるためのルールだけを渡す。
編集長には、企画と判断のルールだけを渡す。
待てよ、と思った。
これ、学校で学んだオブジェクト指向じゃないか。
1つの巨大なファイルに全部書くのではなく、
役割ごとに設計図を分ける。
JavaやUMLで聞いた話が、
急にブログ運営の中でつながった。
学校で学んだJavaとUMLが、
ようやく使える言葉になった瞬間だった。
学校で習ったことは、使える場所が来るまで待っていた。
最初に、ライターエージェントを分けた
最初に分けたのは、ライターだった。
`writer/__init__.md` というファイルを作った。
書くためのルールだけを入れた。
文体。文字数。ブレイク文の使い方。内部リンクの扱い方。
それ以外は入れなかった。
CLAUDE.mdには「ライターのルールはwriter/__init__.mdを読め」とだけ書いた。
動いた。
CLAUDE.mdが、少し軽くなった。
その後、リサーチャーを分けた。
編集長を分けた。
コンテンツマネージャーを分けた。
分けるたびに、それぞれのAI社員が迷わなくなった。
AI社員を雇うというのは、
派手な機能を使うことではなかった。
役割ごとに、設計図を分けることだった。
最初は全部CLAUDE.mdに書いていた。
でも、全部を1つに入れると、AIも人間も迷う。
だから分けた。
書く人には、書くためのルールだけを渡す。
それだけで、ブログ運営は少し静かになった。
設計は、重ねるほど静かになる。
S0シリーズの最初の記事はこちら。
→ AIでブログを書く前に、ブログ設計図を作ろう。初心者のためのAI編集部入門
このブログがHTMLファイルから始まった経緯はこちら。
→ 最初はHTMLファイルだった。AIブログ運営が会社になるまでの話
記事リストをDBにしてリサーチャーが生まれた話はこちら。
→ 記事リスト.txtをClaudeに読ませたら、AIリサーチャーが生まれた
設計が育つと、そこに役割が生まれる。
コメント