「トークン爆発」で予算が半年で尽きる——AI利用料を読めるようにする予算設計と、見積書の7項目

「1年分の予算を5カ月半で使い切る」が、もう報道の見出しになっている

最初に、これが一部の先進企業の話ではなくなっている事実から押さえます。

日経ビジネスは2026年10月2日、「AIの年間予算が半年弱で枯渇、企業を襲う『トークン爆発』」という記事を出しました。冒頭はこうです。「『1年分の予算を5カ月半で使い切る』『月の半ばで利用枠が底を突く』――。生成AI（人工知能）の利用拡大に伴い、トークンの消費が当初想定を超えて膨らむ『トークン爆発』の状態となる企業が相次いでいる」。

その3週間前には、日本経済新聞も「AI利用料の予算超過相次ぐ、月200万円超も」と報じました（2026年9月10日）。同紙の報道によると、月々の予算を約200万円超過する状態が3カ月続いた企業もあります。どちらも会員限定記事なので引用はここまでにしますが、見出しとリードだけで十分に伝わります。予算超過が、個別の失敗談ではなく「相次ぐ」と書かれる段階に来ました。

私たちが商談でいただく懸念も、この1年で変わりました。以前は「精度は出るのか」「情報は漏れないか」が中心でした。いまは費用の話が先に出ます。冒頭の建材メーカーの情報システム部長は、複数システムを別々に作る方針を「よろしくない。最適なやり方とセキュリティ要件を見定めないと、正直、一時の投資になってしまう」と警戒していました。ある大手化学メーカーの上級執行役員は、大手SaaSについて「イニシャルコストも維持コストも高い」と実感として口にしました。ある不動産仲介会社の代表の話によると、使っているツールは「月6万9800円を払っていて地味に高い」とのことでした。金額の大小は違いますが、問われているのは同じです。この費用は、来年も説明できるのか。

「トークン爆発」「トークンポカリプス」は何を指す言葉なのか

言葉の整理をしておきます。どちらも制度名ではありません。現場の悲鳴から生まれた呼び名です。

英語圏では「トークンポカリプス（Tokenpocalypse）」という造語が使われています。日本語の解説記事によると、出どころは米国のフォーラムに書き込まれたユーザーの言葉でした。広まったきっかけのひとつは、GitHubが2026年6月1日にCopilotの企業向け課金を「使用回数ベース」から「使用量（トークン）ベース」へ変えたことです。使った回数ではなく、使ったトークンの量で請求される。この変更で、同じ使い方をしていても請求額が跳ねる企業が出ました。

同じ記事は、2026年7月1日のパランティアCEOの発言も引いています。「何かが完全に間違っている」と、トークン課金そのものを公然と批判した。ウーバーが従業員1人あたり月1,500ドルという上限を設けたとの報道（2026年5月28日）も紹介されています。使わせないわけにはいかない、しかし無制限にもできない。大手が同時にこの線引きを始めました。

日本語の報道では「トークン爆発」という呼び方が定着しつつあります。@ITの連載は、記事タイトルをこう付けました。「トークン単価は8割下がった。なのに請求額は増えた」（2026年10月6日）。この一文が、問題の形をいちばん短く言い表しています。安くなっているのに、高くなる。矛盾しているように見えて、矛盾していません。

私たちの定義はこうです。トークン爆発とは、請求額を決めているものが「単価」から「設計と使い方」に移ったのに、予算の立て方だけが単価の時代のまま残っている状態。価格の問題ではなく、見積もりの方法の問題として扱っています。

単価は下がっている。それでも請求が増える3つの理由

理由は3つに分かれます。どれも「使いすぎ」という言葉では説明できません。

1つ目は、モデルの乗り換えです。 最新のモデルは、ほぼ例外なく高い。性能が上がったモデルに社内の利用が自然に流れると、単価表の平均値は上がります。しかも主要なモデルは、出力側の単価が入力側の数倍に設定されています。「長く考えて、長く書く」使い方に寄れば、同じ業務でも請求は増えます。

2つ目は、設計の変更です。 ここがいちばん効きます。Anthropicは自社の調査として「エージェントはチャットのやりとりの約4倍、マルチエージェントのシステムはチャットの約15倍のトークンを使う」と公表しました（2025年6月13日）。原文の表現は「agents typically use about 4× more tokens than chat interactions」。マルチエージェントについては「about 15× more tokens than chats」と書かれています。チャットで質問していたものを、自律的に動くエージェントに置き換えた。それだけで15倍の桁に入ります。この数字を知らずに「社内チャットの実績から全社の予算を引いた」会社は、最初から外れた予算を持っていることになります。

