RAGで社内文書を活用するには？仕組み・社内検索との違い・準備

「社内マニュアルをAIに覚えさせたい」と相談すると、RAGという言葉が出てくることがあります。導入を検討する担当者に必要なのは、専門用語をすべて覚えることより、どこで回答の根拠が決まり、誰が資料を管理するかを理解することです。

検索してから、回答を作る

RAGはRetrieval-Augmented Generationの略です。Lewisらの原論文では、外部の検索可能な情報と、文章を生成するモデルを組み合わせる方法が示されています。ここから先は、その考え方を社内業務へ当てはめたMakeAIの説明です。原論文：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

1. 利用者が質問する。
2. 質問に関係しそうな文書や箇所を探す。
3. 見つけた内容を、回答の材料としてAIへ渡す。
4. 回答と参照先を利用者へ示す。

例えば「出張の申請はいつまでか」という質問なら、対象者に適用される出張規程から締切に関する箇所を探します。生成AIには、その箇所を使って答え、資料名や版を併記させる設計が考えられます。これは動作を説明する仮想例であり、特定の製品の仕様ではありません。

社内検索、FAQ、RAGはどう使い分けるか

手段	利用者へ渡すもの	検討しやすい場面
社内検索	文書や該当箇所の候補	担当者が原文を読んで判断できる
固定FAQ	事前に承認した質問と回答	質問が少数で、答えがほぼ決まっている
RAGを用いた回答支援	検索した材料を基にした回答文	表現の異なる質問に、複数資料を参照して案内したい

すべてをRAGへ置き換える必要はありません。承認済みの回答をそのまま案内すべき質問なら、固定FAQのほうが管理しやすいこともあります。最初に「質問の種類」と「答えの揺れをどこまで認めるか」を整理します。

「資料を入れたのに答えられない」を分けて考える

回答が違う場合、生成AIの文章だけを直しても解決しないことがあります。まず、必要な資料が存在するか、次に正しい箇所が検索されたか、最後にその内容が正しく文章化されたかを確認します。

段階	起こり得る問題	確認するもの
資料	規程が古い、対象部門が不明	文書の版・有効日・管理者
検索	似た言葉の別制度を選んだ	実際に回答へ渡された箇所
回答	例外条件を省いて断定した	回答と参照箇所の対応
表示	利用者が原文を開けない	参照リンクと利用者の権限

回答に引用元らしい名前が付いていても、それだけでは裏付けになりません。実際の資料にその記述があるか、質問した人へ適用されるかを点検します。

始める前に、資料の管理責任を決める

試行の対象は、一部門の一つの用途など、小さく区切ります。文書ごとに管理者、対象者、有効な版、更新時の扱いを決めてください。旧版と新版が同時に検索される状態を放置すると、回答の材料がぶれます。

閲覧権限は、AIへの指示文だけに任せるものではありません。検索やデータ取得の段階で、利用者がアクセスできる資料を制御する設計が必要です。実装する場合は、権限の継承や除外の仕組みを担当者と確認します。

小さな試行で用意したい質問

• 答えが明記されている質問：正しい箇所を見つけて、条件付きで答えられるか。
• 似た制度がある質問：対象部署や雇用形態など、必要な確認を挟めるか。
• 資料に答えがない質問：もっともらしい数字を作らず、確認先を案内できるか。
• 閲覧できない資料に関する質問：権限のない内容が回答へ混ざらないか。
• 旧版と新版で答えが違う質問：有効な版を選べるか。

テスト結果には、質問、期待する根拠、検索された資料、回答、修正点を残します。回答の自然さだけで評価せず、「資料を探せたか」と「資料に沿って答えたか」を分けて見ると、改善する場所が明確になります。

RAGを相談するときに持っていく情報

最初から完成した仕様書は必要ありません。よくある質問の例、回答の根拠になっている資料、答える担当者、利用者の範囲が分かると、試行の対象を選びやすくなります。

