AIコーディングエージェントのトークンとコストを減らすために意識したい8つのこと

はじめに

Claude CodeやCodex、GitHub CopilotなどのAIコーディングエージェントを使っていると、

• 思ったより早く利用上限に達する
• API利用料が思ったより高い
• 何にそんなにトークンを使っているのか分からない

と感じることがあります。

AIのトークン削減というと、「プロンプトを短くする」「安いモデルを使う」といった方法を思い浮かべがちです。

しかし、AIコーディングエージェントでは、ユーザーが入力した文章だけでなく、

• 会話履歴
• 読み込んだコードやファイル
• ツールの実行結果
• テストやコマンドのログ
• AGENTS.md / CLAUDE.mdなどの指示
• MCPやツールの定義
• 推論（Reasoning）
• サブエージェントの処理

などもモデルとのやり取りに使われます。¹

さらに、Agentは1回の依頼に対して1回だけモデルを呼び出すとは限りません。コードを調べ、ツールを実行し、その結果を受けて再び推論する、といった処理を繰り返します。

この記事では、GitHub、OpenAI、Anthropicなどの公式ドキュメントをもとに、AIコーディングエージェントのトークン消費・コストを抑えるために、実務で意識しやすいポイントを整理します。

製品によってキャッシュ、課金、コンテキストの扱いは異なります。

この記事では、Claude Code、Codex、GitHub Copilotなどに共通しやすい考え方を、各製品の公式情報で確認しながら整理します。モデル名や料金などの具体例は、Codexを中心に扱います。製品ごとに挙動が異なる部分は個別に補足します。

まず知っておきたい：トークン数とコストは同じではない

トークンを減らすことと、最終的なコストを減らすことは同じではありません。

具体例としてCodexを見ると、GPT-5.6系のCodex向けクレジット換算は次のようになっています。¹

Model	Input	Cached input	Output
Sol	125	12.5	750
Terra	50	5	300
Luna	5	0.5	30

LunaはTerraの1/10の単価です。また、cached inputは通常inputの1/10になっています。

そのため、モデル切り替えで一時的にキャッシュが効かず入力トークンが増えても、軽量モデルへの単価差が大きければ総コストは下がることがあります。逆に軽量モデルで失敗を繰り返せば、最初から上位モデルを使うより高くつくこともあります。

見るべきなのは1回の入力トークン数ではなく、

• input
• cached input
• reasoning
• output
• モデル単価
• Agentのターン数
• 手戻り

まで含めた、タスク完了までの総消費です。

---

1. プロンプトを短くするより、探索範囲を明確にする

「トークン削減 = プロンプトを短くする」と考えると、必要な情報まで削ってしまいがちです。

例えば、

この認証処理をいい感じにリファクタリングして

だけでは、Agent側で「どのファイルを見るのか」「何を問題とするのか」「どこまで変更してよいのか」を調べる必要があります。

それよりも、

対象:
- AuthService.java

目的:
- refresh token更新処理の重複をなくす

制約:
- public APIは変更しない
- DBスキーマは変更しない
- 認証方式自体は変更しない

完了条件:
- 既存テストがすべて成功する
- AuthServiceTestに重複処理のテストを追加する

のように、対象・制約・完了条件を明示した方が、Agentが余計な探索や試行錯誤をする余地を減らせます。

GitHubも、曖昧なプロンプトは意図の推測、余計なコンテキスト探索、scope driftやretryにつながるとしており、明確なタスク、必要なコンテキスト、終了条件を与えることを推奨しています。²

入力そのものを数十トークン減らすより、Agentの余計な1ターンを減らす方が効果が大きい場面は多いはずです。

---

2. コンテキストを必要以上に増やさない

Agentが読む情報は、すべて無料ではありません。

特に増えやすいのが、

• repository全体の検索
• 巨大なログやtest output
• AGENTS.md / CLAUDE.md
• MCPやツール定義
• 自動生成ファイル

などです。

