この記事のポイント
クラウド生成AIに預けられない機密データを扱う企業は、オンプレミス基盤の3レイヤー(ハード+推論ミドル+モデル)で自社設計する選択肢が現実味を帯びている
Dell AI Factory・HPE Private Cloud AI・Nutanix Enterprise AIなど主要ベンダーがNVIDIA認定構成で提供、自組み立てより導入期間を短縮しやすい
デジタル庁「源内」の国産LLM7モデル選定(tsuzumi 2・cotomi v3・PLaMo 2.0 Prime等)で、日本語処理性能と主権要件を両立させる道筋ができた
中規模PoCなら数百万円台から、フル本番のGPUクラスタは数千万円〜数億円規模。損益分岐点はクラウド従量課金との2〜3年比較で判定するのが実務的
モデル陳腐化・冷却電力・運用人材の3点で詰まる企業が多く、ハード導入前に運用設計まで含めた計画が必須

Microsoft MVP・AIパートナー。LinkX Japan株式会社 代表取締役。東京工業大学大学院にて自然言語処理・金融工学を研究。NHK放送技術研究所でAI・ブロックチェーンの研究開発に従事し、国際学会・ジャーナルでの発表多数。経営情報学会 優秀賞受賞。シンガポールでWeb3企業を創業後、現在は企業向けAI導入・DX推進を支援。
オンプレミス生成AIとは、大規模言語モデル(LLM)などの生成AIを、自社のデータセンターやサーバー上で構築・運用する基盤を指します。
クラウドの生成AIサービスに機密データを預けることができない企業や、規制産業・国産LLM活用を検討する企業を中心に、2026年に入って本格的な導入検討が進んでいます。
本記事では、オンプレミス生成AIの定義から基盤を構成する3つのレイヤー、Dell・HPE・Nutanixなど主要ベンダー比較、デジタル庁「源内」で選定された国産LLM、コスト構造とTCO、クラウドとの使い分け、導入で見落とされやすい論点、関連製品・検証・ソブリンAIの動向までを2026年7月時点の情報で体系的に整理します。
オンプレミス生成AIとは

オンプレミス生成AIとは、大規模言語モデル(LLM)や画像生成モデルといった生成AIを、外部のクラウドサービスに預けるのではなく、自社のデータセンターやサーバー上に基盤ごと構築して運用する形態を指します。
「オンプレミス(on-premises)」は本来「自社の敷地内」という意味で、モデルそのものではなく、モデルを稼働させるサーバー・GPU・推論ミドルウェア・ネットワークを含むインフラ全体を自社管理下に置くことを示します。
2026年に入って、この選択肢が本格的に再評価されています。GPU出荷・オープンウェイトモデルの性能向上・国産LLMの流通が同時に揃い、自社データを外に出さずに実用レベルの推論を回せる現実的な選択肢が、ようやくエンタープライズ規模で組めるようになった段階です。
クラウド生成AI・ローカルAI・エッジAIとの位置関係

オンプレミス生成AIは、クラウド生成AIやローカルAI、エッジAIとしばしば混同されますが、運用主体と設置場所の2軸で整理すると差が明確になります。
-
クラウド生成AI
OpenAI・Anthropic・Googleなどのクラウドサービス経由で利用する形態。初期投資は低く最新モデルにも即アクセスできる一方、機密データが事業者側に渡る
-
オンプレミス生成AI
自社データセンター・自社サーバー室に基盤を構築。中〜大規模のGPUクラスタで、部門横断・全社利用を想定
-
ローカルAI(個人PC・ワークステーション)
個人の開発者や業務端末上でOllama等を動かす形態。10796_ローカルAIで詳述
-
エッジAI
工場設備・カメラ・IoTデバイスなど、現場側で推論を完結させる形態。低遅延・オフライン動作が主軸
本記事は「エンタープライズ規模のオンプレミス生成AI基盤」を中心に扱います。
オンプレミス生成AI基盤を構成する3つのレイヤー

オンプレミス生成AI基盤は、単にGPUサーバーを買ってくれば動くものではありません。ハードウェア層・推論ミドルウェア層・モデル層の3レイヤーをそれぞれ選定・組み合わせて初めて業務利用に耐える基盤になります。

