← ブログに戻る
AI・開発

フィードバックループによるエージェント・オーケストレーション：開発者が痛い目で学んでいること

適切なフィードバックなしに、マルチエージェントシステムはエラーを17倍に増幅させます。RedditのビルダーやSpotify Engineering、Anthropicの研究が明かす、オーケストレーションされたエージェントを本番環境で実際に機能させる方法とは。

Jordan Reeves

デベロッパーエクスペリエンスリード

2026年3月15日 14分で読める

Gartnerは、2024年第1四半期から2026年第2四半期にかけて、エンタープライズにおけるマルチエージェントへの問い合わせが1,445%急増したことを記録しました。ほぼすべての真剣なAIチームが、今やオーケストレーションされたエージェントで構築しています。そしてほぼすべての真剣なAIチームが同じ壁にぶつかっています。デモでは機能するエージェントが本番環境で失敗する。モデルが悪いからではなく、調整レイヤーにフィードバックがないからです。

この記事は、Spotify Engineeringのバックグラウンドコーディングエージェントに関するパブリックポストモーテム、Anthropicのマルチエージェント研究論文、Google ADKの8つの本番パターン、そしてr/AI_Agentsとr/LocalLLaMAからの開発者の生の声に基づいています。すべてのソースで浮かび上がるパターンは同じです：フィードバックループこそが製品であり、エージェントではない。

なぜマルチエージェントシステムはフィードバックなしに失敗するのか

調整インフラなしにシステムにエージェントを追加しても、結果は改善されません。むしろ悪化します。Towards Data Scienceで発表された研究がこれを定量化しています：調整されていない「エージェントの袋」システムは、個々のエージェントの約17倍の速度でエラーを増幅させます。各エージェントのミスは相殺されるのではなく、伝播して複合化していきます。

マルチエージェントシステムにおけるエラー増幅と調整品質の関係

数学は残酷です。ステップごとの成功率が99%の10ステップのエージェントプロセスは、エンドツーエンドの成功率が90.4%にすぎません。本番システムは99.9%以上が必要です。この数字の差がエンジニアリング上の問題であり、プロンプトを改善するだけでは解決できません。

コミュニティから、ある開発者の観察が複数のスレッドで広く引用されました：

「フレームワークはハッピーパスを処理する。悲しいパスは常に独自実装だ。」— r/AI_Agentsの開発者

これはフレームワークへの不満ではありません。根本的なアーキテクチャ上の現実です：すべてのエージェントオーケストレーションシステムには、カスタムの障害処理、リトライロジック、サーキットブレーカー、部分的な障害からの回復が必要です。どのフレームワークもこれをあなたの代わりに提供してくれません。

ハブアンドスポークパターン：本番システムの80%が使うもの

すべての主要なオーケストレーションアプローチをテストした後、この分野は信頼性を持ってスケールする1つのパターンに収束しました：中央オーケストレーターが2〜4人のスペシャリストワーカーを管理し、ワーカーは直接互いに通信するのではなくオーケストレーターにレポートします。

ハブアンドスポークエージェントオーケストレーションパターン

Google ADKのドキュメントには8つの本番オーケストレーションパターンが記述されています。Coordinator/Dispatcherが最も一般的ですが、現実のシステムはほぼ常に少なくとももう1つと組み合わせます。通常は品質管理のためのGenerator/Criticループです。Anthropicの内部研究システムがこれをどのように実装しているかを示します：

  • リードオーケストレーターがクエリを分解し、3〜5つのサブエージェントを並行して生成する
  • 各サブエージェントが特定の研究スライスを処理し、構造化された結果を返す
  • オーケストレーターが発見事項を統合し、出力を表示する前にクリティックパスを実行する
  • 結果：内部評価でシングルエージェント比90.2%のパフォーマンス向上、タスク完了時間の40%削減

Cursorのアーキテクチャは3つの役割を明示的に名付けています：プランナーがコードベースを探索してタスクを分解し、ワーカーが独立して実行し、ジャッジエージェントが次のサイクルが始まる前に各サイクルが許容可能な出力を生成したかどうかを評価します。

