ローカル LLM とは｜仕組み・必要スペック・おすすめモデルと始め方【2026 年 10 月】

結論｜ローカル LLM は「機材」と「外に出せないもの」から選ぶ

ローカル LLM は、モデルの重みを手元の PC や社内サーバーに置き、推論まで自分の機材で完結させる使い方です。推論の入力が外に出ないことが最大の利点で、コストが下がるかどうかは使い方次第です。

判断の順番は次のとおりです。

1. 何を外に出せないのかを決めます。外に出してよいデータなら、まずクラウドの LLM で用が済まないかを確かめます
2. 手元のメモリ量から、動かせるモデルの大きさを計算します。4 ビット量子化なら 16GB で 12B 級、24GB で 30B 級が目安です
3. その大きさのモデルから、ライセンスと用途で候補を絞り、自分のタスクで試します

この記事は、手元で LLM を動かしたい開発者と、機密データを外に出せない業務で社内の AI を検討している情報システム担当の方に向けて書いています。数値は 2026 年 10 月 5 日に確認した公式ドキュメントとモデルカードに基づきます。個別のモデルは、各節から Gemma 4 12B などの解説記事へ進んでください。

ローカル LLM とは｜クラウドの LLM との違い

ChatGPT や Claude のようなクラウドの LLM では、入力を提供元のサーバーへ送り、そこで計算した回答を受け取ります。ローカル LLM では、この計算を自分の機材で行います。

動かすのに必要な要素は 3 つです。1 つ目は重みで、学習済みモデルの中身です。公開されているものを「オープンウェイト」と呼び、Hugging Face などから取得します。2 つ目は推論ランタイムで、重みを読み込んで計算するソフトです。Ollama・LM Studio・llama.cpp が代表的です。3 つ目は機材で、重みと計算途中のデータを載せるメモリ (GPU の VRAM、または Apple Silicon のユニファイドメモリ) の量が、動かせるモデルの大きさを決めます。

もう 1 つ押さえておきたいのが量子化です。重みの数値の精度を 16 ビットから 8 ビットや 4 ビットに落とし、必要なメモリを減らす手法で、llama.cpp は 1.5 ビットから 8 ビットまでに対応しています (llama.cpp の README)。手元で動かすモデルの多くは、4 ビット前後に量子化された版です。

ローカル LLM でできること・向かないこと

できることは、クラウドの LLM と同じく文章の要約・分類・抽出・書き換え・翻訳・コード生成です。手元に載る大きさのモデルは、ベンダーの公表値では一部のベンチマークでクラウドの上位モデルに並ぶものの、長い作業や設計判断で同じ品質が出るかは、自分のタスクで確かめる必要があります。ローカルに任せるかどうかは、処理の型で線を引くと判断しやすくなります。

社内文書を参照して答えさせたい場合は、検索と組み合わせる RAG の設計が必要です (RAG 構築の実践ガイド)。画像生成 (Stable Diffusion など) は別系統のモデルとツールになるため、この記事では扱いません。

必要スペック｜メモリはモデルの大きさから計算できる

重みのメモリ = パラメータ数 × 精度のバイト数

重みを載せるメモリの下限は、パラメータ数に 1 パラメータあたりのバイト数を掛けた値です。

実際の配布ファイルは、量子化の方式や画像入力の部品を含むかどうかで、この概算より大きくなります。たとえば Ollama の qwen3.8:27b (4 ビット) は 18GB、bf16 版は 56GB です (Ollama のタグ一覧)。概算で当たりをつけ、最後は配布サイズで確かめてください。

コンテキスト長もメモリを使う

入力が長くなるほど、計算途中のデータ (KV キャッシュ) を置くメモリが増えます。見落としやすいのが、Ollama が VRAM の量に応じてコンテキスト長の既定値を変える点です (Ollama の Context length)。

同じページは、Web 検索・エージェント・コーディングツールには 64,000 トークン以上を設定するよう案内しています。16GB の機材で起動できたモデルでも、既定の 4K のままでは長い文書を一度に入れられません。コンテキスト長を延ばすとその分メモリを使うため、重みのサイズだけで機材を決めないでください。

