［開発者向け］「短くする」ではなく「終わらせる」——GitHub Copilotのコスト最適化に学ぶ

2026-09-09

はじめに

　GitHubは2026年9月2日、AIコーディングエージェント「GitHub Copilot」において、タスクの完了品質を落とさずにコストを抑えるための4つの改善を公開しました。本稿では、その内容をもとに、トークン削減という発想がなぜ落とし穴になり得るのか、実際に効果があった工夫について解説します。

参考記事

タイトル: How we make AI coding more cost efficient without sacrificing task quality
著者: Erik Kristensen, Napalys Klicius
発行元: GitHub
発行日: 2026年9月2日
URL: https://github.blog/ai-and-ml/github-copilot/how-we-make-ai-coding-more-cost-efficient-without-sacrificing-task-quality/

要点

GitHubは、個々のツール呼び出しのトークン数ではなく、タスク全体が完了するまでのコストを効率化の指標としている。
出力短縮ツール「RTK」を検証した結果、省略された情報をエージェントが再取得する動きが増え、タスク全体では平均コストが増加した。
ファイル閲覧ツールから行番号プレフィックスを削除したことで、オフラインベンチマークでモデル推論コストが約5%減少した。
タスクツールのプロンプトをメタプロンプティングで圧縮した際、並列実行の挙動が変わる回帰が一度発生し、修正を経て安全に圧縮できた。
バックグラウンドで完了した作業の結果を直接配信する変更により、トークン関連使用量が約2.3%減少した。

詳細解説

「短くする」と「終わらせる」は違う——ローカル最適化の罠

　AIコーディングエージェントのコストを抑える発想として、個々のツール呼び出しの出力を短くする手法がよく使われます。GitHubは、シェル出力を短縮するユーティリティ「RTK」を自社のエージェント型コーディングベンチマークで検証しましたが、省略された情報が実は必要だった場合、モデルは元の出力を再度開いたりコマンドを再実行したりして情報を取り戻す動きを見せました。GitHubによれば、この回復作業がターン数とコンテキストを増やし、個々の応答は短くなった一方で タスク全体では平均してトークン消費量が増加した という結果になり、処理時間も伸びました。

　この結果は今回検証した統合・ワークロードに限った話であり、RTKの設定全般や出力圧縮そのものを否定するものではないとGitHubは述べています。本稿としては、ツール呼び出し単位の指標だけを見ていると、こうした見えにくいコストを見落としやすい点に注意が必要だと考えています。

出力圧縮とviewツール——実際に効いた2つの工夫

　GitHubは、インストール・ビルド・テスト・lintの出力に多い繰り返しノイズと、catやgit diffのようなソースに近い出力を区別する方針に切り替えました。ソースに近い出力はそのまま保持し、grepなどの検索結果は内容を落とさずに整理し、繰り返しノイズのみ効果が大きい場合に圧縮する、という3段階の運用です。圧縮された出力は必要なら元の内容を直接取得できる経路が用意されており、GitHubによれば、この経路をエージェントが実際に使う頻度は少なく、オフラインでの成功率に有意な後退は見られなかったといいます。

　もう一つの変更が、ファイル内容を表示する「view」ツールから行番号の接頭辞を取り除いたことです。以前の編集ツールは行番号を使って変更箇所を指定していましたが、現在のツールは周辺のコードと照合する方式に変わっており、行番号は使われないまま毎回の出力に付き続けていました。GitHubによれば、この接頭辞を削除したことでオフラインベンチマークのモデル推論コストが約5%減少し、Copilot CLIでのオンライン実験ではユーザー1人あたりの1日の平均モデル推論コストが約3%下がったとのことです。GitHub Copilotのハーネス構成については、以前の記事でも8ステップの開発ワークフローとして整理していますが、今回の改善もこの共通ハーネス上で行われている点は同様です。

　こうした「使われなくなった処理を静かに取り除く」変更は、モデルに新しい指示を与える必要がなく、失われる情報の回復手段を用意する必要もないため、リスクの小さい効率化と言えると思います。

プロンプト圧縮の落とし穴と、ワークロードごとに効果が変わるという教訓

　並列でサブエージェントを立ち上げる「タスクツール」の指示文は、ツールの説明・スキーマ・エージェント定義など複数の場所に蓄積されていました。GitHubは、Copilot自身に指示文を書き直させる手法でこの指示文を半分程度まで圧縮しましたが、最初のオンライン実験で問題が見つかりました。圧縮された指示文が、慎重な並列実行の方針を厳格なスケジューリングルールに書き換えてしまい、本来並列で動くはずの独立したエージェントが直列に実行されるようになっていました。GitHubは実験を止め、この挙動を検証するテストを新たに用意した上で、許可リストと禁止リストによる明示的な指定を「独立したエージェントは並列に実行できる。副作用に注意すること」という一文に置き換えて修正しました。GitHubによれば、この修正後の指示文はターンあたり約1,300トークン少なく、セッション全体では約1.8%のプロンプトトークン削減、稼働時間あたりでは約2.9%のコスト低下につながったとしています。

　バックグラウンドで進む処理についても改善が加えられました。シェルコマンドやサブエージェントの調査が完了した際、以前は完了の通知だけが届き、結果を取得するために別のターンが必要でした。GitHubによれば、複数の処理が近い時間に完了する場合はこの取得作業が繰り返されていましたが、現在は完了した結果をまとめて既存のツール応答の形式で直接届けるようになり、トークン関連の使用量が約2.3%減少したとのことです。

　なお、GitHubは、ある変更が一つのワークフローで効果があっても、別のワークフローではコストが増える場合があるとも述べています。実際、Copilotコードレビュー向けに調整したファイルツールの指示文はコードレビューでは有効でしたが、Copilot CLIのオンライン実験ではコストが増加したため導入されませんでした。本稿としては、AIエージェントの効率化は一律の正解があるわけではなく、製品ごとの計測を積み重ねる必要がある取り組みだと受け止めています。