NVIDIA AI Enterpriseが対象とする主要ワークロード群(出典:NVIDIA AI Enterprise)
NVIDIA AI Enterpriseは、上記のような生成AIチャット・データ分析・シミュレーション・音声処理などを1つの推論ミドル基盤でカバーできるように設計されており、オンプレミスGPU上で本番運用する際の中核ソフトスタックとして採用されるケースが多くなっています。以下の表で、各レイヤーの役割と代表的な選択肢を整理しました。
| レイヤー | 役割 | 代表的な選択肢 |
|---|---|---|
| ハードウェア層 | GPU計算資源・ストレージ・ネットワーク・冷却 | NVIDIA H200/B200/GB200/Dell PowerEdge XE9712/HPE ProLiant DL380a Gen12/NVIDIA-Certified Systems |
| 推論ミドルウェア層 | モデル管理・API公開・GPU割り当て・監視 | NVIDIA AI Enterprise/NVIDIA NIM/vLLM/Ollama/Red Hat OpenShift AI |
| モデル層 | 実際の推論を担う生成AIモデル | Llama 3.3 70B/Qwen 2.5 72B/DeepSeek/国産LLM(tsuzumi 2・cotomi v3等) |
この表が示すのは、どのレイヤーもクラウド生成AIでは事業者側に隠蔽されていた部分を、自社が主体的に選ぶ必要があるという点です。
以下、各レイヤーの選定ポイントを個別に見ていきます。
ハードウェア層——GPU選定と冷却・電力

ハードウェア層で最も投資額が大きく、選定が難しいのがGPUです。2026年時点でエンタープライズ用途の主流はNVIDIA Blackwell世代(B200・GB200)ですが、既存H100/H200を活用する構成も引き続き有効です。
-
H200(HBM3e 141GB)
量子化・コンテキスト長・KVキャッシュ・バッチサイズなどの実行条件によっては70B〜120Bクラスのモデルを1枚で推論可能。既存H100からの移行として現実的
-
B200/GB200(Blackwell)
70B超のモデルを高スループットで推論、大規模学習・エージェント同時実行に向く。高密度構成では水冷が有力だが、Dell PowerEdge XE9780のような8基搭載の空冷サーバー構成も存在する
-
RTX PRO 6000 Blackwell Server Edition
比較的低い予算帯でBlackwellを導入したいエンタープライズ向け。HPE Private Cloud AIのAir-gapped構成でも採用
Blackwell世代の導入は冷却・電源容量の増強要否を構成ごとに確認する必要があります。
8基搭載の空冷サーバー構成も選べる一方、高密度ラック運用や大規模クラスタでは水冷化のファシリティ工事が必要になるケースも多く、冷却・電力設計を軽視すると、GPU本体は届いたのに稼働開始が半年遅れるといった事態になりかねません。
推論ミドルウェア層——AI Enterprise/NIMかOSSか

モデルをただGPU上で動かすだけならvLLMやOllamaといったOSSでも可能ですが、エンタープライズ運用ではAPI公開・GPU割り当てオーケストレーション・監視・アクセス制御まで含めた推論ミドルが必要です。
商用パスの主流はNVIDIA AI Enterpriseで、GPU 1枚あたり年額$4,500のサブスクリプション(5年サポート込みの永久ライセンスは$22,500/GPUで別途提供)として利用します。
この上でNVIDIA NIM(Inference Microservices)を使えば、Llama・DeepSeek・国産LLMをコンテナ単位でAPIとしてデプロイできます。
OSSパスはvLLM+KubernetesまたはRed Hat OpenShift AIの組み合わせが一般的です。ライセンスコストは抑えられますが、運用ノウハウを自社で持つ前提になります。
モデル層——オープンウェイトLLMと国産LLMの2択

モデル層は、大きく分けてオープンウェイトモデル(Llama 3.3 70B・Qwen 2.5 72B・DeepSeek等)と、日本市場向けの国産LLM(NTT tsuzumi 2・NEC cotomi v3・PFN PLaMo 2.0 Prime等)の2択になります。
Meta・Alibabaのオープンウェイトモデルはグローバル最新性能を追いかけやすく、コード・多言語処理では第一候補です。
一方、日本語の敬語・業界慣習・法令文書の扱いでは国産LLMのほうが精度で優位に立つケースが多く、金融・医療・公共の実務では国産LLM検討が現実的な選択肢になっています(詳細は後段の国産LLMセクションで扱います)。
オンプレミス生成AIのメリットとデメリット

オンプレミス生成AI基盤の性質は、クラウド生成AIとの比較よりも先に、「自社に基盤を持つこと自体が何をもたらすか」を単体で押さえておく必要があります。
以下、実務でよく挙がるメリット4点とデメリット3点を、それぞれ1〜2文で総覧します(クラウドとの詳細な使い分けは次のセクションで扱います)。
オンプレミス生成AI 4つのメリット

-
機密データを外に出さない
プロンプト・応答・埋め込みベクトルまで含めて、すべての推論トラフィックを社内ネットワーク内で完結できます。医療・金融・法務の機密文書を扱う業務では、この一点だけでオンプレ選択が決まるケースが多く見られます
-
モデル・推論基盤のカスタマイズ自由度
オープンウェイトモデルの重みを保持したうえで、追加学習・RAG構築・独自トークナイザ導入・量子化まで自社判断で行えます。クラウドAPIでは触れないハイパーパラメータ・システムプロンプト層に踏み込めるのが、他の運用形態にない強みです
-
既存システムとの近接統合
ERP・MES・電子カルテ・基幹DBがオンプレに残っている企業では、生成AI基盤を同じデータセンターに置くことで低遅延API連携・共通ID基盤・共通監査ログの活用が可能になります
-
利用量が読める領域では長期TCOで優位
月間APIコール数が大きく、利用量が読める運用(社内チャット・要約バッチ・大量ドキュメント処理)では、GPU固定資産化のほうがクラウド従量課金より安く着地するケースが増えています。損益分岐の考え方は後段のTCOセクションで詳述
この4点は「オンプレの本質的な利点」であり、クラウド利用の否定ではありません。用途によってクラウドが依然として有利な領域があることは、次セクションで整理します。
オンプレミス生成AI 3つのデメリット

