AI開発
RAGを業務で動かす
社内文書をLLMに接続し、質問すれば根拠つきで答える社内ナレッジ検索アシスタント。デモではなく業務で使える品質に到達させるための、パイプライン実装と運用の勘所を整理します。
この記事の要点
社内ナレッジのように量が多く、頻繁に更新され、出典が必要な用途では、RAGが基本の選択肢になります。ファインチューニングは文体や出力形式を固定したいときに併用します。
RAGは各段の品質が積み重なるパイプラインです。回答がおかしいときは、生成段のプロンプトより先に検索段を疑うと切り分けが早く進みます。
出典提示・根拠範囲への限定・「分かりません」の許容・継続評価・アクセス権限の検索段フィルタが、試作と実用を分けます。アクセス権限はLLMへ渡す前の検索段で効かせます。
— 01
RAGが解決する課題と、使い分け
社内の規程・マニュアル・過去案件・FAQをLLMに接続し、質問すれば根拠つきで答える。それが社内ナレッジ検索アシスタントです。デモなら一晩で動きますが、業務で使える品質に到達させるには別の難しさがあります。本記事は、社内文書を使ったRAG(Retrieval-Augmented Generation、検索拡張生成)を構築・検討している技術部門の方に向けて、概念やPoCの進め方ではなく、検索品質・出典・評価・セキュリティといった実用化で詰まる部分に焦点を当てます。
LLMは学習済みのパラメトリック知識を持ちますが、単体では自社の規程や過去案件、その最新版にはアクセスできません。社内文書をLLMに接続する手段は主に3つあり、性質が異なります。
ファインチューニング: モデルの重みを追加学習で調整します。文体や分類タスクの定着には有効です。知識を覚えさせる用途も可能ですが、更新性・網羅性・出典根拠の信頼性でRAGに劣ります。最新知識を反映するには再学習や別の外部知識機構が必要になります。
プロンプト同梱: 関連しそうな文書を毎回プロンプトに丸ごと貼り付けます。少量なら有効ですが、文書が増えるほど入力長と費用がかさみます。長コンテキストモデルやキャッシュで緩和はできるものの、大量文書を毎回丸ごと入れる運用は非効率です。
RAG: 質問に関連する文書だけを検索して取り出し、その断片をプロンプトに添えて回答させます。文書の更新は再インデックスで反映でき（版管理やアクセス権の更新も伴います）、検索由来の出典も返せます。
社内ナレッジのように量が多く、頻繁に更新され、出典が必要な用途では、RAGが基本の選択肢になります。ファインチューニングは文体や出力形式を固定したいときにRAGと併用する、という整理が実務的です。
— 02
パイプラインの全体像
RAGは大きく2つのフェーズに分かれます。事前にデータを準備する「インデックス構築」と、質問のたびに走る「検索と生成」です。
インデックス構築（事前・バッチ処理）:
文書取り込み(ingestion) → チャンク分割(chunking) → 埋め込みベクトル化(embedding) → ベクトルストアへ格納
検索と生成（質問のたび・リアルタイム）:
ユーザーの質問 → 質問を埋め込みベクトル化 → ベクトルストアを検索(retrieval) → 関連チャンクを並べ替え(reranking) → 質問＋チャンクをプロンプトに合成 → LLMが出典つきで回答を生成(generation)
各段の品質が積み重なるため、どこか1段が弱いと全体が崩れます。とりわけ検索段で正しいチャンクを拾えなければ、LLMが内部知識で偶然正答することはあっても、根拠つきの回答としては成立しません。回答がおかしいときは、生成段のプロンプトより先に検索段を疑うと切り分けが早く進みます。
— 03
チャンク設計の勘所
文書をそのまま埋め込むことはせず、検索しやすい単位に分割します。この分割設計が検索品質を大きく左右します。
サイズ: 大きすぎると1チャンクに複数の話題が混ざり、検索の精度が落ちます。小さすぎると文脈が切れて意味が取れません。目安として数百トークン前後から始め、対象文書で調整します。
オーバーラップ: チャンク境界で文脈が途切れないよう、隣接チャンクを少し重ねます。重ねすぎると重複ヒットが増えるため、1〜2割程度が目安です。
見出し単位の分割: 規程やマニュアルは章・節の構造を持ちます。文字数で機械的に切るより、見出し構造に沿って区切るほうが意味のまとまりを保てます。
メタデータ付与: 各チャンクに、出典文書名・章番号・最終更新日・部署・公開範囲などを付けます。これは出典提示・フィルタリング・鮮度管理のすべてに効く、見落とされがちな投資です。
固定文字数の機械分割で十分なケースもありますが、社内規程のように構造を持つ文書では、構造に沿った分割が効きます。
— 04
検索品質を上げる
ベクトル検索（意味の近さで探す）だけでは取りこぼしが出ます。実用品質には次の組み合わせが有効です。
ハイブリッド検索: ベクトル検索と、
BM25などのキーワード検索を併用します。ベクトル検索は言い換えに強い一方、製品コードや社内固有の略語といった字面の一致が重要な語では取りこぼしが出やすく、キーワード検索がそこを補います。両者のスコアを統合して順位を決めます。なお小規模かつ完全一致中心の用途では、キーワード検索やデータベース検索だけで足りる場合もあります。リランキング: 一次検索で多めに候補を取り出し、リランキング専用モデルで質問との関連度を精密に並べ替えます。一次検索の粗い順位を補正でき、最終的にLLMへ渡す上位チャンクの質が上がります。
メタデータフィルタ: 「人事部の最新版だけ」「失効していない規程だけ」のように、検索前に候補を絞ります。鮮度とアクセス権の制御にも直結します。
すべてを最初から入れる必要はありません。まずベクトル＋キーワードのハイブリッドを土台にし、評価で不足が見えたらリランキングを足す、という順序が現実的です。
— 05
生成段：出典・ハルシネーション・「分かりません」
検索したチャンクをプロンプトに添えてLLMに回答させますが、ここで実用と試作の差が出ます。
出典を必ず返す: 回答には、根拠にしたチャンクの出典（文書名・章）を併記させます。利用者が一次資料を確認でき、誤りにも気づけます。社内ナレッジ検索や規程の照会では、出典のない回答は確認のしようがなく、信頼に足りません。
根拠の範囲に限定させる: システムプロンプトで「提供された文書の範囲だけで答える」「文書にない事柄は推測しない」と明示します。LLMは知識で補完しがちなため、明示的な制約が要ります。
「分かりません」を許容する: 関連チャンクが見つからない、または不十分なときは、無理に答えず「該当文書が見つかりません」と返させます。誤りを断定するより、空振りを正直に返すほうが業務では信頼されます。検索スコアが閾値に届かなければ生成段に進ませない、という設計も有効です。
指示追従の精度はモデルや設定で差が出ます。Anthropic Claudeのような指示追従に定評のあるモデルを使う場合でも、制約はプロンプト任せにせず、検索設計（閾値・フィルタ）と組み合わせて担保するほうが安全です。
あなたは社内ナレッジ検索アシスタントです。
以下の【参考文書】の範囲だけを根拠に回答してください。
- 参考文書に根拠がない事柄は「該当文書が見つかりません」と返す
- 推測で補完しない
- 回答末尾に、根拠にした文書名と章番号を必ず列挙する
【参考文書】
{retrieved_chunks}
【質問】
{user_question}— 06
評価(evals)を回す
「動いた気がする」で本番に出すと、モデル更新・文書追加・インデックス変更のたびに精度が劣化し得ます。RAGは継続的な評価が前提のシステムです。
検索ヒット率: 想定質問のセットを用意し、正解チャンクが上位に入る割合を測ります。検索段の良し悪しはここで切り分けます。
回答の根拠整合: 回答内容が、取り出したチャンクの記述と矛盾しないかを確認します。出典と回答のずれはハルシネーションの兆候です。
回帰テスト: チャンクサイズ変更・モデル更新・文書追加のたびに、評価セットを流して劣化していないかを確認します。一度作った評価セットは資産になります。
評価セットは小さく始めて構いません。現場でよく来る質問を数十問集めるだけでも、改善の効果を数値で語れるようになります。
— 07
よくある失敗
チャンクが大きすぎる／小さすぎる: 話題が混ざる、または文脈が切れる。評価で最適サイズを探ります。
古い文書の混入: 失効した旧版が検索に出て、誤った回答の根拠になります。最終更新日のメタデータと有効版フラグで除外します。
権限を無視した横断検索: 全文書を無差別に検索すると、閲覧権限のない情報が回答に漏れます。
出典なしの回答: 根拠を確認できず、誤りに気づけません。出典提示は任意機能ではなく必須要件です。
— 08
セキュリティとアクセス権限
社内ナレッジは機密情報の塊です。技術選定と同じ重みで設計します。
外部LLMへ渡る経路の管理: SaaS型のLLMを使う構成では、質問文と検索チャンクが外部サービスに送信されます（オンプレやVPC、ローカルモデルなら外部送信されません）。提供形態ごとにデータ取り扱い方針（学習利用の有無・保持期間）を確認し、必要に応じて学習利用を無効化できる提供形態や、自社管理環境で完結する構成を検討します。
アクセス権限をRAGに反映する: 元文書の閲覧権限を、検索段で必ず適用します。各チャンクのメタデータに公開範囲を持たせ、検索時にユーザーの権限でフィルタします。アプリ側で後から表示を絞る方式は、LLMに権限外の情報が渡った後では手遅れになり得ます。権限はLLMへ渡す前の検索段で効かせます。これを原則とします。
監査ログ: 誰が何を質問し、どのチャンクが根拠として渡されたかを記録します。情報漏えいの調査と、品質改善の両方に使えます。
— 09
RAGを使うべきでないケース
RAGは万能ではありません。次の場合は別手段を検討します。
答えが文書ではなく構造化データにある: 「先月の売上合計」のような集計は、検索ではなくデータベースへのクエリの仕事です。RAGより、LLMにSQLや関数を呼ばせる設計が適します。
文書が頻繁かつ即時に変わる: 在庫数のような秒単位の値は、インデックス更新が追いつきません。APIで都度取得します。
出力の文体・形式の固定が主目的: 知識の追加ではなく出力整形が狙いなら、ファインチューニングやテンプレートのほうが適します。
高い厳密性が要る判断: 法的・医療的な最終判断をRAGに委ねてはいけません。あくまで一次情報への案内役と位置づけます。
RAGは大量の社内文書から、根拠つきで該当箇所を引いてくる用途で強みを発揮します。自社の課題がこの形に合うかを最初に見極めることが、最短の実用化につながります。
よくあるご質問
RAGとファインチューニングはどちらを選べばよいですか。
知識を追加・更新したいならRAG、出力の文体や形式を固定したいならファインチューニングです。社内ナレッジ検索は前者にあたります。両者は排他ではなく、文体はファインチューニング、知識はRAGという併用も有効です。
ベクトルデータベースは何を使えばよいですか。
専用のベクトルデータベース、既存データベースのベクトル拡張、検索エンジンのベクトル機能など複数の選択肢があります。文書規模・既存基盤・運用体制で選びます。小規模なら既存基盤の拡張から始め、規模が増えたら専用製品を検討する流れが無理がありません。特定製品に最初から固定せず、評価で見極めます。
回答が間違っているとき、どこを直せばよいですか。
まず検索段を疑います。正解チャンクが検索結果の上位に入っているかを確認し、入っていなければチャンク設計・ハイブリッド検索・リランキングを見直します。上位に入っているのに回答が誤るなら、生成段のプロンプトや制約を調整します。
ハルシネーションを完全に防げますか。
ゼロにはできません。出典の明示・根拠範囲への限定・「分かりません」の許容・継続評価を重ねて、発生率を下げ、起きても利用者が気づける状態を作ることが現実的な目標です。
アクセス権限はどう反映しますか。
各チャンクのメタデータに公開範囲を持たせ、検索の段階でユーザーの権限に応じてフィルタします。生成後の表示制御では、LLMへ権限外情報が渡った後になり手遅れになり得るため、検索前のフィルタが原則です。
この記事の著者
この記事が向いている方
社内文書を使ったRAGを構築・検討している技術部門の方
PoCは動いたものの、業務で使える検索品質・出典・評価まで詰めきれていない方
社内ナレッジ検索でアクセス権限とセキュリティを正しく設計したい方
— 壁打ち相談
読者のよくある相談
記事を読んだ後に「自分の状況だとどう判断すべきか」を整理するための壁打ち相談を受け付けています。下記のような相談例が当てはまる方は、お気軽にご連絡ください。
Q. RAGのPoCは動いたのですが、検索品質が業務で使える水準に届きません。
チャンク設計・ハイブリッド検索・リランキング・評価セットの整備まで、既存文書に合わせて検索段の立て直しを壁打ちできます。
Q. 社内ナレッジ検索で、アクセス権限とセキュリティをどう設計すべきか相談したいです。
検索段でのアクセス権限フィルタ、外部LLMへのデータ経路、監査ログの設計まで、自社の構成に合わせて整理します。
上記いずれかが該当する場合、初回30分の壁打ち相談で論点整理に対応します。記事に書ききれない個別事情を踏まえた判断材料が必要な段階こそ、壁打ちが活きやすいフェーズです。
関連するサービス
AI実装支援｜Netsujo
RAGの実装・運用をつくる
社内文書をLLMに接続するRAGの構築から、検索品質の改善、評価とセキュリティ設計までご相談いただけます。要件が固まっていない段階でも構いません。