第71回ブログ｜【2026年5月版】日本語に強いローカルLLM徹底比較 ─ モデル選定からオンプレミス構築までの実践ガイド

セキュリティ要件・コスト・オフライン稼働。ローカルLLMが「実用」になった2026年現在、日本語性能で選ぶならどのモデルか。なぜオンプレミス運用が重要なのか。どう環境を構築するのか。コンシューマGPUでの個人検証から、企業のオンプレミス基盤構築までを通しで整理してみた。

なぜ今、ローカルLLMなのか

2024年までの「ローカルLLM = クラウドの劣化版」という構図は、2026年に入ってほぼ消滅した。Qwen3、Gemma 4、Llama 4などの登場により、コーディング分野では一部のローカルモデルがクローズドモデルに肉薄、あるいは超越し始めている。SWE-benchではGLM-5.1がGPT-5.4を超えるスコアを記録し、Kimi K2.5は76.8%、MiniMax M2.5は80.2%を達成という報告もある。

ローカルで動かす理由は、もはや「劣化版でも我慢」ではない:

データ主権: 患者データ、契約書、社内文書をクラウドに出さずに済む
コスト: 月間100万トークン処理ならクラウドAPIと比べ長期では大幅に有利
オフライン稼働: 院内ネットワーク・閉域環境でも完結
カスタマイズ: LoRAやファインチューニングで業務特化が可能

医療データや個人情報を扱う案件、あるいは閉域環境での運用が前提となる業務では、ローカル実行がもはや「選択肢」ではなく「要件」になっているケースも多い。

オンプレミス運用の重要性 ─ なぜ今、企業はオンプレに回帰するのか

ローカルLLMの話題でしばしば混同されるのが「ローカル」と「オンプレミス」の関係だ。整理しておくと、ローカルLLMはモデルを自社で保持・実行する方式を指し、その実行環境がオンプレミスであることもクラウドIaaS(自社管理のVPC内)であることもある。本記事で扱う「オンプレミス運用」は、物理サーバー(または閉域ネットワーク内のサーバー)で完結する構成を指す。

オンプレミスが選ばれる6つの理由

1. データ主権とコンプライアンス

クラウドLLMでは、入力データが外部サーバーに送信される。学習に利用されないと明言されたAPIを使えばリスクは限定できるが、「データが社外に出る」という構造そのものを許容できない業界がある:

医療: 個人情報保護法、医療法、要配慮個人情報ガイドライン ─ 電子カルテや診療情報の院外送信は厳格に制限
金融: FISC安全対策基準、監督指針 ─ 取引データ・与信情報の取り扱いに監督官庁への説明責任
官公庁: 政府情報システムのセキュリティ要件(ISMAP) ─ 住民情報、行政文書は越境移転の制約あり
法務: 弁護士法上の守秘義務 ─ 依頼者情報を外部サービスに送信すること自体が職務違反となりうる
製造: 不正競争防止法上の営業秘密、未公開特許情報 ─ 国際競争力に直結する知財の流出リスク
越境データ: GDPR、改正個人情報保護法 ─ EU・域外への個人データ移転には特別な手続きが必要

「データがどこにあるか」を明確に説明できることは、セキュリティレビューや監査対応において構造的に情報漏洩リスクを排除できるという意味で、極めて大きい。「外部にコピーすること自体がNG」という規定がある業界では、クラウドLLMは初めから検討対象外となる。

2. 長期的なコスト最適化

クラウドLLMは初期費用ゼロで始められる反面、利用量に応じた従量課金が発生する。社員数百人が日常的に使う規模になると、月間トークン消費が急増し、年間コストが数百万〜数千万円規模になることも珍しくない。

オンプレミスは初期投資(GPU サーバー、ネットワーク、構築費)が必要だが、運用が軌道に乗れば電気代と保守費だけで稼働し続ける。3年スパンで見ると、月100万トークン超の処理規模ではオンプレミスの方が圧倒的に有利になるケースが多い。

3. レイテンシと可用性

