こんにちは。インフラセクションの開発支援チームで、コードレビュー支援ツールの開発・運用を担当している恩田です。
CEDEC2026では、佐藤、山崎、恩田の3名で「コードレビュー支援ツール開発から学ぶ：LLMを用いた業務システムの実践的な運用設計と誤出力対策」というタイトルで発表を行いました。ご参加・ご視聴いただいた皆さま、ありがとうございました。
本セッションでは、社内向けコードレビュー支援ツール「Lyra」の開発・運用を題材に、LLMの出力品質を安定させるための構造化出力、誤出力を抑えるマルチエージェント設計、継続的な改善を支える運用ダッシュボードについて紹介しました。
当日の資料はこちらです。
質問への回答
こちらのフォローアップ記事では、セッション中やAsk the Speakerなどでいただいた質問のうち、特に多かったものや、セッション時間内では十分に説明できなかったものへ改めて回答します。
Q. 人間のレビュータスクに何か変化はありましたか？ レビュー観点が絞られて負荷が下がった、レビュワーの負荷は変わらないもののコード品質が向上した、といった変化があれば教えてください。
A. 利用者からは「見落としを減らせた」「変更内容を把握しやすくなった」という声が届いています。
Lyraは人間のレビューを置き換えるものではなく、人間がレビューを始める前の初期確認や、レビュー観点を補助するものとして位置づけています。AIが変更差分から検出できる問題を先に提示し、プルリクエストの変更内容を要約することで、人間のレビュワーは、仕様や設計意図、プロジェクト固有の背景、長期的な保守性など、人間の判断がより必要な観点へ集中しやすくなります。
実際の利用者からは、「レビューを依頼する前にセルフチェックで見落としていた箇所を指摘してもらえた」「レビュー要約機能によって、コードを細かく読む前にどのような変更があるのか把握できて助かる」といった声が届いています。また、LyraはGitHubのプルリクエスト上で動作するため、利用者が別のツールへ移動せず、普段のレビューの流れの中で結果を確認できる点も、継続利用につながっていると考えています。
一方で、プロジェクトごとに導入前後のレビュー時間や不具合件数を同じ条件で比較していないため、現時点では「人間のレビュー負荷が何％減った」「コード品質が何％向上した」といった数値までは提示できません。今後は、レビュー開始から完了までの時間、AIの指摘が実際に採用された割合、レビュー後に見つかった問題、利用者アンケートなどを継続的に計測し、見落としの抑制や変更内容の理解をどの程度支援できたかを評価していきます。
Q. レビュー内容を作成する際、AIエージェントにはどの程度の情報を渡していますか？ 差分だけなのか、周辺のコードも含めているのか教えてください。
A. 変更差分だけでなく、レビュー対象のPRの時点のリポジトリ全体を参照できるようにしており、具体的にどこまで確認するかはAIが判断しています。
レビュー開始時にAIエージェントへ渡すのは、起点となるPRの変更差分だけです。周辺コードまであらかじめプロンプトへ詰め込むのではなく、必要になった時点でAIエージェント自身がリポジトリ内を検索し、関連する関数の実装、呼び出し元、型定義、設定ファイル、テストなどを確認する構成にしています。たとえば、差分だけを見ると問題に見えるコードでも、別ファイルにある共通処理によって安全性が担保されている場合があります。そのような情報を確認してから指摘を判断することで、差分だけを見たことによる誤指摘を減らしています。
また、レビューのたびに準備へ時間がかからないよう、Lyraのサーバー内ではレビュー対象のコードをすぐに参照できる状態を整えています。仕組み上はリポジトリ全体を参照できますが、実際にどこまで確認するかは、指摘候補を検証する過程でAIエージェントが行う探索に委ねられています。
Q. 4つのエージェントの合意項目は、そのうち1つのエージェントが抽出しているのでしょうか？
A. 4つのうち、どれか1つだけが最終判断するのではなく、各エージェントの批評結果をアプリケーション側で集計します。
1回目のラウンドでは、SecurityとQualityの観点を持つClaudeとCodexの計4エージェントが、それぞれ独立して指摘候補を作成します。2回目のラウンドでは、各エージェントが自分以外の3エージェントの指摘候補を確認し、指摘ごとに「採用」「却下」「修正」「重複」のいずれかで批評します。これにより、あるエージェントが作成した指摘は、残りのエージェントから検証を受けることになります。
その後、各エージェントが構造化データとして出力した批評結果を、アプリケーション側の専用処理で集計します。ここでは、対象行が実際に変更差分内にあるかを検証したうえで、反証を受けた指摘を折りたたみ表示へ回し、重複する指摘を1件にまとめます。セッションで紹介した通常の4エージェント構成では、この最終集計は別のLLMエージェントではなく、あらかじめ定めたルールに基づく処理として実装しています。そのため、特定の1エージェントの判断へ偏らず、合意形成の基準も一定に保てるようになっています。
Q. マルチエージェント化によりトークン数が増加し、コストも増えると思いますが、どの程度増加したのでしょうか？
A. 単一エージェントが1回レビューする構成と比べ、主要なエージェント実行単位は、差分を分割した1処理単位あたり約8倍です。
Lyraでは、最初に4つのエージェントを並列に実行して指摘候補を作成し、続いて同じ4つのエージェントを並列に実行して、ほかのエージェントが作成した指摘を批評します。そのため、差分を分割した処理単位ごとに「4回のレビュー生成＋4回の批評」という、合計8回のエージェント実行が発生します。最終的な合意結果の集計はアプリケーション側で行うため、そこでは追加のLLM呼び出しは発生しません。
ただし、実際のトークン数や料金が常に正確に8倍になるわけではありません。ラウンドごとに入力と出力の量が異なるほか、利用するモデルの料金、差分の分割数、リポジトリ内の探索量によっても変動します。Lyraでは、各モデル呼び出しの入力トークン、出力トークン、推定コストを記録し、レビュー単位で合計を確認できるようにしています。「約8倍」は主要な実行単位を基準にした目安であり、実コストは計測結果を見て評価しています。
Q. レビューの出力までの時間や、コストの観点で工夫している点はありますか？
A. まず誤指摘を減らすことが利用者の信頼獲得に直結すると考え、現段階ではコスト最小化より品質の検証を優先しています。
処理時間がエージェントの実行数に比例して8倍にならないよう、同じラウンド内のエージェントは並列に実行しています。待ち時間を決めるのは8回のモデル実行時間の合計ではなく、主に「指摘候補の作成」と「批評」という直列の2ラウンドです。各ラウンドの処理時間が同程度であれば、単一エージェントを1回実行する場合と比べて、おおむね2倍程度が目安になります。ただし、実際には変更差分の大きさ、モデルの応答時間、リポジトリ内の探索量などによって変動します。
さらに、2回目の批評では、1回目にエージェントへ渡した情報を引き継ぐことで、入力トークンの重複を抑えています。大きな差分は分割し、各エージェントが一度に扱う情報量を制限しています。あわせて、レビュー開始前の準備処理も効率化し、コードの取得にかかる時間を抑えています。
今後は、記録しているトークン数、推定コスト、各フェーズの所要時間とレビュー品質を合わせて確認し、エージェント数やモデル、ラウンド数を用途に応じて調整していきます。
今後の展望
セッションでお話ししたとおり、Lyraではレビュー結果を構造化データとして受け取り、指摘1件ごとに採用・却下や利用者からのフィードバックを紐づけて、分析可能な形で蓄積しています。今後は、この蓄積したデータをレビュー品質の改善へ継続的に反映していきたいと考えています。
現在の活用は指摘単位の追跡やプロジェクト別の集計が中心ですが、データが溜まってきたことで、どのような指摘が採用されやすいのか、どのような誤指摘が繰り返されているのか、といった傾向も分析できるようになってきました。たとえば、あるプロジェクトで却下され続けている種類の指摘があれば、そのプロジェクトのレビュー観点やプロンプトを調整する、といった判断をデータに基づいて行えます。利用者が「良い指摘」「悪い指摘」ボタンを押した結果が、次のレビューの品質につながっていく形です。
こうした改善を続けていくと、マルチエージェントの構成やモデルを見直す際にも、変更の前後で品質がどう変わったのかをデータで確認できます。誤出力への対策を設計時の一度きりで終わらせず、運用の中で改善を継続できる仕組みへ育てていきたいと考えています。
最後に
今回のセッションでは、社内向けコードレビュー支援ツール「Lyra」の開発・運用を通じて得られた知見として、次の2点を紹介しました。
- LLMの揺らぎや誤出力は起きる前提で設計する必要があるということ
- 利用状況やフィードバックを可視化し、運用しながら継続的に品質を改善すること
また、インフラセクションでは、ゲームを支える基盤の構築・運用だけでなくLyraのような開発者支援ツールの内製にも取り組んでいます。もし、ご興味をお持ちいただけましたらこちらの採用ページをご覧ください。