重要なインサイトは、オーケストレーターの仕事は調整と品質管理であり、作業を行うことではないという点です。フィードバックループを閉じた状態に保ちます。

エージェントのフィードバックスタック

Spotify Engineeringのバックグラウンドコーディングエージェント（Honkプロジェクト）に関する投稿は、エージェントが検証なしに実行されるときの3つのエスカレーティングな障害モードを特定しました：

  1. PR生成の失敗 — 軽微で、手動介入が許容可能
  2. CI障害 — 不完全な作業のレビューにエンジニアの時間を浪費する
  3. CIを通過する機能的に誤ったPR — 最も危険で、信頼を損ない本番インシデントのリスクを高める

彼らの解決策は、階層化されたフィードバックスタックでした：コードベースのコンテンツに基づいてトリガーする独立した自動起動型のベリファイア（Mavenベリファイアはpom.xmlの検出時に起動）、エラー出力をregexで解析して関連メッセージを抽出し、エージェントのコンテキストウィンドウに認知的負荷を加えることなくエージェントの進行をゲートします。

Spotifyのレポートからの重要な設計原則：

「エージェントは検証が何をしてどう機能するかを知らない。ただ変更を検証するためにそれを呼び出せること（そして特定のケースでは呼び出さなければならないこと）を知っているだけだ。」— Spotify Engineering

エージェントのフィードバックスタックの層

彼らのLLMジャッジ層はエージェントセッションの約25%に拒否権を行使します。つまり、4回に1回のエージェント実行は、フィードバック層なしには壊れた、またはスコープ外のコードを出荷していたことになります。拒否権は主にスコープクリープで発動します：依頼されていないコードをリファクタリングするエージェント、CIを通過させるためにテストを無効化するエージェント、または宣言されたタスク境界を超えた変更を行うエージェントです。

本番経験から生まれた4層スタック：

  • 層1 — オーケストレーターのガードレール：イテレーション上限、状態の外部化、ハードサーキットブレーカー、ハンドオフスキーマ、信頼度の閾値
  • 層2 — エージェントの自己検証：クリティックエージェント、TDDの合否、証拠バンドル、ツール出力の検査
  • 層3 — CI/自動化検証：ユニットテスト、統合テスト、lint、typecheck、終了コード
  • 層4 — 本番モニタリング：実際のトラフィック、エラーレート、セッションあたりのコスト、LLMの拒否率

状態が最も難しい問題

ルーティングは解決済みの問題です。状態管理こそが本番システムが崩壊する場所です。Builder.ioのエンジニアリングブログから：

「マルチエージェントオーケストレーションで最も難しい問題はルーティングではなく、状態だ。」

開発者スレッドで繰り返し3つの障害モードが現れます：

レース条件

並行エージェントが共有状態に書き込む場合、エラーなしに1つのエージェントが別のエージェントの作業を上書きします。Google ADKの並行ファンアウトパターンは、各ワーカーがユニークな状態キー（決して同じフィールドではない）に書き込むことを要求することでこれに対処します。シンセサイザーエージェントが結果を明示的にマージします。

コンテキストオーバーフロー

シングルエージェントはコンテキストウィンドウが埋まるまで動作します。マルチエージェントシステムはこれに早く到達します。ハンドオフメッセージがすべての前のエージェントからの蓄積されたコンテキストを運ぶからです。コンテキストが少なすぎるとエージェントは作業を繰り返します。多すぎるとトークンコストは各ハンドオフで二乗的にスケールします。あるエージェントが再帰的な自己改善を発見し、サーキットブレーカーなしに独自のプロンプトを最適化するために自分自身を呼び続けたため、1日に$2,000のAPIコストが発生したと報告した開発者もいます。

「50ファーストデーツ」問題

エージェントはセッション間ですべてを忘れます。Steve Yeggeの「Beads」システムは、並行エージェント間でのマージ競合を防ぐためにハッシュベースのIDを使用したgitバックのJSONLメモリでこれに対処します。Addy Osmaniのパターンは、セッション間で持続する発見されたパターン、落とし穴、規則を記録した継続的なハンドブックであるAGENTS.mdファイルを使用します。原則：「各改善が将来の改善を容易にするべき。」