ネットワークを経由しないため、リクエストから応答までの遅延が小さい。外部APIに依存しないことで、クラウド側の障害・レート制限・APIバージョン変更に振り回されることもなくなる。基幹業務に組み込む場合、SLAを自社でコントロールできる意義は大きい。

4. カスタマイズの自由度

クラウドLLMでは、提供事業者が用意したモデルとAPIに合わせる必要がある。オンプレミスならモデル本体・推論パラメータ・前後処理パイプラインをすべて自社の業務に最適化できる:

業務データでのLoRAファインチューニング
ドメイン特化の語彙拡張
RAG(検索拡張生成)による社内ナレッジ統合
業務ワークフローへの組み込み(Dify、LangChain、LlamaIndex)

5. 既存資産との統合

製造業の図面データや基幹システムの蓄積データなど、数TB級のオンプレミス資産を持つ企業にとって、それらをわざわざクラウドに移行することは現実的でない。既存のオンプレミスシステムにLLMだけを「足す」構成が、最も合理的な選択になる。

6. ベンダーロックインの回避

クラウドLLMの価格改定、提供終了、機能変更はベンダーの都合で発生する。OpenAIやAnthropicの過去のモデル廃止アナウンスを見ても、「使い続けたいモデルが半年後にAPI終了」というリスクは現実的だ。Apache 2.0ライセンスのQwen3やGemma系をオンプレミスで運用していれば、ベンダーがサービスを止めても自社内でモデルとインフラを完全に統制し続けられる。事業の根幹をAIに委ねるなら、この自律性は無視できない。

オンプレミス運用の課題

良いことばかりではない。導入前に押さえておくべき主な課題:

課題	内容	対策
初期投資	GPUサーバー数百万円〜、冷却・電源・ネットワーク整備	スモールスタート(1台構成)で検証してから拡張
専門人材	インフラ・MLOps・セキュリティの複合スキルが必要	SIerパートナーとの協業、社内育成と外部活用の併用
運用負荷	ハードウェア保守、OSアップデート、モデル更新、監視	構成管理(Ansible/Terraform)、監視(Prometheus/Grafana)の整備
ガバナンス	利用ガイドライン、アクセス制御、ログ監査	ISMS準拠の運用ルール策定、SSOによる認証統合

「技術的に動かせること」と「組織として継続運用できること」の間には大きな差がある。導入の意思決定では、ハードウェア選定よりむしろ運用体制の設計が成功要因となるケースが多い。

オンプレミスLLMの典型的なユースケース

業界	用途	求められる要件
医療	電子カルテ要約、診療支援、リハビリ補助	個人情報を院外に出さない、24時間稼働
法務	契約書レビュー、判例検索、文書ドラフト	依頼者情報の機密保持
製造	技術文書検索、不具合解析、設計支援	営業秘密保護、工場ネットワーク内完結
金融	与信判断補助、社内文書RAG、レポート要約	FISC準拠、監査対応
官公庁	文書作成支援、議事録要約、相談業務補助	ISMAP対応、住民情報保護
教育	教材生成、添削、学習支援	児童・生徒のプライバシー保護

モデル選定の5つの観点

実用に向けて、まず以下を整理しておく。

パラメータ数とVRAM要件: ハードウェアに乗らないモデルは選択肢に入らない
日本語性能: ベンチマーク(JCQ, Japanese MT-Bench, ELYZA Tasks 100など)
アーキテクチャ: Dense vs MoE(Mixture of Experts)
ライセンス: 商用利用可否(Apache 2.0/MIT/独自ライセンス)
量子化前提の品質: Q4_K_M, Q8_0などで実用に耐えるか

特にMoEの台頭は2026年のローカルLLM事情を大きく変えた。総パラメータが大きくても推論時はその一部しか動かない設計のため、これまでは「VRAMが足りないから諦め」だったクラスのモデルが手元で動くようになっている。

日本語性能で選ぶ・ローカルLLM主要モデル一覧

第一推薦: Qwen3シリーズ(Alibaba)