-
初期投資が大きく、意思決定の速度が落ちる
中規模のGPUサーバー導入で数百万〜1,000万円台、フル本番のGPUクラスタでは数千万円〜数億円規模になります。稟議・調達・データセンター工事を通す期間を含めると、PoC承認から本稼働まで6〜12か月かかるのが標準です
-
運用人材の確保とスキル維持が難しい
GPU保守・推論ミドル運用・モデル選定・ファインチューニングまで自社で回すには、AI基盤エンジニア+インフラエンジニア+MLOpsエンジニアの複合体制が必要です。中規模企業にとってはこの人件費が最大のランニングコストになりやすい
-
モデル陳腐化リスクを自社で吸収する必要がある
クラウドでは新モデルへのアクセスや更新機能が提供されるのに対し、オンプレでは6〜12か月周期で新世代モデル(Llama 5・DeepSeek v4等)が出るたびに評価・切替判断を自社で回さなければなりません(クラウドでも固定バージョン・Provisioned構成では手動移行が必要ですが、選択肢が用意されている点はオンプレと違います)。
基盤選定時に「モデル差し替えが容易な推論ミドル」を選ぶかどうかで、この負担は大きく変わります
デメリットの3点はすべて「基盤導入時に運用設計を後回しにすると顕在化する」性質のものです。ハード購入前に、これら3点への対処を含めた3年計画を組めるかが、オンプレ成功の分水嶺になります。
クラウド生成AIとの違いと選び方

オンプレミス生成AIの導入判断で最も詰まりやすいのが、「うちの会社はクラウドとオンプレのどちらが向いているか」の判定です。
単純なコスト比較だけで決めると、機密データ運用に足りない基盤を選んでしまうことが実務ではよく起きます。
以下の表で、両者の主要な違いを整理しました。
| 観点 | クラウド生成AI | オンプレミス生成AI |
|---|---|---|
| データ所在 | 事業者側のデータセンター | 自社データセンター内 |
| 初期投資 | ほぼゼロ(従量課金) | 数百万〜数億円のGPU+施設投資 |
| ランニングコスト | 従量課金(月額の変動が大きい) | 電力・冷却・運用人件費(ほぼ固定) |
| 最新モデル追随 | 更新機能を提供(方式・設定により手動移行あり) | 自社で世代交代の評価・切替 |
| カスタマイズ自由度 | API仕様の範囲内 | 重み・推論ミドル・トークナイザまで自社判断 |
| 応答レイテンシ | 数百ms〜(インターネット経由) | 数十ms〜(LAN内完結) |
| 業務システム連携 | API経由でVPN・専用線接続 | 同一DC内で直接統合 |
| 規制・監査対応 | 事業者のSOC2/ISMS等に依存 | 自社の監査基準に準拠可能 |
この比較表が示すのは、両者は代替関係ではなく用途による使い分け関係にあるという点です。全部をどちらかに寄せるのではなく、業務種別ごとに配置先を決めるハイブリッド運用が現実解になります。
オンプレミスを選ぶべき企業の4つの条件

以下の条件のいずれかに強く当てはまる企業は、オンプレミス生成AI基盤を第一候補として検討する価値があります。
-
機密データを外部に出せない業種
金融(取引データ・与信情報)、医療(電子カルテ・診療情報)、法務(契約書・訴訟資料)、公共(住民情報・機密文書)など、規制または業界慣習により顧客データの外部送信が困難な業種
-
月間APIコール数が読めて量が多い
社内チャットボット・大量ドキュメント要約・定型帳票生成など、実利用量とモデル単価を基に2〜3年TCOを比較できる用途。単価×トークン数×契約形態を自社構成で試算した結果、クラウド従量課金と比べてオンプレ側の投資回収が見えるライン
-
既存の基幹システムがオンプレに残っている
ERP・MES・電子カルテ・SCADAが自社DC内にあり、生成AI基盤を同一DCに置くことで統合・監査・低遅延の利点を最大化できる構成
-
主権要件・国内完結を求められる
個別の法令・契約・内部規程等で「国内で処理・国内で保管」が求められる領域。国産LLMの活用と組み合わせやすい
逆にこの4条件のいずれにも当てはまらない企業では、まずクラウド生成AIで用途を確立してから、必要が明確になった段階でオンプレを追加する順序のほうが失敗しにくいです。
SIerとしての実務的な使い分け——3つのパターン

