企業向けオンプレミスLLM導入：ハードウェア、モデル、TCO（2026年版）

「なぜ自社導入なのか」から「実際に何を買うべきか」へ

東南アジアと日本の企業がLLMをファイアウォールの内側に移す理由をお読みいただいた方は、その背景にある要因をご存知でしょう。データ主権に関する法規制、顧客データの越境移転を制限する契約条項、そして一部の文書は決して社外に出すべきではないというシンプルな事実です。本記事はその続きとして、CTOやインフラ責任者が発注書にサインする前に実際に答えるべき実務的な問いを扱います。

個人開発者として自分のワークステーションのスペックを検討している場合は、ハードウェア選定ガイドがシングルユーザー環境を詳しく解説しています。本記事はそのガイドが最後に示唆した「別の話」、つまり複数ユーザー・本番グレード・組織単位の導入について扱います。稼働率、同時接続数、既存システムとの統合、コンプライアンスが、モデルの純粋な性能と同じくらい重要になる領域です。

目次

1. 企業向け導入の4つのティア
2. ユースケース別オープンウェイトモデルの選び方
3. サービングスタックの選定
4. TCOの問題：オンプレミスがAPIを上回るのはいつか
5. コンプライアンスの観点
6. 意思決定フレームワーク
7. よくある質問

企業向け導入の4つのティア

個人用ワークステーションと異なり、企業導入では同時ユーザー数、稼働率への期待、そして深夜2時に障害が起きた際のサポート体制まで考慮する必要があります。以下の4つのティアで、これまで支援してきたほぼすべての組織をカバーできます。

ティア1 — パイロット／概念実証

VRAM 24〜48GBのワークステーション級GPU1枚（現行世代のコンシューマー向けまたはエントリー級プロフェッショナルカード）であれば、4bit量子化で約32Bパラメータまでのdenseモデル、またはtotal parameter数はかなり大きいがactive parameter数が小さいmixture-of-expertsモデルを実行できます。少人数のユーザーで実際の業務予算を投じる前にユースケースを検証するためのティアで、構築費用は概ね4,000〜15,000ドルです。

適する用途: RAGパイプラインの検証、小規模チームでのコーディングアシスタントのテスト、ビジネスケースの構築
適さない用途: 少人数を超える同時接続、または顧客向けの用途

ティア2 — 部門規模のサーバー

VRAM 80〜96GBのプロフェッショナル級GPU1枚（現行のワークステーション・データセンター向けカードとして最上位クラス）であれば、実用的な量子化での70Bクラスのdenseモデル、あるいはより大きなmixture-of-expertsモデルを、部門単位の同時接続ユーザーに問題なく提供できます。構築費用の目安は15,000〜30,000ドルで、シャーシ、CPUプラットフォーム、メモリ構成によって変動します。

適する用途: 単一部門の本番ワークロード——法務文書レビュー、社内向けコーディングアシスタント、特定事業部向けの顧客サポートRAGシステムなど

ティア3 — マルチユーザー本番環境

1台のサーバーに複数GPU（一般的に4〜8枚、プロフェッショナルワークステーション級または高帯域インターコネクトを備えたデータセンター級）を搭載することで、数十人規模の同時接続ユーザー、より高精度な大規模モデル、あるいは複数モデルの同時提供が可能になります。予算は概ね60,000ドルから始まり、数十万ドル規模に達することもあります。2026年はメモリ価格が無視できないコスト要因となっており、メーカーがAIアクセラレータ用メモリへ製造能力を振り向けたことでDRAM契約価格が大幅に上昇しています。仕様上「本来これくらいのはず」というサーバー価格が、実際の納品時にはかなり高くなるケースが目立ちます。

適する用途: 単一の主力モデルを全社展開する場合、または共有インフラから複数チームにサービスを提供する場合

ティア4 — フロンティア級MoE

フロンティア級のクローズドモデルの品質に近づく、最大規模のオープンウェイトmixture-of-expertsモデルには、高速インターコネクトを備えた大容量メモリのデータセンター級GPUが複数台、一般的には1システムあたり8枚以上必要です。これは400,000ドル以上の投資であり、非常に高いクエリ量を抱える組織、またはより小規模なモデルでは満たせないフロンティア級のreasoning要件がある組織に限って現実的な選択肢となります。

