トークンは安くなるのに、なぜ AI 請求額は増えるのか？- VPSSpark

2023 年、GPT-4 API の入力は 100 万トークンあたり $30。2024 年末には同等クラスのモデルが $3 未満、2025 年には Haiku 級が $1 を切りました。単価だけ見れば、AI は確実に「安くなっている」はずです。

ところが先月の請求書を開くと、多くの開発者が同じ反応をします：なぜ去年より高いのか？

これは気のせいでも、ベンダーの罠でもありません。160 年前からある経済学の法則が、AI 時代にまた繰り返されている——ジェボンズのパラドックス（Jevons Paradox）です。

核心

トークン単価が半分になるたびに、実際の使用量はだいたい 3〜5 倍に膨らむ。単価下落による「節約」は、増えた消費に丸ごと飲み込まれ、請求総額はむしろ上がる。

−97%

GPT-4 級モデル
単価 2023→2026

10×

同期間の平均
トークン消費増

3×

個人開発者の
月次 AI 請求増

ジェボンズのパラドックス：安くなるほど、使い倒す

1865 年、経済学者ウィリアム・スタンリー・ジェボンズは石炭の研究で奇妙な事実に気づきました。蒸気機関の効率が上がるたびに、石炭の総消費量は減らず増えた。単位あたりのコストが下がると、もともと使えなかった工場が参入し、1 ラインだったところが 3 ラインになる——そういう構造です。

「1 単位あたりの節約」は「総消費の節約」とは限りません。これがジェボンズのパラドックス：資源がより効率的（または安価）になると、総需要は減るのではなく増えることが多い。

トークンの話もまったく同じです。単価が 1 桁下がるたびに、「高すぎて諦めていた」ユースケースが一気に解放されます。

$30/M のときは週報の要約だけ AI に頼む。
$3/M になるとコードレビューも任せ始める。
$0.3/M では OpenClaw で夜間にログ解析、Cursor の Agent で PR 下書きまで回す。
$0.03/M になるとワークフロー全体を渡し、止め忘れたまま常駐させる。

値下げのたびに「節約」ではなく「もっと使える」が起き、請求額は単価下落と逆方向に静かに登っていきます。

請求が膨らむ三つの構造的要因

ジェボンズは「なぜ」を説明します。コストを抑えるには、お金がどこで燃えているかを知る必要があります。AI API 請求では、次の三つが構造的な膨張源です。

要因一：使用量の爆発——「たまに聞く」から「常駐バックグラウンド」へ

2 年前の典型的な使い方は「困ったときだけ Chat」。今は日本の個人開発者・小規模チームでも、Cursor の Composer や OpenClaw がデフォルトの開発フローに入り込んでいます。寝ている間に CI ログを要約し、会議中にリポジトリを整理し、食事中に Discord 経由でユーザーフィードバックに返信する——AI は「受け身の Q&A」から「能動的な実行」に変わりました。

呼び出し頻度は「1 日数十回」から「1 日数千回」へ。1 回あたりの単価が 1/10 でも、総量で見れば請求は簡単に倍になります。

利用段階	典型的な呼び出し頻度	1 回あたりのトークン	月間トークン総量
Q&A 補助（2023）	30 回/日	〜500 tokens	〜450K tokens
コード Review（2024）	200 回/日	〜3,000 tokens	〜18M tokens
常駐 Agent（2025+）	2,000 回/日	〜8,000 tokens	〜480M tokens

最終行に注目：450K から 480M へ——約 1000 倍。同期に単価が 90% 下がっても、請求は 2023 年比で 100 倍になり得ます。

要因二：コンテキストの肥大化——1 リクエストの「重さ」が別物

より見えにくい請求キラーは「回数」ではなく「1 回のボリューム」です。

2023 年、GPT-3.5 のコンテキストは 4K。今は Claude Sonnet で 200K、Gemini 2.5 Pro で 1M。個人開発でも「コンテキストを削る」より「リポジトリ丸ごと渡す」が常態化しています。Cursor の @codebase、OpenClaw のワークスペース丸読み——どちらも「モデルが読めるから」という理由で prompt が巨大化します。

コンテキストの隠れコスト

