LinkedInのマルチエージェントAIコードレビュー設計｜受け入れ率63.9％の仕組み

LinkedInの大規模なAIコードレビューから得られる結論は、レビュー品質はモデル単体の賢さではなく、複数モデルの役割分担、コードベース固有ルール、重複排除、継続評価を組み合わせたシステム設計で決まるということです。

LinkedIn Engineeringは、マルチエージェント型のAIコードレビューを約1万リポジトリへ展開し、週約7万9,000件のレビューを処理しています。サンプル調査では、自動レビューボットの総合受け入れ率が63.9％に達したと報告されました。単に多くの指摘を生成するのではなく、開発者が実際に修正へ反映する「高シグナルな指摘」へ絞り込んだことが重要です。(LinkedIn)

この記事では、LinkedInのマルチエージェントAIコードレビュー設計を分解し、自社のGitHubや社内開発基盤へ導入する際の判断基準、評価指標、失敗しやすいポイントまで具体的に解説します。

LinkedInのAIコードレビュー設計の全体像

LinkedInの仕組みは、複数のAIへ同じPull Requestを渡して結果を並べるだけではありません。

中心となるオーケストレーターが、コンテキストの収集、サブエージェントの選択、並列実行、指摘の検証、重複排除、ルール適用、GitHubへの投稿までを統括します。

課題	LinkedInが採用した設計
単一モデルには繰り返し発生する見落としがある	異なるモデルとハーネスを組み合わせた複数サブエージェント
一般論のような指摘が増える	組織・リポジトリ・用途に応じた3層のルール注入
複数モデルから同じ指摘が出る	意味的な重複排除と一致度による信頼度判定
誤検知や細かすぎる指摘が混ざる	コードベース全体を使った相互検証とフィルタリング
モデルやプロンプト変更で品質が下がる	リリース前のペアワイズ評価
利用者が本当に役立てたか分からない	マージ後のコードを使った受け入れ率評価
AIレビューが人間より遅い	イベント駆動と並列処理による10分以内のレビュー
モデル提供元に障害が起きる	段階展開、監視、フェイルオーバー、縮退運転

LinkedInが重視しているのは、特定モデルの性能ではなく、複数モデルの長所と短所を制御するオーケストレーション層です。各サブエージェントは異なるモデルと実行ハーネスの組み合わせで構成され、精度と検出範囲のバランスが補完関係になるように選ばれています。(LinkedIn)

なぜ単一モデルのAIコードレビューでは不十分なのか

高性能なLLMを使用しても、同じモデルを使い続ける限り、見落とし方や過剰反応の傾向は固定されます。

例えば、あるモデルが並行処理の不具合には強い一方で、例外処理の欠落を見逃しやすい場合、Pull Requestの件数を増やしても同じ種類の問題が繰り返し残ります。

LinkedInは、単一モデル型のレビューに次の構造的な制約があると説明しています。

モデル固有の偏りが繰り返される

LLMには学習データやモデル構造に由来する傾向があります。

そのため、同じ種類の問題を毎回見逃したり、逆に価値の低い指摘を繰り返したりする可能性があります。プロンプトだけで完全に修正するのは困難です。

単一のルールファイルでは組織全体を表現できない

一般的なAIコードレビュー製品でも、リポジトリ内のルールファイルを読み込めるものは増えています。

しかし、大規模組織では次のルールを同時に扱う必要があります。

• 全社共通のセキュリティポリシー
• リポジトリ固有のアーキテクチャ規約
• 特定の移行作業や機能開発だけに適用するルール
• 重要度やリスクが異なるサービスごとの基準

1つの巨大なルールファイルへすべてを詰め込むと、関係のない指示までコンテキストに入り、矛盾やノイズが増えます。

外部サービスでは運用を完全に制御できない

外部のレビューサービスをそのまま利用する場合、モデルやプロンプトの変更を一部リポジトリだけで試すカナリア展開、プロバイダー障害時の切り替え、リポジトリ別の品質監視などが制限されることがあります。