例えばテストが大量のログを出す場合、最初から最後までAgentへ渡す必要はありません。失敗したテストと周辺のstack traceだけで十分なら、そこへ絞った方が効率的です。Anthropicも、10,000行のログをHookで絞り込み、数万トークン相当のコンテキストを数百トークンまで減らす例を紹介しています。³

同じ考え方で、repository全体ではなく対象ディレクトリから調べる、巨大なログではなくERROR周辺だけ取得する、生成物やvendorディレクトリを検索対象から外す、変更確認にはgit diffを使う、といった工夫ができます。

AGENTS.mdやCLAUDE.mdも常時読み込まれる分だけコンテキストを使います。GitHubやAnthropicは、framework、build/test方法、チーム固有のルールなど毎回必要な情報に絞り、特殊なworkflow向けの指示は必要時に読み込む仕組みへ分離することを推奨しています。²³

MCPやツール定義も同様です。現在のClaude CodeやVS Codeには必要なtool definitionsだけを遅延ロードする仕組みもあるため、「MCPを追加すると必ず大幅に増える」とは言えません。³⁴ それでも、使わないMCP serverや大量のツールを常時有効にしておく必要はありません。

---

3. タスクが変わったらセッションも分ける

会話を続けるほど、それまでに読んだファイルやツールの実行結果、会話履歴がコンテキストとして積み上がります。

同じ問題を、

「原因調査 → 修正 → テスト」

まで続けるなら、そのまま同じセッションを使う意味があります。

一方、認証機能の修正が終わったあとに、README修正、別Issueの実装、別機能の設計相談まで同じセッションで続ける必要はありません。

GitHub Copilotでは、新しい問題へ移る際には新しい会話を開始し、同じ問題のまま履歴が長くなった場合は/compactで要約することが推奨されています。²

Claude Codeでも、無関係なタスクへ移る際に/clearすることがコスト削減策として案内されています。³

覚え方としては、

• 同じ問題なら続ける
• 同じ問題のまま長くなったらcompact
• 問題そのものが変わったら新しいセッション

で十分です。

---

4. タスクを整理して、安いモデルでも解ける状態にする

モデル選びは「何行変更するか」より、Agentにどれだけ判断させる必要があるかで考えると分かりやすくなります。

製品によってモデル名や性能差は異なりますが、考え方自体は共通しています。

Codexでは、OpenAIがGPT-5.6系を次のように位置づけています。⁵

Model	向いている作業
Sol	曖昧・複雑で、分析や判断が多い仕事
Terra	日常的な開発、ある程度の推論やツール操作が必要な仕事
Luna	何をすればよいか明確な、反復可能な仕事

Claude CodeやGitHub Copilotでも利用できるモデルや選択方式は異なりますが、「判断の余地が大きい仕事ほど強いモデルを使い、作業が明確になるほど軽量なモデルを使う」という考え方自体は共通します。²⁶

軽量モデルは「タイポ修正専用」というわけではありません。

例えば100行以上の変更でも、

• 詳細設計が完成している
• 変更対象が決まっている
• 既存実装と同じパターンで作ればよい
• 完了条件やテスト観点が決まっている

なら、Agent側で考える余地はかなり減っています。こうした作業は軽量モデルでも十分処理できる可能性があります。

逆に1行の変更でも、原因不明のrace conditionを調査し、安全な修正方法まで考えさせるなら難しい仕事です。

設計を先に固めると、実装を軽量モデルへ渡せる

例えば最初から、

「要件を調べて、設計して、実装して、テストして」

と丸ごと強いモデルへ任せるのではなく、調査・設計までは強いモデルや中間モデルで行い、詳細な実装計画をMarkdownに残したあと、その計画に沿った実装を軽量モデルへ任せる方法があります。

GitHubも、計画では強いreasoningモデルを使い、計画済みの実装ではより安価なモデルを使うという分け方を推奨しています。²

Codexなら、SolやTerraで調査・設計した内容をMarkdownに残し、その計画に沿った実装をLunaへ引き継ぐ、といった運用ができます。

つまり設計を具体化することは、単にAIへの説明を丁寧にするだけではありません。

