トークンコストを10分の1に 「GitHub Copilot」はどう削減したのか：Microsoftが明かす「Visual Studio Code」のハーネス改善事例

Microsoftは、「Visual Studio Code」における「GitHub Copilot」のエージェントハーネスのトークン効率向上の成果を紹介した。

[＠IT]

　自律的に複雑なタスクを遂行する「AIエージェント」の本番投入が始まる中、大きな議論となっているのが、エージェント効率的な実行とコストコントロールの両立だ。特に、「GitHub Copilot」が使用量ベースの従量課金制に移行したことは利用者にとって大きな転換期となった。

　エージェントセッションで消費される全てのトークンが、ユーザーのクレジット、レイテンシ（遅延）、タスクのために割り当てられたコンテキストウィンドウに直接影響を与えるためだ。

　コスト増加の課題に対し、Microsoftは、「何も対策を講じなければAIエージェントが高価になりすぎて実用性を失う」と指摘する。同社のデータによれば、AIモデルは世代が新しくなるたびに、「1タスク当たりのトークン消費量が増加する傾向にある」という。

モデルの世代が進むにつれて1ターン当たりのトークン消費量が増加（提供：Microsoft）

　そこでMicrosoftは、本番環境でのABテストや大規模なオフライン評価を通じて、「Visual Studio Code」（以下、VS Code）における「GitHub Copilot」の継続的な最適化を検証、確認してきた。

　その結果、タスクの成功率を犠牲にすることなく、トークン消費量を最大で10分の1に削減できることを実証したという。どのような取り組みによって達成できたのか、Microsoftが成果とともに解説した。

MicrosoftがVS Codeで実践した4つの削減アプローチと、トークン消費のメカニズム

　Microsoftは、AIエージェントが裏でどのようにトークンを消費するのか、その基本的なメカニズムを次のように解説している。

プロンプトプレフィックス

　コーディングエージェントのセッションでは、システム指示、ツール定義、リポジトリのコンテキスト、会話履歴など、各リクエストの大部分がターンをまたいで繰り返される。この繰り返される冒頭部分は「プロンプトプレフィックス」と呼ばれる。

　後続のリクエストで同じプレフィックスが共有される場合、推論プロバイダーは、キャッシュされたモデル状態を再利用し、一からの再計算を省略できる。キャッシュ再利用により、トークンコストは最大で10分の1に抑えられ、レイテンシも大幅に軽減されることから、Microsoftはプロンプトキャッシュのヒット率を高く保つことを目指している。

プロンプトの構成要素を可視化した「Cache Explorer」の画面（提供：Microsoft）

ツール定義のオーバーヘッド

　ツール定義のオーバーヘッドも大きなコスト要因となる。エージェントは、MCP（Model Context Protocol）サーバ、組み込みツール、拡張機能によって提供されるツールなど、多数のツールを呼び出す場合がある。各ツールは、完全な定義（名前、説明、JSON形式の完全なパラメータースキーマ）がリクエストのたびにモデルへ送信され、全てコンテキストに読み込まれていた。

　そこでMicrosoftは、モデルがツール定義をオンデマンドで読み込める「ツール検索」を実装した。モデルにはまず、遅延読み込みされる各ツールの名前と説明だけが提示され、より重いパラメータースキーマは、モデルがツールを検索して読み込むまで、コンテキストの外に置かれる。

　遅延読み込み対象のツールは、コンテキストウィンドウの先頭ではなく末尾に追加されるため、キャッシュ済みプロンプトプレフィックスのメリットは、ターンをまたいで持続する。

OpenAIモデルでのトークン効率向上における成果

　Microsoftは、トークン効率の向上を通じてCopilotユーザーの使用コストとレイテンシを削減することを目指し、OpenAIモデルに関しては、キャッシュされたモデル状態の保持期間の延長、ツール定義のオーバーヘッド削減、WebSocketへの移行を重点的に進めてきた。

プロンプトキャッシュの保持期間を24時間に延長