LinkedInは約1万リポジトリという規模に対応するため、AIレビューツールを単なるSaaSとして利用するのではなく、社内の重要インフラとして運用する方式を選択しました。(LinkedIn)

マルチエージェントAIコードレビューの処理フロー

LinkedInが公開した構成を簡略化すると、次のような流れになります。

GitHub Webhook
      ↓
耐久性のあるイベントキュー
      ↓
Kubernetesワーカープール
      ↓
レビューオーケストレーター
      ↓
複数のサブエージェントを並列実行
      ↓
ルール適用・相互検証・重複排除
      ↓
1つのレビューとしてPull Requestへ投稿

Pull Requestのコンテキストを収集する

サブエージェントには、変更差分だけでなく、コードベースや最近の変更を含むコンテキストが渡されます。

差分だけを見てレビューすると、次のような誤検知が起こりやすくなります。

• 別ファイルに存在する共通処理を見落とす
• プロジェクト独自の実装パターンを一般的なアンチパターンと誤認する
• 後続コミットですでに修正された問題を指摘する
• 意図的な設計判断を単純な欠陥として扱う

AIコードレビューでは、モデルの性能と同じくらい、どのコードをコンテキストとして渡すかが重要です。

サブエージェントを独立して実行する

LinkedInの設計では、各サブエージェントが他のエージェントの回答を見ずにレビューします。

独立性を保つ理由は、最初の回答に引きずられるアンカリングを防ぐためです。最初のモデルの指摘を後続モデルへ渡すと、複数モデルが同じ誤りへ同調し、見かけ上の一致度だけが高くなる恐れがあります。

それぞれが独立して同じ問題を検出した場合に初めて、その重複を強い信頼度シグナルとして利用できます。(LinkedIn)

オーケストレーターが最終判断を行う

サブエージェントの役割は候補となる指摘を生成することです。

最終的にどの指摘を投稿するかは、オーケストレーターが判断します。具体的には、次の処理を担当します。

• 利用するサブエージェントの選択
• プロンプトとコンテキストの配信
• 出力形式の統一
• 重複コメントの統合
• 単独で検出された問題の再検証
• 組織・リポジトリ固有ルールの適用
• 重要度の判定
• 投稿対象コメントの選別

つまり、AIコードレビューの品質改善では、モデルを交換するだけでなく、オーケストレーターの判断ロジックを改善する必要があります。

重複排除を「後処理」ではなく信頼度判定に使う

複数モデルを実行すると、同じコードに似たコメントが複数生成されます。

通常の重複排除では、単に似た文章を1つにまとめます。しかしLinkedInは、独立した複数エージェントが同じ問題を検出した事実そのものを信頼度の根拠として利用しています。

検出状況	推奨される処理
複数エージェントが同じ問題を検出	高信頼度の候補として優先
1つのエージェントだけが検出	捨てずに別モデルや検証処理で確認
検証に失敗した指摘	投稿対象から除外
すでに後続コミットで修正済み	抑制
コードベースの既存パターンと矛盾	抑制または重要度を下げる
見た目や好みに関する軽微な指摘	ノイズにならないよう抑制

LinkedInでは、単独のエージェントだけが発見した指摘を自動的に削除していません。別のモデルへ再確認させ、有効性と重要度を評価してから投稿対象を決めています。複数エージェントの実行コストを、単なる検出件数の増加ではなく、検証可能な信頼度へ変換している点が特徴です。(LinkedIn)

文章の類似度だけでは重複を判定できない

実装時には、文字列が似ているかではなく、指摘対象と原因が同じかを判定する必要があります。

例えば、次の2つは表現が異なっていても同じ指摘です。

• 「この共有変数へのアクセスはスレッドセーフではありません」
• 「複数スレッドから同時更新されると値が失われる可能性があります」

重複判定に使う情報は、少なくとも次の項目へ分解すると扱いやすくなります。

