「トークンを削ったのにコストが増えた」 GitHubが明かすAIコーディング“効率化の落とし穴”：「GitHub Copilot」のコストを下げた4つの改善（1/2 ページ）

GitHubは、AIコーディングエージェントのコスト効率を高めるために「GitHub Copilot」に加えた4つの改善を公開した。ツール呼び出し1回分の出力を短くする定石が、かえってタスク全体の費用を押し上げる場合があるという。

[＠IT]

　GitHubは2026年9月2日（米国時間）、AIコーディングエージェントのコスト効率を高めるために「GitHub Copilot」に加えた4つの改善を、技術ブログで公開した。個々のやりとりのトークン数だけでは効率を測れず、タスクを前に進めるのに必要なだけのコンテキストを渡すことが重要だとしている。

Copilotの品質を保ちながら無駄を減らすための4つの改善

　4つの改善はいずれも、オフラインのベンチマークで評価し、有望なものだけをオンライン実験で検証してから投入した。例はGitHub Copilot CLI（コマンドラインインタフェース）のものだが、効果は同じハーネスを使う「Copilotコードレビュー」などにも及ぶ。

AIクレジットを指標にした4つの独立したA/Bテストの結果。効果は必ずしも単純に加算されるわけではない（提供：GitHub）

1.ノイズだけを選んで圧縮し、ソース類はそのまま返す

　エージェントのコストを抑える方法として、ツール呼び出しごとの出力を短くする手法はよく使われる。GitHubは、エージェントが読む前にシェル出力を短縮するユーティリティー「RTK」（Rust Token Killer）をベンチマークで評価した。

　RTKは一部の応答を短くしたものの、省かれた部分が重要だった場合にモデルが元の出力を開き直したり、コマンドを実行し直したりした。この手順がターンを増やし、より多くのコンテキストを後続に持ち越す。個々のツール応答は短くなったが、平均するとタスクで使うトークンは増え、所要時間も延びた。ただし、この結果はGitHubが検証した統合環境とワークロードに限られ、RTKの全ての構成や出力圧縮一般に当てはまるわけではない。

　ツール呼び出し当たりのトークン数は目的関数として適切ではなく、効率化はユーザーの依頼から最終結果までのタスク全体で評価する必要がある、というのがGitHubの結論だ。

ツール応答を短くすると、欠けた情報を取り戻すためにエージェントが出力を読み直し、コマンドを再実行し、より多くのコンテキストを持ち越す（提供：GitHub）

　そこでGitHubは、繰り返しの多い出力だけを短くする方針を採った。ベンチマークでは、インストール、ビルド、テスト、lint（リント）の出力に反復的なノイズが多く、ソースコードに類する出力や任意のコマンドの結果には必要な情報が含まれやすかった。初期の版は圧縮が強過ぎ、モデルが作業を繰り返して全体のコストが増え、成功率も下がった。こうした失敗を経て、3つの方針にまとまった。

• ソースコードに類する出力と任意のコマンドの出力は保存する：「cat」「git diff」「git show」やスクリプトの結果はそのまま返す
• 検索結果は内容を落とさずに整理する：「grep」などが返す一致箇所やファイル一覧は、全件を残したまま効率よくまとめる
• 反復的なノイズは選択的に圧縮する：インストール、ビルド、テスト、進捗（しんちょく）の出力は、削減量が大きいときだけ縮める

　例えば当初はgit diffの出力も圧縮していたが、エージェントが元の出力を開き直したので対象から外した。

　出力を圧縮した場合も、エージェントは直接の復旧経路から圧縮前の完全な出力を取り出せる。この経路は安全策であると同時に評価のシグナルでもあり、GitHubは保存された元の出力を開いたか、コマンドを再実行したか、探索をやり直したか、検索範囲を狭めたか、ターンを追加したかを追跡した。復旧の頻発は、圧縮で必要な情報が失われた証拠になる。

　出力圧縮が働いたオフラインのタスクでは、統計的に有意な成功率の低下は検出されず、保存された元の出力を開くことも極めて“まれ”だった。オンライン実験では平均コストがわずかに下がり、品質指標に悪化は検出されなかった。

正式に採用された圧縮処理は、ソースコードに類する出力を保存し、検索結果を欠落なく整理し、予測可能な反復的ノイズだけを圧縮しつつ完全な原文を残す（提供：GitHub）

2.情報を削る前に書式を削る、viewツールの行番号を廃止

　情報を削らずにトークンを減らせた例が、ファイルの内容をコンテキストに読み込むviewツールだ。従来は全ての行に行番号を付けていた。以前のファイル編集ツールはその番号で変更箇所を指定していたが、現在のツールは周辺のコードとの一致で位置を決めるので行番号を使わない。

　接頭辞1つは小さくても、ファイルを読むたびに全行に付くため積み上がる。そこでGitHubはこれを削除した。オフラインのベンチマークではモデルの推論コストが約5％下がり、成功率は実行ごとのばらつきの範囲に収まり、編集の失敗も増えなかった。GitHub Copilot CLIのユーザーを対象にしたオンライン実験では、1人当たりの1日平均の推論コストが約3％下がり、品質や満足度の指標に悪化は検出されなかった。

　行番号自体はdiff（差分）や短い断片では有用だが、全てのファイル読み込みに付いていた点が無駄だった。開発者は、使われない書式ではなく作業そのものにコンテキストウィンドウの多くを割けるようになる。

行番号の接頭辞を削除しても、ソースはそのまま保たれる（提供：GitHub）