# 第 12 章：ナレッジエンジニアリングのためのローカルモデル

> **一文で：** ローカルモデルは、ナレッジ harness 全体を自分のハードウェアで動かすことを可能にする ——プライベートで、無料で、ますますクラウド API と競合できる。
>
> **なぜ重要か：** ナレッジベースに機微なデータが含まれるなら、または自分のノートでモデルをファインチューンしたいなら、ローカル推論こそがすべてを自分の管理下に保つ唯一の道だ。

これまでの章は、クラウド API アクセスを概ね前提とするナレッジエンジニアリングスタックを記述している ——context window を Anthropic、OpenAI、Google に送って応答を返してもらう。これは大半のユーザーにとってよく機能する。だが、クラウド推論が実用的でないか望ましくない実践者の層が増えている：機微な企業データを扱う者、データレジデンシー要件が厳しい管轄区にいる者、そして自分でコンパイルした知識上でモデルをファインチューンしてループを完全に閉じたい者。

本章はローカルモデルとナレッジエンジニアリングの交差を扱う。GPU 購入ガイド、ベンチマーク比較、量子化技法は扱わない ——それらのトピックは他のリソースで十分にカバーされている。代わりに、モデルを自分のインフラの内側に持ち込むときに重要となるアーキテクチャ判断に焦点を当てる。

---

## ナレッジエンジニアリングにとってローカルがなぜ重要か

ナレッジシステムにおけるローカルモデルの採用を駆動する 3 つの力：

**ポリシーではなくアーキテクチャとしてのプライバシー。** 内部企業文書上で RAG を動かすたびに、すべてのクエリが文書チャンクをクラウドプロバイダーに送る。データ処理契約は助けになるが、表面積を消し去りはしない。ローカル推論なら、データはマシンを離れない。法律事務所、医療組織、政府機関にとって、これは選好ではない ——要件である。

**スケール時のコスト。** 継続的なバックグラウンドプロセス ——vault lint、自動ノートコンパイル、定期的な再インデックス —— を動かすナレッジシステムは、日に数千の API 呼び出しを生成する。クラウド価格では、これは急速に積み重なる。コンシューマーハードウェアで動くローカルモデルは、初期セットアップ後はクエリあたり限界コストがゼロだ。常時稼働のナレッジ保守（Karpathy のアーキテクチャの Lint 操作）にとって、ローカル推論は経済学を完全に変える。

**ファインチューニングのエンドゲーム。** これが恐らく最も説得力のある理由だ。ナレッジベースが十分な品質に到達したら ——Ingest 操作を通してコンパイルされた、よく構造化され相互リンクされた数百のノート —— それは原始的な合成データセットになる。このデータセットで小さなローカルモデルをファインチューンでき、ランタイムに検索を必要とせず本来的にあなたのドメインを「知る」モデルが生まれる。知識は context window ではなく重みの中にある。

---

## アーキテクチャ：ローカルモデルが収まる場所

ナレッジ harness のすべてのコンポーネントが等しくローカル推論から恩恵を受けるわけではない。ローカルモデルが最大の価値を提供する場所はここだ：

### Embedding モデル（高価値）

Embedding はあらゆる RAG パイプラインの土台だ。Vault にノートを追加するたびに、類似度検索のためにベクトルへ変換する必要がある。これは高ボリューム・低複雑度の操作 ——ローカル推論にうってつけ。

人気の選択肢：
- **nomic-embed-text**（137M パラメータ）：強い汎用 embedding、CPU で動く
- **mxbai-embed-large**（335M）：より高品質、控えめなハードウェアでも管理可能
- **bge-m3**（568M）：多言語、混合言語コンテンツの vault に優秀

これらのモデルは、GPU なしの現代のラップトップで動かせるほど小さい。ローカルとクラウド embedding（OpenAI の text-embedding-3、Cohere の embed）の品質差は著しく狭まった ——大半のナレッジ管理ユースケースで、ローカル embedding は十分だ。

Ollama 経由でローカル実行：
```
ollama pull nomic-embed-text
```

### Query と推論（中価値）