{
  "file": "src/service/Counter.java",
  "start_line": 42,
  "end_line": 48,
  "category": "concurrency",
  "severity": "high",
  "claim": "共有状態の更新が排他制御されていない",
  "evidence": "複数スレッドからincrement()が呼ばれる",
  "suggested_fix": "AtomicIntegerまたは同期処理を使用する",
  "rule_id": null
}

各エージェントの出力を共通スキーマへ揃えることで、ファイル、行番号、問題分類、原因、修正方針を使った意味的な重複判定が可能になります。

コードベース固有の知識を3層で注入する

LinkedInは、組織全体のポリシー、リポジトリ固有のルール、特定用途のガイダンスを組み合わせるため、3層のカスタマイズフレームワークを採用しています。

公開記事では、LinkedIn用プラグインを含むリポジトリのガイドライン、OpenTelemetryメトリクス移行時のレビュー規則、例外処理に関する全体共通のYAMLルールが例として示されています。(LinkedIn)

実装者向けに整理すると、次のように分けられます。以下はLinkedIn内部の名称や優先順位をそのまま再現したものではなく、公開された設計意図を一般化した構成です。

ルール層	主な目的	具体例
組織共通ルール	全リポジトリで守る最低基準	認証、秘密情報、例外処理、ログ、個人情報
リポジトリルール	サービス固有の設計を理解させる	使用ライブラリ、レイヤー構造、命名規則、禁止API
ユースケース別ルール	特定の変更だけを重点確認する	API移行、OpenTelemetry移行、DB変更、非推奨機能の置換

組織共通ルール

組織全体に適用するルールです。

例えば、例外を何も記録せずに握りつぶす実装を禁止する、認証情報をログへ出力しない、SQLを文字列連結で組み立てない、といった基準が該当します。

リポジトリ固有ルール

同じ会社のコードでも、サービスによって正しい実装は異なります。

あるリポジトリでは直接データベースへアクセスしてよくても、別のリポジトリでは必ずRepository層を経由する必要があるかもしれません。

AIへ一般的なベストプラクティスだけを与えると、プロジェクトとして正しい既存設計を誤って否定する可能性があります。

ユースケース別ルール

期間限定の移行作業や特定機能だけに適用するルールです。

例えば、OpenTelemetryへの移行中であれば、単にコード品質を見るだけでなく、旧メトリクスAPIの残存、属性名の不一致、単位の変更、カーディナリティ増大などを重点的に確認させます。

ルールは文章ではなく管理対象のデータにする

レビュー規則は、自然言語の長文ファイルとして置くだけでなく、ID、適用範囲、所有者、有効期限を持つ構造化データとして管理するのが有効です。

id: exception-must-be-observable
scope: organization
applies_to:
  - "**/*.java"
severity: high
instruction: >
  例外を空のcatchブロックで握りつぶしてはならない。
  再送出、適切な変換、または監視可能なログ記録が必要。
evidence_required:
  - 対象のcatchブロック
  - 例外が失われる実行経路
owner: platform-security
expires_at: null

これはLinkedInが公開した内部YAMLの再現ではなく、3層ルールを運用可能にするための概念例です。

実務では、さらに次の項目を持たせると管理しやすくなります。

• ルールのバージョン
• 対象言語やディレクトリ
• 適用除外条件
• 違反例と許容例
• 自動修正の可否
• 非推奨になる日付
• 承認者と変更履歴

ルール同士の衝突を防ぐ優先順位設計

3層のルールを導入すると、リポジトリ側の指示と組織共通ルールが衝突する場合があります。

例えば、リポジトリルールに「デバッグのためリクエスト内容をすべてログ出力する」と書かれていても、組織共通ルールが個人情報の出力を禁止しているなら、後者を優先する必要があります。

実装時には、次のような優先順位が現実的です。

1. 上書き不可のセキュリティ・法令・コンプライアンス規則
2. リポジトリ固有のアーキテクチャ規則
3. Pull Requestや移行作業に限定したユースケース規則
4. 一般的なコーディング推奨事項

