マルチエージェント・コードレビュー・ワークフロー：2人のレビュアー、1人の最終ライター
複数の AI コーディングセッションを使うと、同じ制限に何度もぶつかります。私の経験では、並列セッションは異なるコードパスを見つけますが、その意見の食い違いは別々のスレッドに閉じ込められたままです。私はメッセージバスとなり、片方のレビューをもう一方のセッションにコピーし、どのモデルがファイルを理解していたのかを判断することになります。
よりよい設計は、3つの明確な役割を持つマルチエージェント・コードレビュー・ワークフローです。2つの AI セッションが同じファイルリビジョンを独立して調査します。両者は発見事項を交換し、互いの証拠に異議を唱えます。3つ目のセッションは判断記録を受け取り、1つのパッチを書き、チェックを実行します。
レビュー中は、ファイルを共有された不変の入力として扱います。レビューが収束した時点で、1つのセッションに書き込み権限を与えます。
これは、私が現在使っているハイブリッド AI コードレビューループ→とは異なります。このループでは、1つのモデルが書き、2つ目のモデルが各修正をレビューします。このループはすでにレビュアーに有用な独立性を与えています。次の実験では書き込みを遅らせます。最初の2つのセッションがレビューを行い、意見の相違から判断記録が生まれた後で、3つ目のセッションだけがコーディングを開始します。
このパターンは、現在のエージェントツールがサポートしている機能にすでに近いものです。OpenAI の Codex サブエージェントのドキュメントは、読み取り中心の探索、テスト、トリアージ、レビューには並列エージェントを推奨する一方、書き込み中心のワークフローを並列化すると競合や調整コストが生じると警告しています。欠けているのは、レビュアーとライターの間にある、第一級の議論および統合レイヤーです。
なぜマルチエージェント・コードレビュー・ワークフローには1人のライターが必要なのか？
並列分析を使えば、複数の競合するパッチを作らずに、異なる失敗仮説を得られます。
一方のレビュアーは、挙動と不変条件を追跡できます。もう一方は、セキュリティ問題、競合状態、欠落しているテスト、API 契約の破壊を探せます。両者は同じコミット SHA とタスクから開始しますが、異なるレビュー概要を受け取ります。この分離により、両方のセッションが同じ最初のアイデアに従う可能性を下げられます。
Anthropic は、Building effective agentsで関連する本番パターンを説明しています。複数のモデル呼び出しで異なる観点からコードをレビューし、オーケストレーター・ワーカー型のワークフローで作業を委任し、結果を統合できます。Anthropic は、測定可能な成果を改善する場合にのみエージェント的な複雑性を追加するようチームに助言しています。3つのセッションは1つより多くのトークンと時間を消費するため、このワークフローには存在する理由が必要です。
同時変更がその理由になることは、ほとんどありません。2つのエージェントが同じ作業コピーを編集すると、システムは古いコンテキスト、重複するハンク、部分的に適用された前提を解決しなければなりません。Git にはすでに、より安全なプリミティブがあります。リンクされた worktreeを使えば、別々のセッションが同じリポジトリ履歴を共有しながら、分離された `HEAD` と index の状態を利用できます。
レビュアーは実験のために worktree を使っても構いませんが、候補パッチの所有者になるのはインテグレーターだけにします。
各 AI セッションは何を担当すべきか？
| セッション | アクセス | 必須の出力 | してはいけないこと |
|---|---|---|---|
| --- | --- | --- | --- |
| Reviewer A | 読み取り専用スナップショット | 挙動上のリスク、壊れた不変条件、行番号の参照、提案テスト | 最終ブランチを編集する |
| Reviewer B | 読み取り専用スナップショット | セキュリティ、並行性、エッジケース、反例 | 証拠なしに Reviewer A の結論をコピーする |
| Integrator | 排他的な書き込みアクセス | 採用したパッチ、理由付きで却下した発見事項、テスト結果、最終 diff | 合意した範囲を超えて書き換える |
3つ目のエージェントが自動的に賢いわけではありません。その優位性は所有権から生まれます。限定された証拠を受け取り、競合解決を明示し、監査可能な1つの diff を生成します。
私は、レビュアー同士が最初のパスを互いに見えない状態にしておくことも勧めます。マルチエージェント・ディベートに関する統制研究では、多数派からの圧力が独立した訂正を抑制する可能性が示されています。早い段階で会話を始めると、2人のレビュアーが同じ意見を繰り返すだけになることがあります。まず独立した発見事項を出し、その後、両者が最初の証拠を確定してから議論を始めるべきです。
レビュアーは1つのファイルについてどのように議論すべきか？
自由形式のチャットは人間には便利ですが、コーディングワークフローには簡潔な発見事項台帳が必要です。各主張には、インテグレーターが非公開の思考過程を再現せずに検証できるだけの証拠を添えるべきです。
{ "id": "F-03", "revision": "8a31f2c", "file": "src/auth/session.ts", "lines": "84-103", "claim": "A refresh failure can leave the previous session active", "evidence": "The error branch returns before clearSession()", "risk": "stale authorization state", "proposed_test": "refresh 401 clears the active session", "confidence": "high", "status": "disputed" }
2人目のレビュアーは、その発見事項を受け入れることも、到達可能なコードであることを示す議論によって反証することも、範囲を狭めることもできます。台帳には両方の立場が保存されます。合意だけでは正しさの証明にならず、自信に満ちた段落が再現可能なテストを上回るべきでもありません。
エージェントプロトコルはこの方向に進んでいます。Google のAgent2Agent プロトコルは、タスク、メッセージ、状態、アーティファクトを通じてコラボレーションをモデル化します。ローカルのコーディングシステムが完全なプロトコルを必要とするわけではありませんが、その契約を取り入れることはできます。構造化されていない記録ではなく、型付きメッセージ、安定した ID、明示的なステータス、永続的なアーティファクトを使います。
私のAI ピアレビューブリッジ→は、すでに diff、重点質問、構造化された判定を2つ目のモデル向けにパッケージ化しています。3セッションのワークフローには次のレイヤーが必要です。ライターが受け取る前に、同じ発見事項 ID を参照し、異議を唱え、解決できる2つのレビューパケットです。
ライターは編集前に何を受け取る必要があるか？
インテグレーターが受け取るべきなのは、2つの長いチャット履歴ではありません。必要なのは小さな引き継ぎパッケージです。
その後、ライターは現在のファイルを再読し、そのリビジョンを引き継ぎ内容と比較します。不一致があれば書き込みを停止します。この1つのチェックにより、昨日のファイルに対する有効なレビューが、今日のコードに対する壊れたパッチになるのを防げます。
ここで権限も決定論的にすべきです。私は決定論的な AI エージェント権限→を提唱してきました。「このファイルだけ編集する」というプロンプトは、他のすべてのパスを読み取り専用にするツールポリシーより弱いからです。このワークフローでは、権限モデルが役割分担を強制すべきです。レビュアーは書き込めず、インテグレーターは新しい判断なしにスコープを拡大できません。
議論はソフトウェアパッチを改善するのか？
証拠はこの方向性を支持していますが、すべてのチームが必ず2人のレビュアーと1人のライターを使うべきだと証明しているわけではありません。
Improving Factuality and Reasoning in Language Models through Multiagent Debateは、複数のモデルインスタンスが複数ラウンドにわたって回答を提案、批評、改善できることを示しており、論文の推論および事実性タスクで結果が向上しています。これらの実験では、Git の競合や本番のプルリクエストはテストされていません。
よりコードに近い例が、2025年のプレプリントSWE-Debateに登場しました。そのエージェントは、競合する障害箇所特定のトレースについて議論し、修正計画を統合し、その計画を別のパッチ生成エージェントに渡します。論文では、SWE-bench Verified の500タスク中207タスク、つまり41.4%を解決したと報告されています。これは、記載された最も強いベースラインの38.8%と比較した値です。ベンチマークとアーキテクチャは私が提案しているワークフローとは異なりますが、分離の考え方は示唆的です。まず多様な分析を行い、その後に1つの変更段階を置きます。
正直な次のステップは、実際のプルリクエストを使った小規模な統制評価です。10〜20件のバグを対象に、単一のコーディングエージェントと3セッションのワークフローを比較します。有効な発見事項、誤検知、マージ競合、受け入れ可能なパッチまでの時間、初稿後に検出されたリグレッションを測定します。エージェントメッセージの数が成功指標ではありません。
ライターはどのように監査可能な1つのパッチを作るのか？
インテグレーターは、狭いループに従うべきです。
最後のレビューでは、設計議論を再開するのではなく、パッチを検査します。各レビュアーは2つの質問に答えます。ライターは採用された判断を実装したか、そしてパッチは新たなリスクを導入していないか、です。
OpenAI の現在の Codex アプリは、すでに別々のスレッドと worktree を使い、同じローカル Git 状態に触れずにエージェントを並列実行できるようにしています。また、開発者は各 diff を検査してコメントできます。Codex アプリの発表は、分離レイヤーが存在することを示しています。共有された発見事項台帳と明示的なインテグレーターの役割があれば、並列タスクを調整されたレビュー室に変えられます。
どのような失敗が残るのか？
1人のライターにすることで編集競合はなくなりますが、モデルの誤りはなくなりません。
2人のレビュアーが同じ盲点を共有することはあります。特に、同じモデル、プロンプト、コンテキストを使う場合です。インテグレーターは正しい議論ではなく、説得力のある議論を選ぶ可能性があります。リポジトリ内のコメントには、信頼できない指示が含まれていることがあります。テストスイートが成功しても、ユーザーが依存している挙動を見逃す可能性があります。
ワークフローにはガードが必要です。
215.4億トークンのコードエージェント活動→を受けた以前の結論は、今も当てはまります。モデルを取り巻くシステムが、より多くの知性を有用な作業に変えるのか、それとも後片付けを速くするだけなのかを決めます。
3セッションのワークフローはいつ価値があるのか？
間違ったパッチのコストが高い場合、またはコードに複数のもっともらしい解釈がある場合に使います。認証、権限、決済、マイグレーション、並行性、公開 API、インシデント対応の修正などです。また、シニアエンジニアが通常、異なるリスク領域を2人の専門家にレビューしてもらうような場合にも役立ちます。
フォーマット、生成ファイル、単純な名前変更、明確なテストオラクルがある変更には使わないでください。Anthropic のマルチエージェントチームは、調整の複雑性が急速に増大することを発見しています。また、その本番研究システムは、明確な委任と、専門化された結果を統合するリードエージェントに依存しています。コーディングにも同じ規律が必要ですが、曖昧な書き込みに対する許容度はさらに低くなります。
私は、コーディングエージェントが、そのうちの1つがカーソルを得る前に証拠について議論してほしいと思っています。2つのセッションが同じファイルを調査し、公の場で意見を異にし、1つの判断記録を残すべきです。3つ目のセッションが候補パッチを書き、リポジトリに対してそれを証明すべきです。
その候補には、依然としてテスト、diff レビュー、人間によるリリース判断が必要です。3つの AI セッションはパッチに至る道筋を改善できますが、パッチを真実に変えるわけではありません。
FAQ
2つの AI エージェントが同じファイルを同時に編集できますか？
できますが、共有された書き込みは古いコンテキストと編集競合を生みます。両方のエージェントに同じリビジョンを読み取り専用モードで分析させるか、別々の worktree で実験を分離し、その後、最終ブランチへの排他的な書き込みアクセスを1人のインテグレーターに与えてください。
両方のレビュアーは同じモデルを使うべきですか？
同じモデルでも構いませんが、異なるプロンプト、役割、またはモデルファミリーを使うことで、相関した盲点を減らせる可能性があります。多様性は正しさを保証しないため、ワークフローには依然として証拠とテストが必要です。
レビュアーの意見が一致しない場合はどうなりますか？
発見事項台帳に両方の立場を記録します。インテグレーターは主張を再現し、提案されたテストを実行するか、人間による確認のために未解決としてマークすべきです。多数決は、検証可能な証拠の代わりとしては弱いものです。
3つ目の AI セッションは人間によるコードレビューに取って代わりますか？
いいえ。3つ目のセッションは統合と候補パッチの書き込みを担当します。パッチがより広いシステム、プロダクトの意図、リリースリスクに適合するかどうかは、依然として人間が判断します。
このワークフローは複数ファイルにまたがる変更に対応できますか？
はい。レビュー対象のすべてのファイルを同じリポジトリリビジョンに固定し、明確な所有権を割り当て、1つの統合ブランチを維持します。レビュアーは分離された worktree で作業できますが、最終パッチを組み立てるセッションはインテグレーターだけにします。