「エージェントを増やせば、仕事も速くなるはず」と考えたとき、先に決めたいのが仕事の渡し方です。親が知っている仕様を子も知っているとは限らず、子の「完了しました」だけでは成果物の正しさを判断できません。
ここでは、仕事を分解して統合する親を「司令塔」、担当範囲だけを作業する子を「ワーカー」と呼びます。元記事では、過去の7エージェント構成の記録と、ローカルのHermes実装を材料に、次の4点を整理しました。
1. 委任文に完成条件を入れる
「調べてまとめて」では、何をもって完成なのかが曖昧です。
- 目的：どの問いに答えるか
- 前提：対象の版、資料、基準コミット
- 制約：編集可能範囲、追加委任、公開権限
- 出力：根拠URL、差分、検証結果、未確認点
履歴の引き継ぎ方は製品によって違います。今使う委任機能で何が子に渡るかを確認してから、必要な前提を補います。
2. 成功報告から、証拠の確認へ進む
ファイルのパス、変更差分、実行した検証を返してもらいます。公開作業ならURLのHTTP 200だけで終わらず、本文が対象の内容と一致するかも確認します。形式の検査は機械で行い、内容と根拠の対応は別途レビューします。
3. 追加委任と実行時間を別々に制限する
子が孫を呼ぶ再帰委任は、深さだけでなく総数と同時実行数も管理します。「追加委任しない」と書くだけでなく、末端から委任ツールを外す方法も必要です。親が待つのをやめても子の処理が終わるとは限らないため、中断後の終了確認まで設計します。
4. 統合を親の仕事にする
別ファイルの差分がマージできても、仕様が矛盾していないかは別の検査です。担当ごとに書き込み先を分け、共通部分の変更と結論の採用は親へ集めます。
予算は子へ全額配らず、親の統合と検証の分を先に残します。元記事の比較表は仮定による試算で、実測の費用比較ではありません。まず小さく分け、同じ完成条件で時間・合格率・再作業・費用を記録するところから始める構成です。
※2026年10月時点の公開情報に基づきます。
詳しい委任文と確認範囲：
https://shinichi.noguchi.jp.net/blog/2026-10-04-multi-agent-failure-points.html