AI社内検索を導入するには、社内文書をAIへ渡すだけでなく、検索する範囲、閲覧権限、回答の根拠、情報を更新する運用を決める必要があります。RAGは、質問に関係する資料を検索し、その内容を参照してAIが回答する仕組みです。社内規程や手順書を探す負担を減らす候補になりますが、資料が古い、権限が不明、正しい回答を確認する人がいない状態では、そのまま全社展開できません。
まず対象を一つの部門や業務へ絞り、「何を探す時間を減らすか」「どの資料を根拠に答えるか」「答えられないとき誰へ戻すか」を整理します。本記事では、開発担当者へ丸投げせずに導入可否と検証範囲を判断するための確認事項を説明します。
1. AI社内検索とRAGでできること
一般的なファイル検索は、資料名や本文に含まれる語から候補を探します。AI社内検索では、言い換えを含む質問を受け付け、関連資料の要点をまとめて提示する構成も取れます。RAGの基本は検索と回答生成の組み合わせであり、社内資料を参照するたびにモデルを追加学習させることと同じではありません。MicrosoftのRAG解説でも、検索する情報とアクセス制御が重要な構成要素として説明されています。
たとえば、申請手順、製品マニュアル、社内の問い合わせ履歴から、担当者が必要な説明を探す用途が考えられます。一方、最新の在庫数や個別顧客の契約状態など、常に変わる情報は文書検索だけでは足りません。業務DBやAPIを権限付きで参照する必要があるかを分けて検討します。
検索できることと、自動で業務を決定・実行してよいことも別です。AIの回答を承認の代わりにせず、規程の解釈や個別判断が必要な場面は担当者へ戻します。
2. 最初に一つの検索業務を選ぶ
「社内の全情報を検索したい」から始めると、資料整備と権限調整の範囲が広がります。最初は、質問が繰り返され、答えの根拠が明確で、確認担当者を決められる業務を選びます。
- 誰が、どの場面で資料を探しているか
- 検索から回答確認までに何をしているか
- 見つからない原因は資料不足か、保管場所か、用語の違いか
- 誤った回答を使うと、どのような業務影響があるか
- 現在の検索やFAQ整理だけでは解決できないか
たとえば、同じ手順書の保存場所が分からないだけなら、まず文書の集約と案内の改善で足りる場合があります。複数資料の照合や言い換え質問への対応が負担になっているなら、AI検索を検証する意味があります。AIの導入自体ではなく、担当者の検索と確認の負荷を比較対象にします。
3. 文書を集める前に正本と管理者を決める
同じ規程の旧版、新版、担当者のメモを一緒に取り込むと、どれを優先するか判断できません。文書一覧には、種類、保存場所、管理者、更新日、適用開始日、閲覧対象、廃止予定を記録します。作成日が新しいファイルが、必ず現在有効な資料とは限りません。
検索に使える状態か確認する
PDF、Word、表計算、社内Webページなど、形式ごとに見出しや本文を取得できるか確認します。画像だけのPDF、結合セルの多い表、図中にしかない説明は、読み取りや構造整理が必要になる場合があります。取り込み件数ではなく、質問への回答に必要な箇所を取り出せるかを見ます。
文書を小さな単位へ分ける場合も、見出しや注意書きとの関係を残します。本文だけを切り出して例外条件を落とすと、検索結果が見つかっていても回答を誤ります。元ファイル、ページ、節へ戻れる情報を持たせ、担当者が根拠を確認できるようにします。
更新・削除を検索側にも反映する
文書を一度取り込んだだけでは、元資料の修正や削除が検索結果へ反映されるとは限りません。誰が更新を通知するか、どの間隔で同期するか、失敗時に誰へ知らせるかを決めます。古い文書を検索対象から外した後も、キャッシュや回答履歴へ情報が残る可能性があるため、保存対象ごとに扱いを確認します。
4. 閲覧権限は回答後ではなく検索前に制御する
人事資料や顧客情報を含める場合、「機密事項を答えないようAIへ指示する」だけでは不十分です。利用者を認証し、その利用者が閲覧できる文書だけを検索・取得する設計が必要です。
- 元の文書管理の権限を、検索側へどう引き継ぐか
- 部門異動、退職、共有解除をいつ反映するか
- 管理者と一般利用者で見える範囲が分かれるか
- 根拠リンクや検索結果の抜粋から情報が漏れないか
- 会話履歴やキャッシュが別利用者へ渡らないか
権限テストでは、閲覧できる人が正しく答えを得られることに加え、閲覧できない人が資料の存在や内容を推測できないかも確認します。複数部門の情報を横断する場合は、全社共通資料から始め、権限の複雑な資料を段階的に増やす方法もあります。
5. 回答の根拠と「答えない条件」を設計する
回答画面には、回答文だけでなく、参照資料、該当箇所、必要に応じて資料の適用日を表示します。リンクがあるだけで正しいとは判断せず、回答中の主張がその箇所で裏付けられるかを確認します。
資料に答えがない、質問が曖昧、複数資料が矛盾する、権限が不足する場合は、推測して埋めずに確認事項を返すよう設計します。「該当資料が見つからない」と「対象業務にルールが存在しない」は異なります。
たとえば、申請条件について一般的な手順は見つかっても、個別の例外承認は資料にない場合があります。このときは、確認できた一般条件と未確認の個別条件を分け、所管部署への確認へつなぎます。もっともらしい一つの答えへまとめることを、常に成功条件にしないでください。
6. PoCでは検索と回答を分けて評価する
過去の質問や想定質問から評価用の組を作ります。各質問に、必要な根拠資料、答えに含める内容、答えてはいけない内容、利用者の権限を対応させます。調整に使った問題だけで評価せず、未使用の質問も残します。
評価は、必要な資料が取得できたか、回答が資料と一致するか、根拠を追跡できるか、形式や権限を守れたかに分けます。検索の失敗と回答生成の失敗を分ければ、文書整理を直すべきか、検索設定や回答条件を直すべきかを判断できます。
業務面では、検索・確認時間、担当者への再質問、利用者による修正、未回答の扱いを確認します。平均時間だけでなく、誤った手順を案内した場合の影響が大きい質問を別に集計します。正解率の目標は、対象業務のリスクと人による確認範囲に合わせて決めます。
7. 既存システム連携と費用の見積範囲
費用を左右するのは、AIモデルの利用料だけではありません。文書の取得・整形、権限連携、検索基盤、回答画面、評価データ、ログ、更新監視、人手確認の設計が必要です。文書数だけでなく、形式のばらつき、更新頻度、部門別権限、同時利用、必要な応答時間が調査対象になります。
既存ポータルへ追加するのか、独立した画面を用意するのかでも変更範囲が異なります。認証やDBとの接続を含む場合は、既存システムへ生成AIを組み込む際の構成と依頼前の確認事項も整理しておくと、検索機能だけの費用と、周辺システム改修の費用を分けやすくなります。
本番化後は、モデルや検索設定、文書形式、権限の変更時に再評価します。使い続けるほど文書が増えるため、取り込み対象を増やす承認者と、利用されない資料を整理する運用も見積範囲へ含めます。
8. 相談前に整理しておく情報
相談時は、対象業務、検索する人、代表的な質問、資料の種類と保管場所、閲覧権限、現在の検索手段を分かる範囲で整理します。資料そのものを最初から一括送付する必要はありません。機密区分と受渡し方法を確認し、サンプルは必要に応じて匿名化します。
資料が未整理でも、その状態を把握することで、文書整備から始めるか、限定した資料でPoCを行うかを判断しやすくなります。回答に必要な精度、権限、更新条件を共有したうえで、既存製品を利用する範囲と個別開発する範囲を検討してください。
