ローカルLLM比較｜主要モデル・ツールの選び方とおすすめ

本ページはローカルLLMの「比較」（モデル・ランタイム・UIの選び方とおすすめ）に特化した記事です。導入の手順や全体像は、ローカルLLMの導入｜始め方とおすすめツールをご覧ください。

クラウドAPIに頼らず、自社サーバーやローカルPCでLLMを動かす「ローカルLLM」が急速に普及しています。コスト削減・情報漏洩リスクの排除・カスタマイズ性の高さなど、実務上のメリットは大きい一方で、「どのモデルを選ぶか」「どのツールで動かすか」という判断が結果を大きく左右します。本記事では、2025〜2026年時点で実用候補となる主要なローカルLLMモデルとランタイム・フロントエンドツールを多角的に比較し、用途別の選び方まで解説します。自社での検証・実務利用で得た知見も交えながら、実際に手を動かせる情報をお届けします。

機密データ運用で私たちが実際に使っている「選定の順番」

クリスタルメソッドでは、外部に出せない機密データを扱う業務のために自社でローカルLLMを運用しています。その実運用を通じて痛感したのは、「どのモデルが一番賢いか」から選び始めると、後で作り直しになりやすいということです。私たちが実際に採っている選定の順番を、モデル表とは別の実務目線でまとめます。

まず決めるのはモデルでもツールでもなく「機密要件と隔離レベル」です。ローカルで動かす最大の理由がデータを外に出さないことなら、推論を行う端末・サーバーの外部通信可否や、フロントエンドが自動送信するテレメトリの有無まで先に確認します。ここを曖昧にしたまま高性能モデルを選ぶと、せっかくローカル化した意味が薄れます。次に手元のVRAMという「動かせる上限」から逆算してモデルサイズと量子化を絞り込み、最後に自社の実データで少数の出力を人手評価して初めて本採用します。ベンチマークの数字より、この「実データでの数件チェック」が採否を左右することがほとんどでした。

もう一点、運用して分かった実務的な勘所として、モデルは差し替え前提で組むことを強くおすすめします。私たちはOpenAI互換APIを共通の窓口として使い、新しい有力モデルが出るたびにアプリ側を触らずモデルだけ入れ替えられる構成にしています。ローカルLLMは進化が速いため、特定モデルに密結合させないことが、結果的に一番運用コストを下げる選び方だと考えています。

主要ローカルLLMモデルの比較

モデル選定は「サイズ（パラメータ数）」「量子化ビット数」「ライセンス」「得意タスク」で判断します。以下に2025〜2026年時点の主要候補をまとめます。

モデル	開発元	代表サイズ	ライセンス	日本語対応	主な強み
Llama 3.1 / 3.2 / 3.3	Meta	8B / 70B / 405B	Meta Community（商用可・条件あり）	△〜○	バランス型・エコシステム最大。8Bは汎用的に優秀
Mistral / Mixtral	Mistral AI	7B / 8x7B(MoE)	Apache 2.0	△	英語コード生成・推論に強い。MoEで高速
Gemma 2 / 3	Google	2B / 9B / 27B	Gemma Terms（商用可）	○	小サイズで高性能。多言語対応が良好
Phi-3 / Phi-4	Microsoft	3.8B / 14B	MIT	△	超小型で推論・数学・コードに強い。エッジ向け
Qwen2.5 / Qwen3	Alibaba	7B / 14B / 72B	Apache 2.0（一部異なる）	◎	日本語・中国語が特に強い。コード生成も優秀
DeepSeek-R1 / V3	DeepSeek	7B / 14B / 70B	MIT	○	推論・数学・コードで GPT-4 水準。蒸留版が実用的
Command R+（Cohere）	Cohere	35B / 104B	CC-BY-NC（非商用）	○	RAG特化・ツール呼び出し対応
Elyza / LLM-JP等	国内各社	7B〜70B	各モデルによる	◎	日本語特化ファインチューニング済み

モデル選定の実践的な判断基準