手元のメモリ別に動かせる規模の目安

2026 年 10 月 5 日時点の Ollama の配布サイズから整理すると、目安は次のとおりです。

Meta は Muse Glimmer のモデルカードで、24GB・32GB・64GB の機材を想定したサイズを示しています (Muse Glimmer のモデルカード)。4 ビット前後に量子化した言語モデル部分は 20GB 未満で、24GB または 32GB の中に KV キャッシュや画像の部品まで収まるとしています。量子化による精度の低下は、15 種のベンチマークの平均で 32GB 向けが 0.2%、24GB 向けが 1.0% です。いずれも Meta 自身の測定です。

Apple Silicon の Mac はユニファイドメモリを OS やブラウザと共有するため、上の表で 1 行下のメモリ量を選ぶと余裕が出ます。GPU が無い場合も llama.cpp は CPU だけで推論できますが、応答が遅くなるため、動作の確認や待ち時間を許容できる一括処理に向きます。

おすすめモデル比較【2026 年 10 月時点】

手元の機材で動かせる大きさのモデルを、ライセンスと用途で並べます。値は各モデルカードと Ollama のタグ一覧で 2026 年 10 月 5 日に確認したものです。

Ollama の公式ライブラリに配布の無い 2 本は重みのサイズで見ます。MiMo-V2.6-Distill-Qwen-9B は bf16 で約 19GB、ELYZA-Thinking の 32b-a3b は 4 ビットに換算して約 16GB です。MiMo-V2.6-Distill-Qwen-9B のコンテキスト長は、モデルカードに記載がありません。出典は Gemma 4 12B、Qwen3.8-27B、Muse Glimmer、MiMo-V2.6-Distill-Qwen-9B、ELYZA-Thinking の各モデルカードと、Ollama のモデル一覧 です。

16GB クラスなら、最初の 1 本は Gemma 4 12B が扱いやすい候補です (Gemma 4 12B の解説)。24GB クラスなら Qwen3.8-27B と Muse Glimmer 30B が候補になります。この 2 本を自社サーバーに置けるかで比べた記事が オープンウェイト 3 モデル比較 です。

日本語で選ぶなら

Google は Gemma 4 を 140 以上の言語で事前学習し、35 以上の言語をサポートするとしています。Meta は Muse Glimmer を 100 以上の言語のデータで学習したとしています。いずれも対応言語の数で、日本語の文章として自然かどうかは別に確かめる必要があります。

日本語を主に扱うなら、国産の選択肢として ELYZA-Thinking があります。国立情報学研究所 (NII) が開発した LLM-jp-4 をベースに ELYZA が追加学習したモデルで、Apache 2.0 で公開されています。公式の量子化版は無く、モデルカードの起動例は vLLM です (ELYZA LLM-jp-4 の解説)。

コーディングで選ぶなら

Qwen3.8 はコーディングとエージェント用途を前面に出したモデルで、Ollama のページにも Claude Code・OpenCode から起動するコマンドが載っています。Muse Glimmer のモデルカードも、SWE-Bench などのタスク完遂や、ツール呼び出しが失敗したときの再試行を設計目標に挙げています。

9B 級では、Xiaomi の MiMo-V2.6-Distill-Qwen-9B があります。Xiaomi の技術報告では、元の Qwen3.5-9B と比べて SWE Verified が 60.0 から 61.1、SWE Pro が 32.0 から 44.6 に上がったとされています。いずれも Xiaomi 自身の測定です (MiMo-V2.6 の解説)。

手元に置けない大型モデル

重みが公開されていても、手元では動かせないモデルがあります。DeepSeek-V4-Pro (1.7 兆パラメータ)、Qwen3.8-Max の重み (Hugging Face の Qwen/Qwen3.8-2.4T-A95B、約 2.4 兆)、MiMo-V2.6-Pro (1.02 兆) は、4 ビットに量子化しても約 500GB〜1.2TB のメモリが要り、データセンター向けの構成が前提です。「オープンウェイト」という言葉だけで手元に置けると判断しないでください (Qwen3.8-Max の解説)。

