AIは安くなるほど請求が増える——Uberの予算枯渇が示す「一仕事あたり原価」の必要性

AIモデルの利用料金は下がり続けています。それなら企業のAI請求額も下がるはずです。ところが、2026年8月29日に＠ITが紹介したIDCの分析では、複数モデルを組み合わせたトークン単価が前年比で約50％下がった一方、請求総額は期待どおりには減っていません。配車サービス大手Uberでは、同年4月中旬の時点で年間のAI予算枠を使い果たしたと報じられました。

この逆転は、単なる見積もりミスではありません。AIが一問一答の道具から、検索、計画、実行、自己確認、やり直しを繰り返すエージェントへ変わったことで、一回の仕事の裏側にある推論回数が見えにくく増えています。単価が半分になっても、処理量が三倍、五倍になれば、請求総額は増えます。

同じ週、The Vergeは米国のデータセンターや発電設備に関わる大気汚染許可について、住民への通知と意見募集を求める連邦要件を撤廃する案を報じました。AIの費用はクラウドの請求書だけではありません。電力、冷却、非常用発電、地域の環境負荷、説明責任まで含めて考える必要があります。

日本企業が次に管理すべきなのは、百万円当たりのトークン数でも、社員一人当たりの利用回数でもありません。顧客対応を一件終える、障害を一件直す、契約書を一件確認するという「一仕事あたり原価」と、その仕事が生んだ価値です。

トークン単価が下がると、なぜ総額が増えるのでしょうか

＠ITの記事によると、2025年から2026年にかけて、一部の組織ではAIが生んだ事業価値ではなく、消費したトークン数で利用を評価する動きがありました。誰が最もAIを使ったかを競う仕組みまで現れ、この風潮は「トークンマクシング」と呼ばれています。

導入初期に利用を促す目的は理解できます。使われなければ、業務へ合うかどうかも分かりません。しかし、消費量を成果として扱うと、長い指示、過剰な再試行、目的のない自動実行まで「多く使った実績」に見えます。電力を多く使った工場ほど優秀だと評価するようなものです。

エージェント型AIでは、この問題がさらに見えにくくなります。利用者が一回「月次資料を作って」と頼んでも、裏側では次の処理が動く場合があります。

1. 必要なファイルを探します。
2. 複数の文書を読み込みます。
3. 表を作り、計算し、文章へ整えます。
4. 自分の出力を別のモデルで評価します。
5. 評価結果を受けて書き直します。
6. 形式エラーがあれば、もう一度実行します。

画面上は一回の依頼でも、課金上は複数回の推論です。検索対象が広いほど入力文脈が長くなり、自己確認を増やすほど出力も増えます。モデルの値下げは、一回の処理を安くする一方、「安いからもう一度試す」という需要も増やします。

これは、通信料金が下がると動画視聴量が増え、ストレージ単価が下がると保存量が増える現象に似ています。AIでも、単位価格の低下をそのまま予算削減へ置き換えることはできません。単価、回数、文脈長、再試行率を分けて見なければなりません。

以前、Smart KurashiではAIエージェント導入で増えるクラウド費と統制費を整理しました。当時の中心は、探索範囲と停止条件を先に決めることでした。今回のUberの例は、その論点が個別の事故ではなく、年間予算を左右する経営課題へ進んだことを示しています。

Uberの予算枯渇が示したのは「責任の空白」です

＠ITが紹介した報道では、UberのCTOが2026年4月中旬に年間のAI予算枠を使い果たしたと明かしたとされています。重要なのは、Uberだけが特別にAIを乱用したと結論づけることではありません。安価な推論を広い業務へ展開したとき、年間固定予算と従量課金の速度が合わなくなる危険を示す事例として読むべきです。

IDCの分析が指摘する構造は明快です。開発・運用担当者は、利用量の急増や異常なループへ早く気付けます。しかし、予算を止めたり、業務部門へ配賦したりする権限を持たないことがあります。一方、財務部門には権限がありますが、ベンダーの請求書が届くまで異常を把握できない場合があります。

つまり、見える人と止められる人が分かれています。AIの費用は、開発担当者と財務担当者の境界へ落ち、誰の業務原価なのかが曖昧になります。

