はじめに
GitHubが2026年9月2日、AIコーディングエージェントのコスト効率をタスク品質を落とさずに高める取り組みを公開しました。本稿では、GitHub Copilotに実装された4つの改善と、その裏で見つかった「局所最適の罠」について解説します。
参考記事
- タイトル: How we make AI coding more cost efficient without sacrificing task quality
- 著者: Erik Kristensen、Napalys Klicius
- 発行元: The GitHub Blog
- 発行日: 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%、オンライン実験で1ユーザーあたりの1日平均コストが約3%低下した
- タスクツールのプロンプト短縮により1ターンあたり約1,300トークンを削減し、アクティブ時間あたりの正規化コストが2.9%低下した
- バックグラウンド処理の完了通知に結果自体を同梱する変更により、AI Credits換算で平均約2.3%の削減となった
詳細解説
「トークンを減らす」が逆効果になるとき
エージェントのコスト削減策として一般的なのは、各ツール呼び出しの出力を短くする方法です。GitHubは RTK（Rust Token Killer） というシェル出力短縮ユーティリティを、自社のエージェンティックコーディングベンチマークで評価しました。
RTKは確かに一部のレスポンスを短縮したものの、省略された箇所が重要だった場合、モデルは元の出力を開き直したりコマンドを再実行したりして情報を回収しようとしました。この回収ステップがターン数を増やし、より多くのコンテキストを後続に持ち越すため、平均するとタスク全体のトークン消費と所要時間はむしろ増加したとのことです。GitHubはこれを「ローカルで節約し、グローバルで浪費した」と表現しています。
なお同社は、この結果は自社の統合方法とテストしたワークロードに固有のものであり、出力圧縮一般に当てはまるわけではないと明示しています。エージェント基盤（ハーネス）の設計次第で結果が変わりうる点は、Copilotのハーネス構造を整理した際にも触れた観点と重なる部分だと思います。
ノイズだけを選んで圧縮する
この結果を踏まえ、GitHubは「モデルに作業をやり直させずに削れるものは何か」という問いに切り替えました。ベンチマーク実行の分析では、インストール・ビルド・テスト・lintの出力には反復的なノイズが多く、ソースコードに類する出力や任意のコマンド結果にはエージェントが必要とする情報が含まれやすい傾向が見えたと説明されています。そこから導かれたのが、次の3点からなる選択的圧縮ポリシーです。
- cat、git diff、git show や任意のスクリプトなど、ソース類似・任意出力はそのまま返す
- grep などの検索結果は、すべての結果を保持したまま効率的にグループ化して再構成する
- インストール・ビルド・テスト・進捗表示などの反復的ノイズは、削減幅が大きい場合にのみ圧縮する
初期版は圧縮が強すぎ、かえって全体コストが増えてタスク成功率も下がったとのことです。当初は git diff も圧縮対象でしたが、エージェントが元の出力を開き直す挙動が確認されたため外されています。圧縮時には元の全文を取り出せる復元経路が用意されており、これは安全装置であると同時に評価指標としても機能します。原文を開いたか、コマンドを再実行したかを追跡すれば、圧縮が必要な情報を削っていないかを検証できる仕組みです。オフライン評価ではタスク成功率に統計的に有意な低下は検出されず、原文が開かれることもほとんどなかったと報告されています。
情報を削る前に、書式を削る
4つの改善のうち最も素直だったのが、ファイル内容を読み込む view ツールの変更です。従来この機能は各行に行番号を付与していました。かつてのファイル編集ツールは編集対象の指定にこの番号を使っていましたが、現在のツールは周辺コードのマッチングで位置を特定するため、行番号は使われていません。
1行あたりの追加は小さくとも、すべての行・すべてのファイル読み込みで繰り返されればセッション全体では相応の量になります。削除の結果、オフラインベンチマークで推論コストが約5%低下し、成功率は実行ごとのばらつきの範囲内、編集の失敗も増えなかったとされています。Copilot CLIユーザーを対象としたオンライン実験でも、1ユーザーあたりの1日平均の推論コストが約3%低下し、品質・満足度の指標に実質的な悪化は検出されなかったとのことです。ソースの内容は一切変わらないまま、コンテキストウィンドウをより多く作業本体に使えるようになる、リスクの少ない改善だと言えます。
プロンプトを縮めても意図は縮めない
プロンプトは毎ターン送信されるため、短縮の効果は積み上がります。GitHub Copilotの並列作業用「タスクツール」の指示は、ツール説明・スキーマ・エージェント定義・システム指示などに分散して蓄積していました。同社はCopilot自身に自分のプロンプトを反復的に書かせるメタプロンプティングのループを回し、分量をおよそ半分に減らしています。
ただし最初のオンライン実験で、オフライン評価が見逃していた回帰が見つかりました。書き換えの過程で慎重な並列実行に関する記述が硬いスケジューリング規則に変わり、独立したカスタムエージェントが逐次実行される状態になっていました。GitHubは実験を停止し、この挙動の回帰テストを先に用意したうえで、明示的な許可・禁止リストを次の一文に置き換えました。
Independent agents can run in parallel; consider side effects. （独立したエージェントは並列実行してよい。副作用には注意すること）
短く制約の弱いこの一文は、並列実行の可否をモデル側の判断に委ねる形になっています。 プロンプトの挙動にもテストが必要 であり、テストされていない挙動は短縮の過程で気づかれずに失われうる、というのが同社の結論です。出荷された版は1ターンあたり約1,300トークンを削減し、セッションあたりのプロンプトトークンで約1.8%、アクティブ時間あたりの正規化コストで2.9%の低下につながったとされています。
完了した作業を、取りに行かせない
エージェントは、長時間実行のシェルコマンドとサブエージェントの調査といった独立した作業をバックグラウンドで並行させることがあります。従来、それらの完了通知には結果本体が含まれておらず、エージェントは既に手元にある出力を取得するためだけに1ターンを消費していました。現在のCopilotは対象の完了通知をまとめ、既存のツール結果フォーマットで結果そのものを直接届けます。前述の例では従来4回のモデル呼び出しが必要でしたが、まとめて配信することで1回で両方を処理できるようになり、圧縮も要約も行わずにAI Credits換算で平均約2.3%の使用量削減につながったとされています。
ワークフローごとに測る
あるワークフローでトークンを節約する変更が、別のワークフローではコストを増やしうるという指摘も含まれています。実際、Copilot code reviewで良い結果が出たファイルツール指示の絞り込みは、Copilot CLIのオンライン実験でコストが増加したため出荷が見送られました。一方で行番号の削除と選択的な出力圧縮は、大規模なcode reviewタスク群の独立評価でレビューあたりの平均プロンプトトークンをそれぞれ約5%削減し、品質指標に実質的な変化は検出されなかったとされています。
同社が挙げる教訓は、タスク完了を最適化すること、オーケストレーションも最適化すること、出力の性質に応じて圧縮方法を変えること、プロンプト書き換えの副作用を検証すること、証拠はワークロード固有だと認識すること、の5点です。いずれもモデルを賢くしたわけではなく、モデルが本来やる必要のなかった作業を取り除いただけだ、という締めくくりは示唆的だと思います。
まとめ
GitHubの4つの改善に共通するのは、局所的なトークン数ではなくタスク完了までの総コストで測るという姿勢です。自前でエージェントを組む場合も、圧縮や短縮の効果は自分のワークロードで検証する必要があると考えられます。トークン消費を抑える実践的な工夫については、過去記事でも整理していますので、あわせてご覧いただければと思います。