• VRAM量が最大の制約：4B〜8BモデルはVRAM 8GB（RTX 3060/4060相当）で動作可。13B〜14BはVRAM 12〜16GB以上、70BはVRAM 48GB以上または量子化＋CPU混在が必要。
• 量子化（Q4_K_M・Q8等）でトレードオフ：Q4_K_M量子化は元モデルの約4割のVRAMで動作し、体感品質の劣化は軽微。Q8は品質重視、Q4は速度・省メモリ重視で使い分ける。
• 日本語タスクならQwen2.5か国内特化モデル：自社検証では、日本語でのRAGや社内ドキュメント要約においてQwen2.5-14BはLlama3.1-8Bと比べて文意把握の精度が顕著に高かった（2025年時点の検証。現行の主力はQwen3系）。
• コード生成ならDeepSeek-Coder系かQwen2.5-Coder：Python・SQLのコード補完では専用ファインチューニング済みモデルが汎用モデルを大幅に上回る。

ランタイム（推論エンジン）の比較

モデルファイルを実際に動かす「ランタイム」の選択は、使いやすさ・速度・API互換性に直結します。

ツール	対応OS	GPU対応	OpenAI互換API	セットアップ難度	特徴
Ollama	Win / Mac / Linux	CUDA / Metal / ROCm	◎	★☆☆（簡単）	コマンド一発でモデル取得・起動。REST APIで即アプリ連携可能。最も普及
llama.cpp	Win / Mac / Linux	CUDA / Metal / Vulkan	○（サーバモード）	★★☆（中程度）	CPU推論の王者。GGUF形式の事実上の標準。最軽量・最カスタマイズ性
LM Studio	Win / Mac / Linux	CUDA / Metal	◎	★☆☆（簡単）	GUIでモデル検索・管理・チャットまで完結。非エンジニアに最適
vLLM	Linux（主）	CUDA（必須）	◎	★★★（高度）	本番サービング特化。PagedAttentionで高スループット。マルチGPU対応
text-generation-webui	Win / Mac / Linux	CUDA / CPU	○	★★☆（中程度）	Gradio UI内蔵。ファインチューニング(LoRA)もGUIで可能
Jan	Win / Mac / Linux	CUDA / Metal	◎	★☆☆（簡単）	オープンソースのデスクトップアプリ。Ollamaに近い使用感

用途別ランタイムの選び方

• 個人・社内検証の入門：Ollamaが第一選択。ollama pull llama3.1の一行でモデル取得から起動まで完了し、http://localhost:11434のOpenAI互換APIがそのまま使える。
• 非エンジニアがGUIで使いたい：LM Studioはモデル検索・ダウンロード・チャットがGUI一体型。PCスペック確認機能もあり安心。
• 本番API・高並列処理：vLLMは複数ユーザーからの同時リクエストを効率的に捌けるため、社内APIサーバー化に最適。ただしGPUサーバー前提。
• GPU非搭載の省スペースPC・Apple Silicon：llama.cppはCPUのみ・Metal対応で動作し、Raspberry Pi等での実験も可能。

フロントエンド・管理UIの比較

ランタイムの上にチャットUIやRAG機能を重ねるフロントエンド層も選択肢が広がっています。

ツール	連携ランタイム	RAG機能	マルチユーザー	特徴
Open WebUI	Ollama / OpenAI互換	◎（内蔵）	○	ChatGPT風UI。画像生成・音声入力・プラグインも対応。Dockerで即起動
AnythingLLM	Ollama / LM Studio / OpenAI互換	◎（ワークスペース型）	○（チーム向け）	PDFや社内文書のRAGをGUIで構築できる。エージェント機能も内蔵
Dify	Ollama / OpenAI互換他	◎	◎	ノーコードでRAGアプリ・AIワークフローを構築。本番利用に向いた構成
PrivateGPT	llama.cpp / Ollama	◎	△	完全オフライン前提。機密文書RAGに特化した設計
LibreChat	OpenAI互換全般	○	◎	複数LLMの切替・ユーザー管理・会話履歴管理が充実。社内展開に向く

フロントエンド選定のポイント

自社検証では、社内RAGの構築にAnythingLLM + Ollama + Qwen2.5-14Bの組み合わせが安定して動作しました（2025年時点の検証。現行の主力はQwen3系）。PDFや社内マニュアルをドラッグ＆ドロップでナレッジベースに追加できるため、非エンジニアの担当者でも運用に参加できる点が実務上の大きな利点です。チーム展開が必要な場合はDifyかLibreChatが向いており、Dockerで迅速に環境を整えられます。

