ローカルLLM運用ガイド Ollama×llama.cpp 2026

1. なぜいま「ローカルLLM × AIエージェント」なのか

クラウド API のみで AIエージェントを構築するアプローチは、PoC や小規模運用では最適解です。ただ、ある段階を超えると 3 つの制約に当たります。

• 機密データの越境:契約書、人事評価、医療記録、設計図面など、社外送信が禁止または強い慎重さを要求される情報を、エージェントの会話履歴・ツール呼び出しの入出力に乗せざるを得なくなる。
• コスト構造の硬直化:トークン単価は確かに下がり続けていますが、エージェントは 1 タスクで数万トークンを消費することが珍しくなく、本数が増えると月額が階段状に上がる。
• レイテンシと可用性:エンドポイントの停止・レート制限・地理的なレイテンシが、業務クリティカルなフローのボトルネックになる。

ローカルLLMはこの 3 点に対する「逃げ道」を作る選択肢になります。重要なのは「全部ローカルに置き換える」ことではなく、機密度と難易度でモデルを使い分けるハイブリッド構成を取れるようになる、という点です。

「ローカル」の 3 レイヤー

一口にローカルLLMと言っても、実際には次の 3 つのレイヤーが混在します。

1. 開発者の手元(MacBook / RTX 4090 ワークステーション):プロトタイピング、評価、小規模なオフライン推論。
2. 社内オンプレ GPU サーバ(H100 / A100 / L40S):本番の推論ワーカー。バッチ・並列・常時稼働。
3. VPC 内クラウド GPU(AWS g5/g6・GCP a3・Azure NDv5):外部 API を呼ばずに済む「自社管理下のクラウド」。物理的にはクラウドだが、ネットワーク境界としてはローカル扱い。

Ollama は 1. と 2. の両方で軽く扱える層、llama.cpp はその下層エンジン、というのが本稿の前提です。

2. Ollama と llama.cpp の役割分担

結論から書くと、Ollama は llama.cpp の上に乗ったランタイム+モデル管理のラッパーです。Ollama 公式リポジトリ(ollama/ollama)も「llama.cpp をエンジンとして利用している」と明記しています(2026年5月時点)。

項目	llama.cpp	Ollama
レイヤー	推論エンジン(C/C++)	モデル管理 + API サーバ(Go)
主要バイナリ	llama-cli / llama-server	ollama / ollama serve
モデル形式	GGUF	GGUF(独自のレジストリ経由)
API	OpenAI 互換 + 独自	OpenAI 互換 + 独自(/api/chat 等)
主な利用層	研究者・組み込み・性能チューニング層	アプリ開発者・PoC・社内サービス
運用の手間	パラメータ管理を自分でやる	Modelfile で一括管理

「Ollama でやれることは llama.cpp でもやれる」と言って間違いではありません。ただし、llama.cpp で本番運用すると、モデル ID 管理、テンプレート管理、システムプロンプト管理、コンテキスト長設定、量子化レベルのバージョニングを自前で組み立てる必要が出てきます。Ollama はこれらを Modelfile という宣言的な記法でまとめてくれる、という関係です。

使い分けの判断軸

• Ollama を使う:複数モデルを差し替えて評価したい / 同一サーバで複数モデルを同時に提供したい / OpenAI 互換 API でアプリと繋ぎたい / 運用者がアプリ寄り。
• llama.cpp を直接使う:CPU/GPU レイヤーでチューニングしたい / バッチ推論を極限まで高速化したい / Embeddings 専用サーバなど用途を絞った最適化をしたい / RAG パイプラインで独自実装と密結合したい。

3. Ollama セットアップ:5 分でエージェントが叩ける状態にする

ここからは、開発機(macOS / Linux)で Ollama を立ち上げ、AIエージェント用に OpenAI 互換 API として晒すまでを 5 ステップで整理します。

3-1. インストール

# macOS / Linux
curl -fsSL https://ollama.com/install.sh | sh

# 起動確認
ollama --version
# ollama version 0.5.x など

# サーバを起動(デフォルトで 127.0.0.1:11434 にバインド)
ollama serve &

