社内ナレッジをAIに回答させる仕組み(RAG入門)｜RAGだけに頼らない方式の選び方

「社内のマニュアルや規定を AI に読ませて、質問に答えさせたい」──それを実現する仕組みとして最も広く知られているのが RAG(ラグ / Retrieval-Augmented Generation・検索拡張生成)です。RAG は AI を作り直したり再学習させたりする技術ではなく、質問が来るたびに社内資料の中から関連する箇所を検索し、見つけた根拠をもとに回答文を組み立てる、「検索」と「生成」の組み合わせです。ただし先に言っておくと、RAG は唯一の方式ではありませんし、万能でもありません。この記事では、RAG が回答を作る流れを 5 つのステップで解説した上で、精度チューニングの現実と、もう一つの有力な選択肢(厳選したナレッジを構造化して参照させる方式)まで含めた「目的に合う方式の選び方」を扱います。

RAG とは ── 生成 AI に「自社の事実」を答えさせる代表的な仕組み

まず前提から整理します。ChatGPT や Gemini のような生成 AI は、インターネット上の公開情報を学習して作られています。そのため一般的な知識には答えられますが、あなたの会社の就業規則・製品仕様・料金規定・過去の対応履歴は知りません。さらに厄介なのは、知らないことを聞かれたときに「知らない」と言わず、それらしい文章を作ってしまうことがある点です(ハルシネーションと呼ばれる現象です)。

この 2 つの問題──「社内の事実を知らない」「知らないのに作ってしまう」──を解決するアプローチとして、最も広く知られているのが RAG です。試験にたとえると分かりやすくなります。AI に社内知識を暗記させ直す(再学習させる)のではなく、「持ち込み資料」を渡して、その資料の範囲で答えさせる持ち込み可の試験方式に変える。これが RAG の発想です。質問のたびに資料の該当ページを開いて渡すので、AI は自分の記憶ではなく、目の前の根拠をもとに答えます。

似た選択肢としてよく比較されるのが、AI 本体に社内データを追加学習させる「ファインチューニング」です。両者は排他的な技術ではありませんが、社内ナレッジに回答させる用途では性質がかなり違います。

更新のしやすさと根拠の示しやすさから、「社内の事実を正確に答えさせる」用途では、ファインチューニングより「外部の知識を参照して答える」系のアプローチが先に挙がるのが一般的です。なお、顧客対応の文脈では、この考え方は「一問一答 FAQ を作り込まなくても動くチャットボット」として製品化が進んでいます。「FAQ作り込み不要のAIチャットボットとは」で書いたとおり、「探して、根拠にして、答える」を実現する方式は製品によってさまざまで、RAG はその代表例の一つです。本記事ではまず代表例である RAG の中身を理解し、その上で RAG 以外の選択肢まで含めた選び方を見ていきます。

RAG が回答を作る流れ ── 5 つのステップ

冒頭のロードマップに示した 5 ステップを、順に中身まで見ていきます。ステップ 1〜2 が「準備」、3〜4 が「質問が来るたびに毎回動く処理」、5 が「運用」です。

ステップ 1: 知識源の取り込み ── 「何を読ませるか」を決める

最初にやることは、AI の知識源にする資料を決めて登録することです。対象になるのは、マニュアル、規定集、製品仕様書、案内文書、社内 wiki、過去の問い合わせ対応ログなど、すでに社内にある文書です。PDF・Word・スプレッドシート・Web ページなど、多くの形式がそのまま扱えます。

ここでの勘所は「全部入れない」ことです。手元の資料を一括投入したくなりますが、旧版の規定が混ざっていると、AI は旧版を根拠に堂々と古い回答を作ります。検索は「正しい資料」と「古い資料」を区別できません。質問が実際に多い領域から、最新版だけを選んで入れる──この選別が、後続のすべてのステップの精度の土台になります。

ステップ 2: チャンク分割と索引化 ── 資料を「検索できる単位」に刻む

登録した資料は、そのままの形では検索に向きません。そこで資料を数百文字程度の断片(チャンク)に分割します。チャンクが大きすぎると 1 つの断片に無関係な話題が混ざって検索の的が甘くなり、小さすぎると文脈が切れて「何の話か」が分からない断片になります。分割の粒度は RAG の代表的なチューニングポイントです。