ツールの選び方｜Ollama・LM Studio・llama.cpp

出典は Ollama の macOS・Windows の要件、LM Studio のシステム要件・料金・利用規約、llama.cpp の README です。LM Studio は Intel の Mac に対応していません。x64 の Windows では AVX2 対応の CPU が必須で、16GB 以上のメモリと 4GB 以上の VRAM が推奨されています。

迷ったら Ollama から始めるのが早道です。モデルの取得から手元で API を呼べる状態までコマンド 1 つで済み、後から Claude Code などのツールにもつなげられます。量子化の種類を切り替えて比べたい場合は LM Studio が向いています。

FIXIT

Ollama で動かしてるなら、全部手元で処理してるってことだよね？

Kaname

そうとは限りません。Ollama には、クラウドで動くモデルもあります。

FIXIT

えっ、同じアプリから選べちゃうの？

Kaname

はい。業務で使うなら、最初にクラウド機能を切っておきます。

ローカル LLM の始め方 (構築手順)

Ollama で動かす

1. Ollama の公式サイト から macOS・Windows・Linux 版を入れます
2. モデルを取得して対話を始めます。初回は重みのダウンロードが走ります
3. 別のアプリから呼ぶ場合は、OpenAI 互換の API を使います
4. 長い文書やコーディングに使う場合は、アプリの設定画面のスライダーでコンテキスト長を 64K に上げます。アプリを使わない場合 (Linux のサーバーなど) は、環境変数を付けて ollama serve を起動します

# 2. 取得して対話する (16GB クラスの例)
ollama run gemma4:12b
 
# 3. OpenAI 互換 API を呼ぶ (既定は localhost:11434)
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "gemma4:12b", "messages": [{"role": "user", "content": "この議事録を 3 行で要約して"}]}'
 
# 4. アプリを使わない場合は、コンテキスト長を 64K にして起動し、割り当てを確かめる
OLLAMA_CONTEXT_LENGTH=64000 ollama serve
ollama ps

ollama ps の PROCESSOR 列が 100% GPU なら、モデルがすべて GPU に載っています (Ollama の Context length)。モデルの一部が CPU に割り当てられていると応答が遅くなるため、モデルを小さくするか、コンテキスト長を下げます。既存の OpenAI 向けのクライアントは、接続先を差し替えるだけで使えます (OpenAI compatibility)。

LM Studio で動かす

アプリの検索画面でモデルを探し、量子化の種類を選んでダウンロードすると、そのままチャットできます。開発者向けの画面からローカルサーバーを起動すると、OpenAI 互換の API が http://localhost:1234/v1 で使えます。コマンドで操作する場合は lms を使います (LM Studio の CLI)。

lms get <モデル名>
lms load <モデル名>
lms server start

llama.cpp で動かす

llama.cpp は、LM Studio の内部でも MLX と並んで使われている推論エンジンです。README の手順では、インストール後に Hugging Face の GGUF (llama.cpp 系のツールが使う重みの形式) を直接指定して動かせます。例のモデルは README のものです。

# Hugging Face の GGUF を取得して対話する
llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF
 
# OpenAI 互換の API サーバーとして起動する
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

コーディングに使う｜Claude Code から手元のモデルを呼ぶ

Ollama 経由で、Claude Code などのエージェントを手元のモデルにつなげられます。Ollama の Claude Code 連携ページ の起動コマンドに、qwen3.8 のライブラリページ にあるモデル指定を付けると次のとおりです。

# Claude Code を Ollama の qwen3.8 につないで起動する
ollama launch claude --model qwen3.8

同じページは、ローカルのモデルには 64K 以上のコンテキストを推奨しています。24GiB 未満の VRAM では既定値が 4K なので、設定を変えずに起動するとリポジトリの文脈が入りきりません。27B 級なら重みだけで 18GB あり、64K の KV キャッシュが加わると 24GB の機材では余裕が小さくなります。Codex CLI や OpenCode も ollama launch で起動できます。