500KB のソースを 1 回の prompt に入れると約 125,000 トークン——2023 年の 1 ヶ月分の典型消費を超えます。Agent が毎回フルコンテキストを運ぶと、請求は線形ではなく指数的に膨らみます。

さらに「extended thinking」モード。最終回答の前に内部推論トークンが大量発生し、それも課金対象。1 回の「深い分析」が想定の 5〜10 倍になることは珍しくありません。

要因三：Agent の乗数——トークンは足し算ではなく掛け算

請求膨張で最も手強いのがここです。

Q&A モードでは 1 リクエスト＝1 回の課金。Agentic ワークフローでは、ユーザー 1 指示が呼び出しチェーン全体を起動します。

図 1 · 「シンプルな」Agent リクエストの内部チェーン

ユーザーが 1 指示「この PR をレビューして修正案を出して」

Orchestrator Agentサブタスクを分割 → LLM 1 回

子 Agent ×4コード読取・ドキュメント検索・テスト確認・コメント生成 → 各回フルコンテキスト

集約 + リトライエラー時に自動再試行 → さらに 2〜3 回

ユーザーは 1 行送っただけなのに、実際は 7〜8 回の LLM 呼び出し。ボタンは 1 回押したつもりが、請求書には 8 行並びます。

より危険なのは終了条件のない Agent ループ。CI に「失敗テストを自動修正」する OpenClaw スキルを入れ、max retry を忘れた——そんな話は個人開発コミュニティでもよく聞きます。flaky test が 1 本、8 時間で 2,300 回の LLM 呼び出し、$340。単価が安くても乗数が大きければ請求は跳ねます。

実例

ある開発者が CI に「自動テスト修復」Agent を接続し、最大リトライ未設定のまま放置。偶発的な flaky test がループを誘発し、8 時間で 2,300 回の LLM 呼び出し、請求 $340。モデルは安い。乗数が効けばどの単価でも大きな数字になります。

請求を分解する：冷徹な算数

今日の典型的シナリオ：1 日 10 件の Agent タスク、各タスク平均 8 回の LLM 呼び出し、各呼び出し平均 10,000 トークン（コンテキスト込み）。

パラメータ	値
1 日の Agent タスク数	10
タスクあたり LLM 呼び出し（乗数）	8
1 回あたりのトークン	10,000
月間トークン総量	10 × 8 × 10,000 × 30 = 24M tokens
単価（Sonnet 級 $3/M）	24M × $3/M = $72/月
高価モデル（$15/M）の場合	24M × $15/M = $360/月

$72〜$360/月は、1 人の個人開発者の日常だけ。チームが増え、Agent タスクが倍になれば、そのまま乗算されます。請求の大きさは「AI を使っているか」ではなく「乗数チェーンがどれだけ長いか」で決まります。

請求を制御する：減らすのではなく、意図的に使う

ジェボンズの教訓は「使うな」ではなく「構造を整えろ」です。石炭消費の増加は産業革命をもたらした。トークン消費の増加も生産性革命をもたらします。問題は、その請求に見合う価値が出ているかどうか。

すぐ始められる三つの手段——実装コストの低い順です。

手段一：階層ルーティング——安いモデルに大量仕事を回す

すべてのタスクに最強モデルは不要です。「構文エラーの有無」と「システム全体の設計」では要求される知性が桁違い。両方に Claude Sonnet を使えば、請求も桁違いになります。

複雑度で三段階に分けるのが実務的です。

整形・要約・単純分類：Haiku / GPT-4o-mini 級（$0.15〜$0.3/M）
コード生成・多段推論・ドキュメント：Sonnet / GPT-4o 級（$3〜$5/M）
アーキテクチャ設計・難解デバッグ・extended thinking：Opus / o3 級、必要時のみ

実装は LiteLLM などの Gateway でモデル別名（fast / smart / deep）を定義し、クライアントはタスク種別でルーティング。マスターキーとルールはクラウド Mac 上の Gateway に集約——クラウド Mac × OpenRouter 実践ガイドの三層ルーティングがそのまま雛形になります。OpenRouter 公式ドキュメントと組み合わせれば、Cursor・OpenClaw から同じエンドポイントに統一できます。

手段二：予算ブレーカー——燃え尽きる前に遮断

階層ルーティングは「適切なモデル」、予算ブレーカーは「暴走した使用量」に効きます。Agent ループ、想定外リトライ、終了条件のない長時間タスク——理論ではなく、Cursor や OpenClaw を本気で使う人が必ず踏む地雷です。

