GitHub、AI コーディングの効率化とコスト削減を両立する手法を発表

AI コーディングエージェントを活用する際、出力の質は重要ですが、真の効率性は「いかに迅速かつ適切に、必要な文脈を踏まえて作業を完了できるか」にかかっています。

そのため、個々のやり取りにおけるトークン数だけを効率性の指標とすることは意味がありません。目指すべきはトークンを減らすことではなく、タスクを進めるために適切な量の文脈を活用することです。情報が不足して簡潔なツール応答が返された場合、エージェントが必要とする情報を補うための追加呼び出しや作業が発生し、結果としてタスクの完了が遅くなり、コストが増大する可能性があります。

そこで私たちは、ツール呼び出しそのものではなく「成果」を最適化することを重視しています。本稿では、この原則を実践するために GitHub Copilot で導入された 4 つの変更点について解説します。

• 有用な文脈は保持しつつ、重複した出力を削減する
• タスクに価値をもたらさない書式情報を削除する
• 有用な動作を変えずに指示を短くする
• 追加の検索ステップなしで完了済みのバックグラウンド処理を提供する

これらの変更案は、エージェントによるコーディングベンチマークを用いてオフラインで評価されました。有望な変更については、本番環境での統制実験を経て検証された後に実装されています。本稿で紹介する事例は GitHub Copilot CLI のものですが、GitHub Copilot アプリや Copilot コードレビューなど他の製品でも同様の基盤が採用されており、これらの改善によってより効率的に動作しています。

image図 1: 同じ AI クレジット指標を用いた 4 つの独立した A/B 実験。セグメントは比較のために並べて表示されていますが、その効果は必ずしも単純に足し算できるものではありません。

ローカル指標の罠

エージェントのコストを削減するため、ツール呼び出しごとの出力を短くする手法が一般的です。RTK（Rust Token Killer）は、エージェントが読み込む前にシェル出力を短縮するためのユーティリティです。私たちは、この RTK が GitHub Copilot に与える影響を、エージェントによるコーディングベンチマークを用いて評価しました。

私たちの評価環境とベンチマーク設定では、RTK は一部のレスポンスを短縮しましたが、省略されたテキストが重要な役割を果たす場合、モデルは必要な情報を回復するために元の出力を再開いたり、コマンドを再実行したりすることがありました。

これらの回復ステップによってターン数が増え、より多くのコンテキストが引き継がれました。個々のツールレスポンス自体は短くなりましたが、平均するとタスク全体で消費されるトークン量が増加し、所要時間も延びました。ローカルではトークンを節約できたものの、グローバルにはより多くを費やしてしまったのです。

image図 2: 重要な詳細情報が欠落しているためエージェントが出力の再読やコマンドの再実行を余儀なくされ、より多くのコンテキストを引き継ぐ結果、ツールレスポンスが短かくなったことで、完了したタスクのコストが高くなるケースがあります。

この結果は、テストした統合やワークロードに適用されるものであり、すべての RTK 設定や一般的な出力圧縮に当てはまるわけではありません。つまり、「ツール呼び出しあたりのトークン数」を最適化目標とすることは誤りです。効率性は、ユーザーからの要求から最終的な成果物に至るまでのタスク全体を通じて評価する必要があります。

より重要なのは、モデルが作業を繰り返すことなく何を取り除けるかという視点です。

ノイズを圧縮し、有用な情報を保持する

目的は、エージェントがタスクを完了するために必要なコンテキストを損なわずに、繰り返し出力を短縮することでした。

ベンチマーク実行の分析では、インストール、ビルド、テスト、リンターの出力には反復的なノイズが多く含まれる一方、ソースコード風の出力や任意のコマンド結果には、エージェントが実際に必要とする情報が含まれている可能性が高いことが示されました。この分析に基づき、RTK や類似のアプローチも参考にしながら、選択的に情報を圧縮するコンプレッサが開発されました。

このプロトタイプは、エージェント向けコーディングベンチマークと、多数のオープンソースリポジトリに対して評価されました。これらではビルド、テスト、リンターシステムが実際に実行されました。

初期バージョンは過度に積極的すぎました。その結果、モデルが作業を繰り返したり、保存された出力全体を読み直したりしてしまい、エンドツーエンドのコストが増大し、タスクの成功率が低下しました。例えば当初は git diff を圧縮していましたが、ベンチマークタスクでエージェントが欠落した情報を回復するために元の出力を開き直すことが判明したため、このフィルタリングは撤回されました。

これらの初期の失敗から、以下の 3 つの方針を策定しました：

出力はソースコードの形式や任意の出力を保持します。cat、git diff、git show などのコマンドや任意のスクリプトは変更せずに返されます。

検索結果は内容を削らずに再編成されます。grep などのツールからのマッチ結果やファイルリストは、すべての結果を残しつつより効率的にグループ化できます。