次に、各チャンクを「埋め込み(エンベディング)」という処理で、意味を表す数値の並び(ベクトル)に変換し、索引として保存します。数値化のポイントは、キーワードの一致ではなく「意味の近さ」で探せるようになることです。たとえば「解約したい」と「契約をやめたい」は使っている単語が違いますが、意味が近いので数値空間上では近い場所に置かれます。従来のキーワード検索では取りこぼしていた「言い回しの揺れ」に強いのは、この仕組みのおかげです。

ステップ 3: 質問に関連する箇所を検索する

ユーザーから質問が来ると、質問文も同じ方法で数値化され、索引の中から意味が近いチャンクの上位数件が取り出されます。この検索処理は毎回の質問ごとに行われるため、資料を更新すれば次の質問から新しい内容が使われます。

実務上いちばん重要な事実をここで書いておきます。検索で正しい箇所が取れなければ、後段の生成がどれだけ賢くても正しい回答は出ません。RAG の回答品質に不満があるとき、原因の多くは生成 AI 側ではなく、この検索段階(そしてその手前の資料とチャンクの質)にあります。「検索の失敗は、生成では挽回できない」──RAG を評価・改善するときの基本の視点です。

ステップ 4: 根拠を添えて回答を生成する

検索で取り出したチャンクを、元の質問と一緒に生成 AI へ渡します。このとき「渡した資料の範囲で答えること」「資料にないことは、ないと答えること」という指示を添えるのが標準的な作り方です。AI は渡された根拠をもとに、質問への回答文を自然な文章として組み立てます。

ハルシネーション対策の中核はこの設計にあります。自由に記憶から答えさせるのではなく、根拠を渡し、その範囲に縛る。さらに回答に「どの資料のどの箇所を根拠にしたか」を併記させる構成にすれば、利用者側が回答の確からしさを検証できるようになります。社内利用では、この出典表示が「AI の回答を信じてよいか」の不安を下げる効果的な仕掛けになります。

ステップ 5: 評価と更新 ── 作って終わりにしない

RAG は「作った日がいちばん精度が低く、運用で伸びていく」仕組みです。公開後は、答えられなかった質問と、ズレた回答のログが最良の改善材料になります。資料に情報が足りなかったのか、資料はあるのに検索で取れなかったのか、取れたのに回答の組み立てが悪かったのか──原因の切り分けごとに、資料の追加・チャンク分割の調整・指示文の改善という打ち手が対応します。

なお、回答品質をどう測るか(テスト質問セットの作り方・公開前検証の観点)は、それ自体が 1 つの独立したテーマです。本記事では「ログを見て資料と設計に戻す」という原則までにとどめ、評価の具体的な手順は別記事で詳しく扱う予定です。

RAG の現実 ── 精度チューニングは「入れて終わり」にならない

仕組みだけを見ると、RAG はシンプルで筋の良い方法に見えます。実際、筋は良いのです。ただ、「動くものを作ること」と「業務で信頼される精度を保つこと」の間には、はっきりした距離があります。RAG を検討するなら、次の 4 つの難所を最初から見積もりに入れておくことをおすすめします。いずれも特定の製品の欠点ではなく、「広い資料群を検索して答える」方式に構造的についてくる仕事です。

• ①チャンク分割に唯一の正解がない ── 分割の粒度や区切り位置で検索結果が変わります。規定集・マニュアル・対応ログでは適した刻み方が違うため、資料の種類ごとに試行錯誤が必要になります。
• ②検索には当たり外れがある ── 「意味の近さ」は万能ではありません。似た規定・例外条項・紛らわしい断片を上位に出してしまうことがあり、質問の言い方によって取れる箇所が揺れます。
• ③根拠の取り違えが起きる ── 「関連はするが答えではない」断片が渡ると、AI はそれを根拠にそれらしく間違えます。複数の文書の情報を 1 つの回答に混ぜてしまうケースもあります。
• ④評価と改善が運用として続く ── テスト質問の整備、ログの分析、資料の手入れ、分割や指示文の調整。これらは一度やって終わりではなく、資料と質問が変わり続ける限り続く仕事で、担当者の継続稼働が前提になります。

これは「RAG はやめておけ」という話ではありません。知識の範囲を広く取れる方式は、その分だけ検索の設計と運用に仕事が乗る、という構造の話です。この構造を正直に見積もると、「そもそも自分たちの用途に、どこまで広い検索が必要か?」という問いが出てきます。それが次のセクションです。

