この記事の日付について。 2026-09-27に調査・執筆し、公開日の2026-10-04に、Ollama公式FAQ(プライバシー・ollama ps・クラウド無効化の記述)、Ollamaのクラウドモデル一覧とドキュメント、Ollama library qwen3.6 tags、Qwen3-8Bの設定ファイルとモデルカード(コンテキスト長)、筆者環境の ollama list / ollama show の表示を一次資料で再確認して更新しました。本文中の「2026-09-27確認」は執筆時、「2026-10-04確認」は公開前の再確認の日付です。筆者環境の計測値は、断りがない限り2026-09-27の記録です。2026-10-11に第7節・第10節・第11節とよくある質問6項目を追記しました(「2026-10-11確認」はその日の確認です)。
この記事でわかること
- ローカルLLMの定義と、ChatGPTのようなクラウドLLMとの違い
- Ollama・LM Studioを使うとき、入力が手元に留まる範囲と、通信が発生する操作
- 重み・量子化・実行ソフトの3つで、手元の推論が成り立つ仕組み
- 自分のPCで動くかを、パラメータ数とビット数から見積もる計算方法
- ローカルLLMが向く作業と、向かない作業
ローカルLLMとは、大規模言語モデル(LLM)の推論を自分のPCや自社サーバーの上で実行する使い方です。モデルの重みファイルを手元に置き、実行ソフトがそれを読み込んで文章を生成します。
ChatGPTとの違いは「どこで計算するか」です。クラウドLLMは入力を提供元のサーバーへ送って処理します。ローカルLLMは、モデルを取得したあとなら通信なしで応答できます。LM Studioの公式ドキュメントは、ダウンロード済みモデルとのチャットで入力した内容は端末の外に出ないと明記しています(LM Studio Docs『Offline Operation』2026-09-27確認)。動かせるかどうかは、主にメモリ量で決まります。小型の量子化モデルなら一般的なPCも候補になります。ただし必要量は重みだけでなくKVキャッシュや実行バッファでも変わるため、空きメモリと実際のロード状態を確認します。
1. ローカルLLMとは──「ローカル」は推論の実行場所を指す
LLMを使う処理は、大きく「学習」と「推論」に分かれます。学習は大量の計算資源で重みを作る工程です。推論は、できあがった重みに文章を入力して続きを出させる工程です。
ローカルLLMの「ローカル」は、このうち推論をどこで実行するかを指します。学習まで手元で行う必要はありません。Qwen・Gemma・Llamaのように、開発元が重みを公開しているモデル(オープンウェイトモデル)をダウンロードして使うのが一般的です。
そのため「ローカルLLM」という名前のモデルがあるわけではありません。同じQwen3-8Bでも、自分のPCで動かせばローカル、クラウドのAPI経由で使えばクラウドです。
2. 一次資料の対応表
この記事の事実関係は、次の一次資料と筆者の運用記録から取っています。
| 主張 | 一次資料 | 種別 | 確認日 |
|---|---|---|---|
| ローカル実行時、Ollamaはプロンプトやデータを見ない。既定の待ち受けは localhost の11434番ポート | Ollama FAQ | 公式ドキュメント | 2026-09-27(プライバシーの記述は2026-10-04再確認) |
| Ollamaはモデルをインターネットから取得する。モデルの保存場所、既定で5分間メモリに保持 | Ollama FAQ | 公式ドキュメント | 2026-09-27 |
Ollamaのクラウド機能は OLLAMA_NO_CLOUD=1 で無効化できる | Ollama FAQ | 公式ドキュメント | 2026-10-04 |
| Ollamaのクラウドモデルには公開重みのモデルも並ぶ | Ollama cloud models、Ollama docs: Cloud | 公式ライブラリ・ドキュメント | 2026-10-04 |
Ollamaの既定コンテキスト長はVRAM量で4k/32k/256kに変わる。ollama ps の列の意味 | Ollama docs: Context length | 公式ドキュメント | 2026-09-27 |
| LM Studioはモデル取得後はオフラインで動き、入力と文書は端末外に出ない。通信が要る5つの操作 | LM Studio Docs『Offline Operation』 | 公式ドキュメント | 2026-09-27 |
| llama.cppは1.5〜8ビットの整数量子化、CPUとGPUの併用推論に対応。MITライセンス | GitHub ggml-org/llama.cpp | GitHub | 2026-09-27 |
| Qwen3-8Bは8.2Bパラメータ、36層、KVヘッド8、Apache 2.0。コンテキスト長は標準32,768トークン、YaRN併用で131,072トークン | Hugging Face Qwen/Qwen3-8B、config.json | モデルカード・設定ファイル | 2026-09-27(コンテキスト長は2026-10-04確認) |
| qwen3:8b の標準タグはq4_K_Mで5.2GB、q8_0は8.9GB、fp16は16GB | Ollama library qwen3 tags | 公式ライブラリ | 2026-09-27 |
| DGX Sparkでのモデル重みのサイズ・メモリ配分・生成速度 | 筆者の作業記録(2026-03-15、2026-08-04) | 運用記録 | 2026-09-27 |
| CPUのみの動作、Apple M系の対応、生成速度とメモリ帯域の関係 | Ollama docs: macOS、llama.cpp Discussion #4167、Apple Newsroom | 公式ドキュメント・GitHub・公式発表 | 2026-10-11 |
| Qwen・Llama 3.3・Gemmaの商用利用条件、Ollamaのコーディング連携 | 各モデルのLICENSE、Gemma Terms of Use、Ollama docs: Integrations | ライセンス文書・公式ドキュメント | 2026-10-11 |
企画段階では、DGX Spark上でネットワークを遮断した状態の動作と、ollama ps・生成速度を新たに測る予定でした。この記事の公開時点では、その測定はまだ行えていません。そのため後半の数字は、過去の作業記録にある値と、一次資料からの計算値に限っています。
3. クラウドLLMとの違い
ChatGPTやClaudeのWeb版・API版と比べると、違いは次のように整理できます。
| 観点 | ローカルLLM | クラウドLLM(ChatGPT等) |
|---|---|---|
| 推論を実行する場所 | 自分のPC・自社サーバー | 提供元のデータセンター |
| 入力の送信先 | 手元の実行ソフト(既定はlocalhost) | 提供元のサーバー |
| 通信が要る場面 | モデルの取得、アプリ更新など | 毎回の問い合わせ |
| 使えるモデル | 重みが公開されたモデル | 提供元の非公開モデル。公開重みのモデルをクラウドで動かすサービスもある |
| 性能の上限 | 手元のメモリと計算性能で決まる | 提供元の設備で決まる |
| 費用 | 機材と電気代。手元で推論する分のAPI利用料はかからない | 月額または従量課金 |
| 保守の担当 | 自分(モデル更新・設定・障害対応) | 提供元 |
最大の差は、入力データの行き先です。一方で、性能の天井も手元の機材に縛られます。ChatGPTで使えるような最上位モデルは重みが公開されていないため、ローカルでは動かせません。
4. 何が手元に留まり、何に通信が要るか
「ローカルLLMならデータは外に出ない」は、条件付きで正しい説明です。対象になるのは、推論を手元で完結させる構成でのチャット入力と文書です。モデルの取得、アプリ更新の確認、クラウド連携機能の利用、事業者によるアカウント情報や利用メタデータの収集は、それぞれ別に確かめる必要があります。2つの代表的な実行ソフトの公式文書を並べます。
| 項目 | Ollama | LM Studio |
|---|---|---|
| チャットの入力 | ローカル実行時はOllama側に見えない | 端末の外に出ない |
| アップロードした文書 | (FAQに記載なし) | 処理は端末内で完結 |
| モデルの取得 | インターネットから取得。プロキシが要る場合あり | 通信が必要 |
| モデルの検索・カタログ閲覧 | (FAQに記載なし) | 通信が必要 |
| 実行ランタイムの取得 | (FAQに記載なし) | 通信が必要 |
| アプリの更新確認 | (FAQに記載なし) | 通信が必要 |
| 既定の待ち受け | localhost:11434 | 既定値の記載なし。localhostまたはLAN上でOpenAI互換のローカルサーバーとして動かせる |
出典はOllama FAQとLM Studio Docs『Offline Operation』です(いずれも2026-09-27確認)。
Ollama FAQの記述は「Ollama runs locally. We don’t see your prompts or data when you run locally.」です。LM Studioは、通信が要る操作をモデルの検索、新しいモデルのダウンロード、カタログの閲覧、LM Runtimesのダウンロード、アプリ更新の確認の5つに限定しています。
「外に出ない」が崩れる3つの場面
公式文書を読むと、ローカル実行ソフトを使っていても入力が外に出る場面があります。
- クラウドモデルを選んだとき: Ollamaにはクラウド上で動くモデルもあり、DeepSeek・GLM・Gemma 4など公開重みのモデルも並んでいます(Ollama cloud models 2026-10-04確認)。同じモデル名でも、クラウド版を選べば推論は手元で走りません。FAQによると、その場合プロンプトと応答はクラウドで処理されます(保存・ログ記録はしないと説明)。使わないなら
OLLAMA_NO_CLOUD=1、または~/.ollama/server.jsonの"disable_ollama_cloud": trueで無効化できます(Ollama FAQ 2026-10-04確認) - 待ち受けをネットワークに開いたとき:
OLLAMA_HOST=0.0.0.0:11434にすると、同じネットワークの他の端末から呼び出せます。推論は手元のままですが、呼び出せる範囲が広がります。認証やファイアウォールで接続元を絞らないと、そのネットワークに到達できる端末から使える状態になります - 外部と連携するツールをつないだとき: Web検索やMCPサーバーなど外部に通信するツールを組み合わせると、その経路で入力の一部が送られます
このほか、Ollama FAQは「We collect basic account info and limited usage metadata to provide the service that does not include prompt or response content.」とも説明しています(2026-10-04確認)。プロンプトの中身とは別に、アカウント情報や利用メタデータの扱いがある点は押さえておきます。
つまり「ローカルかどうか」はアプリの種類ではなく、推論がどこで走ったかと周辺ツールの通信で決まります。
5. 仕組み──重み・量子化・実行ソフトの3点で成り立つ
手元で推論が成り立つまでの流れを、段階ごとに示します。
- 重みを取得する: 開発元が公開したモデルの重み(数十億〜数千億個の数値)をダウンロードします。Ollamaなら
ollama pull qwen3:8bの1行です - 量子化で小さくする: 重みは通常16ビット(BF16)で配布されます。これを8ビットや4ビットに丸めて、ファイルとメモリを縮めます。Ollamaの標準タグの多くは量子化済みです
- 実行ソフトが読み込む: llama.cppなどの推論エンジンを組み込んだOllama・LM Studioが、重みをGPUメモリ(またはメインメモリ)に載せます。Ollamaには
gemma4:26b-nvfp4のようなMLX向けのタグもあり、エンジンはllama.cppだけではありません - 入力をトークンに分けて計算する: 入力文をトークンに分割し、重みを使って次のトークンの確率を計算します
- 1トークンずつ生成する: 出たトークンを入力の末尾に足し、また次を計算します。途中の計算結果はKVキャッシュとしてメモリに保持します
- ローカルAPIで返す: 結果は画面か、localhostのAPI経由で他のアプリへ返ります
量子化とは
量子化は、重みを表すビット数を減らす処理です。16ビットの数値を4ビットにすれば、重みの理想計算では約4分の1の大きさになります。実際のファイルは、ブロックごとの倍率などの付帯情報や、一部を高いビット数で残す分だけ大きくなります。代わりに数値が粗くなるため、出力の質がどこまで落ちるかはモデルと方式によります。
llama.cppは1.5・2・3・4・5・6・8ビットの整数量子化に対応しています(GitHub ggml-org/llama.cpp 2026-09-27確認)。実際のOllamaのタグでは、qwen3:8b の標準タグが q4_K_M(5.2GB)、q8_0 が8.9GB、fp16 が16GBです(Ollama library qwen3 tags 2026-09-27確認)。
実行ソフトの種類
| ソフト | 形態 | 特徴 |
|---|---|---|
| llama.cpp | C/C++のライブラリ・CLI | CUDA・Metal・Vulkan・HIPなどに対応。VRAMを超えるモデルをCPUと分担して動かせる。MITライセンス |
| Ollama | CLI+常駐サーバー | ollama pull と ollama run で取得から実行まで。localhost:11434でAPIを提供 |
| LM Studio | デスクトップアプリ | GUIでモデルを探して実行。localhostまたはLAN上でOpenAI互換のローカルサーバーとして動かせる(LM Studio Docs 2026-09-27確認) |
| vLLM | 推論サーバー | 同時アクセスの多いサーバー用途向け。筆者は2026年4月までDGX Sparkで使っていた |
llama.cppのREADMEは、目標を「幅広いハードウェアで、最小限のセットアップと最先端の性能でLLM推論を可能にすること」と説明しています。
6. 自分のPCで動くか──必要メモリの見積もり方
必要なメモリは、重みの大きさ、KVキャッシュ、実行バッファなどの合計でおおよそ見積もれます。
$$ \text{必要メモリ} \approx \frac{\text{パラメータ数} \times \text{ビット数}}{8} + \text{KVキャッシュ} + \text{実行バッファ等} $$第1項が重みの理想的なバイト数で、実ファイルは量子化の付帯情報の分だけ大きくなります。第2項は会話が長くなるほど、また同時に処理する数が増えるほど増えます。第3項は計算途中の値を置く領域などで、実行ソフトと設定で変わります。このほかにOSや他のアプリが使う分の空きも見込みます。
重みの見積もりと、Ollamaの実サイズ
Qwen3-8B(8.2Bパラメータ)で計算し、Ollamaの実サイズと比べます。
| 精度 | 計算値 | Ollamaの表示サイズ | 差の理由 |
|---|---|---|---|
| 16ビット | 8.2×16÷8=16.4GB | 16GB(fp16) | ほぼ一致 |
| 8ビット | 8.2×8÷8=8.2GB | 8.9GB(q8_0) | ブロックごとの倍率を別に持つため |
| 4ビット | 8.2×4÷8=4.1GB | 5.2GB(q4_K_M) | ブロックごとの倍率に加え、一部の層を高いビット数で残す混合方式のため |
表示サイズの出典はOllama library qwen3 tags(2026-09-27確認)です。4ビット版は計算値より1GBほど大きくなりました。この例では計算値の約1.27倍(5.2÷4.1)です。ただしこれはQwen3-8B q4_K_Mの1例から見た概算です。上乗せ率は、埋め込み層・出力層の割合(モデル規模で変わり、小型モデルほど大きい)や量子化の種類(q4_0とq4_K_Mなど)で変わるため、他のモデルでは参考値として扱ってください。
KVキャッシュの見積もり
KVキャッシュは、生成済みトークンのKeyとValueを層ごとに保存する領域です。1トークンあたりの大きさは次の式で計算できます。
$$ 2 \times \text{層数} \times \text{KVヘッド数} \times \text{ヘッド次元} \times \text{1要素のバイト数} $$Qwen3-8Bの設定ファイルは、層数36、KVヘッド数8、ヘッド次元128です(config.json 2026-09-27確認)。16ビット(2バイト)で保持すると、1トークンあたり147,456バイト(144KiB)になります。
| コンテキスト長 | KVキャッシュ(Qwen3-8B、同時処理1、FP16の計算値) |
|---|---|
| 4,096トークン | 約0.56GiB |
| 32,768トークン | 約4.5GiB |
| 131,072トークン | 約18GiB(標準の上限を超える。下の注を参照) |
Qwen3-8Bのモデルカードは、コンテキスト長を「32,768 natively and 131,072 tokens with YaRN」としています(設定ファイルの max_position_embeddings は40,960、2026-10-04確認)。131,072トークンの行は、YaRNで拡張した場合の計算例です。
4ビット版の重み5.2GBに32Kトークン分(約4.5GiB≒4.8GB)を足すと、約10GBです。8GBのPCで長い文書を扱うのは厳しいでしょう。16GBなら計算上は6GBほど残りますが、この値には実行バッファやOSの分を含めていないため、実際に載るかは ollama ps などで確認してください。同じ式で32B級のQwen3-32B(64層)を計算すると、1トークンあたり256KiBで8Bの約1.8倍になります(config.json)。
この表は、同時処理1・全層のKVをFP16で持つという条件での理論値です。実行ソフトによってはKVキャッシュも量子化でき、その場合は小さくなります。逆に、同時に処理するリクエストを増やしたり、確保の単位に余白があったりすると大きくなります。
既定のコンテキスト長に注意
Ollamaは、何も設定しないとコンテキスト長をVRAM量で決めます。24GiB未満なら4k、24〜48GiBなら32k、48GiB以上なら256kです(Ollama docs: Context length 2026-09-27確認)。なおFAQページには「既定4096トークン」との記述も残っており、2つのページで書き方が揃っていません。
実際の割り当ては ollama ps の CONTEXT 列で確認できます。PROCESSOR 列は、モデルがGPUとメインメモリのどちらに配置されたかを示します。FAQの説明では「100% GPU」は全体がGPUメモリ、「100% CPU」は全体がメインメモリ、「48%/52% CPU/GPU」のような表示は両方にまたがった状態です(2026-10-04確認)。CPU側の表示はGPUが無い・対応していない場合にも出るため、それだけでメモリ不足とは判断できません。
ollama pull qwen3:8b
ollama run qwen3:8b
ollama ps
OLLAMA_CONTEXT_LENGTH=32768 ollama serve
7. 必要なPCスペックの目安──GPUなしで動くか、Macはどうか
第6節の式で決まるのは「メモリに載るか」です。具体的なモデル名はメモリ量別のおすすめ記事にまとめています。
GPUがなくても動きます。 llama.cppはx86向けに「AVX, AVX2, AVX512 and AMX support」を挙げ、CPUの拡張命令で計算します(GitHub ggml-org/llama.cpp 2026-10-11確認)。Ollamaも、Mac版の動作条件を「Apple M series (CPU and GPU support) or x86 (CPU only)」としています(Ollama docs: macOS 2026-10-11確認)。GPUのVRAMに載りきらない分をCPU側に回すこともできますが、READMEの表現は「partially accelerate」で、全体がGPUに載った状態よりは遅くなります。配置は ollama ps の PROCESSOR 列で確かめます。
生成の速さはメモリ帯域に連動します。 llama.cppの公式リポジトリには、Apple M系チップごとの速度を集めたディスカッションがあります。入力の読み込み(PP)の速さをGPUコア数と、1トークンずつの生成(TG)の速さをメモリ帯域と並べてグラフにしています(題は「PP vs GPU Cores and TG vs Bandwidth」、llama.cpp Discussion #4167 2026-10-11確認)。表では、帯域(GB/s)の大きいチップほど生成が速く、同じチップでは量子化のビット数が少ないほど生成が速い値です。スペック表では、まずメモリ容量(載るか)、次にメモリ帯域(生成の速さ)を見ます。GPUのコア数は、長い文書を読み込ませる用途で効いてきます。
Macは統合メモリをモデルの置き場所に使えます。 AppleはM1の発表で、統合メモリを「a single pool」にまとめ、チップ上の各部が「access the same data without copying it」と説明しています(Apple Newsroom 2020-11-10 2026-10-11確認)。GPU専用メモリが別にあるPCと違い、第6節の式は搭載メモリの総量から考えます。llama.cppのREADMEは「Apple silicon is a first-class citizen」と書き、Metalに対応しています。仕様ページには容量と帯域が並びます。現行のMacBook Airなら「16GB unified memory Configurable to: 24GB or 32GB」「153GB/s memory bandwidth」です(Apple MacBook Air 技術仕様 2026-10-11確認)。容量は購入時に選ぶ構成なので、第6節で出した必要量に余裕を持たせます。筆者はMacでの速度を測っていません。
8. DGX Sparkでの運用記録
筆者はNVIDIA DGX Spark(GB10、CPUとGPUで共有する統合メモリ128GB、aarch64)でローカルLLMを動かしています。今回新たに測ったものではなく、過去の作業記録に残っている値です。
| 条件 | 値 | 単位 | 記録日 |
|---|---|---|---|
| vLLM+Qwen3-32B-NVFP4 の重み | 約20 | GB | 2026-03-15 |
同構成のメモリ予算(gpu-memory-utilization 0.50、128GB×0.50からの計算値) | 約64(重みを除く残り約44) | GB | 2026-03-15 |
| 同構成の生成速度 | 約9.5 | tok/s | 2026-03-15 |
| Ollama qwen3.6:35b-a3b(翻訳・要約・分類用) | 23 | GB | 2026-08-04 |
| Ollama gemma4 26B 4ビット版(Ollama libraryの公表値) | 16〜19 | GB | 2026-09-27確認 |
| Ollama qwen3-next:80b | 50 | GB | 2026-08-04 |
2026-03-15の移行検討メモでは、Qwen3-32B-NVFP4の生成速度を約9.5 tok/sと記録していました(条件を揃えたベンチマークではありません)。gemma4 26B 4ビット版のサイズはOllama library gemma4 tags(2026-09-27確認)の値です。
2026-10-04に筆者環境(Ollama 0.32.0)の ollama list / ollama show を見直しました(モデルのロードはしていません)。qwen3.6:35b-a3b は23GB(36.0B、Q4_K_M)で、記録と同じでした。Ollama library上の現在の標準タグは23〜24GBと表示されています(Ollama library qwen3.6 tags 2026-10-04確認)。gemma4 26Bは、筆者環境では gemma4-qat:26b という登録名で14GB(25.2B、Q4_0)です。公式タグの16〜19GBより小さく、量子化の方式で大きさが変わる例になっています。qwen3-next:80b は2026-10-04時点では筆者環境に登録されておらず、表の50GBは2026-08-04の記録です。
この記録から読み取れることが2つあります。1つ目は、vLLMがモデルを読み込んだ後の残りメモリをKVキャッシュに回すことです。0.50なら128GB×0.50=64GBの予算から重み約20GBを除いた約44GBが残る計算で、実際のKVキャッシュの量は起動時の確保で決まります。0.80のときのメモは「重み約20GB＋KVキャッシュ約76GB＝約96GB」という見積もりでした。128GB×0.80は102.4GBなので、この96GBは実測の占有量ではありません。筆者は、他の用途にメモリを空けるために0.50へ下げました。
2つ目は、筆者の運用で見えたローカルLLMの限界です。筆者はQwen3-32B-NVFP4で記事の下書きを自動生成していました。しかし品質が足りず毎回手直しが必要だったため、2026年4月に記事生成をクラウドのClaude Codeへ移しました。現在は翻訳・要約・分類のように、出力を機械的に検証しやすい作業だけをローカルに任せています。
9. できること・できないこと
| できること | できないこと・難しいこと |
|---|---|
| 機密文書の要約・翻訳を、入力を外部に送らずに行う | ChatGPTやClaudeの最上位モデルそのものを動かす(重みが非公開) |
| ネットワークのない環境でチャットやAPIを使う | 外部とつながらない状態で新しいモデルを入手する(別の端末で取得したファイルを持ち込む方法はある) |
| 利用量を気にせず大量の分類・抽出を回す | 16GB級のPCで70B級を快適に動かす |
| localhostのAPIを自作ツールから呼ぶ | 外部の情報なしで最新ニュースに答える(Web検索を足すと通信が発生) |
| モデルやバージョンを固定し、提供元の更新で挙動が変わるのを避ける(同じ出力の保証には乱数シードや生成設定の固定も要る) | 保守・更新・障害対応を他者に任せる |
向くケース
- 社外秘・個人情報を含む文書を扱い、送信先を手元に限定したい
- 分類・抽出・翻訳のように、出力の形式や正誤を確かめやすい作業が大量にある
- 16GB以上のメモリ、またはGPU付きのPCがすでにある
向かないケース
- 長文の執筆や難しい推論で、最上位モデルの品質が必要(筆者の運用では記事執筆がこれに当たりました)
- 8GB以下のPCで、長い文書を扱いたい
- モデル更新や設定を自分で管理する時間を取れない
10. 費用と商用利用──電気代と機材以外は無料、ただしモデルのライセンスは要確認
手元で推論する分には、トークン数に応じた利用料はかかりません。費用は機材(第6節の必要メモリを満たすPC)と電気代(消費電力×使用時間×電力量料金の単価)です。筆者は推論中の消費電力を測っていないため、金額は出しません。実行ソフトは、Ollamaとllama.cppがMITライセンスです(GitHub ollama/ollama 2026-10-11確認)。第4節のクラウドモデルを選んだ場合の料金は、この記事では確認していません。
商用で使えるかは、モデルの重みのライセンスで決まります。同じ開発元でも世代で条件が変わります。
| モデル | ライセンス | 商用利用に関わる条件(条文の抜粋) |
|---|---|---|
| Qwen3、Gemma 4 | Apache 2.0 | 「perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable」な利用許諾(Qwen3-8B LICENSE) |
| Qwen2.5-72B-Instruct | Qwen License | 「more than 100 million monthly active users」の商用利用は別途許諾(LICENSE) |
| Llama 3.3 | Llama 3.3 Community License | 月間アクティブユーザー「greater than 700 million」は別途許諾。配布時は「Built with Llama」を表示し、Acceptable Use Policyを守る(LICENSE) |
| Gemma 3など | Gemma Terms of Use | 「Gemma Prohibited Use Policy」の禁止用途に使わない(Gemma Terms of Use) |
出典はいずれも2026-10-11確認です。Gemma Terms of Useの冒頭には「For Gemma 4 terms, see the Gemma 4 license」とあり、Gemma 4には適用されません。表示の義務や禁止用途は、事業の規模に関係なくかかります。Hugging Face上では、Qwen2.5-3B-Instructは「qwen-research」という別のライセンス表示です。名前の似たモデルでも、使う版のモデルカードで確かめてください。
11. 向いている用途──コーディング支援、画像生成との組み合わせ、「検閲なし」の意味
コーディング支援。 Ollamaの公式ドキュメントは、ollama launch でコーディングエージェントを選ぶ手順をまとめています(Ollama docs: Integrations 2026-10-11確認)。Claude Codeは「Anthropic-compatible API」経由でつながり、ollama launch claude で起動します。VS CodeはOllama拡張(VS Code 1.127以降)を入れるとチャットでモデルを選べ、拡張は既定で http://127.0.0.1:11434 を見に行きます。OpenClawは、ローカルモデルで使う場合に「at least 64k tokens」のコンテキスト長が推奨です。第6節のとおりOllamaの既定は4kまで下がるため、ollama ps の CONTEXT 列を確かめます。またOpenClawを ollama launch で起動すると同梱のWeb検索が有効になり、第4節の「外に出る」場面に当たります。筆者はローカルモデルでのコーディングの品質を評価していません。
画像・動画生成は別の種類のモデルです。 ローカルLLMは文章を作るモデルで、画像にはFLUX.1やStable Diffusion 3.5のような「text-to-image」のモデルを使います。ライセンスは版で分かれ、Hugging Faceの表示ではFLUX.1 [schnell] がApache 2.0、FLUX.1 [dev] は「flux-1-dev-non-commercial-license」です(FLUX.1-schnell、FLUX.1-dev 2026-10-11確認)。筆者がDGX Sparkで動画生成モデルを動かした記録は動画生成AIをローカルで動かす手順にあります。
「検閲なし(uncensored)」は、拒否を減らすよう学習し直した派生モデルです。 Ollamaのライブラリにある「Llama 2 Uncensored」は「based on Meta’s Llama 2 model」で、Eric Hartford氏のブログの手順で作られたと説明されています(Ollama library llama2-uncensored 2026-10-11確認)。その手順は「Identify and remove as many refusals and biased answers, and keep the rest.」で、絞ったデータで元と同じ方法で学習し直します(Eric Hartford『Uncensored Models』 2026-10-11確認)。拒否を除いても、正確さが増すわけではありません。元のモデルのライセンスは派生物にも及びます。Llama 3.3の契約は派生物(derivative works)を配布する場合にも契約書の添付と「Built with Llama」の表示を求め、Gemma Terms of Useも対象に「Model Derivatives」を含めています。同じブログも「You are responsible for whatever you do with the output of these models」と書いています。日本語向けの派生モデルは一次資料を確認していないため、具体名は挙げません。
よくある質問
ローカルLLMは無料で使えますか
Ollama・LM Studio・llama.cppは無料で使え、Qwen3やGemma 4はApache 2.0で公開されています。手元で推論する分には、モデルのAPI利用料はかかりません。ただし機材と電気代はかかり、メモリが足りなければPCの買い替えが必要です。
費用の内訳とモデルごとの商用利用の条件は第10節にまとめました。
ネットを切っても本当に動きますか
LM Studioは、モデル取得後はオフラインで動作すると公式に明記しています。Ollamaもモデルの取得にはインターネットが要ると説明していますが、取得済みモデルの推論はlocalhostで完結します。筆者は今回、遮断状態での動作を改めて測っていません。
GPUがないPCでも動きますか
llama.cppはCPUだけでも推論でき、VRAMを超えるモデルをCPUとGPUで分担する機能もあります。ただしCPU側に回った分は遅くなります。ollama ps の PROCESSOR 列で、GPUメモリとメインメモリへの配置の割合を確認できます。
GPUのないPCやMacでの動かし方は第7節にまとめました。
量子化すると精度はどれくらい落ちますか
モデルと量子化方式によって変わり、一律の数字はありません。筆者も同じモデルの4ビット版と8ビット版を比べていません。メモリに余裕があれば q8_0 版も取得し、自分の用途の入力で出力を比べるのが確実です。
会社の業務に使っても大丈夫ですか
入力を外部に送らない構成は作れますが、周辺ツールの通信や OLLAMA_HOST の公開設定で崩れることがあります。モデルのライセンスも版ごとに異なるため、開発元のモデルカードで確認してください。出力の正確さは利用者側で検証する必要があります。
ローカルLLMの料金はいくらですか
トークン単位の料金はかかりません。費用は機材と電気代で、手持ちのPCで第6節の必要メモリを満たせば追加の出費はありません(第10節)。
ローカルLLMの欠点は何ですか
性能の上限が手元の機材で決まり、最上位モデルは動かせません(第3節)。保守も自分の担当です。Ollamaの既定のコンテキスト長は4kまで下がることがあります(第6節)。
ローカルLLMは実用的ですか
用途によります。筆者は翻訳・要約・分類にqwen3.6:35b-a3bを使い続けていますが、Qwen3-32B-NVFP4での記事の下書きは品質不足で2026年4月にクラウドへ移しました(第8節)。
商用利用できますか
モデルのライセンスによります。Qwen3やGemma 4はApache 2.0、Llama 3.3は月間アクティブユーザー7億人超で別途許諾などの条件があります(第10節)。
日本語のモデルはどれがいいですか
手元のメモリ量で候補が変わります。ローカルLLMおすすめはメモリ量で決まるで、メモリ帯ごとに整理しています。
構築の手順は
Ollamaの公式クイックスタートでは、macOS・Windows・Linux向けのアプリを入れ、ターミナルで ollama を実行して案内に従います(Ollama docs: Quickstart 2026-10-11確認)。そのあと第6節の ollama pull → ollama run → ollama ps で、取得から配置の確認まで進めます。
関連記事
- ローカルLLMおすすめはメモリ量で決まる ── 8・16・24・32GB以上のメモリ帯ごとに、Ollamaで使える具体的なモデルを絞っています
- Qwen3.8-27Bの推奨4bitが16GBカードに載らない話 ── 量子化後のサイズとGPUメモリの関係を、27B級の実例で扱っています
- Google TurboQuant──KVキャッシュを6倍圧縮 ── この記事で計算したKVキャッシュを小さくする研究を解説しています
- 【DGX Spark実機】動画生成AIをローカルで動かす手順 ── 第11節で触れた動画生成モデル(LTX-2.3)を同じDGX Sparkで動かした記録です
まとめ
- ローカルLLMとは、LLMの推論を自分のPCやサーバーで実行する使い方で、クラウドLLMとの違いは計算する場所と入力の送信先です
- Ollama・LM Studioの公式文書では、推論を手元で完結させる構成なら取得済みモデルとのチャット入力は手元に留まります。モデル取得や更新の確認には通信が要ります
- クラウドモデルの選択、外部ツール連携では入力が外に出ます。待ち受けをネットワークに開くと、手元のAPIを呼べる範囲が広がります
- 必要メモリは「パラメータ数×ビット数÷8＋KVキャッシュ＋実行バッファ等」で見積もれ、Qwen3-8Bの4ビット版なら重みのファイルが5.2GBです
- 検証しやすい大量作業には向き、筆者の運用では最上位モデルの品質が要る記事執筆には向きませんでした