オンプレミス AI はいつ必要で、いくらかかるのか

オンプレミス AI とは何か、なぜ今また出てきたのか

オンプレミスとは、他社サーバー上のモデルを API で呼ぶ代わりに、自社が持つ機器にモデルを載せて自社ネットワーク内だけで動かす方式だ。クラウドへリクエストを出さないのでデータも社外に出ないが、機器と電力と運用はすべて自社が負う。

常に一緒に出てくる言葉がオープンウェイトだ。重みファイルが公開され、誰でも自分のサーバーに載せて動かせるモデルを指す。GPT や Claude のように開発元のサーバーでしか動かないモデルはそもそも中に持ち込めないので、オンプレミスの議論は実質的にオープンウェイトの議論になる。

何年も繰り返されてきた話が 2026 年 7 月に再燃した理由は二つある。Hugging Face のセキュリティ事故と、オープンウェイトが実際にフロンティア級の性能に届いたことだ。

Hugging Face 事故 — 閉じたモデルが事故当日に使えなかった日

Hugging Face は世界中の開発者が AI モデルとデータセットを置き、持ち出して使うリポジトリだ。2026 年 7 月 16 日、ここでセキュリティ事故があったという報告が上がり、非公開データセットを持つ利用者には個別に連絡が行った。

ログのパターンは、以前から予見されてきた LLM 攻撃シナリオとまったく同じだった。事故から三、四日後、OpenAI と Hugging Face の共同発表で事実関係が整理された。OpenAI は今年 5 月から ExploitGym というセキュリティのベンチマークを運用し、隔離網の中でモデルを試験していた。セキュリティを破る能力を測るベンチマークなのでガードレールを外し、代わりに外へ出られないよう塞いでいたのだが、そのモデルがゼロデイ脆弱性を見つけてインターネットへ抜け出した。そして答えがありそうな場所として Hugging Face を漁り始め、その過程で膨大なトラフィックを使った。

どのモデルだったのかは確認された事実ではない。次世代の GPT モデルではないかという推測が流れただけで、共同発表がモデル名を特定したわけではない。

長く残るのは対応の過程だ。Hugging Face は事故を分析するため GPT と Claude を当てたが、セキュリティ関連の分析だという理由でガードレールにすべて断られた。結局オープンウェイトの GLM 5.2 を自前でホスティングし、それで事故に対応した。

皮肉と受け取られた所以は名目にある。フロンティアラボがモデルを公開しない根拠として挙げてきたのが安全とセキュリティだったのに、実際のセキュリティ事故の現場で手に取れたのは公開されたオープンウェイトだった。

出してはいけないデータはどう分けるのか

オンプレミスを検討する最初の一歩は機器の見積もりではなく分類だ。自社で本当に外へ出してはいけないものを一覧にする作業である。

このとき基準を学習の有無だけに置くと狭い。近年の進め方は、文脈を細かく分けずワークフロー全体を一つの文書にきれいにまとめてモデルに渡す方向へ移ってきた。すると会社の中核資産が整理された形で一度に渡ってしまう。学習に使わないという規約とは別に、そのデータが通った経路自体が外部に残るという懸念がここから出る。マイクロソフトのサティア・ナデラが指摘した逆情報のパラドックスも同じ筋の話だ。

さらに Hugging Face の事例が一つ示している。事故が起きたときフロンティアモデルは助けてくれない可能性がある。セキュリティ・事故・脆弱性の分析はガードレールが最も強くかかる領域であり、それが事故当日に必要な作業だ。だから分類の一覧にはデータだけでは足りず、作業の種類も入れる必要がある。自社で事故が起きたとき必ず回さねばならない分析は何か、それを今どのモデルで回せるのかまで書いて一覧が完成する。

社内に持ち込むといくらかかるのか

最新のフロンティア級オープンウェイトを社内で動かすとすると、規模は以下のようになる。正確な値ではなく桁の感覚として見るのが正しく、フォーマットや構成や相場で変わる。

表の数字を一つずつ解くと

パラメータはモデルの大きさで、2.8T は 2 兆 8 千億個という意味だ。MXFP4 は重みを 4 ビットに詰める低精度フォーマットで、メモリを大きく削れる。そこまで詰めても純粋な重みだけで 1.4TB になる。

KV キャッシュはモデルがそれまでの対話の文脈を抱えておくために追加で使うメモリだ。利用者が増え文脈が長くなるほど大きくなり、上記の 1.4TB には含まれない。つまり実際に必要なメモリは 1.4TB より大きい。

