LLMを開発や業務に導入すると、「思ったより費用がかかる」と感じることがあります。しかし、請求額を押し上げているのは、モデルの単価だけではありません。長いコンテキスト、冗長な出力、増え続けるターンなど、使い方による影響のほうが大きい場合があります。
本記事では、AIコストが増える仕組みと、無駄を減らす順番を整理します。例には Claude API、Claude Code、Claude Agent SDK を使います。料金は2026年9月時点の公式情報に基づいています。
1. TLDR: 単価ではなく「成功1件あたり」で考える
最初に、要点を3つにまとめます。
- LLMには限界費用がある。 呼び出すたびに、入力・出力トークンに応じた料金が発生します。
- 請求額は、単価・トークン量・呼び出し回数の積で決まる。 エージェントでは、とくにトークン量とターン数が増えやすくなります。
- 管理すべき指標は、請求総額ではなく成功1件あたりのコストである。 安いモデルでも失敗と再実行が増えれば、結果として高くつきます。
AIコストを下げるには、まずこの3つの要因を分けて測る必要があります。
2. なぜエージェントは高くなるのか
2.1 コストを決める3つの要因
1リクエストの基本的なコストは、次の式で表せます。
コスト = 入力トークン × 入力単価 + 出力トークン × 出力単価
入力には、システムプロンプト、ツール定義、会話履歴、ツールの実行結果が含まれます。出力には、回答だけでなく思考トークンも含まれます。
主要モデルの料金は次のとおりです。
| モデル | 入力（$/MTok） | 出力（$/MTok） | キャッシュ読み取り（$/MTok） |
|---|---|---|---|
| Claude Fable 5.1 | 10 | 50 | 0.25 |
| Claude Opus 5.5 | 4 | 20 | 0.20 |
| Claude Sonnet 5 | 2 | 10 | 0.20 |
| Claude Haiku 4.5 | 1 | 5 | 0.10 |
出力単価が入力単価の5倍である点は共通ですが、キャッシュ読み取りの割引率は一律ではありません。多くのモデルは入力単価の10%ですが、Opus 5.5は5%、Fable 5.1は2.5%です。またキャッシュへの書き込みには、入力単価の1.25倍（5分TTL）または2倍（1時間TTL）がかかります。キャッシュは常に安いのではなく、書き込んだ分を読み返して初めて元が取れます。
請求額が増えたら、次の順に原因を切り分けます。
| 要因 | 確認する指標 | よくある原因 | 最初の対策 |
|---|---|---|---|
| 単価 | モデル別の成功1件あたりのコスト | 単純な処理にも最上位モデル | 同じevalでモデルを比較する |
| トークン量 | キャッシュ読み取り率、出力・思考トークン | 長い履歴、冗長な回答 | コンテキストと出力を短くする |
| 呼び出し回数 | ターン数、リトライ数、コストのp90/p99 | 曖昧な依頼、無制限のループ | 終了条件と予算上限を設ける |
2.2 ターンが増えると、入力はほぼ2乗で増える
エージェントは、ツールを呼び出すたびに、それまでの会話を再送します。コンテキストが毎ターン増える場合、総入力はおおよそ次の形になります。
総入力 ≈ N × 初期コンテキスト + 1ターンあたりの増分 × N² / 2
重要なのはN²です。ターン数が増えるほど、過去の履歴を繰り返し送るコストが急増します。
Sonnet 5で、コンテキストが20Kから120Kトークンまで増え、毎ターン1.5Kトークンを出力する40ターンの実行を試算すると、結果は次のようになります。総入力は約2.8Mトークン、総出力は60Kトークンです。
図1：同じ40ターンでも、キャッシュの使い方によって約5.3倍の差が生じます。
キャッシュが有効なら$1.44ですが、キャッシュなしでは$6.20です。動的な値をプロンプトの先頭に置き、毎回キャッシュを無効にすると$7.60まで増えます。
キャッシュなしより「毎回破壊」のほうが高いのは、書き込み料金（入力単価の1.25倍）を毎ターン払いながら、一度も読み返せないためです。キャッシュは、設定しさえすれば安くなるものではありません。
2.3 トークン単価だけでは比較できない
安いモデルが、必ずしも安い結果を生むとは限りません。低価格のモデルで失敗が増えると、再実行と下流工程の手戻りが発生するためです。一方、高価なモデルでも、少ないターンで成功できれば、成功1件あたりでは安くなる場合があります。
モデルを比較するときは、同じタスクと同じ成功条件を使い、次の式で評価します。
成功1件あたりのコスト = すべての試行の費用 ÷ 成功数
平均だけでなく、難しいタスクや高額な実行も確認します。AIコストは、一部の長い実行に偏りやすいためです。
3. LLMの「7つのムダ」
トヨタ生産方式の「7つのムダ」をLLMに当てはめると、問題を見つけやすくなります。
| ムダ | LLMで起きること | 例 |
|---|---|---|
| 作りすぎ | 読まれない文章や不要な思考を生成する | 過剰な説明、不要な自己検証 |
| 在庫 | 使わない情報をコンテキストに残す | 長い履歴、全ツール定義、巨大な指示ファイル |
| 運搬 | 同じ内容を何度も送る | キャッシュ未使用、動的な接頭辞 |
| 加工のしすぎ | 必要以上に高性能なモデルを使う | yes/noの判定に最上位モデル |
| 動作 | 不要な探索やツール呼び出しを行う | 曖昧な依頼、目的のない調査 |
| 手待ち | 即時性が不要な処理を同期実行する | evalや夜間処理を通常APIで実行 |
| 不良 | 失敗した処理にも料金がかかる | リトライ、途中終了、捨てられる成果物 |
とくに重要なのは「在庫」です。コンテキスト内の情報には、使われなくても毎ターン読み取り料金がかかります。参照されない情報は、費用だけを生む在庫です。
4. Claude Codeのコストを減らす
開発現場では、次の5点から見直します。
4.1 作業が変わったらセッションを分ける
Claude Codeは、リクエストごとに会話履歴を送信します。長いセッションでは、短い質問でも大きなコンテキストを再送することになります。
- 別の作業へ移るときは
/clearを使う - 履歴を引き継ぐときは
/compactで残す情報を指定する -
/compact自体にも要約コストがかかるため、継続性が不要なら/clearを選ぶ
4.2 モデルとeffortを作業に合わせる
多くのコーディング作業はSonnetで処理できます。Opusは、複雑な設計判断や長い推論が必要な作業に限定します。テスト実行や検索など、結果を検証しやすいサブエージェントにはHaikuが向きます。
effortも同様です。単純な修正や定型作業では下げ、長時間のコーディングなど、精度差が出る作業だけ上げます。
4.3 常駐する指示とツールを減らす
CLAUDE.mdはセッション開始時に読み込まれます。特定の作業にしか使わない指示はスキルへ移し、必要なときだけ読み込みます。CLAUDE.mdは200行以下が目安です。
MCPサーバーも同じです。現在のClaude Codeはツール定義を遅延読み込みするため、既定で常駐するのはツール名とサーバーの説明だけですが、サーバー数が増えればその分は積み上がります。/contextで内訳を確認し、使っていないサーバーは/mcpで無効にします。ghやawsのようにCLIで足りる操作は、MCPサーバーを追加するより常駐コストが小さく済みます。
4.4 ツールの出力を絞る
テストログやビルドログをそのまま渡す必要はありません。失敗したテスト名、エラー周辺、該当ファイルだけを抽出して返します。
大量のログ処理をサブエージェントに任せ、メインの会話には要約だけを戻す方法も有効です。詳細な出力がメインのコンテキストへ残るのを防げます。
ただし、サブエージェント自身のリクエストにも料金はかかります。減らせるのはメインの会話が毎ターン肥大化する分であり、処理そのものが無料になるわけではありません。単純な作業には小さなモデルを割り当てます。
4.5 利用状況をチームで測る
/usageでは、トークン使用量、キャッシュヒット率、キャッシュミスの原因を確認できます。組織全体ではOpenTelemetryを使い、利用者・機能・モデルごとのコストを可視化します。
自動実行には--max-budget-usdを指定し、1回の処理に支出上限を設けます。
5. API・Agent SDKのコストを減らす
対策は、効果が大きく実装しやすい順に進めます。
5.1 プロンプトキャッシュを有効にする
プロンプトキャッシュは、エージェントのコストに最も大きく影響する対策の一つです。公式ドキュメントのDeepResearch Bench IIでの計測では、1タスクあたりのコストがSonnet 5で$3.20から$1.20（約63%減）、Fable 5.1で$37.94から$7.12（約81%減）まで下がっています。
ただし、キャッシュはツール、システムプロンプト、メッセージの順に前方一致で判定されます。前半が変わると、それ以降も無効になります。
# NG：毎回変わる値を先頭に置く
system = f"現在時刻: {now}\nユーザーID: {user_id}\n" + LONG_INSTRUCTIONS
# OK：静的な接頭辞を固定してキャッシュし、動的な情報は最後のメッセージへ置く
system = [{
"type": "text",
"text": LONG_INSTRUCTIONS,
"cache_control": {"type": "ephemeral"},
}]
messages = history + [{
"role": "user",
"content": f"現在時刻: {now}\nユーザーID: {user_id}\n{user_message}",
}]
公式ドキュメントによれば、実トラフィックのエージェントループは入力の中央値84%をキャッシュから読み取り、上位10%のハーネスでは94%以上に達します。本番では80%以上を目安にし、下回った場合は、ツール定義、システムプロンプト、effortなどが途中で変わっていないか確認します。effortは値がプロンプトに埋め込まれるため、途中で変えるとキャッシュが無効になります。
5.2 コンテキストと出力を短くする
コンテキストウィンドウが大きくても、すべてを入れる必要はありません。
- ツール定義：必要なツールだけを遅延読み込みする
- データ：CSVを貼り付けず、Files APIとコード実行を使う
- 履歴：長い実行では古いツール結果を短い要約へ置き換える
- 出力：必要な項目と上限を指定し、説明文を作りすぎない
出力は入力より単価が高く、その後のターンでは入力として再送されます。短い出力は、生成時と再送時の両方で効きます。
5.3 モデルより先にeffortを比較する
モデルを増やす前に、同じモデルでeffortを変えてevalします。公式ドキュメントの計測では、リサーチ系のベンチマークでlowは1〜3ポイントの低下と引き換えにコストが3分の1〜半分になり、mediumは既定と同等の精度を約70〜87%のコストで達成しました。一方、SWE-bench Proのような長時間のコーディングでは差が残り、xhighはhighより約1.4ポイント高い代わりにコストは2.5倍でした。効果の出方はタスク次第なので、自分のevalで測る必要があります。
結果を自動検証できるなら、最初はlowで実行し、失敗したタスクだけhighで再実行する方法も有効です。
モデルやプロンプトを変更するときは、古いモデル向けの「必ず二度検証する」「最大限詳しく考える」といった指示も見直します。こうした指示は、精度を上げずに思考と出力だけを増やすことがあります。
5.4 待てる処理はBatch APIへ回す
Batch APIは、入力・出力ともに50%割引です。夜間処理、eval、バックフィル、定期実行など、即時応答が不要な処理に向きます。プロンプトキャッシュとも併用できます。
5.5 定型的な判断では文章を生成しない
分類、ルーティング、スコアリングの答えがラベルやyes/noで済むなら、長い文章を生成する必要はありません。
生成モデルを使う場合も、ツール呼び出しや構造化出力で返却形式を制約します。判断専用モデルを使える場合は、大半を低コストで処理し、信頼度の低いケースだけLLMへ送ります。
1日10万件のチケットを30日間（月300万件）分類する試算では、構成によって月額に約100倍の差が生じます。1件あたりの入力は1,500トークン、出力は20トークンとし、キャッシュを使う行では入力のうち1,000トークンを共通の接頭辞、500トークンを変動部分としています。判断専用モデルの行は、Jevの公表単価（入力$0.042/MTok、出力は課金なし）による計算です。
| 構成 | 月額の目安 |
|---|---|
| Opus 5.5、同期、キャッシュなし | 約$19,200 |
| Sonnet 5、接頭辞をキャッシュ | 約$4,200 |
| Haiku 4.5、キャッシュ＋Batch | 約$1,050 |
| 判断専用モデル（Jev） | 約$190 |
図2：処理件数が同じでも、構成によって月額は約$19,200から約$190まで変わります。品質は同じevalで確認する必要があります。
5.6 1タスクと組織全体の両方に上限を設ける
エージェントのコストは、少数の長い実行に偏ります。そのため、平均値だけでなくp90・p99を監視します。
| 制御 | 目的 |
|---|---|
| タスク予算 | モデルに残り予算を意識させ、探索量を調整する |
max_tokens |
1応答の絶対上限を設ける |
max_turns |
ツール使用ターンを制限する |
max_budget_usd |
1タスクの損失上限を設ける |
| ワークスペース支出上限 | 組織全体の支出を止める |
max_tokensは安全上限であり、単独では成功1件あたりのコストを下げにくい点に注意してください。途中で切れた試行にも料金がかかるためです。
5.7 そもそもLLMを呼ぶ必要があるか確認する
呼び出し方を最適化するより、呼び出し自体を減らすほうが効果的な場合があります。
- 閲覧のたびに生成せず、コンテンツの登録時に一度だけ生成して保存する
- 判断方法が安定したら、通常のコードやルールへ置き換える
- 利用されていないAI機能は、evalやモデル移行を含む維持費も見て廃止を判断する
- ローカルLLMは、API費よりGPU・運用・品質差の総コストが低い場合に限って検討する
6. TokenOps：測ってから削る
AIコストは、機能単位で継続的に管理します。追うべき指標は次の5つです。
- 成功1件あたりのコスト
- キャッシュ読み取り率
- 出力・思考トークン数
- ターン数とコストのp90・p99
- 定義したツールのうち、実際に呼ばれた割合
最適化は、一度で終わる作業ではありません。本番に近いタスクでevalし、小さく切り替え、結果を監視します。
取り組む順番は、次のとおりです。
- 成功条件と成功1件あたりのコストを定義する
- キャッシュを有効にし、コンテキストと出力を削る
- 待てる処理をBatch APIへ移す
- 同じモデルで
effortを比較する - 必要ならモデルを変更する
- 最後にマルチモデル構成を検討する
7. おわりに
AIが高くつくのは、モデルの単価だけが原因ではありません。限界費用を意識せずに、すべてを渡し、長く生成し、何度も試すことが請求額を押し上げます。
まず測るべき数字は、「キャッシュ読み取り率」と「成功1件あたりのコスト」です。この2つが分かれば、どの無駄から削るべきか判断できます。
参考資料
- 料金 - Claude Platform Docs
- Optimizing for cost and intelligence - Claude Platform Docs
- Steering thinking - Claude Platform Docs
- Manage costs effectively - Claude Code Docs
- How the agent loop works - Claude Agent SDK
- TypeSafe's Jev: Can decision models replace LLM judges? - Arize AI
- Jev as a judge - Langfuse