RAG（Retrieval-Augmented Generation）構築の手順は、文書準備・ベクトル化・検索設計・プロンプト調整の4段階に分かれます。社内文書を生成AIで活用するには、どの文書を対象にするか決め、検索精度を高める構造設計を行い、回答品質を検証する工程が必要です。この記事では、各フェーズで何をどう判断するか、実装の順序と選択基準を示します。

RAG構築の手順｜全体の流れと各フェーズの目的

RAG構築は次の4フェーズで進めます。各フェーズは独立して完結させ、次に進む前に動作確認と評価を行います。

  • フェーズ1：文書選定と前処理 — 対象文書を決め、AIが読み込める形式に整える
  • フェーズ2：ベクトル化とインデックス構築 — 文書を数値表現に変換し、検索可能な状態にする
  • フェーズ3：検索ロジックの設計 — ユーザーの質問から適切な文書を取り出す仕組みを作る
  • フェーズ4：プロンプト設計と回答生成 — 検索結果をもとに、正確な回答を生成する指示文を作る

各フェーズは前の段階の出力を入力として受け取るため、順序を入れ替えることはできません。フェーズ1で文書の品質が低いままフェーズ2に進むと、ベクトル化の精度が下がり、後工程での修正コストが増大します。

フェーズ1：文書選定と前処理｜対象範囲の決定と構造化

最初に決めるのは、どの文書をRAGの対象にするかです。社内文書は種類・フォーマット・更新頻度が多様であり、すべてを一度に取り込むことは推奨されません。対象を絞る基準は次の通りです。

  • 更新頻度が低い文書 — 規程・マニュアル・技術仕様書など、内容が安定しているもの
  • 参照回数が多い文書 — 問い合わせ対応・新人教育で繰り返し使われるもの
  • 構造が明確な文書 — 章立て・見出し・箇条書きで整理されているもの

選定後、文書を前処理します。前処理の目的は、AIが意味を正確に抽出できる形式に整えることです。具体的な作業は次の通りです。

  • テキスト抽出 — PDF・Word・PowerPointから文字情報を取り出す。OCRが必要な画像化PDF は精度を事前確認する
  • 不要情報の削除 — ヘッダー・フッター・ページ番号・図表キャプションのみの行を除去する
  • チャンク分割 — 1つの検索単位（チャンク）を300〜500トークン程度に区切る。見出し単位で区切ると意味の一貫性が保たれる

チャンク分割は検索精度に直結します。1チャンクが長すぎると無関係な情報が混入し、短すぎると文脈が失われます。見出しや段落の区切りを基準にすることで、意味のまとまりを維持できます。

フェーズ2：ベクトル化とインデックス構築｜検索基盤の作成

前処理した文書を、ベクトル（数値の列）に変換します。ベクトル化には埋め込みモデル（Embedding Model）を使用します。埋め込みモデルは文章の意味を数値で表現し、意味が近い文章同士は近い数値になるよう学習されています。

ベクトル化の手順は次の通りです。

  1. 埋め込みモデルの選択 — OpenAIのtext-embedding-ada-002、AzureのAda、Cohereのembed-multilingual等から選ぶ。日本語文書にはmultilingual対応モデルを使う
  2. チャンクごとにベクトル生成 — 各チャンクをモデルに入力し、1536次元や768次元のベクトルを取得する
  3. ベクトルデータベースへの格納 — 生成したベクトルをPinecone・Weaviate・Chroma等のベクトルDBに保存する

ベクトルデータベースは、類似度計算を高速に実行するインデックス構造を持ちます。ユーザーの質問もベクトル化し、データベース内のチャンクベクトルと比較することで、意味的に近い文書を取り出します。

ベクトル化の精度を確認するには、既知の質問と期待される文書のペアを10〜20件用意し、正しい文書が上位3件以内に返ってくるかテストします。期待した文書が返らない場合、チャンク分割の単位を見直すか、埋め込みモデルを変更します。

フェーズ3：検索ロジックの設計｜適切な文書を取り出す仕組み

ベクトル検索だけでは不十分なケースがあります。ユーザーの質問が曖昧な場合や、複数の文書にまたがる情報が必要な場合、検索結果の精度が下がるためです。検索ロジックを設計する際は、次の要素を組み合わせます。

  • ハイブリッド検索 — ベクトル検索（意味的類似度）とキーワード検索（完全一致）を併用し、両方の結果を統合する
  • メタデータフィルタ — 文書の種類・作成日・部署等のメタデータで絞り込み、関係ない文書を除外する
  • リランキング — 検索上位10〜20件を別のモデルで再評価し、質問との関連度が高い順に並べ替える

ハイブリッド検索は、型番・製品名・規程番号など固有名詞を含む質問に有効です。ベクトル検索だけでは類似する別の製品が返ることがあるため、キーワード検索で正確な一致を確保します。