ユースケース別ルールを最も具体的な指示として扱いつつ、セキュリティ規則だけは下位層から緩和できない構造にすると安全です。

週7万9,000件を処理するインフラ設計

LinkedInのAIコードレビューは、全社導入規模として約1万リポジトリに採用されています。一方、典型的な1週間の実稼働では、7,500以上のリポジトリ、4万件以上のPull Request、7万9,000件以上のレビューを処理し、タスク完了率は99.1％とされています。

約1万という数字は導入されたリポジトリの規模、7,500以上という数字は典型的な週に実際の処理対象となった規模と考えると、数字の違いを理解しやすくなります。(LinkedIn)

イベント駆動でPull Requestを受け付ける

GitHubのWebhookから受け取ったイベントは、耐久性のあるイベントキューへ格納されます。

キューを挟むことで、Pull Requestが集中してもGitHubイベントを失わず、ワーカー数に応じて順次処理できます。

Kubernetesワーカーを水平拡張する

イベントキューの後段には、水平スケール可能なKubernetesワーカープールがあります。

LinkedInの公開情報では、各ワーカーホストが最大12件のPull Requestを並行してレビューし、それぞれが独立したマルチエージェントセッションとして実行されます。GitHub APIのトークンプールとレート制限を管理する専用レイヤーも設けられています。(LinkedIn)

モデル障害をPull Request全体の失敗にしない

複数のモデル提供元を利用する場合、一部のプロバイダーで遅延や障害が発生することがあります。

そのため、次の運用機能が必要です。

• モデル単位のタイムアウト
• 一時的なサブエージェント除外
• 別モデルへの切り替え
• 最低限のエージェントだけで処理する縮退運転
• モデル別の成功率と待ち時間の監視
• 特定リポジトリだけで変更を試すカナリア展開

すべてのモデルが完了するまで無制限に待つ設計では、最も遅いモデルがレビュー全体の応答時間を決めてしまいます。

AIコードレビューでは速度も品質の一部になる

優れた指摘でも、人間のレビューとマージが終わった後に届けば役に立ちません。

LinkedInでは、Pull Requestイベントを5秒未満でキューへ入れ、約90秒以内にレビューを開始し、大半のレビューを10分以内に完了させる目標を設けています。多くの場合、AIが最初のレビュアーになる設計です。(LinkedIn)

実務では平均値だけでなく、次の時間を測定します。

指標	確認できること
キュー投入時間	Webhookや受付処理の遅延
キュー待機時間	ワーカー不足やアクセス集中
コンテキスト取得時間	大規模リポジトリやAPI遅延
モデル別応答時間	遅いモデルやプロバイダー
重複排除時間	集約処理のボトルネック
Pull Request投稿時間	GitHub API制限の影響
エンドツーエンドのP90	遅いケースを含めた利用者体験

平均5分でも、一部のPull Requestだけ30分かかるなら開発者の信頼を失います。SLAやSLOには中央値だけでなく、P90やP95を含めることが重要です。

リリース前のペアワイズ評価で品質低下を防ぐ

AIシステムでは、モデルを新しくしたからといって必ず品質が上がるとは限りません。

モデル、プロンプト、コンテキスト取得方法、出力フィルターのどれかを変更すると、ある問題の検出率が上がる一方で、別の問題の誤検知が増える可能性があります。

LinkedInでは、モデル、プロンプト、ハーネスの変更を本番へ出す前に、現在の本番版と候補版を直接比較するペアワイズ評価を行っています。

評価は固定ルーブリックを使ったLLM判定で、回答の提示順を入れ替えながら3ラウンド実施します。位置による判定の偏りを抑え、候補版が総合的に勝つか同点の場合だけリリースする仕組みです。(LinkedIn)

評価データには実際のPull Requestを使う

評価セットは、単純なコード問題集だけでなく、実際の開発で発生したPull Requestから作成する必要があります。

含めるべきケースは次のとおりです。