TDDは決定的なフィードバックシグナル

エージェントのループに対する最良のフィードバックシグナルは、曖昧でなく、即時で、クリティカルパスに人間を必要としないものです。テスト駆動開発はまさにこれを提供します。

まず失敗するテストを書きます。エージェントはそれらに対して実装し、実行し、パスするまで自己修正します。解釈は不要です。合格か不合格かが評決です。Colin Eberhardtのflexboxアルゴリズム実験（Scott LogicのブログにPublished）は、このパターンを使用して3時間で800行のコードと350のテストを完了しました。2015年に手動で2週間かかったタスクです。

なぜTDDがエージェントにこれほどうまく機能するかについての彼の観察：

「エディタでどれくらいのコードを書いて、実行せずに正しいと確信できますか？個人的には5行のコードを超えるのは難しいでしょう。」— Colin Eberhardt、Scott Logic

同じ制約がエージェントにも当てはまります。違いは、コードを実行することが彼らにとって安価で速いということです。ボトルネックは、出力が正しいかどうかについて明確なシグナルを持つことです。テストはそのシグナルを提供します。

競合仮説パターン

Claude CodeのAgent Teamsドキュメントからの1つのインサイトは、より広い注目を集める価値があります。複雑な問題をデバッグする場合、順次調査には偏りがあります：1つの仮説が探索されると、その後の調査はそれに固執します。代替案は並行する敵対的調査です：

「5人のエージェントチームメイトを生成して、さまざまな仮説を調査させましょう。科学的な議論のように、彼らがお互いの理論を反証しようとするよう話し合わせます。」— Claude Codeドキュメント

これにより、単一の推論スレッドが支配しないため、より信頼性の高い根本原因の特定が生まれます。各エージェントは独自の証拠を構築します。オーケストレーターは単一の思考の連鎖を拡張するのではなく、競合する結論を評価します。

このパターンの推奨チームサイズ：3〜5エージェント。エージェントが増えると、比例した品質向上なしに調整のオーバーヘッドが増加します。

トークン経済がアーキテクチャを決定する

マルチエージェントシステムにおけるすべてのアーキテクチャ上の決定はコストの決定でもあります。Anthropicのデータは、マルチエージェントシステムがシングルエージェントチャットよりも約15倍多くのトークンを使用することを示しています。5エージェントのCrewAIクルーは、1つのLangChainエージェントよりもタスクあたり約5倍のコストがかかります。

正しい質問は「これを並行化できるか？」ではなく、「品質の向上はトークンコストを正当化するか？」です。

コミュニティの開発者の声はコストの現実について直接的です：

  • ある開発者は、小さなタスクに対する11回の制御されていない改訂サイクルで$4のAPIコストを浪費した
  • 複雑なワークフローのマルチエージェントオーケストレーションはセッションあたり$200に達することがある
  • インフラレベルのセマンティックキャッシング（Redis）は70%のヒット率を達成し、大量処理システムでLLMコストを最大70%削減する

フレームワーク比較からの実践的なガイダンス：トークン使用量はパフォーマンスの分散の80%を説明します。エージェントを追加する前に、各エージェントに渡されるコンテキストを最適化してください。

ループの中ではなく、ループの上に人間を置く

Martin Fowlerのエージェントシステムにおける3つの人間のポジショニングモードの枠組みは、エンジニアリングの努力がどこに向かうべきかについて最も明確な説明です：

  • ループの外に人間を置く（「バイブコーディング」）— 人間が結果を指定し、エージェントが実装する。リスク：コードベースの品質が時間とともに劣化する。
  • ループ内に人間を置く — 人間がすべてのエージェント出力を手動で検査する。問題：エージェントは人間が検査できるよりも速くコードを生成し、ボトルネックを作る。
  • ループの上に人間を置く（推奨） — 人間がハーネスを設計する：仕様、品質ゲート、評価基準。成果物をレビューするのではなく、それらを生成するシステムを改善する。