性能・ベンチマークの見方と実用的な注意点

MMLU・HumanEval・MATHなどの学術ベンチマークはモデル選定の参考になりますが、実業務での性能とは必ずしも一致しません。

• 日本語ベンチマーク（JCommonsenseQA・JNLI等）を確認する：英語ベンチマーク上位のモデルが日本語では大幅に性能を落とすケースがある。
• コンテキスト長（Context Length）：長文書RAGでは8K〜32Kトークン以上が実用水準。モデルによって有効活用できるウィンドウ長に差がある。
• 推論速度（トークン/秒）：チャット用途ではVRAM量により10〜80トークン/秒前後が目安。CPU推論はGPUの10分の1以下になる場合が多い。
• 量子化による品質劣化：Q4_K_Mは多くのタスクで実用上問題ないが、複雑な推論・論理問題では誤りが増える傾向がある。重要タスクはQ6以上を推奨。

クラウドLLMとローカルLLMの使い分け

ローカルLLMに移行すべきかどうかは、要件に応じて判断が必要です。

なお、クラウドLLMも含めたより広範なモデル比較（GPT-4o・Claude・Gemini等との横断的な比較）については、AIモデルの比較（LLM比較）の記事で詳しく解説しています。ローカルLLMの選定と合わせて参照することで、用途に応じた最適な選択が可能になります。

推奨スペック・GPUの選び方など構築の詳細は → こちらの専門記事にまとめています。

ベンチマーク指標を実務でどう読むか：速度・品質・コンテキスト長

公開ベンチマークは選定の入口としては便利ですが、数値をそのまま自分の環境の性能予測に使うと外します。ここでは「どの指標を、どんな限界を踏まえて読むか」を実務目線で整理します。

まず見るべき4つの指標と、その落とし穴

指標	意味	読むときの注意
生成速度（tokens/sec）	1秒あたりの出力トークン数。体感の速さに直結	プロンプト処理速度と生成速度は別物。バッチや短文と長文で大きく変わる
品質ベンチ	知識・推論などをテスト形式で採点したスコア	設問形式に最適化されやすく、実タスクの使い勝手とは一致しないことがある
コンテキスト長	一度に扱える入力＋出力の上限	公称の最大長と、精度を保てる実効長は乖離しがち。長文ほど破綻・失速しやすい
量子化後の品質	軽量化した状態での実力	量子化で品質は下がる傾向。ベンチ値が非量子化なら手元と条件が違う

公開ベンチが自分の環境に当てはまらない理由

• 測定条件が違う：ハード、ランタイム、量子化の有無、プロンプト設計が異なれば速度も品質も変わります。
• タスクが違う：汎用ベンチが高くても、あなたの日本語業務・要約・コード補助での実力は別問題です。
• 更新頻度：モデルもランタイムも更新が速く、古い数値は現状を反映しません。

数値の罠（チェリーピック）を避ける

• 好条件のみを切り出した比較でないか（最速ケース・特定設問だけ）を疑う。
• 速度と品質はトレードオフになりやすいので、片方だけの数値で判断しない。
• ライセンスや正確なスコアは二次情報を鵜呑みにせず公式で確認する。

結論：自分のタスクで小さく実測する

最も確実なのは、候補を2〜3本に絞り、実際に使う代表プロンプトを10件ほど用意して手元で回すことです。生成速度・出力品質・長文での安定性を同じ条件で比べれば、公開ベンチのバイアスに左右されず、あなたの用途に最適な1本が見えてきます。

用途別・選定マトリクスの作り方：要件からモデルとランタイムを決める

個別の比較表を眺めても「結局どれ」と迷うのは、比較軸が自分の要件に紐づいていないからです。ここでは、比較を「自分の要件で決める表」に落とし込む枠組みだけを扱います。各モデルの詳細スペックやランタイムの機能比較は本記事の他セクションを参照し、ここでは決め方に徹します。

1. まず決める5つの軸

候補を絞る前に、次を自分の言葉で言語化します。ここが曖昧なままだと比較が発散します。

