AIエージェントの性能は、強いツールを渡せば自然に上がるのでしょうか。GitHub の事例は、その答えがかなり条件付きであることを示しています。
Better tools made Copilot code review worse. Here’s how we actually improved it. では、Copilot code review が専用のコード探索ツールから、Copilot CLI と共有する grep、glob、view に移行した際の検証が紹介されています。移行直後はレビューコストが上がり、有用な指摘も減りました。原因はツールではなく、レビューという仕事に合っていない探索手順にありました。
ここで重要なのは、「高機能な探索」そのものが悪かったわけではない点です。リポジトリ全体を理解して変更を加えるエージェントなら、広く検索し、周辺ファイルを読み、文脈を増やしていく動きには意味があります。しかしコードレビューの仕事は少し違います。起点は pull request の diff であり、問うべきことは「この変更が問題を生んだか」です。
そのため、レビューエージェントに必要なのは、より多く読む力ではなく、読む範囲を狭める手順です。GitHub は、diff から具体的なレビュー質問を作り、まず grep や glob で候補を絞り、必要な行範囲が見えた段階で view するように指示を作り直しました。結果として、本番環境ではレビュー品質を維持しながら平均レビューコストを約20%下げたと説明されています。
この事例は、AIエージェント導入の判断材料として使えます。ツール統合や共通基盤化は、保守性や横展開の面で大きな機会があります。ただし、共通ツールをそのまま各業務に流し込むだけでは、エージェントの行動は業務からずれていきます。ツール説明、システム指示、評価ベンチマークまで含めて、その仕事の形に合わせる必要があります。
コードレビューであれば、「どれだけ賢く探索できるか」より、「diff に anchored したまま、最小限の証拠で判断できるか」が性能になります。AIエージェントを実務に入れるときの改善余地は、モデル選定やツール追加だけにあるわけではありません。仕事の単位をどう定義し、どこから始め、どこで読むのを止めるか。その設計こそが、コストと品質の両方を動かします。
関連記事
- Our new community investments in Virginia support local jobs and expand energy affordability.
- How Deutsche Telekom is rewiring telecommunications with AI
- UST is bringing Claude to physical AI
参考文献
コメント