ローカルLLM比較2026｜オープンウェイトモデルの​選び方

要点（100字）：ローカルLLMは​ガバナンス・コスト・レイテンシの​3軸で​選ぶ。​2026年8月時点で​モデルは​1T超の​フラッグシップと​単一GPUで​動く​30B級に​二極化した。​企業が​自前で​回せるのは​後者で、​クラウドAPI併用の​ハイブリッド設計が​定石。

本記事は定期的に更新しています（最終更新：2026年8月26日）。

この​​記事の​​対象読者

• データ持ち出し制約の​ある​企業​（金融 / 医療 / 公共 / 防衛）の​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年8月時点）

パラメータ数・コンテキスト長・ライセンスは、​各モデルの​公式モデルカードで​確認した​値を​記載する。掲載順は規模順で、優劣ではない。

2026年8月の​​更新点​（6月版からの​​差分）

1. ライセンスの潮目が変わった。「米国系は​制限的、​中国系は​寛容」と​いう​2026年前半までの​通念は、​もう​成り​立たない。​Metaは​Muse Glimmer 30Bを​Apache 2.0で​公開し、​Llama Community Licenseの​独自条項から​離れた。​Googleの​Gemma 4も​Apache 2.0で、​Gemma独自規約の​制約は​外れている。​逆に​Alibabaは​フラッグシップの​Qwen3.8-2.4T-A95Bを​独自ライセンス​（qwen3.8-max）で​出しており、​同社の​27Bが​Apache 2.0であるのと​対照的だ。ベンダー名でライセンスを推測せず、モデル単位でライセンス欄を読むこと。

2. 規模が二極化し、中間が消えた。 1T超の​フラッグシップ​（Kimi K3 2.8T、​Qwen3.8 2.4T、​DeepSeek-V4-Pro 1.7T）と、​単一GPUに​載る​27〜33Bクラスに​割れている。​2026年前半に​主戦場だった​70B〜235Bの​中間帯は、​選択肢が​薄い。企業が自社設備で現実的に回せるのは後者だけである​（次項の​VRAM試算を​参照）。

3. コンテキスト長は100万トークン級が上位の標準になった。 ただし長文脈は​KVキャッシュが​VRAMを​食う​ため、​「1M対応」と​「1Mを​業務で​常用できる」は​別物である。

4. マルチモーダルが上位モデルの既定になった。 Qwen3.8-27B、​Gemma 4 31B、​Muse Glimmer 30B、​Kimi K3は​いずれも​画像入力に​対応する。​テキスト専用前提で​設計すると、​後から​差し替えが​必要に​なる。

5. 日本語特化モデルはライセンス条件を必ず読む。 国立情報学研究所の​llm-jp-4-33b-thinkingは​Apache 2.0で​制約が​無い。​一方、​Preferred Networksの​PLaMo 3系は​PLaMo community licenseで、商用利用にはPFNへの事前登録が必要であり、かつ利用者または利用者の関係会社の年商が10億円を超える場合は別途PFNから商用ライセンスを取得する必要がある。​エンタープライズ用途では、​この​年商要件で​ほぼ確実に​別契約側に​該当する。​検証で​使えたからと​いって本番で​同じ​条件では​使えない​典型例である。

本記事のライセンス記述は2026年8月26日時点で公開条文を確認したものである。 条文は​改定される​ため、​採用判断では​必ずライセンス原文の​最新版を​確認し、​自社法務の​レビューを​通す​こと。​本記事の​記載を​法的助言と​して​用いない​こと。

モデル選定ポイント

拡大 ⤢

※上図は​2026年6月時点の​主要モデルを​商用利用​容易さ×​日本語性能で​プロットした​もの。​ライセンス状況は​上表の​8月時点の​値が​最新である。

規模から入らない。 2.8Tの​モデルは、​FP8でも​重みだけで​約2.8TBの​VRAMを​要する。​H200​（141GB）​換算で​20枚超であり、​これは​自社オンプレの​話ではなく​データセンター事業の​話に​なる。フラッグシップ級は「APIで使う対象」であって「自社で建てる対象」ではないと​割り切るのが​実務的だ。