Vault について質問に答えるためにローカルモデルを使うこと ——Query 操作 —— はトレードオフがより微妙になる場所だ。クラウドモデル（Claude Opus、GPT-4o）は依然として、複雑な推論、多段合成、繊細な指示追従において意味のある優位を持つ。だが、素直な検索ベース Q&A（「先月 X について何を書いたか？」）には、7–14B パラメータ域のローカルモデルが良好に機能する。

実用的な選択肢：
- **Qwen3-14B**：強い多言語性能、Apache 2.0 ライセンス
- **Llama 3.3-8B**：高速推論、構造化指示に従うのが得意
- **DeepSeek-R1-Distill-7B**：完全 R1 から蒸留された推論能力、MIT ライセンス
- **Gemma 3-12B**：Google の効率的アーキテクチャ、構造化出力が得意

最も機能するパターンは **段階的アプローチ** である：日常クエリと vault 保守にはローカルモデル、複雑な合成と創造的タスクにはクラウド API へエスカレートする。これは harness エンジニアリングの progressive disclosure 原則がモデル選択にどう適用されるかを反映する ——各タスクに最低限の能力モデルを使え。

### ナレッジコンパイル（高価値）

Ingest 操作 ——生のソースを読んで構造化された wiki ページにコンパイル —— は意外にもローカルモデルに適している。タスクは明確に定義されている：記事を読み、要点を抽出し、wikilink 付きの構造化ノートを生成する。指示追従が良い 14B モデルは、特に出力形式がシステム prompt で精密に指定されているとき、これを信頼性高く扱える。

経済学的論拠が最強なのはここだ。Web Clipper が 1 日 5–10 記事を捕捉し、各コンパイルが 2–3 分の推論を要するなら、これをローカルで動かすと、ナレッジベースは限界コストゼロで継続的に成長する。

### Vault 保守（高価値）

Lint 操作 ——矛盾、陳腐化、孤立ノートをスキャン —— はバッチプロセスで、ローカル推論から多大な恩恵を受ける。API コストを心配せずに、毎時、日次、または継続的に背景で動かせる。ローカルモデルが vault をスキャンし、問題をフラグ付けし、健康レポートを生成する ——データがマシンを離れることなく。

---

## ファインチューニングのエンドゲーム

Andrej Karpathy が概説したビジョンを、いま多くの実践者が追求している：LLM 保守の wiki が十分な品質に到達したら、それを使って個人 Small Language Model (SLM) をファインチューンせよ。

ワークフロー：

1. 数か月の Ingest 操作を通じてナレッジベースを **コンパイル** する。Wiki はよく構造化され相互リンクされた数百のノートへと成長する。
2. Wiki から訓練ペアを **抽出** する：各ノートは（質問、回答）ペア、または（context、completion）ペアとなる。
3. このデータセット上で小さなモデル（1–3B パラメータ）を、LoRA か QLoRA を使って **ファインチューン** する。
4. ファインチューンしたモデルを **デプロイ** ローカルに。検索を必要とせず、自分の重みからあなたのドメインに関する質問に答える。

これは RAG を完全に置き換えるわけではない ——ファインチューンしたモデルも最近の情報や特定の詳細では検索から恩恵を受ける。だが検索の負担は劇的に下がる。モデルはあなたのドメインの基盤概念、関係、パターンを「知っている」。RAG は新しいまたは非常に特定の情報を補足するだけでよくなる。

このパイプラインのツールは成熟している：
- **Unsloth** ：効率的なファインチューニング向け（2 倍速く、60% メモリ少なく）
- **Axolotl** ：管理された訓練設定向け
- **MLX**（Apple Silicon）または **llama.cpp** ：ファインチューンしたモデルのローカル推論向け

---

## 統合パターン

### パターン 1：万能バックエンドとしての Ollama

Ollama は、OpenAI 互換 API でローカルモデルを動かす統一インターフェースを提供する。これは、OpenAI API で動くツールが base URL を変えるだけでローカルモデルに向けられることを意味する：

```
base_url: http://localhost:11434/v1
model: qwen3:14b
```

