RAGは何をする仕組みか
RAGはRetrieval-Augmented Generationの略で、検索した情報を生成AIの回答に利用する構成です。Microsoft Learn「RAG in Azure AI Search」も、組織の保有コンテンツを回答の根拠として利用するパターンとして説明しています。社内資料をモデルそのものへ追加学習させることと、質問ごとに必要な資料を検索して渡すことは別です。
社内規程の問い合わせを例にすると、質問を受け取り、閲覧可能な資料を検索し、該当箇所をもとに回答を作り、根拠へのリンクを返します。ただし検索対象に正しい情報がなければ、正しい回答を保証できません。資料をアップロードするだけで、社内の曖昧なルールが自動で整理されるわけではありません。
まず既存の全文検索、文書の整理、FAQの整備で足りるかも比較します。文書名がわかっており、該当ファイルを開くだけで解決するなら、生成AIを加えない方が運用しやすい場合があります。
開発前に文書の所有者と正本を決める
当社が提案する最初の作業は、対象文書の棚卸しです。全社の共有フォルダを一度に取り込まず、問い合わせが多く、文書の管理者が明確な一領域から始めます。総務規程を対象にするなら、人事評価や個人の給与資料まで同時に含めない、といった範囲設定が考えられます。
| 項目 | 確認内容 | 未整理の場合の対応 |
|---|---|---|
| 正本・管理者 | どの場所にある版が正式か | 所有部署と正本の置き場を決める |
| 適用範囲 | 拠点・雇用区分・製品などの対象 | 文書属性として記録する |
| 有効日・失効日 | 現在の規程か、過去の参照用か | 現行と旧版を区別する |
| 閲覧権限 | 誰が原文を見られるか | 利用者・部署の認可条件を整理する |
| 形式 | PDF、画像、表、注記を読めるか | 抽出結果を原文と照合する |
| 更新・削除 | いつ、誰が検索対象へ反映するか | 更新担当と反映期限を決める |
特に表の例外条件、脚注、画像内の文字は、文章として取り出した際に関係が崩れる可能性があります。抽出できた文字数だけで判断せず、実際の質問に必要な条件が残っているかを確かめます。
権限は回答を作る前に絞る
Microsoft Learn「Security filters for trimming results」では、利用者やグループの識別情報を検索フィルターに使い、結果を絞る方法を説明しています。またフィルター内の文字列そのものは認証ではないことも明記しています。
この区別を踏まえた当社の設計上の提案は、ログイン済み利用者の権限をサーバー側で確認し、その人が参照できる文書だけを検索・生成の対象にすることです。画面から任意の部署名を送れば閲覧範囲が広がる設計や、すべての資料をAIへ渡した後で「秘密は答えないで」と指示するだけの設計は避けます。
異動・退職・権限変更もテスト対象です。検索結果だけでなく、原文へのリンク、過去の会話、キャッシュ、ログに残る内容まで確認します。元の文書を削除した際に、検索用の複製や分割データへ反映する手順も必要です。どこまで保管するかは自社の情報管理方針と合わせます。
答えない条件を先に設計する
以下は当社の想定設計例です。出張規程について「宿泊費はいくらまでですか」と聞かれたとき、拠点や役職、適用日で条件が異なるなら、AIが一つの金額に決めつけるのではなく不足条件を確認します。根拠が見つからない場合は、その旨と問い合わせ先を返します。
回答画面には結論だけでなく、文書名、該当箇所、適用日、原文へのリンクを示す案を推奨します。出典リンクがあることと、出典が回答を裏付けていることは別です。利用者がクリックして確かめられるか、引用箇所にない条件を補っていないかを確認します。
文書間で規程が食い違う場合も、AIに都合よく統合させず、相違と確認先を示します。「最新版を使う」といっても、更新日が新しい草案より、承認済みの現行規程を優先する場合があります。優先ルールは業務担当者が定義します。
受け入れテストは検索と回答を分ける
正しい回答が出ないときは、検索で該当文書が取れていないのか、取れた資料から回答を作る段階で誤ったのかを分けて調べます。モデルを変更する前に、文書の抽出や検索条件の問題を確認できます。
| 質問・条件 | 期待する動作 | 確認する担当 |
|---|---|---|
| 正式名称を使った質問 | 正本の該当箇所に到達する | 業務担当 |
| 略称や言い換えでの質問 | 同じ規程を参照できる | 現場利用者 |
| 例外条件を含む質問 | 本文だけでなく例外を反映する | 規程管理者 |
| 対象外の内容 | 根拠がないことを示す | 業務責任者 |
| 他部署の非公開資料 | 回答・リンク・履歴へ漏らさない | 情報システム担当 |
| 文書更新・削除後 | 合意した期限内に検索対象へ反映する | 文書管理者と運用担当 |
この表は検証案であり、実測した性能や一律の合格基準ではありません。通常の質問の正答率と、権限違反の有無は別に評価します。利用者の「便利だった」という感想に加え、解決までの時間と担当部署への再問い合わせ件数も記録します。
小さく始めても、更新担当は必要
初期開発だけでなく、文書更新、検索データの再作成、アクセス権の同期、質問ログの確認に誰が時間を使うかを決めます。誤回答の報告窓口がないと、問題が繰り返されても開発側へ届きません。問い合わせ内容そのものが機密情報を含む場合もあるため、ログの保存項目は必要な範囲に絞ります。
相談時は対象文書の種類と量、利用部署、月間のおおよその問い合わせ件数、代表的な質問を共有してください。全文の持ち出しが難しい場合は、まず文書構造だけで検討できます。要件整理と本番化の確認項目を合わせて読むと、検証と本番の範囲を分けやすくなります。
参考にした一次情報
参照日: 2026年9月14日。公式資料の説明と、当社の提案・想定例を区別しています。比較表・モデル計画は当社の検討案であり、実測結果や効果保証ではありません。