単一ノードで完結する境界は概ね120B級。 Mistral-Small-4-119B​（アクティブ6.5B）や​gpt-oss-120b​（アクティブ5.1B）は、​総パラメータこそ​100B超だが​MoEで​アクティブが​小さく、​推論コストは​実効的に​軽い。​ただしMoEは全エキスパートの重みをVRAMに載せる必要があるため、​必要VRAMは​アクティブ側ではなく​総パラメータ側で​見積もる。​ここを​取り違えると​調達を​誤る。

ただし配布形式が低精度なら要件は下がる。 gpt-oss-120bは​MoEの​重みが​MXFP4で​後訓練されており、​公式モデルカードは​80GB GPU 1枚​（H100や​MI300X）で​動作すると​明記している。総パラメータからの機械的な計算と、実際の配布形式は別物なので、​必ず​モデルカードを​確認する​こと。

業務で最も現実的なのは27〜33Bクラス。 Qwen3.8-27B / Gemma 4 31B / Muse Glimmer 30B / llm-jp-4-33b は​いずれも​Apache 2.0で、​FP8なら​48GB級の​GPU 1枚に​収まる。​多くの​社内ユースケース​（要約・分類・抽出・​一次回答）は​この帯で​足りる。

MITとApache 2.0は実務上ほぼ同等に扱える。 DeepSeek系と​GLM-5.2は​MIT、​上記30B級は​Apache 2.0で、​いずれも​商用利用・改変・再配布に​制限が​無い。​独自ライセンス​（Kimi-K3 License、​qwen3.8-max、​PLaMo community license）​のみ、​法務レビューを​通す。

日本語性能は公表ベンチマークで決めない。 モデルの​入れ替わりが​四半期単位で​起きており、​2026年8月時点で​「日本語なら​これ」と​言い​切れる​定説は​無い。自社業務の評価セット（500〜1,000サンプル）を作り、候補3つを実測して決めること。​この​評価セットは​一度​作れば​次の​モデル更新でも​再利用でき、​モデル選定を​継続的な​作業に​変えられる。

推論基盤の​​選択肢

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推論）

必要VRAMは総パラメータ数×約1バイト（FP8）が重みの下限で、​これに​KVキャッシュ・アクティベーション・推論基盤の​オーバーヘッドが​加わる。​長文脈を​常用する​場合は​KVキャッシュが​支配的に​なる​ため、​下表の​「対応モデル例」は​重み基準の​概算である。

1T超のフラッグシップは自社オンプレの検討対象から外してよい。 H200換算で​12〜20枚以上が​必要で、​電源・​冷却・ノード間接続の​要件が​データセンター設計の​領域に​入る。​これらは​APIまたは​マネージド推論で​使い、​自社に​建てるのは​30B〜120B級、と​いう​切り​分けが​2026年8月時点の​現実解である。

自社オンプレ 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との​​ハイブリッド設計

拡大 ⤢

完全ローカル化を​狙わず、ハイブリッドが定石。

設計原則

ルーティング実装

3パターン：

1. ルールベース：データ分類タグで​ルーティング​（簡単 / ​柔軟性低）
2. 小型分類モデル：FastText / DistilBERT等で​機微判定 → ローカル / クラウド振り分け
3. ゲートウェイ製品：LiteLLM / OpenRouter / Portkeyなどの​ルーティング製品を​活用

最初は​ルールベースで​開始、​運用ログが​溜まったら​分類モデル / ゲートウェイ製品に​進化。

データガバナンス観点

監査ログ

ローカルLLMは​ 入力 / 出力ログを自前で持つ。​これが​クラウドAPI​（特に​Enterprise契約の​ない​デフォルトAPI）に​対する​大きな​優位。

• 月次の​入出力サンプリングレビュー
• 規制対応の​証跡保管​（7年など​業界要件次第）
• 内部​監査 / 外部​監査での​提示

モデル更新ポリシー

オープンウェイトモデルは​数ヶ月単位で​メジャー更新が​出る。

• セキュリティパッチ：適用SLAを​30日以内などで​定義
• 性能改善：四半期評価で​更新判定​（A/Bテスト後の​段階的展開）
• 切り​替え​検証：既存業務での​品質劣化を​検査する​ベンチマークを​社内に​持つ

セキュリティパッチ