これは LangChain、LlamaIndex、Dify、大半の RAG フレームワークで動く。Obsidian ユーザーには、Smart Connections のようなプラグインがクラウド API の代わりにローカル Ollama モデルを使うよう設定できる。

### パターン 2：ハイブリッドクラウド・ローカル

大半のユーザーにとって最も実用的なアーキテクチャ：
- **ローカル** ：Embedding、vault 保守、日常クエリ、ナレッジコンパイル
- **クラウド** ：複雑な推論、創造的合成、多段エージェントワークフロー

これは高ボリューム操作のためのプライバシーとコストの恩恵を、本当に必要とするタスクのためのフロンティアモデル能力へのアクセスとともに与える。

### パターン 3：ローカルモデルでの MCP

Model Context Protocol は Ollama の OpenAI 互換エンドポイントを通じてローカルモデルで動く。これは、ローカルナレッジソース ——あなたの vault、データベース、ファイルシステム —— に接続し、ローカルで動くモデルにそれらをサーブする MCP サーバーを構築できることを意味する。ナレッジ harness 全体があなたのマシンで動く。

---

## 本章が扱わないこと

本章は意図的に省く：
- **ハードウェア推奨** ：GPU 選択、VRAM 要件、クラウド GPU レンタルは r/LocalLLaMA wiki や Ollama ドキュメントなどのリソースで広範に扱われている。
- **モデルベンチマーク** ：ランキングは月次で変わる。現在の順位は [Open LLM Leaderboard](https://huggingface.co/spaces/open-llm-leaderboard/open_llm_leaderboard) を参照。
- **量子化詳細** ：GGUF 形式、INT4 vs INT8、品質/速度トレードオフは llama.cpp と Ollama コミュニティでよく文書化されている。
- **訓練インフラ** ：マルチ GPU セットアップ、分散訓練、クラウド訓練プラットフォームはナレッジエンジニアリングの範囲外。

ここでの焦点はアーキテクチャ的問いだ：ローカルモデルはあなたのナレッジ harness のどこに収まるか、そして何を可能にするか？

---

## 鍵となる持ち帰り

1. **ローカル embedding は当然の選択。** 品質ギャップは閉じ、コストはゼロ、プライバシーの恩恵は絶対的。RAG を動かすなら、embedding はローカルで動かせ。

2. **段階的推論が実用的選択。** 日常操作にはローカル、複雑な推論にはクラウド。フロンティアモデルがより上手にすることを 7B モデルに強いるな。

3. **コンパイルユースケースは過小評価されている。** Ingest をローカルで動かすと、ナレッジベースは限界コストゼロで継続的に成長できる。これはナレッジ保守の経済学を変える。

4. **ファインチューニングは出発点ではなくエンドゲーム。** まず wiki を構築せよ。数百の質の高いノートをコンパイルせよ。それからファインチューン。訓練データの質 ——あなたの wiki —— が結果モデルの質を決める。

5. **プライバシーはアーキテクチャ判断。** 知識に機微情報が含まれるなら、ローカル推論はオプションではない。最初からそれを前提に設計せよ。

---

## Sources

- Ollama: [https://ollama.ai](https://ollama.ai)
- llama.cpp: [https://github.com/ggml-org/llama.cpp](https://github.com/ggml-org/llama.cpp)
- Unsloth: [https://github.com/unslothai/unsloth](https://github.com/unslothai/unsloth)
- Karpathy, Andrej. "LLM Wiki" pattern — Gist defining the raw → wiki → schema layered architecture and the Ingest / Compile / Lint / Query operations referenced throughout this chapter. [https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)
- Open LLM Leaderboard: [https://huggingface.co/spaces/open-llm-leaderboard](https://huggingface.co/spaces/open-llm-leaderboard)
- Nomic Embed: [https://huggingface.co/nomic-ai/nomic-embed-text-v1.5](https://huggingface.co/nomic-ai/nomic-embed-text-v1.5)
- r/LocalLLaMA: [https://reddit.com/r/LocalLLaMA](https://reddit.com/r/LocalLLaMA)

---

*前の章: [第 11 章 — LLM ナレッジエンジニアリングの鍵となる瞬間](11-timeline.md)*