• 過去に本番障害へつながった変更
• 人間のレビューで重要な修正が入ったPull Request
• AIが誤検知しやすい特殊な実装
• リファクタリングだけを行った変更
• 自動生成コードを多く含む変更
• 複数リポジトリにまたがるAPI移行
• セキュリティ修正
• 正しいが一般的ではない社内パターン

簡単なバグだけで構成された評価セットでは、本番環境で発生するノイズや文脈依存の問題を測定できません。

LLM判定だけに依存しない

LLMを判定者として使う場合は、定期的に人間の評価と比較する必要があります。

特に確認すべきなのは、次の点です。

• 重要度の高い指摘を正しく優先できているか
• 長い説明を高品質と誤判定していないか
• 特定の書き方やモデルを好んでいないか
• 修正案が異なるだけの同等回答を公平に扱っているか
• セキュリティ指摘の妥当性を評価できているか

ペアワイズ評価は有効ですが、判定モデルの変更によって評価基準自体が変わらないよう、モデルとプロンプトのバージョン管理も必要です。

マージ後のコードで受け入れ率を測定する

AIコメントへの「いいね」や開発者アンケートだけでは、指摘が実際に役立ったか判断できません。

LinkedInは、AIの提案と最終的にマージされたコードを比較し、提案内容が実装へ反映されたかを自動評価しています。

公開された調査では、7日間にわたる1,727件のPull Requestと5,230件のレビューコメントが対象になりました。評価結果には、受け入れ、一部受け入れ、非受け入れ、対応対象外といった分類が使われています。(LinkedIn)

評価の確信度	件数	割合
High	4,711件	90.1％
Medium	450件	8.6％
Low	69件	1.3％
合計	5,230件	100％

Highは、最終的なマージ差分に、提案が採用されたか否かを判断できる明確な証拠があることを示します。調査全体では、自動レビューボットの総合受け入れ率が63.9％と報告されています。(LinkedIn)

90.1％はレビュー精度ではない

High判定が90.1％だったという数字は、「AIレビューの90.1％が正しかった」という意味ではありません。

これは、評価者がマージ後のコードを見て、採否を高い確信度で判断できた割合です。

次の3つは分けて管理する必要があります。

• 指摘が技術的に正しいか
• 指摘が開発者にとって有用か
• 採用されたかどうかを明確に判定できるか

評価の確信度と、レビューコメント自体の品質を混同しないことが重要です。

指摘カテゴリーによって受け入れ率は大きく異なる

LinkedInの調査では、正しさに直結する指摘ほど高い受け入れ率を示しました。

指摘カテゴリー	受け入れ率
並行処理の不具合	100％
ロジックエラー	80％
バグ修正全体	58.1％
リファクタリング	43.5％
セキュリティ	40.6％

並行処理やロジックエラーは、問題が再現可能で、修正する必要性も比較的明確です。

一方、リファクタリングやセキュリティの指摘には、設計意図、事業上の優先順位、既存対策、許容リスクなど、差分だけでは分からない要素が含まれます。LinkedInも、受け入れ率の低さを単純な失敗とは捉えず、主観性や文脈依存性を示すシグナルとして扱っています。(LinkedIn)

なお、公開記事では各カテゴリーのサンプル件数まで示されていません。並行処理の100％という数字だけを見て、すべての並行処理バグを検出できると判断することはできません。

カテゴリー別評価を公開する場合は、率だけでなく次の情報も併記すべきです。

• 対象コメント数
• 対象Pull Request数
• 全受け入れと一部受け入れの内訳
• 評価不能だった件数
• 信頼区間
• リポジトリや言語の偏り

受け入れ率63.9％をどう解釈すべきか

受け入れ率は、AIコードレビューの有用性を測る重要な指標です。ただし、正解率と同じものではありません。

受け入れられなかった指摘が誤りとは限らない

正しい指摘でも、今回のPull Requestでは対応しない、別チケットへ分ける、リスクを理解したうえで現状を維持するといった判断があります。