Windows は公式インストーラ(ollama.com/download)、Docker 利用時は ollama/ollama イメージを使います。

3-2. モデルの取得

# Llama 3.3 70B (Llama 4 系列の主要モデルのひとつ。Q4_K_M 量子化が既定)
ollama pull llama3.3

# Qwen3 8B Instruct
ollama pull qwen3:8b

# 軽量・コード特化
ollama pull qwen2.5-coder:7b

# 確認
ollama list

モデル名は Ollama 公式ライブラリ(ollama.com/library)の表記に従ってください。タグなしでは既定の量子化(多くは Q4_K_M)が降ってきます。

3-3. ローカル実行

# 単発推論
ollama run llama3.3 "AIエージェントのプランナー層で気をつけるべきことを3つ挙げて"

# REST API 経由(エージェントから叩く想定)
curl http://localhost:11434/api/chat -d '{
  "model": "llama3.3",
  "messages": [
    {"role": "system", "content": "あなたはAIエージェントの設計レビュワーです"},
    {"role": "user", "content": "ReActループでよくある失敗を1つ教えて"}
  ],
  "stream": false
}'

3-4. OpenAI 互換 API として使う

2026年5月時点の Ollama は、/v1/chat/completions として OpenAI 互換のエンドポイントを提供しています。OpenAI SDK / LangChain / LlamaIndex / Anthropic ベースの自前エージェントを最小変更で繋げます。

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # ダミーで可
)

resp = client.chat.completions.create(
    model="llama3.3",
    messages=[
        {"role": "system", "content": "あなたは厳密なJSONだけを返す関数です。"},
        {"role": "user", "content": "次の文を意図(intent)とエンティティ(entities)に分解: 来週の月曜10時に田中さんと打ち合わせを設定して"}
    ],
    temperature=0.1
)
print(resp.choices[0].message.content)

3-5. Modelfile でエージェント用に固定化する

本番運用では、システムプロンプト・温度・コンテキスト長・stop シーケンスを宣言的に固定したくなります。Ollama では Modelfile を書いてベースモデルから派生モデルを作れます。

# Modelfile.agent-planner
FROM llama3.3

PARAMETER temperature 0.2
PARAMETER num_ctx 16384
PARAMETER repeat_penalty 1.05
PARAMETER stop ""

SYSTEM """
あなたは AIエージェントのプランナーです。出力は必ず以下のJSONスキーマに従ってください。
{ "thought": string, "next_action": "tool" | "answer", "tool_name": string | null, "tool_args": object | null }
"""

ollama create agent-planner -f Modelfile.agent-planner
ollama run agent-planner "請求書PDFから合計金額を抽出して"

この派生モデルを、エージェントのプランナー層 / ツール選択層 / 要約層と用途別に作っておくと、同じベースモデルから複数の役割を同居させやすくなります。

4. モデル選定:Llama 4 / Qwen3 / Mistral のどれを選ぶか

2026年5月時点で「AIエージェントの実用ローカルモデル」と言える主要系列を整理します。すべて Hugging Face / 公式アナウンスベースで、ベンチマーク数値の引用は本稿では避け、用途と特徴に絞ります(ベンチマークは数ヶ月で陳腐化するため)。

Llama 4 系(Meta)

• 立ち位置:Meta のオープンウェイトフラッグシップ。長文・推論・コードを総合的にカバー。Llama 4 Scout / Llama 4 Maverick など複数サイズがリリースされている(Meta 公式 ai.meta.com)。
• 得意:汎用性、英語の知識、ロングコンテキスト。
• 不得意:日本語のニュアンス(タスク次第。日本語ファインチューン版を使うのが現実解)。
• 注意点:Acceptable Use Policy と Llama Community License の遵守が前提。商用利用条件・ユーザ数閾値を必ず読む。

Qwen3 系(Alibaba)

