Articles
Subagentはいつ使うべきか マルチAIレビュー比較のメモ
2026-03-17にXのスレッドとして公開した調査メモの再掲です。以下、スレッドの各投稿をそのまま掲載します。
CodexのSubagentがGAになったので、複数のAI CLIにレビューを委譲するorchestratorとして測ってみた。手元の対象は最近作っている記事作成用のリポジトリで、reviewerとして3つのAIを使う時に、既存のシェルによる並列実行とSubagentからの移譲でどうなるかを見た。結果は、
ある意味当然だがシェルによる並列実行が優位だった。2つの記事を渡して、シェルによる並列実行は約101.7 s、Subagentは約191.5 s。単純に複数のAI CLIへレビューを並列委譲するだけなら、Subagentがそのまま置き換え先になるわけではなさそうだった。
面白かったのは、Subagentの遅さの中身。レビュー処理自体が遅いのか、AIが仕事に着手するまでの待ち時間が遅いのかを分けて見るために、待ち時間を追加で計測した。全体で237,745 msのうち、最も遅いAIは待ち時間93,767 msと実行143,978 msに分かれた。
この時、3レビュアークリティカルパスでは、全体237.7 sのうち約93.8 sが待ち時間、約144.0 sがレビュー実行だった。つまり遅延の内訳は待ち時間39% / レビュー実行61%くらい。Subagentの遅さはレビュー本体だけではなく、着手待ちもかなり大きい。
もちろん、この比較実験はSubagentの強みを最大限に使う課題設定ではない。見ていたのは「既存の複数のAI CLIへのレビュー委譲をどう並列実行するか」であって、複雑な分岐や多段の判断フローはあまり使っていない。だから結論は「Subagentは不要」ではなく、「Subagentとは別にシェルによる並列実行も依然として重要」になる。
今の使い分けはこう見る。定常運用で複数のレビュー委譲を速く回したいならシェルによる並列実行。Subagentなしでも、記事作成AIとレビューAIを分けて同時に走らせるユースケースは十分成立する。一方でSubagentは、失敗したレビューの切り分けや再試行前提の運用、レビュー前後の分岐のような、高制御なorchestratorとしてかなり扱いやすい。置き換え先というより、役割が違う道具として見るのがよさそう。