• 用途：チャット補助／文書要約・分類／コード生成／RAG（社内文書検索）など、主タスクを1つに絞る
• 機密度：外部送信が許されるか。不可なら完全ローカルが前提になり選択肢が変わる
• 日本語要否：日本語の入出力品質が主目的か、英語中心の補助か
• 予算：GPUを新調するか、手持ちCPU/内蔵GPUで回すか（機材詳細は他記事参照）
• 運用体制：個人が試すのか、チームで共有・更新し続けるのか

2. 軸から候補を絞る考え方

• 機密度が高い→クラウドAPIを外し、ローカル完結できるモデル・ランタイムに限定する
• 予算が小さい→小さめパラメータ帯を先に候補化し、大型は保留にする
• 日本語が主目的→日本語評価の情報が多いモデルを優先し、実際は自分の代表プロンプトで試す
• 運用体制がチーム→導入・更新のしやすさ（GUI有無、モデル入れ替えの手間）をランタイム側の判断材料に加える

1つの軸で候補が絞れたら次の軸を重ねる、を繰り返します。すべてを一度に満たそうとせず、外せない軸（多くは機密度）から順に足切りするのがコツです。

3. 決定マトリクスの例（行＝用途）

※ 表は「軸→絞り込みの向き」を示す枠組みです。具体的なモデル名・ライセンス・性能値は各モデルの公式情報で必ず確認してください。

4. 迷ったときの初手

決めきれないときは、用途を1つに絞り、小さめのモデル＋導入の簡単なランタイムで最小構成を動かすのが最短です。自分の代表的な入力を10件ほど流し、日本語品質・速度・手間を体感してから、必要に応じて大型やGPU増強へ進みます。最初から最上位を狙わず、要件に効く軸だけで一巡させることが、比較疲れを避ける近道です。

「自分のGPUで動くか」で候補を先に絞る──VRAMと量子化の判断軸

モデル比較でありがちな失敗は、パラメータ数やベンチマークのスコアだけを横並びにして「一番賢いもの」を選んでしまうことです。ローカルLLMでは、そのモデルが手元のGPUのVRAMに収まって実用速度で動くかが先に決まり、収まらないモデルはどれほど高性能でも候補から外れます。比較表を作る前に、まず自分の環境で動く範囲へ候補を絞り込むのが実務の順序です。

必要VRAMのざっくり見積もり方

重み(モデル本体)の占有量は「パラメータ数 × 1パラメータあたりのバイト数」でおおまかに見積もれます。量子化(重みを低ビットで表す圧縮)によってこのバイト数が変わります。以下はあくまで概算であり、実際の必要量は実装(推論エンジン)や設定によって変動するため、最終的には使用するツールの公式情報や実測で確認してください。

• FP16(無圧縮): 約2バイト/パラメータ。7Bで約14GB、13Bで約26GB(概算)。
• 8bit(Q8系): 約1バイト/パラメータ。7Bで約7GB(概算)。
• 4bit(Q4系): 約0.5バイト/パラメータ。7Bで約4GB前後(概算。実際の量子化フォーマットにより誤差あり)。

これに加えて、会話履歴や入力文書を保持するKVキャッシュがコンテキスト長に比例してVRAMを食います。長文RAGや長い会話を想定するなら、重みだけでVRAMを使い切らず余白を残して候補を選ぶ必要があります。VRAMをはみ出すと一部がCPU/メインメモリにオフロードされ、生成速度が目に見えて低下することがあります。低下の度合いはハードウェア構成や推論エンジンの実装に依存するため一概な数値では言えませんが、「入り切る中で最も品質の高い量子化」を狙うのが判断軸になります。

量子化レベルの選び分け

量子化	VRAM	品質の傾向	向く選択場面
Q4_K_M など4bit系	最小級	実用範囲で劣化は小さめとされることが多い	VRAMが厳しい/まず動かして比較したい
Q5・Q6系	中	4bitより余裕がある	VRAMに余裕があり品質を上げたい
Q8・FP16	大	劣化はほぼ無いとされる	精度検証・出力を厳密に比較したい