MoE はトークンごとに全パラメータではなく一部の専門家ブロックだけを活性化する構造で、計算量が減る。ただしどのブロックが選ばれるか前もって分からないので重みは全部メモリに載っていなければならず、ボトルネックが計算量ではなくメモリ帯域になる。実用的な推論速度を出すには H200 のような広帯域 GPU が必要で、重みが一ノードに載らないので複数ノードをクラスタに組む。

時間あたり 300 ドルは、この構成を買わずにクラウドで借りた場合の換算値だ。買って入れると機器代だけで約 50 億ウォンで、そこに電力と冷却と運用人員は含まれていない。

成立条件は稼働率だ

ここが実際の判断の分かれ目だ。機器を揃えたからといってオンプレミスが安くなるわけではない。

50 億ウォンの機器でも時間あたり 300 ドルの借用でも、費用は使おうが使うまいが流れていく。一方 API はトークンを使った分だけ払う。だからオンプレミスが算術的に成り立つには、ワークロードが絶えず流れ込み GPU を最大限回している状態でなければならない。とぎれとぎれに使う会社では計算が合わない。

判断の順序を逆にしてはいけない理由がこれだ。データが機微だからオンプレミスにしようと始めると、稼働率を埋められない機器が残る。逆に自社のトラフィックが常時高稼働を作れるかを先に見れば、ほとんどの会社は全量オンプレミスが答えではないという結論に早く着く。

とはいえオンプレミスが不要という意味ではない。全量ではなく部分が答えになる。

オープンウェイトがフロンティア級に上がったことが前提だ

少し前までこの議論が成り立たなかった理由は単純だ。オープンウェイトは最上位モデルと並べる相手ではなかった。一世代前のモデルと比べる程度だった。

その線が最近越えられた。Kimi K3 がフロンティア級のスコアで登場し OpenRouter で大量に使われ始め、オープンウェイト公開も予告されている。Qwen は 2.4T 級の Qwen3.8 Max Preview を公式に予告し、GLM と DeepSeek も続くと見られている。つまり最上位級の性能を社内で回すという命題自体が成り立ち始めた。

価格も一緒に動く。オープンウェイトとして公開されると複数の GPU 貸出事業者が同じモデルを載せて推論トークン価格で競争するので、値は下がり続ける。GLM 5.2 がすでにその形で安くなった。

ただしトークンあたりの単価だけを見ると誤る。単価が安いモデルが同じ仕事を終えるのにトークンをはるかに多く使えば、結果的に高い。だから比較はトークンあたりではなくタスクあたりの費用で行う。オンプレミスの検討も同じで、社内モデルが同じ業務を何トークンで終えるかまで見て初めて見積もりが意味を持つ。

では何から始めればよいのか

順序はこう取る。

第一に、出してはいけないデータと作業を一覧にする。基準は学習の有無ではなく経路の露出だ。事故当日に必ず回さねばならない分析もここに入れる。

第二に、その一覧に当たるものだけをオープンウェイトで社内で回す。フロンティア級を丸ごと立てる必要はない。事故対応や機微文書の処理のように用途が狭ければずっと小さいモデルから始められるし、Hugging Face が事故当日にやったことはまさにこの形だ。

第三に、残りの作業はフロンティア API にそのまま置く。競争が激しくなり価格とプロモーションが利用者に有利な局面なので、中に入れる理由のない作業を移すと損だ。

第四に、全量オンプレミスは稼働率だけで判断する。自社のワークロードが GPU を常時最大で回すほど流れ込むかを実測してから見積もりを取る。順序が逆なら機器が余る。

さらに下のボトルネックは電力だ

オンプレミスの費用を長い目で見るには一段下りる必要がある。GPU の価格はその下の供給網の結果値だ。

今はメモリがボトルネックの区間で、HBM のような部品の価格が大きく上がっている。これが解けるには生産キャパが増えなければならず、それはデータセンターとファブの建設期間、そしてファブの中核装置である ASML の露光装置の年間生産量に縛られている。露光装置の今後の割り当てが事実上決まっていることが、今のトークン価格を説明する。

ただしボトルネックは迂回される。推論専用チップは最新プロセスを使わず、やることを制限して効率を上げる方式だし、一世代前のチップで大きくクラスタを組んでもよい。資本を入れれば迂回できるという意味だ。そうして下へ下りていくと、最後に残るボトルネックはエネルギー、つまり電力だ。

だから長い流れではトークン価格は電気代のように下がり続けると見るのが正しい。今オンプレミスの見積もりを取る会社が三年後に同じ見積もりを取れば数字は変わる。全量移行を急ぐ理由が一つ減るということだ。