ブログ運営をAIエージェントに分担させると、最初は楽になる。
役割を分けたのに、なぜかまた重くなってきた。
前の記事「ブログ運営に役職を作った。編集長・ライター・リサーチャーで記事を書く」でエージェントに役職を与えた。
編集長、ライター、リサーチャー。
それぞれに担当を決めて、専用のファイルを作った。
しばらくはうまく動いていた。
でも、仕事から帰ってPCを開いたら、CLAUDE.md が125行になっていた。
各エージェントの workflow.md も、気づいたら膨らんでいた。
「役割は分けた。でも中身は分けていなかった。」
これが今回やったことの核心だ。
役職を作ったら、役職の中身が膨らんだ
エージェントに役職を作った直後は、すっきりしていた。
「ライターは書く」「リサーチャーは調べる」「編集長は判断する」。
役割の境界線を引けた。指示もシンプルになった。
でも2週間後、CLAUDE.md を開いたら125行になっていた。
最初は51行だったファイルが、2倍以上に膨らんでいた。
原因はすぐわかった。
各エージェントの workflow.md にも、どんどん手順が追加されていた。
「競合分析はこう進める」「SEOレビューはここを見る」「差し戻しの基準はこれ」。
役職のなかに、手順がどんどん混じっていた。
役職（クラス）を作ったら、次はその中の手順（メソッド）が育ち始めた。
でもクラスのなかにメソッドを全部詰め込んでいた。
これが太る原因だった。
担当が重くなるのは、仕事が増えたからじゃない。
手順を役職ファイルに混ぜ続けたから。
何でもできる担当は、結局何も速くならない
ライターのファイルを開いたとき、気づいたことがある。
「競合分析の方法」も「SEOレビューの基準」も書いてあった。
「書くだけの人」のはずが、知識のストレージになっていた。
これは人間の現場でも起きることだ。
何でもできる優秀な担当者は、最初は重宝される。
でも仕事が増えるにつれ、何をしているのかわからなくなる。
AIエージェントも同じだった。
ひとつのファイルに「書き方」「調べ方」「判断の基準」が全部ある。
起動するたびに全部読み込む。
不要な情報まで処理して、本来の仕事が遅くなる。
専門家を作るとはそういうことだ。
「何ができるか」じゃなく「何をやらないか」を決める。
役職を作ったときと同じ発想が、手順にも必要だった。
何でもできる担当は、何でも遅くなる。
ブログ運営の手順を methods/ フォルダに切り出す
解決策は単純だった。
手順を、別のファイルに分ける。
役職ファイル（__init__.md）には「この人は何をする人か」だけを書く。
手順（どうやるか）は methods/ フォルダの中に、別ファイルとして置く。
プログラミングに例えると、こういうことだ。
クラスの定義と、メソッドの実装を分ける発想に近い。
役職ファイルがクラス定義で、methods/ フォルダがメソッドの置き場。
呼ばれたときだけ、必要なファイルを読み込む。
普段は読まない。指示されたときだけ参照する。
これで役職ファイルがスリムになる。
各エージェントのフォルダに methods/ ディレクトリを作った。
そこに手順書を置いていく。
ファイル名がそのままメソッド名になる。
役職は「何をする人か」。methods/ は「どうやるか」。
この2層に分けることで、ファイルが太らなくなる。
researcher と content_manager に methods/ を作った
実際に作ったのは3つのファイルだ。
researcher には：
- methods/gap_analysis.md（競合との差分を分析する手順）
- methods/competitive_analysis.md（競合記事を調べる手順）
content_manager には：
- methods/chatgpt_seo_review.md（ChatGPTにSEOレビューを依頼する手順）
どれも「今まで workflow.md に書いていたこと」を切り出したものだ。
手順が変わっても、workflow.md には触らなくていい。
methods/ のファイルだけ更新すればいい。
変化はすぐ感じた。
researcher の workflow.md が短くなった。
content_manager の起動指示がシンプルになった。
「このメソッドを使って」という一言で動くようになった。
ライターからは、競合分析とSEOレビューを外した。
「書くだけ」に絞ったら、指示がさらに短くなった。
手順はファイルに分けるほど、扱いやすくなる。
writer が「書くだけ」になった
ライターに「何をやらないか」を改めて定義した。
競合分析は researcher がやる。
SEOレビューは content_manager がやる。
構成案は henshucho（編集長）が作る。
俺がライターにする指示は、発注書を渡すだけになった。
「この発注書どおりに書いて」。それだけ。
以前は「競合との差別化を意識しながら、かつSEOも考えて、ブランドも守って書いて」と伝えていた。
全部曖昧だった。指示が複雑なほど、出力もぼける。
専門家に仕事を頼むとき、手順を一緒に渡す必要はない。
「こういう記事を書いて」だけでいい。
手順は相手のなかに、ファイルとして入っている。
役割を分けた次は、手順を分けた。
そうしたらライターが、ようやく「書くだけ」になった。
専門化の完成形は「それ以外をやらない」こと。
クラスで分けて、次はメソッドで分ける
ブログ運営をAI会社に見立てたとき、最初にやるのは「誰が何をするか」の定義だ。
これが、前の記事で扱ったクラス設計である。
でも役職を作っただけでは足りない。
「どうやるか」の手順が育ち始めたら、それもファイルに分ける。
これがメソッド設計（今回）。
設計は「分ける」の繰り返しだ。
役割を分けたら、手順が育つ。
手順が育ったら、また分ける。
俺の CLAUDE.md が125行から51行に戻った。
各エージェントの workflow.md がスリムになった。
methods/ フォルダに、手順の設計図が増えていった。
次は「記事を書く前に設計書を作る。AIにいきなり本文を書かせない理由」の話をする。
設計書とはつまり、ひとつの記事に対するメソッドだ。
分けるたびに、設計は深くなる。
コメント