2026年6月1日から GitHub Copilot の課金体系が変わりました。
X（Twitter）では日本でも海外でも辛辣な意見ばかり出ています。Claude Sonnetのクレジット消費量が旧制度の9倍、Claude Opusにいたっては27倍という数字が一部ユーザーから報告されていて、Agent modeを日常的に使っていた人には事実上の大幅値上げです。
この騒ぎを受けて「そもそもトークンをどうやって節約するか」という話を調べてみました。
今回はX（Twitter）で主に海外勢のトークン節約についての情報を収集しています。
Netflixのエンジニアが作ったトークン圧縮ツール「Headroom」については以前投稿した記事を参照してください。今回はそれ以外の手法を中心にまとめます。
3行まとめ
- GitHub Copilotが6/1から従量課金に移行し、Agent mode多用者は実質大幅値上げ
- 出力削減には ケイブマン（原始人）プロンプト、入力削減には プロンプトキャッシング が現状の二大手法
- 設計書→コードにはキャッシング戦略、コード→設計書にはサブエージェント分離が現実的な正解
まず、何が変わったのか
旧制度では「プレミアムリクエスト」という単位で管理されていました。GPT-4oやClaude Sonnetを呼ぶたびに一定のプレミアムリクエストを消費して、上限を超えると低品質モデルに自動的に切り替わる設計です。上限に達しても完全停止はしない、という安全装置つきでした。
新制度の「GitHub AI Credits」はトークン消費量ベースの従量課金です。1 AI Credit は ドル換算でおおよそ $0.01 相当（目安） で、入力・出力・キャッシュトークンがモデルごとの単価で計算されます。
プラン別の月次付与クレジットはこんな感じです。
| プラン | 1か月あたりの価格 | 基本クレジット | フレックス割り当て | 毎月の合計 AI credits |
|---|---|---|---|---|
| Copilot Pro | $10 | 1,000 | 500 | 1,500 |
| Copilot Pro+ | $39 | 3,900 | 3,100 | 7,000 |
| Copilot Max | $100 | 10,000 | 10,000 | 20,000 |
※Pro/Pro+ はフレックス割り当てを含む
※出典：GitHub 公式ドキュメント - 個人の使用量ベースの課金
月額は据え置きで、同額相当のクレジットが付与される、という建て付けです。
コード補完は無料のまま
重要なので強調しておきます。インライン補完とNext Edit提案はAI Creditsを消費しません。 全プランで 現時点では 無制限のままです。騒ぎになっているのはチャット・Agent mode・コードレビューです。
Agent modeがなぜ急激に高くなるのか
チャットで短い質問をする場合、入力500トークン・出力200トークン程度なら消費クレジットはかなり小さく、1回あたりでも大した額にはなりません。
Agent modeは違います。「この機能を直して」という一言に対して、エージェントが複数ファイルを読み込み、ツールを呼び出し、直前の文脈を再投入し、実装と検証を繰り返します。一つの依頼が内部で何十回ものモデル呼び出しに分解されて、入力と出力が積み上がります。しかも旧制度のフォールバックが廃止されたので、クレジットを使い切ったら機能停止（コード補完は継続）です。
X（Twitter）で話題になっていた4つの削減手法
1. Caveman Prompt（出力トークン削減）
2026年3月ごろ、GitHubに JuliusBrussee/caveman というリポジトリが登場して数日で数千スターを獲得しています。
発想はシンプルで、「LLMを原始人みたいに喋らせる」 というものです。
※Caveman（ケイブマン）= 原始人
# Caveman Mode
- No filler
- No grammar if not needed
- No repetition
- Use keywords, arrows, symbols
- Compress aggressively
- Assume user smart
Output = shortest correct answer possible
普通のLLMはこう答えます。
「JOINを使うことができます。SQLでは、共通のキーを使って2つのテーブルからデータを結合する際にJOIN句を活用できます。」
Caveman Modeだとこうなります。
「JOIN 使う」
意味は同じ。トークン数は大違いです。
実際のところ何%削れるのか
「75%削減」という宣伝文句で広まりましたが、検証した人たちの数字はこうなっています。
| 検証者 | 条件 | 削減率 |
|---|---|---|
| 作者側ベンチマーク | コーディングタスク全般 | 最大75% |
| Kuba Guzik | Claude Sonnet/Opus, 18回 | 14〜21% |
| Better Stack | 独自ベンチ | 45%（出力のみ） |
Headroomのときと同じ構図で、「コードブロック自体は圧縮されない」という仕様が数字を押し下げます。出力の大半がコードなら効果は限定的です。
簡潔にさせると精度が上がる
2026年3月のarXiv論文（arXiv:2604.00025）によると、31モデルを1,485問で評価したところ、簡潔さを制約したほうが大型モデルの精度が上がるケースがあるとわかりました。
大型モデルが余計な説明を書くうちに自分で混乱する現象（spontaneous scale-dependent verbosityと呼ばれている）が原因のようです。コストだけでなく品質にも良い方向に働く可能性があります。
単発クエリには使わないほうがいい
Caveman Promptのシステムプロンプト本体は 数百トークン あります。単発のクエリだとこの追加コストが削減分を上回ります。複数ターンの会話でプロンプトキャッシングが効いてくると話が変わります。
向いているシーン：
- 長いエージェントセッションを繰り返す（キャッシングが効く）
- コードではなく説明・分析・サマリを生成させている
- エージェントが同じ問いを何度も繰り返すパイプライン
向いていないシーン：
- 単発の質問
- 出力の大半がコードブロックのとき
- 詳細な説明が必要なドキュメント生成
2. プロンプトキャッシング（入力トークン削減）
GitHub Copilotの新料金体系でもキャッシュトークンの単価は入力より安い設定です。これを意識した設計をするかどうかで、同じ作業をしても請求額が変わります。
仕組みのおさらい
LLMが同じテキストを毎回最初から読み直すのは非効率です。AnthropicはKV（Key-Value）キャッシュという仕組みで、一度読んだプレフィックスの計算結果をサーバーに保存します。2回目以降は 90% 割引（Anthropic 公式） です。
X（Twitter）でも キャッシュによる大幅なコスト削減 が報告されています。
静的なものを上に、動的なものを下に
# キャッシュが効く配置（順番が命）
[上に置く：静的なもの]
- システムプロンプト
- プロジェクト規約・制約
- ツール定義
[下に置く：動的なもの]
- 会話履歴
- ツール実行結果
- 最新のユーザーメッセージ
Anthropic APIではキャッシュブレークポイント（cache_control）の指定が必要ですが、Copilotや各種AIエージェントでは内部的に同様のキャッシュ戦略が利用されているため、静的な情報を先頭に配置する設計が一般に推奨されています。
2026年4月29日にリリースされた VSCode 1.118 ではGitHub Copilotのキャッシュ周りがかなり最適化されています。
VSCodeをしばらく更新していない方は、最新化するだけでも効果が実感できるかもしれません。
Visual Studio Code 1.118 - 公式リリースノート
GitHub Copilotでユーザーが意識的にキャッシュを効かせる方法
- .github/copilot-instructions.md（カスタムインストラクション）に静的なプロジェクト規約を書く → 毎セッション同じテキストが先頭に来るので内部キャッシュが効きやすい
- セッション中にモデルを切り替えない → キャッシュが壊れる
- プロンプトファイル（.prompt.md）にルールを外出しする → 再利用のたびにキャッシュが使われやすくなる
キャッシュを効率的に使う上でやってはいけないこと
システムプロンプトにタイムスタンプを埋め込む、セッション中にモデルを切り替える、ツール定義の順番を変える。
これらはいずれもキャッシュミスを引き起こします。
3. モデルルーティング ── 適材適所でクレジットを温存する
Copilotの新体系で特に重要になった考え方です。高性能モデルを全部のタスクに使うのは、タクシーで通勤するようなものです。
Copilotで利用できる主なモデルのコスト感（クレジット消費量はモデルの実際のトークン単価に基づく）
※モデルラインナップはクライアントやプランにより異なります。最新はモデルピッカーで確認を
| モデル群 | コスト感 | 向いている作業 |
|---|---|---|
| Gemini Flash・GPT mini系・Claude Haiku | 安価 | 軽作業・定型作業 |
| GPT-5系・Claude Sonnet系・Gemini Pro系 | 中程度 | 通常の開発タスク |
| GPT-5.5・Claude Opus系 | 高価 | 複雑な設計・難しい問題解決 |
一部ユーザーから報告されているClaude Sonnetのマルチプライヤは旧制度比9倍、Opusは27倍です。Pro（月1,500クレジット）でOpus系を使い倒せば、数日で枯渇します。
ですからまずAutoモードの存在を中心に据えるべきです。AutoモードではCopilotがリアルタイムのシステム健全性・可用性を追跡しながらタスクの複雑さ（推論、コード生成の複雑さ、バグ診断の難易度、ツールオーケストレーションの必要性）を評価し、最適なモデルを自動選択します。
キャッシュを効かせるためにモデルの切り替えはNGとされていますが、Autoモードはキャッシュの境界を意識してルーティングするよう設計されています。その意味でもAutoモードはコスト最適化との相性が良い仕組みと言えます。
※AutoはOpus等の高コストモデルをルーティング対象から除外しているのでOpus等を使いたいなら手動指定が必要です。
4. サブエージェント分離（コンテキスト汚染防止）
ファイル探索・grep・テスト実行など「読み込みが重い操作」を別のコンテキストウィンドウに追い出して、メインの会話を軽量に保つアプローチです。
Agent modeでファイルを大量読み込みさせると、入力トークンが積み上がります。サブエージェントに調査を委任して要約だけ返させると、メインコンテキストへの影響が最小限になります。
こう指示する
src/auth配下の認証フローを調べて、
シーケンス図に必要なクラスとメソッドだけを
箇条書きで返してください（コード本体は不要）。
これだけで、ファイル探索のコストがメインセッションに乗ってこなくなります。
手法の使いどころ早見表
| シーン | 主な問題 | 推奨手法 |
|---|---|---|
| DBクエリ結果・ログ・JSON が重い | 入力トークン過多 | Headroom |
| エージェントの説明が長い | 出力トークン過多 | Caveman Prompt |
| 同じシステムプロンプトを何度も送る | 入力の繰り返し | プロンプトキャッシング |
| ファイル探索・調査で文脈が肥大化 | コンテキスト汚染 | サブエージェント分離 |
| 単純タスクにOpusを使っている | モデル過剰 | モデルルーティング |
組み合わせることもできます。Caveman Promptをシステムプロンプトに入れておけば、追加プロンプト部分はキャッシュ対象 になるため、オーバーヘッドを抑えつつ出力削減効果を得られます。
設計書→コード、コード→設計書の場合
Headroomはこの2つに効かないと前回書きました。では何を使えばいいか。
設計書→コード
一番効くのは プロンプトキャッシング です。設計書は「毎ターン変わらない静的テキスト」なので、キャッシュとの相性が抜群です。copilot-instructions.mdに設計書の要約や規約を書くことで仕様追加や修正のたびにフルコストで読み直す必要がなくなります。
コード→設計書
サブエージェント分離 が現実的な正解です。コードを全部メインコンテキストに読み込ませるとあっという間に埋まります。「必要なクラスとメソッドだけ箇条書きで返して」という委任タスクを噛ませることで、メインへの流入量を大幅に削れます。
なお、設計書の出力にCaveman Promptを使うのはおすすめしません。設計書が原始人語になります。
さいごに
GitHub Copilotの料金改定は「料金表が変わっただけ」ではなく、「何をどのモデルでどう使うか」を改めて考えさせるきっかけになっています。
Agent modeを脳死で使っているとあっという間にクレジットが溶けます。ただ、コード補完は 現時点では 無制限のままなので「チャットとエージェントだけ気をつける」というのが当面の現実的な方針です。
Copilotのダッシュボードにモデル別・機能別の消費量が見えるようになっているので、まず自分の消費パターンを確認してから対策を選ぶのが順序だと思います。試した方、感想をコメントで教えてください！
※他にもトークン代を節約するNetflixのエンジニアが作ったツール「Headroom」について調べてみたので、こちら↓の記事もご覧ください。