支援経験からは、実際の企業では以下の3パターンで基盤を組み分けるケースが増えています。
-
全面クラウド型
中小・スタートアップ、まだ用途が固まっていない企業、機密度が高くない業務中心の企業。ChatGPT Enterprise・Azure OpenAI Service・Claude for Workで完結
-
ハイブリッド型(最多パターン)
機密データを扱う業務のみオンプレ、それ以外はクラウド。金融・医療・製造の中堅〜大手で多い。オンプレ側は国産LLMやLlama、クラウド側はGPT-5.5・Claude Opus 4.8と使い分ける
-
フルオンプレ型
超機密領域(防衛・原子力・国家インフラ)、大規模利用で従量課金が経営を圧迫する企業、主権要件が明確な公共領域。なお、デジタル庁「源内」はガバメントクラウド上で稼働する政府向けAI基盤で厳密には「フルオンプレ」ではないが、国産LLMを国内主権環境で運用するソブリンAIの代表事例
実務での選定軸は、「まずクラウドで使いこなす→機密業務や利用量増大で必要な部分だけオンプレ化」という順序が現実的です。最初からフルオンプレを狙うと、初期投資規模とROI回収期間の両方でハードルが高くなります。
主要ベンダーのオンプレミス生成AI基盤を比較

オンプレミス生成AI基盤を自組み立てするには、GPU・ネットワーク・推論ミドル・監視・セキュリティを個別に調達して統合する必要があり、専門人材を揃えても半年〜1年の構築期間がかかります。この負担を軽減するため、2024〜2026年にかけて主要ベンダーがNVIDIA認定の統合パッケージ「AIファクトリー」型ソリューションを相次いで投入しました。
以下の表で、本記事執筆時点の主要ベンダー6社の代表的オンプレミス生成AI基盤を整理しました。
| ベンダー | 製品名 | 特徴 | ハードウェア |
|---|---|---|---|
| Dell | Dell AI Factory with NVIDIA | PowerEdge XEシリーズ+NVIDIA Blackwell、水冷・空冷選択可、リファレンスアーキテクチャ多数 | PowerEdge XE9712(72 GPU/rack) |
| HPE | HPE Private Cloud AI | 2026 GTC発表で最大128 GPU拡張とAir-gapped構成追加、Fortanix Confidential AI認証中(2026 Q3対応予定) | ProLiant DL380a Gen12+RTX PRO 6000 Blackwell |
| Nutanix | Nutanix Enterprise AI (NAI) | GPT-in-a-Box 2.0を構成する新製品として位置づけ、Dell/HPE/Lenovoサーバー互換(GPT-in-a-Box 2.0構成でUnified Storageを利用) | サードパーティGPUサーバー+NAIソフトウェア |
| Cisco | Cisco AI PODs / UCS AI Server | ネットワーク統合を強みに持つNVIDIA認定AIファクトリー | UCS Cシリーズ+NVIDIA HGX |
| VMware (Broadcom) | VMware Private AI Foundation with NVIDIA | vSphere基盤上でNVIDIA AI Enterprise統合、既存vSphereユーザー向け | 既存vSphere互換GPUサーバー |
| Red Hat (IBM) | Red Hat OpenShift AI | Kubernetesベースの推論ミドル、OSSパスの本命、ハード非依存 | 各社GPUサーバー+OpenShift |
この比較から見えるのは、ハードウェア主体(Dell・HPE・Cisco)/既存基盤との親和性(Nutanix・VMware)/OSSベース(Red Hat)という3つの型があるという点です。

Nutanix Enterprise AI × NVIDIA NIMの3クラウド(AWS/Azure/GCP)展開構成(出典:Nutanix Blog)
Nutanix Enterprise AI(NAI)は、同一のNVIDIA AI Enterprise NIM層をAWS・Azure・Google Cloudの各パブリッククラウドとオンプレミスの両方で動かせる設計になっており、ハイブリッド運用を前提とする企業に選ばれやすい構造です。以下、選定時の見落としやすい観点を3つ整理します。
ベンダー選定で見落としやすい3つの観点

-
既存インフラベンダーとの親和性を優先
すでにDell PowerEdge中心のデータセンターなら Dell AI Factory、HPE ProLiant中心ならHPE Private Cloud AI、VMware vSphere基盤ならVMware Private AIが自然な選択肢。AIファクトリー単独でベンダーを乗り換えると、既存の運用ノウハウと監視基盤が使えなくなる
-
モデル層の柔軟性(Nutanix・Red Hat・vLLMパス)
特定ベンダーロックインを避け、Llama・DeepSeek・国産LLMを自由に差し替えたい場合は、モデル層を分離できるNutanix Enterprise AIまたはRed Hat OpenShift AIが強い。逆にNVIDIA NIM前提の運用に振り切るなら、Dell/HPE/CiscoのNVIDIA連携が濃い構成が有利
-
Air-gapped要件と主権要件
外部ネットワークから完全遮断された環境(防衛・機密業務・特定金融業務)が要件になる場合は、HPE Private Cloud AIのAir-gapped構成やCisco AI PODsのAir-gapped対応が現実的な選択肢。VMware Private AIも自社DCで完結する構成が可能