もう一つの選択肢 ── 厳選ナレッジを「構造化して必要な分だけ」参照させる方式

RAG が「雑多な資料群を、検索でどこでも当たれるようにする」方式だとすると、逆の発想もあります。答えるべき領域を先に絞り、人が厳選・整理したナレッジを構造化して、AI が質問に応じて必要な分だけ読みに行く方式です。ナレッジを「全体の案内図 → 分野ごとのまとまり → 詳細」のような階層に整理しておき、AI はまず案内図を見て、該当する分野の詳細だけを開いて答えます。ベクトル検索に頼らず、構造そのものが「どこを読むべきか」の道しるべになります。

この方式には、先ほど挙げた RAG の難所と対になる利点があります。

• ①取り違えが構造的に起きにくい ── 知識源は人が厳選済みで、旧版や紛らわしい断片がそもそも入っていません。検索の当たり外れに悩む場面が大きく減ります。
• ②回答が安定する ── 同じ質問には同じナレッジが参照されるため、検索結果の揺れによる回答のブレが小さくなります。範囲外の質問には「答えない」がはっきりします。
• ③更新の運用が軽い ── 「この回答を変えたければ、この文書を直す」という対応関係が明確です。チャンクや索引の再調整ではなく、該当ナレッジの差し替えで済みます。

もちろん、この方式にも向き不向きがあります。知識範囲が広く雑多な用途──全社の文書を横断して「何でも」探させたい調査支援のような使い方──には向きません。また、立ち上げ時に人がナレッジを厳選・構造化する整理の仕事があります(RAG でも資料整備は必要ですが、こちらは整理の質により深く投資する方式です)。つまりトレードオフは「範囲の広さを取るか、絞った範囲での精度の安定と運用の軽さを取るか」です。

カスタマーサポートは、後者が向く典型例です。質問の大半は製品・サービスの周辺に集中していて領域を絞りやすく、その一方で誤案内のコストが高い。範囲の広さより「絞った範囲で確実に答えること」が価値になる用途だからです。どちらの方式が新しい・優れているという話ではなく、知識の範囲・求める精度・回せる運用体制で選ぶ──方式選びの結論はこれに尽きます。

どの方式でも精度は「資料の質と設計」で決まる ── 導入前にやる 3 つの整備

方式の違いを見てきましたが、共通する土台があります。RAG でも厳選ナレッジ構造化型でも、回答の精度を最終的に決めるのは AI モデルの賢さではなく、知識源の資料の質と運用の設計です。導入前にやっておくべき整備は、方式を問わず次の 3 つに集約されます。

自社で作るか、サービスを使うか

RAG は主要なクラウドサービスやオープンソースのフレームワークが部品を提供しており、技術者がいれば試作(PoC)自体は組めます。厳選ナレッジ構造化型も、ナレッジの整理と生成 AI の組み合わせで小さく試すことは可能です。ただし、ここまで見てきたとおり、本番運用には検索やナレッジのチューニング、答えられない時の分岐、評価と更新の運用、セキュリティ設計が継続的に必要です。判断基準はシンプルで、目的が「技術の理解・検証」なら自社開発は学びが大きく、目的が「業務で使う回答窓口を早く安定稼働させること」なら、方式の設計と運用ごと提供されるサービスに乗る方が確実です。

とくに顧客向けの窓口(HP のチャットボット)は、24 時間の安定稼働・誤案内時の切り替え・継続改善まで求められるため、本番運用設計の比重が社内利用より大きくなります。顧客対応の負荷を下げる打ち手全体の中でチャットボットをどう位置づけるかは「コールセンターの問い合わせを削減する方法【完全ガイド】」で整理しています。

当社の「コルット」は、本記事の分類で言う厳選ナレッジ構造化型の顧客対応 AI チャットボットです。ベクトル検索で資料群を漁るのではなく、マニュアル・規定・対応ログから厳選・整理したナレッジを構造化し、AI が質問に応じて必要な分だけ参照して答えます。カスタマーサポートという「領域が絞れて、誤案内のコストが高い」用途に合わせた方式選択です。初期のナレッジ整備・構築は当社が伴走し、答えられない質問は有人対応へ即時に切り替えます。設置は HP に専用タグを 1 行貼るだけ、最短 3 日で本番稼働します。

よくある質問