2026年現在、日本語ローカルLLMで最も信頼できるのがQwen3シリーズ。Alibaba Cloudが2025年4月にリリースしたこのファミリーは、後継のQwen3.5、Qwen3.6まで世代を重ね、日本語品質はGPT-4を超えるレベルとも評される。

主なバリエーション:

モデル	パラメータ	VRAM(Q4)	特徴
Qwen3-8B	8B	約6GB	軽量・汎用、エッジ向け
Qwen3-14B	14B	約9GB	バランス型、ミドルレンジGPUの定番
Qwen3-32B	32B	約20GB	ハイエンドGPU向け、高品質
Qwen3-30B-A3B (MoE)	30B総/3B active	約12GB	限られたVRAMで32B級品質

選ぶ理由:

学習データにSwallow Corpus(日本語コーパス)が組み込まれている世代もある
思考モード/非思考モードをシームレスに切り替え(GPT-5的なハイブリッド設計)
Apache 2.0ライセンスで商用利用に制約なし
119〜201言語対応で多言語性能が高い

VRAM 12〜16GBクラスのGPUであれば、Qwen3-14B (Q4_K_M) が現実的な第一候補となる。Qwen3-30B-A3Bも12GB VRAMで動くという実測報告があり、MoEの恩恵を体感したいなら試す価値が高い。

第二推薦: Gemma 3 / Gemma 4(Google)

Googleの公開モデル。Gemma 3は1B/4B/12B/27Bの4サイズ、Gemma 4ではMoEを採用したE2B/E4B/31B/26B-A4Bという構成になった。

QAT(Quantization-Aware Training)対応モデルのVRAM:

モデル	BF16	int4
Gemma 3 27B	54GB	14.1GB
Gemma 3 12B	24GB	6.6GB
Gemma 3 4B	8GB	2.6GB

Gemma 3 27B (int4) はRTX 3090 24GB級なら余裕で動く。VRAM 16GBクラスなら12B、24GBクラスなら27B が快適圏といえる。

Gemma 4ではDGX Sparkでのベンチマーク報告で、31Bが日本語タスク97.9%、26B-A4B(Active 3.8B)が96.4%を記録し、Nemotron 3 Super (120B) を上回るという結果が出ている。Thinkingモードが全モデルに搭載され、Ollama 0.20.0以降では "think": true で有効化できる。

日本語のトークン効率が良く、ReActスタイルのfunction callingにも強い印象がある。マルチモーダル(4B以上は画像入力対応)も標準装備。

第三推薦: Llama 4 Scout(Meta)

Llama 4はMeta初のMoE採用世代。Scoutが17B active / 109B total、Maverickが17B active / 400B total。日本語を含む12言語対応。

Scoutの特徴:

1,000万トークンのコンテキストウィンドウ(理論値): 日本語換算で500〜700万字、文庫本50冊分
INT4量子化でH100 1枚に乗る ─ 個人GPUでは厳しいが、サーバー環境を持つなら有力
マルチモーダル対応

ただしコンシューマGPUでのフルローカル稼働は現実的に厳しい。完全ロードに400GB以上のVRAMが必要なMaverickは論外として、Scoutも個人用途では量子化を強くかける必要がある。社内文書検索やコードレビュー用にサーバー側で動かす想定なら最有力候補のひとつ。

ライセンスはLlama 4 Community License。月間アクティブユーザー7億超のサービスは別途許諾が必要、EU圏のマルチモーダル利用には制限がある点に注意。

日本語特化モデル: ELYZA / Swallow / Karakuri / ABEJA / PLaMo

「日本語の汎用LLMがここまで強い時代に、日本語特化モデルは必要か」という議論はあるが、特定用途や日本語の細やかなニュアンスを求める場合は依然として候補になる。

ELYZA

ELYZA-Thinking-1.0-Qwen-32B(2025): Qwen 2.5ベースの推論モデル
ELYZA-Shortcut-1.0-Qwen-32B(2025): SFT版
過去にはLlama-3-ELYZA-JP 70BがGPT-4を上回るベンチマーク結果を出した
拡散言語モデル ELYZA-Diffusion も研究中
日本の医療分野特化モデル(SIP第三期)の開発実績あり ─ 医療系業務には選択肢として有力

