7章 ローカルAI・ローカルLLM・オープンウェイトの基礎：実行環境・評価・注意点
ローカルで生成AIを動かすことは、データを外部サービスへ送らずに試せる可能性や、モデル・実行環境を自分で選べる可能性をもたらします。一方で、モデルのライセンス、ハードウェア、更新、脆弱性、ネットワーク公開、評価を自分または組織で管理する責任が生じます。この章では、用語の違いと安全な選定・評価の方法を学びます。
この章の対象者
- ローカルLLM、ローカルAI、オープンウェイトの違いを整理したい方
- LM Studio、Ollamaなどでローカルモデルを試したい方
- 社内・自宅のPCやサーバーでAIを動かす可能性を検討している方
- モデル・ソフトウェア・ハードウェアを分けて評価したい方
この章でできるようになること
- ローカルAI、ローカルLLM、オープンウェイト、オープンソース、自己ホストを区別できる。
- モデル、実行ソフトウェア、利用画面、実行基盤の役割を説明できる。
- モデルの重み、KVキャッシュ、実行時バッファ、RAM・VRAMの関係を説明できる。
- ローカル実行時のデータ・ネットワーク・ライセンス・更新の注意点を確認できる。
- 小さな検証環境で、性能と安全性を記録しながら評価できる。
7-1. 似た用語を同じ意味で使わない
ローカルLLM、ローカルAI、オープンウェイト、オープンソースなどは、同じ一つの分類ではありません。「どこで動かすか」「何が公開されているか」「誰が運用するか」という別の軸を表す言葉です。
用語の扱い
「ローカルAI」「ローカルLLM」「自己ホスト」は、業界全体で一つに固定された正式用語ではありません。この章では学習・選定のための操作的定義を明示します。権利、ライセンス、公開範囲は、モデルまたはサービスごとの公式資料で判断してください。特に「オープンウェイト」と「オープンソースAI」は同義ではありません。【E8】【E9】
| 用語 | この章での意味 | 根拠・用語の扱い | よくある誤解 |
|---|---|---|---|
| ローカルAI | 利用者のPC、端末、社内環境などで動かすAI全般 | 本章での操作的定義。ローカルモデルの実行・ローカルAPIという実装例はLM StudioとOllamaの公式資料を参照。【E1】【E3】 | LLMだけを指すとは限らない |
| ローカルLLM | LLMの推論を利用者のPCまたは組織管理環境で行う形 | 本章での操作的定義。製品ごとのローカル実行の範囲は公式仕様で確認する。【E1】【E3】 | ライセンスや安全性を保証しない |
| オープンウェイト | 学習済みモデルの重み（パラメータ）を入手・実行できる形で提供すること | Open Source Initiative（OSI）は、重みを利用できることを指す語として説明し、Open Source AIとは区別している。【E8】 | 必ずしもソースコード公開・商用利用可・ローカル実行を意味しない |
| オープンソースAI | 重みだけでなく、コード・学習データに関する情報などを含む公開範囲と利用上の自由を定義した考え方 | OSIの「Open Source AI Definition」に基づく説明。個別モデルがこの定義を満たすかは別途確認する。【E9】 | 重み公開だけで自動的にオープンソースAIになるわけではない |
| 自己ホスト | 個人や組織がサーバー・実行ソフト・アクセス制御を運用すること | 本章での操作的定義。推論サーバーの運用では性能、アクセス制御、監視等を利用者側が管理する。【E6】 | 自動的に安全・低コストになるわけではない |
| オフライン利用 | 推論時に外部通信しない利用形態 | LM Studioは、ダウンロード済みモデルとローカルサーバーはオフラインで動作し得る一方、モデル取得・アプリ更新等には接続を要すると説明している。【E10】 | モデル取得、更新、分析機能などは通信する場合がある |
flowchart TD
A[生成AIの利用形態] --> B[どこで動かすか]
A --> C[何が公開されているか]
A --> D[誰が運用するか]
B --> B1[クラウド / 端末 / 社内サーバー]
C --> C1[重み / ソースコード / ライセンス]
D --> D1[提供者 / 個人 / 組織]重要
「オープンウェイト＝安全」「ローカル＝通信しない」「オープンソース＝商用利用できる」とは限りません。モデルカード、ライセンス、実行ソフトウェアの設定、組織のルールを個別に確認します。
7-2. モデルと実行ソフトウェアを分けて考える
モデルの重みだけでは、通常は対話やAPI提供を行えません。重みを読み込み、ハードウェアを使って推論し、必要に応じて画面やローカルAPIを提供する実行ソフトウェアが必要です。
| 層 | 役割 | 例 |
|---|---|---|
| モデル | 文章・画像などを生成する重みと設定 | オープンウェイトモデル、量子化済みモデル |
| 実行ソフトウェア | モデル読込、推論、GPU利用、API提供 | LM Studio、Ollama、llama.cpp、vLLM |
| 利用画面・連携 | 人やアプリが利用する入口 | チャット画面、ローカルAPI、業務アプリ |
| 実行基盤 | CPU、GPU、メモリ、OS、ドライバ、ネットワーク | PC、ワークステーション、社内サーバー |
| ソフトウェア | 主な位置付け | 導入時に確認すること |
|---|---|---|
| LM Studio | デスクトップでのモデル管理・対話・ローカルAPI | 対応OS・CPU・GPU、モデル保存先、ローカル／ネットワーク公開設定【E1】【E2】 |
| Ollama | ローカルモデル実行とAPI連携のランタイム | ローカルAPIの待受範囲、モデル、クラウド機能、更新方法【E3】 |
| llama.cpp | 軽量なローカル推論、CLI、サーバー実装 | 対応形式、量子化、CPU・GPUバックエンド、サーバー公開設定【E4】【E5】 |
| vLLM | 主にサーバー向けの推論・配信ライブラリ | GPUメモリ、同時利用数、監視、アクセス制御、運用人員【E6】 |
これらは優劣を一律に比較するものではありません。個人の学習、少人数の検証、アプリ連携、複数利用者への提供では、必要な画面、API、性能、運用責任が異なります。
7-3. ハードウェア制約を4種類に分ける
「このモデルは動くか」を判断するには、単にGPUの有無を見るだけでは不十分です。保存容量、メモリ容量、処理性能、互換性を分けて確認します。
| 制約 | 主な確認項目 | 足りない場合に起きること |
|---|---|---|
| ディスク | モデル本体、量子化版、追加部品、更新用の空き容量 | ダウンロード・読込・更新ができない |
| RAM | モデル重み、OS、実行ソフト、CPU側のバッファ | 読込失敗、極端な低速化、OSの不安定化 |
| VRAM | GPUへ載せる重み、KVキャッシュ、実行時バッファ | GPU利用不可、CPUへの退避、速度低下、エラー |
| 演算・帯域 | CPU/GPU/NPU性能、メモリ帯域、ドライバ、冷却 | 初回応答・生成が遅い、長時間利用で不安定 |
必要な実行メモリ
≧ モデル重み
+ KVキャッシュ（文脈長・同時利用数に応じて増加）
+ 実行時バッファ
+ OS・他アプリケーションの余裕モデルファイルのサイズは最低限の目安にすぎません。量子化は、重みを少ないビット数で表現し、保存容量・メモリ使用量を下げる方法です。量子化の種類により、容量、速度、品質、実行ソフトとの対応が変わります。【E4】【E5】
llama.cppの量子化資料では、例としてLlama 3.1のQ4_K_M量子化版は8Bで約4.9GB、70Bで約43.1GBと示されています。ただし実行時にはコンテキストやバッファなどの追加メモリが必要であり、同じモデルでも設定・ソフトウェア・ハードウェアで必要量は変わります。【E4】
互換性の確認
- CPUのみでも実行できる場合がありますが、生成速度はCPU性能・メモリ帯域に大きく左右されます。
- GPUを使う場合は、VRAM容量だけでなく、GPUバックエンド、ドライバ、実行ソフトの対応を確認します。
- Apple Siliconのようなユニファイドメモリ環境では、CPUとGPUが共有するメモリと、他アプリとの競合を考慮します。
- NPUは対応ソフト・対応モデル・量子化形式が限られる場合があります。NPU搭載だけで実行できるとは判断しません。
- LM Studioは、対応OS・CPU・GPUを定め、Windowsでは16GB以上のRAMと4GB以上の専用VRAMを推奨していますが、これはアプリケーションの一般的な目安であり、特定モデルの快適な利用を保証する値ではありません。【E2】
7-4. 性能は実測で評価する
モデルのパラメータ数やGPU名だけで、利用者の体験は決まりません。業務・学習で使う予定の条件を固定し、性能と品質を一緒に実測します。
| 指標 | 意味 | 記録例 |
|---|---|---|
| 初回応答時間 | 送信から最初の文字が出るまでの時間 | 12秒 |
| 生成速度 | 1秒あたりに生成されるトークン数 | 18 tokens/秒 |
| 入力処理速度 | 長い文書を読み始める速さ | 500 tokens/秒 |
| 最大文脈長 | 安定して扱えた入力量 | 8,000 tokens |
| メモリ使用量 | RAM・VRAMの最大使用量 | RAM 13GB、VRAM 7GB |
| 同時利用数 | 品質・速度を保てた利用者数 | 1人、または3人 |
| 品質 | 正答率、引用の適合、修正量 | テスト20問中17問合格 |
評価手順
- 用途を一つに固定する。例：要約、社内文書検索、コード補助。
- モデル名、版、量子化、実行ソフト、コンテキスト長、設定を記録する。
- 個人情報・機密情報を含まない、正解を確認できるテストデータを用意する。
- 速度だけでなく、誤り、根拠、修正量、資源使用量を測る。
- 長文入力、他アプリ利用、複数利用者を想定して余裕を確認する。
- 性能が高くても、ライセンス・安全性・運用体制を満たさなければ採用しない。
7-5. ローカル実行でも確認するデータ処理と通信
ローカル推論は、入力が必ず外部へ送信されないことを保証する言葉ではありません。モデルのダウンロード、更新確認、クラウド連携、利用統計、ネットワーク公開、外部ツール利用などが設定されている場合があります。
| 確認項目 | 具体的に見ること |
|---|---|
| 通信 | モデル取得・更新・分析・クラウド機能でどこへ通信するか |
| 待受範囲 | APIがlocalhostだけか、LANやインターネットへ公開されるか |
| ファイル権限 | モデルやツールが読めるフォルダ、書き込める場所はどこか |
| 外部ツール | Web検索、ファイル操作、メール、コマンド実行の権限があるか |
| モデル配布元 | 公式配布元、ハッシュ、署名、モデルカード、ライセンスを確認したか |
| 更新 | 実行ソフト、モデル、ドライバ、依存関係の更新担当者と確認方法 |
LM Studioはローカルだけでなくネットワーク上でもAPIを提供でき、OllamaはローカルAPIとクラウドモデルのAPIを扱えます。利用前に、実際の待受設定と通信先を確認します。【E1】【E3】
ローカル実行でも、ハルシネーション、偏り、著作権、脆弱性、プロンプトインジェクション、誤った出力の実行といったリスクは残ります。自己管理する場合は、更新、アクセス制御、ログ、インシデント対応も自分または組織の責任になります。【E7】
7-6. ミニ演習：ローカルLLM検証計画を作る
次の条件で、導入前の検証計画を作成します。
# ローカルLLM検証計画
## 目的
公開済みの社内研修資料を要約する下書きを作る。
## 利用者と入力
- 利用者：まずは研修担当者1名
- 入力：公開済み資料と匿名化済みの練習文書だけ
## 禁止事項
- 個人情報
- 未公開資料
- 外部ネットワークへのAPI公開
## 評価期間
2週間検証時にLLMへ渡す依頼も、同じMarkdown形式で「対象資料」「してよいこと」「しないこと」「期待する出力」「確認方法」を分けます。構造化しても入力禁止情報の制御やネットワーク設定は自動化されないため、別途確認します。【E7】
| 項目 | 記入内容 |
|---|---|
| 候補モデル | 名称、版、量子化、ライセンス、配布元 |
| 実行環境 | PC/サーバー、OS、CPU、GPU、RAM、VRAM、ディスク空き容量 |
| 実行ソフト | 名称、版、入手元、待受設定、更新方法 |
| テスト | 文書数、期待する出力、正確性・速度の合格基準 |
| 安全策 | 入力禁止情報、ネットワーク、権限、ログ、削除方法 |
| 責任者 | 実行者、確認者、更新担当、相談先 |
| 中止条件 | 誤情報、漏えい、性能不足、ライセンス不適合など |
振り返り
- 「モデル」「実行ソフト」「ハードウェア」「運用」のどれに制約があるか。
- モデルファイルのサイズ以外に、どのメモリを見積もる必要があるか。
- ローカル環境が外部通信・ネットワーク公開をしないことを、どのように確認するか。
- 性能だけでなく、ライセンスとデータ保護を確認できているか。
まとめ
- ローカルAI、ローカルLLM、オープンウェイト、オープンソース、自己ホストは別の軸の概念である。
- モデルを利用するには、実行ソフトウェア、利用画面、ハードウェア、運用設定が必要である。
- 必要容量は、モデル重みだけでなく、KVキャッシュ、実行時バッファ、OSの余裕を含めて見積もる。
- 量子化は容量を減らすが、品質・速度・互換性とのトレードオフがある。
- ローカル実行でも、通信、ネットワーク公開、ライセンス、更新、AI固有のリスクを確認する。
- 導入前に、安全なテストデータで性能・品質・安全性を実測する。
次の学習
次は、第8章「AIエージェントとMCP」で、生成AIから外部のデータやツールへ安全に接続する考え方と、読み取り専用MCPサーバーの作成方法を学びます。その後、用途別の特集として「生成AIサービスの全体像」「国外提供生成AIの評価」「RAG構築」「AIセキュリティ」「ローカルLLMの実装・運用」を学ぶと、より専門的な活用へ進めます。
出典・エビデンス
| 本文の対象 | 根拠資料 | 確認した内容 |
|---|---|---|
| ローカル・オープン関連用語 | 【E1】【E3】【E8】【E9】【E10】 | ローカル実行の例、オープンウェイトとOpen Source AIの区別、オフライン運用時にも通信が必要となる操作 |
| LM Studioのローカル・ネットワークAPI提供 | 【E1】 | LM Studioがlocalhostまたはネットワーク上でAPIサーバーを提供できること |
| LM Studioの対応環境・推奨値 | 【E2】 | OS・CPU・GPUの対応、RAM・VRAMに関する一般的な推奨 |
| Ollamaのローカル／クラウドAPI | 【E3】 | ローカルAPIとクラウドAPIの提供形態 |
| 量子化とモデル容量 | 【E4】 | 量子化、モデルサイズ、メモリ・ディスク要件の例 |
| llama.cppの対応ハードウェア・量子化 | 【E5】 | 複数バックエンド、量子化、CPU＋GPU推論の対応 |
| vLLMの推論・配信用途 | 【E6】 | LLMの推論・サービング向けライブラリであること |
| 生成AIのリスク管理 | 【E7】 | 信頼性、安全性、セキュリティ等を含む生成AIリスクの管理 |
- 【E1】 LM Studio, *LM Studio as a Local LLM API Server*
https://lmstudio.ai/docs/developer/core/server
- 【E2】 LM Studio, *System Requirements*
https://www.lmstudio.ai/docs/app/system-requirements
- 【E3】 Ollama, *Introduction*
https://docs.ollama.com/api/introduction
- 【E4】 llama.cpp, *Quantize the GGUF — Memory/Disk Requirements*
https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md
- 【E5】 llama.cpp, *README*
https://github.com/ggml-org/llama.cpp/blob/master/README.md
- 【E6】 vLLM, *Documentation*
https://docs.vllm.ai/en/stable/
- 【E7】 NIST, *Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile*（NIST AI 600-1、2024年7月26日）
https://doi.org/10.6028/NIST.AI.600-1
- 【E8】 Open Source Initiative, *Open Weights: not quite what you've been told*
https://opensource.org/ai/open-weights
- 【E9】 Open Source Initiative, *The Open Source AI Definition — 1.0*
https://opensource.org/ai/open-source-ai-definition
- 【E10】 LM Studio, *Offline Operation*
https://lmstudio.ai/docs/app/offline
参照日：2026年7月14日。モデル、実行ソフトウェア、ドライバ、ライセンス、対応ハードウェアは更新されるため、導入・公開前に各公式資料を再確認してください。