「トークンを減らせば安い」は誤り？ GitHub Copilotに学ぶAIエージェントの総コスト最適化

トークン削減だけでは、AIエージェントは安くならない

AIコーディングエージェントのコスト最適化というと、1回のツール呼び出しで返す文字数や、消費トークン数を減らす方法に注目しがちです。しかし、GitHubが公開したCopilotの改善事例は、局所的なトークン削減がタスク全体のコスト増につながる場合があることを示しています。

重要なのは、個々の応答を短くすることではありません。ユーザーの依頼からコード変更、テスト、最終結果の提示まで、タスク完了に必要な総時間・総トークン・モデル呼び出し回数・品質をまとめて評価することです。

GitHubはこの考え方にもとづき、Copilotで次の4つの改善を進めました。

• 有用な情報を残したまま、反復的な出力を圧縮する
• タスクに寄与しない整形を削除する
• 動作を維持したままプロンプトを短縮する
• バックグラウンド処理の結果を追加取得なしで渡す

出力を短くしすぎると、エージェントは作業をやり直す

シェルコマンドの出力を圧縮する仕組みは、一見すると有効な最適化に見えます。実際、GitHubはRTK（Rust Token Killer）の効果をエージェント向けのベンチマークで評価しました。

しかし、出力から削られた情報がタスクに必要だった場合、エージェントは次のような追加操作を行うことがあります。

• 元の出力を再度読み込む
• 同じコマンドを再実行する
• より細かい検索をやり直す
• 追加のモデル呼び出しで不足情報を補う

この結果、1回のツール応答は短くなっても、タスク全体ではトークン数が増え、処理時間も長くなる可能性があります。つまり、「ツール呼び出しあたりのトークン数」は、AIエージェントの効率を測る指標として不十分です。

圧縮する対象を選ぶ

GitHubの改善では、出力の種類に応じて圧縮方針を分けています。ソースコードのように内容そのものが重要な出力は保持し、ビルドやテストの進捗表示のように反復が多い出力だけを選択的に圧縮します。

方針は次の通りです。

• cat、git diff、git show、任意のスクリプト出力など、ソースに近い内容や任意形式の出力は変更しない
• grepなどの検索結果は、情報を削除せずに整理する
• インストール、ビルド、テスト、進捗表示は、削減効果が大きい場合に限って圧縮する
• 圧縮前の完全な出力を取得できる復旧経路を残す

実装で重要なのは、単に「短くする」ことではなく、エージェントが再探索や再実行をしなくてもタスクを進められる情報量を残すことです。

情報ではなく、不要な整形を削る

もっと安全な最適化の例が、ファイル内容を表示するツールから行番号のプレフィックスを取り除いた変更です。

以前の編集ツールでは、行番号が編集対象を指定するために使われていました。しかし、現在のツールは周辺コードとの一致を使って編集するため、通常のファイル読み込みに付与される行番号が実質的に不要になっていました。

行ごとの小さなプレフィックスでも、セッション中に何度もファイルを読み込めば無視できない量になります。そこで、ソースコード本体を変えず、使われていない整形だけを削除しました。

この変更では、オフラインのエージェント型コーディングベンチマークでモデル推論コストが約5％低下し、成功率や編集失敗の増加は確認されませんでした。Copilot CLIのオンライン実験でも、ユーザーあたりの1日平均モデル推論コストが約3％減少しました。

この事例から得られる実務上のポイントは明確です。

• 情報量を削る前に、不要な装飾や重複を探す
• モデルが実際に利用していないメタデータを特定する
• ソースコードの内容を変えずに済む最適化を優先する
• 削除後に編集精度やタスク成功率が変わらないか測定する

プロンプト短縮には、振る舞いの回帰テストが必要

AIエージェントのプロンプトは、モデルの各ターンに繰り返し送られます。そのため、長い指示を短くできれば継続的なコスト削減になります。ただし、プロンプトを削ることは、モデルの振る舞いを変えることでもあります。

GitHubは、並列作業を行うタスクツールの指示を短縮しました。プロンプトをおよそ半分に削減する過程で、最初のオンライン実験では、独立したカスタムエージェントが並列ではなく逐次実行される回帰が見つかりました。