「何でも答える社内AI」ではなく、「この部署の、この問い合わせで、資料を探す負担を減らす」と表せる範囲から始めましょう。費用や製品を選ぶ前に、根拠のある回答を作れる条件を確認するためです。

小さく試すために、文書三つと質問五つを先にそろえる

RAGの導入を検討するとき、初回から社内の全ファイルを集める必要はありません。まず一種類の問い合わせを選び、回答に必要な資料、現在の回答方法、回答を確認できる担当者をそろえます。次は「貸出機器をどこへ返すか」という架空の社内問い合わせを使った設計例です。実際のRAGで回答を生成した検証結果ではありません。

資料ID	確認した内容	試行での扱い
K-01・第2版	10月1日以降、返却場所は総務窓口。受付は平日10～17時	現在の回答根拠にする
K-01・第1版	返却場所は返却棚A。第2版で廃止	旧版と明示し、通常の回答対象から外す
K-02・第1版	故障時は使用を止め、機器番号と症状を総務へ連絡する	故障の質問に使う。返却場所の根拠にはしない

資料名だけで新版と判断せず、内容の管理者が有効な版を確認します。更新日が新しくても、単に誤字を直したファイルかもしれません。今回のように適用日がある手順では、版、適用開始日、失効した版、承認した担当を別々に記録すると、どの条件で答えるべきかを説明できます。

文書の整え方では、見出し、略語の定義、前後の文脈が参考になります。AWSのRAG向け文書作成ガイドも、検索された部分だけで意味が通るように資料を整理する考え方を示しています。自社の資料では、表の単位や対象部署が抜けて読まれないかを実際に確認してください。

質問と、合格に必要な答えを対にする

「正しく答えたか」を後から感覚で判断しないよう、質問を作る人と内容を知る人で期待する結果を決めます。文章の一致ではなく、残すべき条件と根拠で判定します。

質問	期待する結果	不合格になる例
貸出パソコンはどこへ返す？	総務窓口。K-01第2版を根拠に示す	返却棚Aへ案内する
18時に返却できる？	通常の受付は17時まで。時間外の対応は資料にないと示す	警備員へ預けられると補う
壊れた端末を返したい	使用停止と機器番号・症状の連絡を案内し、根拠を示す	通常返却だけを案内して故障の扱いを落とす
返却棚に戻す手順はまだ使える？	第1版の手順で、現在は総務窓口へ変わったと説明する	二つの手順を同時に現行扱いする
紛失したときの負担額は？	この資料には金額がない。判断担当へ確認する	一般的な相場や推定額を社内規則として答える

最後の質問は、答えられないときに適切に止まれるかを見るものです。資料にない回答まで常に返す仕組みにすると、正しい回答の割合だけを見た試行では問題を見逃します。質問の意図に合う資料を探せたかと、探した資料に書かれた範囲で答えたかを、別の欄に残します。

失敗した場所を分けて、直す対象を決める

返却場所が違ったとき、すぐにAIへの指示を長くするのではなく、どの段階で食い違ったかを確かめます。根拠として表示された資料が旧版なら、まず登録対象や検索対象の管理を調べます。第2版が取り出されているのに回答が返却棚Aなら、回答生成や別の会話文脈の影響を調べる必要があります。

観察した状態	最初に戻る場所	再確認すること
正しい資料が見つからない	登録・検索	資料が取り込まれたか、対象の語や文脈が残っているか
似た資料だが対象部署が違う	検索条件・資料の区分	部署や適用条件を区別できるか
根拠は正しいのに結論が違う	回答の作り方	条件の省略、推測、複数資料の混同がないか
本文は正しいが出典を開けない	表示・閲覧権限	利用者が根拠を確認できる経路があるか

「回答が悪い」という一つの記録では、修正後に何を比べればよいか分かりません。質問ID、入力文、回答、根拠資料と版、期待結果、問題の分類、修正した対象、再確認の結果を一行にまとめます。回答が毎回同じとは限らないため、一度の成功だけを全体の品質として説明しないことも必要です。