反対に、採用された修正でも、AIコメントだけが修正の原因とは限りません。人間のレビューやCIテストでも同じ問題が発見されていた可能性があります。

そのため、受け入れ率は「AIが正しかった割合」ではなく、開発者が実際のコード変更へ反映できるほど有用だった割合を示す代理指標として扱うのが適切です。

受け入れ率だけを最適化すると検出範囲が狭くなる

確実に採用されそうな単純な指摘だけを投稿すれば、受け入れ率は上がります。

しかし、重大だが判断の難しい問題を一切指摘しなくなれば、レビューシステムとしての価値は下がります。

受け入れ率は、次の指標と組み合わせる必要があります。

観点	指標例
有用性	全受け入れ率、一部受け入れ率
ノイズ	対応対象外率、誤検知率
検出範囲	人間だけが発見した重要問題の割合
重大度	高重大度の検出数と採用率
速度	AIレビュー完了時間のP50・P90
信頼性	タスク完了率、再試行率
コスト	Pull Request当たりのトークン数と費用
利用体験	Pull Request当たりのコメント数

リポジトリ別に評価しなければ全体平均にだまされる

LinkedInでは、リポジトリ別の受け入れ率が0％から100％まで大きく異なったと報告されています。コードベースごとに規約、重要度、開発者の期待、AI指摘への許容度が異なるためです。(LinkedIn)

全社平均だけを見ると、特定のリポジトリでAIレビューが大量のノイズを発生させていても発見できません。

最低でも、次の単位でメトリクスを分けます。

• リポジトリ
• 開発チーム
• プログラミング言語
• 指摘カテゴリー
• 重大度
• 使用モデル
• プロンプトバージョン
• ルールセットバージョン
• Pull Requestの変更行数
• 自動生成コードの有無

受け入れ率が低いリポジトリでは、モデルをすぐ交換するのではなく、コンテキスト不足、ルールの矛盾、生成コードの混入、設計資料の不足などを調査します。

自社で導入するための実装手順

LinkedInと同じ規模でなくても、設計思想は小規模環境へ段階的に取り入れられます。

対象リポジトリを限定する

最初から全リポジトリへ導入せず、性質の異なる2～3リポジトリを選びます。

適した候補は次のとおりです。

• Pull Requestが継続的に作成されている
• 人間のレビュー履歴が十分にある
• コーディング規約や設計方針が文書化されている
• 担当チームが評価に協力できる
• 障害履歴や修正履歴を追跡できる

初期段階では、AIコメントをPull Requestへ直接投稿せず、非公開の評価環境で人間のコメントと比較する方法も有効です。

過去のPull Requestから評価セットを作る

過去のPull Requestを収集し、次の情報を保存します。

• レビュー開始時点の差分
• 人間が投稿したレビューコメント
• コメント後に追加された修正
• 最終的にマージされたコード
• CIの失敗内容
• 関連する障害やバグチケット

評価時にマージ後のコードまで使えるようにしておくと、LinkedInと同様の事後評価を実施できます。

2種類以上の独立したレビュー経路を用意する

単に同じモデルへ同じプロンプトを2回送るだけでは、十分な多様性を得られません。

次の要素の一部を変えます。

• モデル
• システムプロンプト
• コンテキスト取得方法
• 問題の探索順序
• レビュー観点
• 出力フィルター
• 使用可能な解析ツール

例えば、一方を正確性重視、もう一方を検出範囲重視に設定します。

ただし、「セキュリティ担当」「パフォーマンス担当」のように対象を完全分離すると、同じ問題を独立して検出したという一致度を利用できません。重要領域には適度な重なりを残す必要があります。

出力を構造化する

すべてのエージェントに共通スキーマを使わせます。

最低限必要なのは、ファイル、行番号、カテゴリー、重大度、問題の根拠、修正案、適用ルールIDです。

自由形式の長文だけでは、重複排除、評価、メトリクス集計が困難になります。

検証エージェントを追加する