• 推論基盤​（vLLM / TGI等）の​CVE対応：月次パッチ
• OS / コンテナ：通常の​運用基盤と​同等
• モデル本体の​脆弱性​（プロンプトインジェクション等）​：社内Red Team / 監査

FAQ

Q1. 日​本語性能が​​一番​​高い​​オープンウェイトは？

2026年8月時点で「これ」と言い切れる定説は無い。 モデルの​入れ替わりが​四半期単位で​起きており、​公開ベンチマークの​順位は​次の​更新で​入れ替わる​前提で​見るべきである。

日本語を​主目的に​開発された​選択肢と​しては、​国立情報学研究所の​ llm-jp-4-33b-thinking（Apache 2.0、​33B、​コンテキスト65,536）と、​Preferred Networksの​ PLaMo 3系（31B。​ただし商用利用は​事前登録が​必要で、​年商10億円超は​別途商用ライセンスが​必要）が​ある。​汎用モデル側では​ Qwen3.8-27B / Gemma 4 31B が​多言語で​安定している。

決め方は変わらない。自社業務の評価セット（500〜1,000サンプル）を作り、候補3つを実測する。 評価セットは​一度​作れば​次の​モデル更新でも​使い回せる。​ベンチマーク順位を​追うより、​自社の​評価セットを​持つことの​ほうが​長期的な​資産に​なる。

Q2. ライセンスで​​商用利用に​​注意すべきモデルは？

2026年8月時点で法務レビューを必須にすべきは独自ライセンスの3つである。

• PLaMo 3系（Preferred Networks）：PLaMo community license。​商用利用には​PFNへの​事前登録が​必要で、利用者または関係会社の年商が10億円を超える場合は別途PFNから商用ライセンスの取得が必要。​エンタープライズは​ほぼ確実に​この​条件に​該当する
• Qwen3.8-2.4T-A95B（Alibaba）：独自の qwen3.8-max ライセンス。​同社の​ Qwen3.8-27B が​ Apache 2.0 であるのと​条件が​異なる​ため、​モデル単位で​確認する
• Kimi K3（Moonshot AI）：独自の​ Kimi-K3 License

商用フリーで扱いやすい：Qwen3.8-27B / Gemma 4 31B / Muse Glimmer 30B / llm-jp-4-33b / Mistral-Small-4-119B / gpt-oss-120b​（いずれも​ Apache 2.0）、​DeepSeek-V4系 / GLM-5.2​（MIT）

ベンダー名でライセンスを推測しないこと。 同じ​提供元でも​モデルごとに​条件が​違う年に​なった。​な​お本記事の​ライセンス記述は​2026年8月26日時点の​公開条文に​基づく​確認結果であり、​法的助言ではない。​採用判断では​原文の​最新版を​確認し、​自社法務の​レビューを​通す​こと。

Q3. 推論基盤は​​vLLM一択か？

エンタープライズ本番は​vLLMが​現時点で​デファクトだが、​用途次第：

• 本番運用 / 高スループット：vLLM
• オンプレ / 軽量 / CPU：llama.cpp
• HuggingFaceエコシステム：TGI
• PoC / 開発：Ollama
• 構造化出力多用 / 最新最適化：SGLang

複数併用も​普通。​検証は​Ollama、​本番は​vLLM、​エッジは​llama.cppと​いう​ケースが​多い。

Q4. 何GPU必要か？

業務要件から​逆算する​：

• 小規模PoC / 個人 / 20B級量子化：RTX 4090 1枚​（$1.6K）
• 中規模本番 / 27〜33B Dense：RTX 6000 Ada 1枚​（$7K〜）または​H100×1​（$25K〜）
• 大規模本番 / 120B級MoE：H100×1〜H200×1​（$25K〜）。​MoEは​総パラメータ分の​重みを​載せる​必要が​ある​ためアクティブ数で​見積もらないが、​配布形式が​低精度なら​下がる​（gpt-oss-120bは​80GB 1枚）
• 300B〜750B級MoE：H200×4〜8​（$120K〜$240K）
• 1T超のフラッグシップ：単一ノードでは​非現実的。​APIまたは​マネージド推論を​使う

冷却 / 電源 / ネットワーク機器を​含めると​上記の​1.5倍が​初期コスト目安。

Q5. セキュリティパッチは​​どう​​運用する？