適する用途: 既存のAPI支出額が大きい大企業の置き換え、またはモデル品質を一切妥協できないユースケース

ティア2・3では、リファービッシュ（再生）ハードウェアの検討も価値があります。企業級GPUやサーバーは初回導入後も何年も安定稼働するため、同じシリコンをより低コストで調達できます。メモリ価格が高騰している現状では、この差はいつも以上に大きな意味を持ちます。

GPU予算が全くないチームにとって重要な選択肢として、行列演算アクセラレーション命令セットを備えた最新のサーバー向けCPUだけで、GPUなしでもmixture-of-expertsモデルを稼働させられることが挙げられます。インタラクティブなチャット用途に十分な速度が出て、軽度の同時接続負荷にもある程度対応できます。スループットではGPUティアに及びませんが、オンプレミスLLM提供をハードウェア調達プロジェクトではなくソフトウェアの意思決定に変えることができ、電力・冷却・予算に制約のあるチームにとって現実的な選択肢となります。

ユースケース別オープンウェイトモデルの選び方

2026年のオープンウェイトモデルのエコシステムは、企業のほとんどのタスクにおいてホスト型フロンティアAPIと本当の意味で競合できる水準に達しています。「オープンウェイトかクローズドか」という選択はもはや本質ではなく、どのオープンウェイトファミリーがハードウェアティア、言語要件、タスクに合うかが問われます。

一般的な企業チャットや文書業務向け: 30B〜70Bクラスの中規模denseモデルおよびmixture-of-expertsモデルは、強力な多言語性能を持ち——タイ語・日本語・中国語の文書業務では特に重要です——ティア1〜2の予算に収まるハードウェアコストで実現できます。

コーディングやエージェント型ワークフロー向け: 現在最も強力なオープンウェイトのコーディングモデルの多くは、total parameter数は大きいものの1回のforward passで実際に使うactive parameter数はかなり小さいmixture-of-experts型に属しており、モデル全体のサイズに反してinferenceが高速です。これらは概ねティア2以上のハードウェアが必要です。

オンプレミスで最大のreasoning品質を求める場合: 最大規模のオープンウェイトmixture-of-expertsモデルはフロンティア級クローズドモデルの品質に迫りますが、本番速度で提供するにはティア3〜4のハードウェアが必要です。ほとんどの企業ユースケースはこのティアを必要としません。必要だと決めつける前に、中規模モデルを実際のワークロードでベンチマークすることをお勧めします。

ライセンスは性能と同じくらい重要です。 商用導入の前には、必ずモデルカードに記載された具体的なライセンスを確認してください。オープンウェイトモデルの中には、名称だけでは分からない利用制限がかかっているものもあります。この5分の確認作業が、後で法務との長い協議を避けることにつながります。

ほとんどの導入に当てはまる実用的な原則は、技術的に動かせる最大のモデルではなく、確実にタスクを解決できる最小のモデルから始めることです。大きなモデルは、実際のユースケースでは表れないことも多い利得のために、ハードウェア、レイテンシ、電力のコストを増大させます。

サービングスタックの選定

実際のスループットにおいて、サービング用ソフトウェアはハードウェアとほぼ同じくらい重要です。企業導入のほとんどをカバーする3つの選択肢を紹介します。

vLLM — 最大限の柔軟性、ライセンス費用ゼロ、新しくリリースされたオープンモデルへの最速のアクセスを求めるチームの標準的な選択肢です。トレードオフとして、統合、堅牢化、サポートを自社チームで担う必要があります。

ベンダー提供の推論コンテナ（NVIDIAのNIMなど）— ベンダーSLA、能動的なセキュリティパッチ適用、検証済みのパフォーマンスプロファイルを備えたすぐに使えるコンテナです。GPUあたりのライセンス費用（一般的に年間約4,500ドルとされますが、企業向けの数量・期間割引が適用されます）と、特定モデルバージョンへの結合度の高さがトレードオフとなります。

SGLang／TensorRT-LLM — 汎用スタックでは満たせない特定のレイテンシやスループット要件があるチームにとって、検討する価値があります。

