GitHub Copilot 従量課金時代の考え方——品質を上げることが、トークンコストを下げる

2026年6月、GitHub Copilot は従量課金制（Usage-Based Billing / UBB）へ移行しました。前回の記事「GitHub Copilot が6月1日から従量課金制（Usage-Based Billing）に移行します」では、課金が PRU からトークンベースの AI クレジット方式へ変わること、そして管理者が予算（Budget）をどう設計し、利用状況をどう監視するかを中心に解説しました。

では、予算を整えれば対策は万全かというと、そうではありません。予算はあくまで「上限」です。実際にいくら消費するかを決めるのは、日々の現場の使い方です。

本記事（前編）では、具体的なテクニックに入る前に、その土台となる考え方を整理します。テーマをひとことで言えば——「なぜ、雑に使うと高くつくのか」。そして、その答えが「品質を上げることが、そのままトークンコストを下げることになる」という、一見意外な関係につながっていきます。具体的な実践方法は後編で扱います。

1. 前回のおさらい：UBB とは何だったか

これまでの PRU（プレミアムリクエストユニット）は「何回使ったか」を基準に課金していました。新しい AI クレジット方式では、各インタラクションで処理されたトークンの合計量で使用量を測定します。トークンには、入力（プロンプトや渡すコンテキスト）、出力（AI が生成した応答）、キャッシュ（再利用される過去のコンテキスト）の3種類が含まれます。

つまり、プロンプトが長いほど、応答が長いほど、エージェント的なワークフローを多用するほど、消費するクレジットは増えるということです。なお、コード補完（コード補完機能・Next Edit Suggestions）はこれまで通り無償で、クレジットを消費しません。

課金の仕組みそのものや、管理者が行うべき予算設計・可視化の手順は前回記事に譲り、本記事ではここから先——「使い方とコストの関係」に踏み込みます。

2. Budget は「上限管理」でしかない

UBB では、ユーザー・組織・コストセンター・エンタープライズという複数の階層で Budget を設定し、超過支出に上限を引けます。これは「使いすぎを止める」ためには有効な仕組みです。

ただし、ここを誤解しないことが大切です。Budget は「天井」を決めているだけです。天井を低く設定しても、使い方が変わらなければ、その天井に早く到達して利用が停止するだけで、コストそのものが効率的になるわけではありません。実際、いずれかの Budget が $0 になると、そのスコープのユーザーは利用停止になります。

予算管理は「ガードレール」、つまり事故を防ぐ枠です。一方で、枠の中で無駄なく走るかどうかは、運転——つまり現場の使い方——の問題です。本当にコストを最適化したいなら、消費が発生する源である使い方に手を入れる必要があります。

3. 実際の消費量は、現場の「使い方」で決まる

従量課金時代の本質は、コスト ＝ 処理したトークン量 ＝ 使い方という関係に集約されます。同じタスクでも、どのモデルを選ぶか、どこまでコンテキストを渡すか、工程をどう分けるかによって、消費するトークンは大きく変わります。

ここで意識を切り替えたいのが、いわゆる「エージェント・ギャンブル」です。トークンが安かったころは、エージェントの精度を多少気にしなくても問題になりませんでした。雑に投げて、結果がいまひとつならやり直す——それでもコストは小さかったからです。

しかし従量課金になった今、その「やり直し」のたびにトークン、すなわち費用が出ていきます。雑な使い方は、品質の低下とコストの増加を同時に招くのです。だからこそ、トークンが安かった時代には後回しにできた「精度を上げるためのエンジニアリング上の工夫」が、いまや必須になりました。

4. 品質とコストは同じレバーで動く

GitHub は、エージェントの投資対効果（ROI）を次のように整理しています。

> エージェントの ROI ＝（出力の価値 − トークンコスト）÷ トークンコスト

ポイントは、品質が「価値」を決め、価値が ROI を決めるという関係です。出力の品質が上がれば価値が上がり、ROI が改善します。

そして見落とされがちなのが、品質を上げる工夫（明確な指示、適切なモデル選択、無駄なコンテキストの削減）は、たいていの場合トークン消費そのものも減らすという点です。つまり品質とコストは対立しません。同じ「使い方」の改善で、両方が良くなるのです。「安く使う」と「賢く使う」は、別々の努力ではありません。

では、なぜ「雑に使う」とコストが膨らむのか。ここからは、その理由を仕組みの面から3つ——複合エラー・非決定論・コンテキストの劣化——に分けて見ていきます。

5. 複合エラー問題——失敗は「積み上がる」

