LinkedInが複数エージェントでAIコードレビューを大規模化

はじめに

大規模な開発組織において、AIコードレビューの難しさは大量のコメントを生成することではない。開発者が事実に基づく有用な指摘だと判断し、実際に修正へつなげられるコメントを安定して出すことである。素材によれば、既製ツールをそのまま使う方法には三つの構造的な課題がある。単一モデルの盲点によって同じ種類の欠陥を見逃したり、低価値の問題を繰り返し指摘したりすること。組織やリポジトリ固有の知識を十分に反映できないこと。そして、遅延や品質、障害を工程として管理しにくいことである。

LinkedInはこの問題に対し、AIレビューを単なるツールではなく、運用可能な本番インフラとして設計した。複数エージェントによるレビュー基盤は、信号対雑音比を高め、人的レビューより前に意味のある発見を届けることを目指している。

中核となる仕組み

• 独立したレビューエージェント。 複数のエージェントが異なるモデルや推論方法で同じ変更を調べる。複数エージェントが独立して同じ問題を見つけた場合、その一致を信頼度を高める材料として扱う。一方、単独のエージェントだけが見つけた指摘も自動的に捨てず、別途検証する。
• 組織固有の知識をルール化。 組織レベルのポリシー、リポジトリごとの慣行、特定の文脈や高リスク領域向けのルールを組み合わせられる。一般的なベストプラクティスだけでなく、チームが蓄積した暗黙知もレビューの判断材料にできる。
• 公開前のフィルタリング。 表面的な装飾、すでに修正済みの問題、変更と無関係な内容、リポジトリの慣行に合わない提案を除去する。モデルが出したコメントをすべて開発者に見せないことが、レビューの信頼性を守る。
• サービスとしての運用。 Kubernetesを基盤とするイベント駆動パイプラインに永続キューと水平拡張可能なワーカーを組み合わせる。遅延、採用率、完了率、プロバイダー障害を追跡でき、AIレビュアーを測定可能なサービスとして管理できる。

コメント数ではなく採用を測る

LinkedInは、AIの提案と最終的にマージされたコードを比較する自動評価パイプラインも構築した。1727件のPRから抽出した5230件のコメントのうち、90.1%はマージ後のコードを使って高い確度で評価でき、全体の採用率は63.9%だった。種類別では、ロジックエラーが80%、バグ修正が58.1%、リファクタリングが43.5%、セキュリティ関連修正が40.6%、並行性の欠陥が100%となった。

この結果は、すべての指摘が同じ精度を持つことを示すものではない。むしろ、生成したコメントの数よりも、最終コードにどのような変化が現れたかを評価する方が、実用的な価値を捉えやすいことを示している。

意義と影響

LinkedInの事例は、企業向けAI開発ツールの競争軸が、より強いモデルを接続することから、検証・カスタマイズ・運用を含むシステム設計へ移りつつあることを示す。複数エージェントは幻覚を自動的に解消するわけではなく、オーケストレーションや検証のコストも増やす。それでも、能力を分離し、独立した判断を突き合わせる仕組みは、単一モデルに依存するより管理しやすい。

CloudflareはOpenCodeを中心としたオーケストレーションを、DatabricksはUnity AI GatewayやOmnigentなどを展開しており、企業ごとに異なる均衡点を探っている。重要なのは構成をそのまま模倣することではなく、価値あるレビューの定義を先に置き、採用率、誤検知、遅延、障害復旧を継続的に改善することである。

出典：InfoQ中国語