制作をChatGPTに移し、書くAIを1つに戻した

9月9日の朝のSNS制作は5099秒・129ターンかかり、9月10日の記事制作は3時間を超えても終わっていませんでした。昨日、僕はそこで逆に、書く担当を減らしました。調査と制作をChatGPTの定期タスクへ移し、記事・日刊・週刊・月刊・SNSを、それぞれ1つのタスクが企画から完成稿まで直接つくる形に変えました。

速くなるか、文章が良くなるかは、まだ分かりません。今日が長文制作の新しい構成での最初の自然実行です。

何を見たのか

もともと引っかかっていたのは、ワンショットで頼むと文章は悪くないのに、スケジュールタスクにすると急に平均的になることでした。

9月10日に僕が立てた仮説は、制作を任せていたサブエージェントが、普段のClaudeで使っている共通メモリや文章のチューニングを引き継いでいないのではないか、というものです。これは僕が自分で仕様まで検証できた事実ではありません。だから「原因が確定した」とは置かず、構成を見直すきっかけになった仮説として扱っています。

一方で、遅さは実際に見えていました。9月9日の朝のSNS制作は5099秒・129ターン。9月10日の記事制作は3時間を超えても未完了でした。旧構成では、複数のサブエージェント、本文やBase64の受け渡し、親側での統合が同時に走っていました。どれが何割悪かったのかは分けて測れていません。

だから、サブエージェントだけを犯人にするのはやめました。代わりに、制作の構造そのものを単純にしました。

試したのは、分業を増やすことではなく境界を減らすこと

昨日決めた新しい構成では、調査と制作はChatGPTの定期タスクが直接やります。記事なら記事、日刊なら日刊、SNSならその枠を、1つのタスクが材料集めから本文、Drive保存まで持ちます。本文を別の子タスクへ渡して書かせません。

その後の審査・配信・実測・日次レポートはローカルのClaude Codeに分けました。書く担当と、出来上がったものを疑って確認する担当は分ける。でも「書いている途中」で担当を増やさない、という形です。ファイルの受け渡しも、モデルが本文やBase64、ハッシュを書き写すのではなく、コードが扱うようにしました。

初日からきれいには動いていません。朝の0700枠では、ChatGPT側の成果物とローカル側の台帳契約が噛み合わず、審査後も6面すべて未送信になりました。本文そのものではなく、制作工程の証跡の形式が配信ゲートを落としていたので、その不整合を直しました。

その後、1800枠は新しい流れで審査を通り、6面すべて配信まで確認できました。少なくとも、構成を変えたあとに「制作→独立審査→配信」まで一本つながるところまでは試せています。

捨てたもの

捨てたのは、親のAIが材料を集めて、複数の子エージェントへ本文を振り、最後にまた親が統合する形です。制作をCowork側に寄せる構成も止めました。

効率を上げるつもりで分けていたけど、僕が欲しいのはAIの人数ではなく、最後に出てくる1本の質です。昨日はそのために、並列化よりも「誰が最後まで書くのか」を固定する方を選びました。

まだ分かっていないこと

一番大事なところは、まだ未計測です。

新しい構成で長文の文章品質が本当に上がるのか。制作時間が短くなるのか。トークン消費が減るのか。特にChatGPT側の使用量は今の取得経路では測れていません。

サブエージェントが共通メモリを引き継がないことが品質低下の主要因だった、という仮説も、今回の変更だけで証明できるわけではありません。もし1タスク1本にしても文章が悪ければ、別の原因が残っています。

今日から、その結果が出始めます。