Swallow

東工大・産総研中心のSwallowプロジェクト
Swallow Corpus v3.2、Swallow Math/Code v2など日本語コーパス整備が継続中
Llama 2/3、Qwen系をベースとした継続事前学習モデルを公開
Gemma-2-Llama Swallow ではGemma 2をベースに日本語強化版を出している

Karakuri

KARAKURI LM 70B v0.1とその会話特化版
カスタマーサポート向けに最適化された実績
商用利用はカラクリ株式会社への要問合せ

ABEJA

ABEJA-Qwen2.5-32b-Japanese-v1.0: 抽出・推論能力に特化
約2万件の人手アノテーションデータでSFT+DPO
Apache 2.0ライセンス

PLaMo(Preferred Networks)

PLaMo-13B-Instructで指示学習に対応
翻訳特化の「PLaMo翻訳」も公開
国産アーキテクチャから設計された数少ないモデル

正直なところ、日本語特化モデルの多くはQwen系・Gemma系の汎用モデルが日本語にも強くなった結果、優位性を出しにくくなっている。ただし、医療・法務など特定領域ではドメイン特化のファインチューニングを受けた日本語モデルの方が安定して動くケースがあり、用途次第で評価が変わる。

ハードウェア別・実践的な選び方

8GB VRAM(RTX 3060 Ti, 4060クラス)

Qwen3-8B (Q4_K_M): 約6GB、コンテキスト32K可能
Gemma 3 4B (int4): 約2.6GB
用途: チャット、軽量な要約、ローカル翻訳

16GB VRAM(RTX 5060 Ti, 4070 Ti Super, 5070クラス)

Qwen3-14B (Q4_K_M): 約9〜10GB、日本語業務の本命
Gemma 3 12B (int4): 約6.6GB、軽くて速い
Qwen3-30B-A3B MoE: 12GB VRAMで動作実績あり、品質は別格
用途: RAG、コード生成、業務文書作成、Whisperと並列実行も可能

24GB VRAM(RTX 3090, 4090, 5090クラス)

Qwen3-32B (Q4_K_M): 約20GB
Gemma 3 27B (int4): 14.1GB
用途: ほぼ何でも

32GB以上(プロ向け)

70Bクラスのモデルが快適動作圏
Llama 4 Scoutの本格運用も視野

推論ツール: Ollama / LM Studio / llama.cpp

モデルを動かすツールも選択肢が増えた。すべてllama.cppベースなので素の推論速度は5%以内の差、選定基準は使い勝手とエコシステムにある。

ツール	主要UI	強み	弱み
llama.cpp	CLI/コード	最も低レベル、全制御可能、最適化の余地最大	ビルド・パラメータ設定の知識が必要
Ollama	CLI/REST API	1コマンドで起動、OpenAI互換API、LangChainと相性◎	デフォルトでcontext 2048、Q4_0が多い
LM Studio	GUI	モデル探索が楽、Hugging Faceから直接DL、MLXバックエンド(Apple)	個人利用以外のライセンス要確認

実務的な使い分け:

本番アプリに組み込むなら Ollama: REST API互換で他言語からアクセスしやすい
モデル比較・実験段階は LM Studio: GUIで切り替えが速い
最大性能を引き出したいなら llama.cpp 直叩き: CUDAビルドで LLAMA_CUDA=ON

WSL2 + Docker + VS Codeのような開発環境では、Ollamaをdevcontainer内で動かす構成が扱いやすい。.zshrcで最低限の設定だけしておくと良い:

export OLLAMA_CONTEXT_LENGTH=32768
export OLLAMA_FLASH_ATTENTION=1
export OLLAMA_KV_CACHE_TYPE=q8_0

Ollamaのデフォルト設定で「思ったより性能が出ない」と感じる原因の多くは、コンテキストが2048に制限されていることとFlash Attentionが無効なこと。明示的に有効化するだけで体感がかなり変わる。

