オンプレAIやローカルLLMを検討するとき、GPUサーバーの見積額だけを見て「高い」「数年で元が取れる」と判断するのは早計です。稼働後には電力、保守、ソフトウェア更新、監視、障害対応が発生し、それを実行する人の時間も必要になります。一方、クラウドにも利用料、通信、運用作業があり、単純にオンプレだけへ「隠れコスト」を足せば公平な比較にはなりません。
本稿では、未確定の単価を置かずに、オンプレAIの総保有コスト（TCO）を7つの費目へ分解します。結論は「オンプレが常に安い／高い」ではありません。同じ業務量、同じ可用性、同じ比較期間で、双方の費用と便益を並べることが判断の出発点です。
01 / BOUNDARY
まず決めるのは金額ではなく、比較の境界
TCOを計算する前に、次の条件を1枚に固定します。
- 対象業務と利用者数
- 推論中心か、追加学習・評価も行うか
- 稼働時間、繁忙時の同時実行数、許容待ち時間
- 可用性の目標と、停止時に許容できる復旧時間
- 保存するデータ量、ログ保持期間、バックアップ範囲
- 外部接続の可否と、更新物を搬入する手順
- 比較期間（例：3年または5年）と、更新・更改の想定
条件が違えば費用も変わります。24時間運転の冗長構成と、平日日中だけ使う単体構成を、同じ「GPU 1台」で比較することはできません。
02 / SEVEN COSTS
オンプレAIのTCOを構成する7つの費目
1. ハードウェア
GPUだけでなく、CPU、メモリ、ストレージ、ネットワーク、ラック、UPS、バックアップ先、予備機・予備部品まで対象にします。初期購入費に加え、設置、増設、撤去、データ消去、更改も別行にします。既存設備を使う場合も費用をゼロとせず、「空き容量」「他用途を諦める機会費用」「保守期限」を確認します。
2. 電力と冷却
カタログ上の最大消費電力だけで年間費を断定しません。アイドル時と業務負荷時の実測電力、稼働時間、電力契約の単価を用います。GPU以外のサーバー部品、ストレージ、ネットワーク、UPS損失、空調も境界に含めます。
年間電力量（kWh）＝ 平均実測電力（kW）× 年間稼働時間（h）× 設備係数
年間電力費 ＝ 年間電力量（kWh）× 自社契約の実効単価（円/kWh）
設備係数は、冷却・給電損失を電力量へ含めるための倍率です。既存のサーバールームでPUEを測定していればその値を用い、測定値がなければ仮定値を使い、仮定であることを試算表へ明記します。
3. 保守・サポート
ベンダー保守、延長保証、ソフトウェアサブスクリプション、交換部品、現地作業、問い合わせ窓口を分けます。「翌営業日対応」と「停止時間を短くする構成」は同じではありません。保守契約の対象外となる部品や、契約終了後の扱いも確認します。
4. 更新
OS、ドライバー、コンテナ基盤、推論エンジン、モデル、周辺ライブラリには、それぞれ互換性とサポート期間があります。費用には、情報収集、脆弱性評価、検証環境でのテスト、承認、本番適用、動作確認、記録を含めます。
閉域環境での署名検証、更新物の搬入、ロールバック設計は別テーマです。本稿の試算表には、それらの作業回数と所要時間だけを反映してください。
5. 監視
監視対象は死活だけではありません。GPU使用率・温度・電力・メモリエラー、ディスク、ネットワーク、応答時間、キュー、モデルの出力品質、ログ容量などを候補にします。監視サーバー、ログ保存先、通知サービスの費用と、アラートを確認する担当時間も必要です。
6. 障害対応
予算化するのは「故障部品の価格」だけではありません。一次切り分け、ベンダー連絡、代替機への切替、復旧、データ再投入、原因分析、再発防止、業務部門との調整を含めます。障害の発生率を根拠なく決めず、シナリオ別に評価します。
- 軽微：サービス再起動で復旧
- 中程度：ドライバーやモデルの切戻し、部品交換が必要
- 重大：サーバー停止、バックアップからの復元、業務の代替運用が必要
各シナリオについて「年に何回起きると仮定したか」「何人が何時間対応するか」「停止1時間が業務へ与える影響」を別々に置きます。
運用体制で先に決める4点
費目を積算する前に、次の4点を自社で確定します。金額よりも先に決まらないと、試算表の作業回数・作業時間の根拠が定まりません。
- 本番適用の承認境界：モデル・ドライバー・設定変更を本番へ適用してよいと判断するのは誰か、承認記録をどこに残すか
- 権限：管理者権限とデータアクセス権を誰に付与し、棚卸しを誰がどの頻度で行うか
- 監査：操作ログ・承認記録・アクセス記録をどの範囲でどれだけの期間保持するか（保持期間はログ容量と監視費に影響します）
- 障害時の縮退：停止まで至らない範囲で許容する縮退運転（機能限定、手動運用、代替系への切替）と、その発動を判断する人
これらは構成が未確定の段階でも検討できます。決めた内容は、7費目の「管理」「変更」「障害」行の作業時間として試算表へ戻します。
7. 人件作業
もっとも抜けやすい費目が、社内担当者と委託先の作業です。定常作業と臨時作業に分けます。
※画面幅が狭い場合、表を横にスクロールできます。
| 区分 | 作業例 | 見積の置き方 |
|---|---|---|
| 定常 | 日次確認、アカウント管理、ログ確認、容量管理、バックアップ確認 | 頻度 × 1回の時間 × 担当人数 |
| 変更 | モデル・ドライバー更新、設定変更、利用部門追加 | 年間回数 × 1回の時間 × 担当人数 |
| 品質 | 回答評価、誤出力調査、評価データ更新 | 月間件数 × 1件の時間 |
| 障害 | 切り分け、復旧、報告、再発防止 | シナリオ別回数 × 対応時間 |
| 管理 | ベンダー調整、資産・契約管理、監査証跡 | 月次または年次の時間 |
人件費単価を公開情報から借りるのではなく、自社の原価計算ルールを使います。単価を置けない段階では、まず「人時」のまま比較しても構いません。
03 / TCO SHEET
TCO試算表は「固定・変動・リスク」の3層で作る
計算式はシンプルです。
比較期間のTCO ＝ 初期費用 ＋ 定常運用費 ＋ 更新・更改費 ＋ リスク対応費 − 残存価値
本テンプレートは金額の優劣を示すものではありません。単価は自社の正式見積・実測で置き換えてください。
※画面幅が狭い場合、表を横にスクロールできます。
| 層 | 主な項目 | ドライバー（増減要因） | 根拠 |
|---|---|---|---|
| 初期・固定 | 機器、設置、基盤ソフト、設計 | GPU数、冗長化、保存容量 | 見積書・構成表 |
| 定常・変動 | 電力、冷却、保守、監視、人件作業 | 稼働時間、負荷、ログ量、利用者数 | 実測・契約・作業記録 |
| 更新・更改 | 検証、適用、部品・機器更改 | 更新頻度、サポート期限 | ライフサイクル表 |
| リスク | 障害対応、停止影響、緊急調達 | 可用性、復旧時間、代替手段 | シナリオと実績 |
金額は一点ではなく、少なくとも「低位・基準・高位」の3ケースで示します。たとえば稼働率、ログ保持量、更新回数、障害対応時間だけを変え、どの前提がTCOへ効くかを確認します。これが感度分析です。
各方式に自社データを入力
- 非金銭評価：情報管理
- 非金銭評価：遅延
- 非金銭評価：停止耐性
- 非金銭評価：拡張性
04 / COMPARISON
クラウドとの比較でそろえるべき条件
オンプレとクラウドは、次の条件をそろえて比較します。
- 同じモデルと品質要件
- 同じ処理量、ピーク性能、応答時間
- 同じ可用性、バックアップ、復旧目標
- 同じデータ保持・監視・セキュリティ範囲
- 同じ比較期間
- 両方の移行・運用人件作業
データを外へ出せない、回線断でも現場を止められない、既存設備と低遅延で連携したい、といった要件は金額だけでは表せません。TCOの横に、情報管理、遅延、停止耐性、拡張性を評価した非金銭項目を置きます。負荷が読めない段階ではクラウドやハイブリッドで実測し、安定した処理だけをオンプレへ移す選択肢もあります。
05 / EVIDENCE
導入前に最低限そろえる5つの証拠
- 本番相当ワークロードのGPU使用率、応答時間、電力量
- 機器・保守・ソフトウェアの正式見積と対象範囲
- 全構成部品のサポート期限、更新頻度、互換性条件
- 定常・更新・障害時のRACI（実行・責任・相談・報告先）
- 低位・基準・高位のTCOと、クラウド／ハイブリッドの同条件比較
この5点がなければ、総額が精密に見えても前提が変わるたびに結論が揺れます。逆に、単価が確定していなくても、構成と作業量が見えていれば、見積取得後に更新できる試算になります。
業務要件を固定
要件表
PoCで性能・電力を実測
測定ログ
7費目を積算
TCO表
3ケースで感度分析
比較グラフ
方式選定・運用分担
RACI
06 / FAQ
よくある質問
オンプレAIはクラウドより安くなりますか？
一概には言えません。処理量が安定し機器を継続的に使える場合は、オンプレの設備投資を稼働量で分散しやすくなります。一方、需要変動が大きい、短期間だけ使う、運用要員を確保できない場合はクラウドが有利になり得ます。同じ要件と期間で比較してください。
GPUサーバーの価格が分かればTCOを計算できますか？
機器代だけでは不足します。少なくとも電力・冷却、保守、更新、監視、障害対応、人件作業を加えます。設置、バックアップ、ネットワーク、撤去・データ消去も構成に応じて必要です。
電力費はカタログの最大消費電力から出せますか？
予算上限の参考にはなりますが、基準ケースには実測値を推奨します。本番相当負荷の平均電力、アイドル時間、年間稼働時間、周辺機器と冷却、実際の電力契約単価を使います。
更新作業は保守契約に含まれますか？
契約によります。更新物の提供、互換性検証、停止調整、本番適用、動作確認、切戻しのどこまでが含まれるかを確認してください。閉域環境では搬入と承認の追加作業も見積もります。
まだ構成が決まっていなくても相談できますか？
はい。まず対象業務、データの置き場所、利用時間、処理量、停止許容時間を整理すれば、オンプレ・クラウド・ハイブリッドの比較条件を作れます。未確定の単価は空欄または幅で管理し、PoCの実測で更新します。
07 / REFERENCES
参考文献・出典
- NIST, SP 800-40 Rev.4: Guide to Enterprise Patch Management Planning — 更新を予防保守として計画する根拠。（2026-09-21 参照）
- NIST, SP 800-92: Guide to Computer Security Log Management — ログ管理範囲の根拠。（2026-09-21 参照）
- NIST, SP 800-61 Rev.3: Incident Response Recommendations and Considerations — 対応・復旧を事前計画へ含める根拠。（2026-09-21 参照）
- NVIDIA, DCGM Field Identifiers — GPU電力・累積エネルギーの取得に関する参照先。（2026-09-21 参照）
- NVIDIA, DCGM Health Monitoring — GPUヘルス監視の範囲に関する参照先。（2026-09-21 参照）
- NVIDIA, AI Enterprise Lifecycle Policy — リリース系列・サポート期間の確認先（本稿では区分名・期間の具体値を検証していません）。（2026-09-21 参照）
出典は2026年9月21日時点の公開資料を基にしています。各リンク先の改訂状況と版は導入時に再確認してください。外部リンクは新しいタブで開きます。