3階層運用：

1. OS / コンテナ：通常の​運用基盤と​同等​（月次パッチ / 緊急パッチ）
2. 推論基盤（vLLM / TGI）：GitHub Watchで​リリース追跡 / 月次パッチ
3. モデル本体：四半期での​更新評価 / 重大バグは​ホットフィックス

国内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倍」​「機微​データで​クラウド使えない」と​いう​典型課題に​対して、​ハイブリッド設計で​現実解を​提示する。

FDXに​ローカルLLM導入の​相談を​する​ →

関連記事

• LLMトークン節約5パターン｜本番運用で​コストを​70%削る​ハーネス設計
• ループエンジニアリング入門｜自律エージェントを​"動かし続ける​"ハーネス設計
• AIエージェント完全ガイド｜2026年版
• LangGraph実装入門｜エンタープライズの​AIエージェント構築フレームワーク
• AI内製化の​進め方​｜外注依存から​脱却する​5ステップ
• DS+FDEハイブリッドチーム設計

まとめ

• ローカルLLMは、​データ持ち出し禁止・月数千万トークン超の​長期運用・サブ秒レイテンシ要求の​3ケースで​検討する
• 2026年8月時点で​モデルは​1T超の​フラッグシップと​単一GPUに​載る​27〜33B級に​二極化した。​自社で​建てるなら​後者、​フラッグシップは​APIで​使う
• ライセンスは​ベンダー名で​推測せず​モデル単位で​読む。​同じ​提供元でも​条件が​違う。​独自ライセンス​（PLaMo Community / qwen3.8-max / Kimi-K3）は​法務レビュー必須で、​特に​PLaMo 3は​年商10億円超で​別途商用契約が​必要
• 日​本語性能に​定説は​無い。​自社の​評価セット​（500〜1,000サンプル）を​作って​実測する。​評価セットは​次の​モデル更新でも​再利用できる​資産に​なる
• 推論基盤は​本番は​vLLM、​軽量・オンプレは​llama.cpp、​検証は​Ollamaと​用途で​使い分ける
• コストは​3〜5年TCOで​評価する。​24h 365日フル稼働でなければ​専用クラウドGPUが​優位な​ことが​多い
• 完全ローカル化ではなく、​機微情報は​ローカル・高難度推論は​クラウドAPIの​ハイブリッド設計が​定石
• 監査ログ・モデル更新ポリシー・セキュリティパッチまで​含めた​運用設計と​セットで​導入を​判断する

出典・参考文献

モデルの​諸元​（パラメータ数・コンテキスト長・ライセンス）は、​以下の​公式モデルカードで​確認した​値を​記載している​（2026年8月26日確認）。

• Moonshot AI​「Kimi-K3 Model Card」
• Alibaba​「Qwen3.8-2.4T-A95B / Qwen3.8-27B Model Card」
• DeepSeek AI​「DeepSeek-V4-Pro-0813 / DeepSeek-V4-Flash-0731 Model Card」
• Z.ai​「GLM-5.2 Model Card」
• Mistral AI​「Mistral-Small-4-119B-2603 Model Card」
• OpenAI​「gpt-oss-120b Model Card」
• Google​「gemma-4-31B-it Model Card」
• Meta​「Muse-Glimmer-30B Model Card」
• 国立情報学研究所​「llm-jp-4-33b-thinking Model Card」
• Preferred Networks​「plamo-3-nict-31b-base Model Card / PLaMo Community License」
• vLLM Documentation​「PagedAttention / OpenAI API Compat」
• HuggingFace​「TGI Documentation」
• llama.cpp GitHub README

更新履歴

本記事は​モデルの​入れ替わりが​速い​領域を​扱う​ため、原則として月次でモデル一覧・ライセンス・GPU要件を見直している（最終更新日は​冒頭に​記載）。

• 2026年8月26日：モデル一覧を​全面​刷新​（Kimi K3 / Qwen3.8 / DeepSeek V4 / GLM-5.2 / Gemma 4 / Muse Glimmer / llm-jp-4 / PLaMo 3 を​追加）。​ライセンス潮流の​変化、​規模の​二極化、​VRAM試算の​考え方を​追記
• 2026年7月7日：初版公開後の​表記修正
• 2026年7月3日：初版公開