ティア1のパイロット段階では、OllamaやLM StudioのサーバーモードなどのツールでスタートするのがReasonableな選択です。両者とも、継続的なバッチ処理やREST APIといった本番運用スタイルのデプロイパターンをサポートするようになっており、これは数年前には実現していなかったことです。パイロットの有効性が確認され、同時接続の要件が増大した段階で、vLLMやベンダーコンテナへ移行するのが自然な次のステップです。

TCOの問題：オンプレミスがAPIを上回るのはいつか

これは予算責任者が本当に知りたい問いであり、正直な答えは利用量に大きく左右され、コンプライアンス要件が計算式そのものを変えてしまうというものです。

基本の計算式

API方式の導入では、月次コストは利用量に直接比例してスケールします。

月次API費用 = (1日あたりのリクエスト数 × 平均入力トークン数 × 入力単価/100万トークン
             + 1日あたりのリクエスト数 × 平均出力トークン数 × 出力単価/100万トークン) × 30

2026年のフロンティア級クローズドAPIの価格は、フラッグシップ層で入力100万トークンあたり2〜5ドル、出力100万トークンあたり10〜25ドルという水準が一般的です。予算重視の層やホスト型オープンウェイトモデルでは、負荷が軽いタスクであれば100万トークンあたり1ドルを大きく下回る選択肢もあります。出力トークンは入力トークンより一般的に3〜10倍高価であるため、生成される回答が長いアプリケーションは、回答が短く入力コンテキストが長いアプリケーションよりもモデル選定への感度がはるかに高くなります。

オンプレミス導入では、コスト構造が逆転します。多額の初期ハードウェア投資の後は、クエリ量に応じて同じようにスケールしない、比較的横ばいのランニングコスト（電気代、保守、サポート契約があればその費用）が続きます。

試算例

中規模の導入を想定してみましょう。月間50万リクエスト、リクエストあたり平均入力1,000トークン、出力400トークンとします。フラッグシップ層の一般的なAPI価格では、月額は数万ドル台前半から半ばに達し、年間では速やかに数十万ドル規模に積み上がります。同じワークロードをティア2のオンプレミス導入（ハードウェア投資20,000〜25,000ドル、電気代と一部の技術要員の稼働率を加えたもの）で処理すれば、初年度以内にAPI支出に対する損益分岐点を明確に上回り、以降の毎月がほぼそのまま純粋な節約になります。

オンプレミスLLM導入の経済性に関する独立した分析では、中程度の利用量の組織はクラウドAPIの同等コストに対して概ね6〜12ヶ月で損益分岐点に達するという結果が一般的で、実際のクライアント導入で見られる傾向とも一致しています。この利用量の閾値を下回る場合は、財務的にはAPI利用が依然として有利な選択肢であることが多く、ハードウェア投資を決断する前に、自社のワークロードにおける損益分岐点を実際に計算する価値があります。

この計算式に含まれない要素

純粋なトークン計算を超えて、計算を変える3つの要因があります。

• コンプライアンス要件により「安い」選択肢がそもそも選択肢でなくなることがあります。 APPI、PIPL、等保2.0などの要件によりデータが自社インフラの外に出せない場合、TCOの議論はもはやコストの問題ではなくなり、予算に合ったオンプレミスのティアはどれかという問題になります。オンプレミスに行くかどうかではありません。
• 技術者の時間は無料ではありません。 自社ホスティングには、モデルの更新、監視、インシデント対応を担う担当者が必要です。バックグラウンドのオーバーヘッドとして片付けず、明示的に予算化すべきです。
• 手戻りと品質管理のコストは両方の方式に発生します。 安価なモデルでも、成果物の相当な割合に人間によるレビューが必要な場合、レビュー率の低い高価なモデルよりもタスク完了あたりのコストが結局高くなることがあります。この論理は、APIの層を比較する場合でも、自社ホストモデルとホスト型モデルを比較する場合でも同様に当てはまります。

コンプライアンスの観点

当社の主要市場全体で、規制環境は引き続きデータローカリティの方向に進んでおり、予算と同じくらい導入ティアの判断を左右します。

