RAG・社内ナレッジAIを導入する前に
整理すべき6つのこと

1. RAGとは何か — 社内文書を参照して根拠付きで回答するAI

RAG（ラグ、Retrieval-Augmented Generation：検索拡張生成）とは、ひとことで言えば「質問に答える前に社内の文書を検索し、見つかった内容を根拠として回答するAI」の仕組みです。「就業規則で慶弔休暇は何日でしたか」と聞くと、規程の該当箇所を探し出し、その記述に基づいて「◯◯規程の第◯条によると──」という形で答えてくれる。社内ナレッジAI・社内ChatGPTなどと呼ばれるものの多くは、この仕組みで作られています。

ChatGPTのような汎用のAIとの違いは明確です。汎用AIは一般に公開された情報などから学習したモデルであり、貴社の規程・マニュアル・過去の議事録の中身は知りません。RAGはその弱点を、「回答の直前に自社の文書を検索して読ませる」ことで補います。モデル自体を自社データで作り直す（再学習する）のに比べて、文書を差し替えれば知識を更新できるため、多くの企業にとって現実的な選択肢になっています。

ただし、最初に押さえていただきたいのは、RAGは「正解を保証する仕組み」ではないという点です。検索が適切な文書を見つけられなければ、AIは不十分な材料から回答を組み立てますし、生成AIには事実と異なる内容をもっともらしく述べる「ハルシネーション」と呼ばれる性質があり、RAGでもゼロにはなりません。さらに、参照した文書自体が古ければ、AIは古い内容を自信を持って答えます。つまりRAGの回答品質は、モデルの性能だけでなく、「どんな文書を・どんな状態で・誰に見せてよいものとして」渡すかで決まります。ここが本記事の主題です。

支援の現場でRAGの相談を受けるとき、多くの企業がベクトルDBやLLM（大規模言語モデル）の選定──つまり技術の話から入ろうとされます。しかし私たちの経験では、RAGの成否はその手前の「文書品質・権限・更新・検索粒度・回答評価・運用責任」の整理でほぼ決まります。技術選定は開発会社が支援できますが、この6つは自社にしか決められないからです。

2. RAGが向いている業務・向いていない業務

すべてのナレッジ業務がRAGに向くわけではありません。判断の目安は「答えが文書に書かれているか」です。

向いている業務 — 答えが文書のどこかに書いてある

• 社内規程・手続きの照会 — 「経費精算の締め日はいつか」「在宅勤務の申請方法は」など、総務・人事への定型的な問い合わせ対応
• マニュアル・仕様書の検索 — 製品仕様、操作手順、障害対応手順など、探すのに時間がかかっている文書の参照
• 過去事例・過去回答の再利用 — 過去の提案書・見積もりの考え方・顧客への回答履歴を、似た案件で参照する
• 新人・異動者のオンボーディング — 「これは誰に聞けばいいのか」という初歩的な質問の受け皿

向いていない業務 — 答えが文書にない、または判断そのもの

• 文書化されていない暗黙知への質問 — ベテランの頭の中にしかない判断基準は、まず文書化しなければRAGは答えられません
• 判断・承認そのもの — 「この契約条件を受けてよいか」のような意思決定は、根拠の提示までがAIの役割で、判断は人が行うべき領域です
• リアルタイムの数値参照 — 在庫数や売上の「今の値」は、文書検索ではなく基幹システムへの照会で扱うべき問題です
• 誤答が直ちに重大な影響を及ぼす回答の無人運用 — 法令解釈や医療・安全に関わる回答を、人の確認なしに外部へ返す使い方は避けるべきです

「向いていない業務」に挙げたものは、RAGが役に立たないという意味ではありません。暗黙知は文書化すれば対象になりますし、判断業務も「関連する規程と過去事例を並べて提示する」ところまでは大きく支援できます。線を引くべきなのは「最後に確定させるのは誰か」であり、それは6項目の整理の中で決めていきます。

3. 導入前に整理すべき6つのこと

ここからが本題です。開発会社に相談する前に、次の6項目を整理してください。完璧である必要はありませんが、「未検討」のまま開発に入ると、後述する失敗のいずれかを高確率で踏みます。

① 対象文書の範囲と品質 — 「全部入れる」から始めない

