ローカルAIに「うちの規程では？」と聞くと、それっぽいが事実と違う答えが返ることがあります。これを抑えるのがグラウンディング（接地）——モデルの答えを外部の典拠につなぐことです。本記事は、グラウンディングとは何か、なぜローカルAIでこそ重要か、そして自分のデータにオフラインで接地する3つの方法を、実装スタック・必要スペック・限界まで実践的にまとめます。
グラウンディングとは（なぜローカルで効くか）
グラウンディングは、LLMが答える前に外部の情報源（文書・データベース・計算・API）を参照させ、出力をその典拠に接地する手法の総称です。根拠: LLM grounding解説
ローカルAIで特に効く理由は2つ。
- 小型ローカルモデルほど幻覚しやすい。パラメータが小さいほど「知らないことを知らないと言えず」作話します。だから外部接地の価値がクラウドの大型モデルより大きい。
- 自分のデータにオフラインで接地できる＝機密を外に出さない。社外秘・個人情報・自治体データを、外部APIに送らず手元で根拠にできます。
効果は大きい一方、万能ではありません。ある調査ではRAGによる接地で幻覚が42〜68%減と報告されますが、ゼロにはならず、検証（出典提示・人手確認）の併用が要ります。根拠: grounding技術（要検証・二次情報）
ローカルで使える3つの接地
グラウンディングは1つの技術ではなく、3つの接地を組み合わせるのが実務です（本番システムは複数併用が定石）。根拠: wizr.ai
① RAG ― 検索で「事実」を渡す
社内文書やマニュアルをチャンクに分割→埋め込み（ベクトル化）→ベクトルDBに格納し、質問時に意味の近い断片を検索して文脈に注入します。根拠: RAG解説 2026
ローカルでは、ローカルの埋め込みモデル＋ローカルのベクトルDB＋ローカル生成で完結できます。手軽な実装は AnythingLLM / GPT4All（フォルダ丸ごとQA）、本格派は LlamaIndex / LangChain ＋ Ollama。社内共有なら Open WebUI がRAG標準装備です。実際の組み方はローカルAIデモ集と社内AIサーバー入門に。
② ツール接地 ― 計算・APIに「任せる」
数値計算・最新の在庫・天気・社内DB照会のような確定的な事実は、AIに推測させずツール（function calling）に投げて結果を受け取るのが接地です。これはRAGと並ぶ第二の柱で、/agents/ のエージェント実用度インデックスで実測しているとおり、ツールを正しく呼べるかはモデル（特に日本語では“族”）で大きく変わります。接地の前提として、まずfunction callingの実測でモデルを選ぶのが安全です。なぜチャットの賢さがツール接地を保証しないかはエージェント能力とチャット能力の違いへ。
③ 出典付け ― 「どこから」を明示する
検索・計算で得た根拠を、回答に出典として添える。これで利用者が検証できるようになり、幻覚を「見抜ける」状態にします。知識グラフやルックアップ表で構造化された事実に当てる方法も含みます。当サイトが全主張に 根拠:URL を付けているのと同じ思想です。
2026年は、検索と検証をエージェントが並列で回す Agentic RAG が主流パターンになっています。
根拠:Agentic RAG 2026
「知識は外、振る舞いはAI」― ファインチューニングとの使い分け
よくある誤解が「知識を覚えさせたい＝ファインチューニング」。実は逆で、変わりうる“事実”は接地（RAG・ツール）に、口調や出力形式は微調整（FT）に任せるのが定石です。事実をFTで焼き込むと更新できず陳腐化し、幻覚も増えます。この役割分担は最適化の順序（プロンプト→RAG→FT）で詳説しています。
実装：ローカルのグラウンディング・スタックと必要スペック
RAGは埋め込み＋生成の二段なので、生成モデルに加えて軽量な埋め込みモデルが要ります。スペックの目安は次の通り（生成モデル側。埋め込みは数百MB級で軽い）。
| 規模 | 生成モデル | 目安メモリ | 向く機材 |
|---|---|---|---|
| お試し・小規模RAG | 2〜4B | 8GB〜 | ミニPC・Jetson・ラズパイ |
| 実用RAG（社内QA） | 7〜14B | 12〜18GB | Mac mini M4 / 24GB GPU |
| 大規模・長文書 | 14〜32B＋ | 24〜48GB | RTX A6000 級 |
- 静音・省電力でデスク常設の万能機: Amazonで見る広告・Amazon ／ 楽天で見る広告・楽天
- 大型文書・大規模RAGの上限帯: Amazonで見る広告・Amazon ／ 楽天で見る広告・楽天
GPUの選び方は自宅GPUの選び方、手元で実用速度が出るかは動くか診断と検証DBで確認できます。なお生成速度はメモリ帯域で決まるため、RAGでも「載る・動く・使える」を分けて考えます。
moat例：GIS・防災データにローカルAIを接地する
接地が最も活きるのが、計算やデータで“事実”が確定する領域です。ハザード・日照・建築規制のような値は、AIに推測させず外部に接地し、AIは「どう伝えるか」を担う——この構図はハザードマップ×オフラインAIそのもの。
たとえば日照（日影）・建築可能ボリューム・眺望を3D都市モデル（PLATEAU）で計算するツールの例として、みるラボの3D不動産分析シミュレータ（日影・ボリューム・眺望）があります。こうした確定値を持つ計算・GISをツール接地の“情報源”にし、ローカルAIに説明や対話を任せれば、オフラインでも事実に根ざした応答ができます。
グラウンディングの限界（正直に）
- 幻覚はゼロにならない（前述の報告で42〜68%減・要検証）。検索が外せば誤答し、検索が当たっても小型モデルは根拠を誤読することがあります。
- 検索品質が天井。チャンク分割・埋め込みの質が悪いと「関係ない断片」を渡してしまう。データ整備がRAGの8割です。
- ツール接地はモデル依存。日本語ではツールを正しく呼べないモデルが多く（実用度インデックス参照）、接地の前にモデル選定が要ります。
- 対策は出典提示＋人手検証＋（重要操作の）承認ゲートの併用。接地は「幻覚を見抜ける状態」を作る手段で、無謬化ではありません。
まとめ
- グラウンディング＝答えを外部の典拠に接地して幻覚を抑える設計。小型でオフラインなローカルAIでこそ効く。
- ローカルで使える3つの接地＝①RAG（検索）②ツール接地（計算・API）③出典付け。本番は併用。
- 事実は接地、形式はFT。役割を分けるのが定石。
- GIS・防災など計算で事実が出る領域はツール接地と相性抜群（moat）。
- ただし幻覚はゼロにならない。検索品質とモデル選定、そして検証の併用が前提。
外部の数値（幻覚42〜68%減等）は二次情報の引用で要検証。ローカルでの実効果はデータ・モデル・スペックに依存します。手元構成での可否は動くか診断、モデル選定はエージェント実用度インデックスと検証DB（自前実測）でご確認ください。