実践的な意味合い：エンジニアリングの時間は、個々のエージェント出力のレビューではなく、フィードバックインフラに向けるべきです。よく設計されたハーネスは悪い出力を自動的に捕捉します。設計が不十分なハーネスは、あなたが検証レイヤーになることを強います。それはスケールしません。

2026年のフレームワーク選択

コミュニティは有用なヒューリスティックを開発しました：「ループのあるフローチャートのように見えればLangGraph。会話スレッドのように見えればAutoGen。求人票のボードのように見えればCrewAI。」

フレームワーク比較が本番準備状況について明らかにすること：

  • LangGraph — 自己修正を伴うステートフルな循環ワークフローに最適。急な学習曲線。事前の状態スキーマ定義が必要。LangSmithはデバッグを「至るところにprint文」から「失敗したノードをクリック」に変えた。
  • CrewAI — YAMLドリブンワークフローを持つロールベースのチームに最適。ロギングが壊れている（Task内では標準のprint/log関数が機能しない）。クリティックからリサーチャーへのフィードバックループがフレームワークと戦っているように感じることがある。
  • AutoGen — 会話型マルチエージェント問題解決に最適。speaker_selection_method="auto"は予測不可能にエージェントをスキップしたり、明白な理由なしにループを作ったりする。スケールでの会話のデバッグが困難。
  • Claude Code Agent Teams — 並行リサーチ、レビュー、クロスレイヤー機能に最適。実験的だが競合仮説パターンは独自に強力。

プロトコル層が成熟している

オーケストレーションエコシステムが安定するにつれて、追跡する価値のある2つの新興標準があります：

  • MCP（Model Context Protocol） Anthropic製 — エージェントがツールにアクセスする方法を標準化し、統合表面積を削減する
  • A2A（Agent-to-Agent） Google製 — MicrosoftやSalesforceを含む50以上の企業が支持するピアツーピアエージェントコラボレーションプロトコル

これらのプロトコルは、マルチエージェント開発の最も痛い部分の1つ：エージェントとツール間のグルーコードに対処します。成熟するにつれ、より多くのエンジニアリング努力が統合配管ではなくオーケストレーションロジックとフィードバックインフラに向けられます。

最初に何を構築するか

本番環境で実際に機能するものに基づいた実践的な出発点：

  1. シングルエージェントと良いテストから始める。TDDからのフィードバックループは、エージェントを追加するよりも価値があります。「マルチエージェントの問題」のように感じるタスクのほとんどは、検証が不十分なシングルエージェントの問題です。
  2. ワーカーエージェントを追加する前にクリティックエージェントを追加する。出力品質を検証するクリティックは必要なフィードバックシグナルを与えます。2番目のワーカーエージェントは並行性を与えます。品質問題が解決された後にのみ有用です。
  3. フィードバックスタックを層ごとに構築する。層3（CI統合）の前に層2（エージェントの自己検証）を追加します。各層は上の層が見逃したものを捕捉します。前の層が固まる前に本番モニタリングにスキップしないでください。
  4. イテレーションを厳しく制限し、状態を外部化する。すべてのオーケストレーションシステムには最大イテレーション数が必要です。N回のサイクルで問題を解決していないエージェントは、試し続けるのではなくエスカレートするべきです。状態はエージェントのコンテキストウィンドウの外に存在するべきです。
  5. 初日からセッションあたりのコストを追跡する。このメトリクスなしに、オーケストレーションが機能しているか、繰り返しの失敗でトークンを燃焼しているかがわかりません。

結論

2027年までに廃棄されると予測されるエージェント型AIプロジェクトの40%は、モデルが不十分だから失敗するのではありません。調整レイヤーにフィードバックがないから失敗します。エージェントが実行され、出力を生成しますが、その出力が正しかったかどうかを伝えるシステムが存在しません。

機能するマルチエージェントシステムを出荷するチームは、フィードバックインフラを主要なエンジニアリング成果物として扱います。エージェントは二次的です。ループを正しく機能させれば、エージェントは何ができるかであなたを驚かせるでしょう。ループをスキップすれば、エージェントを追加するだけで、すでに壊れているものを増幅させるだけです。

まずハーネスを構築してください。エージェントはあなたに感謝するでしょう。