LangChain×RAGとは？仕組み・実装手順・社内活用例をローカル検証付きで解説
- LangChain×RAGは、LLMと社内文書などの外部知識をつないで回答を作る構成
- RAGの品質はデータ整備、検索精度、権限管理、評価方法で左右される
- 小規模な検証から始め、検索結果と生成回答を分けて評価することが重要
社内規程やFAQを参照する生成AIを作りたくても、「LLMにどのように文書を検索させるのか」「回答をどこまで信頼できるのか」と悩む担当者もいるでしょう。LangChainは、LLM、文書検索、プロンプトなどを接続する開発基盤です。
本記事では、LangChainとRAGの違い、組み合わせるメリット、実装手順、社内活用例を整理します。後半では、架空のITヘルプデスク文書を使った実演結果も紹介するので、自社で試す際の判断材料にしてください。
＼生成AIを活用して業務プロセスを自動化／
LangChainとは
LangChainは、モデルやプロンプト、ツール、文書検索などを組み合わせて、LLMを使うアプリケーションを開発するフレームワークです。LangChain公式ドキュメントでは、モデル、ツール、プロンプト、ミドルウェアを用途に合わせて構成できる基盤として説明されています。
特定のLLMやベクトルストアに限定されず、共通化された部品を入れ替えられる点が特徴です。ただし、LangChainを導入しただけで回答精度や安全性が保証されるわけではありません。検索対象の品質、権限、ログ、評価、人による確認まで含めて設計する必要があります。
LangChainと大規模言語モデル（LLM）の違い
LLMは、入力された文章を解釈し、回答、要約、分類などを行うモデルそのものです。単体でも文章を生成できますが、社内の最新規程や業務システムのデータを自動で参照する機能は別途用意しなければなりません。
一方、LangChainは、LLMを業務アプリケーションの中で使うための開発基盤です。LLMが文章を生成するエンジンなら、LangChainはエンジンを検索やツールと接続する配線と考えると分かりやすいでしょう。
LangChainとRAGの違い
RAG（Retrieval-Augmented Generation）は、質問に関係する外部情報を検索し、取得した情報をLLMの入力に加えて回答を生成する設計手法です。LangChainのRetrieval公式ドキュメントでも、検索で外部コンテキストを取得し、生成処理と組み合わせる構成がRAGとして整理されています。
LangChainはRAG自体ではありません。文書の読み込みやテキスト分割、Embedding、ベクトル検索、プロンプト作成、回答生成といったRAGの構成要素をつなぐための選択肢です。
| 項目 | LLM | RAG | LangChain |
|---|---|---|---|
| 役割 | 文章の理解・生成 | 外部情報を検索して回答に加える設計手法 | モデル、検索、ツールなどをつなぐ開発基盤 |
| 社内情報の参照 | 仕組みを別途構築 | 検索対象として参照 | ローダーやRetrieverなどで実装を支援 |
| 情報更新 | モデル学習時点の知識に左右される | 検索対象の文書を更新 | 更新した文書の登録フローを組める |
| 利用時の注意 | ハルシネーション、コスト、データ取り扱い | 誤検索、古い文書、権限漏れ | 依存パッケージ、ログ、例外処理、評価設計 |
LangChainについては下記で詳しく解説しています
LangChainとRAGを組み合わせるメリット
LangChainとRAGを組み合わせると、検索対象やLLMなどを用途に合わせて選び、社内知識を参照する回答フローを組めます。まずは問い合わせが多く、正解と根拠文書を準備しやすい業務に絞ると、効果と問題点を判断しやすくなります。
ここでは、実装を始めやすくする効果と、実務で見落としやすい制約をセットで確認します。
開発工数の削減
LangChainには、文書を共通のDocument形式で扱うためのローダーやテキスト分割、Embeddingモデル、ベクトルストア、Retrieverなどの部品があります。それぞれの接続処理をゼロから実装するより、PoC（概念実証）の準備を短縮しやすいでしょう。
ただし、フレームワークは業務要件を決めてくれません。アクセス制御、監査ログ、エラー処理、評価データ、文書更新の責任者は自社で設計する必要があります。
応答精度の向上
RAGでは、質問に近い社内文書やマニュアルを検索し、その内容をLLMへ渡します。一般的な知識だけに頼るよりも、社内の制度や製品仕様に沿った回答を作りやすくなります。
一方で、最終回答の品質は検索品質に強く依存します。文書の重複や古い版を放置せず、チャンクの大きさ、検索件数、メタデータフィルターを評価してください。
質問ごとの評価表を残せば、検索結果と回答のどちらに改善余地があるか、変更前後で確認できます。
ハルシネーション抑制
検索結果だけを根拠に回答するよう指示すれば、LLMが記憶や推測だけで答える場面を減らせます。出典文書名や該当箇所を回答と一緒に表示すれば、利用者が原文に戻って確認できます。
回答の根拠を利用者が確認できる導線も必要です。
ただし、RAGはハルシネーションをゼロにする仕組みではありません。誤った文書を取得したり、LLMが検索文脈を読み違えたりする可能性があります。根拠が不足するときの回答拒否と、重要な判断に対する人の確認を残しましょう。
LLMへの依存低減
RAGを使えば、社内規程やFAQが更新されるたびにモデルを追加学習させるのではなく、検索対象の文書を差し替える運用にできます。これは、社内知識をLLM本体に埋め込む必要を減らすという意味での依存低減です。
LLMが不要になるわけではありません。回答生成モデル、Embeddingモデル、ベクトルストアには依存するため、モデル交換時に使える評価質問と期待回答を自社で保持しておくと安心です。
あわせて、文書の更新履歴も残しましょう。
外部ツールの呼び出し
LangChainでは、RAGの文書検索に加え、データベース照会や社内APIなどをツールとしてつなげられます。例えば、製品マニュアルをRAGで検索し、現在の在庫数は社内APIに照会して、ひとつの回答にまとめるといった拡張が可能です。
最初は参照のみの操作から段階的に広げると、影響を確認しやすくなります。
更新や削除を伴う操作は、検索よりもリスクが高くなります。ツールごとの実行権限と人の承認を設け、LLMに与える権限を最小限にしてください。
LangChainを用いたRAGの実装手順
LangChainでRAGを実装するときは、文書を検索できる形へ変換する「登録」と、質問ごとに関連文書を取り出す「検索・生成」を分けて考えます。はじめに少量の文書と評価質問を用意すれば、問題がデータ、検索、生成のどこにあるのかを切り分けやすくなります。
対象文書と利用ルールを決める
社内規程、FAQ、マニュアルなど、回答の根拠にする文書を選びます。機密区分、閲覧対象者、更新責任者、保存期間を登録前に決めます。
文書を読み込み、適切な大きさに分割する
長い文書を見出しや意味のまとまりで分けます。分割が大きすぎると不要な文章が増え、小さすぎると回答に必要な前後関係が失われます。文書名、版、部署、権限などのメタデータも付与しましょう。
Embeddingを作り、ベクトルストアへ登録する
Embeddingモデルで文書をベクトル化し、Chromaなどのベクトルストアへ保存します。LangChainのChroma連携ドキュメントには、メモリ内での実行とpersist_directoryを使うローカル永続化の両方が示されています。
Retrieverとプロンプトを設計する
Retrieverで質問に近い文書を取得し、その文章と質問をLLMへ渡します。「検索結果だけを根拠にする」「資料にない場合はそう答える」と指定し、出典を追える出力にします。
検索と回答を別々に評価し、運用へ進める
想定質問ごとに、正しい文書を取得できたか、回答が文書と一致したか、根拠不足時に回答を控えられたかを確認します。応答時間、APIコスト、利用者フィードバック、権限漏れも評価対象です。
| 評価対象 | 確認する内容 | 改善例 |
|---|---|---|
| 文書品質 | 古い版、重複、誤記がないか | 正本を決め、更新日と責任者を付与 |
| 検索品質 | 期待する文書が上位に出るか | チャンク、検索件数、フィルターを調整 |
| 回答品質 | 根拠と回答が一致するか | プロンプト、回答形式、拒否ルールを調整 |
| 安全性 | 閲覧権限のない文書が出ないか | 検索前のユーザー認証とメタデータ制御 |
| 運用性 | コスト、応答時間、障害時の影響 | 上限設定、監視、フォールバックを追加 |
【実践】LangChainでRAGをローカル構築してみた
ここでは、LangChain、OpenAIのEmbeddingモデルとチャットモデル、Chroma、ローカル文書を使った最小構成を検証しました。実在の社内データは使わず、VPN接続、ソフトウェア購入、情報セキュリティ事故報告に関する3つの架空文書を用意しています。
検証用スクリプトは、OPENAI_API_KEYを環境変数から読み込むため、キーをコードや実行画面に記載しません。OpenAIEmbeddingsのLangChain公式連携ドキュメントでも、APIキーをOPENAI_API_KEYとして設定する方法が案内されています。
最初に検証環境を表で整理し、検索対象の文書、Chromaへの登録と検索、出力の順に確認します。
| 項目 | 検証内容 |
|---|---|
| 実行環境 | Windows上のPython環境 |
| 検索対象 | ローカルの架空ITヘルプデスク文書3件 |
| Embedding | OpenAI text-embedding-3-small |
| ベクトルストア | Chroma（検証時はメモリ内で使用） |
| 回答生成 | OpenAI gpt-5.4-mini、temperature=0 |
| 検索件数 | k=1 |
| 質問 | 「VPN接続に失敗した場合、最初に何を確認し、誰に連絡しますか？」 |
検証用の架空文書を用意する
まず、検索対象を明確にするため、VPN対応手順を1件の検証文書として用意しました。内容は実在の規程ではなく、外部へ出して問題のない架空データだけに限定しています。この範囲なら、文書検索と回答生成の基本動作を安全に確かめられます。
検証で使ったvpn_support.txtには、社給PCのインターネット接続を確認すること、VPNクライアントを再起動すること、復旧しない場合はエラー番号を添えてITヘルプデスクへ連絡することを記載しています。
Chromaへ登録しRetrieverを作る
次に、文書を読み込み、ベクトルストアへ登録してRetrieverから検索できる状態にします。この例では、検索件数をk=1に固定し、質問に最も近い文書を1件だけ取得します。
取得した文書の本文と出典ファイル名をcontextに連結し、モデルにはその検索結果だけを根拠に回答するよう指示しています。
【コード】
以下は、実際に実行した検証用スクリプトから、RAGの主要処理を抜粋したコードです。実行用ファイルには、読み込んだ文書名、検索結果、確認項目を表示するログも追加しています。
クリックで表示
from pathlib import Path
from langchain_chroma import Chroma
from langchain_core.documents import Document
from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
data_dir = Path(__file__).resolve().parent / "data"
documents = [
Document(
page_content=path.read_text(encoding="utf-8"),
metadata={"source": path.name},
)
for path in sorted(data_dir.glob("*.txt"))
]
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vector_store = Chroma.from_documents(documents, embedding=embeddings)
retriever = vector_store.as_retriever(search_kwargs={"k": 1})
question = "VPN接続に失敗した場合、最初に何を確認し、誰に連絡しますか？"
retrieved_documents = retriever.invoke(question)
context = "\n\n".join(
f"[出典: {document.metadata['source']}]\n{document.page_content}"
for document in retrieved_documents
)
prompt = ChatPromptTemplate.from_template(
"""次の検索結果だけを根拠に日本語で回答してください。
検索結果にない内容は推測せず、「資料に記載がありません」と答えてください。
検索結果:
{context}
質問:
{question}
"""
)
model = ChatOpenAI(model="gpt-5.4-mini", temperature=0)
answer = (prompt | model).invoke(
{"context": context, "question": question}
).content検索結果と回答を分けて確認する
text-embedding-3-smallはテキストを数値ベクトルに変換するEmbeddingモデルで、OpenAI公式のモデル説明では検索、クラスタリング、レコメンドなどの用途が示されています。2026年7月の検証用スクリプトでは、回答生成にgpt-5.4-miniを指定しています。
実行すると、検索結果にvpn_support.txtが1件表示されました。生成回答には、まず社給PCがインターネットへ接続できているか確認することと、復旧しない場合はエラー番号を添えてITヘルプデスクへ連絡することが含まれ、検索文書にない手順の追加は確認されませんでした。
今回は少量の架空データとk=1に限定したため、検索の正しさを確認しやすい構成です。本番運用では、ユーザーの権限に合う文書だけを検索する制御、文書更新、ログ監視、評価データの拡充が必要です。
なお、文書とChromaをローカルに置いても、OpenAIのEmbeddingモデルとチャットモデルを使う場合はテキストが外部APIへ送信されます。OpenAIのデータ管理に関する公式ドキュメントを確認し、データの送信先、保持、契約条件を社内ポリシーと照合してください。
LangChain×RAGの活用シーン
LangChain×RAGは、参照すべき文書があり、似た質問が繰り返し発生する業務と相性が良い構成です。導入候補を選ぶときは、回答の根拠と正解を準備できるか、誤回答が起きたときに人がフォローできるかを確認しましょう。
社内問い合わせ対応
就業規則、経費精算、IT申請などの社内文書を検索対象にすれば、従業員が必要な手続きを探す時間と、情報システム部門への定型的な問い合わせを減らせます。
質問の傾向を記録すれば、FAQや社内手続き自体の改善にもつなげられます。
検索対象の規程が最新版か、定期的に点検する運用も必要です。回答には出典文書名とリンクを添え、最終判断は必ず原文で確認できる設計にしてください。人事情報や評価資料など、ユーザーごとに閲覧可否が異なる文書は検索前に権限で絞り込みます。
社内ヘルプデスクにおける生成AIの活用方法は下記で解説
FAQボット
公開FAQ、製品マニュアル、サービス利用ガイドを検索対象にすれば、顧客が問い合わせ前に疑問を解決するFAQボットを作れます。質問の表現がFAQと一致しない場合でも、Embeddingによる類似度検索で関連文書を探せます。問い合わせへの導線も併せて表示すると、解決できない場合に対応を引き継げます。
公開中の製品と版が一致しているかを定期的に確認し、古いFAQを検索対象から外す仕組みが必要です。資料にない問い合わせは推測で答えず、人の窓口へ誘導します。
カスタマーサポート
過去の対応手順、障害情報、製品仕様をRAGで参照し、オペレーター向けの回答案を作る用途です。対応履歴を引き継ぎ資料に整えたり、関係するマニュアルをオペレーターに提示したりもできます。
回答案をそのまま送信せず、担当者が内容を確認できる画面設計にすると安心です。
顧客の氏名、契約情報、問い合わせ内容を外部APIへ送る場合は、送信範囲と利用条件の確認が必要です。自動回答の対象を低リスクな問い合わせに限定し、返金、契約、法的判断などは人が確認する運用が現実的です。
生成AIをカスタマーサポートに活用する方法は下記で解説
ナレッジの分析
議事録、報告書、社内Wikiなどを横断検索し、関連情報の所在を見つける用途です。複数のプロジェクトに分散した過去の意思決定や、似た問題の対応履歴を探す際に役立ちます。
検索対象の範囲を部署や期間で絞れるようにすると、不要な情報を混ぜにくくなります。
そのうえで原文へのリンクを示せば、要約の妥当性も確認できます。
要約だけを返すと、異なる案件の情報を混ぜるおそれがあります。出典、日付、部署、プロジェクト名を回答に残すことで、利用者が内容を検証できます。
ナレッジ管理の手法は下記で解説
検索精度を高めるための前処理や検索手法も確認したい方は、次の記事をご覧ください。
営業支援
提案資料、導入事例、製品仕様書を検索し、商談の論点に合う情報を営業担当者へ提示できます。提案文のたたき台や、次回商談で確認すべき質問の整理にも使えるでしょう。
営業担当者が確認すべき根拠文書を一緒に示せば、提案内容を見直しやすくなります。
価格、納期、契約条件は変更されるため、記事や古い提案書だけを根拠にしてはいけません。最新の正式資料へのリンクと承認フローを組み込み、顧客へ送付する前に人が確認します。
生成AIを用いた営業支援は下記で解説
よくある質問
LangChain×RAGを小さく検証して社内活用へつなげよう
LangChainは、LLM、文書検索、プロンプト、外部ツールをつなぐ開発基盤です。RAGと組み合わせれば、社内規程やFAQを検索し、根拠を示して回答する構成を作れます。
ただしRAGの品質はLLMの性能だけでは決まりません。文書の正確さや検索設定、アクセス権、評価データ、監査ログ、人の確認まで含めた設計が欠かせません。まずは定型的な問い合わせと少量の公開可能な文書で小さく検証し、検索と回答を分けて評価しながら、自社に合うPoCの進め方を見極めましょう。
最後に
LangChainとRAGの実装や社内活用の進め方に迷ったら、WEELの無料相談へお気軽にご相談ください。自社データや業務要件に合わせた検証・導入のポイントを一緒に整理します。
株式会社WEELは、自社・業務特化の効果が出るAIプロダクト開発が強みです！
開発実績として、
・新規事業室での「リサーチ」「分析」「事業計画検討」を70％自動化するAIエージェント
・社内お問い合わせの1次回答を自動化するRAG型のチャットボット
・過去事例や最新情報を加味して、10秒で記事のたたき台を作成できるAIプロダクト
・お客様からのメール対応の工数を80％削減したAIメール
・サーバーやAI PCを活用したオンプレでの生成AI活用
・生徒の感情や学習状況を踏まえ、勉強をアシストするAIアシスタント
などの開発実績がございます。
生成AIを活用したプロダクト開発の支援内容は、以下のページでも詳しくご覧いただけます。
➡︎株式会社WEELのサービスを詳しく見る。
まずは、「無料相談」にてご相談を承っておりますので、ご興味がある方はぜひご連絡ください。
➡︎生成AIを使った業務効率化、生成AIツールの開発について相談をしてみる。
「生成AIを社内で活用したい」「生成AIの事業をやっていきたい」という方に向けて、生成AI社内セミナー・勉強会をさせていただいております。
セミナー内容や料金については、ご相談ください。
また、サービス紹介資料もご用意しておりますので、併せてご確認ください。
