RAG入門：生成AIの精度を上げる手順集

RAG（Retrieval-Augmented Generation）は、生成AIに外部知識を参照させながら回答させる設計です。社内マニュアル、FAQ、議事録、製品仕様書のような手元の情報を検索し、その結果を根拠としてモデルに渡すことで、回答の再現性と説明しやすさを高められます。汎用モデルは言語生成に強い一方、社内固有のルールや最新資料は標準状態では知りません。そこで、質問のたびに関連文書を取得して文脈として追加するRAGが有効になります。生成AIを業務で使い始めると、「それっぽいが根拠が弱い」「最新版の規程とずれる」といった問題が起きがちですが、RAGはそのズレを小さくするための基本手段です。

第1章：RAGの仕組みと必要性

まず、RAGの流れは大きく三段階です。最初に、社内文書やWebページ、PDF、表計算ファイルなどを取り込み、検索しやすい形に整えます。次に、ユーザーの質問に応じて関連する断片を検索し、最後にその検索結果を生成AIへ渡して回答を作らせます。つまり、RAGは単なる「AIに資料を読ませる仕組み」ではなく、検索基盤と生成基盤をつなぐ設計そのものです。

一方で、RAGが必要になる背景はとても実務的です。たとえば情シス部門で「VPN接続エラー809の対処法は？」と質問されたとき、モデル単体では一般論は返せても、自社の認証方式、申請フロー、接続先の制約までは把握できません。営業支援でも「AプランとBプランの違いは？」と聞かれた際に、最新の価格表や注記を参照しなければ誤回答の原因になります。RAGを使えば、最新版の運用手順書、料金表、障害対応メモを検索してから回答させられるため、回答の根拠が業務データに寄ります。その結果、ハルシネーションの抑制だけでなく、回答の出典提示や監査対応も進めやすくなります。

さらに、RAGは「モデルを賢くする」より「根拠に寄せる」考え方だと理解すると導入判断がしやすくなります。学習済みモデルを追加学習で更新する方法は、コストや運用負荷が高く、文書更新にも追随しづらい面があります。その点、RAGは検索対象を差し替えれば最新情報を反映しやすく、部署ごとに知識ベースを分けることも可能です。たとえば人事向けには就業規則と申請書式、カスタマーサポート向けにはFAQと障害履歴、開発部門向けには設計書とAPI仕様を組み合わせる、といった構成が取りやすくなります。つまり、RAGは生成AIを業務文脈へ接続するための現実的な入口だといえます。

第2章：文書分割・埋め込み・検索の基本手順

次に、RAG構築で最初に詰まりやすいのが、文書をどう分けて、どう検索可能にするかです。一般的な流れは、文書を適度な長さに分割し、その断片ごとに埋め込みベクトルを作成し、ベクトルDBや検索エンジンへ格納する、というものです。ここで重要なのは、文書全体を丸ごと一件として保存しないことです。たとえば40ページの就業規則PDFを一つの検索単位にすると、質問が「育休復帰後の短時間勤務」に限られていても、AIには広すぎる文脈が渡ってしまいます。そこで、見出しや段落、表の区切りを活用しながら、意味が壊れない範囲でチャンク化します。実務では、300〜800字前後を起点にしつつ、前後100〜200字ほどのオーバーラップを持たせる設計が扱いやすいことが多いです。

埋め込みは、各チャンクの意味を数値ベクトルに変換する工程です。たとえば「パスワード初期化の手順」と「認証情報をリセットする方法」は表現が違っても近い意味として扱えるため、語彙が完全一致しなくても拾いやすくなります。ただし、ベクトル検索だけで十分とは限りません。ベクトル検索は概念的な近さに強く、キーワード検索は製品名、型番、エラーコード、法令名のような厳密一致に強いからです。たとえば「ESET」「Error 0x80072F8F」「第36条協定」のような文字列は、BM25系の全文検索を混ぜたほうが安定します。

そのうえで、検索結果をそのままAIに渡すのではなく、上位候補を再ランキングする設計も有効です。初回検索で集めた候補を意味的に並べ替える二段構成にすると、回答に必要な断片が先頭へ上がりやすくなります。たとえば社内FAQ、議事録、マニュアルが混在している場合でも、質問との関係が深い説明文を優先できます。また、メタデータ設計も見落とせません。文書種別、更新日、部門、製品名、版番号を保持しておけば、「2025年度版のみ」「人事部の正式文書だけ」といった絞り込みが可能です。結果として、文書分割、埋め込み、検索、再ランキング、メタデータ管理を一体で設計することが、RAG精度の土台になります。

第3章：回答品質を左右するプロンプト設計

検索がうまくいっても、最終回答の質はプロンプト設計で大きく変わります。RAGでは特に、「何を根拠に」「どのような形式で」「不足情報があるときはどう振る舞うか」を明示することが重要です。たとえば、単に「質問に答えてください」と書くよりも、「以下の参考情報のみを根拠に日本語で回答し、該当箇所がない場合は推測せず不明と記載する。最後に参照した文書名を列挙する」としたほうが、業務利用では安定します。つまり、検索結果を渡すだけではなく、その使い方までモデルに指定する必要があります。