• 立ち位置:Hugging Face で公開されているオープンウェイト群。Qwen3-8B / 14B / 32B / 72B など複数サイズ + コード特化(qwen2.5-coder の系譜)。
• 得意:中国語と英語、関数呼び出し / ツールユースのテンプレート対応、コード生成。
• 不得意:日本語ライティングのトーン。ただし指示追従性が高く、システムプロンプトで矯正しやすい。
• 備考:Hugging Face の Qwen 公式 org(Qwen) を一次ソースとし、サードパーティの GGUF 量子化版を使う場合は配布者の信頼性をチェック。

Mistral 系

• 立ち位置:7B クラスのバランス型、Mixtral 系の MoE(Mixture of Experts)、コード特化の Codestral など。
• 得意:推論コストあたりの応答品質。エッジに置きやすい 7B クラスの完成度。
• 不得意:純粋なパラメータ数勝負だと Llama 4 / Qwen3 のフラッグシップに見劣りする領域がある。
• 備考:ライセンスはモデルごとに異なる(Apache-2.0 / Mistral 独自ライセンス)ので個別確認必須。

選定の意思決定表

要件	第一候補	第二候補
日本語ナレッジQ&A・要約	Llama 4 / Qwen3 の日本語ファインチューン版	Qwen3 32B 素
コード生成・コードリファクタ	Qwen2.5-Coder / Codestral	Llama 4 系
ツールユース(関数呼び出し)	Qwen3(関数呼び出しテンプレが安定)	Llama 4
低レイテンシ・エッジ	Mistral 7B / Qwen3 8B	Llama 3.1 8B
本格的な推論・長文	Llama 4 Maverick クラス / Qwen3 72B	Mixtral 系

5. 量子化:Q4 / Q5 / Q8 / BF16 のトレードオフ

量子化はローカルLLM運用の最重要パラメータです。同じモデルでも量子化レベルでメモリ消費・推論速度・出力品質が大きく変わります。GGUF 形式における主要な量子化レベルを実用観点で整理します(以下のサイズは Hugging Face で配布される代表的な GGUF を参照した目安値で、配布元によりブレがあります)。

量子化	1パラメータあたりbit目安	70Bモデルのサイズ目安	品質感	用途
BF16 / F16	16 bit	約 140 GB	劣化ほぼなし	学術評価・H100 複数枚での本番
Q8_0	約 8 bit	約 70 GB	ほぼ無損失と言われる帯	A100 80GB × 1 で 70B を走らせたい場合
Q6_K	約 6.5 bit	約 56 GB	体感差は限定的	L40S 48GB ×1 をやや工夫
Q5_K_M	約 5.5 bit	約 48 GB	軽微な劣化	RTX 6000 Ada 48GB
Q4_K_M	約 4.5 bit	約 40 GB	用途次第で許容	RTX 4090 24GB ×2 / L40S 48GB
Q3_K_S / Q2_K	3 bit 以下	約 26-32 GB	明確な劣化	非常設・実験用

量子化を選ぶときの実務ルール

1. 「動く一番大きいモデル」より「品質を確保できる量子化」。70B Q2_K より 32B Q5_K_M のほうがエージェント用途では結果が良いことが多い。
2. ツールユース・関数呼び出し用途は Q4 以下を避ける。JSON スキーマ遵守や関数名生成の精度が落ちやすい。
3. 要約・分類など出力スキーマが緩いタスクは Q4_K_M で十分。
4. 埋め込み(Embeddings)モデルは原則として Q8 以上。検索品質に直結。
5. 同じ量子化名でも配布者(unsloth / bartowski / 公式)で微妙にレシピが違う。本番では配布者を固定し、ハッシュをロックする。

llama.cpp での量子化検証コマンド例

# 例:Hugging Face で取得したGGUFを起動し、KVキャッシュ含めVRAM使用量を観察
./llama-server 
  --model ./models/llama-3.3-70b-instruct-Q5_K_M.gguf 
  --n-gpu-layers 999 
  --ctx-size 16384 
  --parallel 4 
  --port 8080

GPU メモリが溢れる場合、まず --ctx-size を下げる、次に --parallel を下げる、最後に量子化を 1 段落とす、の順で対処します。--n-gpu-layers を低くして CPU オフロードする方法もありますが、AIエージェントのインタラクティブ用途ではトークン/秒が一気に落ちるため非推奨です。