HPE Private Cloud AIとNVIDIA連携(出典:HPE Newsroom)
HPE Private Cloud AIは2026年3月のNVIDIA GTCでAir-gapped構成の追加と最大128 GPUまでの拡張が発表されており、Fortanix Confidential AIの認証取得(2026 Q3対応予定)と併せて機密業務向けのオンプレ選択肢としての地位を強めています。
いずれの選択でも、PoC段階で「モデル差し替えのしやすさ」と「監視・ログ基盤の統合可否」を実測しておくことが、本番運用開始後の修正コストを最小化します。
主要な国産LLMをオンプレミスで利用する選択肢

日本市場のオンプレミス生成AI検討で、2026年に大きな追い風になったのがデジタル庁による国産LLM選定と、日本AI推進法(AI基本法)の全面施行です。
両者はセットで、日本企業がオンプレ基盤に載せる国産LLMの実用度を大きく引き上げました。
日本AI推進法とデジタル庁「源内」の動き

日本AI推進法(正式名称:人工知能関連技術の研究開発及び活用の推進に関する法律)は、2025年5月28日に成立、同年6月4日に公布、9月1日に全面施行されました。内閣に「人工知能戦略本部」を設置し、AIの研究開発・活用推進と、権利侵害防止のための透明性確保を国策として位置づけたものです。
その具体的な運用の一つが、デジタル庁の政府向けAI基盤である源内(げんない)です。2026年3月、デジタル庁は源内で試用する国産LLMとして7モデルを選定し、2027年度以降に有償政府調達に進む段階的なロードマップを公表しました。

デジタル庁「源内」における国産AI育成の取組状況と3つの狙い(出典:デジタル庁 参考資料PDF)
上記の政府資料が示すとおり、源内は「国産AI育成」「行政現場からのフィードバックによる性能改善」「政府調達による安定需要創出」の3つを狙いに据えており、単なる政府内利用にとどまらず日本の国産AI産業全体を押し上げる政策装置として位置づけられています。
これは政府案件だけでなく、金融・医療・公共・製造の民間企業にとっても「国産LLMを本番運用に載せる際の参考」として参照されうる位置づけです(民間市場での選定順位を政府調達が直接示すわけではない点は留意)。
源内で選定された主要な国産LLM7モデル

以下の表で、デジタル庁が2026年3月に選定した国産LLM7モデルを整理しました。
| ベンダー | モデル名 | 特徴 |
|---|---|---|
| NTTデータ | tsuzumi 2 | 軽量ながら高い日本語処理性能。医療機関・金融からの相談が多い |
| NEC | cotomi v3 | 業界特化・エンタープライズ実装重視 |
| 富士通 | Takane 32B | Cohereと共同開発、日本語エンタープライズ向けに最適化 |
| Preferred Networks | PLaMo 2.0 Prime | ゼロから独自開発の基盤モデル、日本語ネイティブ設計 |
| ソフトバンク | Sarashina2 mini | 大量日本語テキスト事前学習、軽量モデルの完成度に強み |
| KDDI・ELYZA | Llama-3.1-ELYZA-JP-70B | MetaのLlama 3.1に日本語追加学習、大規模モデルの日本語適応 |
| カスタマークラウド | CC Gov-LLM | 官公庁業務特化、行政文書処理に最適化 |
この一覧が示すのは、日本企業には「基盤モデルをゼロから独自開発する路線(PFN/PLaMo)」と「MetaのオープンモデルをベースにJP追加学習する路線(ELYZA)」の2アプローチが並立しているという点です。どちらもオンプレ基盤で動かせるため、業務特性に応じて選択できます。
国産LLMをオンプレで動かす際の実務ポイント

国産LLMをオンプレ基盤で運用する場合、次の3点を事前に確認しておくと、選定後の手戻りを防げます。
-
モデルウェイトの提供形態
Hugging Face公開・商用ライセンス契約・パートナーSI経由の3パターンがあります。tsuzumi 2は「INTELLILINK Private AI スタートパック」などNTTデータ先端技術のオンプレ導入パッケージ経由でも提供されています
-
必要GPUメモリと推論性能
32B〜70B級モデルは、量子化などの条件次第でH200(141GB)1枚で動かせますが、70B級を量子化なしのFP16で運用する場合は重みだけで約140GBに達するため複数GPUが必要。事前にモデルカードで確認
-
日本語性能ベンチマークの確認
JGLUE・JMMLU等の日本語ベンチマーク、または自社業務ドキュメントを使ったPoC評価が必須。海外モデルとのA/B比較を最低1週間実施することが実務推奨
NTTが2026年2月の記者会見で公表した情報では、tsuzumi関連の国内引き合いが約2,000件に到達し、地方自治体・金融機関・医療機関を中心にクローズドAI需要が顕在化していると説明されています。国産LLM×オンプレ構成は、既に日本市場での実装が急速に立ち上がっている段階です。
オンプレミス生成AIの導入・運用コストとTCOの考え方

