マルチエージェントの作業が長い

Date2026/09/17
Last Modified2026/09/17

概要

これまで単体のエージェント（Codex）に作業させていた時は、かなり大きな作業をさせても30分程度に収まっていた。
しかし、サブエージェント構成を導入してからは小さな修正でも20~30分程度、大きな修正だと1時間以上を超えてくることも珍しくなくなった。
最初は丁寧にやっているのかと思ったが、さすがに時間が長すぎるのでログを取らせてみたところ、処理がスタックしたり手戻りが発生しまくっていることが判明。
それでも、品質が向上しているのは間違いないので、サブエージェントをハーネスする方法を探している。

現在の構成

親エージェント
├ 作業者(worker / テスト以外の実装)
├ テスト作成担当(test_writer / テストをwriteする)
├ テストレビュー(test_reviewer / read-onlyでテストと仕様をレビュー)
└ 画面構成レビュー(QA / playwright+スクショでレビュー)

まずはプロンプトを親エージェントが受け取り、作業内容をまとめてtest_writerへコンテキストを渡す。
作業が完了したら親エージェントへ戻し、また親エージェントは次の担当へとコンテキストを渡す……というのをループさせる。

この構成の狙いは、一つのエージェントが都合の良い解釈で完了させないよう、独立した各視点をもつエージェントによって相互に成果を評価することにある。
作業者とテストのレビュアーを分けることによって「テスト通過のためのテスト」などを書くことを防止したり、QAを置くことによって副作用的なデザインの崩れも防止できるようにしている。

ハーネスのための格闘を残しておく

ここからは、発生した色々なスタック要因と対処の記録を書き残していく。

ドキュメント更新による手戻り

内容

AGENTS.mdにて、コードを更新した後は最後に必ずドキュメントも整備するという形で規定していた。
しかし、トリガーが正しく設定されておらず、

サブエージェントからの完了報告 -> ドキュメント更新 -> サブエージェントへ依頼
という流れになってしまい、何度もドキュメントを更新するという手戻りが発生していた。

対策

ドキュメント更新は全ての作業が終了した後に行う。最もシンプルな例。

環境障害が起きたことを報告していない

内容

サブエージェントにて、Docker Engine未起動や、ブロックされた操作によって未完了のタスクがあったが、それをエスカレーションしていなかった。
それにより、他のサブエージェントも同じ問題でスタックするし、繰り返し「今回は起動していないかな」と自己完結でチェックするため、毎回失敗して2~3分の時間を無駄にしていた。

対策

各視点を独立させるために、渡すコンテキストを絞りすぎていたのが原因。
エージェント間のコンテキストのやりとりにおいて、環境情報の共有は必ず行うようにした。
さらに、作業開始時点で親エージェントが作業環境を予め確認する、というルールを作って初動を整えた。

作業後のフィードバックが不十分で、改善策が微妙

内容

作業に1hなどかかったときに「今回の作業をフィードバックして、次の作業を改善策をまとめてほしい」と依頼したが、そこで出力されたのは"予測"が結構含まれていた。
なぜかというと、作業結果の要約は保持しているが「どの作業の何が原因でスタックし、実際に何分かかった」という詳細情報が失われているからだった。
あと、メインエージェントに知識が統合されるからか、どのサブエージェントが何をしたかについてもかなり曖昧になるようだった。そのため、作業後の自己フィードバックによる改善案の提案は限界があり、効果が薄そうだと思った。

対策

作業中に、１つ１つのサブエージェントが作業ログを取るようにした。これにより各視点から見えた世界が記録されて、情報の密度がアップ。
また指摘を受けて「run_id」や時間の実測値も詳細に盛り込むようにした結果、どの処理がどういう経路で繋がって止まったか、という流れが見えてきた。
これをもとに、客観的な視点のためChatGPTなどに投げてみて、そこから導き出される対策を１つずつ盛り込んでいっている。
おかげで、作業が止まっているというログを見ることが減ってきた気がする。

見る範囲を狭めたら改修範囲の視野も狭くなった

内容

必要以上のコンテキストを渡さずに、与えられた影響範囲のみについて実装やテストを行う形にしていたが、「波及先」という概念が欠けていた。
特に画面のレビュアーにおいて、改修対象の画面のスタイルを修正した場合、複数の画面に影響する変更だったにもかかわらず、当該画面だけのテストになっていたりした。
これは親エージェントが全体テストなどを行いレビューしたときに判明し、再度指摘された画面の確認などを行っていたので、結果的には全体がテストされていたのだが、1回の修正につき波及先を考慮していないことによって+1回分余計な手戻りが発生していることが発覚した。

対策

最初に影響範囲について測定し、ロードマップ的なものを作成することによって大きく作業が逸脱することが減った。
例えば文字の置換などを行うと他の画面に影響することがあるが、最初に影響範囲を

タイムアウトが厳しすぎて、成功するはずの作業をタイムアウト判定していた

内容

テストの実行リミットを120秒にしていたが「120秒でタイムアウトして180秒に差し替えてみたら成功した」というログを発見した。
具体的な理由がなく120秒だったので、見直す必要があった。

対策

まずは実測値をもとにリミットを決めるべき。そのために全体テスト等の共通事項については履歴を取って予測値の精度を高める。
また、テスト中の死活判定が可能なのであれば、タイムアウト以外の判定軸でもルールが決められる。

全体テストが早すぎて、不用意に重いテストを実行しすぎていた