生成AIコストの「概算」と「実費」はなぜズレるのか
生成AIの費用の概算（トークン数×単価表の計算）と実費（請求額）の違いと、ズレが生まれる理由を整理します。単価表の更新漏れ・キャッシュや割引・リージョン・為替・税・集計期間など主な原因と、ズレの大きさの見方、概算と実費を前提にした月次の運用を解説します。
生成AIの費用の概算は「トークン数 × 単価表」で計算した金額、実費はプロバイダが請求する金額です。両者がズレるのは、単価表に反映されていない請求の条件——単価の改定、キャッシュや割引、リージョンによる単価差、為替、税、集計期間の違い、請求データの反映の遅れ——があるためです。ズレをゼロにすることはできないため、2つの数字を区別して扱う運用が必要になります。
この記事では、概算と実費の違い、ズレが生まれる主な原因、ズレの大きさの見方、2つの数字を前提にした月次の運用を説明します。全体像は「生成AIのコスト管理 完全ガイド」を参照してください。
生成AIの費用の「概算」と「実費」の違い
| 概算 | 実費 | |
|---|---|---|
| 計算のしかた | 利用量（トークン数）× モデル別の単価表 | プロバイダの請求のデータ・請求書 |
| 出せる単位 | APIキー・利用者・部署・モデルなど細かい単位 | 組織・プロジェクト・アカウントなど粗い単位 |
| 出るまでの速さ | 利用量が取れればすぐ計算できる | 数時間〜1〜2日遅れることがある |
| 請求書との一致 | 一致しない（ズレがある） | 一致する |
| 主な使い道 | 内訳の把握、月の途中の状況、異常の察知 | 経理処理、予算の実績、経営報告 |
2つの数字が必要になるのは、請求のデータが細かい単位まで出ないからです。多くのプロバイダでは、実費はプロジェクトやアカウントの単位までで、APIキーや利用者ごとの実費はありません。部署や利用者ごとの費用を知るには、利用量と単価表から計算する概算を使うしかありません。
概算と実費がズレる主な原因
| 分類 | 原因 | 概算が実費からずれる方向 |
|---|---|---|
| 単価 | 単価が改定されたが、単価表が古いまま | 改定の内容による |
| 単価 | 新しいモデルの単価が単価表にない | 概算が少なくなる（計上されない） |
| 単価 | リージョンやルーティングによる単価の違い | 単価表と実際の単価の差の分 |
| 数量 | キャッシュされた入力の割引の扱い | 割引を反映しないと概算が多くなる |
| 数量 | 推論のトークンなど、出力に含まれる分の扱い | 数え漏れがあると概算が少なくなる |
| 数量 | 利用量のデータの二重計上・取りこぼし | 計上の誤りの分 |
| 期間 | タイムゾーンの違い（請求はUTC基準のことが多い） | 月の境目の利用が前後の月にずれる |
| 期間 | 請求のデータの反映の遅れ | 直近の数日は実費が少なく見える |
| 金額 | 為替のレート（ドル建ての請求を円で見る場合） | 使うレートの差の分 |
| 金額 | 税・契約による割引・無料枠 | 単価表に含めていない分 |
ズレの原因は、大きく単価・数量・期間・金額の4つに分けられます。原因を分けておくと、差が出たときにどこから確認すればよいかが分かります。単価表の計算そのものの手順は「OpenAI API料金の計算方法」が参考になります。
単価表の計算でズレが出る例
仮の数字で、単価表の計算と請求がずれる例を示します。
| 項目 | 概算の計算 | 実際の請求 |
|---|---|---|
| 入力トークン（仮） | 1,000万トークン × 仮の単価 1ドル/100万 ＝ 10ドル | うち一部がキャッシュの割引で安くなる |
| 出力トークン（仮） | 200万トークン × 仮の単価 4ドル/100万 ＝ 8ドル | 推論のトークンが出力に加わる |
| 合計 | 18ドル | 割引と追加の分だけ 18ドルからずれる |
この例のように、割引で下がる分と、数え漏れで上がる分が打ち消し合うこともあります。合計の差が小さくても、内訳の原因が隠れていることがある点に注意します。
ズレの大きさをどう判断するか
ズレがあること自体は問題ではありません。見るべきなのは、ズレの大きさが安定しているか、急に広がっていないかです。
| 状態 | 考えられること | 対応 |
|---|---|---|
| 差が小さく、毎月ほぼ同じ | 為替・税・割引など、構造的な差 | 差の理由を記録し、そのまま運用する |
| 差が急に広がった | 単価の改定、新しいモデル、二重計上 | 単価表と利用量のデータを確認する |
| 直近の数日だけ差が大きい | 請求のデータの反映の遅れ | 数日待って、確定した値で比べる |
| 月の境目だけ差が大きい | タイムゾーンの違い | 集計の基準時刻を揃える |
ManageAIでは、Azure OpenAI・AWS Bedrock（Amazon Bedrock）の実測で、概算と実費の差は1〜1.8%でした。差の大きさは、契約の条件や使い方によって変わります。大切なのは、自社のふだんの差を知っておき、差が急に広がったことを異常のシグナルとして扱うことです。差が広がったことで、単価の改定や二重計上に気づけることがあります。
概算と実費のズレを前提にした運用
概算と実費のズレをなくそうとするより、ズレを前提にした運用を決めておくほうが現実的です。
| 運用のルール | 内容 |
|---|---|
| 合計は実費、内訳は概算 | 全社・プロジェクトの合計は請求と一致する実費、部署・利用者・キーの内訳は概算と明記する |
| 2つの数字を混ぜない | 同じ表の同じ列に実費と概算を入れない |
| 配賦は比率で行う | 部署別の概算の比率で、実費を部署に割り振る |
| 月次で突き合わせる | 概算の合計と実費の差を毎月記録し、推移を見る |
| 単価表を保守する | 単価の改定・新しいモデルの追加に合わせて単価表を更新する |
配賦を比率で行うと、部署に配る金額の合計は請求額と一致します。たとえば、仮に実費が100万円、部署Aの概算が全体の60%なら、部署Aには60万円を配賦します。部署ごとの概算の金額をそのまま請求するより、経理との説明がしやすくなります。
報告では、部署別の費用を「正確な金額」として扱わないことが大切です。部署から「この数字は正確なのか」と問われたときに、「合計は請求と一致する実費、内訳は利用量から計算した概算」と答えられるようにしておきます。プロバイダごとの請求の単位は「生成AI APIの請求書には何が書かれ、何が書かれていないか」で整理しています。
よくある質問
Q. 概算を実費に完全に一致させることはできますか？ できません。税・為替・割引・反映の遅れなど、利用量と単価表だけでは表せない条件があるためです。差を小さく保ち、差の理由を説明できるようにすることを目標にします。
Q. 管理画面に表示される金額は、概算ですか、実費ですか？ 画面によって違います。利用量の画面の金額が概算で、請求の画面の金額が実費、ということもあります。どの数字がどちらなのかを確認し、社内の資料でも区別して書きます。
Q. 差が大きい月は、どこから確認すればよいですか？ まず、新しいモデルが使われ始めていないか、単価が改定されていないかを確認します。次に、月の境目の集計期間、為替のレート、請求のデータが確定しているかを確認します。
まとめ
- 概算は「トークン数 × 単価表」の計算、実費は請求額。部署・利用者・キー単位の費用は概算でしか出せない
- ズレの原因は、単価（改定・未登録・リージョン）、数量（キャッシュ・推論のトークン・計上の誤り）、期間（タイムゾーン・反映の遅れ）、金額（為替・税・割引）に分けられる
- ズレの大きさより、差が急に広がったかどうかを見る。急な広がりは異常のシグナルになる
- 合計は実費、内訳は概算として区別し、配賦は概算の比率で実費を割り振る
請求書に載るのは合計額やプロジェクト単位の金額までです。ManageAIは、部署・利用者・APIキー別の費用を可視化し、請求と突合できる「実費」と、利用量から計算した「概算」を常に区別して表示します。モニター企業を募集中です。
関連記事
- 生成AIのコスト管理 完全ガイド｜費用構造・可視化・予算統制の全体像
- 生成AI APIの請求書には何が書かれ、何が書かれていないか
- 生成AIの費用は何で決まるのか——トークン・モデル・呼び出し回数の3要素
- ドル建ての生成AI費用を円で管理する方法と為替リスク
次に読む
この記事を書いた人
モニター企業募集
初期費用0円・月額5万円（税別）
先着5社・2026年11月末まで
5プロバイダの利用量と費用を部署・利用者・APIキー別に可視化。読み取り専用キーの登録だけで当日から始められます。
募集要項を見る資料請求・お問い合わせ