GitHub Copilotのトークンコストを下げる使い方：VS Codeの内部実装から逆算する¶
対象 / ポイント
対象: VS CodeとGitHub Copilotで日常的に開発していて、AI Creditsの消費とレイテンシーを下げたい開発者。
ポイント:
- VS Codeのトークン効率化は自動で効くが、効き目はユーザーの使い方で変わる。
- コストを下げる操作は、中断を減らす、MCP・拡張を絞る、対応世代のモデルを使う、の3つだ。
- 長時間放置後の再開やセッション途中の推論強度変更は、キャッシュ失効でコストを押し上げる可能性がある。
GitHub Copilotは2026年6月1日、Premium Request UnitsからGitHub AI Creditsへ移行した。 入力、出力、キャッシュ済みトークンが使用量として計算されるため、エージェントの長い1ターンはそのままコストとレイテンシーに効く1。
VS Code開発チームが公開した最適化は、プロンプトキャッシュ、ツール検索、WebSocket通信という内部実装の話に見える2。 しかし、ユーザー側の操作にもそのまま跳ね返る。
この記事の問いは一つだ。 Copilotで開発する側は、何を意識すればトークンコストを下げられるのか。
結論：実装は自動、効き目は使い方しだい¶
VS Codeのトークン効率改善は、基本的にユーザーが設定するものではない。 プレフィックスのキャッシュも、ツール定義の遅延読み込みも、WebSocket通信も、VS CodeとCopilotのハーネスが内部で行う2。 ユーザーがprompt_cache_retentionやdefer_loadingを書く必要はない。
ただし、その最適化が効くかどうかは使い方で変わる。 キャッシュが再利用されるか、ツール定義が増えすぎるか、対応モデルを使っているかで、同じCopilotでも実コストは動く。
やることは3つに絞れる。
| 操作 | 狙い |
|---|---|
| 中断を減らし、長時間放置後の再開に注意する | プレフィックスキャッシュの再利用を保つ |
| 使わないMCPサーバーや拡張ツールを切る | ツール定義の母数を減らす |
| GPT-5.4以降やClaudeなど、最適化対象のモデルを使う | ツール検索やWebSocketの恩恵を受ける |
実装の詳細は「へぇ」で終わらせてもよい。 大事なのは、キャッシュを壊しにくい進め方と、ツールを増やしすぎない運用である。
なぜ「使い方」が効くのか¶
トークン消費が集中する場所は2つある2。 1つ目は「プレフィックス」、つまり毎回のリクエスト先頭で繰り返される部分だ。 システム指示、ツール定義、リポジトリのコンテキスト、会話履歴がここに含まれる。
この先頭が前回と同じなら、推論プロバイダー側のキャッシュを再利用できる。 キャッシュ済みトークンは未キャッシュ時より最大10分の1程度まで安くなり、最初の応答までの時間も短くなる。 先頭が変われば、その分だけ再計算が増える。
2つ目は「ツール定義」だ。 エージェントが使えるツールは、名前・説明・JSONスキーマを含む定義としてリクエストに載る。 MCPサーバーや拡張機能を増やすほど、ツールの候補も増える。
VS CodeはこれをTool Searchで緩和し、必要なときだけ重い定義を読み込むようにしている2。 それでも、何を接続し、どのツールを常用状態にするかはユーザー側の選択だ。 キャッシュを保つか、ツールを盛りすぎるか。 ここがCopilotユーザー側のレバーになる。
キャッシュを保つ使い方¶
最も効くのは、キャッシュを無駄に捨てないことだ。 標準的なキャッシュは、数分から十数分の無操作で消える場合がある。 その状態で次のリクエストを送ると、先頭の長いプレフィックスをフルコストで再計算することになる2。
VS Codeは、対応するOpenAIモデルでキャッシュ保持を最長24時間まで延長している。 これにより、数十分の休憩を挟んでも安く速く再開しやすくなる。 VS Codeの測定では、40〜60分空いたケースでGPT-5.4のキャッシュヒット率が相対値で919%増えた2。
ただし、24時間を超える放置や、古いモデルでの作業まで救えるわけではない。 丸1日以上寝かせたセッションを再開するなら、コールドスタートに近いコストが発生し得る。 長い作業は、区切りのよいところで完了させるほうが読みやすく、コスト面でも扱いやすい。
もう1つ避けたいのが、セッション途中での推論強度の変更だ。 VS Codeチームは、reasoning effortの途中変更を、コストを静かに押し上げる操作として挙げている2。 重い推論が必要な作業かどうかは、着手前に決めるほうがよい。
MCP・拡張は必要な分だけ有効にする¶
MCPサーバーや拡張機能は便利だが、常時増やせばツール候補も増える。 VS Codeの別記事も、ツールが多すぎるとエージェントが遅くなり、不要な探索や誤ったツール呼び出しが増えると説明している3。
対応モデルではTool Searchが働く。 OpenAIではGPT-5.4以降、AnthropicではClaudeモデル向けにツール定義の遅延読み込みが導入されている2。 使わないツールの重いJSONスキーマを最初から全部積まないため、トークン消費とレイテンシーを抑えやすい。
それでも、ツールの母数が多いほど選択の余地は増える。 普段使わないMCPサーバー、検証中の拡張機能、一時的に使った連携は切っておく。 「必要なときだけ有効にする」が、Copilotのツール環境では堅実な運用になる。
一方で、運用上の余地も広がっている。 Claudeモデルではツール検索がクライアント側へ移され、作業中にMCPサーバーを追加・削除しても反映される2。 さらにGitHubは、ツール名の文字列一致ではなく、Copilotの埋め込みモデルで意図に近いツールを選ぶ仕組みを説明している3。
つまり「全部つなぎっぱなし」ではなく、作業フェーズごとにMCPを切り替えやすくなっている。 調査、実装、デプロイで必要な接続を分けるほうが、ツールの見通しもコストも安定する。
対応世代のモデルを使う¶
これらの恩恵は、対応モデルでないと得られない。 VS Codeの記事では、Tool SearchはGPT-5.4以降、WebSocket通信はGPT-5.2以降のOpenAIモデルで使われると説明されている2。 Anthropic側ではClaude Sonnet 4.6やClaude Opus 4.6を含む実験結果が示されている。
数値で見ると差は大きい。 Tool Searchを使わない場合と比べ、セッション全体のトークン消費は中央値ユーザーでGPT-5.4が8.97%、GPT-5.5が10.92%減った。 Anthropicのサーバー側Tool Searchでは、中央値ユーザーの総トークン消費が18.03%減っている2。
モデル選択に迷うなら、古い世代を固定するより、新しい対応世代か自動選択を使うほうがよい。 安いモデルを選んでも、ツール検索やキャッシュが効かずに長いセッションで膨らむなら、総コストでは不利になる場合がある。
もちろん、すべての作業を強いモデルに寄せる必要はない。 短い質問、局所修正、説明生成は軽いモデルで十分なことも多い。 長いAgent作業だけ、対応世代と予算を意識して選ぶ。 この切り分けが現実的だ。
まとめ：これから来る「コスト可視化」を使う¶
VS Code開発チームは、トークン使用状況とキャッシュ状態を製品内で可視化する取り組みを進めるとしている2。 具体的には、キャッシュが失効した状態でのセッション再開や、途中での推論強度の変更といった「コストを静かに押し上げる操作」を、課金前に知らせる構想だ。
この機能が入れば、落とし穴を感覚ではなく表示で避けられる。 それまでは、次の3つだけ覚えておけばよい。
- 短く区切る: 長い放置を前提にせず、作業単位ごとに完了させる。
- 不要なツールを切る: MCPや拡張は、作業フェーズに必要なものだけ有効にする。
- 対応モデルを選ぶ: 長いAgent作業では、Tool SearchやWebSocketの対象世代を使う。
Copilotの内部実装はユーザーが直接触るものではない。 それでも、使い方はコストに効く。 キャッシュが生きる作業リズム、絞ったツール環境、対応モデルの選択。 この3つが、AI Credits時代のCopilot運用の基本になる。