反復的なノイズは選択的に圧縮されます。インストール、ビルド、テスト、進捗状況の出力は、削減効果が顕著な場合のみ圧縮対象となります。

最終版は繰り返し評価と改良を経て完成しました。保守的になったのは、保守的なコンプレッサを作ることを目指したからではなく、評価結果がそれを支持していたからです。

出力を圧縮しても、エージェントは直接の復元経路を通じて完全な元のデータを取得できます。

image図 3：採用されたコンプレッサは、ソースコードに似た出力を保持し、検索結果を損失なく再編成し、予測可能な反復的なノイズのみを圧縮しながら完全な元データを維持します。

この復元経路は安全装置であると同時に評価指標でもあります。エージェントが保存された元のファイルを開いたか、コマンドを再実行したか、探索を繰り返したか、検索範囲を絞り込んだか、追加の手順を取ったかを追跡しました。頻繁な復元が必要であれば、それはコンプレッサが重要な情報を削除してしまったことを示します。

オフラインタスクにおいて、出力圧縮がトリガーされた場合でも、統計的に有意なタスク成功率の低下は検出されず、エージェントが保存された元ファイルを開くことは極めて稀でした。オンライン実験では、平均コストがわずかに減少し、追跡された品質指標において実質的な低下は見られませんでした。

情報を削除する前に書式を削除する

トークン最適化における一つのクリーンな成果は、ファイル内容をコンテキストに読み込むためにエージェントが使用する「ビューツール」から得られました。

以前はこのビューツールは、モデルに内容を表示する前に各行の先頭に行番号を付与していました。以前のファイル編集ツールでは、これらの番号を使って変更対象を特定していましたが、現在のツールは周囲のコードと照合してマッチングさせるため、行番号を使用しません。通常のワークフローでこれらが必要なくなったにもかかわらず、行番号のプレフィックスは残されたままでした。

各プレフィックス自体は小さくても、セッション中に読み込まれるすべてのファイルのすべての行にわたって繰り返されることで、使用されない書式情報が蓄積していました。そこで、これを削除しました。

image図 4: 行番号のプレフィックスを削除することで、すべてのファイル読み込みで繰り返されていた書式情報を排除しつつ、ソースコードを正確に保持できます。

行番号は差分表示や短いスニペットでは依然として有用です。しかし今回は、現在の編集ワークフローに役立っていないにもかかわらず、すべてのファイル読み込みに付随していたため、無駄なコストとなっていました。

オフラインの自律型コーディングベンチマークにおいて、これらを削除した結果、モデル推論コストは約 5% 低下しました。成功率はランごとの変動範囲内に留まり、編集失敗率も増加しませんでした。

次に、Copilot CLI ユーザーを対象にこの変更をテストしました。オンライン実験では、ユーザーあたりの平均日次モデル推論コストが約 3% 削減され、追跡した品質や満足度の指標において実質的な悪化は見られませんでした。

開発者にとってこれは、コンテキストウィンドウのより多くの領域をフォーマット処理ではなく、実際の作業に充てられることを意味します。

これは理想的な変更でした。モデルに対する新しい指示は不要で、回復すべき情報源も存在せず、追加の判断も必要ありませんでした。ファイルの内容はそのままモデルに届きます。

意図を圧縮しながらプロンプトを圧縮する

プロンプトにはエージェントの動作を形作る指示が含まれており、これはすべてのターンでモデルに送信されます。エージェントが開発者が依存する振る舞いを維持できる場合に限り、短縮することで効率化が実現します。

GitHub Copilot では、タスクツールが並行作業のための専門エージェントを起動します。そのガイダンスは、ツールの説明、スキーマ、エージェント定義、システム指示、そしてコンパニオンツールにわたって蓄積されてきました。

Copilot が自らのプロンプトを反復して作成するメタプロンプティング・ループにより、プロンプト長はおおよそ半分まで短縮されました。Copilot はより小さな候補を作成・洗練させ、目標とする機能を維持するための行動テストで要件が満たされているか検証しました。

最初のオンライン実験で、当初のオフライン評価では見逃されていた回帰現象が検出されました。メタプロンプティングのループが、慎重な並列実行のガイダンスを「厳格なスケジューリングポリシー」へと書き換えてしまい、独立したカスタムエージェントが順次実行される結果になっていました。

実験は即座に停止しました。再度プロンプトを変更する前に、ユーザーが示した挙動に対する回帰評価を作成しました。最終的な修正では、明示的な許可リストと拒否リストを以下の 1 文に置き換えました。

Independent agents can run in parallel; consider side effects.

この一文はより簡潔で制限も緩く、サブエージェントを並列実行するかどうかの判断を、以前の明示的なガイダンスからモデル側に委ねる形になりました。これにより、新しい挙動テストに合格し、既存のテストが失敗することもありませんでした。

プロンプトの挙動にはテストが必要です。もし挙動がテストされていなければ、短くしたプロンプトによってその機能が削除されても誰も気づかないからです。