　OpenAIモデルは、プロンプトプレフィックスを自動的にキャッシュする。キャッシュされた入力の課金に対応するほとんどのモデルでは、キャッシュされていない入力トークンのコストは、キャッシュ入力トークンの10倍だ。

　デフォルト（既定）では、キャッシュは高速なGPUメモリに置かれ、約5〜10分間アクセスがないと破棄される。「prompt_cache_retention」パラメーターを「24h」に設定すると、キャッシュは大容量で低速のGPUローカルストレージに移され、最大24時間保持される。これにより、長時間の中断後も、作業再開は高速かつ低コストのままとなる。

　VS Codeで同設定を有効化した後、キャッシュヒット率は大幅に上昇した。上昇幅はリクエスト間隔が長いほど大きく、「GPT-5.4」では、リクエスト間隔が40〜60分の場合に919％増（従来値の10.19倍）に達した。

リクエスト間隔	GPT-5.2	GPT-5.3-Codex	GPT-5.4
10〜20分	+13％	+32％	+10％
20〜30分	+135％	+142％	+137％
30〜40分	+301％	+203％	+679％
40〜60分	+338％	+279％	+919％
プロンプトキャッシュの保持期間を延長する設定を有効化した後のキャッシュヒット率の相対的上昇率（リクエスト間隔別）

ツール検索によるオンデマンド読み込み

　GPT-5.4以降で利用できるOpenAIのネイティブなツール検索は、「defer_loading」フラグで遅延読み込みを実装している。4日間のVS Code実験では、ツール検索により、ターン当たりのトークン使用量、最初のトークンが返るまでの時間（TTFT：Time To First Token）、完了までの時間（TTC：Time To Complete）が削減された。

　セッション全体では、Copilotユーザーの中央値で、総トークン使用量がGPT-5.4で8.97%、GPT-5.5で10.92％減少した。

指標	モデル	変化率
1ターン当たりの総トークン使用量（P50）	GPT-5.4	-9.81％
1ターン当たりの総トークン使用量（P50）	GPT-5.5	-8.61％
TTFT（P50）	GPT-5.4	-6.88％
TTFT（P50）	GPT-5.5	-7.34％
TTC（P50）	GPT-5.4	-5.31％
TTC（P50）	GPT-5.5	-5.42％
ツール検索によるトークン効率化効果（4日間の実験後、p50は中央値）

WebSocketへの移行による遅延削減

　コーディングエージェントのターンでは、推論プロバイダーへの多数の逐次的リクエストが発生することがある。モデルがツールを呼び出し、処理を実行するステップごとに1回ずつ、APIリクエストが発生するためだ。

　これに対し、MicrosoftはOpenAIが公開している「Responses API」のWebSocketモードを導入し、永続的な接続を維持することで、こうしたリクエストに対して低レイテンシの継続パスを提供した。これにより、接続（コネクション）専用のインメモリキャッシュから最新の応答（レスポンス）状態を再利用でき、長大なツール呼び出しチェーンにおける継続オーバーヘッドを削減できるようになったという。

　VS Codeの安定版では、WebSocketの導入により、HTTP比でTTFTの中央値（p50）が、GPT-5.3-Codexで19.46％、GPT-5.4で16.37％低下した。

　WebSocketは現在、VS Code、Copilot CLI、GitHubアプリなどCopilot製品全体で、GPT-5.2以降のOpenAIモデルにおけるデフォルトの通信プロトコルになっている。

指標	パーセンタイル	GPT-5.3-Codex	GPT-5.4
TTFT	p50	-19.46％	-16.37％
TTFT	p95	-12.92％	-15.78％
完了時間（ターン単位）	p50	-13.55％	-11.74％
完了時間（ターン単位）	p95	-7.86％	-6.26％
WebSocketによるHTTP比のレイテンシ低減率（低いほど良い。p95は95パーセンタイル値）

Anthropicモデルでのトークン効率向上

　MicrosoftはAnthropicモデルについては、プロンプトキャッシュのブレークポイントのより意図的な使用と、ツール検索によるツール定義の遅延読み込みに取り組んだという。