• タイ（PDPA）: 個人データを含む文書を海外のAPIに送信するあらゆるワークフローに、越境データ移転の制限が直接適用されます。
• 日本（APPI）: 継続中の改正サイクルによりprocessorの監督義務が強化されており、経済安全保障推進法は重要インフラ事業者に対する特有の考慮事項を加えています。J-SOX対応が求められる上場企業にとっては、内部統制の観点からもデータの保管場所の統制が重要になります。
• 中国（等保2.0／PIPL／数据安全法）: 数据不出境——データを国外に出さない——という原則が多くの企業導入を規定しており、幅広いユースケースで事実上オンプレミスまたは国内ホスティングが必須となります。

これらの規制が適用される場合、導入ティアの判断は基本的に予算と規模の問題になり、自社構築か購入かという二択の問題ではなくなります。なぜなら「購入」——海外APIの利用——がそもそもコンプライアンス上の選択肢にならない可能性があるからです。

意思決定フレームワーク

flowchart TD
A["データを自社インフラの外に出せないという規制要件があるか"] -->|はい| B["オンプレミスが必須 予算と同時接続数でティアを選定"]
A -->|いいえ| C["月間クエリ量を見積もる"]
C --> D["高利用量かつ継続的な利用か"]
D -->|はい| E["TCOの損益分岐点を試算 多くの場合1年以内にオンプレミスが有利"]
D -->|いいえ| F["財務的にはAPI利用が有利なことが多い"]
B --> G["同時接続数に応じてティアを選定 ティア1パイロットからティア4フロンティアまで"]
E --> G
G --> H["タスクに応じてモデルを選定 一般チャット コーディング 最大reasoning"]
H --> I["サービングスタックを選定 vLLM ベンダーコンテナ 軽量ツール"]

よくある質問

そもそもローカルLLMの実行にGPUは必要ですか。
必ずしも必要ではありません。行列演算アクセラレーション命令セットを備えた最新のサーバー向けCPUは、GPUなしでmixture-of-expertsモデルを、インタラクティブなチャットに使える速度で提供できます。既存のCPUフリートを持つチームや、電力・冷却に制約のあるチームには適した選択です。ただし同時接続数が増えると、スループットの面ではGPUティアの方が上回ります。

量子化は実際どの程度品質に影響しますか。
ほとんどの企業タスクでは、4bit量子化（一般にQ4と呼ばれます）が実用的な標準であり、品質の低下はチャット、要約、RAGにおいて問題にならない程度に小さいものです。より高精度（8bit以上）は、細かな誤差が積み重なるコーディングや複雑なreasoningタスクにおいて、追加のメモリコストに見合う価値があります。

オンプレミスとAPI利用を併用できますか。
はい、当社の多くのクライアントがそうしています。通常のクエリは自社ホストのモデルにルーティングし、品質の差が特に重要になる本当に難しいクエリだけをクローズド型APIに送る形です。このハイブリッドアプローチにより、必要な部分での品質を維持しながらコストを大きく削減できます。ただし、規制対象データを含むものはすべて、オンプレミス経路のみを通す必要があります。

ティア2の導入は、意思決定から本番稼働までどのくらいかかりますか。
ユースケースが明確な部門規模の導入であれば、ハードウェア発注から本番稼働まで4〜8週間が現実的な目安です。これはユースケースと統合ポイントがすでに明確であることを前提としています。それより長くかかる場合は、技術的な構築そのものではなく、要件の不明確さが原因であることがほとんどです。

自社に必要なティアを最も早く把握する方法は何ですか。
Enterprise Local LLM Readiness Assessmentをお試しください。25の質問に自己採点形式で答えることで、データの機微性、利用量、コンプライアンス要件を推奨される開始ティアにマッピングします。

次のステップ

ハードウェアとモデルの選定は、正しいフレームワークがあれば解決できる問題です。より難しいのは、自社固有のコンプライアンス義務、既存システム、チームのキャパシティを適切なティアに落とし込むことです。予算を投じる前にセカンドオピニオンが必要な場合は、技術パートナー評価ガイドが導入パートナー選定で確認すべきポイントをまとめています。もちろん、貴社の具体的な要件について直接お話しすることも歓迎します。

お問い合わせ: hello@simplico.net