はじめに
0。
これが今回の数字です。何のゼロかというと、このシリーズでこれまでに書いてきた自分のZenn/Qiita自動投稿パイプラインの運用障害・設計ミスの記事11本のうち、「複数のAIエージェントを協調させる仕組みがあれば防げていた」ものの数です。
今週、業界ニュースを眺めていたら、OpenAIが企業向けに複数のエージェントを協調させて業務を進めるプラットフォーム「Agent Workspace」のパブリックベータを出したという記事や、Salesforce/Anthropicが「Claudeforce」という提携を発表した記事、Accenture/Google Cloudが大規模なエージェント導入支援組織を立ち上げたという記事が、同じ時期に立て続けに出てきました（いずれも業界ニュースサイト経由の情報で、各社の一次リリースまでは確認していません。後で自己批判として触れます）。「複数のエージェントを協調させる」ことがエンタープライズAIの合言葉になりつつある、という空気を感じたので、自分の運用実績と照らし合わせてみることにしました。
TL;DR
- 業界ニュース経由で、OpenAI「Agent Workspace」（複数エージェント協調基盤のパブリックベータ）、Salesforce×Anthropic「Claudeforce」、Accenture×Google Cloudのエージェント導入支援組織といった発表が、2026年9月上旬に立て続けに出ていることを確認（一次ソース未確認）
- 自分のZenn/Qiita自動投稿パイプラインについて、これまで書いた運用系の記事12本（うち障害・設計ミスを扱ったもの11本、安定運用の検証記事1本）を洗い出し、障害11本それぞれの根本原因を数え直した
- 障害11本のうち、根本原因が「エージェントの数が足りなかったこと」「複数エージェントの協調が必要だったこと」に該当するものは0本。すべてAPIのレート制限仕様、状態管理（idの未確定・部分成功の見落とし）、命名衝突（スラッグ重複）、実行前チェックの欠如のいずれかだった
- むしろ複数エージェントを同時に走らせていた場合に悪化しうる障害（同時push、id競合）が実際に含まれていた
実際に起きたこと
運用系の記事12本を、タイトルと本文の「原因」記述に戻って読み直し、根本原因を分類しました。
| 記事 | 根本原因の分類 | 複数エージェント化で防げたか |
|---|---|---|
| GitHub Actionsが12分13秒で9回失敗した日 | qiita-cliが既存記事を「更新済み」と誤判定＋ワークフローの設計ミス | いいえ（単一エージェントの設計問題） |
| この48時間、Qiitaへの自動投稿は13回試みて成功は1回だけだった | Qiita側のレート制限（外部API仕様） | いいえ（外部APIの制約） |
| 「4時間52分」の次に13時間12分空けても解除されなかった | レート制限解除の条件を誤解していた | いいえ（仕様理解の誤り） |
| 「時間を空ければ解除される」と思っていたら5時間空けても解除されなかった | 同上、時間経過だけを解除条件とする思い込み | いいえ（仕様理解の誤り） |
| 3日前も今日も待ち時間は同じだったのに結果が分かれた | レート制限解除条件が時間以外の要因に依存（未特定） | いいえ（原因未特定だが協調とは無関係） |
| レート制限解除と書いた4分20秒後にまた失敗した | 一時的な解消を恒久解消と誤認 | いいえ（判断ミス） |
| 2本まとめて投稿したら1本成功でも「失敗」ログしか残らなかった | 部分成功が失敗として記録されるログ設計 | いいえ、むしろ同時実行が原因の一端 |
| GitHubへのpushは11回成功もZennで7日間非公開だった | Zenn側のスラッグ重複によるデプロイブロック | いいえ（命名衝突） |
| Qiitaのレート制限失敗が18時間19分id:nullで放置された | 失敗後の自動リトライ・復旧の仕組みがなかった | いいえ（復旧設計の欠如） |
| 記事を複製していた話（重複記事とレート制限の実験ログ） | 執筆前の既存記事確認を怠った | いいえ（単一エージェントの手順欠如） |
| もう書いていないかを数えさせたら24時間前の自分と鉢合わせした | 同上、執筆前チェック手順を明文化する前の話 | いいえ（同上） |
障害を扱ったのはここまでの11本です。残る1本「また壊れるはずと思っていたら14回連続成功していた」は、障害ではなく安定運用そのものを検証した記事なので、上の集計には含めていません。
自分で見返して意外だったのは、「2本まとめて投稿したら1本は成功していたのに失敗ログしか残らなかった」件です。これは複数の処理が同時に走ったことがきっかけで見えにくくなった障害で、もし本当に複数のエージェントを並行稼働させていたら、同種の「どちらが本当に成功したか分からない」状態がさらに起きやすくなっていたはずです。つまり今回のケースでは、複数エージェント化は解決策どころか、悪化要因になり得る側に入ります。
なぜこうなったか
自分のパイプラインの障害は、振り返ると全部「1つのエージェントが、1つのタスクを、正しい前提条件のもとで実行できているか」の問題でした。Qiita APIのレート制限仕様、Zennのスラッグ重複、部分成功のログ化、id未確定のままの放置——これらはどれも、エージェントの人数を増やしても解決しません。むしろ状態（どの記事がどこまで処理されたか）を複数の実行主体で共有・同期する必要が増える分、競合や二重書き込みのリスクは上がる方向に働きます。
一方で、今週見た業界ニュースが強調していた「複数のエージェントが協調して複雑な業務タスクを遂行する」という価値は、自分のようなタスクとは前提が違うと感じました。あちらは「1つのタスクの中に複数の専門性・複数の権限境界が必要な複雑な業務プロセス」を対象にしています。自分の投稿パイプラインは、逆に「1つの明確なタスクを、決まった手順で、状態を壊さずに実行し続ける」ことが課題であり、これは拙著でいうところのLoop EngineeringとHarness Engineeringの範疇の話で、Orchestration（複数エージェントの指揮）の出番ではありませんでした。
自己批判：この記事について正直に言うと
3つ、正直に書いておきます。
1つ目。「障害11本・安定運用1本」という分類は自分自身の主観的な線引きです。 どこまでを「障害記事」に含めるかは恣意的で、たとえば「複製記事の実験ログ」のように障害と教訓が混ざった記事の扱いは、別の基準で数えれば10本や12本になった可能性があります。
2つ目。OpenAI「Agent Workspace」やSalesforce×Anthropic「Claudeforce」の情報は、業界ニュースサイト経由で確認したもので、各社の一次リリースやドキュメントまでは自分で読みに行っていません。 発表の正確な内容・時期・スコープについては誤りが含まれている可能性があります。
3つ目。自分のパイプライン（3週間・50数回の実行、単一の反復タスク）とエンタープライズの複雑な業務プロセスは、規模も複雑さもまったく別物です。 「自分の場合は複数エージェント化が要らなかった」ことは、「複数エージェント化が一般に過剰である」ことの証明にはなりません。今回言えるのは、あくまで自分の狭い運用範囲での話です。
今日から使えること
- 「複数エージェント化」を検討する前に、自分の過去の障害ログを実際に数え直す。 根本原因が状態管理・外部APIの制約・命名衝突なら、エージェントを増やしても解決しません。まず直すべきは単一エージェントの手順とチェックの設計です。
- 新しいオーケストレーション基盤を導入するかどうかは、「自分の過去のインシデントのうち何件がこれで防げたか」という具体的な問いでテストする。 トレンドだから採用するのではなく、自分の実績データに当ててから判断する方が安全です。
- 複数の処理を並行させるほど、状態の競合・部分成功の見落としは増える前提で設計する。 今回のケースのように、並行実行そのものが障害の見えにくさを増やすことがあります。
拙著『AIエージェント設計論 — Harness/Loop EngineeringからRAGまで』でも、Orchestration（複数エージェントの指揮）とLoop/Harness Engineering（単一エージェントの実行を安定させる設計）を別の章に分けて扱っています。今回のように、自分の課題がどちらに属するかを見極めることが、最初の一歩だと考えています。