GitHubは、1回の呼び出しにおけるトークン数だけでコーディングエージェントの効率を測定すると、誤解を招く結果になる可能性があると考えている。出力が短くなったことで、モデルがコマンドを再実行したり、削除された情報を要求したりすれば、ラウンド数、時間、タスク全体のコストが増加する可能性がある。そのため同社は、単一のツール応答のサイズではなく、最終的なタスク結果に基づいてGitHub Copilotの改善を再評価した。
エリック・クリステンセンとナバレス・クレシウスが2026年9月2日に公開したブログ記事で、GitHubは、エージェント型コーディングタスクを評価するベンチマークを用いたオフラインテストを通じて開発し、リリース前にユーザーを対象とした管理実験で検証した4つの変更について説明した。GitHub Copilotアプリやコードレビューを含む複数のCopilot製品は同じ基盤を使用しているが、記事の例はGitHub Copilot CLIから引用されている。
なぜ短い応答だけでは不十分なのか
GitHubは、shellの出力をエージェントに表示する前に短縮するRTK（Rust Token Killer）ツールの影響を検証した。使用したテスト設定では、重要なテキストの一部を削除すると、元の出力を再び開いたり、コマンドを再実行したりすることになった。その結果、ツールの応答サイズは局所的には減少したものの、タスク全体では平均してより多くのトークンと長い時間を要した。
同社は、この結果が検証した統合とワークロードに関するものであり、RTKのすべての設定や出力圧縮のすべての手法に対する判断ではないと強調している。実務上の教訓は、評価基準をユーザーの要求から最終結果まで広げ、取得のラウンドややり直しも算入する必要があるということだ。
選択的な出力圧縮
GitHubの解決策は、エージェントが必要とする情報を維持しながら、繰り返し発生するノイズを圧縮することだった。運用分析では、インストール、ビルド、テスト、lint処理の出力には大きな反復が含まれることが多い一方、コードに似た出力や任意のコマンドの結果には、必要不可欠な情報が含まれる可能性があることが示された。
リリース版では、次の3項目からなるポリシーを採用した。
- コードに似た出力と任意の結果は変更せずに保持する。これには、cat、git diff、git show、任意のスクリプトなどのコマンドが含まれる。
- grepの結果やファイル一覧など、検索結果を整理し直すが、結果は一つも削除しない。
- インストール、ビルド、テスト、進行状況の出力は、削減効果が大きい場合に限って圧縮する。
Copilotには、元の完全な出力を直接取得する経路も残された。GitHubはこの経路の利用状況を、安全機構であると同時に、圧縮によって有用な情報が削除されたことを示す指標として追跡した。圧縮を有効にしたオフラインタスクでは、タスク成功率に統計的に有意な低下は確認されなかった。また、オンライン実験では、追跡した品質指標に大きな低下を生じさせることなく、平均コストがわずかに減少した。
不要な書式の削除
GitHubは、ファイル内容をモデルに表示するviewツールによって、最も明確な削減効果の一つを達成した。このツールは各行に行番号を追加していたが、現在の編集ツールは周辺コードの照合に依存しており、通常のワークフローではこれらの番号を使用していない。そのため同社は、ファイルの読み取りからこの接頭辞を削除し、差分や短いスニペットでは行番号を有用な情報として残した。
この変更により、オフラインのエージェント型コーディングタスクのベンチマークでは、モデル推論コストが約5%低下した。成功率は予想される変動範囲内にとどまり、編集エラーも増加しなかった。Copilot CLIユーザーを対象としたオンライン実験では、ユーザー1人当たりの1日平均推論コストが約3%低下し、GitHubが測定した品質および満足度の指標にも大きな低下は見られなかった。
動作を変えずに指示を短縮
taskツールの指示は、ツールの説明、スキーマ、エージェント定義、システム指示を通じて蓄積されていた。GitHubは指示を自動的に改善するループを使用し、テキストを約半分に削減した後、維持したい動作をテストした。
しかし、最初のオンライン実験では、オフライン評価では現れなかった問題が明らかになった。慎重な並列化に関するガイダンスが厳格なスケジューリングポリシーに変わり、独立したカスタムエージェントが順番に動作するようになったのだ。GitHubは実験を停止し、この動作に対する回帰テストを追加した。その後、許可事項と禁止事項のリストを、次の一文に置き換えた。「独立したエージェントは並列に実行できます。副作用を考慮してください」
最終版の文面により、タスクツールの指示はラウンドごとに約1300トークン削減された。これはセッション当たりの指示総トークン数で約1.8%の減少、活動1時間当たりの正規化コストで2.9%の減少に相当する。測定した評価では、品質の低下は確認されなかった。
不要な取得ラウンドの排除
エージェントは、サブエージェントが調査を行うのと並行して長時間のshellコマンドを実行するなど、独立した作業をバックグラウンドで行うことがある。以前は、こうした作業の完了通知が結果そのものを伴わずに届いていたため、エージェントはCopilotがすでに取得していた出力を取り出すために、追加の呼び出しを行う必要があった。現在、システムは対象となる完了通知をまとめ、完成した結果を既存のツール結果形式に含めて送信する。
shellコマンドとサブエージェントを組み合わせた例では、以前は作業を完了するために、モデルへの呼び出しが4回必要だった。結果を要求する呼び出しが2回、結果を処理する呼び出しが2回である。変更後は、2つの結果が1回の処理呼び出しで同時に届く。この変更により、AI Credits単位で測定したトークン関連の平均使用量が約2.3%減少した。
実際には何が変わるのか
GitHubの実験は、コーディングエージェントの開発者に重要な原則を示している。最も安全な最適化は、できるだけ多くのテキストを削除することではなく、そもそもモデルが必要としない作業を取り除くことだ。これには、使用されていない書式、システムが解決できる待機と取得のラウンド、復元経路を提供しながら圧縮できる重複が含まれる。
一方で、すべての結果をテスト環境の外部に一般化することはできない。ファイルツールの指示を狭めたところ、コードレビューでは成功したにもかかわらず、Copilot CLIの実験ではコストが増加したため、GitHubはリリースしなかった。また、git diffの圧縮は、エージェントが削除された情報を復元するために元の出力を再び開くことをベンチマークが示した後、取り除かれた。
この記事が示す結論は、変更をタスク、ワークフロー、実際に使用される製品のレベルで、オフラインベンチマーク、オンライン実験、明確な動作テストを通じて測定する必要があるということだ。これらの改善が個々のユーザーに与える影響は、タスクの種類、ツール、出力に左右され、トークン数の局所的な減少だけから推測することはできない。