3人のサブエージェントに同じPRを見せたら、4割の指摘で意見が割れた話
マルチエージェントのコードレビューは、ただの上乗せだと思っていました。3人のサブエージェントに同じPRを見せれば、1人分のコストで3倍の目玉。安いものです。
実際にやってみたら、500行のリファクタリングPRに3つのSub-agentを並列で当てた結果、コメントの41%で意見が割れました。15分で終わるつもりだったマージ作業に1時間かかりました。Brooksの法則は2026年でも生きていて、しかもエージェントにまでスケールしているようです。
Anthropicは3月のCode Review発表で、社内利用時に「不正確」と判定された指摘は1%未満だと報告しています。この数字自体は本物です。ただし、これは数ヶ月かけて調整されたパイプラインを自社コードベースで動かした結果の数字でした。同じ手触りを期待して自分のリポジトリで3つのSub-agentを動かしてみたら、「一致」という言葉の意味が私の想像とは違っていました。
本記事はその実験記録です。これは以前書いたClaude CodeのSub-agent設計記事の続編で、設計論ではなく並列稼働させた実測データの話です。
実験の設定
対象は副業プロジェクトのWebRTCシグナリング層をリファクタリングする500行のPRです。8ファイル、ほぼTypeScript、設定ファイルを少しいじり、新しいエラー型が1つ。1人のレビュアーでは何かを見落とす程度には複雑で、いわゆる「実験のための実験」にならない程度の地味さがありました。
3つのSub-agentを .claude/agents/ に定義しました。全部Sonnet 4.6、全部読み取り専用。
---
name: explore-reviewer
description: 呼び出し元、依存先、デッドコードパスを追跡する。
model: sonnet
allowed-tools: Read Grep Glob
---
あなたはコードの考古学者です。変更されたファイルごとに、すべての呼び出し元、
参照するテスト、変更後に静かになるパスを見つけてください。
file:line形式の引用を伴って具体的に報告してください。スタイル論はなし。---
name: security-reviewer
description: 認証、検証、シークレット管理の退行を探す。
model: sonnet
allowed-tools: Read Grep Glob WebSearch
---
あなたはセキュリティレビュアーです。認証フロー、入力検証、シークレット管理、
依存リスクのみを扱ってください。各指摘に推定CVSSを付けてください。
スタイルとアーキテクチャは無視。---
name: plan-architect
description: 既存規約に対する設計判断を評価する。
model: sonnet
allowed-tools: Read Grep Glob
---
あなたはソフトウェアアーキテクトです。PRの設計判断を、このコードベースの
既存規約と比較してください。ドリフト、抜けている境界、次の人が困る抽象化を
指摘してください。各Sub-agentに同じプロンプトを渡しました。「PR #482を1行ずつレビューし、file
」。全員が独立したコンテキストで動き、互いの出力は見ません。最後に統合するのは私だけです。
41%の不一致はこういう形をしていた
3つ全部が終わったとき、生のコメント数は計78件ありました。スプレッドシートを開いて1つずつ「3エージェント全員が指摘」「2/3が指摘」「1/3だけが指摘」とタグ付けしました。
| カバレッジ | 件数 | 比率 |
|---|---|---|
| 全3エージェントが指摘 | 14 | 18% |
| 2/3エージェントが指摘 | 32 | 41% |
| 1/3エージェントだけが指摘 | 32 | 41% |
「1/3だけが指摘」のバケツが、私が不一致と呼んでいる部分です。残り2つのSub-agentは同じ行を、同じツールで、同じ差分の上で見ていました。それでも素通りした。ある指摘が「あるSub-agentの個人的な意見」である確率は41%。これが今日の数字です。
Anthropicの「1%未満」は計測方法が違います。彼らはエンジニアが「修正せずに明示的にcloseした指摘」をカウントしています。私がカウントしているのは「同じコードを見ていた他の2人が言及すらしなかった指摘」です。問いが違うので、答えも違って当然です。そして私の時間を奪うのは後者です。
不一致の4パターン
全件を分類したら、ほぼすべてが4つのパターンに収まりました。
重要度のドリフト。 plan-architectは「null チェックが抜けている」を critical と判定。同じ行をsecurity-reviewerは「low、呼び出し元が既に検証済み」と判定。両方とも、ある意味で正しい。architectは関数を単体で読んでいて、security-reviewerはgrepで呼び出し元を歩いて上流の検証を確認していました。同じ行、正反対の判定。
スコープのドリフト。 「このPRをレビューせよ」と頼んだら、explore-reviewerはPRが触っていない別ファイルの既存バグまで3件報告してきました。plan-architectは差分の外には一切触れません。事前にどちらの挙動になるか分かりません。厳密に言えばどちらの解釈も擁護できます。実用的に言えば、片方がコメント数を爆発させます。
具体性のドリフト。 plan-architectが書いてきたのは「リトライ処理を共通ヘルパーに抽出することを検討してください」。security-reviewerが書いてきたのは「184-201行目を retry(opts, () => fetchToken(opts.url)) に置き換え、30秒の上限を設けてください。さもないと auth-refresh パスがワーカーをハングさせます」。同じアイデア。片方は30秒で適用できて、もう片方は会議を1つ消費します。具体性は私の想像よりずっと大きな分散軸でした。
ツール予算のドリフト。 explore-reviewerは grep と glob を使い、改名された関数がCIスクリプトでまだ参照されていることに気づきました。plan-architectは同じツールを持っていたのに、そこまで見に行かない。同じ allowed-tools、同じ「依存先を探せ」の指示。片方は表面を歩き、片方は建物の中を歩く。ドリフトの正体は、システムプロンプトがどれだけ「徘徊」を奨励しているかでした。
Claude CodeのSub-agent公式ドキュメントを読んでいれば、ここまでは想定内かもしれません。私が驚いたのは、私がタグ付けした不一致のほぼ全部が、この4つに綺麗に収まったことです。
誰も気づかなかったバグ
マージから2日後、同僚が新しいエラーハンドリングパスにレースコンディションを見つけました。PRは1フレーム分の窓を開けていて、同じソケットに2回のreconnectが走り得る状態でした。3つのSub-agent、誰も触れていませんでした。私が手書きしたPR descriptionには「reconnect ロジックを移動」と書いてあって、同僚はそれを見て調べに行ってくれたのです。
「目玉が十分あれば、バグは浅くなる」とEric Raymondは1999年に書きました。目玉の話は正しい。ただし、3つの目玉が全部同じ窓を見ている場合の話はしていません。私の3つは全員が差分を凝視していました。誰も一歩下がって「タイミングは何が変わったのか?」と問いませんでした。
マージで失った1時間
3つのレポートを統合する作業こそ、私が予算化していなかった部分です。
「2/3」「1/3」の指摘1件ごとに、判断が必要でした。
- これは本物の指摘か、それともgrep 1発で埋まるコンテキストギャップか
- 本物だとして、エージェントAの重要度判定が正しいか、エージェントBが正しいか
- 修正案が出ているとして、具体案をそのまま適用していいか、抽象案に戻すべきか
3番目の質問だけで、コーヒーを3杯飲みました。2つのSub-agentは「共通ヘルパーに抽出せよ」と言ってきました。1つは具体的なヘルパーを書いてきました。その具体ヘルパーが本当に正しい形をしているかは、結局、差分を3周目に読んで自分で判断しなければなりませんでした。正しくありませんでした。私は4番目のバージョンを書く羽目になりました。
Brooksの法則は、遅延プロジェクトに人を追加すると人間同士のコミュニケーションコストが爆発する話でした。私は今、これが一般化すると確信しています。N人の独立した視点を同じ成果物に当てた瞬間、N+1番目のレビュアーは統合担当者になり、統合担当者の時間はNに対してほぼ線形に増えます。3つのSub-agentは3倍の目玉だった一方、3倍の統合コストでもありました。
Claude Codeを24時間自律稼働させた話を逆方向から見ると同じ結論にたどり着きます。ボトルネックはエージェントの出力を読む人間に移動するのです。
何人並列が最適か
答えは1ではないと思っています。同じ週にN=1で小さなPRを試しました。汎用エージェントによる1回のレビューパスです。explore-reviewerなら気づいたであろうクロスファイルの依存関係を、見落としました。1組の目玉は、2組より明確に悪いです。
12本くらいPRを通したあとの、私の現時点ヒューリスティック:
- 小さなPR (100行未満、新ファイルなし): Sub-agent 1つ。それ以上は無駄。
- 中規模PR (100-500行、1サブシステムに収まる): 異なる角度の2つ。たいていは explore + security か explore + architect。PRが何をリスクに晒しているかで選ぶ。
- 大規模・横断PR (500行超、複数サブシステム): 3つ。事前に統合時間を確保すること。無料ではない。
3を超えると、いまのところ価値を感じたことがありません。HAMYの9エージェント構成は興味深いものの、レポートをマージする2つ目のツールが必要になり、それは私自身より安くないと割に合いません。
もう1つのツマミは具体性です。私は今、各Sub-agentに「最小の具体的な修正案を添えること、わからない場合は no-fix と明記すること」を必ず要求しています。システムプロンプトのこの1行だけで、具体性ドリフトが半分近く消えました。
結局、私が今信じていること
マルチエージェントのコードレビューはタダではありません。実態は「3人のジュニアレビュアーが別々の部屋で読んで、あなたがメモを統合するシニア」に近い。目の数は確かに増えますが、統合コストも増え、その統合コストはあなたのカレンダーに居座ります。
誰も気づかなかったバグの件が、私を一番謙虚にさせました。3エージェント、3つの角度、全員読み取り専用、全員同じ差分。誰もタイミングの変化に気づかなかった理由は、誰もそれを問われていなかったからです。Sub-agentはシステムプロンプトに書かれた質問にはとても強い。書き忘れた質問には平凡です。 限界はモデルではなく、こちらの問いの設計でした。
ひとつだけ持ち帰っていただきたいのは、これです。what-am-i-not-asking という4つ目のSub-agentプロンプトを書き、差分を渡し、他のエージェントが見落とすカテゴリを列挙させる。その答えを読んでから、本番のレビュープロンプトを書く。本記事の実験では私はそれをやりませんでした。そして1時間を失い、同僚にレースコンディションを見つけてもらいました。因果関係は明白です。
Anthropicの1%未満という数字は本物です。ただしそれは、数ヶ月かけて誰かが磨いたパイプライン上の数字です。会議の合間に3つ書いたSub-agentで出る数字ではありません。あなたの環境で磨いてください。それまでは、4割で見積もるのが安全です。
この記事を本1冊分に拡張したいなら。 Sub-agent設計、カスタムエージェントのパターン、Claude Codeのワークフロー全体は、Practical Claude Code(実践Claude Code) にまとめています。Claude Codeを本気で運用したいエンジニアのためのフィールドガイドです。
関連記事:
この記事は役に立ちましたか？