メタデータフィルタを設定する場合、文書にタグ付けする必要があります。例えば「部署:人事」「種別:規程」「更新日:2024-01-15」のようなメタデータを各チャンクに付与し、検索時に条件として指定します。これにより、特定部署のマニュアルのみを対象にした検索が可能になります。

フェーズ4：プロンプト設計と回答生成｜正確な出力を得る指示文

検索で取得した文書を、生成AIに渡して回答を作らせます。このとき、どのような指示文（プロンプト）を与えるかで、回答の正確性と形式が変わります。プロンプトには次の要素を含めます。

  • 役割定義 — 「あなたは社内規程に詳しいアシスタントです」のように、AIの立場を指定する
  • 参照文書の明示 — 「以下の文書のみを根拠として回答してください」と指示し、検索結果を渡す
  • 回答形式の指定 — 「箇条書きで3点にまとめる」「根拠となる文書名を併記する」など出力構造を決める
  • 禁止事項の明示 — 「文書に書かれていない情報を推測しない」「わからない場合は『情報がありません』と答える」と制約を設ける

プロンプト設計で最も重要なのは、AIが勝手に情報を補完しないよう制約することです。生成AIは文脈から推測して回答を作る性質があるため、明示的に「参照文書の範囲内で答える」と指示しないと、社内文書に存在しない情報を答えてしまいます。

回答品質を検証するには、典型的な質問パターンを20〜30件用意し、正解と照らし合わせます。不正確な回答が出た場合、原因は次のいずれかです。

  • 検索で正しい文書が取得できていない → フェーズ3に戻り検索ロジックを調整
  • 文書は正しいが回答が不正確 → プロンプトの指示が不十分。制約を追加
  • 文書自体が曖昧 → フェーズ1に戻り、文書の記述を明確化

実装後の運用｜継続的な精度改善の仕組み

RAG構築は初回の実装で完結しません。ユーザーからの質問ログを分析し、回答できなかったケース・誤った回答をしたケースを洗い出して改善します。運用フェーズで必要な作業は次の通りです。

  • 質問ログの収集 — ユーザーの質問・返された文書・生成された回答をセットで記録する
  • 失敗ケースの分類 — 「検索ミス」「プロンプト不備」「文書不足」のいずれが原因か判定する
  • 定期的な再学習 — 文書更新時は該当チャンクを再ベクトル化し、インデックスを差し替える

質問ログから「回答できない質問」が多い場合、対象文書の範囲を広げる判断が必要です。逆に、ほとんど使われない文書がインデックスに残っていると検索ノイズになるため、アクセス頻度をもとに対象を絞り込みます。

文書更新の反映タイミングは、文書の種類によって変えます。規程のように変更頻度が低いものは月次更新、FAQ のように日々追加されるものは週次更新とすることで、運用負荷と鮮度のバランスを取ります。

セキュリティとガバナンスの考慮点

社内文書をRAGで扱う場合、アクセス制御と情報漏洩対策が必須です。生成AIのAPIに文書を送信する場合、データがどこに保存されるか、学習データに使われるかを確認します。

国内では、AI事業者ガイドライン（第1.2版）が、AIシステムの透明性や説明可能性について指針を示しています。また、個人情報を含む文書を扱う場合は、個人情報保護委員会の情報を参照し、適切な取り扱いを確認する必要があります。

具体的な対策は次の通りです。

  • アクセス制御の実装 — ユーザーの所属部署・役職に応じて、検索対象文書を制限する
  • ログの監査 — 誰がいつ何を検索したか記録し、不正アクセスを検知できるようにする
  • データの暗号化 — ベクトルデータベースへの保存時・API通信時に暗号化を行う
  • オンプレミス構築の検討 — 機密度が高い文書は、クラウドAPIを使わず自社環境で閉じた構成にする

オンプレミス構築では、オープンソースの埋め込みモデル（sentence-transformers等）と、セルフホスト可能なベクトルDB（Weaviate・Milvus等）を組み合わせます。外部APIに依存しないため情報漏洩リスクは下がりますが、運用負荷とインフラコストは増加します。

よくある失敗パターンと対策

RAG構築でよく発生する失敗とその原因を示します。

  • 検索結果は正しいのに回答が不正確 — プロンプトで「文書の範囲内で答える」制約が不足している。AIが文脈から推測して答えを作っている
  • 同じ質問でも回答が毎回変わる — 生成AIのtemperatureパラメータが高すぎる。0.2以下に設定すると再現性が上がる
  • 古い情報が返ってくる — 文書更新後にベクトル再生成を行っていない。更新フローに再ベクトル化を組み込む
  • 特定の文書が全く検索されない — チャンク分割時に見出しが失われている。見出しを含めた状態でチャンクを作る

これらの失敗は、各フェーズの検証を省略したまま次に進むことで発生します。フェーズごとに期待する出力を定義し、テストケースで確認してから次に進むことで、手戻りを減らせます。