同記事が紹介したIDC調査では、独立したAI予算枠を設定しているCEOは五人に一人、20％にとどまります。また、中東、トルコ、アフリカ地域を対象にした調査では、61％の組織が2025年のクラウドAI予算を超過しました。ただし、超過した組織の83％は超過幅が15％未満だったとされ、早期に統制を設ければ損失の広がりを抑えられる可能性も示されています。

日本企業では、AI費用を情報システム部門の共通費へまとめるだけでは不十分です。営業部門の提案書作成、法務部門の契約確認、開発部門のコード修正では、許容できる原価も失敗の影響も違います。部門別より細かい「仕事別」の責任者が必要です。

管理単位	見える数字	見えない問題
トークン単価	モデルの価格差	再試行と長い文脈が隠れます
月額請求	全社の支出総額	どの仕事が増やしたか分かりません
部門別費用	営業、開発、法務の配賦	成果を生まない自動処理が残ります
一仕事あたり原価	完了一件に必要な総費用	品質と事業価値も合わせて見る必要があります

「一仕事あたり原価」はモデル料金だけではありません

顧客からの問い合わせを一件解決する場合、AI原価には入力と出力のトークン料金だけでなく、検索基盤、ログ保存、評価モデル、人の確認、誤答後の手直しが含まれます。契約書の確認なら、法務担当者が原文へ戻る時間も含めるべきです。コード修正なら、テスト実行、失敗したビルド、レビュー、障害時の復旧まで一つの仕事です。

次の式で考えると、比較しやすくなります。

一仕事あたり原価 ＝ モデル利用料 ＋ 検索・保存費 ＋ 評価・監視費 ＋ 人の確認費 ＋ 失敗と復旧の期待費用

この式は会計基準ではなく、運用を比べるための管理式です。すべてを一円単位で正確に測る必要はありません。少なくとも、安いモデルへ変えた結果、再試行が増えて人の確認時間が延びていないかを見られます。

例えば、モデルAは一回十円で九割の仕事を完了し、モデルBは一回六円でも七割しか完了しないとします。失敗した三割を再実行し、人が修正するなら、Bが最終的に安いとは限りません。反対に、社内文書の分類のように失敗時の影響が小さい仕事では、安価なモデルと短い文脈で十分かもしれません。

直近の記事では、AI推論のボトルネックをGPU台数ではなくメモリ配置から見直す方法を取り上げました。費用管理でも同じ発想が使えます。すべての仕事へ最も高性能なモデルと最長の文脈を割り当てるのではなく、重要度、緊急性、やり直し可能性に応じて資源を配ります。

Hacker Newsに現れた「AIの財務レイヤー」という需要

8月29日のHacker Newsには、複数モデルを使うAIアプリケーション向けの財務可視化サービスが投稿されました。公開ページでは、複数プロバイダーをまたぐAIウォレット、リアルタイムの費用追跡、予算上限、支出アラート、OpenAI互換のプロキシなどを掲げています。

個別サービスの完成度をここで評価することはできません。ただし、モデルへ直接接続するだけでなく、その手前へ費用と予算の制御層を置こうとする動きは重要です。従来のクラウドFinOpsでは、仮想マシン、ストレージ、通信をタグで分類しました。AIでは、さらに依頼元の業務、モデル、プロンプト版、エージェントの反復回数、完了結果を結び付ける必要があります。

最低限、各実行へ次の情報を付けます。

• どの業務と利用者が依頼したか
• どのモデルと設定を使ったか
• 入力と出力の量はいくつか
• ツール呼び出しと再試行は何回か
• 仕事は完了したか、人が手直ししたか
• 品質、安全、速度の基準を満たしたか
• 予算上限へ近づいたとき誰へ通知するか

ここで注意したいのは、監視のために本文や機密情報を過剰保存しないことです。費用可視化と内容の保存は分けられます。業務ID、量、時間、モデル、結果だけを記録し、本文は必要な保存期間とアクセス権を別に管理します。

AIの「外側の請求書」も消えません

企業のダッシュボードに表示されるのは、主にAPI、クラウド、保存、通信の費用です。しかし、大規模なAI利用を支えるデータセンターでは、電力と冷却が必要になり、地域によってはガスタービンなどの発電設備も関わります。