単独のエージェントだけが発見した問題は、別の検証処理へ渡します。

検証時には、単に「この指摘は正しいですか」と聞くのではなく、次の証拠を要求します。

• 問題が発生する実行経路
• 関連する呼び出し元
• 既存のテストや保護処理
• コードベース内の類似実装
• 後続コミットでの修正有無
• 適用される社内ルール

根拠を提示できない指摘は、重要度を下げるか投稿しません。

3層ルールを整備する

既存のコーディング規約をそのまま大量投入するのではなく、組織共通、リポジトリ固有、ユースケース別へ分類します。

ルールごとに所有者を決め、変更をPull Requestでレビューできる状態にします。

カナリア展開する

新しいモデルやプロンプトは、少数のリポジトリへ限定して展開します。

比較対象として、本番版と候補版を同じPull Requestで裏側から実行し、投稿は本番版だけにするシャドー評価も有効です。

マージ後の評価を自動化する

AIコメントと最終差分を比較し、次の状態へ分類します。

• 完全に反映された
• 一部反映された
• 反映されなかった
• 対応対象ではなかった
• 判断できなかった

判断不能を無理に採用・非採用へ振り分けると、受け入れ率が不正確になります。

導入時に追跡すべき評価指標

指標	計算・確認方法
タスク完了率	完了レビュー数 ÷ 受付レビュー数
AIレビュー開始時間	Webhook受付からモデル実行開始まで
エンドツーエンド時間	Webhook受付からコメント投稿まで
コメント数	Pull Request当たりの投稿コメント数
重複抑制率	統合・削除した候補数 ÷ 全候補数
全受け入れ率	完全に反映された指摘の割合
一部受け入れ率	一部だけ反映された指摘の割合
対応対象外率	実行可能な指摘ではなかった割合
高重大度の採用率	高重大度指摘のうち反映された割合
人間のみの発見率	AIが見逃し、人間が発見した重要問題の割合
リポジトリ別受け入れ率	リポジトリ単位で算出
Pull Request当たりの費用	モデル・検索・検証を含む総費用
モデル別失敗率	タイムアウト、API失敗、形式不正の割合

特に重要なのは、受け入れ率と人間のみの発見率を同時に見ることです。

受け入れ率が上がっても、人間だけが発見する重大問題が増えているなら、AIが安全な指摘だけを選ぶようになり、検出範囲が狭くなっている可能性があります。

セキュリティとガバナンスで確認すべきこと

AIコードレビューでは、社内ソースコードをモデルへ送信します。導入前に、次の項目を確認する必要があります。

確認項目	主な対策
ソースコードの外部送信	契約、保存期間、学習利用、データ所在地を確認
秘密情報の混入	送信前のシークレット検出とマスキング
個人情報や顧客データ	対象ファイルの除外、ログの匿名化
リポジトリ内のプロンプトインジェクション	コードやREADMEを命令ではなく非信頼データとして扱う
AIの操作権限	初期段階は読み取りとコメント投稿だけに限定
自動修正	人間の承認なしにコミットやマージを行わない
モデル切り替え	プロバイダーごとに事前評価を実施
監査	モデル、プロンプト、ルール、出力を追跡可能にする

特に、ソースコード内のコメントやドキュメントに「これまでの指示を無視せよ」といった文章が含まれていても、モデルの制御命令として扱わない仕組みが必要です。

リポジトリから取得した内容は、信頼できるシステムプロンプトではなく、レビュー対象となる非信頼データとして境界を分けます。

よくある失敗と改善方法

