社内文書の検索（RAG）を業務に入れるかどうかは、「文書が整っているか」「間違えたときの影響をどう吸収するか」「正解をどう確かめるか」の3点でほぼ決まります。検索の精度を上げる技術はその後の話です。この記事では、問い合わせ対応を例に、RAGを業務に入れる前に確認したい判断ポイントを7つに分けて説明します。
RAGとは何をする仕組みか
RAG（Retrieval-Augmented Generation、検索拡張生成）は、質問に関係する社内文書を先に検索し、その内容を生成AIに渡して回答を作らせる仕組みです。生成AIは一般的な知識は持っていても、自社の製品仕様や社内規程は知りません。知らないことをもっともらしく答えてしまうこともあります。RAGは、回答の材料を社内文書に限ることで、この弱点を補います。
仕組みとしては、文書を適当な長さに区切り（チャンク分割）、質問と内容が近い部分を探し出し、その部分を根拠として回答させる、という流れです。意味の近さで探すベクトル検索と、単語の一致で探すキーワード検索を組み合わせる方法もよく使われます。
例：製品の問い合わせ対応
産業用ポンプを扱う会社で、販売店や顧客からの技術的な問い合わせをサポート担当が受けているとします。
- 問い合わせは月に数百件、電話とメールで届く
- 回答には製品カタログ、取扱説明書、過去の問い合わせ記録、技術部門の社内メモを使う
- 経験の長い担当者は即答できるが、新しい担当者は資料探しに時間がかかり、技術部門に質問が集中する
依頼は「社内文書を使って回答案を出すAIを入れたい」です。ここから判断ポイントを順に見ていきます。
判断1：本当にRAGが必要か
最初に、問い合わせの中身を分類します。過去の記録を数十件読むと、たいてい次のように分かれます。
| 問い合わせの種類 | 向いている手段 |
|---|---|
| 型番ごとの仕様値（流量、寸法など）を知りたい | 製品マスタの検索画面。決まった値を返すだけでよい |
| よくある質問（保証期間、納期の目安） | FAQページの整備 |
| 症状から原因と対処を知りたい（異音がする、圧力が上がらない） | 取扱説明書と過去記録を参照するRAGが向いている |
| 見積や在庫の確認 | 基幹システムの照会。生成AIは不要 |
決まった値を返すだけの問い合わせに生成AIを使うと、かえって誤回答の危険が増えます。手法の選び分けはAIと最適化の記事で整理しています。RAGの対象は、文書を読み合わせて答える必要がある種類に絞ります。
判断2：文書の状態は使えるか
RAGの回答は、渡した文書の質を超えません。導入前に次を確認します。
- どれが最新版か分かるか：同じ取扱説明書の旧版と新版が並んでいると、旧版の内容で回答することがある
- 形式：スキャンした画像のPDFは、そのままでは文字として検索できない。文字起こしが必要になる
- 書かれていない知識：経験者が頭の中に持っている判断（この症状ならまず配管を疑う）は文書にない。必要なら先に書き起こす
- 社内メモの扱い：技術部門の非公式なメモに、顧客に出してはいけない内容が混じっていないか
文書の棚卸しをすると、RAGを入れる前に「文書を整理するだけで新人の資料探しがかなり楽になる」と分かることもあります。
判断3：誰にどの文書を見せてよいか
社内文書には、部署や役職によって見てはいけないものがあります。RAGの検索対象に入れた文書は、回答の中に引用されて表に出る可能性があります。総務省の令和8年版情報通信白書でも、生成AIと社内データの連携が進むなかでアクセス権限をより慎重に設定する必要が出ていること、先進的な企業ではAIが参照するデータの範囲を絞るなどの対策がとられていることが紹介されています。
この例では、販売店向けに出してよい文書と、社内限りの文書を分け、まずは社内のサポート担当だけが使う形にしました。
判断4：間違えたときの影響をどう吸収するか
生成AIの回答は確率的で、同じ質問でも揺れることがあります。そのため、間違えたときに何が起きるかで、業務フローの組み方を変えます。
| 用途 | 誤回答の影響 | 業務フローの組み方 |
|---|---|---|
| 担当者が資料を探す補助 | 担当者が根拠を見て気づける | 回答と一緒に根拠の文書と該当箇所を必ず表示する |
| 顧客への回答案の作成 | 誤った案内が外に出る | 担当者が確認してから送る。送信は人が行う |
| 顧客が直接質問する窓口 | 確認なしで外に出る | 対象を限定し、答えられない質問は人につなぐ |
この例では最初の段階として「担当者が資料を探す補助」から始め、回答には必ず根拠の文書名と該当部分を付けることを要件にしました。
判断5：正解をどう確かめるか
「使ってみたら良さそう」では、導入の判断も改善もできません。過去の問い合わせ記録から、質問と正しい回答の組を50件ほど作り、評価用の質問セットにします。
- 正しい文書を探し出せたか（検索の評価）
- 回答の内容が正しいか（生成の評価）
- 答えられない質問に「分からない」と返せたか
検索で正しい文書が見つかっていなければ、文書の区切り方や検索方法を見直します。文書は見つかっているのに回答が間違っているなら、回答の指示を見直します。どちらで失敗しているかを分けて見ると、改善の手が打ちやすくなります。型番のような正確な文字列で探す質問はキーワード検索のほうが強いことが多く、こうした傾向も質問セットで確かめられます。
判断6：使う人の流れに入るか
検索画面を別に作っても、サポート担当が普段使っている問い合わせ管理の画面から離れないと使えないなら、使われなくなります。誰が、問い合わせ対応のどの時点で、どの画面から使うのかを業務フローの中に書き込みます。回答案をそのまま返信文に貼れるか、根拠の文書をすぐ開けるかといった細部が、定着に効きます。
判断7：文書の更新を誰が担うか
製品の改良や説明書の改訂があれば、検索対象の文書も更新が必要です。更新の担当者、更新のタイミング、古い版を検索対象から外す手順を、導入前に決めておきます。また、評価用の質問セットに回答の誤りが見つかったものを足していくと、改善の記録が残ります。
小さく始めるときの順番
7つの判断を踏まえると、最初の段階は次のような順番で進めると無理がありません。
- 過去の問い合わせを分類し、RAGの対象にする種類を1つか2つに絞る
- その種類に必要な文書だけを集め、最新版をそろえて社内限りの内容を外す
- 過去の記録から評価用の質問セットを作る
- 社内の担当者向けに、根拠つきで回答案を出す形で試す
- 2〜4週間使ってもらい、質問セットの正答率と、担当者が実際に使った回数・資料探しの時間を導入前と比べる
- 結果を見て、対象の種類を広げるか、文書や検索方法を見直すかを決める
対象を広げるのは、狭い範囲で「根拠を見れば担当者が正しさを確かめられる」状態ができてからにします。最初から全文書・全問い合わせを対象にすると、どこで精度が落ちているのかが分からなくなります。
よくある失敗
- 何でもRAGで解こうとする：仕様値や在庫のように決まった値を返すものまで生成AIに任せ、誤回答が増える
- 文書を整理せずに全部入れる：旧版や社内限りのメモが回答に混じる
- 根拠を表示しない：担当者が回答を確かめられず、結局は使われなくなる
- 評価の質問セットを作らない：精度が上がったのか下がったのか、誰も判断できない
- 更新の担当を決めない：半年後に古い情報で回答するようになる
この記事のまとめ
- RAGは社内文書を検索し、その内容を根拠に生成AIに回答させる仕組み
- 導入前に問い合わせを分類し、文書を読み合わせる必要がある種類に対象を絞る
- 文書の最新版・形式・書かれていない知識・社内限りの内容を確認する
- 検索対象の文書は回答に出る前提で、見せてよい範囲を決める
- 誤回答の影響に応じて、根拠の表示や人の確認を業務フローに組み込む
- 過去の記録から評価用の質問セットを作り、検索と生成を分けて評価する
- 使う人の画面の流れと、文書を更新する担当まで決めておく
この記事の内容は、ロードマップのStep 6「進めて作る」にあたります。生成AI導入の全体の状況は日本企業の生成AI導入の現状の記事にまとめています。RAGの技術（埋め込み、チャンク分割、検索の組み合わせ）を手を動かして学ぶなら、FDEガイドのAIプロダクト開発カリキュラムを、手法の選び分けはAIと最適化を参照してください。演習はlecture.iplot.jpで取り組めます。