難しい問題を、より安いモデルでも解ける問題へ変換することにもつながります。

---

5. Thinking Effortは必要なときだけ上げる

Thinking Effort / Reasoning Effortを変更できる製品では、これもコストへ影響します。

高いEffortではより深い推論が行われますが、その分reasoning tokenも増えます。OpenAIではreasoning tokenもoutput tokenとして課金されます。⁷

そのため、

• rename
• format
• 既存パターンに沿った実装
• 明確なテスト追加

のような仕事に毎回Highを使う必要はありません。

一方、

• 原因不明の障害
• architecture設計
• 複数案のtrade-off比較
• 複雑な並行処理の問題

などでは、Effortを上げる意味があります。

OpenAIはCodexについて、まず標準のEffortから始め、深い分析が必要な場合に上げることを案内しています。⁵ Claude Codeなど、同じモデル内でEffortを調整できる製品でも基本的な考え方は同じです。⁸

モデルとEffortは別の軸なので、「軽量モデルだから常にLow」「強いモデルだから常にHigh」と固定するより、作業内容に合わせて考える方がよさそうです。

---

6. 進行中のタスクでモデルや設定を頻繁に切り替えない

途中でモデルを変更すると、製品によってはprompt cacheが効かなくなります。

GitHub Copilotでは、セッション途中のモデル変更、reasoning effort変更、context size変更、有効なtoolやMCP serverの変更などがcache invalidationの原因になると説明されています。²

Claude Codeも、モデル変更に加えてEffort Levelがcache keyに含まれるため、Effortを変更すると次のrequestではキャッシュが外れます。⁹

CodexについてもOpenAIは、モデル変更やtool構成の変更などによってprefixが変わるとcache missにつながることを説明しています。¹⁰ ただし、Thinking Effort変更までClaude Codeと同じ条件でキャッシュが無効になるとは、公開資料からは確認できません。

そのため、同じ長い作業の途中でモデルを数ターンごとに切り替えるより、調査・設計が終わって実装へ移るときなど、タスクの境界でモデルを変更する方が扱いやすくなります。

例えばCodexでTerra → Luna → Terra → Sol → Terraのように往復する使い方は、このケースに当たります。

ただし、冒頭で見た通り、キャッシュが切れることと総コストが増えることは同義ではありません。キャッシュヒット率だけで損得を判断せず、切り替え後のモデル単価や手戻りまで含めて考える必要があります。

---

7. サブエージェントは「節約機能」ではなく、役割分担に使う

サブエージェントを使うと、探索やログ調査などをメインの会話から分離できます。

例えば、

• コードベースの探索
• 大量ログの調査
• テスト失敗の解析
• ドキュメント確認
• git diffの要約
• 限定された範囲のレビュー

などは、親Agentの長いコンテキストを引き継がなくても完結しやすい仕事です。

製品によってはsubagentごとにモデルを分けられるため、メイン処理には通常のモデルを使い、独立した軽作業だけ軽量モデルへ任せる構成も取れます。

Codexではsubagentごとにモデルやreasoning effortを設定できるため、例えば親をTerra、独立した軽作業をLunaに任せる構成も可能です。¹¹ Claude Codeなどでもsubagentは独立したcontextを持ち、モデルを個別指定できます。¹²

ただし、OpenAIはCodexについて、subagent workflowは同等のsingle-agent runより多くのtokenを使うと明記しています。各subagentが独自にモデルを呼び、ツールを使うためです。¹¹ 「子Agentを使うこと自体が節約」ではなく、親のcontextを汚さず、独立した作業を適切なモデルへ切り出せるかどうかで判断するのがよさそうです。

そのため、サブエージェントを増やせば増やすほど節約できるわけではありません。

特に、親が長い時間かけて理解した設計判断をすべて必要とする仕事は、子Agent側でも同じ情報を読み直す必要があります。

サブエージェントは、トークン削減装置というより、コンテキスト分離とモデルルーティングのための仕組みとして使う方が自然です。

---

8. AIに考えさせなくてよい処理はHookやCLIへ任せる