環境構築 ─ 実践的なステップガイド

ここからは、ローカルLLMを実際に動かすための環境構築を、開発者向けと本番運用向けの2段階で整理する。

ハードウェア選定の指針

オンプレミスLLMの中核はGPUだ。選定時に押さえるべき軸は3つ:

VRAM容量: モデルサイズに直結。動かしたいモデルのQ4量子化サイズの1.5倍程度を確保するのが目安
メモリ帯域幅: 推論速度に直結。同じVRAM 16GBでも128bit bus(RTX 4060 Ti)と256bit bus(RTX 5080)では体感速度が大きく違う
電力・冷却: 24時間稼働する本番環境では電源容量と排熱経路の設計が地味に効く

用途別の推奨構成:

規模	用途	推奨GPU	概算予算
検証/個人	モデル比較、PoC	RTX 4060 Ti 16GB / 5060 Ti 16GB	10〜15万円
小規模チーム	部署内10〜30人、RAG	RTX 4090 24GB / 5090 32GB	30〜60万円
中規模本番	全社100〜500人	RTX 6000 Ada 48GB ×2 / L40S	200〜500万円
大規模本番	千人超、ファインチューニング有	NVIDIA H100/H200 ×複数枚、DGX系	1,000万円〜

CPU、メモリ、ストレージは「GPUのボトルネックにならないこと」が目安。一般にはCore i7/Ryzen 7以上、メモリ 64GB以上、NVMe SSD 1TB以上を確保しておけば困らない。

開発・検証環境(WSL2 + Docker + Ollama)

個人開発や検証段階では、Windows + WSL2 + Docker Desktop + NVIDIA Container Toolkit + Ollama の構成が最もスタンダードかつ移行性が高い。Linux本番環境とほぼ同じワークフローでローカル開発できる。

ステップ1: NVIDIA ドライバ(Windows 側)

WSL2でGPUを使う場合、WSL2の中にLinux用GPUドライバを入れてはいけない。Windows側のドライバが /usr/lib/wsl/lib/ 経由でWSL2に自動公開される仕組みになっている。NVIDIA公式から最新のWindows用Game Ready/Studio ドライバ(545.23.06以降)を入れるだけでよい。

ステップ2: WSL2 + Ubuntu のセットアップ

PowerShellを管理者権限で開いて:

wsl --install -d Ubuntu-24.04

.wslconfig でメモリ割り当てを調整しておく(C:\Users\<username>\.wslconfig):

[wsl2]
memory=32GB
processors=8
sparseVhd=true
networkingMode=mirrored

sparseVhd=true でディスクの動的拡張を有効化、mirrored でLAN内の他デバイスから直接アクセス可能にする。

ステップ3: GPUの確認

WSL2 のUbuntu内で:

nvidia-smi

ドライバとCUDAバージョンが表示されればOK。CUDA Toolkitが別途必要な場合は、「cuda-toolkit-12-x」メタパッケージのみインストールする(cudaやcuda-driversを入れるとLinuxドライバが上書きされて壊れる)。

ステップ4: Docker と NVIDIA Container Toolkit

# NVIDIA Container Toolkit のインストール
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt update && sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# 動作確認
docker run --rm --gpus all nvidia/cuda:12.5.0-base-ubuntu22.04 nvidia-smi

最後のコマンドでGPU情報が表示されれば、コンテナからGPUを使える状態になっている。

ステップ5: Ollama + Open WebUI の起動(Docker Compose)

作業ディレクトリに compose.yaml を作成:

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ./ollama:/root/.ollama
    environment:
      - OLLAMA_FLASH_ATTENTION=1
      - OLLAMA_KV_CACHE_TYPE=q8_0
      - OLLAMA_CONTEXT_LENGTH=32768
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]
              driver: nvidia
              count: all
    restart: unless-stopped

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "8080:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_AUTH=False  # 本番ではTrueに
    volumes:
      - ./open-webui:/app/backend/data
    depends_on:
      - ollama
    restart: unless-stopped

