「社内の規程やマニュアルを、AIに聞けば答えてくれるようにしたい」。そのための仕組みとしてよく名前が挙がるのがRAG（検索拡張生成）です。ただ「答えが古い」「見せてはいけない文書の内容が出てきた」といったつまずきも起きやすい領域です。ここではRAGの仕組みを平易に整理し、着手前に押さえておきたい準備を実務目線でまとめます。
RAGとは「社内の文書を検索し、見つかった内容をもとにAIが回答文を作る」仕組みです。利用者が質問すると、社内文書から関連しそうな箇所が検索され、その本文がAIに渡されます。AIはその内容を読んだうえで、質問に沿った回答を組み立てます。
ここで押さえておきたいのは、AIモデルそのものを自社データで作り直しているわけではないという点です。よく「学習させる」と表現されますが、RAGでは元のAIモデルに手を加えず、回答のたびに社内文書を参照させています。この違いは実務上重要で、文書を差し替えれば回答も追随する、逆に言えば元の文書が誤っていれば回答も誤るという性質につながります。
もう一つの利点は、回答の根拠となった文書を提示しやすいことです。「この規程の第3条にこう書かれています」と出典を添えられるため、利用者が自分で裏取りできます。業務利用では大きな意味を持つ性質です。
RAGは万能ではなく、扱う情報の性質によって相性が分かれます。
この線引きを最初に決めておくことが重要です。何でも答えられる想定で始めると、答えられない質問が積み重なり、利用者が離れていきがちです。
RAGの品質は、ツールの性能よりも「渡す文書がどれだけ整っているか」に左右される傾向があります。着手前に次の4点は点検しておきたいところです。
共有フォルダに「規程_旧」「規程_最終版」「規程_最終版2」が同居している——よくある状況です。このまま取り込むと検索は古い版も等しく拾い、誤った回答の主要な原因になります。取り込み前に、どれが有効な版かを所管部門と確認し、旧版を対象から外す運用を決めておく必要があります。改定時に取り込み直す手順まで設計しておくと、運用開始後に陳腐化しにくくなります。
事故につながりやすいのがここです。人事評価や役員資料など、閲覧を限定すべき文書が対象に混ざっていると、権限のない社員の質問に対して、その内容が回答文の中に現れる可能性があります。元ファイルにアクセスできなくても、回答文として内容が出てしまえば同じことです。対策としては、（1）限定文書を対象範囲に入れない、（2）利用者の権限に応じて検索範囲を絞れる仕組みを選ぶ、のいずれかを最初に決めておきます。まずは全社公開レベルの文書に限定して始めるのが安全側の進め方です。
紙をスキャンしただけのPDFや画像として貼られた表は、そのままでは文字として読み取れず、検索対象から漏れます。文字認識（OCR）をかける手もありますが、精度は原本の状態次第です。複雑なレイアウトの表も、読み取れても文脈が崩れやすい傾向があります。対象文書のうちどれだけがテキストとして扱えるかを先に棚卸ししておくと、期待値のずれを防げます。
数百ページの資料が1ファイルにまとまっていると、該当箇所を特定しにくくなります。逆に細かすぎると、前後の文脈が欠けた断片が渡されて回答がずれます。章や項目ごとに区切られ、見出しが付いた文書ほど扱いやすいと考えておくとよいでしょう。負荷が高い場合は問い合わせの多い領域から順に整えるのが現実的です。
準備を尽くしても、回答に誤りが混じることは避けられません。検索が適切な箇所を拾えなかった場合や、複数の記述が矛盾している場合には、もっともらしい誤答が出ることがあります。
運用設計では「AIの回答をそのまま最終判断に使わない」ことを前提に置くのが安全です。具体的には、回答に出典（どの文書のどの箇所か）を表示させる、重要な判断は原文で確認する、対外的な回答は人の確認を挟む、といった組み合わせになります。利用ルールを文書化しておくと、現場も迷わずに使えます。
導入時の説明でも「調べる時間を短くする道具であって、判断を代行するものではない」と位置づけを共有しておくと、後の不信感を招きにくくなります。
「規程も引きたいし受注状況も見たい」という要望はよく出ますが、この二つは仕組みが異なります。文書はRAGで、システムの数値はデータ連携で——と経路を分けて設計するのが基本です。同じ画面から使える構成は可能ですが、裏側では別の仕組みが動いていると理解しておくと要件定義で混乱しません。連携方式の考え方は基幹システムとAIをつなぐ3つの型で整理しています。
また、基幹データを扱う場合は鮮度の要件（リアルタイムが必要か、日次で足りるか）と権限設計が新たに加わります。確認事項が増えるため、段階を分けて進めるほうが安全です。
利用するサービスの契約と設定によります。法人向けのサービスでは、入力データを学習に利用しない設定や契約条項が用意されていることが一般的ですが、提供事業者ごとに条件が異なるため個別の確認が必要です。データの保管先リージョン、保持期間、削除手続きも契約前に押さえておきたい項目です。
対象業務を一つに絞り、問い合わせが多い文書だけを整備して小さく試すのが失敗の少ない順番です。全社の文書を一度に取り込もうとすると整備だけで数ヶ月を要し、その間に熱が冷めるケースが見られます。範囲・体制・確認事項の洗い出しにはAI導入 設計アシスタントが使えます。
AIそのものより渡している文書側に原因があるケースが目立ちます。旧版が混在していないか、該当箇所がスキャン画像で読み取れていないか、そもそも答えが書かれた文書が対象範囲に入っているか——この順で確認すると切り分けが進みます。
RAGは仕組み自体は理解しやすい一方、成果を左右するのは文書整備と権限設計という地味な準備です。ここを飛ばすと、精度への不満か情報事故のどちらかに行き着きやすくなります。基幹システムとの接続も視野に入れる場合は、基幹・CRM連携チェックリストで確認項目を洗い出し、連携の3つの型と照らし合わせて進め方を決めるとよいでしょう。
本記事は一般的な考え方を整理した参考情報であり、特定製品の推奨や導入の成否・効果を保証するものではありません。実際の検討・判断は、自社のシステム仕様・社内規程・契約・関連法令に照らして専門家とご確認ください。