Agentが実行できるからといって、すべてをLLMへ判断させる必要はありません。

例えば、

• formatter
• lint
• 型チェック
• 決まったunit test
• security scan

は、結果が決定論的に決まる処理です。

Claude Code、Codex、VS CodeのAgentにはそれぞれHook機構があり、ファイル編集後など特定のタイミングでスクリプトを実行できます。¹³¹⁴¹⁵

例えば編集後にformatterやlintを自動実行するようにしておけば、毎回Agentへ「formatして」「lintして」と依頼する必要がありません。

GitHubも、unit test、lint、security scanなどの決定論的なguardrailを用意することで、誤った状態のままAgentが処理を続け、後で大きな手戻りが発生することを防げるとしています。²

LLMが考える必要のない部分は、既存の開発ツールへ寄せる方が安定します。

---

明日から試すなら、この4つ

すべてを一度に変える必要はありません。

まずは次の4つだけでも、普段の使い方をかなり見直せます。

1. 別のIssueへ移るときは新しいセッションを作る
2. 依頼時に対象・制約・完了条件を明記する
3. 詳細設計済みの実装では軽量モデルを試す
4. format / lint / testなど決まった処理はHookやCLIへ寄せる

そして、利用量を確認できる環境なら、1ターンの数字ではなく、同じ種類のタスクを完了するまでのターン数や総消費で比較します。

「強いモデルを使わない」「プロンプトを短くする」といった単独のテクニックではなく、Agentが余計に考えたり、読み直したり、やり直したりする仕事を減らすことが、結果としてトークンとコストの削減につながります。

1. OpenAI: Codex Pricing — Codexで消費されるトークンの範囲と、Sol / Terra / Lunaのクレジット換算。 ↩ ↩²

2. GitHub Docs: Optimizing your AI usage to maximize efficiency and reduce cost — プロンプト、コンテキスト、モデル選択、キャッシュ、計画と実装の分離、決定論的なguardrailに関するGitHub公式ガイド。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

3. Anthropic: Manage costs effectively - Claude Code Docs — /clear、CLAUDE.md、MCP、Hookによるログ前処理など、Claude Codeの具体的なトークン削減策。 ↩ ↩² ↩³ ↩⁴

4. Visual Studio Code: Improving token efficiency for GitHub Copilot in VS Code — tool definitionの遅延ロードと、実測されたtoken削減効果。 ↩

5. OpenAI: Codex Models — Sol / Terra / Lunaの位置づけとReasoning Effortの選び方。 ↩ ↩²

6. Anthropic: Model configuration - Claude Code Docs — Claude Codeのopus / sonnet / haikuなどのモデル設定と、Plan ModeでOpus・実装時にSonnetを使うopusplan。 ↩

7. OpenAI: Reasoning models — reasoning tokenの扱い。reasoning tokenもcontextを消費し、output tokenとして課金される。 ↩

8. Anthropic: Thinking - Claude Platform Docs — Claudeのadaptive thinkingとEffortによるthinking depthの制御。 ↩

9. Anthropic: How Claude Code uses prompt caching — Claude Codeのprompt cache、モデル・Effort変更時のキャッシュ挙動。 ↩

10. OpenAI: Unrolling the Codex agent loop — Codexのagent loopと、モデル・tool・sandbox設定などの変更によるcache miss。 ↩

11. OpenAI: Codex Subagents — subagentのモデル・reasoning設定と、single-agent runよりtoken消費が増える点。 ↩ ↩²

12. Anthropic: Create custom subagents - Claude Code Docs — Claude Codeのsubagentごとのモデル指定と独立したcontext。 ↩

13. OpenAI: Codex Hooks — Codexのライフサイクル中に決定論的なスクリプトを実行するHook機構。 ↩

14. Anthropic: Hooks reference - Claude Code Docs — Claude CodeのHookイベントと実行方式。 ↩

15. Visual Studio Code: Agent hooks in Visual Studio Code — VS CodeのAgent Hooks。PostToolUseでPrettierを実行する公式例も掲載。 ↩