オンプレミス生成AI基盤の投資判断で最も難しいのが、初期投資(CAPEX)と3〜5年のランニング(OPEX)を含めたTCO(総所有コスト)試算です。GPU本体の値段だけで比較すると必ずクラウド有利に見えてしまうので、施設・電力・人件費まで含めた3年トータルで組む必要があります。
3階層のコスト構造

オンプレミス生成AI基盤のコストは、大きく3階層に分けて見積もります。
-
初期投資(CAPEX)
GPUサーバー本体・ネットワーク機器・ストレージ・水冷/空冷設備・データセンター工事。ミニマム構成(H200×1台)で数百万円台、中規模(H200×4〜8台)で数千万円、フル本番のBlackwellクラスタで数億円規模
-
ランニング(電力・冷却)
GPUサーバーの消費電力+冷却電力+PUE(データセンター効率)。H200 1枚で約700W、B200で約1,000Wを消費し、PUE 1.5前後を掛けた電力コストが月額で効いてきます
-
運用人件費(最大の固定費)
AI基盤エンジニア・インフラエンジニア・MLOpsエンジニアの人件費。中規模企業でも最低2〜3名は必要で、年間3,000万〜5,000万円の人件費が継続的にかかる
この3階層のうち、多くの企業がCAPEXだけを見て意思決定を進め、後から運用人件費で採算が崩れるというパターンが目立ちます。特に運用人材の採用難と定着コストは、初期試算で過小評価されがちです。
中規模企業のミニマム構成例

具体的な金額感を掴むため、中規模企業のミニマム構成でTCOを試算しました。以下はあくまで目安値で、実際の見積もりはベンダー・構成・為替で変動します。
| 項目 | ミニマム構成 | 中規模構成 | 大規模構成 |
|---|---|---|---|
| GPU | H200×1〜2枚 | H200×8枚 or B200×4枚 | B200×32枚以上 |
| CAPEX(初期) | 500万〜1,500万円 | 5,000万〜1億円 | 3億円〜 |
| 電力(月額) | 5万〜20万円 | 30万〜80万円 | 300万円〜 |
| 運用人件費(年額) | 1,500万〜3,000万円 | 3,000万〜5,000万円 | 1億円〜 |
| 想定同時利用者数 | 数十〜100名 | 数百〜1,000名 | 数千名〜全社 |
| 3年TCO目安 | 5,000万〜1.2億円 | 1.5億〜3億円 | 6億円〜 |
この試算から見えるのは、同時利用者数100名規模なら3年で5,000万〜1.2億円がひとつの目安という点です。
同じ利用規模のクラウドコストは、利用モデル(GPT・Claude・Gemini等)・入出力トークン数・利用率・契約形態(ChatGPT Enterpriseは個別契約、Azure OpenAIはモデル・トークン・デプロイ方式で料金が変動)・為替で大きく振れます。
実際の損益分岐は、自社ユースケースの実利用量をOpenAI Enterprise営業窓口・Azure AI Foundryのコスト管理などで個別試算して比較する必要があります。
損益分岐点の考え方

損益分岐は「クラウド従量課金の月次コストが、オンプレ運用の月次コストを超えるか」で判定するのが実務的です。
-
月間APIコール数×平均単価
クラウド側のコスト=月間コール数×平均トークン数×モデル単価。ヘビーユースの社内チャットや大量ドキュメント処理では月額数百万円に達しやすい
-
オンプレ側の月次償却+運用コスト
CAPEXを3年で割った月次償却+電力+人件費。ミニマム構成で月額200万〜300万円、中規模で500万〜700万円が目安
-
2〜3年で回収できるかを判定
クラウド月次がオンプレ月次を上回るなら移行検討。逆にクラウド月次のほうが安いなら、その業務はクラウドを継続する
単純な金額比較だけでなく、「機密データを外に出せない」という定性要件で決まる領域については、TCO計算とは別軸で先にオンプレ確定させ、それ以外の業務でクラウド活用を最大化する順序が実務的です。
導入前に確認したいセキュリティ・性能・運用上の論点

オンプレミス生成AI基盤の導入は、ハードウェアが届いた時点では半分しか進んでいません。
セキュリティ運用・性能チューニング・人材・モデル陳腐化の4点を事前に設計しておかないと、稼働開始後に「導入したのに使えない」状態に陥ります。以下、実際のPoC〜本番移行で頻繁に詰まる4つの論点を整理します。
詰まりポイント1:規制・監査要件のクリア設計

