はじめに
2026年6月1日から、GitHub Copilotの課金体系はGitHub AI Creditsベースの使用量課金に移行しました。
GitHub公式ドキュメントでは、Copilotの利用時に以下のトークンが消費されると説明されています。
- 入力トークン
- 出力トークン
- キャッシュされたトークン
また、1 AI credit は $0.01 USD 相当として扱われます。
コード補完とNext Edit Suggestionsは、少なくともGitHub公式ドキュメント上ではAI Creditsの課金対象外です。一方で、Copilot Chat、CLI、Cloud Agent、Spaces、Spark、サードパーティ coding agent などはAI Creditsを消費します。
つまり、今後は「AIを使うかどうか」だけでなく、どれだけトークンを使うか が開発コストに直結しやすくなります。
この記事では、AIエージェントやLLM APIを使うときのトークン削減手法を整理します。
特定ツールの裏技ではなく、LLM APIやAIエージェント全般で使える考え方を中心にまとめます。
3行まとめ
- トークン削減は、入力・出力・モデル選択・コンテキスト管理に分けて考える
- 一番効きやすいのは、静的コンテキストをキャッシュし、不要な文脈を送らないこと
- AIエージェントでは、長い会話を続けるより「調査」「実装」「要約」を分けた方が安定しやすい
トークンコストはどこで増えるのか
まず、LLM APIのコストはざっくり以下で決まります。
コスト = 入力トークン × 入力単価
+ 出力トークン × 出力単価
+ キャッシュ関連トークン × キャッシュ単価
実際の単価やキャッシュの扱いは、モデルやプロバイダーによって異なります。
重要なのは、トークン削減には複数の方向があることです。
| 削減対象 | 例 |
|---|---|
| 入力トークン | 長い設計書、会話履歴、ログ、JSON、コード全文 |
| 出力トークン | 長すぎる説明、重複した要約、冗長な前置き |
| モデルコスト | 高性能モデルを単純作業に使う |
| 再実行コスト | エラー、リトライ、曖昧な指示によるやり直し |
| コンテキスト汚染 | 調査結果や不要なファイル内容が会話に残り続ける |
「プロンプトを短くする」だけでは不十分です。
AIエージェント時代には、どの情報を、どのモデルに、何回送っているか を見る必要があります。
1. 静的コンテキストは上に置き、動的情報は下に置く
入力トークン削減でまず考えたいのが、プロンプトキャッシングです。
プロンプトキャッシングは、同じプロンプトの前半部分を再利用しやすくする仕組みです。
代表的には、以下のような情報がキャッシュと相性がよいです。
- システムプロンプト
- プロジェクト規約
- コーディングルール
- API仕様
- 固定の設計方針
- ツール定義
逆に、以下は毎回変わりやすいので、キャッシュの邪魔になりやすいです。
- 最新のユーザーメッセージ
- ツール実行結果
- 現在時刻
- ランダムなID
- 毎回変わるログ
- 直近の差分
基本形は以下です。
[上: 変わりにくい情報]
- システムプロンプト
- プロジェクト規約
- API仕様
- コーディングルール
[下: 変わりやすい情報]
- 今回の依頼
- 最新の差分
- ツール実行結果
- エラー内容
Anthropicの公式説明では、プロンプトキャッシングにより、キャッシュされた内容の読み取りは通常入力より大幅に安くなります。ただし、キャッシュの書き込みやTTL、cache controlの指定方法はモデルやAPIによって異なります。
OpenAIのAPIにもPrompt Cachingがあり、長い共通prefixを再利用することで、レイテンシや入力コストを下げられる場合があります。
使うサービスごとに仕様が違うため、「キャッシュがあるらしい」ではなく、実際のAPI仕様と課金表を見るのが安全です。
2. 出力を短くする
次に効くのが、出力トークンの削減です。
AIエージェントは、放っておくと以下のような出力をしがちです。
- 長い前置き
- 既に分かっている背景説明
- 似た内容の繰り返し
- コードの全文再掲
- 変更していないファイルの説明
- 最後の一般的なまとめ
これを減らすには、出力フォーマットを明示します。
例えば、調査だけしてほしい場合：
調査結果だけ返してください。
コード全文は不要です。
出力形式:
- 関連ファイル
- 原因候補
- 次に確認すること
各項目は3行以内。
コードレビューの場合：
重大な問題だけを優先してください。
問題がなければ「重大な問題なし」とだけ返してください。
説明は各指摘につき最大3文。
設計相談の場合：
選択肢を3つまでに絞ってください。
各案は以下だけで比較してください。
- メリット
- デメリット
- 採用条件
いわゆる「Caveman Prompt」のように、極端に短い出力を求めるプロンプトも話題になっています。
ただし、こうした圧縮プロンプトは万能ではありません。
向いているのは、以下のような場面です。
- エージェントの説明が長すぎる
- 要点だけ分かればよい
- 何度も同じ形式で結果を返す
- コードではなく調査・分類・要約が中心
向いていないのは、以下です。
- 初心者向けの説明
- 設計書や仕様書の作成
- 誤解を避けたいレビュー
- 顧客向けドキュメント
- コードブロック自体が出力の大半を占める場合
短ければよいわけではありません。
人間が理解できる最小量 を狙うのが現実的です。
3. 大きな入力をそのまま渡さない
ログ、JSON、CSV、DBクエリ結果、長いエラートレースを、そのままLLMに渡すと入力トークンが一気に増えます。
その前に、機械的に削れるものを削ります。
例えば、ログなら以下を削れます。
- 重複行
- タイムスタンプだけ違う同一エラー
- debugログ
- 成功リクエスト
- 関係ないservice名
- 長すぎるstack traceの中間部分
JSONなら以下を削れます。
- null項目
- 空配列
- UI表示に関係ないmetadata
- 重複するフィールド
- 巨大な本文
例：
{
"request_id": "req_123",
"status": 500,
"model": "example-model",
"latency_ms": 12800,
"error_type": "timeout",
"retry_count": 3
}
LLMに見せる前に、人間でも読めるくらいまで削るのが基本です。
AIに「この巨大ログを要約して」と投げる前に、まずプログラムで前処理できないかを考えます。
4. モデルを使い分ける
すべてのタスクに高性能モデルを使うと、コストは増えます。
タスクごとに、必要な能力は違います。
| タスク | 高性能モデルが必要か |
|---|---|
| 誤字修正 | 低い |
| 短い要約 | 低〜中 |
| JSON整形 | 低〜中 |
| 単純なコード変換 | 中 |
| 複雑な設計判断 | 高い |
| 難しいバグ調査 | 高い |
| 複数ファイルをまたぐリファクタ | 高い |
モデルルーティングの基本は、次のような考え方です。
軽いタスク:
安価・高速なモデル
通常の開発タスク:
バランス型モデル
難しい設計・調査:
高性能モデル
ただし、安いモデルを使えば必ず安くなるとは限りません。
精度が足りずに何度もやり直すと、結果的に高くなります。
見るべきなのは、1回あたりの単価だけでなく、完了までの総コスト です。
5. サブエージェントや別セッションで調査を分離する
AIエージェントを長時間使うと、会話コンテキストが大きくなります。
特に重いのは、以下です。
- ファイル探索
- grep結果
- テストログ
- 差分の読み込み
- 複数ファイルのコード全文
- 調査中の仮説
これらをメイン会話に全部残すと、次の依頼でも入力トークンとして積み上がります。
そこで、調査タスクを分離します。
例：
src/auth配下だけを調べてください。
コード全文は返さないでください。
返すもの:
- 関連ファイル
- 認証フローの要約
- 変更が必要そうな関数
- 未確認の点
メインセッションには、要約だけ戻します。
調査結果:
- login.ts が入口
- session.ts でCookieを発行
- middleware.ts で認証チェック
- refresh tokenまわりは未確認
この形にすると、ファイル探索の大量トークンをメインコンテキストに持ち込みにくくなります。
コードから設計書を作るときも同じです。
最初から全コードを読ませるのではなく、まず「必要なクラスと関数だけ抽出」させ、その後で設計書にします。
6. max_tokens と終了条件を決める
APIを直接使っている場合、出力上限を設定できることがあります。
例えば、OpenAI SDKでは max_tokens や max_completion_tokens など、モデルやAPI形式に応じた出力上限パラメータがあります。
実際に使えるパラメータ名はモデル・SDK・APIバージョンによって異なるため、最新ドキュメントを確認してください。
考え方としては、以下です。
分類: 20〜100 tokens
短い要約: 100〜300 tokens
レビュー指摘: 300〜800 tokens
設計相談: 800〜2000 tokens
長文生成: 必要に応じて
分類やルーティングのようなタスクに、長文出力は不要です。
終了条件も明示します。
該当なしの場合は「なし」とだけ返してください。
理由説明は不要です。
これだけでも、不要な出力を減らせます。
7. 会話を長くしすぎない
長い会話は便利ですが、トークンコストが増えやすいです。
特にAIエージェントでは、会話が長くなるほど以下が混ざります。
- 既に解決した仮説
- 古いエラー
- 使わなかった方針
- 途中で捨てたコード案
- 関係なくなったログ
ある程度進んだら、会話を圧縮します。
例：
ここまでの決定事項だけを10行以内でまとめてください。
未解決の論点も分けてください。
そして新しいセッションに、要約だけ持ち込みます。
これは人間の作業でも同じです。
長い議事録を全部読むより、決定事項と次のTODOだけを見る方が速いです。
8. キャッシュしやすいプロジェクト指示を書く
AI coding toolを使う場合、プロジェクト固有の指示を毎回チャットで手入力するより、固定ファイルにまとめた方が扱いやすいです。
例えば、GitHub Copilotでは .github/copilot-instructions.md のようなカスタム指示ファイルを使えます。
書く内容の例：
# Project instructions
- TypeScriptを使う
- package managerはpnpm
- テストは変更した箇所に近いものを優先する
- APIレスポンスの型を勝手に変えない
- 破壊的なDB migrationは事前確認する
ポイントは、毎回変わらないルールだけを書くことです。
以下は入れない方がよいです。
- 今日の日付
- 今回だけのタスク
- 一時的なログ
- 未確定の仮説
- 毎回変わるファイル一覧
静的な指示は静的な場所に置き、動的な依頼はチャットで渡す。
これがキャッシュしやすい構造です。
9. コストを見るためのログを残す
トークン削減は、勘だけでやると外れます。
まず見るべきなのは、実際の利用量です。
LLM APIやAIゲートウェイを使っている場合、以下を見られる状態にしておくと改善しやすいです。
- リクエスト数
- モデル別の利用量
- 入力トークン
- 出力トークン
- 成功 / 失敗
- レイテンシ
- 利用履歴
- モデル料金
例えば、コスト増加の原因が以下のどれかで、対策は変わります。
| 原因 | 対策 |
|---|---|
| 入力が長い | 要約、前処理、キャッシュ |
| 出力が長い | 出力形式、上限、簡潔な回答 |
| 高いモデルを使いすぎ | モデルルーティング |
| リトライが多い | エラー原因の修正、タイムアウト調整 |
| 会話が長い | セッション分割、要約持ち越し |
ログがないと、どこを削ればよいか分かりません。
Flatkeyでできる確認
Flatkeyは、OpenAI / Anthropic互換APIとして使えるAIトークンゲートウェイです。
公開済みの記事や管理画面説明で触れている範囲では、以下のような項目を確認できます。
- APIキーの作成
- クレジット追加
- リクエスト送信
- 残高
- 利用量
- リクエスト数
- 利用履歴
- モデル料金
そのため、base_url を切り替えて小さく検証しながら、どのモデル・どのリクエストでコストが増えているかを見る用途に向いています。
ただし、Flatkey自体がプロンプトを自動で短くする、キャッシュを必ず最適化する、すべてのモデルで同じ削減率を保証する、という意味ではありません。
トークン削減は、アプリケーション側の設計、モデル選択、プロンプト構造、ログ確認を組み合わせて行うものです。
使いどころ早見表
| 状況 | まず試すこと |
|---|---|
| 毎回同じ長い指示を送っている | プロンプトキャッシングを意識した構造にする |
| エージェントの返答が長い | 出力形式と上限を指定する |
| ログやJSONが大きい | LLMに渡す前に前処理する |
| 高性能モデルばかり使っている | タスク別にモデルを分ける |
| 会話が長くなりすぎる | 要約して別セッションに移す |
| 調査で大量ファイルを読む | サブタスクに分けて要約だけ戻す |
| コスト増加の原因が分からない | モデル別・用途別の利用量ログを見る |
まとめ
トークン削減は、単に「短いプロンプトを書く」だけではありません。
実際には、以下を組み合わせます。
- 静的コンテキストをキャッシュしやすくする
- 動的情報を下に置く
- 出力形式を短く指定する
- 大きなログやJSONを前処理する
- タスクに合ったモデルを使う
- 調査と実装を分ける
- 長い会話を要約してリセットする
- 利用量ログを見る
AIエージェントの利用が増えるほど、トークンは見えないところで積み上がります。
まずは、自分の使い方で「入力」「出力」「モデル」「リトライ」のどこが大きいのかを見るところから始めるのが現実的です。