2026年6月1日から、GitHub CopilotはAI Creditsベースのusage-based billingへ移行しました。
これによって、Copilot Chat、Copilot CLI、Copilot cloud agent、Spaces、Spark、third-party coding agentsなどの利用は、入力トークン、出力トークン、キャッシュ済み入力トークンをもとにAI Creditsへ換算されます。コード補完とNext Edit Suggestionsは、有料プランではAI Credits課金対象外のままです。参考: GitHub Copilot is moving to usage-based billing、Usage-based billing for individuals
つまり、Copilotを「補完ツール」として使うだけなら、これまでと大きく感覚は変わりません。
一方で、ChatやCLIやAgentにバグ調査、実装、レビュー、テストまで任せる使い方では、会話が長くなるほどコストが読みづらくなります。GitHubのCopilot CLIドキュメントでも、ユーザーのメッセージ、Copilotの応答、ツール呼び出しと結果、システム指示がcontext windowに保持されると説明されています。参考: Managing context in GitHub Copilot CLI
ここで効いてくるのが、いわゆる「短く答えさせる」運用です。
ただし、採用すべきなのは「原始人みたいな文体」そのものではありません。実務で必要なのは、短く、構造化し、余計な説明を出させないための制約プロンプトです。
私はこれを Terse Technical Mode と呼ぶのがよいと思っています。
結論
Copilot従量課金対策を試すなら、まず次の方針を出発点にするのがよいと思います。
AIには詳しく考えさせる。だが、詳しく喋らせない。
説明を完全に消すのではありません。
原因、根拠、修正、テストコマンドは残す。その代わり、前置き、称賛、一般論、チュートリアル、不要な補足を削る。
これがコストと品質のバランスを取りやすい運用です。
ただし、最初から全員の標準ルールにするのはおすすめしません。まずは一部のタスクで実験し、AI Credits、再質問回数、修正成功率、人間のレビュー時間を見てから広げるのが安全です。
なぜ短い応答がコストに効くのか
CopilotのAI Creditsは、モデルごとのトークン単価に基づいて計算されます。GitHubのモデル価格表を見ると、多くのモデルで出力トークンは入力トークンより高く設定されています。たとえば2026年6月8日時点の表では、GPT-5.5は入力が100万トークンあたり5ドル、出力が100万トークンあたり30ドルです。参考: Models and pricing for GitHub Copilot
単純化すると、節約効果はこう考えられます。
節約率 ≒ 出力削減率 × 全コストに占める出力の割合たとえばGPT-5.5で、入力10,000トークン、出力2,000トークンのChatを考えます。
| 項目 | コスト |
|---|---|
| 入力 | 10,000 × $5 / 1M = $0.05 |
| 出力 | 2,000 × $30 / 1M = $0.06 |
| 合計 | $0.11 = 11 AI Credits |
出力を60%削って800トークンにできると、こうなります。
| 項目 | コスト |
|---|---|
| 入力 | $0.05 |
| 出力 | 800 × $30 / 1M = $0.024 |
| 合計 | $0.074 = 7.4 AI Credits |
この例では、1回あたり約33%の削減です。
もちろん、Agentが大量のファイルやログを読んでいて、入力が100,000トークン、出力が1,000トークンのような場面では、出力削減だけでは効きません。そこでは「短く答えさせる」よりも、「巨大ログを要約して渡す」「最初の調査仮説を明示する」「必要になったら読む範囲を広げる」のほうが重要です。
それでも短い応答には、もう一つ効能があります。
会話履歴が小さくなることです。長い応答は、その場の出力トークンとして高いだけでなく、次のターン以降に会話文脈として再利用されます。CLIやAgentの長い作業では、応答が短いほど文脈の肥大化も抑えられます。
短くすると精度も上がる可能性がある
この話は、単なる節約術だけではありません。
2026年3月投稿のプレプリント Brevity Constraints Reverse Performance Hierarchies in Language Models は、31モデル、5ベンチマーク、合計1,485問を評価し、115問、つまり7.7%の問題で小さいモデルが大きいモデルを上回るinverse scalingを観測したと報告しています。参考: Brevity Constraints Reverse Performance Hierarchies in Language Models
論文の主張で面白いのは、原因を大規模モデルの能力不足ではなく、spontaneous scale-dependent verbosity、つまり大きいモデルほど自発的に冗長になり、過剰説明や過剰推論でミスを混入させる現象として分析している点です。
標準プロンプトでは、大規模モデルが小規模モデルに平均28.4ポイント負ける問題群がありました。しかし、短く答えるよう制約すると、大規模モデルの精度は26.3ポイント改善し、逆転ギャップは67%縮小したとされています。
ここでいう条件は、かなり単純です。
- 通常条件: いつも通り、短さを指定しない
- Brief条件: 短い理由だけ残して答えさせる
- Direct条件: 理由なしで、最終答えだけ出させる
出力長も大きく減っています。大規模モデルの出力中央値は、通常条件で197トークン、Brief条件で78トークン、Direct条件で57トークンです。
ここから実務に持ち帰るべき教訓は、かなり明確です。
推論は有益。ただし、喋りすぎると壊れることがある。
ただし「答えだけ」は常用しない
同じ論文は、短ければ常に良いとは言っていません。
Direct条件、つまり最終答えだけを出す条件では、逆転ギャップはさらに縮む一方、モデルサイズにかかわらず精度低下も出ています。またBoolQのような読解タスクでは、Brief制約の効果が弱く、むしろ少し悪化したと報告されています。
これはCopilot運用でも同じです。
小さな修正やコマンド確認なら「答えだけ」でよい場面があります。しかし、設計判断、セキュリティ、障害調査、レビューでは、判断根拠を消しすぎると人間が確認できません。短くしすぎて再質問が増えれば、結局コストも時間も増えます。
だから、実務ではDirect条件よりBrief条件がよい。
「理由なし」ではなく、「理由を短く」です。
Cavemanは発想として面白いが、常用ルールにはしない
Cavemanというリポジトリも話題になっています。READMEでは、Claude Codeなどのエージェントに短く話させるskill / pluginとして、10件のプロンプト平均で65%の出力削減を主張しています。参考: JuliusBrussee/caveman
さらにREADMEでは、Cavemanが削るのは出力トークンであり、thinking/reasoning tokensには影響しないとも明記されています。
この方向性は実務的です。
ただ、チーム運用にそのまま「原始人文体」を入れると、レビューコメントや設計相談の文面が雑に見える可能性があります。特に顧客向け、経営向け、教育向けの文章では、短さよりも信頼感が重要です。
だから私は、上で解説したBrief制約やCavemanの発想を、そのままCaveman modeとして入れるのではなく、実務向けに Terse Technical Mode として運用するのがよいと思います。
Terse Technical Modeとは、AIの返答を「短いが、技術判断に必要な情報は残る」状態に固定するための運用ルールです。Terseは「簡潔」、Technicalは「技術情報を省略しない」という意味です。
具体的には、次の4つをAIに求めます。
- 前置き、称賛、一般論、チュートリアルを削る
- 原因、根拠、修正内容、テスト方法は残す
- コード、識別子、ファイルパス、コマンド、エラー文は省略しない
- 判断が必要な場合は、リスクと次の1手だけを短く出す
目指すのは、乱暴な短文ではありません。
技術情報を落とさず、余計な文章だけを削ることです。
Copilot機能ごとの効き方
Terse Technical Modeが効く場所と、注意が必要な場所を分けて考えます。コード補完とNext Edit Suggestionsは有料プランではAI Credits対象外なので、ここではChat / CLI / Agent系に絞ります。
| Copilot機能 | 効果 | 理由 |
|---|---|---|
| Copilot Chat | 大きい | 出力と会話履歴を減らせる |
| Copilot CLI | 大きい | 長いセッションほど文脈肥大化を抑えられる |
| Copilot cloud agent | 大きいが入力対策も必要 | 複数モデル呼び出しやツール結果が積み上がる |
| PR review | 中から大 | 指摘だけに絞ると読みやすく、再入力も小さい |
| 設計相談 | 条件付き | トレードオフとリスクは短く残す |
ポイントは、何でも短くすればよいわけではないことです。
短くする対象は、AIの「思考」ではなく「報告」です。
汎用プロンプト
まず、Copilot ChatやCLIの冒頭に入れるなら、このくらいで十分です。
簡潔・技術的に。
前置き、称賛、一般論、チュートリアル不要。
コード、識別子、ファイルパス、コマンド、エラー文は省略しない。
基本は「原因1行」「最小diff」「テストコマンド」だけ。
必要な確認は1問だけ。英語ならこうです。
Be terse and technical.
No preface, no praise, no tutorial.
Preserve code, identifiers, file paths, commands, and error messages exactly.
Prefer:
- cause in 1 line
- minimal diff
- test command
- risks only if blocking
Ask at most one clarification question if required.バグ調査プロンプト
バグ調査では、説明文よりも証拠が重要です。
原因特定だけ。
出力形式:
1. Cause: 1行
2. Evidence: 該当ファイル/行
3. Fix: 最小diff
4. Test: 実行コマンド
前置き、一般論、学習用説明は不要。これで、長い推測や「可能性があります」の連打をかなり減らせます。
修正依頼プロンプト
実装を頼むときは、変更範囲を閉じます。
最小変更で直して。
公開APIは変えない。
返答は「変更ファイル」「要点」「テスト結果」だけ。
長い説明は不要。エージェントに直接編集させる場合は、unified diffだけを要求するより、変更後の検証結果まで短く返させるほうが実務では安全です。
PRレビュー用プロンプト
レビューでは、称賛や要約を削るとかなり効きます。
Blocking issuesのみ。
形式:
L番号: severity: 問題 -> 修正案
最大10件。
称賛、要約、一般論、nitは不要。レビュー対象コードの入力トークンが支配的な場合、出力削減だけでは限界があります。それでも、レビューコメントが短いほど人間も処理しやすくなります。
設計相談プロンプト
設計相談は、短すぎると危険です。判断根拠を残します。
短く。ただし判断根拠は残す。
出力形式:
- Recommendation: 1行
- Why: 3点まで
- Risks: 3点まで
- Next action: 1つこの形式なら、意思決定に必要な情報を残しつつ、長い比較表や教科書的説明を避けられます。
Agent / CLI向けプロンプト
Agent作業では、出力だけでなく入力も設計します。
タスクを小さく進める。
最初に10行以内のplanを出す。
まず対象範囲と調査仮説を明示する。
文脈不足で危険なら、読む範囲を広げる。
各ステップ後の報告は「変更ファイル」「テスト結果」「次の1手」だけ。
長いログは要点だけ引用。Copilotの公式ドキュメントでも、会話の長さ、複雑さ、Agentic features、モデル選択が使用量に影響すると説明されています。参考: Usage-based billing for individuals
つまり、Agentには「短く答えて」だけでは足りません。
「作業単位」「文脈の増やし方」「報告形式」まで指定する必要があります。文脈を削りすぎると、見落としや誤修正が増えて、結局高くつく可能性があります。
チームで試すなら、まず3つから
組織でCopilotのAI Creditsを抑えるなら、いきなり複雑なプロンプト集を全社標準にするより、まず一部チームや一部タスクで3つのルールを試すのが現実的です。
1. Chatより補完を優先する
数行の実装や定型コードなら、Chatに聞かず補完で済ませます。
有料プランでは、コード補完とNext Edit SuggestionsはAI Credits対象外です。ここを使わずに、何でもChatに聞くのはもったいない。
2. ChatとAgentには出力形式を必ず指定する
「このエラーを直して」ではなく、
原因1行、修正diff、テストコマンドだけ。と指定します。
モデルは親切に長く説明しがちです。親切さはありがたいのですが、従量課金下では出力形式で閉じ込めるほうがよい場面が増えます。
3. 予算上限を入れる
組織利用では、プロンプトだけでコスト管理を完結させないほうがよいです。
GitHub Docsでは、Copilot Businessは1ユーザーあたり月1,900 AI Credits、Copilot Enterpriseは3,900 AI Creditsとされています。また、既存顧客には2026年6月1日から9月1日まで、Business 3,000、Enterprise 7,000のプロモーション枠が設定されています。参考: Usage-based billing for organizations and enterprises
さらに、GitHubは予算設定時に Stop usage when budget limit is reached を有効化することを推奨しています。これを有効にしない場合、上限到達時に通知は出ても、利用と課金は継続し得ます。参考: Managing your company’s spending on GitHub Copilot
プロンプトは節約策です。
budget controlsは安全装置です。
両方を入れるべきです。
測るべき指標は「1応答」ではなく「1タスク」
短い応答で1回あたりのAI Creditsが下がっても、再質問が増えたら意味がありません。
ここでいう1タスクは、AI仕様駆動開発で扱う「1つの仕様 / Issue / 修正単位」を指します。基本的には、1タスク = 1セッションで、調査、実装、テスト、レビュー準備まで進める前提です。
評価するときは、1リクエストではなく、1タスク完了あたりで見ます。つまり、1回の応答が安いかではなく、そのセッション全体で完了まで到達できたかを測ります。
| 指標 | 見る理由 |
|---|---|
| AI Credits / task | 最重要。1回の応答ではなく完了単位で見る |
| Re-prompt回数 | 短すぎて聞き返しが増えていないか |
| 修正成功率 | テストが通るか |
| レビュー時間 | 短いが読みにくくなっていないか |
| モデル別消費 | 高いモデルに偏っていないか |
| Agentのツール回数 | 入力側の肥大化を見つける |
特にAgent作業では、出力より入力が支配的になる場面が多くあります。巨大ログ、全ファイル探索、長いツール結果を放置したまま、応答だけ短くしても限界があります。
だから、テストするなら20〜50件くらいの実タスクを集めて、通常プロンプトとTerse Technical Modeを比較するのが現実的です。
見るべきなのは、気持ちよく短くなったかではありません。
少ないAI Creditsで、同じ品質のタスク完了に到達できたかです。
最後に
Copilotの従量課金化で、プロンプトの書き方はコスト管理そのものになりました。
ただ、短さを目的にしすぎると失敗します。
短くするべきなのは、思考ではなく報告です。
詳しく考えさせる。必要な根拠は残す。コード、ファイル名、コマンド、エラー文は省略しない。そのうえで、前置き、称賛、一般論、長いチュートリアルを削る。
このバランスが、Copilot Chat / CLI / Agentを実務で使うときの現実的な節約術です。
一言でまとめるなら、こうです。
詳しく考えさせる。だが、詳しく喋らせない。