6. GPU / CPU 推論:スループットと現実的なサーバ要件

「ローカルLLM はノート PC でも動く」のは事実ですが、AIエージェントの基盤としての実用性はサーバ要件で決まります。代表的な構成パターンを整理します(数値は公開されている各種ベンチ・実測レポート・llama.cpp / Ollama 公式 GitHub の議論を踏まえた一般的な目安レンジで、具体的なtok/sの保証ではありません)。

構成	主用途	推論速度目安	適合モデル
MacBook Pro (M3 Max 64GB)	個人開発・PoC	30-50 tok/s(8-13B Q4)	Llama 3.1 8B / Qwen3 8B / Mistral 7B
RTX 4090 24GB ×1	個人ハイエンド・小規模社内	40-80 tok/s(8-14B Q4-Q5)	14B 以下、または 30B Q4
L40S 48GB ×1	社内チーム本番(10-50ユーザ)	30-60 tok/s(32B-70B Q4)	32B Q5 / 70B Q4
A100 80GB ×1	本番(50-200ユーザ)	40-70 tok/s(70B Q5-Q8)	70B Q8 まで
H100 80GB ×2-4	本番(200+ユーザ / 並列ワーカー)	50-100 tok/s 以上(並列前提)	70B BF16 / Llama 4 系
CPU のみ(Xeon/EPYC 32コア+)	バッチ・非対話 / 緊急代替	2-8 tok/s	13B 以下 Q4

サーバ要件の決め方

1. 同時利用ユーザ数 × 平均トークン/秒要件を見積もる。エージェントはツール呼び出しの待ち時間があるため、人間チャットほどスループット要件は厳しくない場合が多い。
2. 1 リクエストあたりのコンテキスト長を決める。8K と 32K では KV キャッシュのメモリ消費が桁で違う。
3. 「主モデル + サブモデル」を 1 台に同居させるかを決める。Ollama は同居がしやすいが、ピーク時に VRAM を奪い合うので、本番ワーカーは 1 モデル専有が原則。
4. フェイルオーバー先を Anthropic / OpenAI API に置くか、別のローカルGPUに置くかを設計する。

7. Anthropic / OpenAI API との使い分け方

本稿の前提は「全部ローカル」ではなく「適切にハイブリッド」です。Anthropic 公式は Claude 各モデルの能力と価格、OpenAI 公式は GPT 系列の能力と価格を公開しており、2026年時点でも単純なテキスト品質・関数呼び出し精度・最新知識のカバレッジは、フラッグシップのクラウドAPIモデルが優位な領域が多いです。

使い分けの設計指針

• 機密データの境界で分岐する:データそのものがローカルから出てはいけないなら、そのタスクは無条件でローカルLLM。
• 難易度で分岐する:複雑な推論・長い計画・コード設計はクラウドAPI(Claude / GPT)、定型タスク・要約・分類・関数呼び出しの第一段はローカル。
• コストで分岐する:単純で量が多いタスク(分類、抽出、要約、メタデータ生成)をローカルに移し、高単価なクラウドAPIを「考える」タスクに集中させる。
• SLAで分岐する:クラウドAPIが落ちた / レート制限に当たった瞬間に、ローカルにフォールバックできるよう、抽象化レイヤーを 1 枚挟んでおく。

典型的なハイブリッド構成例

[ユーザ入力]
    ↓
[ルータ層(分類: ローカルLLM 8B)]
    ↓
  ├─ 機密・大量 → [ローカル 32B-70B(Ollama)] → ツール実行 → 結果
  └─ 高難度・少量 → [Claude / GPT API] → ツール実行 → 結果
    ↓
[要約・後処理(ローカル 8B)] → ユーザ応答

ルータ層と後処理層をローカルに置くだけで、クラウドAPI トラフィックは半減することがあります。エージェントは「最終応答 1 回」だけでなく「内部の小さな LLM 呼び出しが何十回も走る」アーキテクチャになりやすいため、内部呼び出しをローカルに寄せるのが第一手です。

AIエージェント全体のコスト最適化観点は AIエージェントのコスト最適化:7原則と具体的削減手法 も合わせて参考にしてください。

