並列 AI エージェントと人間の脳みそ 1 個問題 — auto-publish を 6 スキルに分けて運用してみた reflection

結論 — 生成帯域は N、レビュー帯域は 1、ここは揃えてはいけない

結論を先に書きます。AI で生成側を並列化しても、人間のレビュー帯域は並列にならないので、auto-publish のような書いて公開するパイプラインは「生成 N、レビュー 1」を前提に設計しないと、すぐに人間がボトルネックになって溜まり続けます。

私が運用している AetherEchoes の auto-publish は、6 つのカテゴリスキル (engineering / ai / design / process / essay / breaking) を launchd で曜日と時刻に振り分けて、Bot API 越しに記事を本番に upsert する作りです。生成側だけ見れば、月 / 火 / 水 / 木 / 金 / 土 / 日 のどこかに常に何かが走っていて、並列化しようと思えば 6 本を同時に叩くこともできます。けれど、私の脳みそは 1 個しかありません。生成を 6 並列にした瞬間に、レビューが 6 倍の負債になって自分に返ってくるだけです。今日はその不一致を 5 月時点の運用でどう吸収しているかを書きます。

pepabo の記事を読んで首を縦に振った理由

2026 年 5 月、Zenn で pepabo の方が書かれた『AI を 5 本同時に走らせても、俺の脳みそは 1 個しかない』という記事を読みました。要旨は、AI エージェントを 5 並列で走らせても、それぞれのアウトプットを評価・統合する人間側の認知帯域は 1 個分しかなく、結局並列度を上げすぎると人間が詰まる、というもの。

私の auto-publish も同じ罠の手前まで来ていて、当初は「生成側を増やせば増やすほど記事が増える」と素朴に考えていました。実際、3 月に launchd の cron を 5 つから 7 つに増やした週があって、その週末の土曜の朝、ドトールで MacBook Air M2 を開いて記事一覧を見たら draft 状態の記事が 4 本溜まっていて、どれから手を付けるか決められなくなりました（味の感想はクロワッサンが少し冷めていた、です。本筋から脱線しますが、レビュー判断は脳が温まっていない時にやると間違えるので、私は朝の温かい飲み物とセットの作業に絞っています）。

この時点で、私の運用は pepabo の方が書かれていたボトルネックそのものに刺さっていたので、4 月にかけて設計を組み直しました。組み直しの判断は 3 つで、次の節からそれぞれを書きます。

並列度を上げない、代わりに時刻を分散させる

結論から書きます。並列度を 1 のまま固定して、代わりに launchd の StartCalendarInterval で時刻だけを分散させるのが、私の今の運用です。

具体的には、月 09

(engineering)、火 09 (design)、水 09 (process)、木 09 (engineering)、金 09 (ai)、土 09 (process)、日 10 (essay)、というように、同じ時刻に 2 つ以上が走らないようにしています。breaking は 0/6/12/18 時 JST の 4 回ですが、breaking は「該当時のみ」スキルなので、Hacker News の score が 300 以上で 12 時間以内、という条件を 4 回中 3 回くらいは満たさずに skip-mode で終わるはず（実際、5 月の集計で 28 回走って 6 回しか書かれていません）。

時刻分散のいい点は、人間が朝コーヒーを淹れる前に draft が 1 本だけ上がっている、という状態を作れることです。1 件ずつ机に乗ってくれば、1 件ずつ片付けられる。3 月の「draft 4 本同時」状態と比べて、認知負荷が体感で 4 倍以上違います（数字の根拠は無いですが、私はそう感じます）。

もう 1 つ良い副作用があって、launchd の log を見れば「今週どのカテゴリがいつ走ったか」が時系列で分かるので、振り返りが楽になりました。並列だと「同時に走った 3 本のうち、どれが失敗したか」を切り分ける手間が増えます。

レビュー帯域 1 を守る 3 つの設計判断

要点を先に書きます。レビュー帯域を 1 のまま守るために、SHARED_LOGIC.md に書いた品質 4 指標と最大 5 回リトライ、そして draft-only 着地点の 3 つを置きました。