最初に決めるのは「どの文書を読ませるか」です。ここで「共有フォルダを丸ごと」と答える企業が多いのですが、共有フォルダには通常、完成版と下書き、現行版と廃止版、部署ごとに微妙に違う同名のマニュアルが混在しています。AIは文書の「格」を区別できません。下書きも廃止版も等しく根拠として扱うため、入れる文書の品質がそのまま回答の品質になります。まずは対象を絞り、その範囲だけでも「正のドキュメントはどれか」を確定させることが、精度への最大の投資です。

② 文書の最新版管理 — 「最新版はどれか」を機械が判別できるか

①と似ていますが、こちらは時間軸の問題です。「規程_v3_最終_修正済.docx」のようなファイル名運用では、人間ですらどれが最新か迷います。改定履歴の管理方法、旧版の保管場所（対象フォルダから外す）、ファイルの命名規則──この整理は地味ですが、「AIが古いことを言う」というRAG最頻出の失敗を防ぐ土台になります。

③ アクセス権限 — 誰が何を見てよいかを先に決める

RAGは「検索して答える」仕組みである以上、検索の段階で権限を効かせなければ、質問ひとつで情報が漏れます。一般社員が「役員の報酬規程を教えて」と聞いたとき、答えてよいのか。人事評価の資料は誰まで見えてよいのか。既存のファイルサーバーやグループウェアの権限設定と連動させるのか、RAG側で別に定義するのか。ここは後から直すのが最も難しい項目であり、開発会社への要件として最初に伝えるべき内容です。迷う場合は、権限が単純な文書（全社員に公開してよいもの）だけから始めるのが安全です。

④ 更新フロー — 導入した日がピークにならないために

RAGは導入した瞬間が最も正確で、放置すれば現実とのズレが広がる一方です。規程が改定されたとき、製品仕様が変わったとき、誰が・いつまでに・どうやってAIの参照文書を更新するのか。文書の持ち主（規程なら総務、仕様なら開発部門）と更新の期限をあらかじめ決めておかないと、「更新は情シスの善意頼み」になり、確実に形骸化します。あわせて、検索しやすい文書の粒度（1文書に何でも詰め込まず、テーマごとに分ける・見出しを付ける）を書き手側のルールにしておくと、検索精度と更新のしやすさの両方が上がります。

⑤ 回答できない時の挙動 — 「わからない」と言えるAIにする

実運用で必ず発生するのが「文書に答えがない質問」です。このときAIに推測で答えさせるのか、「該当する文書が見つかりませんでした」と正直に言わせるのか、担当部署への問い合わせ先を案内させるのか。信頼されるナレッジAIの条件は、正答率の高さ以上に「知らないことを知らないと言えること」です。あわせて、回答に必ず根拠（参照した文書名・該当箇所）を表示させ、利用者が原文を確認できるようにする──この2つは要件として必ず開発会社に伝えてください。

⑥ 評価用の質問と正解データ — 精度を「感想」でなく測る

最後が、最も見落とされる項目です。RAGの精度は「なんとなく賢い」という感想では評価できません。実際に現場から来そうな質問30〜50問と、期待する回答（および根拠となる文書の箇所）のセットを、導入前に現場の協力を得て作っておきます。これがあると、開発中のチューニングの効果測定、リリース判定、導入後の劣化検知のすべてに同じ物差しを使えます。逆にこれがないと、開発会社側も「何をもって完成とするか」を決められず、プロジェクトの終わりが曖昧になります。

4. よくある失敗5つと対策

相談の場でよく伺う失敗パターンを5つ挙げます。いずれも技術の失敗ではなく、前章の6項目のどれかが未整理だったことに起因します。

強調したいのは、これらの失敗はすべて「導入前」に予防できるということです。導入後に権限設計をやり直したり、文書を全面整理したりするのは、最初にやる場合の何倍もの手間がかかります。開発会社の技術力で挽回できる範囲ではないため、発注前のこの段階こそが、プロジェクト全体で最も費用対効果の高い時間だと考えてください。

5. 最小構成で始める — 1部門・1文書種から

6項目を前にして「これを全社の文書でやるのは無理だ」と感じられたかもしれません。その感覚は正しく、だからこそ全社でやらないことが正解です。おすすめする最小構成は次の形です。

