「トークンを減らせば安くなる」とは限らない
GitHub Copilotの品質を落とさないコスト削減手法4選 短く削ると逆に高コスト?
GitHubは、AIコーディング支援ツール「GitHub Copilot」で、タスクの品質を維持しながらAI利用コストを削減するために実施した4つの改善策を公開した。
生成AIを使ったコーディングでは、「利用するトークンを減らせばコストも下がる」と考えがちだ。しかし、単純にAIへ渡す情報量を減らせばよいとは限らない。必要な情報まで削れば、AIが同じコマンドを再実行したり、ファイルを読み直したりして、結果的にトークン消費や処理時間が増えるためだ。
GitHubは2026年9月2日(米国時間)、AIコーディング支援ツール「GitHub Copilot」(以下、Copilot)で、タスクの品質を維持しながらAI利用コストを削減するために実施した改善策を公開した。同社が重視するのは、1回のツール呼び出しで使うトークン数ではなく、「ユーザーの依頼からタスク完了までに必要な総コスト」を減らすことだ。
GitHubは主に、出力内容の選択的な圧縮、不要な書式の削除、プロンプトの短縮、バックグラウンド処理結果の受け渡し方法という4つの領域を見直した。では、具体的に何を変えたのか。
「短い出力=低コスト」とは限らない
GitHubによると、AIエージェントのコストを削減する方法として、シェルコマンドなどの出力を短縮してモデルへ渡す手法がある。検証に当たって同社は、AIコーディング支援ツールとターミナルの間に位置し、大規模言語モデル(LLM)に渡すトークン量を減らすCLI(コマンドラインインタフェース)「RTK」(Rust Token Killer)を使った。
その結果、確かに1回の応答は短くなったものの、削除された部分にAIが必要とする情報が含まれている場合、Copilotは元の出力を再び開いたり、コマンドを再実行したりした。
その結果、追加の処理が発生し、タスク全体ではトークン使用量と処理時間が増えるケースが確認されたという。局所的にはトークンを節約できても、タスク全体では逆に高コストになるという状況だ。
この検証を踏まえGitHubは、「1回のツール呼び出しを短くする」のではなく、「AIが同じ作業をやり直さずに済む情報だけを残す」方向へ改善を進めた。
1.ビルドログなどの「ノイズ」だけを圧縮する
GitHubが最初に見直したのが、Copilotへ渡すコマンド出力だ。
GitHubが検証したところ、ソフトウェアのインストール、ビルド、テスト、lintなどの出力には、同じようなメッセージが繰り返される傾向があった。一方、「cat」「git diff」「git show」など、ソースコードや変更内容を確認するコマンドには、AIが次の判断をするために必要な情報が多く含まれる。
そこでGitHubは、出力内容によって処理方法を変える仕組みを採用した。
具体的には、ソースコードに近い出力や任意のスクリプトの結果はそのまま保持する。「grep」などの検索結果は情報を削除せずに並べ替える。一方、インストールやビルド、テスト時に繰り返される出力については、十分な削減効果がある場合だけ圧縮する。
さらに、圧縮前の完全な出力も保存し、必要であればAIが直接取得できるようにした。
初期の実装では圧縮し過ぎたことで、AIが元の出力を読み直し、逆にコストが増えるケースもあった。例えば「git diff」の出力も当初は圧縮対象だったが、AIが元の結果を再度確認するケースが発生したため、対象から外した。
最終版では、出力圧縮が発生したオフラインテストにおいて、タスク成功率に統計的に有意な低下は確認されなかった。オンライン実験でも平均コストはわずかに低下し、追跡した品質指標に重大な悪化は確認されなかったという。
2.情報ではなく「不要な書式」を削る
GitHubによると、より安全にトークンを削減できたのが、AIへ渡す情報そのものではなく、不要になった書式を取り除く方法だ。
Copilotは以前、ソースコードをAIモデルのコンテキストに読み込む際、内部の「view」ツールで各行の先頭に行番号を付けていた。これは、かつてファイル編集ツールが修正箇所を指定するために行番号を利用していた名残だ。
しかし現在の編集ツールは、対象となるコードの前後の内容を照合して編集箇所を特定するため、通常のファイル読み込みでは行番号を必要としない。それでも行番号は各行に付与され続けており、AIモデルにとって不要なトークンを消費していた。
そこでGitHubは、viewツールでファイルを読み込む際の行番号を削除した。ソースコードそのものは変更せず、AIが利用しない付加情報だけを取り除いた形だ。
1行ごとの行番号が占めるトークン量はわずかでも、多数のファイルを何度も読み込むAIエージェントでは、その積み重ねが大きくなる。
GitHubによると、この変更によって、AIコーディングのオフラインベンチマークではモデル推論コストが約5%低下した。タスクの成功率は通常の変動範囲に収まり、編集失敗も増えなかった。
Copilot CLIのユーザーを対象に実施したオンライン実験でも、ユーザー1人当たりの1日の平均モデル推論コストが約3%低下した。GitHubが追跡した品質やユーザー満足度の指標にも、重大な悪化は確認されなかったという。
この改善のポイントは、AIが判断するために必要な情報を減らしていないことだ。GitHubは、情報そのものを圧縮する前に、AIが利用していない書式や付加情報を取り除くことで、品質への影響を抑えながらトークン消費を削減した。
3.プロンプトを短くしても「AIの振る舞い」は変えない
GitHubが次に取り組んだのが、AIエージェントに与えるプロンプトの短縮だ。
プロンプトには、AIエージェントがどのように作業すべきかを定める指示が含まれている。こうした指示はモデルを呼び出すたびに送られるため、プロンプトが長ければ、その分だけ毎回トークンを消費する。
Copilotには、複数の専門エージェントを使って作業を並行して進める「task」ツールがある。このツールに関する指示は、ツールの説明やスキーマ、エージェントの定義、システムプロンプトなど複数箇所にまたがっており、徐々に長くなっていた。
そこでGitHubは、Copilot自身にプロンプトの短縮案を作らせ、それを繰り返し改善する「メタプロンプティング」の手法を使い、プロンプトを約半分まで短縮した。
ただし、単純に文章を短くすればよいわけではなかったという。
最初のオンライン実験では、プロンプトを短縮した結果、それまで並列実行できていた独立したエージェントが順番に処理されるようになる問題が発生した。並列処理に関する慎重な指示が、プロンプトの書き換えによって、より厳格な実行ルールに変わってしまったためだ。
GitHubはこの実験を停止し、同じ問題を検出できる回帰テストを新たに追加した。その上で、並列実行に関する指示をより短い1文に書き換えた。
最終的に採用したプロンプトでは、taskツールについてモデルを呼び出すたびに約1300トークンを削減した。セッション全体ではプロンプトトークンを約1.8%減らし、アクティブ時間当たりの正規化コストを約2.9%低減した。GitHubが実施した評価では、品質の低下も確認されなかったという。
この検証から分かるのは、プロンプトの短縮では「文章量」だけでなく、「従来のAIの振る舞いが維持されているか」を確認する必要があることだ。GitHubは、重要な振る舞いをテストしていなければ、プロンプトを短くした際に意図せず失われても気付けないと指摘している。
4.結果を取得するためだけのAI呼び出しをなくす
GitHubは、AIモデルへ渡す情報だけでなく、AIエージェントを動かす仕組みも見直した。Copilotでは、長時間かかるシェルコマンドや、別のエージェントによる調査などをバックグラウンドで実行することがある。その間、メインのAIエージェントは別の作業を進め、バックグラウンド処理が終了すると通知を受け取る。
従来は、この完了通知に処理結果そのものが含まれていなかった。そのためAIエージェントは、処理が終わったことを知った後、結果を取得するためだけにもう一度ツールを呼び出す必要があった。
例えば、シェルコマンドと別のエージェントによる調査がほぼ同時に終了した場合、それぞれについて「結果を取得する」「取得した結果を処理する」というモデル呼び出しが必要になる。GitHubが示した例では、2つの処理結果を扱うまでに計4回のモデル呼び出しが発生していた。
そこでGitHubは、完了したバックグラウンド処理の結果を通知と同時にAIへ渡すようにした。複数の処理が近いタイミングで終わった場合には、結果をまとめて渡す。
これによって、AIは結果を取りに行くためだけのモデル呼び出しをせず、そのまま次の作業に進める。処理結果の内容を圧縮したり要約したりするわけではないため、必要な情報を失わずにモデルとの不要な往復だけを減らせる。
GitHubによると、この変更によってAI Creditsで測定した平均的なトークン関連の利用量は約2.3%減少した。
コスト削減で見るべきは「1回のトークン量」ではない
GitHubの検証で重要なのは、同じコスト削減策でも、全てのCopilotの機能で同じ効果が出るとは限らなかった点だ。
例えば、Copilotのエージェント機能「Copilot code review」で効果が確認されたファイル操作に関する指示の短縮をCopilot CLIでも試したところ、オンライン実験では逆にコストが増えた。このためGitHubは、Copilot CLIにはこの変更を採用しなかった。
一方、ファイル読み込み時の行番号削除や、出力内容に応じた選択的な圧縮は、Copilot code reviewでも効果が確認された。GitHubによると、それぞれレビュー1件当たりの平均プロンプトトークンを約5%削減し、追跡していたレビュー品質の指標に重大な変化は見られなかったという。
本稿は、2026年9月2日にGitHubが公開したHow we make AI coding more cost efficient without sacrificing task qualityを基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社うるる] 「入札市場」攻略ガイド:効率的に落札するためのポイントを徹底解説 -
製品資料
[株式会社うるる] 入札情報に特化した「販路拡大」「効率化」のためのサポートツールとは? -
市場調査・トレンド
[株式会社うるる] 公共入札に成功する企業と失敗する企業の「5つの違い」 -
製品資料
[日本ビジネスシステムズ株式会社] 専門家が教える、Microsoft 365の「テナント統合/分離」を成功に導く秘訣 -
製品資料
[rakumo株式会社] Microsoft 365での情報埋没を防ぐ、社内ナレッジを資産化する情報ポータル活用
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「Microsoft 365」が乗っ取られる MFAを破る“本物の画面”の恐怖
-
2
世界のデータセンター容量は5カ国に69%集中、電力消費「5%の壁」が招くものとは?
-
3
PHP脆弱性「PHP2Shell」で2260万件に影響 情シスの緊急チェックリスト
-
4
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
5
「Windows」の不要なファイルを安全に消して容量を空ける方法
-
6
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
7
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
8
生成AIが普及しても「技術書」を手放せないエンジニアの本音
-
9
AIをデータ保管場所の近くに置くと安全で経済的 それでも残る“破滅的リスク”
-
10
テレワークやBYODでリスクが拡大、デバイスの多様化を弱点としない管理方法とは
ホワイトペーパーランキング PR
-
1
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
2
2026年のサイバーセキュリティには何が必要か? 最新データに学ぶ傾向と対策
-
3
経験豊富な即戦力人材に直接アプローチできる、「攻めの採用」への転換術
-
4
「IT史に名を残すシステム障害」8選
-
5
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
-
6
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
7
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
-
8
AI駆動開発のスピードと安全性を両立 「品質・セキュリティ管理」の実践ガイド
-
9
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
-
10
「標的型攻撃メール」事例・サンプル集
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー