クラウドAIのリスクは漏えいそのものより「気づけないこと」にあります。多くのAPI利用規約では、入力した文章を一定期間保持し、不正利用の監視や品質改善に使う場合があると定められています。無料プランや一部のビジネスプランでは、入力データが学習データとして再利用される可能性も排除できません。社外秘マニュアルや顧客情報を質問文に含めた瞬間、それは契約上の秘密保持義務（NDA）違反や、個人情報保護法上の第三者提供に該当しかねません。しかも一度送信したデータを相手のサーバーから完全に消し去ったことを、利用者側が確認する手段はほとんどありません。ローカルRAGはこの「気づけないリスク」自体を構造的に消せる点が最大の価値です。

具体的には、就業規則や社内規定の問い合わせ対応、製品マニュアルの検索、契約書のひな形確認、研究ノートや議事録の振り返りなど、「答えは社内のどこかにあるはずだが、探すのに時間がかかる」という場面ほどローカルRAGの効果が大きく出ます。質問する側は身構えずに自然な日本語で聞けばよく、AIが該当箇所を探し出して根拠付きで答えてくれます。

まず最初に1回だけ、すべての資料を読み込んでデータベース化する「仕込み」の作業が走ります。

データベースができてしまえば、あとは質問するたびに次の4ステップが一瞬で実行されます。

ここで使った数字にも意味があります。チャンクを500字で切るのは、AIが一度に参照する文章量を「意味のまとまりを保てる程度」に保つためです。短すぎると文脈が途切れ、長すぎると無関係な情報が混ざって回答の精度が落ちます。100字の重複（オーバーラップ）を持たせるのは、文の境界でちょうど重要な一文が分断されてしまう事故を防ぐ工夫です。検索件数をk=3に絞っているのも同じ理由で、件数を増やすほど情報は増えますが、AIに無関係な文章まで読ませることになり、処理が遅くなったり回答がぼやけたりします。

ポイントは、ネットワーク通信が一切登場しないことです。ベクトル化も検索も生成も、すべて同じPCの中のプロセス間でデータがやり取りされるだけ。だから後述するように、Wi-Fiを切っても全く同じように動きます。

まずはターミナルで、テキストをベクトル化する「埋め込みモデル」と、回答を生成する「LLM」の2つをダウンロードします。

# ① 文章を数値化（ベクトル化）する軽量・高性能モデル
ollama pull nomic-embed-text

# ② 質問に回答するLLM（日本語に強い軽量モデルの例）
ollama pull qwen3:4b

続けて、RAGの組み立てに使うPythonライブラリを導入します。

# LangChain本体・Ollama連携・Chroma（ベクターDB）をまとめて導入
pip install langchain langchain-community langchain-chroma chromadb

ここからが本体のコードです。前半は「読み込み→分割→ベクトル化→保存」、つまりフェーズ1（インデックス作成）にあたる部分です。

import os
from langchain_community.document_loaders import DirectoryLoader, TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.embeddings import OllamaEmbeddings
from langchain_chroma import Chroma

# ① docsフォルダ内のすべての.txtファイルを読み込む
loader = DirectoryLoader('./docs', glob="**/*.txt", loader_cls=TextLoader)
documents = loader.load()

# ② 長文を500字単位（100字重複）に分割──検索精度を上げる下準備
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=100)
texts = splitter.split_documents(documents)

# ③ Ollamaのnomic-embed-textでベクトル化
embeddings = OllamaEmbeddings(model="nomic-embed-text")

# ④ ./db フォルダにベクトルを保存──ここで完全オフラインのDBが完成する
vector_store = Chroma.from_documents(
    documents=texts,
    embedding=embeddings,
    persist_directory="./db"
)

後半は「検索→プロンプト合成→生成」、つまりフェーズ2（質問応答）にあたる部分です。前半のスクリプトに続けて書きます。

from langchain_community.llms import Ollama
from langchain.chains import RetrievalQA

# ① 質問に近いチャンクを3件だけ持ってくる検索役を用意
retriever = vector_store.as_retriever(search_kwargs={"k": 3})

# ② 回答生成用のローカルLLM（temperature=0で創作を抑え事実重視に）
llm = Ollama(model="qwen3:4b", temperature=0)

# ③ 検索とLLMを1本のチェーンに結合
qa_chain = RetrievalQA.from_chain_type(llm=llm, chain_type="stuff", retriever=retriever)

# ④ 実行──Wi-Fiを切っても同じ回答が返ってくる
query = "社外秘プロジェクト『X』のリリース時期と注意点は何ですか？"
response = qa_chain.run(query)
print(response)

temperature=0は、AIの「創作性」を最小限に抑える設定です。値が高いほど表現は豊かになりますが、社外秘マニュアルの内容確認のように正確性が最優先の場面では0に固定し、資料に書かれていないことを勝手に作文（ハルシネーション）させないようにします。またchain_type="stuff"は、検索で見つかった資料をそのまま1つのプロンプトに詰め込んで渡す、最もシンプルな合成方法です。資料の件数が多くなる場合は、いったん要約してから渡すmap_reduceなどの方式に切り替えることもできます。

実行すると、docsフォルダの中身を根拠にした回答が返ってきます。仕組みは②章の図解そのもので、①ベクトル化→②検索→③プロンプト合成→④生成、の4ステップがこの数行の裏側で動いています。同じ質問をWi-Fiを切った状態で試せば、次の⑤章で確認するとおり、結果が変わらないことも体感できます。

もう一つ覚えておきたいのは、300冊すべてを毎回ベクトル化し直す必要はないという点です。マニュアルが1冊追加・改訂されたときは、その差分ファイルだけを読み込んでvector_store.add_documents()のように追記すれば済みます。初回の重いインポートは一度だけ我慢すれば、その後の運用はずっと軽くなります。保存先の./dbフォルダ自体も、3万ページ規模では数GB〜十数GBに育つため、ストレージの空き容量と、後述するバックアップ先にも余裕を持たせておきましょう。

完全オフラインで動くことと、勝手に安全になることは別の話です。ここでは構築時によくある2つの落とし穴と、本当にオフラインかどうかの確認方法を見ていきます。

./dbフォルダはこのシステムの「記憶」そのものです。誤って削除すれば再構築（=再度の重いベクトル化）が必要になるため、定期的なバックアップを忘れないでください。逆に、社外秘マニュアルの提供が終了した、あるいは内容が古くなった場合は、該当する元ファイルをdocsフォルダから削除し、データベースを再構築することで、AIが古い情報や不要になった機密情報を参照し続ける事態を防げます。

まずは数ファイルの小さなテキストで通して動かし、Wi-Fi切断テストと1冊だけのPDF抽出テストをクリアしてから、本番の資料を増やしていくのが安全な進め方です。慣れてきたら④章を参考にモデルやスペックを引き上げ、社内で使うなら⑤章のチェックリストと利用ガイドラインを必ずセットで整えてください。

ここまでの内容を、よくある疑問の形でも振り返っておきます。