要点（100字）：ローカルLLMはガバナンス・コスト・レイテンシの3軸で選ぶ。2026年はLlama 4 / Qwen 3 / DeepSeek V3が主軸。クラウドAPIとの併用前提でのハイブリッド設計が定石で、完全自前運用は限定的なケースのみ。
この記事の対象読者
- データ持ち出し制約のある企業（金融 / 医療 / 公共 / 防衛）のAIプラットフォームエンジニア
- 月数千万トークン超の運用でクラウドAPIコストが負担になっている事業責任者
- サブ秒レイテンシ要求のあるユースケース（コールセンター / 検索 / リアルタイム翻訳）を持つ事業部
- AX推進でローカルLLMの必要性を経営層に説明したいAX推進責任者
ローカルLLMが必要な3ケース
ローカルLLMはクラウドAPIより構築・運用が重い。やみくもにオンプレ化するのは非効率で、以下の3ケースに該当する場合のみ検討する。
ケース1：データ持ち出し禁止
- 金融機関の顧客取引データ
- 医療機関の患者カルテ
- 防衛 / 警察 / 公共インフラの機微情報
- 法務 / 知財関連の機密文書
クラウドAPIでもEnterprise契約（データ学習除外 / ログ保存制御）でカバーできるケースが増えたが、規制上 "物理的にデータを国外に出さない / 自社管理下にない環境で処理しない" 要件がある場合はローカルが必須。
ケース2：月数千万トークン超の長期運用
クラウドAPIは従量制で、月数千万〜数億トークンを継続的に消費する業務（社内ナレッジ検索 / 大量文書要約 / 24hチャットボット）では、3〜5年TCOでローカルLLMがペイすることがある。
損益分岐の目安：月1億トークン × 12ヶ月 = 年12億トークン消費の業務で、$200K超のクラウド支出 → 自前GPUクラスタ（H100×4〜8台）が選択肢になり始める。
ケース3：サブ秒レイテンシ要求
- コールセンターの音声応答（応答200ms以内）
- リアルタイム翻訳 / 通訳支援（300ms以内）
- 検索エンジン補完 / オートコンプリート（100ms以内）
クラウドAPIは通信遅延 + キュー待ち + 生成時間で1〜3秒かかる。サブ秒要求の業務にはローカルLLMが必須。
主要オープンウェイトモデル比較（2026年6月時点）
| モデル | 提供元 | パラメータ | コンテキスト長 | ライセンス | 商用利用 | 日本語性能 | GPU要件（FP8） |
|---|---|---|---|---|---|---|---|
| Llama 4 Maverick | Meta | 400B (17B active, MoE) | 1M | Llama 4 Community License | △（条件付） | ◯ | H200×4 |
| Llama 4 Scout | Meta | 109B (17B active, MoE) | 10M | Llama 4 Community License | △（条件付） | ◯ | H100×2〜H200×2 |
| Qwen 3-235B-A22B | Alibaba | 235B (22B active, MoE) | 256K | Apache 2.0 | ◎（フリー） | ◎（中華圏含む多言語） | H200×4 |
| Qwen 3-32B | Alibaba | 32B（Dense） | 128K | Apache 2.0 | ◎ | ◎ | H100×1 |
| DeepSeek V3.1 | DeepSeek | 671B (37B active, MoE) | 128K | MIT | ◎ | ◯ | H200×8 |
| Mistral Large 2 | Mistral AI | 123B（Dense） | 128K | MRL + Commercial | △（商用要契約） | ◯ | H100×2〜H200×2 |
| Codestral 25.01 | Mistral AI | 22B（Dense / Code特化） | 256K | MRL + Commercial | △ | △ | H100×1 |
| Gemma 3 27B | 27B（Dense） | 128K | Gemma Terms | △（派生物制約） | △〜◯ | RTX 6000 Ada / H100×1 | |
| Phi 4 | Microsoft | 14B（Dense） | 16K | MIT | ◎ | △ | RTX 4090 / 6000 Ada |
モデル選定ポイント
Llama 4系：エコシステムが最大。NVIDIA / Together / Fireworksなど推論プロバイダのサポートが厚い。商用利用は月間アクティブユーザ7億超は別契約が必要（Metaの追加条件）。
Qwen 3系：Apache 2.0で商用フリー。中国語 / 日本語など多言語性能が高く、日系企業での採用が増加中。32B DenseはH100×1で動かせる扱いやすさ。
DeepSeek V3.1：MITライセンスで商用フリー。671BのMoEはGPU要件が重いが、推論コストはActiveパラメータ（37B）相当。コード生成性能はGPT-4o級と評価される。
Mistral Large 2 / Codestral：商用利用にMistralとの契約が必要。価格次第だが、欧州データセンター運用を志向する企業（GDPR厳密対応）には魅力。
Gemma 3：Googleの研究系。27B DenseはRTX 6000 Ada（48GB）でも量子化すれば動く。日本語はLlama 4 / Qwen 3にやや劣る。
Phi 4：14Bと小型ながら推論能力が高い。エッジ / オンデバイス用途向け。
推論基盤の選択肢
vLLM（プロダクション運用の標準）
- NVIDIA GPUでのバッチ推論に最適化（PagedAttention）
- 高スループット / 低レイテンシ
- OpenAI互換APIでラップ可能（vLLMが
/v1/chat/completionsを提供）
適用ケース：エンタープライズ本番運用 / トラフィック100req/s以上 / 複数モデル並列ホスト
llama.cpp（軽量 / オンプレ / CPU可）
- C++ 実装で量子化（GGUF）対応
- CPUでも動作（速度は出ないがPoC可能）
- Mac / Windowsノートでも動かせる
適用ケース：オンプレ小規模 / エッジ / 開発者デスクトップ
TGI（Text Generation Inference / HuggingFace公式）
- HuggingFaceエコシステムとの統合が厚い
- 推論サーバーとして安定
- vLLMより少し性能劣るが運用しやすい
適用ケース：HuggingFace既存ユーザー / モデル切り替え頻度が高い検証環境
Ollama（ローカル開発 / プロトタイピング）
- 1コマンドでモデルダウンロード → 推論
- macOS / Linux / Windows対応
- 量子化済みモデルが豊富
適用ケース：PoC / 開発者個人環境 / デモ
SGLang（高速化志向）
- vLLMの改良版的位置付け
- 構造化出力 / JSONモードに強い
- 学習コストはやや高い
適用ケース：構造化出力ヘビーな業務 / vLLMで性能不足のケース
ハードウェアとコスト試算
GPU別の対応モデル（FP8推論）
| GPU | VRAM | 対応モデル例 | 価格（参考） |
|---|---|---|---|
| H200 | 141GB | Llama 4 Maverick / Qwen 3-235B / DeepSeek V3 | $30K〜 |
| H100 80GB | 80GB | Qwen 3-32B / Mistral Large 2 / Llama 4 Scout(2台) | $25K〜 |
| RTX 6000 Ada | 48GB | Gemma 3 27B / Qwen 3-14B / 量子化70B | $7K〜 |
| RTX 4090 | 24GB | Phi 4 / Gemma 3 9B / 量子化13B | $1.6K〜 |
| B200 / B100 | 192GB | 大規模MoE並列 | $40K〜（出荷次第） |
自社オンプレ vs クラウドGPU（参考試算）
H100×4台構成の場合：
- 自社オンプレ：初期 $120K（GPU）+ $30K（サーバ / 冷却 / 電源） = $150K + 月額電気代 $1〜2K
- クラウド（AWS p5.48xlarge / GCP a3-megagpu）：時間単価 $30〜50 × 730h = 月 $22K〜36K
- 専用クラウドGPU（Together / Fireworks / Lambda）：時間単価 $10〜20 × 730h = 月 $7K〜15K
3年運用でのTCO：
- 自社オンプレ：$150K + $36K（電気） + 運用人件費 = 約 $250〜350K
- クラウド：$800K〜$1.3M
- 専用クラウド：$250〜540K
目安：24h 365日フル稼働なら自社オンプレが安い。日中のみ稼働ならクラウドが安い。
国内データセンター事業者の選択肢
- さくらインターネット（GPUクラウド「高火力」）
- NTT Data（プライベートクラウドGPU）
- 富士通（FUJITSU Hybrid IT Service）
- 国内H100 / H200リソースは需給逼迫しており、6〜12ヶ月リードタイムも珍しくない
国内DC要件（特に金融 / 医療）の場合は早期に契約を進める必要がある。
クラウドAPIとのハイブリッド設計
完全ローカル化を狙わず、ハイブリッドが定石。
設計原則
| 要件 | ルーティング先 |
|---|---|
| 機微情報を含む / データ持ち出し不可 | ローカルLLM |
| 高難度の推論 / 最新モデル必要 | クラウドAPI（Claude Opus / GPT-5 / Gemini Ultra） |
| 高頻度・軽量タスク | ローカルLLM |
| 業務時間外バッチ処理 | クラウドAPIバッチ（50%割引） |
| サブ秒応答要求 | ローカルLLM（特にCPU + 量子化） |
ルーティング実装
3パターン：
- ルールベース：データ分類タグでルーティング（簡単 / 柔軟性低）
- 小型分類モデル：FastText / DistilBERT等で機微判定 → ローカル / クラウド振り分け
- ゲートウェイ製品：LiteLLM / OpenRouter / Portkeyなどのルーティング製品を活用
最初はルールベースで開始、運用ログが溜まったら分類モデル / ゲートウェイ製品に進化。
データガバナンス観点
監査ログ
ローカルLLMは 入力 / 出力ログを自前で持つ。これがクラウドAPI（特にEnterprise契約のないデフォルトAPI）に対する大きな優位。
- 月次の入出力サンプリングレビュー
- 規制対応の証跡保管（7年など業界要件次第）
- 内部監査 / 外部監査での提示
モデル更新ポリシー
オープンウェイトモデルは数ヶ月単位でメジャー更新が出る。
- セキュリティパッチ：適用SLAを30日以内などで定義
- 性能改善：四半期評価で更新判定（A/Bテスト後の段階的展開）
- 切り替え検証：既存業務での品質劣化を検査するベンチマークを社内に持つ
セキュリティパッチ
- 推論基盤（vLLM / TGI等）のCVE対応：月次パッチ
- OS / コンテナ：通常の運用基盤と同等
- モデル本体の脆弱性（プロンプトインジェクション等）：社内Red Team / 監査
FAQ
Q1. 日本語性能が一番高いオープンウェイトは？
2026年6月時点では Qwen 3系（Alibaba）が日本語ベンチマーク（JGLUE / JCommonsenseQA / 日本語MT-Bench）で総合トップ。続いてLlama 4 / DeepSeek V3。
ただしベンチマークはタスク次第で逆転するため、自社業務での評価セット（500〜1000サンプル）で必ず実測する。
Q2. ライセンスで商用利用に注意すべきモデルは？
- Llama 4：月間アクティブユーザ7億超はMetaとの別契約必要。エンタープライズの内部利用は問題ないことが多い
- Mistral Large 2：MRL（Mistral Research License）は研究用途のみ。商用利用にはMistralとのCommercial License契約必須
- Gemma 3：Gemma Terms（独自）。商用可だが、生成物の派生物配布制約がある
商用フリーで安全：Qwen 3（Apache 2.0）/ DeepSeek V3（MIT）/ Phi 4（MIT）
Q3. 推論基盤はvLLM一択か？
エンタープライズ本番はvLLMが現時点でデファクトだが、用途次第：
- 本番運用 / 高スループット：vLLM
- オンプレ / 軽量 / CPU：llama.cpp
- HuggingFaceエコシステム：TGI
- PoC / 開発：Ollama
- 構造化出力多用 / 最新最適化：SGLang
複数併用も普通。検証はOllama、本番はvLLM、エッジはllama.cppというケースが多い。
Q4. 何GPU必要か？
業務要件から逆算する：
- 小規模PoC / 個人 / 13B量子化：RTX 4090 1枚（$1.6K）
- 中規模本番 / 32B Dense：H100×1（$25K〜）
- 大規模本番 / 100B級：H100×2〜H200×2（$50K〜）
- MoE大規模 / 235B〜：H200×4〜8（$120K〜）
冷却 / 電源 / ネットワーク機器を含めると上記の1.5倍が初期コスト目安。
Q5. セキュリティパッチはどう運用する？
3階層運用：
- OS / コンテナ：通常の運用基盤と同等（月次パッチ / 緊急パッチ）
- 推論基盤（vLLM / TGI）：GitHub Watchでリリース追跡 / 月次パッチ
- モデル本体：四半期での更新評価 / 重大バグはホットフィックス
国内DC環境では適用に承認プロセスが必要。SLAを明確化しておく。
Q6. クラウドAPIより本当に安くなるか？
3〜5年TCOで評価する。月1億トークン以上を24h 365日で消費する業務でないと、自社オンプレが安くなることは少ない。
それ未満なら 専用クラウドGPU（Together / Fireworks / Lambda Labs）またはMarketplace経由のホスティングモデル がコストパフォーマンスで勝る。
Q7. ハイブリッド設計でクラウド側はどう選ぶ？
3要素で評価：
- 最新モデル性能：Claude Opus 4.x / GPT-5 / Gemini Ultra
- Enterprise契約：データ学習除外 / ログ保存制御 / SLA
- 国内DC提供：AWS Tokyo / GCP Tokyo / Azure Japan East等
機微情報はローカル、高難度推論はクラウドという役割分担が定石。両側でモデルを揃える必要はなく、強み別に使い分ける。
FDXのローカルLLM導入支援
FDX株式会社は、Forward Deployed Engineer（FDE）+ プラットフォームエンジニアリング によって、ローカルLLM導入を支援する。
- 要件診断（ガバナンス / コスト / レイテンシの3軸評価）
- モデル選定 + ライセンス精査
- 推論基盤構築（vLLM / TGI / llama.cpp）
- クラウドAPIとのハイブリッドアーキテクチャ設計
- 監査ログ / セキュリティ / パッチ運用の整備
- 6〜12ヶ月の運用伴走 → 内製チームへ引き継ぎ
「クラウドAPIでコストが想定5倍」「機微データでクラウド使えない」という典型課題に対して、ハイブリッド設計で現実解を提示する。
関連記事
- LLMトークン節約5パターン｜本番運用でコストを70%削るハーネス設計
- ループエンジニアリング入門｜自律エージェントを"動かし続ける"ハーネス設計
- AIエージェント完全ガイド｜2026年版
- LangGraph実装入門｜エンタープライズのAIエージェント構築フレームワーク
- AI内製化の進め方｜外注依存から脱却する5ステップ
- DS+FDEハイブリッドチーム設計
まとめ
- ローカルLLMは、データ持ち出し禁止・月数千万トークン超の長期運用・サブ秒レイテンシ要求の3ケースで検討する
- 2026年の主軸はLlama 4/Qwen 3/DeepSeek V3。商用フリーで安全なのはQwen 3（Apache 2.0）とDeepSeek V3・Phi 4（MIT）
- 推論基盤は本番はvLLM、軽量・オンプレはllama.cpp、検証はOllamaと用途で使い分ける
- コストは3〜5年TCOで評価する。24h 365日フル稼働でなければ専用クラウドGPUが優位なことが多い
- 完全ローカル化ではなく、機微情報はローカル・高難度推論はクラウドAPIのハイブリッド設計が定石
- 監査ログ・モデル更新ポリシー・セキュリティパッチまで含めた運用設計とセットで導入を判断する
出典・参考文献
- Meta AI「Llama 4 Model Card / Community License」
- Alibaba Cloud「Qwen 3 Technical Report」
- DeepSeek AI「DeepSeek-V3.1 Technical Report」
- Mistral AI「Mistral Large 2 / Codestral 25.01公式」
- Google「Gemma 3 Technical Paper」
- Microsoft Research「Phi 4 Technical Report」
- vLLM Documentation「PagedAttention / OpenAI API Compat」
- HuggingFace「TGI Documentation」
- llama.cpp GitHub README
- 経済産業省「生成AIガバナンス白書2026」
- 国立情報学研究所「日本語LLM評価ベンチマーク2026」