キャッシュブレークポイントの最適化

　Anthropicモデルのプロンプトキャッシュでは、呼び出し側が明示的に「cache_control」ブレークポイントを配置し、APIが各マーカーまでの全てをキャッシュする。リクエスト当たりのブレークポイントの割り当て数は少なく固定されているため、配置場所が重要だ。Microsoftは「Messages API」のキャッシュ処理を見直し、最大4つのブレークポイントを次のように計画的に配置した。

• ターン間で最も変化が少ない部分である、ツール定義の末尾とシステムプロンプトの末尾
• キャッシュ可能な最新の2つのメッセージに置く一対のローリングアンカー

　2つのアンカーのうち古い方は、最新のアンカーがキャッシュミスした場合の安全網として機能する。これらの変更により、キャッシュヒット率は数ポイント上昇した。プレフィックスが長く、ターンが立て続けに発生するエージェント型ワークロードでは、約94％に達した。これにより、使用コストとTTFTの両方が削減される。

クライアントサイドへのベクトル検索移行

　Anthropicモデルのツール検索では、ツールに「defer_loading: true」を指定する。一方、ファイルの読み取りと編集、ターミナルコマンドの実行、ワークスペースの検索といった厳選されたコアツールを読み込んだ状態を保ち、一般的な操作では余分なステップを不要にしている。

　Microsoftはまず、Anthropicのサーバサイド検索でこの仕組みを導入した。この方式では、APIが検索に一致したツールをインラインで「tool_reference」ブロックに展開する。VS Codeでの7日間の実験では、Copilotユーザーの中央値で、セッション全体のプロンプトトークン使用量と総トークン使用量がいずれも約18％減少した。

指標	パーセンタイル（集計単位）	変化率
最初のチャンクまでの時間	p50（ターン単位）	-2.45％
総プロンプトトークン	p50（ターン単位）	-11.30％
総プロンプトトークン	p95（ターン単位）	-8.85％
総プロンプトトークン	p50（ユーザー単位）	-18.32％
総トークン	p50（ターン単位）	-11.09％
総トークン	p95（ターン単位）	-8.74％
総トークン	p50（ユーザー単位）	-18.03％
Anthropicのサーバサイドツール検索によるトークン効率化効果（7日間の実験後）

　その後Microsoftは、検索処理をクライアントサイドに移行した。社内製のCopilot埋め込みモデルを利用し、クエリと利用可能な全ツールのベクトル表現を照合して、文字通りのキーワードではなく、意図に基づいて適切なツールを検索できるようにした。

　これにより、トークンの節約以外にも、サーバサイドとの往復を伴わないローカルな応答性、セッション中に追加、削除されたMCPツールの即時反映、ツール選択品質の向上といった利点が得られた。VS Codeの安定版への導入から2週間を経て、以下のようにレイテンシとユーザーエラー率が低下した。

指標	モデル	変化率
TTFT（p50）	Claude Opus 4.6	-1.91％
完了時間（p50）	Claude Opus 4.6	-1.97％
完了時間（p95）	Claude Opus 4.6	-2.57％
完了時間（p50）	Claude Sonnet 4.6	-1.30％
完了時間（p95）	Claude Sonnet 4.6	-3.35％
ユーザーエラー率	Claude Sonnet 4.6	-4.01％
クライアントサイドツール検索による追加の効率化効果（導入2週間後）

今後の展開

　Microsoftは今後、ワークスペースの検索、コマンドの実行、結果の要約など、特定タスクをメインエージェントから切り離し、専門サブエージェントに委任する計画だ。これらのサブエージェントには、小規模で安価なモデルを採用し、メインモデルのコンテキストウィンドウの節約や、タスク全体のコスト削減を達成可能になるとしている。

　同社はトークン使用量とキャッシュ状態に関する透明性の向上にも取り組み、キャッシュ失効後のセッション再開など、気付かない間にコストを押し上げる操作を警告できるようにする計画だ。