医療なら3省2ガイドライン(医療情報システムの安全管理に関するガイドライン 第7.0版)、金融ならFISC安全対策基準など、業界別のコンプライアンス要件がオンプレ選択の主要理由の一つです。
一方、「オンプレ=安全」と思考停止すると監査で落ちるのが、この領域の落とし穴です。オンプレでも以下は追加で設計する必要があります:ネットワーク分離、監査ログ収集、アクセス制御、暗号化キー管理、脆弱性パッチ運用、災害対策。ハード導入前に情報セキュリティ部門と監査部門を巻き込んだ設計レビューを通しておくことが必須です。
詰まりポイント2:性能チューニングと量子化判断

推論性能はGPUメモリ・モデルサイズ・量子化(FP16/FP8/INT8/INT4)・バッチサイズ・KVキャッシュサイズなど多数のパラメータで決まります。量子化なしで動かして「遅い」と諦めるケース、逆に量子化しすぎて業務精度が落ちるケースが両方頻発します。
- 70Bクラスモデルは、H200×1枚でFP8量子化+バッチサイズ調整で実用速度に到達
- 精度重視の業務(法務・医療の意思決定支援)ではFP16運用、コスト重視の社内チャットではFP8/INT8運用が使い分けの目安
- PoCで自社業務データを使った速度・精度のセット評価を、量子化パターンごとに実施する
詰まりポイント3:運用人材の確保と定着

前セクションでも触れたとおり、AI基盤の運用人材は市場で最も採用難易度が高いポジションの一つです。オンプレを選ぶなら、以下のいずれかで人材リスクを吸収する必要があります。
- 自社で採用+育成(採用に6〜12か月、育成に1年)
- SI・MSP(マネージドサービスプロバイダ)に運用委託
- ベンダー(Dell・HPE・Nutanix等)のマネージドオプションを利用
- 統合アプライアンス(AIファクトリー型)で運用の複雑度を下げる
運用人材の確保はオンプレ×AI導入における主要な成功要因の一つです。ハード選定と同じ重要度で計画する対象です。
詰まりポイント4:モデル陳腐化の吸収設計

クラウドでは新モデルへのアクセスや更新機能が事業者側から提供される(ただし固定バージョン・Provisioned構成では手動移行が必要な場合あり)のに対し、オンプレでは自社が能動的に評価・切替判断を回す必要があります。
Microsoft Foundry のモデル更新ポリシーなどデプロイ方式ごとの動作差も踏まえた上で、「Llama 3.3 70B前提で組んだ基盤が、Llama 5・DeepSeek v4の登場で相対的に劣位になる」サイクルが今後3〜5年は継続する前提で設計する必要があります。
対策は、推論ミドル層でモデル差し替えのしやすさを最優先で設計することです。
- NVIDIA NIMやvLLMのようにモデル追加がコンテナ差し替えで済むミドルを採用
- モデルの重みだけを外部ストレージから読み込ませ、基盤本体は変更なしに切り替え可能な構成にする
- 四半期ごとに新モデル評価を回すMLOpsサイクルを社内で運用する
この4点はいずれも、基盤導入時の設計段階でコストと工数を積んでおかないと、後付けでは対処が難しい性質のものです。ベンダー選定と並行して運用チーム設計まで進めることを強く推奨します。
オンプレミス生成AIの導入手順と周辺動向

オンプレミス生成AI基盤の導入は、いきなり本番のGPUクラスタを買うのではなく、PoC→部分本番→本格本番の3フェーズで段階的に進めるのが失敗しにくい設計です。
以下、標準的な導入ステップと、選定判断の参考となる関連製品・検証・ソブリンAI動向を整理します。
標準的な3フェーズ導入ステップ

-
フェーズ1:PoC(3〜6か月)
ミニマム構成のGPU(H200×1〜2枚)で1〜2業務の検証。オープンウェイトLLM+自社ドキュメントによるRAG構築、社内チャットボット、要約バッチ等の限定用途で速度・精度・運用負荷を実測
-
フェーズ2:部分本番(6〜12か月)
成功したPoC業務を本番展開。同時利用者数百名規模のGPUクラスタ(H200×4〜8枚、または初期Blackwell)を構築し、監視・ログ・アクセス制御を含む運用体制を確立
-
フェーズ3:本格本番(12か月〜)
全社展開・複数業務並列稼働。Blackwellクラスタや複数DC展開で数千名規模の同時利用を支える。国産LLM/オープンウェイトLLMの複数モデルを並列運用
この3フェーズを飛ばして最初から本格本番を狙うと、運用人材が追いつかない・モデル選定を誤る・監査要件を満たせないの3点で失敗する確率が高くなります。PoCで自社業務との相性と運用課題を確定させることが必須です。
関連製品・検証・ソブリンAIの動向

