AI開発の稟議では、開発費（初期費用）の金額に注目が集まりやすい。だが生成AIを使う仕組みは、本番稼働後にLLMのAPI利用料や推論コストが継続的に発生する。ここを見落としたまま開発費だけを承認すると、利用者が増え処理量が膨らんだ段階で運用費が想定を超え、当初描いたROIが崩れる。
本記事では、初期費だけを見て本番でランニングコストに破綻する失敗を発注者の視点で整理し、TCO（総保有コスト）の内訳と、見積もり段階で運用コストを織り込む方法を示す。具体的な単価は各社のモデルやトークン量で変動が大きいため断定しない。重要なのは、金額そのものより「どの費用が、どの条件で、どれだけ増えるか」を発注前に見える化することである。これは見積の曖昧さを扱う見積書の「AI一式」が曖昧になる理由とは別の論点で、本番運用のTCOとROIに焦点を当てる。
結論：開発費でなく12ヶ月のTCOで承認する
AI開発の投資判断は、初期費用ではなく、本番運用を含む12ヶ月のTCO（総保有コスト）で行う。生成AIはLLMのAPI料金や推論コストが従量で発生し、利用量に比例して増える性質を持つ。開発費だけを承認すると、本番でランニングコストが膨らみ、ROIが崩れる。
- LLM API料金・推論コストは従量で、利用量とともに増える
- 初期費用と、月額・従量の運用費を分けて承認する
- 利用が10倍になったときの月額を、見積段階で試算しておく
- ROIは「削減効果 − 開発費 − 12ヶ月の運用費」で見る
開発会社の提案を、システム開発の稟議・ROIの観点で読み直す視点はシステム開発の稟議・ROI診断で整理しており、生成AIの実装範囲そのものはAI開発のサービスで扱う。まず「本番でいくらかかり続けるか」を握ってから承認したい。
なぜ初期費だけ見ると本番で破綻するのか
生成AIは「作って終わり」の費用構造ではない
従来の受託開発は、構築すれば動き続け、運用費は保守の範囲に収まりやすかった。生成AIを組み込んだ仕組みは違う。回答を1回生成するたびにLLMの推論が走り、API料金が発生する。利用者が使えば使うほど費用が積み上がる、従量の費用構造である。初期費用の安さだけを見ると、この継続費用が視界から外れる。
各社LLMの料金は従量・モデル/トークン依存で変動する
主要なLLMのAPI料金は、利用するモデルの種類と、入力・出力のトークン量に応じて課金される従量制が一般的である。高性能なモデルほど単価が高く、長い文脈や長い回答ほどトークンが増える。RAGのように関連文書を毎回プロンプトへ詰め込む構成では、入力トークンが膨らみやすい。料金は各社が随時改定するため、本記事では特定の単価を示さない。発注時に確かめるべきは、選定モデル・想定トークン量・想定利用回数の3点である。
スケールすると運用費が線形以上に増えることがある
PoCや初期は利用者が少なく、月額の運用費も小さい。だが全社展開で利用者が増えると、API料金は利用回数に比例して増える。加えて、応答速度を保つための処理基盤、リトライ、ログ保全、監視なども増える。「PoCでは月数万円だったのに、本番で桁が変わった」という事態は、利用量の前提を置かずに承認した結果として起きやすい。補助金で初期費だけを賄った場合、運用費が補助対象外で別予算になる点も補助金ありきでAI開発を進める失敗で触れている。
ROIが「開発費だけ」で計算され、運用費が抜ける
稟議書のROIが「削減効果 − 開発費」で組まれていると、本番の運用費が分母から抜ける。削減効果が月50万円でも、運用費が月40万円なら実質効果は月10万円である。開発費の回収年数も、運用費を引いた純効果で割り直す必要がある。ここを織り込まないと、稟議は通っても現場で「効果が出ていない」と評価される。
TCO（総保有コスト）の内訳
AI開発のTCOは、初期費用だけでなく、本番運用で継続的にかかる費用まで含めて把握する。下表の区分で、それぞれが見積に含まれているか、固定費か従量費かを確認したい。
| 費用区分 | 内容 | 性質 | 確認したいこと |
|---|---|---|---|
| 初期構築費 | 要件定義、開発、データ整備、評価 | 一度きり | 範囲が明確か |
| LLM API料金 | 推論時のトークン課金 | 従量（利用量比例） | モデル・想定トークン量 |
| 推論基盤費 | サーバ、GPU、ベクトルDB等 | 月額＋一部従量 | スケール時の増え方 |
| 連携・周辺費 | 検索、ストレージ、外部API | 月額＋従量 | 利用回数依存か |
| 監視・運用費 | ログ保全、障害対応、SLA対応 | 月額 | 担当と工数 |
| 改善・再学習費 | 品質見直し、モデル更新 | 定期 | 頻度と費用 |
| ライセンス・保守 | 周辺ソフト、保守契約 | 月額/年額 | 更新条件 |
このうちLLM API料金・推論基盤費・連携費が、利用量に応じて増える「変動費」である。固定費だけを見て承認すると、本番のスケールで予算が崩れる。ベクトルDBやデータ処理基盤の設計はランニングコストに直結するため、データ基盤の構築の観点でも見ておきたい。
1件あたりの単価で「使うほど損する」境界を見る
ランニングコストの議論で見落とされやすいのが、1件（1リクエスト・1タスク）あたりの処理単価という見方である。AIに1件処理させるたびに発生する従量費を、その1件で生まれる削減効果と並べると、「使えば使うほど黒字か、赤字か」の境界が見える。たとえば1件の処理で人手を5分省けても、その1件にかかる従量費がその5分の人件費を上回るなら、利用が増えるほど赤字が膨らむ。逆に1件あたりが黒字なら、スケールは味方になる。固定費が大きい構成では、損益分岐に達する月間処理件数も併せて押さえておきたい。発注前に「1件あたりいくらかかり、いくら得するのか」を開発会社と握っておくと、全社展開の前にROIの向きが判断できる。
ランニングコストを見積段階で織り込む手順
開発費の妥当性だけでなく、本番でいくらかかり続けるかを、次の手順で見積に織り込む。
- 利用量の前提を数字で置く：1日の想定利用回数、1回あたりの入力・出力トークン量、ピーク時の同時利用を仮置きする。例として日100回／日1,000回の2水準を置くと、費用の幅が見える。
- モデルを選定し従量費を試算する：選ぶモデルごとに、想定トークン量×想定回数で月額のAPI料金を試算する。単価は変動するため、最新の公式料金で都度計算する前提にする。
- スケール時の試算を併記する：利用が現状の10倍になったときの月額を併記する。線形に増える前提で構わない。ここで「全社展開すると桁が変わる」かどうかが見える。
- 固定費と変動費を分ける：推論基盤・監視など月額の固定費と、API料金など利用量で動く変動費を分けて整理する。
- 12ヶ月のTCOとROIに落とす：初期費用＋12ヶ月分の運用費を合計し、削減効果から引いて純効果と回収年数を出す。
この手順で作った試算は、そのまま稟議書の根拠になる。開発会社の提案資料だけで決めず、社内で説明できるTCO表に落とす流れはシステム開発の稟議・ROI診断で扱う観点と重なる。AIエージェントのように複数回の推論を連鎖させる構成は、1タスクあたりの推論回数が増えやすいため、AIエージェント開発を検討する際はとくに従量費の試算を厚めに置きたい。
発注前に確認すべきこと（チェックリスト）
- LLMのAPI料金が、初期費用か月額の従量費か確認したか
- 利用するモデルと、想定トークン量・想定利用回数の前提を確認したか
- 利用が10倍になったときの月額の試算を出してもらったか
- 1件あたりの処理単価と、損益分岐となる月間処理件数を確認したか
- 推論基盤・ベクトルDB・周辺サービスの月額を確認したか
- 監視・運用・障害対応の費用が見積に含まれるか確認したか
- 改善・再学習にかかる費用と頻度を確認したか
- ROIが「削減効果 − 開発費 − 12ヶ月運用費」で計算されているか確認したか
- 費用が想定を超えた場合の上限設定や通知の仕組みがあるか確認したか
- 補助金を使う場合、運用費が補助対象外で別予算になっていないか確認したか
GXOに相談する前に整理しておくとよい情報
- AIで実現したい業務と、想定する利用者数・1日の想定利用回数
- 1回の処理で扱う文書量や文章量の目安（トークン量の見当）
- 全社展開・他部門展開など、将来のスケールの想定
- すでに受け取っている見積書があれば、その初期費用と月額・従量費の内訳
- 想定している投資回収年数と、月あたりに許容できる運用費の上限
- 運用・改善を社内で担えるか、外部に任せたいか
これらがあると、本番のランニングコストを具体的に試算でき、開発費だけでなく12ヶ月のTCOで判断できる。AIの導入可否そのものに迷う段階であれば、AI導入可否アセスメントで費用対効果を含めて整理するとよい。自社のDX・データ活用の現在地を把握したい場合はDX成熟度診断も入口になる。
補足：実務上の注意点
ランニングコストは、設計の工夫である程度コントロールできる。たとえば、すべての処理を高性能モデルで行うのではなく、難易度に応じてモデルを使い分ける、プロンプトに詰め込む文書量を絞る、頻出の回答をキャッシュする、といった方法で従量費を抑えられる。ただし、コスト削減のために精度や安全性を犠牲にすると本末転倒になるため、品質との両立を前提に設計したい。
費用の暴走を防ぐ仕組みも重要である。利用量や月額に上限・アラートを設定し、想定を超えたときに気づける状態にしておく。外部公開の用途では、不正利用や大量アクセスで従量費が跳ね上がるリスクもあるため、レート制限や認証の設計を運用費の前提に含める。
また、ランニングコストはモデルの陳腐化とも関わる。モデルを新しいものへ更新すると単価や挙動が変わり、再評価や再調整の費用が発生する。「作って終わり」にせず、モデル更新と再学習を計画に織り込む論点は作って終わり——モデル陳腐化・再学習を計画せず劣化する失敗（技術的負債）で扱う。生成AIの実装と運用設計を一体で相談したい場合はAI開発のサービスから整理できる。
AIの投資判断で大切なのは、初期費用の安さで選ばないことである。安く見える提案が、運用費や改善費を含んでいない場合、12ヶ月後の総額では高くなることがある。逆に、運用費まで明示した提案のほうが、本番後の予算ブレを抑えられる。発注前にシステム開発の稟議・ROI診断の観点でTCOを握っておくと、稟議も現場の評価も食い違いにくくなる。
関連記事
よくある質問
Q1. LLMのAPI料金は、初期費用に含めて見ておけばよいですか
含めて見るのは誤りである。API料金は利用するたびに発生する従量費であり、本番稼働後に毎月かかり続ける。初期費用とは別に、想定利用量に応じた月額として見積もる必要がある。利用が増えれば費用も増える前提で計画したい。
Q2. ランニングコストはどのくらいを見込めばよいですか
利用するモデル、トークン量、利用回数で大きく変わるため、一律の金額は示せない。発注前に、想定利用回数と1回あたりのトークン量の前提を置き、選定モデルの最新の公式料金で試算するのがよい。あわせて、利用が10倍になったときの月額も併記しておくと判断しやすい。
Q3. PoCでは安かったのに、本番で費用が膨らむのはなぜですか
PoCは利用者も処理量も少ないため、従量のAPI料金や推論基盤費が小さく収まる。本番で利用者が増えると、これらが利用量に比例して増える。PoCの月額をそのまま本番の前提に置くと、スケール時に予算が崩れる。本番想定の利用量で試算し直すことが重要である。
Q4. ROIはどう計算すればAIの運用費を反映できますか
「削減効果 − 開発費」ではなく、「削減効果 − 開発費 − 12ヶ月分の運用費」で純効果を見る。運用費にはLLM API料金、推論基盤費、監視・運用費、改善費を含める。回収年数も純効果で割り直す。これにより、稟議の数字と現場での実感が食い違いにくくなる。
発注前チェックリスト（全30項目・無料）：本連載の30類型を1枚で点検できるチェックリストを無料ダウンロードできます。発注前の社内確認・稟議の添付資料にご利用ください。
GXOでは、AI開発のランニングコストとTCOを試算し、初期費用ではなく12ヶ月の総保有コストとROIで投資判断を整理する支援を行っている。本番でいくらかかり続けるかを見える化したい場合は、無料相談から現状の見積や利用量の前提を持ち込んでほしい。