8. オンプレ運用前提の機密データフロー

「ローカルLLMを採用する=安全」ではありません。むしろ、運用者の責任範囲が広がるので、設計を間違えると逆にリスクが上がります。最低限抑えるべき項目を整理します。

ネットワーク設計

• Ollama / llama.cpp サーバは 127.0.0.1 もしくは社内VPN内部からのみ到達可能にする。デフォルトの 11434 / 8080 を公開ネットワークに開けない。
• VPC 内クラウド GPU を使う場合、エグレス先を最小化する(モデルダウンロード時のみ ollama.com / huggingface.co を許可、それ以外は閉じる)。
• ハイブリッド構成のクラウドAPI 側にも、データ送信前に PII / 機密マスキングをかけるレイヤーを噛ませる。

ログ・観測性

• プロンプト・補完を全部生で保存しない。長期保存はメタデータ(トークン数・モデル名・レイテンシ・呼び出し元エージェント)に絞る。
• 失敗ケースだけサンプリングして詳細ログを残す方針が現実的。
• 本番のローカルLLMはバージョン+量子化+ハッシュをセットで記録し、再現性を担保する。

AIエージェントの本番監視全般は AIエージェントのSRE実装ガイド:本番運用とモニタリング に詳しくまとめています。ローカルLLM運用の場合、外部APIにない GPU 利用率 / VRAM 残量 / モデルプロセスのクラッシュリカバリといった指標が追加で必要になります。

RAG パイプラインとの結合

機密データを扱うエージェントは、必然的に Retrieval-Augmented Generation(RAG)パイプラインを内側に抱えます。埋め込みモデル(例:bge-m3、nomic-embed-text、Qwen3-Embedding 等)をローカルで動かし、ベクトルDB も社内に置くのが基本構成です。RAG パターンの整理は Agentic RAG 4パターン比較:エージェント型検索拡張の選び方 を参照してください。

9. コスト試算:ハイブリッド構成で月いくらか

仮の本番ユースケース(社内ナレッジ Q&A エージェント、利用者 100 名、1 日 1 人あたり 30 回呼び出し、1 回平均 5,000 入力トークン + 1,000 出力トークン)を、3 構成で並べてみます。

前提:

• 営業日 20 日/月 → 月 60,000 回呼び出し、月 3 億入力トークン + 6,000 万出力トークン。
• クラウドAPI 単価は概算で、入出力ともに 1M トークンあたり数百円〜数千円のレンジ(モデル・時期で変動。最新は Anthropic / OpenAI 公式の料金ページで要確認)。
• GPU サーバは社内 L40S 48GB ×1 を 1 台、月額 30〜50 万円相当でレンタル(VPC GPU・社内オンプレ運用人件費・電源を含むラフな目安)。

構成	主モデル	月額レンジ目安	備考
クラウドAPI フル	Claude / GPT のミドル〜上位	数十万〜100万円超	呼び出し回数増加で青天井
ローカルLLM フル	32B Q5 ローカル	30-60 万円(GPU 固定費)	難タスクで品質劣化リスク
ハイブリッド(80% ローカル / 20% クラウド)	32B ローカル + Claude 上位	40-70 万円	品質と上限コストの両立。多くのケースで現実解

重要なのは絶対額ではなく、「クラウドAPI フルは呼び出し回数で上限が見えないが、ローカル/ハイブリッドはほぼ固定費に近づく」という構造です。エージェント運用が拡大するほど、ハイブリッド構成の経済性が効いてきます。

10. 本番運用でハマりやすい課題と対処

PoC が動いた後、本番化フェーズで頻発する課題を整理します。

10-1. KV キャッシュで VRAM が突然溢れる

コンテキスト長 × 並列リクエスト数で KV キャッシュは線形に増えます。「単発では動くのに本番ピークで OOM」のほぼ全例がこれ。対処は --ctx-size を 8K / 16K に絞る、--parallel をワーカー数ベースに調整する、必要なら flash-attn / KV キャッシュ量子化(Q4 cache)を有効化する。