任せやすいのは、テストケースの下書き、既存コードの読解と要約、決まったルールでの書き換え (命名の統一、型注釈の追加など) のように範囲がはっきりした作業です。複数のファイルにまたがる設計の判断や長時間の自律作業は、クラウドの上位モデルのほうが安定しやすい傾向があります。普段のリポジトリはクラウドのモデルで進め、外に出せないリポジトリだけをローカルのモデルに切り替える使い分けが現実的です。IDE から使う場合は Copilot for JetBrains の Ollama 対応 も選択肢になります。

業務で使う前に確かめること

情報システム担当の方が社内でローカル LLM を使う前に確認したい項目です。「ローカルで動かしているから安全」と言い切る前に、1 つずつ確かめます。

Ollama の FAQ は、手元で動かしている場合はプロンプトやデータを Ollama 側が見ないこと、クラウドのモデルでは提供のために処理するが保存・記録・学習はしないことを書き分けています。LM Studio も、有料のクラウド推論 (Bionic+) は米国でホストされ、データを保持しない (ZDR) としています。社内で「外に出さない」と説明するなら、手元の推論とクラウドの推論のどちらを使っているかまで明記してください。

FIXIT

じゃあ情シスとしては、何を最初に決めればいいの？

Kaname

待ち受けを 127.0.0.1 に保つ設定です。クラウドを切るのは前提です。

FIXIT

それを各自の PC で守ってもらうってこと？

Kaname

いえ、各自に任せると設定がばらつきます。手順にしておくと、運用が回ります。

クラウドの LLM との使い分けと費用

ローカル LLM では、モデルの利用料が無料でも、機材と電気代は誰かが払います。費用は、機材を持つか、GPU を借りるか、クラウドの API を使うかで分けて考えます。

48GB クラスの GPU を借りた実測では、1 時間あたり 1 ドル前後でした。この単価で計算すると、1 日 8 時間の稼働で月 240 ドル前後、24 時間動かし続けると月 700 ドルを超えます (オープンウェイト 3 モデル比較、Qwen-Image の LoRA 学習の記録)。ローカルが安くなるのは、既にある機材で足りる場合か、処理量が多く従量課金の費用が機材費を上回る場合です。API の料金を下げる手順は LLM コスト最適化 で扱っています。

FIXIT の検証から｜手元の処理とクラウド GPU の実測

FIXIT では、手元での文字起こしと、クラウドの GPU を借りた推論の検証を記事にしてきました。初回の取得時間と、GPU を借りたときの費用の考え方は、その実測に基づいています。

• 40 分の商談録画を、音声を外部へ送らずに文字起こししました。M2・メモリ 24GB の Mac で、39 分 58 秒の音声の処理は 3 分 50 秒でした。初回はモデル (1.6GB) の取得に約 12 分かかっています (ローカル Whisper の実装記録)
• クラウドの GPU で画像生成のモデルを動かした検証では、34.74GB のイメージをキャッシュの無いマシンへ配る初回の起動に 12.1 分かかりました。ワーカーが起動済みの状態では、待ち時間は 792 ミリ秒でした (RunPod の自前ワーカーの記録)

どちらの検証でも、待ち時間と費用を決めたのはモデルの性能ではなく、初回の取得時間と常時起動の有無でした。ローカル LLM を業務に入れるときも、ベンチマークより先に、どの機材で動かし、いつ起動し、誰が更新するかを決めてください。

まとめ

最初の一歩は、手元のメモリ量を確かめ、その大きさに合うモデルを 1 本だけ Ollama で動かしてみることです。そのうえで、外に出せないデータを使う処理を 1 つ選び、クラウドの LLM と同じ指示で比べてください。出力の差が小さければその処理をローカルに移し、差が大きければクラウドを使い続けます。この順番なら、機材を買ってから使い道に困ることを避けられます。

社内文書を参照する AI エージェントや RAG を、モデルの選定から評価の仕組みまで含めて作りたい場合は、AI エージェント開発 でご相談いただけます。個別のご相談は お問い合わせ からどうぞ。