1 つ目は品質 4 指標です。auto-publish の /article-write スキルが draft を upsert した直後に、「見出し階層 valid」「本文長 ≥ カテゴリ別下限 (1200〜1800 字)」「references ≥ カテゴリ別下限 (1〜2 件)」「既存記事との Jaccard < カテゴリ別閾値 (0.5 or 0.7)」を機械で判定します。人間の目を介さずに「これは公開してよさそう」を 4/4 で確定するので、私が後でレビューする時の「本文長が足りない」「refs が無い」のような機械的指摘がゼロになります。

2 つ目は最大 5 回リトライです。1 回目で 3/4 だった時、fail した 1 指標を AI が個別修正して再 upsert、というのを最大 5 回回します。「人間が draft を見て『refs 足りないよ』と書き換える」工程を、生成側の自走でゼロにする狙いです。実測で 5 月の 12 本中、2 回目以内で 4/4 揃ったのが 9 本、3 回目で 2 本、5 回目までに揃わなかった 1 本は次の段で扱います。

3 つ目は draft-only 着地点です。5 回試して 4/4 揃わない場合は、publish せずに draft のまま放置して、write.json に status: "draft-only" を書き出して終わります。これは「人間レビューが必要」を機械が宣言してくれる導線で、私が Admin 画面を開いた時に draft のままの記事だけが残っている状態を作る役割を持ちます。レビュー対象が「全 draft」ではなく「5 回試して通らなかった draft」に絞られるので、レビュー帯域 1 を守ったまま、最後の品質ゲートだけ人間に渡せます。

（脱線として書くと、この 3 つの設計は最初から狙って組んだ訳ではなくて、3 月の「draft 4 本同時」事件の後で書いた reflection メモから一段ずつ抽出した代物です。設計はだいたいインシデント駆動で生えてくる、という個人的な感想は強くなりました）

失敗した運用 — 「人間が後で見ればいい」設定

要点を先に書きます。「とりあえず生成しておいて、後で人間が見ればいい」という設定は、過去 2 ヶ月で 2 回試して 2 回とも失敗しました。

1 回目は 2 月、品質 4 指標を入れる前の運用で、毎日 1 本 draft を作って admin の下書き欄に溜める方式を試しました。3 週間で 21 本の draft が溜まって、最後の 1 本を読み終える前に最初の 1 本のトピックが古くなっていた。これは情報の鮮度問題で、技術記事は書いた瞬間が一番価値があるので、レビュー待ちで 2 週間置くと公開する意義が減ります。

2 回目は 4 月、品質 4 指標は入っていたものの、auto-publish 後に「人間がタイトルだけは見て承認したら publish」というワンクッションを置きました。承認待ちが 5 本溜まったところで、私が「タイトルだけ見ても本文の質は分からない」と気付いて、結局全部読み直す羽目になりました。「人間が後で見る」は「人間がいつまで経っても見ない」とほぼ同義だ、という、5 月の私が出した結論です。

今は逆で、品質 4 指標が pass したら問答無用で publish します。人間が事後に「これは取り下げる」と判断する権限だけ残して、事前承認は完全に外しました。事後取り下げは Bot API の /api/v1/bot/posts/{slug}/archive 1 発で済むので、レビュー帯域への負荷は事前承認の 1/10 以下です。これまでに archive した記事はゼロですが、安全弁としての存在価値はあります。

まとめ — 並列は道具、シリアルが設計の中心

要点を先に書きます。並列 AI エージェントは生成側の道具として強力ですが、人間レビュー帯域がシリアル (1) である以上、設計の中心はシリアル側に置くべき、というのが 2026 年 5 月時点の私の見立てです。

私の auto-publish は 6 スキル + launchd の構成だけ見ると「並列っぽい」見た目ですが、実態は 時刻分散による擬似シリアルで、レビュー帯域 1 にきっちり合わせ込んであります。pepabo の記事を読んだ時に「あ、自分はこれを 4 月に踏んで設計し直した側だ」と気付けたので、6 月以降は draft-only 着地点が頻発した時のリトライ戦略（同じトピックを 2 週間後に再挑戦するか、カテゴリ自体を skip するか）を詰めていく予定です。

書きながら、3 月のドトールでクロワッサンを冷ましながら draft 4 本を眺めていた自分に「並列を増やす方向で考えるな、時刻分散で 1 件ずつ机に乗せる方向で考えろ」と伝えに行きたい気持ちが少しあります（タイムマシンが無いので、この記事を未来の私への置き手紙として置いておきます）。