3つ目は、適用範囲の拡大です。 これは本来、喜ぶべき増え方。1部署の試行が5部署に広がり、月100件だった処理が月3,000件になる。単価が半分になっても、件数が30倍なら請求は15倍です。問題は、この増え方と2つ目の増え方が同じ請求書の中で混ざり、どちらが効いているのか誰も言えなくなることにあります。

同じ入力でも請求は20倍変わる——「単価表の比較」が効かない理由

ここは経営判断に直結するので、具体的な数字で示します。

Claudeの公式ドキュメントに、プロンプトキャッシュ（同じ前提文を使い回す仕組み）の料金が明記されています。キャッシュに書き込むときのトークンは、基本の入力単価の1.25倍（有効期間5分）または2倍（有効期間1時間）。そしてキャッシュから読み出すときのトークンは、基本の入力単価の0.1倍です。モデルによってはさらに安く、Opus 5.5とSonnet 5.5では0.05倍と書かれています。

つまり、まったく同じ前提文を読ませても、キャッシュに当たるかどうかで入力コストは20倍違います。当たらない作りのまま「安いモデルに替えてコストを下げよう」と動くより、当たる作りに直すほうが効く場面があるわけです。AIエージェントの運用コストを単価表の比較で判断できない理由は、ここにあります。

誤解のないように申し上げると、キャッシュを効かせれば済むという話ではありません。有効期間が5分なので、人が間に挟まる業務では切れます。1時間に延ばせば書き込み側が2倍になるので、どのくらいの頻度で同じ前提を使い回すのかを見てから選ぶことになります。私たちが社内の定期処理で1時間の設定を使っているのは、同じ文脈に何度も戻ってくる作業だと分かっているからです。設計を決めずに「どちらが安いか」を聞かれても、答えようがありません。

請求が増えたら、4つに切り分ける

「先月より増えた」という報告が来たとき、増えた理由を4つのどれかに割り当てます。ここを飛ばして節約の議論を始めると、だいたい見当違いの場所を削ります。

切り分け	何を見るか	典型的な原因
① 単価が変わった	モデル別の単価×利用比率	新モデルへの乗り換え。出力側の単価上昇。
② 1件あたりの消費が増えた	1件あたりの入力・出力トークン	エージェント化。履歴の読み直し。ツール定義の肥大。
③ 件数が増えた	月間処理件数、利用者数	展開部署の追加。定期実行の増加。
④ 版や既定値が変わった	ツールのバージョン、既定設定	アップデートによる内部挙動の変化。

④を疑う習慣は、まだどの会社にもありません。実例を挙げます。2026年3月末、Claude Codeのv2.1.88前後で「同じ作業なのにトークン消費が3倍から50倍になった」という報告が相次ぎ、英語圏では"Tokenocalypse"と呼ばれました。あるエンジニアの検証記事によれば、版ごとに消費量が段階的に増え、上位プランでも短時間で枠が尽きた事例があったといいます。開発側のアップデートで、利用者が何も変えていないのに請求が動く。これが④です。

同じ構造は設定の既定値でも起きます。Opus 5.5では、Claude Codeの推論の深さ（エフォート）の既定値がhighからmediumに変わりました。この話はClaude Codeのエフォートと上限で詳しく書いています。要点は「自分で設定を変えていなくても、既定値が変われば消費は変わる」ということです。

正直に申し上げると、私たちも最初はここで時間を使いました。請求の総額だけを見て「使いすぎだ」と結論を出し、現場に節約を頼んだことがあります。あとで調べたら、原因は版の更新でした。総額しか持っていないと、こういう間違い方をします。

私たちがやったこと：セッション単位の「トークン台帳」

ここからは自社の運用です。きれいな話ではないので、失敗から書きます。

私たちはAIエージェントに業務の一部を任せています。議事録、記事の下書き、社内システムの実装、障害の一次調査。当初、費用は月次の請求書でしか見ていませんでした。総額は分かる。けれど「どの業務にいくらかかったか」は誰も答えられない。この状態で「AIで効率化できた」と言っても、社内の誰も納得しません。

そこで、作業の単位ごとにトークンを記録する台帳を作りました。社内で使っている基盤（Sibyl）に、作業セッションが終わるたびに入力・出力のトークン量を残します。あわせて運用ルールを1つ決めました。1つのセッションでは1つのテーマしか扱わない。関係のない作業を1セッションに詰め込むと、どの業務の費用なのか切り分けられなくなるからです。興味深いことに、先ほど触れたエンジニアの検証記事も、コスト対策として「1セッション1トピック」を挙げていました。節約のために始めた工夫と、計測のために始めた工夫が同じ形に着地しています。