オフライン評価で見逃された理由は、プロンプトの文字列そのものは短くなっていても、重要な行動特性を十分に検証していなかったためです。そこで、並列実行に関する回帰テストを追加し、最終的には次のような短い指示に置き換えました。

独立したエージェントは並列実行できます。副作用を考慮してください。

これは、細かな許可・禁止リストで動作を固定するのではなく、モデルに判断の余地を残す指示です。結果として、タスクツール向けプロンプトを1ターンあたり約1,300トークン削減し、品質の回帰を検出せずに運用されています。

プロンプトを短縮する場合は、文字数の比較だけでなく、次のような行動単位のテストが必要です。

• 独立した処理が並列に実行されるか
• 依存関係のある処理が適切な順序で実行されるか
• 変更後に必要なテストや検証が省略されないか
• 失敗時に再試行や報告が期待通りに行われるか
• ユーザーが求める制約や安全上の条件が維持されるか

テストされていない振る舞いは、プロンプト短縮によって失われても発見できません。

モデルに取得させるのではなく、ハーネスが結果を届ける

AIエージェントは、長時間のシェルコマンドやサブエージェントの調査をバックグラウンドで実行することがあります。従来の仕組みでは、処理が完了すると通知だけが届き、エージェントは別のモデル呼び出しで結果を取得する必要がありました。

この設計では、処理結果をすでにハーネスが受け取っているにもかかわらず、モデルが「結果を読んでください」という追加操作を行います。複数の処理が近いタイミングで完了すれば、その取得ターンがさらに増えることもあります。

改善後は、完了した処理の結果を通知に含め、対象となる複数の完了通知をまとめて渡すようにしました。これにより、エージェントは結果を取りに行くための追加ターンを使わず、受け取った情報をそのまま次の判断に利用できます。

これは、LLMの能力を高める変更ではありません。決定的に実行できる処理を、モデルにもう一度依頼しない設計上の改善です。AIエージェントを設計する際は、モデルが必要とする情報を圧縮するだけでなく、モデル呼び出し自体を削減できないか検討することが重要です。

オフライン評価とオンライン実験を使い分ける

GitHubは、まずエージェント型コーディングベンチマークやオープンソースリポジトリを使って候補を評価し、その後、有望な変更を本番のオンライン実験で検証しました。

この2段階には異なる役割があります。

特に注意したいのは、あるワークフローで有効だった変更が、別の製品や処理では逆効果になり得る点です。GitHubの事例でも、Copilot code reviewで良い結果を示したファイルツール向けの指示変更が、Copilot CLIではコスト増につながり、採用されませんでした。

したがって、最適化の効果は「AIエージェント全体」のように一括評価するのではなく、実際に変更を適用する製品、ツール、タスクの組み合わせごとに測る必要があります。

開発者が自分のエージェントに応用するなら

今回の事例から、AIコーディング基盤を設計・改善する際の原則を整理すると、次の5点になります。

1. ツール呼び出しではなく、タスク完了までの総コストを測る
2. 情報を削る前に、不要な整形・重複・待機ターンを削減する
3. 圧縮する場合は、出力の意味と利用頻度に応じて対象を限定する
4. プロンプト変更には、期待する振る舞いを検証する回帰テストを追加する
5. 同じ変更を別のワークフローでも再評価する

測定指標としては、トークン数だけでなく、次のような値を組み合わせると判断しやすくなります。

• タスク完了までの総モデル呼び出し回数
• タスク完了までの経過時間
• 入力・出力を含む総トークン数
• コストやクレジット消費量
• ツールの再実行回数
• 圧縮前データの復旧回数
• タスク成功率と編集失敗率
• ユーザーの満足度や中断率

まとめ：賢く削るより、不要な仕事を発生させない

AIエージェントのコスト最適化で重要なのは、出力を機械的に短くすることではありません。必要な情報を残し、使われていない整形を取り除き、モデルが行う必要のない取得や待機をハーネス側で処理することです。

GitHub Copilotの改善事例が示すのは、モデルを賢くするのではなく、モデルに不要な仕事をさせないというアプローチです。AIコーディングツールを導入する側にとっても、単純なトークン削減率ではなく、品質を維持したままタスク全体をどれだけ短く、少ない呼び出しで完了できるかを評価することが、実用的なコスト最適化につながります。

出典： GitHub Blog