起動とモデル取得:

docker compose up -d
docker compose exec ollama ollama pull qwen3:14b
docker compose exec ollama ollama pull gemma3:12b

ブラウザで http://localhost:8080 を開けばOpen WebUIでチャットできる。ChatGPT風のUIで複数モデルの切り替えやRAGも扱える。

本番運用環境(オンプレミスサーバー)

本番環境では、上記の構成をベースに以下を追加する:

ネットワーク設計

閉域ネットワーク: 外部インターネットから完全に遮断。モデルダウンロードは別途キャッシュサーバー経由
内部DNSとTLS: 社内サービスとして llm.example.local などで公開、社内CAでTLS証明書発行
リバースプロキシ: Nginx/Traefik でレート制限・認証・ログ集約

認証・アクセス制御

SSO統合: Azure AD/Keycloak でSAMLまたはOIDC連携、社員IDで認証
Ollama単体ではAPI認証がないため、リバースプロキシ層でJWT検証や Bearer トークン認証を実装
利用ログ: 誰が何を入力したか・どのモデルを使ったかを記録(GDPR・個人情報保護法準拠の保管期間設定)

監視・ロギング

メトリクス: Prometheus + Grafanaで GPU使用率、トークン生成速度、リクエストレイテンシを可視化
ログ集約: Loki/Elasticsearch で推論ログ、エラーログを一元管理
アラート: VRAM枯渇、応答遅延、エラーレート上昇で通知

バックアップ・運用ポリシー

モデルファイルとファインチューニング差分のバックアップ(週次)
設定ファイル(compose.yaml、認証設定、プロンプトテンプレート)のGit管理
セキュリティパッチ適用の月次サイクル

スケーリング

需要が増えたら、複数GPUサーバーをロードバランサで束ねる。Ollamaは複数インスタンスを並列に動かせるため、リクエストを分散すれば水平スケールが効く。より本格的には vLLM や TGI(Text Generation Inference) といったバッチ推論最適化エンジンへの移行が選択肢になる。

RAG(検索拡張生成)の組み込み

LLM単体では社内情報に答えられない。社内文書を活用するには RAG構成 が標準的なアプローチだ:

ベクトルDB: Qdrant、Weaviate、Chroma、pgvector
埋め込みモデル: multilingual-e5、bge-m3、Qwen-Embedding(日本語性能が高い)
RAGフレームワーク: LangChain、LlamaIndex、Haystack
ノーコード選択肢: Dify ─ オンプレミス対応、ワークフロー構築をUIで完結

Difyはオープンソースかつオンプレミス対応で、RAG・エージェント・ワークフローをノーコードで構築できる。社内SEがLLMの専門知識を持たなくても運用できる現実解として、2026年現在で最も注目されている選択肢のひとつだ。

よくあるトラブルと対処

症状	原因	対処
`could not select device driver "nvidia"`	Container Toolkit未設定	`sudo nvidia-ctk runtime configure --runtime=docker` 実行
GPU使用率が0% (CPUで推論)	VRAM不足/環境変数誤り	小さいモデルで再試行、`docker logs ollama` でログ確認
トークン速度が極端に遅い	コンテキスト長が大きすぎる	`OLLAMA_CONTEXT_LENGTH` を業務に必要な最小値に設定
モデルロードが遅い	`/mnt/c/` 経由でモデル読込	WSL2ネイティブ領域(`~/`)にモデル配置
CUDA out of memory	コンテキスト/バッチサイズ過大	`num_ctx` を下げる、量子化レベルを上げる(Q5→Q4)

構築コストの目安(2026年5月時点)

規模	構成例	ハードウェア初期費用
個人/小チーム	RTX 5060 Ti 16GB ワークステーション	30〜40万円
部門サーバー	RTX 5090 + 64GB RAM サーバー	80〜120万円
小規模本番	RTX 6000 Ada + 128GB RAM	200〜300万円
中規模本番	H100 80GB + サーバー一式	800万円〜

