3 層エージェントオーケストレーションとは、OpenWork のエンジニアが 3層エージェントオーケストレーションで実現する高精度AIコードレビュー で説明しているコードレビューのアーキテクチャに付けた名前である。作業はエージェントの 3 つの階層に分けられる。第 1 層は親エージェントで、変更がどの技術領域に関わるかを判断し、適切なサブエージェントを並列に起動し、その出力をまとめてプルリクエストのコメントにする。第 2 層にはコンテキスト収集エージェント、静的解析エージェント、観点ごとの精査エージェントが置かれる。第 3 層は、それぞれ単一のレビュー観点に限定されたレビューエージェントからなる。この構成は、汎用的なオーケストレーションパターンというよりも、単一エージェントによるレビューで観察された特定の失敗、すなわち指摘の品質が安定しないこと、些末な指摘やハルシネーション、そしてラウンドのたびに同じ点が繰り返し指摘されることへの対応である。
用法
この用語は、著者が一つの具体的なシステムを指すために用いているものであり、本ウィキが持っているのはそのシステムについての説明だけである。その重みの大半は 2 つの仕組みが担っている。
1 つ目はレビュー作業の分割である。1 つのエージェントにあらゆる角度からのレビューを求めるのではなく、アーキテクチャ、ビジネスロジック、明瞭さ、コード品質、パフォーマンス、セキュリティ、フロントエンド固有の事項、テスト設計といった観点をあらかじめ分け、それぞれに専用のエージェントを割り当てる。著者の論拠は人間のレビュアーに当てはまるのと同じものである。小さく範囲の限られたタスクのほうが正確な出力が得られ、対象全体を一度に与えられたエージェントは精度を失う。どの観点を実行するかは変更されたファイルの拡張子から導かれるため、バックエンドとフロントエンドにまたがる変更では両方の観点群が起動される。
2 つ目は合意によるフィルタリングである。各観点は 4 つのエージェントによって独立にレビューされ、精査エージェントは、2 つ以上のエージェントが同じ箇所について同じ理由で挙げた指摘だけを残す。1 つのエージェントしか挙げなかった指摘は、ハルシネーション、行き過ぎ、あるいは些末なものである可能性が高いとして破棄される。4 つのエージェントは意図的に 2 つのモデルファミリーに分けられており、あるベンダーのモデルに特有のバイアスが単に 4 回再生産されることのないようにしている。著者は、ベンダーをまたいだ合意を、単一ベンダー内での合意よりも強い証拠とみなしている。評価を担う役割自体もエージェントであり、精査エージェントの仕事はまさに 4 つの出力を比較して合意のあるものだけを採用することにある。ただし、そこで適用される基準はそれ自身の判断ではなく同輩間の合意であり、この点で、エージェントの実行を直接評価する Agent as a Judge の手法とは区別される。
3 つ目の要素は、アーキテクチャではなくループに関わるものである。コンテキスト収集エージェントがプルリクエストの過去のレビューコメントと返信を読み、すでに挙げられた点と、エンジニアが明示的に却下した点とを切り分けて、その両方を後段に渡すことで、どちらも再び挙げられないようにする。却下された点は、却下された箇所だけでなくレビュー全体に適用されるものとして扱われる。
適用される場面
この説明は、このアプローチが成り立った条件を述べている。前提となるのは、エージェントが読める形のプロジェクトドキュメントがすでに蓄積されていることである。観点ごとのエージェントは、プロジェクト固有のルールについてスキルや指示を参照するよう向けられている。著者は、レビューの精度がそのドキュメントの量と質に左右されるため、一度構築して終わりではなく継続的な監視が必要になると指摘している。また、多数のサブエージェントを起動しても別途課金されない料金体系も前提としている。著者は、数十のエージェントを動かす設計をコストを考慮せずに採用できたのはこのためだと明言しており、したがってこのアプローチは、エージェントの呼び出しごとに課金される体系にはそのままでは移行できない。
このアプローチは、レビューエージェントに課された 4 つの禁止事項によって意図的に範囲を絞られている。良い点を褒めないこと、実装を提案しないこと、YAGNI に反する指摘をしないこと、変更範囲外の既存コードについて指摘しないことである。著者はこのうち実装提案の禁止と YAGNI の厳格な順守の 2 つを、AI レビューに特有のノイズに対して効果のあるものとして取り上げ、これらの制約がなければエージェントは問題の特定から離れ、詳細な実装提案や憶測に基づく将来への備えへと流れていくと報告している。レビューと修正が分けられているのも同じ理由による。修正は、それを実行するコーディングエージェントの役目である。
このアプローチがどの程度確立されているかについて言えば、これは一人のエンジニアのシステムを本人が報告したものであり、本番運用されていてチームからの定性的なフィードバックはあるものの、定量的な評価はない。記事では、著者が計測しようとしている 3 つの基準、すなわち同じプルリクエストへの繰り返しのレビューが収束するか、指摘がエンジニアに妥当と判断されるか、エージェントの指摘が人間のレビュアーが挙げるものと一致するかが、それぞれ 80% の合格ラインとともに示されており、これらを満たすことがレビュー作業をエージェントに委ねるための前提条件とされている。いずれの数値も達成されたとは報告されていない。著者はまた、このアーキテクチャの価値はこの特定の用途を超えて続くものと位置づけ、エージェントのオーケストレーションはツールやタスクに依存しない有望な方向性だと論じる一方で、この特定のレビューシステムが価値を失う可能性も認めている。
関連用語
- エージェント型コードレビュー — これがその一実装にあたる、より広い実践
- サブエージェントアーキテクチャ — 入れ子になったエージェントに委任する一般的なパターン
- Agent as a Judge — エージェントの出力を評価するためにエージェントを用いるという関連する考え方
- オーケストレーション税 — 多数のエージェントを協調させることのコスト面