はじめに
GitHubのNapalys Klicius氏が2026年7月10日、同社ブログでCopilotコードレビューのツール移行に関する知見を公開しました。優れたツールに入れ替えたはずが性能は悪化し、その原因究明から改善に至った経緯を、本稿ではエージェント設計の観点から解説します。
参考記事
- タイトル: Better tools made Copilot code review worse. Here’s how we actually improved it.
- 著者: Napalys Klicius
- 発行元: GitHub Blog
- 発行日: 2026年7月10日
- URL: https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/
関連記事
要点
- GitHub Copilotコードレビューは従来、list_dir・search_file・search_dir・read_codeという専用のコード探索ツールを使用していたが、Copilot CLIハーネスが持つ共通ツール(grep・glob・view)への移行を試みた
- 移行直後のオフラインベンチマークでは、レビューにかかるコストが増加し、検出できる問題の数が減少するという性能低下が確認された
- 原因はツール自体ではなく、ツールの使い方を導く指示(プロンプト)が旧来のエージェント挙動を前提としており、差分起点ではなくリポジトリ全体を広く探索する挙動を誘発していたことにあった
- レビュアーが実際に行う思考プロセス(差分から出発し、的を絞った質問を立てて根拠を集める)に沿うよう指示を書き直した結果、レビュー品質を維持したまま平均レビューコストを約20%削減した
- 同じ焦点を絞った指示をCopilot CLI自体に適用しても同様の効果は得られず、指示とツールの効果は製品の性質に依存することが示された
詳細解説
移行の狙いと直面した性能低下
Copilotコードレビューは元々、SWE-agent流のリポジトリ探索やGitHub Copilot Autofixの発想を参考にした専用のコード探索ツール(list_dir、search_file、search_dir、read_code)を使用していました。一方、Copilot CLIハーネスにはgrep・glob・viewという共通のUnix系コード探索ツールがあり、GitHub Copilot cloud agentなど複数のCopilot製品で共有されています。GitHubは重複した実装を減らし、改善を横展開しやすくする目的で、この共通ツールへの移行を試みました。
しかし、オフラインベンチマークで検証したところ、レビューのコストは増加し、有用なコメントの数は減少しました。専用ツールは一致した行だけでなく周辺のコード文脈も自動的に返す設計になっており、これは以前のモデルが少ないツール呼び出しで必要な情報を得るための工夫だったと考えられます。
トレースから見えた「ブラウジングループ」
GitHubの社内ベンチマークは最終スコアだけでなく、エージェントがどのツールをどう呼び、どれだけの情報が返り、探索を狭めていたか広げていたかという経路まで記録します。共通ツールを導入した際、エージェントは特定のプルリクエストを調査するというより、リポジトリ全体を漫然と閲覧するような挙動を示しました。広く検索し、それらしいパスを推測して読み込み、さらに検索対象を広げるというパターンが繰り返されていたといいます。
この挙動は、コーディングアシスタントが変更前にリポジトリ全体を把握しようとする姿勢としては自然なものですが、レビュアーの実際の仕事とは異なります。レビュアーは通常、差分を起点に「この関数はどこで呼ばれているか」「同じパターンのテストはあるか」といった具体的な問いを立て、それに答えるための最小限の周辺情報だけを求めます。ツール自体に問題があったのではなく、指示がエージェントに誤った振る舞いを促していたことが、トレースの分析によって明らかになりました。
この視点は、汎用のコーディングアシスタントとレビュー専用エージェントとで期待される探索範囲が異なるという、エージェント設計における実践的な教訓を示していると考えられます。
レビュアーの思考に合わせた指示への書き換え
GitHubは指示を、次のようなレビュー専用のワークフローに沿う形へ書き換えました。差分から出発して具体的な問いを立てる、パスが不確かな場合はglobを使い候補を絞る、読み込む前に安価な探索をまとめて行う、ファイルや範囲が特定できた時だけviewを使う、といった内容です。検索が失敗した場合も、より単純な条件で再試行する、globに切り替えるといった具体的な復帰手順を与えることで、小さな失敗が大きな探索の暴走につながることを防いだといいます。
この変更は文言としては小さいものの、エージェントの挙動を「閲覧して読んで再検索する」というリズムから「問い、絞り込み、読み、判断する」というリズムへと変えたと説明されています。ソフトウェア開発における関数のインターフェース設計と同様に、ツールに添える説明文もまた、エージェントの注意の向け方を左右する設計対象だと捉えられている点は、実務上示唆に富むと思います。
本番環境での成果と適用範囲の限界
この改善は本番環境で平均レビューコストを約20%削減し、品質面での明確な劣化は見られなかったとGitHubは報告しています。一方でGitHubは、同様の焦点を絞った指示をCopilot CLI自体にも適用してみたものの、同じ効果は得られなかったとしています。Copilot CLIは単一の差分に縛られない、複数ターンにわたる対話的なコーディングタスクを扱うため、広い探索がタスクの一部として妥当な場合があるためです。
共通のツール基盤を複数の製品で使い回すこと自体は合理的な判断だと考えられますが、その効果はツールに添える指示や評価基準が、対象とする製品の性質と噛み合っているかどうかに左右されるという点は、社内でAIエージェントを設計・運用する際にも参考になる視点ではないでしょうか。
まとめ
同じgrep・glob・viewというツールでも、指示の設計次第で結果は大きく変わるという事例でした。ツール共通化を検討する際は、対象タスクに合わせた指示と評価の仕組みが欠かせないと言えそうです。トークン効率化の別の切り口については、GitHubが自社実践で公開した計測・最適化の全手法もあわせてご覧いただければと思います。
