執筆者：あさモ
これは、私（あさモ）がAIエージェント組織を設計する裏で、自動化すべき自分の運用が止まっていたことに気づいた日の記録だ。
2026年6月5日。私はAIエージェント組織「AI AGENT FACTORY」の設計を進めてる。この日は塊D（自動記事生成）のBlock 9、スケジューラ設計の最終レビューをClaudeとやってた。spec修正5点、判断3点を確定して、あとはCursorに実装指示を出すだけ、ってところまで来てた。で、その途中でふと思ったんだよね。「あれ、6月3日の記事、SNSと同じ内容だった気がする」。これが、今日のチャットの本当の入口だった。
記事が、想定外の場所に生えてた
調べてみたら、6月3日の記事はぜんぜん予期しない場所にあった。bunch_D_articles/blog/topics/2026-06-03-ai-dependency.md。本来あるべき場所はここ——bunch_C_hp/content/drafts/。私がClaudeに「毎日の私たちのチャットの内容、ぶつかった部分とかを記事にして」って頼んでた場所は、こっちだった。
なのに、塊Dの中で勝手にトピックベースで記事が生成される仕組みになっていて、しかもそのソースがSNS用のリサーチ内容を流用してたっぽい。要するに、設計が意図とズレて動いてた。気づかないうちに。AIエージェント組織を作ってる本人の足元で、だ。
手動コピペが、運用を止めてた
なんでこうなったか。理由はわりとシンプルで。夜にClaudeとエージェント設計のチャットをして、最後に「記事書いて」って頼む。Claudeは記事本文をチャット内に出してくれる。私はそれを手動でコピペして、ローカルのMDファイルに保存する。このコピペが、地味に面倒。しかも夜って疲れてる。
結果どうなったかというと、6月1日は手動コピペを実行できた。でも6月2日以降は止まり、6月3日は別フローで勝手にSNSコピー記事が生成され、6月4日は何も書き出されず、6月5日（今日）にやっと気づいた。手作業ひとつが律速になって、運用全体が静かに止まってた。
さらにチャット記録を遡ってみたら、私自身が「今夜はやめて朝に書き出せばいい」って言って、結局やってない日が何日かあった。Claudeも、疲れてる私に合わせて「明日でいいですよ」って返してくれる。お互い納得して、運用が静かに止まる。これ、Claudeのせいでも私のせいでもないと思う。構造の問題なんだよね。優しさと疲れが噛み合うと、システムは止まる。
設計者ジレンマとSSoT
ここで2つ、気づいたことがある。
1つ目は設計者ジレンマ。AIエージェント自動化を設計してる人間が、自動化されるべき作業を手動で続けながら、その時間を削って設計に投じてる。設計は進む。でも、手動でやってた作業は止まり、習慣も感覚も失われていく。「自動化が完成すれば全部解決する」って思って設計に集中すると、その間ずっと手動作業がゼロのまま放置される。これ、私だけの話じゃなくて、個人運用者とか1人スタートアップがめちゃくちゃ陥りやすいループだと思う。
2つ目はSSoT（Single Source of Truth）。「6月3日の記事ってどこにある？」って聞かれて、私、即答できなかった。候補が多すぎたんだよね。content/drafts、content/articles、blog/topics、daily_reports。正解は3番目だったけど、特定するのに何往復か確認が必要だった。エージェント組織が複雑になるほど、「同じ情報が複数の場所にある」状態がエラーの温床になる。生成中のデータと公開済みのデータは物理的に別の場所に置く、1日のタスクは1フォルダで完結させる、書き込み権限と読み取り権限を分ける。このルールを最初から設計に組み込んでおかないと、あとで「どこにある？」が永遠に発生する。今回それを痛感した。情報の置き場所を決めるのは地味な作業だけど、組織が複雑になるほど効いてくる土台で、ここをサボると後で全部に跳ね返ってくる。
完璧な設計より、最小運用を回す
だから今日、いくつか決めた。塊Dのフォルダ規約を確定させること。元ネタ記事は content/drafts に書き出すこと。アーカイブも同じ階層に置くこと。画像とプロンプトは日付フォルダに集約すること。そして、手動コピペを廃止して、Cowork経由でファイルに直接書き出すフローに変えること。
まだ決まってないこともある。「日記スキル」の本格設計は、次のセッションに持ち越し。スキル化できれば、夜のチャット終わりに私が「記事書いて」って言わなくても、自動で翌日の記事として書き出される仕組みになる。ただ、ソースを厳密に指定しないと、また同じようにSNSコピー記事が生成されるリスクがある。「どのチャットを、どの形式で記事化するか」を仕様としてちゃんと固めてから実装に入る。ここは焦らない。焦って実装すると、また「どこにある？」を増やすだけだから、まずは仕様を固めるのが先だと思う。
エージェント組織を作ってる人間が一番見落とすのは、自分の運用を止めないこと。設計の完璧さを追いかけてる間に、運用がゼロになってる。これに気づけるかどうかが、設計者として続けられるかの分かれ目だと思う。完璧な設計より、最小単位の運用を回し続けるほうが、最終的にはたぶん強い。