9月29日、SohiniとManish Kumar Jhaらが「Engineering Multi-Agent AI Teams That Build and Test Themselves」と題した記事を公開した。並列動作する専門エージェントが「それぞれは正しくても、組み合わせると成立しない設計」を生み出す——この構造的な矛盾をどう検出し、全体を再実行せずに修正するか。Salesforce Marketing Cloudチームが構築した「Agent Designer」は、その問いへの実装上の回答だ。マルチエージェントAIチームの設計・テスト・自己修復を自動化するアーキテクチャについて詳しく紹介されている。
背景：マルチエージェント開発の「手作業地獄」
マルチエージェントAIチームを手作業で構築するには、YAMLファイル、プロンプト、プロファイル、ツール、モデル、予算、ターン数制限を定義し、テストし、各エージェントの出力を検査し、失敗を診断し、設定を修正してまた実行する——という繰り返しが必要だった。このサイクルに要する時間は2〜4時間。エンジニアは本来解くべき問題ではなく、エージェントチームの組み立て作業に時間を奪われていた。
Salesforce Marketing Cloudのチームはこの問題に対し、Agent Designerを開発した。エンジニアの初期リクエストから最終承認まで、その間の作業を自動化するシステムだ。目標は処理時間を15〜30分に短縮すること。Marketing Cloud内の約200人のエンジニアが「manager-of-agentsモデル」——複数の専門エージェントをオーケストレーターが統括し、各エージェントの出力を統合・調停する構成——への移行を始める契機になったという。なお、Salesforceが提供するAgentforceプラットフォームや、LangChainなどのマルチエージェントフレームワークでも同様のオーケストレーション思想が採用されており、本記事の知見はそれらの設計にも通じる。
並列分析が生む「見えない設計矛盾」
Agent Designerの最も注目すべき設計判断のひとつが、並列実行する専門エージェントの出力統合だ。
このシステムはオーケストレーターと7つの専門エージェントで構成される。アーキテクチャ分析、障害モード分析、コンプライアンス分析の3エージェントは互いの出力を参照せず独立して動作する。その結果、それぞれは正しくても、組み合わせると成立しない設計が生まれることがある。
具体例として記事では次のケースを挙げる：アーキテクチャ担当が選んだトポロジーをコンプライアンス担当が「予算超過」と判断し、障害モード担当が「信頼性要件を満たすには役割分担を変える必要がある」と結論付ける——3者の矛盾は統合フェーズまで表面化しない。
オーケストレーターはこれを検出し、全体を再実行するのではなく「bounded remediation（限定修正）」で矛盾を解消して一つの実行可能な設計に統合する。その後、エンジニアに提示し、ファイル生成を承認するかどうかの判断を求める。この「矛盾の検出→限定修正→人間による承認」という流れは、全体再実行に比べて処理コストと待ち時間を大幅に削減する設計上の核心だ。
検証エージェント自体が間違える問題
エージェントに検証作業を委ねると、「検証者自身が間違える」という問題が生じる。寛容すぎれば本物の違反を通し、厳格すぎれば正常な設計を落とす。
この問題に対してチームが取った手法は2つだ。
① 構造化された出力フォーマットの強制：各検証エージェントは自由形式の説明ではなく、PASS・WARN・FAILのブロックで結果を返す。オーケストレーターはこれをパースして機械的に判断できる。
② メタチェックの実装：複数の検証エージェントの出力を横断的に照合する。各エージェントが自身のコントラクトを満たしているか、エージェント間の結論が一致しているか、提案された設計と整合しているかを確認する。
「不確実な場合はFAILではなくWARNを返す」「Tier 4の設計をbypassPermissionsの使用だけを理由にFAILしない」といったルールも明示的に組み込まれており、モデルの判断に任せるのではなくルールとして強制している。出力フォーマットを機械可読な形に固定することで、検証結果の曖昧さを排除する——この手法はマルチエージェント設計において広く応用できるパターンだ。
自己修復ループの暴走を止める
自律的な修復ループは、根本原因の診断を誤ると修正のたびに問題を悪化させる可能性がある。
Agent Designerの「test doctor」は障害を以下の7カテゴリに分類する：違反、パーミッションブロック、ツールエラー、起動エラー、ソフトフェイラー、無限ループ、状態破損。多くは明確なシグナルを持つが、ソフトフェイラー（正常に実行されるが誤った結果を返す）の検出には期待される動作との点対点比較が必要になる。
診断の不確実性に対する回答は「修復を賢くする」ではなく「停止条件を明確にする」だった：
- 修復試行は最大2回
- 支出上限は3ドル
この制限を超えた場合、Agent Designerは修復を続けるのではなくエスカレーションする。修復能力を高める方向ではなく、停止基準を先に固める——この設計思想は、自律システムの信頼性設計における実践的な教訓として汎用性が高い。
書き込みスコープの強制をどう実現したか
エージェント仕様には書き込みスコープを定義するネイティブフィールドが存在しなかった。チームはこれをモデルの判断に委ねるのではなく、各エージェントのプロンプト内に書き込み境界を明示的に記述することで強制した。
「This created a deterministic boundary around decisions that could not be left to the model」
——モデルに任せてはいけない決定に対して、決定論的な境界を作る。これはマルチエージェントシステム設計における実践的な教訓として記事の中で最も汎用性が高い知見だ。プロンプトエンジニアリングをセキュリティ境界の手段として使うというアプローチは、フレームワーク側の機能整備が追いつかない現状においての現実的な解法といえる。
設計の本質：エンジニアを「コントロールポイント」に集中させる
Agent Designerはエンジニアをループから外すシステムではなく、「アーキテクチャの承認」「検証結果のレビュー」「自律修復の停止判断」というコントロールポイントに集中させるシステムとして設計されている。自動化の範囲を広げながら、判断責任の所在をエンジニア側に明示的に残す——この設計方針は、マルチエージェントシステムの実運用において欠かせない視点だ。並列エージェントの矛盾検出から自己修復の停止条件まで、各機能はその方針に沿って一貫して構成されている。
詳細はEngineering Multi-Agent AI Teams That Build and Test Themselvesを参照していただきたい。