もうひとつ、計上の決め方を標準化しました。3段構えです。

1. 実測値が取れるなら実測値を使う。 APIの応答などから正確な値が返るなら、それが最優先。
2. 取れないときは、実際に読み込んだ量から概算する。 何をどれだけ読ませたかを基準にします。
3. それも取れないときだけ、上限を付けた粗い概算にする。 上限なしの概算は禁止にしました。

3つ目の禁止に意味があります。上限を付けずに「作業全体の長さから割り出す」方式で計上していた時期があり、長時間の作業で数字が桁ごと膨らみました。実際の請求とも合いません。粗い概算を許すなら上限を付ける。この一行を決めたことで、台帳の数字がようやく経営の会話に使えるようになりました。

可視化の仕組みそのものは、他社の実践も参考になります。DeNAの公開記事によると、各クラウドの日次コストをBigQueryに集め、Lookerでサービス・チーム単位に可視化し、コストアラートを置いているそうです（2026年8月7日）。規模が違っても、順番は同じです。集める、割り当てる、しきい値で鳴らす。

予算は「月額」ではなく「1件あたり」で立てる

稟議に「AI利用料 月額いくら」とだけ書いても、根拠がないので守れません。私たちは次の順番で組み立てます。

1. 業務を1件の単位で定義する。 「見積書1通の作成」「問い合わせ1件の一次回答」「図面1枚のチェック」。
2. その1件に入力・出力それぞれ何トークン使うかを実測する。 推測しません。10〜20件を実際に流して測ります。
3. 1件あたりの金額を出す。 ここでキャッシュが当たる前提かどうかを明示します。前提が変われば金額も変わるため、ここは併記しておきます。
4. 再試行と失敗の率を乗せる。 一発で通る前提の試算は、まず外れます。私たちは業務の難しさに応じて2〜4割を乗せています。
5. 月間件数を掛け、上限を決める。 上限は「超えたら止まる」実装とセットにします。紙の上の上限は上限ではありません。

この形にすると、増えた理由を説明できます。「1件あたりは下がったが、件数が3倍になった」と言えれば、それは成功の報告です。逆に「件数は同じなのに1件あたりが2倍になった」なら、設計か版を調べる話になります。

効果の伝え方にも関係します。ある重工・製鋼メーカーのシステム部門の責任者は、「開発にAIを入れてコールを30%削減しました、とQC発表で報告したが、全然評価が悪くて、あまり響かなかった」と語りました。削減率そのものは正しい。けれど聞いている側は金額と人の話を知りたかった。この種のズレについては「グッドハートの法則」とAIでも書きました。1件あたりの金額を持っていると、効果も費用も同じ単位で話せます。

ついでに言えば、安くすることが目的ではありません。私たちは精度を上げるために、わざとコストを足している処理があります。代表の言葉を借りれば「Geminiが出した回答を、もう少し賢いClaudeで採点させる」。一時的に費用は増えます。それでも、1件あたりの金額と品質の両方を並べて見られる状態なら、足す判断も引く判断も説明できます。

ベンダーの見積書に書かせる7項目

発注側の実務に落とします。AI搭載システムの見積書を受け取ったとき、次の7項目が書かれているかを確認してください。書かれていない見積書は、運用に入ってから揉めます。

#	書かせる項目	書かれていないと起きること
1	AI利用料の契約名義（自社かベンダーか）	請求の内訳が見えない。値上げの理由も確認できない。
2	1件あたりの想定トークン（入力・出力別）と測り方	総額だけが示され、増えた理由を切り分けられない。
3	想定件数と、超過したときの扱い	想定の2倍使った月の扱いが決まらず交渉になる。
4	キャッシュを前提にした見積もりか	前提が崩れた瞬間に入力コストが桁で変わる。
5	モデル変更・版更新時の費用変動の通知義務	ベンダー側の更新で請求が動いても気づけない。
6	上限とアラートの実装（誰がどこで止めるか）	気づくのは翌月の請求書になる。
7	運用移管後のコスト見通し（内製化後の月額）	引き継いだ瞬間に想定外の固定費が乗る。

5番と7番は、特に抜けます。ある製造業のDX推進室の担当者は、開発環境の構築について「通常、日本企業ではベンダーが環境を持ち、費用は保守費用に含まれることが多い」と話していました。従来の発注観では、環境と費用はベンダー側の箱の中にありました。トークン課金はその箱を壊します。使えば使うほど増える費目を、保守費用の中に丸めることはできません。