クラウドLLM(GPT-5やClaude Opus)に月数十万〜数百万を払うチームなら、1〜3年で回収可能な投資といえる。長期的に見れば、オンプレミス構築は単なるコスト削減策ではなく、データ・AIケイパビリティを社内資産として蓄積するという戦略的意味を持つ。

量子化レベルの選び方

ローカルLLMでは量子化(Quantization)が前提。標準的な選択肢:

量子化	品質	サイズ目安(14Bモデル)	推奨用途
Q8_0	原モデルにほぼ同等	約15GB	品質最優先、24GB GPU
Q6_K	高品質	約12GB	バランス重視
Q4_K_M	実用上問題なし	約9GB	コンシューマGPUの定番
Q4_0	やや劣化あり	約8GB	古い、Q4_K_M推奨
Q3_K_M	品質低下顕著	約7GB	VRAM不足の最終手段

注意点として、ある検証では「Qwen3.5-9bのQ8_0版がQ4_K_M版より品質スコアで下回り、速度も4分の1で、VRAMは1.5倍消費した」という報告がある。高精度量子化が必ずしも有利とは限らないため、自分の用途で実測することが重要。

結論: 2026年5月時点、こう選ぶ

VRAM帯別のおすすめ構成:

8〜12GBクラス: Qwen3-8B (Q4_K_M) をメインに、Gemma 3 4Bで速度を稼ぐ
16GBクラス: Qwen3-14B (Q4_K_M) を本命、Gemma 3 12Bで速度補完、Qwen3-30B-A3B MoEで品質に挑む
24GBクラス: Qwen3-32B または Gemma 3 27B でほぼ何でも対応
32GB以上: 70Bクラスや Llama 4 Scout の本格運用

共通の指針:

メインモデルは Qwen3シリーズ ─ 日本語業務の汎用解として最も外しにくい
速度重視/マルチモーダルは Gemma 3 / 4 ─ トークン効率と画像入力の強み
特化用途は ELYZA / Swallow / ABEJA系を業務にファインチューニング
超長文コンテキストが必要なら Llama 4 Scout(サーバー前提)

推論ツール:

本番: Ollama (devcontainerやDocker内で起動、OpenAI互換APIで叩く)
検証: LM Studio (GUI で複数モデル比較)
最大化: llama.cpp 直叩き (Flash Attention + KV cache量子化)

重要な気づき:

「ローカルLLM = 1モデルに絞る」発想を捨て、タスクごとに使い分ける設計が2026年現在の最適解だと感じている。速度が必要なら8〜9B、品質が必要なら30B-MoE、超長文なら専用モデル、というように、推論サーバー側でモデルを切り替える構成を取るアプローチが現実的だ。

次のステップ

個人検証から始めるなら:

手元のGPU(または安価なGPU付き中古PC)にUbuntuまたはWSL2を入れる
Docker + NVIDIA Container Toolkit を導入
Ollama + Open WebUI を Docker Compose で起動
自分のVRAM帯に合うモデルを pull(例: Qwen3-14B、Gemma 3 12B)
業務データで実測してベンチマーク

部門・全社展開を狙うなら:

PoC段階で要件(同時利用人数、必要モデル、応答速度)を整理
適切なGPU/サーバースペックを選定
認証・監視・バックアップを組み込んだ運用設計
RAG構成を組んで社内ナレッジと接続(LangChain / LlamaIndex / LiteLLM)
必要に応じてLoRAファインチューニングで業務特化
利用状況をモニタリングしながらスケール戦略を立てる

ローカルLLMは「完全な代替」ではなく、「クラウドLLMとの併用で使い分ける一手」として組み込むのが現実的だ。プライバシー要件の厳しいデータをローカルで処理し、複雑な推論はClaude OpusやGPT-5に投げる、というハイブリッド構成こそ、2026年の生産的なAI活用の姿だろう。

本記事は2026年5月時点の情報に基づきます。ローカルLLMの進化は速く、半年後には別のモデルが本命になっている可能性が高い点をご了承ください。