最低限、二段の防御が必要です。

上流の credit cap：OpenRouter や Anthropic コンソールで月次ハードリミット。超過時は API が拒否し、黙って課金されない。
Virtual Key 単位の spend cap：LiteLLM 自前 Gateway で Cursor・OpenClaw・スクリプトごとに Virtual Key を発行し、個別の月次予算を設定。1 ツールが暴走しても他は無傷。

LiteLLM Virtual Key 作成例（API）

curl -X POST http://127.0.0.1:4000/key/generate \
                  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
                  -H "Content-Type: application/json" \
                  -d '{
                    "key_alias": "cursor-dev",
                    "models": ["fast", "smart"],
                    "max_budget": 20,
                    "budget_duration": "1mo",
                    "metadata": {"tool": "cursor", "env": "dev"}
                  }'

この Virtual Key は月 $20 上限、fast と smart のみ利用可。超過すると 429 で遮断され、マスターキーは影響を受けません。個人開発者向け「最小のエンタープライズ治理」です。

手段三：可観測性——どこで燃えているか見えなければ節約できない

多くの請求トラブルは「気づいたら月末」です。金曜の夜に Agent が $50 静かに消費し、タスクはとっくに終わっている——リアルタイムの spend ビューがなければ防げません。

最小構成の可観測性：

LiteLLM 内蔵 Dashboard：litellm --detailed_debug 起動後 /ui で Virtual Key 別の spend・リクエスト数・レイテンシを確認（公式ドキュメント参照）。
日次 spend アラート：cron で DB を集計し、閾値超過時に Slack 通知——OpenClaw の Slack 連携がそのまま使えます。
上流請求との突合：週 1 回、LiteLLM ローカル spend と OpenRouter コンソールを比較。10% 超の差は Gateway 迂回の「漏れリクエスト」のサイン。

可観測性の効果

spend 監視を入れたチームの多くは、初月で 20〜30% の「無駄消費」を発見します——結果を誰も読まない常駐 Agent、毎回フルコンテキストを運ぶスクリプト、cron に残った古いタスクなど。

本当の問いは「どう安くするか」ではない

ジェボンズの見落とされがちな側面：効率向上そのものを否定していない。石炭消費は増えたが、イギリスは産業革命を成し遂げた。

同様に、トークンが安くなり AI 請求が上がることは、必ずしも悪ではありません。問うべきは：

増えたトークンは、同等以上の価値を生んでいるか？
請求のうち、意図的な投資と無意識の浪費はどれだけか？
その二つにいつでも答えられる可視化があるか？

「トークンを節約する」は目的としてズレています。「すべてのトークンが刃に使われている」が正しい目標です。階層ルーティング、予算ブレーカー、消費の可視化——これらは使う量を減らすためではなく、何に・どこで・それだけの価値があるかを知るための仕組みです。

トークンはこれからも安くなり、請求も上がり続けるでしょう。治理の構造があれば、少なくとも「上がるべき部分」だけが上がります。

FAQ

ジェボンズのパラドックスはいつまで続く？効用に上限のない資源では、しばしば成立します。AI 推論は人力をほぼ無限に代替できるため、価格が下がるたび新しいユースケースが解放されます。能力の天井に達した日には弱まりますが、その日はまだ見えません。

安いモデルに替えれば請求は抑えられる？短期は効きますが持続しません。安いモデルで足りると分かった瞬間、浮いた予算を別タスクに回し、再びジェボンズの軌道に乗ります。持続的なのは「予算制約＋可視化」であり、モデル格下げだけではありません。

Agent の乗数効果は消せる？完全には消せませんが制御は可能です。① 各 Agent に最大ステップ数・最大呼び出し回数を設定、② 結果キャッシュで同一サブタスクの再実行を避ける、③ Orchestrator で「LLM が本当に必要か」を判定——多くのステップはルールエンジンの方が数百倍安いです。

チームが大きくなると制御は難しくなる？はい。人数が増えるほど「誰がどのモデルで何を回しているか」の把握が難しくなります。Gateway の Virtual Key 分離と per-user spend cap は、3 人を超える前から「あった方がいい」から「必須」に変わります。