私たち自身も、ここで一度やられています。開発中に使っていたライブラリが、公開環境では課金対象でした。社内の記録によると、本番リリースの直前に16万円の請求予定が見つかり、自前の実装に差し替えて消しています。開発環境では無料に見えるものが、本番では有料になる。見積もりの段階でこれを読むのが、作る側の責任だと考えています。

「止める仕組み」がなければ、設計は意味がない

予算と設計を整えても、止まらなければ事故になります。ここは検収項目として扱っています。

私たちが自社で明文化しているのは、次の4つです。いずれも数値で決めます。

• 自律ループの回数上限（1つの作業で何回まで繰り返してよいか）。
• 連続実行の時間上限（何時間で区切るか）。
• 同時に動かすエージェントの数。
• 失敗したときの打ち切り基準（同じエラーが続いたら人が引き取る）。

4つ目は効果が大きい割に軽い対策です。エージェントは同じ失敗を根気よく繰り返します。その間もトークンは消えます。先ほどのエンジニアの検証記事も「エラー2回で運用を止めて人が計画を立て直す」というルールを挙げていました。私たちも似た線引きをしています。AIの粘り強さは長所ですが、費用の面では無限ループと区別がつきません。

外部APIを大量に呼ぶ処理では、全件を同時に投げないことも決めています。50件程度のかたまりに分けて、間を置く。レート制限の回避だけが目的ではありません。暴走したときに止める余地を残すためです。

発注側の立場では、ここを納品物として要求してください。「上限が設定できること」ではなく「上限に達したら実際に止まること」を見せてもらう。止まったつもりで動き続ける仕組みは、いちばん高くつきます。

やってはいけない節約——安いモデルに寄せて、検収が崩れる

削り方を間違えると、金額以上のものを失います。よく見る3つを挙げます。

1つ目は、すべてを安いモデルに寄せること。 判断の難しい工程に軽いモデルを当てると、やり直しが増えます。1回の単価は下がっても、3回やり直せば高い。私たちは、設計や検証のような「間違えると後工程が全部壊れる」工程には、高いモデルを当てたままにしています。

2つ目は、人の確認を削ること。 AIの出力を人が読む時間はコストに見えます。けれどここを削ると、間違いが下流に流れます。私たちの基本姿勢は変わりません。AIは壁打ち相手であり、判断は人間がする。削る対象は人の確認ではなく、AIが無駄に読み直している前提文のほうです。

3つ目は、検証の仕組みを外すこと。 1つのモデルの自己申告を信じない構えは、費用を生みます。それでも外しません。考え方は敵対的検証と同じで、採点する側と採点される側を分けておくだけの話です。ここを節約すると、間違った出力が「正しい」として業務に入ります。

節約の順番としては、まず無駄な読み直しを減らす。次にキャッシュが当たる作りにする。そのうえで、件数の多い単純作業だけ軽いモデルに寄せる。人の確認と検証の仕組みは最後まで残します。順番を逆にした会社は、数か月後に品質の問題として同じ費用を払い直しています。

私たちの見解——トークン爆発は、コストの問題ではなく統制の問題

ここが記事でいちばん伝えたいところです。

私たちの現場経験では、請求額が読めない会社には共通点があります。使用量を部署や業務に割り当てていない。これだけです。総額は全員が見ている。けれど「この部署のこの業務で、1件あたりいくら」を持っていないので、増えても減っても理由が言えません。理由が言えないと、取れる手は2つに狭まります。全面的に使わせるか、全面的に止めるか。どちらも経営判断としては粗すぎます。

私たちは「企業AIは、守れる設計でなければ業務に入れない」という立場で仕事をしています。これまで、守るの中身は権限分離・監査ログ・人間承認でした。いまは費用も同じ枠に入ると考えています。誰が、どの業務で、いくら使ったかを後から説明できる。これは監査可能性の話であり、節約術の話ではありません。

実務でも、その形で設計しています。ある化粧品メーカーの案件では、最初のMVPを私たちの基盤で素早く立ち上げ、その後に顧客の自社管理クラウドへ全面移行しました（利用者19名）。移行の目的は情報セキュリティだけではなく、運用コストの見通しを顧客側に持ってもらうことでもありました。自社の環境に移れば、請求の明細も上限の設定も自分たちの手の内に入ります。「会社ごとに分かれた、移管できる基盤」という私たちの主張は、費用の統制にもそのまま効きます。

ここは意見が分かれるところだと思います。「まず全社で使わせて、量が見えてから統制する」という順番を取る会社もあります。短期的には正しい。ただ、半年後に「予算が尽きたので止める」という判断に追い込まれるのを何度か見ました。使わせる前に、割り当てと上限と1件あたりの単価だけは決めておく。これが私たちの推奨です。