試行記録の空欄
質問ID：
質問した利用者の区分：
期待する回答と根拠：
実際に返った回答：
表示された資料・版：
見つかった問題：資料／検索／回答／表示
直した対象と変更内容：
同じ質問で再確認した結果：
まだ確認できていない条件：

閲覧範囲が異なる資料を扱う場合は、許可された利用者と許可されていない利用者を分けて試します。回答の最後に「社外秘」と付けるだけでは、見せてはいけない内容を渡す問題は解決しません。検索段階でのアクセス制御を含む仕組みの確認が必要です。確認環境がない段階では、全社員向けの資料だけに対象を絞るなど、試行範囲を具体的に制限します。

RAGを選ぶ前に、社内検索やFAQで足りる条件も確かめる

問い合わせが「申請書はどこか」のようにファイルへの案内だけで終わるなら、文書の置き場所と名前を整理した方が早く解決する可能性があります。回答が数種類に決まっていて変更が少ないなら、担当者が承認したFAQを使う方法も比較できます。複数資料の条件を組み合わせて文章で答える必要があるかを、実際の質問から確かめてください。

導入判断の会議では、「RAGを作れるか」だけでなく、「利用者は回答文が必要か」「根拠文書を開くだけで解決するか」「現行資料の管理者がいるか」「誤回答を受けた人がどこへ連絡できるか」を並べます。資料の正しさを決められる人がいない場合、AIの導入だけで正本が決まることはありません。先に社内ナレッジの更新担当を決める作業へ戻ります。

小さな試行を終えたら、対象の質問、使った資料、答えられた範囲、答えられなかった条件、内容を確認した担当、次に調べる点を一枚にまとめます。「回答できたから全社へ展開する」ではなく、未確認の部署や権限、別形式のファイルへ広げる前に追加で試す内容を決めるための記録にしてください。検索や回答の設定を変えた場合も、変更前の記録は残して比較します。

担当者へ渡す前に、試行の依頼を一枚にまとめる

開発担当へ文書だけを送ると、検索画面を作ればよいのか、回答文まで必要なのかが曖昧になります。相談前には「利用者が何を尋ね、どの状態になれば解決したと扱うか」を先に書きます。返却場所の例なら、利用者が現行の場所と受付時間を知り、根拠を開けることが到達点です。返却の予約や機器台帳の更新は別の作業なので、最初の範囲へ自動的に含めません。

依頼項目	架空例での記入
対象の利用者	全社員向け資料を閲覧できる社員。社外利用は今回の対象外
対象の疑問	貸出機器の返却場所、受付時間、故障時の連絡
回答の完成条件	条件を省かず、資料IDと版を表示。記載のない金額は答えない
対象外の操作	予約、申請の送信、台帳変更、担当者への自動通知
変更時の担当	総務が内容を承認し、反映担当が登録、総務が質問で再確認
試行後の判断材料	質問ごとの正誤、根拠の表示、回答できない場合の案内、修正の手間

費用を比較するときも、この範囲をそろえます。単に「資料は三つ」と伝えるだけでなく、ファイルの形式、文字を取り出せるか、更新の頻度、利用者の区分、既存の保存場所との接続を伝えてください。少数の資料でも閲覧権限が複雑なら、誰でも同じ文書を読める試行と作業量は異なります。逆に、まず手動で資料を登録する試行なら、自動同期の構築を初回から求める必要がない場合もあります。

相談先から見積もりが返ったら、資料整理、検索部分、回答部分、画面、試験、運用支援のどこを含むかを確かめます。この記事の架空例から、実際の構築費や納期を算定することはできません。必要な範囲が同じかを比較できる状態にしてから、具体的な条件で見積もりを依頼します。

試行を見送る判断も記録に残します。例えば有効な資料が決まらないなら「内容管理者の確定待ち」、利用者が求めるのが原資料への移動だけなら「検索導線の整理を先行」、入力してよい範囲が分からなければ「対象資料の承認待ち」とします。曖昧な「AIには難しそう」で止めず、再開するために何が必要かが分かる理由へ置き換えてください。