実務で使いやすい構成は、役割、制約、入力、出力形式の四つを分ける形です。たとえば役割には「あなたは社内ヘルプデスク担当です」、制約には「参考情報にない内容を断定しない」、入力には質問文と検索結果、出力形式には「結論→理由→参照文書」の順で書く、といった指定を置きます。さらに、回答の長さや語調も決めておくと、チャットボットの体験がぶれにくくなります。たとえば問い合わせ一次対応なら200〜300字で簡潔に、管理者向け支援なら箇条書きで作業手順を明示する、といった使い分けです。加えて、引用や出典表示を促す文言を入れると、利用者が「なぜその答えになったか」を追いやすくなります。

また、プロンプトは一回で完成しません。たとえば、検索結果に複数の候補があるときに、モデルが似た文脈を混ぜてしまう場合があります。そのときは「最も関連性の高い断片を優先し、矛盾がある場合は最新版を採用する」「手順が複数ある場合は条件分岐を明記する」といった補助ルールを加えると改善しやすくなります。別の例では、社内規程の質問に対し一般論を混ぜてしまう場合、「一般知識ではなく、提供された社内文書を最優先する」と書くことで挙動が安定します。つまり、プロンプト設計は文章術ではなく、検索結果の使い方を制御する仕様設計です。RAGの精度が伸び悩むときは、検索だけでなく、この仕様の曖昧さも疑うべきです。

第4章：日本語RAGで起きやすい検索抜けの対策

日本語RAGでは、英語中心のサンプルどおりに作るだけでは検索抜けが起きやすくなります。理由の一つは、日本語が単語の区切りを明示しない言語だからです。たとえば「在宅勤務申請」「在宅 勤務 申請」「テレワーク申請」は、人間には近い意味でも、検索エンジンの設定によっては別物として扱われます。つまり、日本語検索では、埋め込み以前に正規化と形態素解析の品質が土台になります。

具体的な対策としては、まず表記ゆれを吸収します。たとえば「ログイン」「サインイン」「ログオン」、「生成AI」「生成ＡＩ」「LLM」、「社保」「社会保険」のような揺れを辞書や同義語設定でまとめると、検索ヒット率が上がります。次に、型番やエラーコード、製品名のような厳密一致が重要な項目は、ベクトル検索だけに頼らず全文検索を併用します。たとえば「MF-1234」「0x80070005」「A-210申請書」は、意味近傍よりキーワード一致のほうが強く働くことが多いため、BM25系の検索を混ぜる価値があります。

さらに、チャンクの切り方も日本語では重要です。英語では文境界が比較的取りやすい一方、日本語の業務文書は一文が長く、表や注記が本文中に混じることが少なくありません。そこで、見出し単位で切るだけでなく、箇条書き、表セル、注釈欄を別チャンクとして持つと検索漏れを減らせます。たとえば就業規則の本文と、表内の例外条件が別扱いになっているなら、表を文字列化して独立したチャンクにするだけで回答精度が上がることがあります。また、検索クエリの前処理として、全角半角統一、英数字の小文字化、不要な記号の整理を入れておくと安定します。つまり、日本語RAGは「モデルを変える」前に、「正規化」「辞書」「ハイブリッド検索」「チャンク設計」の四点を整えることで大きく改善できることが多いです。

第5章：精度評価と改善サイクルの回し方

最後に、RAGは作って終わりではなく、評価と改善を回して初めて実用水準へ近づきます。まず必要なのは、正解データを含む評価セットです。たとえば「質問」「期待される答え」「根拠文書」「重要キーワード」を一組にして20〜100件ほど用意すると、改善の方向性が見えやすくなります。つまり、評価は「答えが自然か」だけでなく、「正しい文書を取れたか」まで分解して見る必要があります。

実務では、評価観点を少なくとも三つに分けると改善しやすくなります。第一に検索品質です。期待した文書が上位3件または上位5件に入っているかを確認します。第二に回答品質です。結論が正しいか、重要条件を落としていないか、推測が混じっていないかを見ます。第三に運用品質です。回答時間、トークンコスト、出典表示の有無、更新後の追随性などを確認します。たとえば、FAQ回答の正答率は高くても、毎回10秒以上かかるなら問い合わせ窓口では使いにくいかもしれません。逆に、速度は速くても最新版の文書を拾わないなら、業務上の事故につながります。そのため、正答率だけに寄らず、検索・生成・運用の三層で指標を置くことが大切です。

改善サイクルは、小さな仮説で回すのが基本です。たとえば「質問文を検索用に言い換える」「チャンクサイズを600字から400字へ変更する」「ハイブリッド検索へ切り替える」「プロンプトに出典必須を追加する」といった変更を一つずつ試し、同じ評価セットで前後比較します。改善案を同時に複数入れると、何が効いたのか分からなくなるため注意が必要です。さらに、失敗事例を保存しておくと、再発防止に役立ちます。たとえば「略語で検索漏れ」「旧版を参照」「表の注記を落とす」といった失敗パターンをタグ化しておけば、次の改修方針が見えやすくなります。つまり、RAGの精度向上は魔法ではなく、検索基盤、プロンプト、評価セットを定期的に見直す地道な運用です。その積み重ねが、現場で信頼される生成AIにつながります。

RAGは、生成AIを業務に耐える形へ近づけるための基本技術です。仕組みだけを見ると複雑に見えますが、実務では「どの文書を、どの単位で、どう探し、どのルールで答えさせるか」を順に整えることが本質です。まずは社内FAQや手順書のような小さな範囲で試し、評価セットを用意したうえで改善を回してみてください。そこから検索基盤やプロンプト設計を育てていくことで、生成AIの回答品質は着実に上げられます。