自己診断：5つの問い

自社がどの段階にいるかを確かめる問いです。「いいえ」が3つ以上なら、予算の説明は来年もできません。

1. AIの請求額を、部署または業務に割り当てられていますか。 総額しか分からない状態は、ここが「いいえ」です。
2. 主要な業務について、1件あたりのトークン量を実測していますか。 推測値しかないなら「いいえ」。
3. 上限に達したときに、実際に止まる仕組みがありますか。 設定できるだけでは足りません。
4. ベンダーの見積書に、1件あたりの想定トークンと超過時の扱いが書かれていますか。 総額だけの見積書は「いいえ」。
5. ツールの版や既定値が変わったときに、費用の変化に気づける人がいますか。 誰も見ていないなら「いいえ」。

3番と5番は、技術の話に見えて組織の話です。止める権限を誰が持つのか、版の更新を誰が追うのか。この2つが決まっていない会社では、気づくのは請求書が届いた後になります。

よくある質問

Q1. 定額プランに切り替えれば、この問題は解決しますか。

利用量の上限がある定額プランは、予算の読みやすさという意味では有効です。ただし上限に達したときに業務が止まるので、「止まってよい業務か」を先に決める必要があります。私たちは、止まると困る定期処理は従量課金の経路に残し、試行錯誤の多い開発作業は定額の枠に寄せています。切り替えではなく、業務ごとの振り分けの問題として考えるほうが現実的です。

Q2. ローカルLLMやオンプレミスにすれば、費用は読めるようになりますか。

読めるようにはなります。従量課金が固定費に変わるので、月額の変動はほぼなくなります。一方で、GPUの調達・電力・保守・モデル更新という別の費目が立ちます。私たちはデータの機密性が高い案件（R&D部門や閉域環境）でローカル構成を採りますが、「安くなるから」を理由にしたことはありません。読みやすさと総額は別の話です。

Q3. 1件あたりのコストは、何から測り始めればいいですか。

いちばん件数の多い業務を1つだけ選んでください。その業務を10〜20件流し、入力と出力のトークン量を記録します。スプレッドシート1枚で十分です。列は「業務名／1件の入力トークン／1件の出力トークン／キャッシュ前提の有無／再試行率／1件あたり金額」の6つ。半日あれば1業務ぶんは埋まります。この1行があるだけで、稟議の書き方が変わります。

Q4. ベンダーから「トークン代は実費精算」と言われました。妥当でしょうか。

実費精算そのものは妥当です。確認すべきは3点あります。1件あたりの想定値が示されているか、想定を超えたときに誰が判断するのか、ベンダー側の設計変更で消費が増えたときの扱いはどうなるのか。3点目が曖昧なまま進むと、設計の都合で増えた費用まで発注側が持つことになります。発注と内製の線引きそのものに迷う場合は、AIエージェント開発は外注か内製かも参考になるはずです。

まず試すなら

明日から動かせる順に3つ挙げます。

1. 請求書を1枚持ってきて、金額を業務に割り当ててみる。 割り当てられない金額が何割あるかを数えてください。半分以上が「不明」なら、節約の議論より先に計測を入れる段階です。
2. いちばん件数の多い業務の「1件あたり」を実測する。 10件流して、入力・出力のトークン量と再試行の回数を記録します。所要半日。この数字が、来年の予算の土台になります。
3. いま動いているベンダー見積書を、7項目で点検する。 空欄が3つ以上あれば、次の定例で質問として投げてください。契約の途中でも、通知義務と上限の実装は追加で合意できます。

「AIで何ができるか」を調べる前に、「いまやっている業務の1件あたりがいくらか」を知っておくと、投資の判断が一気に軽くなります。AI-Path では無償の業務プロセス診断（BPR）を実施しており、業務の棚卸しとあわせて、AIを入れたときの1件あたりの費用と上限の設計もお手伝いしています。まずは無償の業務診断で、御社のどの業務にAIが効いて、それがいくらになるのかを一緒に見てみませんか。

参考リンク

• 日経ビジネスの記事。これは「トークン爆発」を報じた2026年10月2日の記事です（会員限定）。

• Anthropicのブログ。これは約4倍・約15倍の原典で、2025年6月13日の公開です。

• Claude公式ドキュメント。これはキャッシュ料金（1.25倍・2倍・0.1倍・0.05倍）の原典です。

• 解説記事。これは「トークンポカリプス」の語源とGitHubの課金変更をまとめた2026年7月6日の記事です。