10-2. 関数呼び出しの JSON が壊れる

低量子化 + 短いシステムプロンプトでよく起きます。対処は (1) 量子化を Q5_K_M 以上に上げる、(2) Outline / JSON Schema 強制(llama.cpp の --grammar / Ollama の format オプション)を使う、(3) 関数呼び出しテンプレが整備されている Qwen3 系に切り替える。

10-3. 同時実行でレイテンシが劣化する

Ollama は OLLAMA_NUM_PARALLEL / OLLAMA_MAX_LOADED_MODELS で挙動を制御できます。1 GPU に複数モデルをロードするとピーク時に押し出しが起き、コールドスタートで応答が一気に遅くなります。本番は 1 GPU 1 モデルが原則。

10-4. モデルの差し替えで品質が静かに劣化する

同じ「llama3.3」タグでも、配布者・量子化レシピ・テンプレ・Ollama 側のデフォルト変更で挙動が動きます。本番ではモデルのハッシュとバージョンをロックし、回帰テスト(代表 100 プロンプト程度のゴールデンセット)を CI で回す。

10-5. ライセンス・利用規約

Llama Community License は MAU 7 億超でライセンス申請が必要、商用利用条件あり。Qwen / Mistral も個別ライセンスを持つ。「オープン=自由」ではない。法務確認は省略しないでください。

10-6. 起動時間と GPU プリウォーム

大きいモデルは初回ロードに数十秒〜数分かかります。冷起動でユーザを待たせない設計(常時 1 つ以上のワーカーを温めておく / ヘルスチェックでロード状況を見る)が必要です。

11. 評価とゴールデンセット運用

ローカルLLM を本番に置く以上、外部評価ベンチマークだけに頼るのは危険です。社内ユースケースに合わせたゴールデンセットを最低 100-300 件用意し、(1) モデル変更時、(2) 量子化変更時、(3) システムプロンプト変更時、(4) Ollama / llama.cpp バージョンアップ時 に必ず回します。

• 項目例:意図分類精度、JSON スキーマ遵守率、ツール選択正解率、要約の事実性、回答の参照漏れ。
• 採点は「人間 1 名 + 上位クラウドAPI 1 名(自動採点)」のダブルチェックが現実解。完全自動採点だけだと採点モデル自体のバイアスが乗る。
• 「Claude / GPT に勝つ」ことを目標にせず、「自社タスクで許容ライン以上」を基準にする。

12. llama.cpp を直接使うべき具体ケース

「Ollama で全部済むなら llama.cpp は触らなくてよいのでは」と思われがちですが、本番運用では llama.cpp を直接使うべき場面が一定割合で出てきます。代表的なものを整理します。

12-1. バッチ推論を最大化したい

夜間バッチで数十万件のドキュメント要約・分類を回すケース。Ollama の REST API 経由でリクエストを並べると、内部のキューイングや HTTP オーバーヘッドが効いてきます。llama.cpp の llama-batched / llama-parallel を使うと、同一プロンプト群を効率的に並列展開でき、GPU 利用率が引き上げられます。

12-2. 埋め込み(Embeddings)専用サーバを立てたい

RAG パイプラインでは、検索用の埋め込みサーバを生成用 LLM とは別マシンに分離するのが定石です。llama-server --embedding モードでテキスト埋め込み専用のエンドポイントを立て、生成側の Ollama とは別 GPU(あるいは同一 GPU 内で VRAM を切る)で運用すると、検索品質と生成のレイテンシを両立できます。

12-3. CPU 推論を本気でチューニングしたい

GPU が用意できない / バッチで夜間に CPU を遊ばせるサーバがある場合、llama.cpp の AVX-512 / AMX / OpenBLAS / BLIS 最適化、量子化 KV キャッシュ、speculative decoding などを使い倒すと、Xeon/EPYC 32-64 コアでも 13B Q4 を 5-10 tok/s 帯に乗せられます。Ollama でもオフロード経由で CPU を使えますが、極限のチューニングは llama.cpp 直叩きが向きます。

12-4. 組み込み・エッジに乗せたい

