AIで複数ブログを運用し始めると、次にぶつかるのが「混ざる」という問題だった。
俺は今、ブログを2つ運営している。
ずみログと、このblog-sekkei。
前回、AIエージェントの判断と実行を分けた話を書いた。
今回はその続きで、作業範囲そのものを分けた話だ。
ブログを2つ運用するようになった
ずみログは、生活の中で起きたことを書くブログだ。
投資・家事・家族・疲れ。40代の俺の日常を、脳疲労を減らす目線で書いている。
blog-sekkeiは違う。
AI社員を作り、ブログ運営を会社化していく過程を書くブログだ。
読者は学生で、知りたいのは生活の話じゃない。
どうやって設計したか、どこで詰まったか、だ。
最初は、ずみログ1本だった。
そこにAI社員の仕組みができてきて、その過程自体をもう1つのブログとして書き始めた。
気づいたら、性格の違う2つのブログを、同じAIに任せることになっていた。
俺の中では自然な流れだった。
書いているうちに増えただけだ。
でも、AIの中では自然じゃなかった。
AIには「今どっちのブログか」を区別する仕組みが、最初は何もなかった。
区別する仕組みなし。
でも、AIに両方任せると、ネタも文体も混ざってきた
ずみログは、一人称「俺」・生活実感・脳疲労を減らす話。
blog-sekkeiは、仕組み化・article_state・エージェント設計の説明。
この2つを同じAIに続けて頼むと、境目が崩れてきた。
blog-sekkeiの記事を書いている途中で、帰宅後にパソコンを開いた、という生活描写が混ざりかけたことがある。
blog-sekkeiの読者は学生で、知りたいのは設計の実話だ。
生活場面の描写は、ここでは弱い。
逆に、ずみログの記事を書いているときに、「article_stateを作って発注書にする」という設計の話が漏れそうになったこともある。
ずみログの読者は、仕組みの説明を読みに来ていない。
同じAIが両方の文脈を持ちすぎると、どちらの記事なのか曖昧になる。
これは文章力の問題じゃなかった。
作業範囲を分けていなかったことが原因だった。
原因は、境界線の不在。
だから、clients/フォルダでフォルダごと分けた
対策として、clients/zumin/・clients/blog-sekkei/・clients/note/という構造を作った。
clients/zumin/は、ずみログ用のフォルダだ。
それぞれのフォルダの中に、persona・editorial・drafts・dataを独立して持たせる。
禁止表現・発注書・下書き・DB、どれもクライアントごとに別だ。
zuminのforbidden.mdと、blog-sekkeiのforbidden.mdは、別のファイルだ。
新しいクライアントを追加するときは、clients/_template/というひな形フォルダをコピーする。
ゼロから作らない。
つまり、新しいブログを増やすたびに、毎回ゼロからルールを作らなくていい。
当時はCLAUDE.mdに、CLIENTと媒体と保存先を並べた一覧表を1つ用意した。
zuminはずみログ、blog-sekkeiはブログ設計図、noteはnote、と対応が一目でわかるようにした。
今から同じ考え方で作るなら、CodexではAGENTS.md側にクライアント一覧を残す。
フォルダを分けただけだ。
でも、これが境界線になった。
クライアントごとの、専用フォルダ。
session.mdのCLIENT変数で、今どっちを触っているかを固定した
フォルダを分けても、AIが「今どのクライアントの作業をしているか」を毎回忘れると意味がない。
そこでsession.mdというファイルに、CLIENT = blog-sekkeiと1行だけ書く運用にした。
CLIENT変数は、今どのブログを作業対象にするかを示す目印のようなものだ。
当時はCLAUDE.mdの読み込み順ルールに、これを組み込んだ。
セッションの最初に必ずsession.mdを読む。
そのあと対象クライアントのforbidden.mdとdecision_logを読んでから、作業を始める。
現在のCodex運用では、同じ考え方をAGENTS.mdのクライアントルールとして扱えばよい。
説明はいらない。
CLIENT変数を1つ確認するだけでいい。
session.mdが空欄なら、既定でzuminとして動く、という規定も決めた。
クライアントを切り替え忘れたときに、想定外の場所に書き込まれる事故を防ぐためだ。
これで、AIが今どちらの文脈で動いているかが、毎回確定するようになった。
CLIENT変数1つで、文脈確定。
分けたことで、AIが別ブログの話を混ぜなくなった
clients/フォルダとCLIENT変数を運用し始めてから、blog-sekkeiの記事に生活描写が混ざることはなくなった。
ずみログの記事にarticle_stateの話が漏れることもなくなった。
禁止表現の基準も、ブランドガイドも、クライアントごとに独立している。
だから、同じAIを使っていても、混ざりようがない。
便利さのために全部同じ場所に置くのをやめた。
分けたぶんだけ、迷わなくなった。
迷いの減った分だけ、速さが増えた。
AIに全部任せない仕組みが、ここで一区切りになった
S1-1からここまで、10本書いた。
CLAUDE.mdを止める話から始まり、役職を作り、メソッドで分けた。
発注書を作り、台帳を作り、投稿を仕組みにした。
目次と内部リンクを整え、判断と実行を分け、作業範囲を分けた。
1本ずつは、目の前の問題を解いただけだった。
並べてみると、全部「AIに全部任せない」という1つの話だったと気づいた。
10本かけてたどり着いた、1つの答え。
これでS1は完走した。
次のシリーズをどうするかは、今は決めない。
S1をひと通り振り返ってから、また考える。
コメント