1. 対象を「1部門・1文書種」に絞る — 例：総務部門の「社内規程・申請手続き」だけ。問い合わせが多く、答えが文書に書いてあり、権限が単純（ほぼ全社員に公開してよい）な領域が最適です。
2. その範囲だけ6項目を整理する — 対象文書は数十点程度になり、正の文書の確定・旧版の隔離・評価用質問30問の作成が現実的な作業量に収まります。
3. 利用者も限定して検証する — まず総務部門自身や特定部署だけで1〜3ヶ月使い、評価用質問での正答率と、根拠表示が機能しているかを確認します。
4. 成功の型を持って広げる — うまくいったら、文書整理の手順・権限の考え方・評価のやり方をそのまま次の文書種（例：営業マニュアル、開発仕様書）に横展開します。

この進め方の利点は、投資が小さく済むことだけではありません。「文書をどう整理すればAIがうまく答えられるか」という自社なりのノウハウが、最初の1領域で確立できることです。RAGの拡張は文書種の追加であり、型があれば2つ目以降は格段に速くなります。逆に最初から全社ナレッジを対象にすると、整理しきれない文書が精度を下げ、「うちのAIは使えない」という空気だけが全社に広がります。

6. 開発会社に相談する時に確認すべき技術論点

6項目が整理できたら、開発会社への相談です。技術の詳細は先方の専門領域ですが、次の質問は非エンジニアの責任者こそ確認すべき論点です。そのまま打ち合わせでお使いください。

• 「検索はどういう仕組みですか。キーワード検索と意味検索の使い分けは？」 — RAGの多くは、文章を意味の近さで探せる数値の並びに変換する「エンベディング」という処理を行い、それを「ベクトルDB」（意味の近い文章を高速に探せるデータベース）に保管して検索します。社内用語や型番のような固有の言葉はキーワード検索のほうが強いことも多く、両者の併用（ハイブリッド検索）を含めた設計方針を確認しましょう。
• 「アクセス権限はどの段階で効かせますか？」 — 「回答時に隠す」のではなく「検索の段階で、その人が見てよい文書しか対象にしない」設計かどうか。既存のファイルサーバーやグループウェアの権限と連動できるかも確認します。
• 「回答に根拠（参照文書と該当箇所）は表示されますか？」 — 根拠表示は誤答の検証と利用者の信頼に直結する必須機能です。原文へのリンクまで辿れるかを確認しましょう。
• 「文書を更新したら、いつ回答に反映されますか？」 — 即時か、夜間の一括処理か、手動作業が必要か。④で決めた更新フローと噛み合うかを見ます。
• 「精度はどうやって評価しますか？」 — ⑥で作った評価用質問セットを渡し、それを使った評価とリリース判定に合意できるかを確認します。ここで具体的な方法が返ってこない会社は注意が必要です。
• 「入力したデータや文書は、AIモデルの学習に使われませんか？」 — 利用するAIサービスのデータの取り扱い（学習への利用有無・保管場所・保管期間）を、契約前に書面で確認しましょう。
• 「費用はどういう構造ですか？」 — 開発費のほかに、AIの利用量に応じた従量課金（使った分だけ毎月かかる費用）と保守費が発生するのが一般的です。利用者数や質問数が増えた場合の見通しまで確認します。

これらの質問に、専門用語を平易に言い換えながら答えてくれるかどうかは、その会社が「作って終わり」ではなく運用まで見据えているかを測るよい試金石にもなります。

7. RAG導入前チェックリスト

ここまでの内容を、開発会社に相談する前のチェックリストにまとめます。

10項目のうち8つ以上にチェックがつけば、開発会社との打ち合わせは要件の議論から始められます。逆にチェックが半分以下の状態で見積もりを取ると、前提が曖昧なぶん金額には安全マージンが乗り、開発が始まってからの仕様変更で期間も費用も膨らみがちです。この整理自体が、最も確実なコスト削減だとお考えください。

整理の次にやること

チェックリストが埋まったら、進む順番は「開発会社への相談・要件のすり合わせ → 小規模構築 → 評価用質問での検証 → 利用範囲の拡大と運用定着」です。なお、この整理を自社だけで進めるのが難しい場合は、整理の段階から外部の支援を受けるのも一つの方法です。文書の棚卸しや業務側の要件定義は、AI導入全般に共通する基礎体力であり、RAG以外の施策にもそのまま活きます。

よくある質問