image図 5 プロンプトの圧縮が安全になったのは、回帰テストでエージェントが直列化されていることが露呈し、1 文の修正で並列実行が回復してからです。これによるトークン削減は、モデルの各ターンで繰り返されます。

本番環境にデプロイされたプロンプトでは、1 ターンあたり約 1,300 トークンのタスク・ツール用プロンプトを削減できました。これはセッション全体の総プロンプトトークンが約 1.8%減少し、アクティブ時間あたりの正規化コストが 2.9%低下することを意味します。測定された評価では品質の低下は検出されませんでした。

追加の検索ラウンドなしで完了したバックグラウンド処理を配信

エージェントは、長時間実行されるシェルコマンドやサブエージェントによる調査など、独立した作業を並行して実行することがよくあります。通知機能を使えば、ツール呼び出しで待機する必要なく、その作業が完了するまでエージェントの処理を継続できます。

もしエージェントが明示的にどちらかのタスクを待たない場合、ハネス（管理層）がモデルを起動し、シェルコマンドやサブエージェントの完了を通知します。

従来、この通知には完了した結果が含まれていなかったため、エージェントは Copilot がすでに取得済みの出力を取得するために、さらに 1 ラウンドを費やす必要がありました。複数のタスクが近接して完了した場合、この迂回処理が繰り返されることもありました。Copilot では現在、対象となる完了通知をバッチ化し、既存のツール結果フォーマットで直接結果を配信しています。これにより、エージェントは必要な情報を持って作業を継続でき、再度取得のためにラウンドを費やす必要がなくなります。まだ実行中の作業に対する明示的な読み取り動作は、従来通り動作します。

image図 6：変更前は、各バックグラウンド完了が検索専用のモデルラウンドを起動していました。変更後は、ハネスが対象となる完了をバッチ化し、既存のツール結果フォーマットで結果を配信します。

この変更以前は、完了したタスクごとに、その結果を要求するモデル呼び出しと、それを処理するためのもう 1 つの呼び出しが必要でした。上記のシェルコマンドとサブエージェントの場合、作業を継続できるまでに合計 4 回のモデル呼び出しが発生していました。

現在、ハレスは両方の補完結果をバッチ処理してまとめて供給するため、1 回のモデル呼び出しで両方を処理できます。この検索の迂回経路を削除することで、不要な呼び出しを通じてフルセッションコンテキストを引き継ぐ必要もなくなります。

圧縮や要約を行わず、また情報を隠すことなく完了した結果を直接提供することで、ハレスは AI クレジット換算で平均的なトークン関連の使用量を約 2.3% 削減しました。

文脈の変化を測定する

ある Copilot ワークフローでトークンを節約できる変更が、別のワークフローではコストを増加させる可能性があります。

例えば、Copilot コードレビューでの肯定的な結果に触発され、ファイルツール指示のセットをより厳格にしたケースがあります。しかし、Copilot CLI のオンライン実験ではコストが増加したため、この変更は採用しませんでした。

一方、行番号プレフィックスの削除と出力の選択的圧縮は、生産環境モデルを使用した大規模な Copilot コードレビュータスクにおける独立した評価で、1 回のレビューあたりの平均プロンプトトークンを約 5% 削減しました。追跡されているレビュー品質指標に実質的な変化は見られませんでした。

これらの知見は、Copilot コードレビューを共有ファイルツールへ移行し、レビュー指示の調整を行った以前の取り組みとは別物です。その移行と調整により、コードレビューのコストは約 20% 削減されました。

各変更は、それが実行されるワークフローにおいて測定する必要があります。

効率的な AI コーディングエージェントを構築するための 5 つの教訓

ツール呼び出しではなく、完了したタスク自体を最適化してください。エージェントが削除された部分を回復するためにターン数を増やす場合、出力が短くても安価にはなりません。

モデルの出力を最適化するだけでなく、オーケストレーション全体を見直す必要があります。ハッチ（基盤フレームワーク）が決定論的に処理できる作業を、モデルが行うターンを排除しましょう。

出力が何を表すかに基づいて圧縮を行います。正確なコンテンツは保持し、損失のない変換を優先します。また、エージェントがリカバリーパスを利用する頻度を測定してください。

プロンプトの書き換えには予期せぬ副作用が生じる可能性があります。意図した動作が維持されていることを検証する必要があります。

エビデンスは特定のワークロードに依存します。オフラインベンチマーク、オンライン実験、そして変更が展開されるすべての製品面で再評価を行ってください。

これらの変更によってモデル自体が賢くなったわけではありません。モデルが本来行う必要のなかった作業を排除しただけです。

本記事で説明した変更点は、同じ基盤ハッチを利用する GitHub Copilot の全体験に順次導入されています。

GitHub Copilot CLI で、エージェンティックなワークフローをターミナルへ。

「タスクの質を犠牲にせず、AI コーディングのコスト効率を高める方法」の記事は、The GitHub Blog に掲載されました。