「ツールを良くすれば結果も良くなる」という直感の裏切り
GitHubのエンジニアリングチームは、Copilotのコードレビュー機能が使っていた専用のコード探索ツール（list_dir・search_file・search_dir・read_code）を、Copilot CLIやCopilotクラウドエージェントなど複数の製品で共有される汎用ツール（glob・grep・view）に置き換える取り組みを行いました（出典）。
狙いは、重複した実装を減らし、ツールの改善を複数のCopilot製品に横展開しやすくすることでした。
「エージェントに良いツールを与えれば、良い仕事をするはずだ——それが直感というものだ」
しかし実際にベンチマークを取ると、レビューのコストは上昇し、検出できる問題の数はむしろ減るという結果になりました。
原因はツールではなく「指示文」だった
調査の結果、問題の本質はツールの性能ではなく、モデルに与えていた指示文の設計にあったことが判明しました。旧来のコードレビュー専用ツールは、モデルのツール呼び出し回数が少なく、必要な文脈を自動的に拾い上げる能力も低かった時代の設計を前提にしていました。つまり、少ない呼び出し回数の中にできるだけ多くの関連情報を詰め込む必要があったのです。
一方、共有ツール基盤に切り替えた後も指示文を旧来の前提のまま使い続けていたため、モデルの実際の挙動とかみ合わなくなっていました。GitHubのチームは、指示文を「レビュアーが実際にプルリクエストをどう読むか」に合わせて書き直すことで、この不整合を解消しました。
| 項目 | 旧ツール | 新ツール（共有基盤） |
|---|---|---|
| ディレクトリ探索 | list_dir | glob |
| コード検索 | search_file / search_dir | grep |
| ファイル読み取り | read_code | view |
（出典）
結果として、レビュー品質を維持したまま平均レビューコストを約20%削減することに成功しました。
Copilot CLIのターミナルUIも正式版に
同時期に、GitHub Copilot CLIの刷新版ターミナルUIも一般提供が開始されました。6月のMicrosoft Buildで初披露されて以来、/experimentalフラグ経由で試験提供されていたものが正式版に格上げされた形です（出典）。
新UIでは画面上部にタブが表示され、Tabキーでセッションタブとgist用タブを切り替えられるほか、リポジトリ内で実行するとIssueタブ・プルリクエストタブが追加されます。Issueやプルリクエストをハイライトしてcキーを押すとプロンプトに参照情報を挿入でき、Copilotに調査・修正・コメント・レビューを依頼できるようになっています。
ツール基盤の共通化とUIの刷新が同時期に進んでいる点から、GitHubがCopilotファミリー全体のインフラを整理し、開発効率を高めようとしている姿勢がうかがえます。個人的には、こうした「地味だが効く」改善こそ日々のコーディング体験に直結すると感じます。自分のスクリプトでもCopilot CLIの新しいIssue連携を試してみたくなりました。