The Vergeが8月28日に報じた米環境保護庁の提案は、新設・拡張設備の大気汚染許可に関する連邦の公衆参加要件を撤廃し、州や地方へ判断を移す内容です。環境保護団体は、データセンターや関連発電設備が住民の知らないまま進む可能性を懸念しています。米環境保護庁は、対象を排出量と環境影響が比較的小さい「minor source」と説明していますが、反対側は地域への累積影響を把握しにくくなると主張しています。

この政策の是非を日本企業が直接決めることはできません。それでも、自社のAI利用料が安い理由を、クラウド事業者の効率化だけで説明しない姿勢は必要です。処理量の増加が、電力、水、発電設備、地域説明へどのような負担を移すのかを調達条件で尋ねられます。

日本国内でも、AIサービスの選定表へ次の項目を加える余地があります。

領域	尋ねること	管理方法
費用	一仕事あたりのモデル・検索・確認費はいくらか	業務IDと実行ログを結びます
品質	完了率、再試行率、人の修正率はどうか	毎月同じ仕事で比較します
資源	処理量、電力、保存量をどう減らすか	短い文脈、キャッシュ、小型モデルを使い分けます
調達	事業者は電力・水・排出情報をどう開示するか	調達質問票と年次報告へ入れます
責任	超過や事故のとき誰が止めるか	業務責任者へ停止権限を与えます

これは、すべてのAI利用を止める提案ではありません。費用と影響を見えないまま増やすのではなく、価値のある仕事へ計算資源を集中する提案です。無駄な十回の再試行を減らせば、予算、待ち時間、インフラ負荷を同時に減らせます。

日本企業が90日で作る四つの台帳

30日：請求書を仕事へ戻します

まず、上位三つのAI用途を選びます。コード修正、問い合わせ対応、議事録作成など、件数と完了条件を数えやすい仕事が向いています。APIキーやクラウドアカウントだけで集計せず、業務IDを付けます。

一週間ごとに、依頼件数、完了件数、再試行回数、人の修正時間、モデル利用料を記録します。利用量が多い人を表彰するのではなく、少ない往復で基準を満たした仕事を探します。

60日：上限と停止線を実装します

一日、一件、一部門の予算上限を分けます。上限へ達したら全社のAIを突然止めるのではなく、低優先度の夜間処理を止め、重要業務は責任者の承認で続けます。

エージェントには、最大反復回数、最大検索件数、最大文脈長、最大実行時間を設けます。同じエラーを繰り返したら、人へ戻します。品質のための自己確認も、無制限にはしません。

90日：価値と原価を同じ会議で見ます

CIOは技術と安定運用、CFOは予算と配賦、業務責任者は完了条件と価値を見ます。三者が別々の資料を見るのではなく、同じ一仕事あたり原価を確認します。

削減額だけでなく、処理時間、完了率、再作業、顧客影響、事故回避を並べます。安いモデルへ変えて原価が下がり、品質も維持できた仕事は拡大します。原価が上がっても重要な障害を早く直せる仕事は、価値を説明した上で残します。目的が曖昧で利用量だけ増えた仕事は止めます。

参考・出典

• ＠IT「トークン単価50％減でもAI請求額が跳ね上がる」（2026年8月29日）
• The Verge「Trump’s EPA wants to let data centers hide their air pollution」（2026年8月28日）
• Hacker News「I built a financial visibility layer for multi-model AI applications」（2026年8月29日）
• Credlier「The Financial Operating System for AI」（2026年8月29日確認）

結論——安いAIではなく、価値を説明できるAIを増やします

トークン単価が半分になっても、エージェントが検索、評価、再試行を何度も繰り返せば、請求総額は増えます。Uberの年間予算枯渇は、値下げだけではAI支出を制御できないことを示しました。IDCの調査は、開発が異常へ気付いても止める権限がなく、財務が権限を持っていても請求書まで気付けないという責任の空白を映しています。

この空白を埋める単位が、一仕事あたり原価です。モデル利用料だけでなく、検索、保存、評価、人の確認、失敗後の復旧を含め、完了率と価値を同じ表で見ます。さらに、調達の外側にある電力、冷却、地域への説明も、安さと切り離さずに尋ねます。

次の予算会議では、「先月は何億トークン使ったか」ではなく、「顧客対応を一件終えるために、何回推論し、いくらかかり、どれだけ手直しが残ったか」を一つだけでも出してみませんか。利用量を競う組織から、価値を説明できる組織へ移れるかが、AIを一時的な実験ではなく長く使える仕事道具にする分岐点です。