以下、2026年時点で参照可能なオンプレミス生成AI周辺の関連製品・検証プロジェクト・ソブリンAI政策動向をまとめました。「特定企業のオンプレ導入事例」ではなく、選定判断の参考となる動向として位置づけます。
-
NTTデータ INTELLILINK Private AI スタートパック(tsuzumi 2 対応検証)
NTTデータ先端技術は2026年4月20日にtsuzumi 2の対応検証を開始しました。日本語処理性能とオンプレ完結型セキュリティを両立させた導入パッケージとして提供されており、機密データを扱う日本企業のオンプレ検討時の選択肢の一つ
-
公共ソブリンAI(デジタル庁「源内」)
政府向けAI基盤として、2026年3月に国産LLM7モデルを選定。5月時点で5社と契約し、以降段階的に試用開始・評価検証・2027年度以降の有償調達に進むロードマップで進行中。ガバメントクラウド上で稼働するソブリンAI事例として、地方自治体・独立行政法人への波及効果が期待される
-
製造業での活用可能性
オンプレミス環境ならインターネット遮断下の工場でも高度なAI機能を活用可能で、既存のERP/MES/SCADAとの直接連携で不良検出・予防保全・作業手順最適化への応用が検討されている領域
これらの動向は、「機密データを外に出せない」「既存基幹システムとの近接統合が必要」「大量利用でクラウド従量課金が経営を圧迫する」という3条件のいずれかに強く該当する業種で先行しやすい傾向にあります。
同じ条件の企業なら、オンプレミス生成AI基盤の検討価値は高いと言えます。
オンプレLLMを含む複数モデルを業務プロセスに定着させるなら
Dell AI FactoryやHPE Private Cloud AIで基盤を組み、tsuzumi 2やLlama 3.3をオンプレに載せても、モデルを動かすだけでは業務価値は生まれません。社内基盤上のLLMを業務プロセスから呼び出せるAgentに変換し、実行ログと権限を1画面で管理する層が必要です。
このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、オンプレLLMとクラウドLLMを含む複数モデルを業務ワークフローに組み込む実行基盤として機能します。
- オンプレ・クラウドをまたぐハイブリッドモデル運用
機密業務はオンプレのtsuzumi 2やLlama、それ以外はクラウドのGPT-5.5やClaude Opus 4.8、と用途ごとにモデル選定を切り替えられます。
- モデル世代交代を吸収する業務組み込み層
Llama 3.3からLlama 5への切り替えでも、業務Agent側の設計は不変。特定モデル依存のワークフロー陥落を回避できます。
- 使い慣れたMicrosoft環境をそのまま活用
Teams・Excel・Outlookなど既存ツールの延長でAIエージェントが動作。新しいツールの学習コストはゼロです。
- データは100%自社テナント内に保持
Azure Managed Applicationsとして自社テナント内で動作が完結。オンプレLLMをAPI経由で呼び出す構成でも業務データの往来を管理レイヤーで制御できます。
AI総合研究所の専任チームが、オンプレ基盤設計からAIエージェント基盤の本番運用まで一貫して伴走支援します。AI Agent Hubのサービスページで、オンプレLLMを業務プロセスに定着させる実行基盤の全体像をご確認ください。
オンプレLLMを業務プロセスに定着
オンプレ・クラウドをまたぐ複数モデル運用
tsuzumi 2やLlamaをオンプレ基盤に載せても、モデルを動かすだけでは業務価値は生まれません。AI Agent Hubのサービスページで、オンプレLLMを含む複数モデルを業務プロセスに繋ぐ実行基盤の全体像をご確認ください。
## まとめ
本記事では、オンプレミス生成AIについて、定義・基盤3レイヤー・主要ベンダー比較・国産LLM(tsuzumi 2/cotomi/PLaMo)・コスト構造とTCO・クラウドとの使い分け・導入手順・関連製品とソブリンAIの動向までを、2026年7月時点の最新情報で解説しました。
2026年時点で押さえておくべきポイントは次の3つです。
- オンプレミス生成AIはハードウェア層+推論ミドル層+モデル層の3レイヤーを自社設計する基盤で、機密度/規模/規制/既存資産の4軸で判定し実務ではハイブリッド型(機密業務のみオンプレ)が最多
- 主要ベンダーはDell・HPE・Nutanix・Cisco・VMware・Red Hatの6社が代表格、国産LLMはデジタル庁「源内」で選定された7モデル(tsuzumi 2・cotomi v3・PLaMo 2.0 Prime等)が主権要件を検討する際の候補
- 中規模で3年TCO 1.5〜3億円、クラウド従量課金との2〜3年比較で損益分岐を判定、規制監査/性能チューニング/運用人材/モデル陳腐化の4点はハード導入前の設計が必須
まずはPoC(3〜6か月)→部分本番(6〜12か月)→本格本番(12か月〜)の3フェーズで段階的に進め、ハード選定と同時に運用設計まで組み上げるのが、本番稼働後の投資回収を左右する第一歩になります。オンプレミス生成AI基盤は「機密データを扱う業種」「利用量が読める大規模用途」「主権要件がある領域」の企業にとって、2026年時点で現実的な選択肢になりました。