Jetson Orin、Apple Silicon の Metal バックエンド、Raspberry Pi 5、Intel NUC など、限定的なハードに置く場合は llama.cpp が第一選択です。Ollama も対応しますが、軽量さ・依存の少なさで勝負するならエンジン直接。

13. セキュリティ:プロンプトインジェクションとモデル盗用

ローカルLLM だからといってセキュリティ脅威がなくなるわけではありません。むしろ「自社運用」前提でガードを内製する必要があります。

13-1. プロンプトインジェクション

RAG で社内文書を取り込むと、悪意あるユーザが投稿した文書経由でエージェントの指示を奪われるリスクが残ります。対策は、(1) システムプロンプトをユーザ入力より「強い」位置に置く構造設計、(2) ツール実行前の人間承認ゲート、(3) 出力に対する別モデルでのガードレール検証、の組み合わせ。ローカルLLM だから安全、ではなく、責任主体が自社になるぶん設計責任は重くなります。

13-2. モデル盗用・抽出攻撃

API として社内に公開すると、内部からモデル出力を大量サンプリングして外部に持ち出す攻撃ベクトルが理論上存在します。レート制限・監査ログ・ファインチューンしたカスタムモデルの取り扱いポリシーが必要。

13-3. サプライチェーン

Hugging Face で配布される GGUF ファイルは、配布者が量子化した時点で内容が変わります。本番では (1) 公式 Ollama ライブラリ、(2) 有名な再配布者(unsloth、bartowski 等)、(3) 自社で再量子化、のいずれかに絞り、ハッシュ検証を必須にしてください。Hugging Face の各モデルカードに記載のチェックサムは、本番運用での最低限の検証ラインです。

14. これから始める人への現実的なロードマップ

最後に、ローカルLLM × AIエージェントを段階的に立ち上げる順序を整理します。

1. Week 0-1:Ollama を 1 台のワークステーションに入れて、Llama 3.1 8B / Qwen3 8B / Mistral 7B を触る。同じプロンプトでの挙動差を体感する。
2. Week 2-3:OpenAI 互換 API として既存エージェントから叩く。クラウドAPI と同じインタフェースで動くことを確認。
3. Week 4-6:1 つのサブタスク(分類 or 要約)だけをローカルに切り出す。コストとレイテンシをモニタする。
4. Month 2:GPU サーバ(L40S 48GB クラス)を確保し、32B クラスに引き上げる。ゴールデンセット 100 件で回帰テストを CI に組む。
5. Month 3-:ハイブリッド構成(ルータ層 + ローカルメイン + クラウドAPI 上位フォールバック)を本番化。観測性・ログマスキング・ライセンス確認を完了させる。

「一気に全部ローカル」を狙わず、サブタスク単位で段階的にローカル化していくのが、品質低下リスクを最小化しつつコストと機密性を改善する最短ルートです。

まとめ

• Ollama は llama.cpp の上に乗ったランタイム + モデル管理層。多くの社内ユースケースは Ollama で十分始められる。
• モデル選定は「フラッグシップ最大サイズ」より「タスクと量子化を合わせる」発想。ツールユース重視なら Qwen3、汎用は Llama 4、軽量・エッジは Mistral 7B。
• 量子化は Q5_K_M を本番の基本線に、JSON 出力や関数呼び出しでは Q4 を避ける。配布者とハッシュを固定する。
• クラウドAPI を捨てる必要はない。機密度・難易度・コスト・SLA で動的に切り分けるハイブリッド構成が現実解。
• 本番運用は KV キャッシュ・量子化・ライセンス・ゴールデンセット評価が肝。「動いた」と「運用できる」の間にあるギャップを甘く見ない。

著者:佐藤傑(さとう・すぐる)。株式会社Uravation 代表取締役。X(@SuguruKun_ai)フォロワー約10万人。著書『AIエージェント仕事術』。

主な参照ソース:Ollama 公式(ollama.com / github.com/ollama/ollama)、llama.cpp(github.com/ggerganov/llama.cpp)、Hugging Face(huggingface.co)、Meta AI(ai.meta.com)、Anthropic 公式 / OpenAI 公式の料金・モデルページ。