エージェントは、複数のステップを連鎖させて動きます。ここで効いてくるのが複合エラー問題です。

仮に1ステップあたりの精度が99%だとしても、50ステップのワークフロー全体では最終的な成功率が約60%まで低下します。1ステップ95%なら、50ステップ後にはわずか8%です。ステップが増えるほど、失敗の確率は急速に積み上がっていくのです。これはエージェント内部のループにも、複数のエージェントを束ねるワークフロー全体にも当てはまります。

ここから導かれる原則はシンプルです。

– 最初に品質を詰める（あいまいなまま走らせない）

– ステップを増やしすぎない

– 誤りを早い段階で止める

これらはいずれも、品質を守ると同時に、やり直しによる無駄なトークン消費を防ぎます。具体的な止め方（テストなどのガードレール）は後編で扱います。

6. LLM は「非決定論的」である

大規模言語モデル（LLM）は、同じ問いに対して毎回まったく同じ答えを返すとは限りません。確率的に次のトークンを選んでいるためです。

これが意味するのは、あいまいな指示は出力が揺れやすく、揺れればやり直しが増え、その分トークンを消費するということです。「とりあえず曖昧なまま投げる」ことが、品質を下げ、同時にコストを押し上げる——その根っこには、この非決定論性があります。だからこそ「明確に指示する」ことが、品質にもコストにも効くのです（明確な指示の書き方は後編で）。

7. コンテキスト・キャッシュ・Context Rot

最後に、トークンが「どこで」消費されるのかを最低限おさえておきましょう。エージェントとのやり取りでは、毎回以下がモデルに送られます。

– 入力トークン：システムプロンプト＋ツール定義＋あなたのプロンプト＋渡したファイル

– 出力トークン：モデルが生成した応答（一般に最もコストが高い）

– キャッシュトークン：同じセッションの2回目以降で再利用される入力（速度とコストを改善する）

ここに、見落とされがちな2つの落とし穴があります。

キャッシュは意外と簡単に壊れる。 GitHub の実測例では、ある推論モデルで2回目のプロンプト時に使えるツールを1つ外しただけで、それまで効いていたキャッシュが無効化され、トークンコストが約65%増加しました。セッションの途中でツールや MCP の構成、システム的な設定を変更すると、キャッシュが壊れて再計算が走るのです。動いている会話の前提は、安易にいじらない——意識するだけで、無駄なコストを避けられます。

「埋められるからといって、埋めるべきとは限らない」（Context Rot）。 コンテキストウィンドウが大きいなら詰め込めばよい、というのは逆効果になることがあります。使用量が50%未満でも、モデルは先頭と末尾を重視して中盤の情報を取りこぼす傾向があり（Lost in the Middle）、50%を超えると直近の情報に引っ張られる傾向が強まります（Recency Bias）。長い会話を延々と続けるより、こまめに区切る方が品質は安定します。

## 8. まとめ：では「どう使えばいいか」は後編で

前編の結論を整理します。従量課金時代は、コスト ＝ トークン ＝ 使い方。予算は上限を引くだけで、消費そのものを減らすのは現場の使い方です。そして**品質とコストは同じレバーで動く**——品質を上げる工夫が、そのままコスト削減になります。複合エラー・LLM の非決定論・コンテキストの劣化（Context Rot）が、「雑に使うと高くつく」理由でした。

では、具体的にどう使えばいいのか。後編「実践ガイド——品質とトークンコストを両立する6つの方法」では、

– タスクに合ったモデルの選び方（Auto Mode）

– コンテキストの絞り方

– 「調査 → 計画 → 実装」への分割

– テスト・リンター・スキャンによるガードレール

– `copilot-instructions.md` / `AGENTS.md` などの設定の永続化

– `/chronicle` 系コマンドによる自己診断

を、日本語と英語のトークン差や切り分けチェックリストとあわせて、今日から使える形に落とし込みます。

GitHub Copilot の導入・運用についてご相談ください

「チームに使い方を定着させたい」「品質とコストの両立の方針を一緒に整理したい」という方は、お気軽にお問い合わせください。

GitHub に関するお問い合わせはこちら

—–

*本記事は、GitHub が公式に提供しているウェビナー資料（エージェントの品質とトークン最適化／Usage-Based Billing）をもとに作成しました。最新情報は [GitHub Blog](https://github.blog/) および [GitHub Docs](https://docs.github.com/en/copilot) をご確認ください。なお、製品の仕様・モデル構成・価格は変更される場合があります。*