品質の傾向は量子化手法やモデルによって差があるため、上表は一般的な目安として捉えてください。比較の実務では、まず4bitで複数モデルを同条件で走らせて絞り込み、最終候補だけ高ビットで精度を見比べる、という二段構えが効率的です。「同じ7Bでも量子化が違えば別物」という前提を持つだけで、公開ベンチマークの数字を鵜呑みにする比較から一歩抜け出せます。

用途とライセンスで最終候補を1つに絞る──目的別の重み付けと確認手順

VRAMで動く範囲まで絞れたら、次は「何に使うか」で評価軸の重みを変えて最終候補を決めます。総合力が高いモデルが自分の用途で最適とは限らず、コード生成・日本語対応・長文RAG・エージェント用途では重視すべき性質が異なります。汎用ランキングをそのまま使わず、自分のタスクに合わせて評価軸を並べ替えるのが選定の要点です。

用途別に重視する評価軸

主な用途	特に効く性質	比較時に見るポイント
コード生成・補助	コード特化の学習/長い出力の安定性	コード系ベンチ、対応言語、指示追従の崩れにくさ
日本語の文章生成	日本語データでの学習量・トークナイザ	日本語出力の自然さを自分のプロンプトで実測
社内文書RAG	長コンテキスト・文脈への忠実性	対応コンテキスト長、与えた文書外を作らないか
エージェント/自動化	tool calling(関数呼び出し)対応	構造化出力・JSON整形の安定度

ベンチマークのスコアは出発点にはなりますが、最終判断は自分の代表タスクを複数用意し、候補モデルへ同じプロンプトを投げて出力を並べるのが確実です。ローカルで動かす場合はAPIの従量課金を気にせず繰り返し試せる点が、この実地比較を行いやすくしています(ただし電力・ハードウェアのコストは別途かかります)。

ライセンス(商用利用の可否)の確認手順

用途で品質が拮抗したときに効いてくるのが利用条件です。ローカルLLMは公開モデルごとにライセンスが異なり、寛容な種類のライセンス(例: Apache 2.0 や MIT系)を採用しているものもあれば、独自の利用規約で利用規模・再配布・出力の再学習利用などに条件を付けているものもあります。どのモデルがどのライセンスかは変更されることもあるため、伝聞や本記事の一般論で判断せず、必ず配布元の一次情報で確認してください。

• 配布元のモデルカードと同梱の LICENSE ファイルを直接読む。
• 「商用利用の可否」「大規模利用時の追加条件」「生成物の権利・再利用の扱い」を項目として確認する。
• 派生・ファインチューニング版を使う場合は、ベースモデルのライセンスが継承される点も見る。
• ライセンス条件は改定されることがあるため、最新版を配布元の公式情報で都度確認する。

技術的に動くこと・出力が良いことに加えて、自社の使い方がライセンス条件の内側に収まるかまで確認して初めて、安心して本番採用できる「最終候補1つ」に絞り込めます。

まとめ

ローカルLLMの比較において重要なのは「モデル・ランタイム・フロントエンド」の3層をそれぞれ目的に合わせて選ぶことです。

• 日本語タスク中心：Qwen3系またはELYZA系モデル ＋ Ollamaの組み合わせが現時点で最もバランスが良い。
• コード生成・推論：DeepSeek-R1蒸留版（7B〜14B）またはQwen3-Coderを推奨。
• 社内RAG構築：AnythingLLMまたはDify ＋ Ollamaが実務導入のハードルが低い。
• 本番高並列API：vLLM ＋ 大型モデル（GPUサーバー必須）。

ローカルLLMの進化は速く、数ヶ月ごとに有力な新モデルがリリースされています。特定のモデルに深く依存しすぎず、ランタイム（特にOllama）のOpenAI互換APIを抽象化レイヤーとして活用し、モデルを差し替えやすい構成にしておくことが長期的な運用コストを下げる鍵です。クラウドLLMとの比較も含め最適な選択をするには、LLM全体の比較記事も併せてご覧ください。

関連記事

• ローカルLLMとは？メリット・始め方・必要環境を解説【2026年版】
• ローカルllm 導入
• ローカルllm 無料
• AIモデルの比較（LLM比較）

あわせて読みたい

• DeepSeekの仕組みと使い方
• オンデバイスAI（ローカル・ブラウザ・オフライン）