Gemma 4時代のローカルLLM比較
目次
1. なぜ今、ローカルLLMを比較するべきなのか
ローカル LLM は、クラウド API の単なる代替ではありません。社内データを外に出さず、低レイテンシで、用途に合わせて AI を組み込むための選択肢として、開発現場での存在感が増しています。
2026 年 6 月時点では、OpenAI の gpt-oss、DeepSeek V4、Mistral Small 4、Llama 4、Gemma 4、Qwen 3.6 Plus / Qwen3-Coder 系など、ローカル実行やオンプレミス検証を現実的に検討できる選択肢が一気に増えています。以前のように「ローカルで動くが性能は妥協する」という段階から、「用途を絞れば業務システムに組み込める」段階へ移りつつあります。
一方で、モデル名だけを見て選ぶと失敗しやすい領域でもあります。ベンチマーク上では強いモデルでも、日本語の社内文書に弱いことがあります。推論能力が高くても、応答が遅すぎてチャット UI には向かないこともあります。マルチモーダル対応をうたっていても、実際の帳票や現場写真では前処理の品質に左右されます。
この記事では、ローカル AI に興味のあるエンジニア向けに、モデルの知名度ではなく、用途、ハードウェア、RAG との相性、セキュリティ、運用しやすさという実務目線で整理します。
ローカルLLMの選定では、モデル性能だけでなく、実行環境、社内データ、セキュリティ要件まで同時に見る必要があります。
結論から言うと、2026 年 6 月現在の比較では、オンプレの汎用・推論基盤なら gpt-oss-120b / 20b、長大コンテキストや大規模エージェント検証なら DeepSeek V4、マルチモーダルと推論・コーディングを 1 つに寄せたいなら Mistral Small 4、マルチモーダルや長文では Llama 4、端末・エッジ寄りのエージェント体験では Gemma 4 が候補になります。Qwen 系は Qwen 3.6 Plus や Qwen3-Coder Plus が開発者向けの最新ラインとして目立ちますが、ローカル/オンプレ用途では公開ウェイトの有無と提供形態を分けて確認する必要があります。
2. 比較前に決めるべき4つの前提
ローカル LLM の比較でよくある失敗は、モデル一覧を眺めながら「一番賢いもの」を探してしまうことです。実務では、同じモデルでも量子化形式、GPU メモリ、コンテキスト長、推論エンジン、プロンプト、RAG の品質によって体感が大きく変わります。
先に決めるべきなのは、モデル名ではなく要件です。少なくとも次の 4 点を明確にしてから比較すると、選定の迷いがかなり減ります。
| 観点 | 決めること | 判断の例 |
|---|---|---|
| 主用途 | コーディング、社内文書検索、要約、チャット、画像理解、エージェント実行のどれか | コードレビューなら推論とコード性能、社内 FAQ なら RAG 品質を優先する |
| 実行場所 | 開発 PC、GPU ワークステーション、社内サーバー、エッジ端末のどれか | 個人検証なら 4B〜8B 級、複数ユーザーならサーバー構成を前提にする |
| 応答速度 | 1 ユーザーの対話用途か、複数ユーザーの業務システムか | チャットは TTFT、バッチ処理は総処理時間を見る |
| 制約 | 商用利用、社内規定、ログ保存、個人情報、外部送信禁止ルール | モデルライセンスと社内監査ログの扱いを最初に確認する |
特に企業利用では、「ローカルだから安全」と考えるのは危険です。端末内に残るプロンプト、回答ログ、キャッシュ、ベクトル DB、参照ファイルの権限がずれていれば、クラウド API を使わなくても情報管理上のリスクは残ります。ローカル LLM は、セキュリティを簡単にする技術ではなく、セキュリティ設計の自由度を高める技術だと捉える方が現実的です。
3. 主要ローカルLLMの特徴比較
2026 年時点でローカル AI の検討に上がりやすいモデル系統を、エンジニア視点で整理すると次のようになります。ここでのポイントは、単純な順位付けではありません。どのモデルにも得意領域と運用上の注意点があります。
| モデル系統 | 向いている用途 | エンジニア視点の見どころ |
|---|---|---|
| gpt-oss-120b / 20b | オンプレ推論、社内エージェント、コード・STEM系タスク、プライベートクラウド | OpenAI の open-weight reasoning モデル。Apache 2.0 で、120b は単一 80GB GPU、20b はより制約のある環境を想定しやすい。テキスト専用なので、画像入力は別モデルと組み合わせる。 |
| DeepSeek V4 Pro / Flash | 1M コンテキスト、巨大コードベース解析、長文RAG、大規模エージェント | Pro と Flash の 2 系統があり、API では deepseek-v4-pro / deepseek-v4-flash が案内されている。長大コンテキストを活かす一方、ローカル運用はサーバー級の設計が前提。 |
| Mistral Small 4 | マルチモーダル、推論、コーディング、業務チャット | 2026年3月公開の open model。119B total / 6.5B active の MoE で、画像入力、推論、コーディングを 1 モデルで扱いやすい。Apache 2.0 で商用検討もしやすい。 |
| Llama 4 Scout / Maverick | マルチモーダル、長文コンテキスト、汎用AIアプリ | Meta の open-weight multimodal MoE 系。Scout と Maverick は 17B active の設計で、強力だがローカル運用では H100 級 GPU やホスト構成を前提に検討したい。 |
| Gemma 4 E2B / E4B / 26B MoE / 31B Dense | オンデバイス、エッジAI、マルチモーダル、ローカルエージェント | 2026年4月公開の Google DeepMind の open model family。Apache 2.0、140以上の言語、視覚処理、エージェント的な計画・ツール利用を前面に出し、E2B/E4Bは端末実行、26B MoE/31B Denseは高性能ローカル・サーバー用途で検討しやすい。 |
| Qwen 3.6 Plus / Qwen3-Coder Plus / Qwen3系 | 開発者向けエージェント、コーディング、多言語、社内チャット | Qwen Code では Qwen 3.6 Plus や Qwen3-Coder Plus が最新ラインとして案内されている。一方でローカル/オンプレ比較では、公開ウェイトとして利用できる Qwen3 系と、API提供モデルを分けて判断する。 |
gpt-oss は、2026 年 6 月時点のローカル LLM 比較で新しく中心に置くべきモデルです。OpenAI が公開している open-weight reasoning モデルで、オンプレミスやプライベートクラウドで動かすことを前提に設計されています。120b は 117B total / 5.1B active、20b は 21B total / 3.6B active の MoE で、どちらも 128k コンテキストを持ちます。テキスト専用なので、画像理解まで 1 モデルで完結させたい場合は別候補を併用します。
DeepSeek V4 は、長大コンテキストとエージェント用途で注目度が高いモデルです。DeepSeek の API ドキュメントでは deepseek-v4-pro と deepseek-v4-flash が案内され、Hugging Face 側にも V4 系のモデルが展開されています。1M コンテキストを前提に、大規模コードベースや長文ドキュメントを扱う構成では魅力的ですが、ローカル実行は「個人 PC で気軽に」ではなく、GPU サーバーや専用推論基盤の話になります。
Mistral Small 4 は、2026 年 3 月時点で Mistral が公開した新しい open model です。従来のチャット、推論、マルチモーダル、コーディングを 1 モデルに寄せた位置づけで、Apache 2.0 ライセンスという点も企業検討では扱いやすいポイントです。RAG の回答生成、画像付き帳票の一次理解、開発者支援をまとめて検証したい場合に候補に入ります。
Llama 4 は、Meta の open-weight multimodal MoE 系として引き続き重要です。Scout や Maverick は強力ですが、ローカル運用では GPU メモリ、量子化、ライセンス、推論エンジン対応を慎重に確認する必要があります。研究・検証用途と、本番の業務システム用途では前提が変わります。
Gemma 4 は、この記事で特に注目したいローカル AI 向けモデルです。Google DeepMind は 2026 年 4 月に Gemma 4 を公開し、E2B、E4B、26B MoE、31B Dense の 4 サイズを用意しました。E2B / E4B は Android AICore Developer Preview や Google AI Edge と組み合わせた端末実行を意識したモデルで、26B MoE / 31B Dense はより高い推論能力やエージェントワークフローを狙う構成です。Apache 2.0 ライセンスで使いやすく、視覚処理、多言語、ローカルでの計画・ツール利用を前面に出している点が、前世代との大きな違いです。
Qwen 系は、コーディングやエージェント開発で存在感があります。Qwen Code 側では Qwen 3.6 Plus や Qwen3-Coder Plus が案内されており、開発者体験としては非常に魅力的です。ただし、ローカル LLM の比較では、API 経由の最新モデルと、実際に自社環境へ持ち込める公開ウェイトを分けて評価する必要があります。
ノートPC、GPUワークステーション、オンプレサーバーでは、選べるモデルサイズと運用設計が大きく変わります。
4. 用途別に見るおすすめ構成
個人開発・検証用: ノートPCまたはMacで小型モデル
まずローカル LLM を体験するなら、Gemma 4 E2B / E4B、Qwen3 系の小型・量子化モデル、gpt-oss-20b の軽量構成などから始めるのが現実的です。Ollama、LM Studio、llama.cpp、MLX、vLLM、Google AI Edge Gallery などを使えば、環境構築の負担を抑えて評価できます。
この段階で重要なのは、巨大モデルを動かすことではありません。プロンプトの作り方、RAG の前処理、UI、ログ設計、回答評価の流れを早めに試すことです。小さいモデルでも、自社の業務に対して「何が足りないか」は十分に見えてきます。
コーディング支援: Qwen3-Coder Plus、DeepSeek V4、gpt-oss、Mistral Small 4を比較
コーディング支援では、単純なベンチマークだけでなく、自社リポジトリを読ませたときの修正精度、テスト失敗時の粘り、不要な大改修を避けられるかが重要です。ローカル運用では、コードを外部 API に送らずに調査できる点が大きな価値になります。
最新ラインで見ると、Qwen3-Coder Plus は開発者向けエージェント体験、DeepSeek V4 は長大コンテキストを使ったコードベース解析、gpt-oss はオンプレ推論とツール利用、Mistral Small 4 はコーディング・推論・画像入力をまとめた検証に向きます。どれを選ぶかは、モデル性能だけでなく、コードを外部に出せるか、GPU をどこに置くか、レビュー前にどの差分を人間が見るかで変わります。
ただし、ローカル LLM にコード修正を任せる場合でも、人間のレビューとテストは必須です。特に、認証、決済、権限管理、個人情報処理のような領域では、AI が作ったコードをそのまま採用しない運用ルールを明確にしておく必要があります。
社内文書検索・RAG: モデルより検索品質が効く
社内 FAQ、議事録、仕様書、営業資料を扱う場合、LLM 単体の性能よりも、チャンク設計、埋め込みモデル、メタデータ、アクセス権限、回答根拠の表示が効きます。ローカル LLM は回答生成の一部であり、ベクトル DB、全文検索、監査ログ、権限管理とセットで設計するべきです。
現場では、モデルを大きくするよりも、文書の前処理を改善した方が回答品質が上がることがよくあります。PDF の表をどう扱うか、古い資料をどう除外するか、部署ごとに参照範囲をどう分けるか。こうした地味な設計が、RAG の実用性を決めます。
画像入力・マルチモーダル: 実データで検証する
画像付きの帳票、現場写真、UI スクリーンショット、図面の説明などを扱うなら、マルチモーダル対応モデルを比較します。2026 年 6 月時点では、Llama 4、Mistral Small 4、Gemma 4 が候補になります。特に Gemma 4 は、E2B / E4B を端末側の一次理解に使い、必要に応じて 26B MoE / 31B Dense やクラウド側の大きなモデルへ渡す設計と相性があります。gpt-oss はテキスト専用なので、画像理解を含める場合は OCR や別の vision model と組み合わせる前提で考えます。
入力解像度、OCR、トリミング、前処理、プロンプトテンプレートの影響が大きいため、公開ベンチマークよりも自社の実データで検証することが大切です。現場写真の照明が暗い、帳票の罫線が多い、手書き文字が混ざる、といった条件は、実データでしか見えません。
5. ハードウェアと運用設計の目安
ローカル LLM の必要スペックは、モデルサイズ、量子化、コンテキスト長、同時接続数で変わります。ざっくりした目安として、1B〜8B 級は開発 PC でも試しやすく、20B 級は高メモリ PC や GPU ワークステーションがあると安定します。gpt-oss-120b、DeepSeek V4、Mistral Small 4、Llama 4 のような MoE・大規模モデルは、単体 PC での実験よりも、サーバー構成、推論エンジン、キャッシュ、キューイング、監視まで含めた運用設計が前提になります。
重要なのは、最大モデルを動かすことではありません。ユーザーが求める精度、応答速度、費用、セキュリティ要件を満たす最小構成を見つけることです。社内 FAQ に 70B 級モデルが必要とは限りません。逆に、複雑な設計レビューや法務文書の比較では、小型モデルだけでは足りないこともあります。
実運用では、次のような分担が現実的です。
| 実行環境 | 向いているモデル規模 | 向いている用途 |
|---|---|---|
| ノートPC / Mac | 1B〜8B 級、軽量量子化モデル | 個人検証、軽い要約、プロンプト評価、開発者向け実験 |
| 高メモリPC / GPUワークステーション | 8B〜30B 級、gpt-oss-20b級 | コーディング支援、社内RAG検証、少人数向け業務チャット |
| オンプレGPUサーバー | gpt-oss-120b、Mistral Small 4、Llama 4、DeepSeek V4 など | 複数部署向けRAG、監査ログ付きAI基盤、閉域環境の業務システム |
| エッジ端末 / AI PC | Gemma 4 E2B / E4B、NPU対応モデル | オフライン入力補助、端末内分類、現場端末の一次応答、ローカルエージェント |
クラウド LLM とのハイブリッド構成も、最初から選択肢に残しておくべきです。個人情報や社内機密を含む一次処理はローカルで行い、公開情報の調査や高度な推論だけクラウドに逃がす。こうした分担にすると、ローカル LLM の強みとクラウド LLM の強みを両方使えます。
6. 導入時のチェックポイント
ローカル LLM を導入する時は、技術検証と同時に運用設計を進める必要があります。モデルが動くことと、業務で使えることの間にはかなり距離があります。
まず確認したいのはライセンスです。商用利用、再配布、モデル改変、生成物の扱いはモデルごとに条件が違います。OSS 風に見えても、企業利用では確認が必要なケースがあります。
次に、ログと権限です。ローカルで動かす場合でも、プロンプト、回答、参照文書、ベクトル化済みデータ、キャッシュは残ります。誰がどの文書を参照できるのか、回答根拠をどう表示するのか、監査ログをどこに保存するのかを決めておかないと、後から運用で詰まります。
最後に、評価データセットを作ることです。モデルを更新した時、量子化形式を変えた時、RAG のチャンクサイズを変えた時に、回答品質が落ちていないか確認できる仕組みが必要です。数十問でもよいので、自社タスクに近い評価セットを用意しておくと、モデル選定が感覚論になりにくくなります。
チェックリストとしては、次の項目を最低限見ておきたいところです。
- 商用利用と再配布の条件をライセンスで確認する
- 社内データを含むプロンプトと回答ログの保存方針を決める
- RAG で参照できる文書を権限ごとに分離する
- モデル更新時に回答品質が落ちないよう、評価データセットを作る
- クラウド LLM とのハイブリッド構成も選択肢に残す
- 量子化後の品質、TTFT、tokens/sec、メモリ使用量を実機で測る
- プロンプトインジェクションや不正なツール実行への対策を設計する
7. まとめ
2026 年 6 月現在のローカル LLM 選定では、モデル単体の勝ち負けよりも、業務データ、検索、権限、運用監視まで含めた設計力が差になります。エンジニアが最初に作るべきなのは、最強モデルのデモではなく、社内の 1 業務に対してローカル AI で安全に回答できる小さな実証環境です。
gpt-oss、DeepSeek V4、Mistral Small 4、Llama 4、Gemma 4、Qwen 系は、それぞれ魅力的な選択肢です。ただし、どれか 1 つが常に正解というわけではありません。コーディング、RAG、マルチモーダル、推論、オンデバイスなど、用途ごとに候補を絞り、実データで検証することが重要です。
OpenBridge では、ローカル AI システムのモデル選定、RAG 構成、オンプレ環境構築、AI エージェント連携、PoC から本番導入まで支援しています。クラウド AI とローカル LLM を適材適所で組み合わせることで、セキュリティと実用性を両立した AI 活用を進められます。
この記事を書いた人