失敗	起こる問題	改善方法
同じモデルを複数回実行する	同じ偏りと見落としが繰り返される	モデル、ハーネス、検索方法を変える
後続エージェントへ先行回答を見せる	最初の回答へ同調する	独立実行後に統合する
生成されたコメントをすべて投稿する	開発者がAIコメントを無視する	検証、重要度判定、投稿数制限を行う
巨大なルールファイルを全PRへ入れる	関係のない指示と矛盾が増える	3層に分けて必要なルールだけ注入する
いいね数だけで評価する	実際のコード変更と結び付かない	マージ後の差分で採否を測る
全リポジトリへ一斉展開する	品質低下が全社へ波及する	カナリア展開とシャドー評価を行う
平均応答時間だけを見る	遅いPull Requestを見逃す	P90・P95を監視する
受け入れ率を正解率とみなす	モデル性能を誤って判断する	正確性、有用性、採否を分ける
AIレビューで人間を置き換える	設計意図や事業判断を見落とす	最終判断を人間に残す

LinkedInでも、すべてのPull Requestは引き続き人間がレビューしています。AIコードレビューは人間を代替するものではなく、レビューを速くし、ばらつきを減らし、見落としを補う仕組みとして位置付けられています。(LinkedIn)

内製と外部サービスのどちらを選ぶべきか

LinkedInが内製したからといって、すべての企業が独自のマルチエージェント基盤を構築すべきとは限りません。

状況	適した方式
リポジトリが少なく共通ルールも単純	外部AIレビューサービス
早く試験導入したい	外部サービスとリポジトリルール
複数言語・複数チームがある	外部サービスに独自評価層を追加
規制や機密性が高い	専用環境または内製オーケストレーション
モデルを切り替えたい	モデル非依存の内製ゲートウェイ
リポジトリ別の精密な評価が必要	独自の監視・評価基盤
数千リポジトリへ展開する	イベント駆動のマルチエージェント基盤

最初は外部サービスを利用し、評価データとルールが蓄積した段階で、重複排除やモデル選択部分だけを内製する方法もあります。

全面的な内製か全面的な外部依存かの二択ではなく、オーケストレーター、モデル、コンテキスト検索、評価基盤を分離して考えることが重要です。

LinkedInが目指す次の改善

LinkedInは今後の方向性として、Pull Request内の高リスク箇所を可視化するインタラクティブなリスクヒートマップを挙げています。

さらに、重大な本番障害の事後分析からレビュー規則を生成し、類似事故をPull Request段階で検出する仕組みも開発中です。リリース前評価とマージ後評価の結果を分析し、どのプロンプトやルールを修正すべきか提案する自動フィードバックループも計画されています。いずれも今後の構想であり、すでに完成済みの機能としては扱わない点に注意が必要です。(LinkedIn)

この方向性が示しているのは、AIコードレビューの最終形が単なるコメント生成ツールではないということです。

本番障害
  ↓
原因と再発パターンを分析
  ↓
レビュー規則へ変換
  ↓
Pull Requestで事前検出
  ↓
採否と見逃しを評価
  ↓
モデル・プロンプト・ルールを改善

障害対応で得た知識を人間向けの事後報告書だけに残さず、再発防止ルールとして開発フローへ戻す仕組みが重要になります。

高精度なAIコードレビューを始めるための要点

LinkedInの事例で最も参考になるのは、強力なモデルを選べば完成するという発想を捨てている点です。

高精度化には、次の要素を一体として設計する必要があります。

• 異なる特性を持つサブエージェントを独立実行する
• 重複を信頼度シグナルとして利用する
• 単独の指摘も検証してから判断する
• 組織、リポジトリ、用途の3層でルールを管理する
• 人間より先に届く速度を確保する
• 変更前にペアワイズ評価を行う
• マージ後のコードで受け入れ率を測る
• 受け入れ率だけでなく、見逃し、ノイズ、費用も追跡する
• モデル障害を前提に縮退運転とカナリア展開を用意する
• 最終的なレビュー権限は人間に残す

導入の第一歩は、エージェント数を増やすことではありません。

まず過去のPull Requestから評価セットを作り、社内ルールを3層へ分類します。そのうえで、特性の異なる2つのレビュー経路を独立実行し、重複排除と検証を追加します。最後に、AIコメントがマージ後のコードへどの程度反映されたかを測定すれば、モデルの印象ではなく実データに基づいて改善できるようになります。