RAGシステムの作り方｜文書取り込みから回答評価まで

RAGシステムの作り方は、正本文書の管理、再現可能な取り込み、権限付き検索、根拠表示、評価、切り戻しを一つの工程として設計することです。 一部署・一質問種別から始め、各工程の確認結果を残せる小規模な業務実装へ落とし込みます。

RAGシステムの作り方を五つの完成物で捉える

RAGの構築は、文書をベクトルデータベースへ入れて回答を表示できた時点では終わりません。本番で必要なのは、正本を選ぶ文書台帳、再実行できる取り込み処理、権限を反映した検索、根拠付き回答、変更前後を比較する評価セットの五つです。Lewisらの原著論文で確認できる事実は、検索器と生成モデルを組み合わせる枠組みです^[1]。この枠組みの限界は、企業固有の版管理、認可、監査まで自動的に定めないことです。これらの追加は本稿の実装上の提案であり、原著論文が個別の運用要件を保証するものではありません。

最初の対象は一部署、一文書群、一つの質問種別へ絞ります。たとえば「全社のあらゆる質問」ではなく、「経費規程の申請条件を現行規程から案内する」と定義します。対象を狭めるほど、正解データと停止条件を具体化できます。

文書取り込みから根拠表示までの実装工程

1．正本台帳を先に作る

共有フォルダを丸ごと読み込まず、文書所有者が正本と認めたファイルだけを台帳へ登録します。同名のPDFとWordがある場合は優先する形式を決めます。改訂前文書は削除せず、`effective_from`、`effective_to`、`status`で現行版と区別すると、過去日付の問い合わせにも対応できます。

2．抽出結果を原文と照合する

PDF本文、表、脚注、ページ番号、箇条書きを抽出し、空ページ率と文字化け率を記録します。100ページ中8ページが空なら、そのまま索引へ進めず、画像PDFか権限制限かを調べます。表の列が混ざる場合は表単位の抽出か、HTML・CSVなど元データの利用を文書所有者へ相談します。

3．断片へ検索に必要な属性を付ける

断片本文に加え、`document_id`、版、節、ページ、所有部署、閲覧グループ、取り込み時刻を保存します。Embeddingsの公式ガイドは、テキストを数値ベクトルへ変換して関連性などへ使う方法を説明しています^[3]。ベクトルだけでは版や権限を表せないため、これらは構造化メタデータとして保持します。

4．認可後の集合から検索する

利用者の会社、部署、職位、案件参加を既存ID基盤から取得し、検索条件へ渡します。検索してから表示を隠す設計では、閲覧不可断片が生成モデルへ送られます。フィルターが検索エンジン側で実行されること、キャッシュキーにも権限条件が入ることをテストします。

5．根拠を使わない回答を拒否する

回答プロンプトでは、取得文だけを根拠とし、資料が不足する場合は確認先を返すよう指定します。引用は文書名だけでなく節・ページを表示し、利用者が原文へ移動できるリンクを付けます。OpenAIのFile searchガイドは検索結果をレスポンスへ含める設定を説明しています^[2]。利用する製品にかかわらず、取得断片と最終回答を同じトレースIDで保存します。

6．固定質問を通してから限定公開する

業務担当者が作った正解付き質問を、取り込み、検索、回答の各段階で実行します。検索上位に正しい根拠がない場合は回答モデルを調整しません。正しい根拠があるのに結論を誤る場合だけ回答工程を直します。原因を切り分けた後、一部署で既存手順との並行運用へ進みます。

2,000文書を取り込む想定計算

以下は実績ではなく、初期容量と作業量を見積もるための想定例です。平均8ページの文書が2,000件、1ページ平均600トークン、1断片600トークン、重なり100トークンとします。実効的な進み幅は500トークンなので、総本文960万トークンから約19,200断片が生じる概算です。表や見出し境界を優先する実装では件数が変わるため、100文書の実測で補正します。

総トークン = 2,000文書 × 8ページ × 600 = 9,600,000
実効進み幅 = 600 - 100 = 500
概算断片数 = 9,600,000 ÷ 500 = 19,200
評価用抽出件数 = 通常60 + 表20 + 旧版10 + 根拠なし10 = 100問

索引費用はベクトル件数だけでなく、埋め込み生成、保存期間、レプリカ、検索回数、再取り込みで変わります。候補製品の料金へ数値を入れる前に、文書100件を実際に抽出し、平均断片数、平均メタデータ量、1質問当たり取得件数を測ります。料金表は公開直前・契約直前に再確認し、試算日と通貨を残します。

API契約とデータ項目を実装前に確定する

取り込みAPIと質問APIの入出力を先に決めると、製品を変更しても業務側を保ちやすくなります。質問APIでは、質問文だけでなく利用者ID、対象時点、対象会社、会話IDを受け取ります。応答には回答、根拠配列、不確実性の理由、処理IDを含めます。利用者が指定していない会社や時点をモデルが推測しない設計にします。

{
  "question": "海外出張の日当はいくらですか",
  "user_context": {"company": "A社", "groups": ["sales"], "as_of": "2026-07-30"},
  "answer": "...",
  "citations": [
    {"document_id": "TRAVEL-004", "version": "2026-04", "page": 12, "section": "海外日当"}
  ],
  "status": "answered | insufficient_evidence | needs_human",
  "trace_id": "rag-..."
}

入力文書に個人情報、営業秘密、輸出管理情報が含まれる場合は、利用目的、送信先、保存期間、再学習への利用有無を確認します。外部サービスの設定だけでなく、自社ログやバックアップに何が残るかも対象です。データの分類ができない場合は、公開文書または匿名化した試験データへ範囲を戻します。実装を始めない条件

正本を指定する文書所有者がいない、利用者権限を検索へ渡せない、評価用の正解根拠を作れない、障害時に元の問い合わせ手順へ戻せない場合は、本番RAGを構築しません。まず不足している業務基盤を整えます。

正常・境界・失敗を含む受入テスト

各ケースは取得断片、順位、スコア、回答、引用、実行時間を保存します。同じ回答文だけを比較すると、偶然正解したケースと正しい根拠を使ったケースを区別できません。Qdrantの公式ドキュメントはベクトル検索、フィルタリング、ハイブリッド検索などの機能を説明しています^[4]が、どの製品でもテストで自社データへの適合を確認します。

公開後に見るダッシュボードと停止基準

公開後は、質問件数ではなく検索・回答・業務結果を分けて監視します。検索では正解根拠の取得率と旧版混入、回答では根拠外断定と適切な不回答、業務では確認時間と問い合わせ再発を見ます。利用者の高評価だけでは、読みやすい誤答を見逃します。

文書版、抽出器、埋め込みモデル、検索設定、回答モデルの変更はすべて再評価の契機です。切り戻しのため、旧索引と旧設定を一定期間保持し、どの版で作った回答かを追跡できるようにします。RAGは一度作って終わる検索画面ではなく、文書更新と評価を継続する業務システムです。

検索対象と回答責任を要件定義で固定する

RAGを作る前に、誰のどの質問へ、どの文書を根拠として、どこまで答えるかを一文で定義します。「社内問い合わせを効率化する」では合否を決められません。「A社の正社員が、現行の経費規程について質問したとき、申請条件と根拠ページを提示し、例外申請は経理へ引き継ぐ」まで具体化します。

業務責任者は正解と許容できない誤りを決め、開発者はその条件を検証可能な仕様へ変換します。たとえば日当の金額を誤ることは重大、案内文の語尾差は軽微と分類します。すべての誤りを同じ点数で平均すると、重大な誤答を軽微な表現改善で相殺してしまいます。

検索対象の文書数だけでなく、月間質問数、同時利用者、許容待ち時間、更新頻度、保存期間、利用地域を確認します。低頻度の質問に高価な常時稼働基盤を用意する必要はありません。逆に、朝9時へ集中する申請問い合わせでは、平均応答時間よりピーク時のp95と待ち行列を要件にします。

抽出・分割・索引を再現可能なパイプラインにする

取り込み処理は、ファイルをアップロードする手作業ではなく、入力と設定から同じ結果を作れるパイプラインとして管理します。文書ハッシュ、抽出器の版、分割規則、埋め込みモデル、索引名、実行時刻を記録し、どの設定で各断片を作ったか追跡します。失敗した文書を黙って飛ばさず、再処理キューと所有者への通知へ回します。

取り込み確認の例では、通常PDF、表を含むPDF、画像スキャン、旧版、閲覧制限付き文書を各4件、計20件選びます。元ファイルのページ数、抽出後の見出し・表・脚注、文書版、断片数、アクセス属性を照合してください。画像スキャンの4件だけ本文が空になる場合は、全体の成功率で相殺せずOCR工程を不合格にします。20件は工程差を見つけるための確認例であり、一般的な品質保証件数ではありません。合格した文書ハッシュと設定版を保存し、固定入力から一定の断片集合を再生成できることまで確かめます。

1. 台帳から承認済み・対象期間内・利用許可済みのファイルだけを選ぶ。
2. ウイルス検査とファイル形式検査を行い、隔離領域で文字を抽出する。
3. 見出し、段落、表、脚注、ページを保持した中間形式へ変換する。
4. 意味のまとまりと引用可能性を優先して分割し、断片IDを付ける。
5. 本文を埋め込みへ変換し、版・権限・日付をメタデータとして保存する。
6. 原文との抜き取り照合、断片数、空断片、重複率を検査する。
7. 合格した新索引を公開し、失敗文書と旧索引の扱いを記録する。

文字数が短いから自動合格とは限りません。1ページの別表が回答の中心なら、抽出失敗1件でも公開を止めます。重要度を文書台帳へ持たせ、重大文書は全ページ照合、補助文書は抜き取り照合など検査強度を変えます。

質問変換・候補取得・再順位付けを段階評価する

利用者の質問をそのまま一回検索するだけでは、略称、誤字、対象日付、複数の論点を扱いにくくなります。質問から製品、手続、時点、会社、否定条件を抽出し、欠けている重要条件は利用者へ聞き返します。「申請できますか」だけで会社や申請種別が分からないときに、全社文書を横断して推測しません。

候補取得では、キーワード検索とベクトル検索を別々に実行して結果を統合する方法があります。条番号、製品型番、エラーコードはキーワード、言い換えや自然文はベクトルが強い傾向があります。OpenAIのEmbeddingsガイドは、埋め込みを検索などへ利用する基本を説明しています^[3]。どの方式を採用しても、自社質問で上位候補を測ります。

1. authorize(user, document_scope)
2. parse(question) -> topic, entity, as_of, missing_fields
3. retrieve_keyword(scope, query, top_k=30)
4. retrieve_vector(scope, embedding, top_k=30)
5. fuse_and_deduplicate()
6. rerank(query, candidates, top_n=8)
7. validate(version, acl, citation)
8. generate_or_abstain()

検索スコアの絶対値を、異なるモデルや索引間で同じ意味として比較しません。採用・不採用の閾値は固定質問で調整し、根拠なし質問を含めて過剰回答とのバランスを確認します。

認証・認可・引用先の権限を同じ利用者で通す

社内RAGでは、利用者がチャット画面へ入れることと、すべての文書を読めることは同じではありません。ID基盤から取得した利用者属性を、検索対象の絞り込み、キャッシュ、引用リンク、ログ閲覧の各段階へ一貫して渡します。モデルに「権限外の情報を出さないで」と指示するだけでは認可になりません。

質問と回答のログも機密情報です。利用者の入力に未公開案件名や個人情報が含まれ、回答に文書の要約が残ります。ログ閲覧者、保存期間、削除、監査利用を定め、本番ログを開発者全員が自由に読む構成にしません。障害調査用には、必要な期間と案件へアクセスを限定します。

外部の生成AI・埋め込み・検索サービスを使う場合は、送信地域、保存、再学習への利用、暗号化、削除、下請事業者、事故通知を契約と設定で確認します。要件を満たせない機密文書は対象外にし、公開資料だけで試行するか、自社管理環境を比較します。

並行運用・切り戻し・文書更新を含めて公開する

公開は、旧問い合わせ窓口を止めて全員へ一斉展開するのではなく、対象部署と質問範囲を限定した並行運用から始めます。RAGの回答を担当者が確認し、最終回答との差分を記録します。誤答報告ボタンだけに依存せず、週次で無作為抽出した案件を元文書と照合します。

切り戻しでは、画面を止めるだけでなく旧索引、旧設定、旧文書版へ戻せるようにします。新索引へ切り替える前に、旧索引の保持期限とルーティング手順を記録します。重大な越権が起きた場合は全体停止、特定文書の抽出失敗なら対象文書だけ停止するなど、影響範囲に応じた停止単位を用意します。

文書更新時は、差分に関係する質問を優先して再評価します。旅費額が変わったなら、一般的な検索50問だけでなく、旧金額、新金額、施行日前後、例外地域を含むケースを実行します。更新処理が失敗した場合は旧版を黙って使い続けず、該当質問を人へ戻す表示へ切り替えます。

OpenAIのFile search公式ガイドは、ベクトルストアとファイル検索ツールの実装方法を示しています^[2]。またQdrantの公式資料は検索やフィルタリングなどの機能を説明しています^[4]。これらは部品仕様であり、自社の公開判定、切り戻し、文書責任まで自動で決めるものではありません。

一つの処理IDで検索・回答・承認を追跡する

RAGの監視では、APIが200を返したかだけでは足りません。質問を受けてから、権限判定、質問変換、候補検索、再順位付け、回答生成、引用表示、人の修正までを一つの処理IDで結びます。個人情報や文書本文を無制限にログへ残さず、調査に必要なID、版、順位、判定理由を構造化して保存します。

{
  "trace_id": "rag-20260730-...",
  "user_scope_hash": "...",
  "question_category": "travel_expense",
  "index_version": "expense-2026-07-30",
  "retrieval": [
    {"chunk_id": "TRAVEL-004#p12-02", "rank": 1, "source": "hybrid"}
  ],
  "answer_status": "answered",
  "citation_check": "passed",
  "human_decision": "edited",
  "edit_reason": "exception_condition_missing"
}

アラートは原因候補へ結び付けます。現行版取得率の急落なら取り込み、検索候補は正しいのに根拠外断定が増えたら回答工程、特定部署だけ候補0件なら権限同期を確認します。モデル変更と文書改訂が同時なら比較できないため、リリースイベントを別に記録します。

ログが欠損した回答は、正しそうに見えても重要業務の自動処理へ使いません。監査ログ障害時には回答を下書きへ降格する、または人の窓口へ戻す設計にします。保存期限を過ぎたログは削除し、評価用に残す場合は匿名化と目的変更の承認を行います。

RAG構築を始める前の最終確認

最初の実装対象を「利用者、質問、正本文書、回答範囲、不回答条件」の五点で一文にしてください。次に、文書所有者が承認したファイル100件と、通常・表・旧版・権限違反・根拠なしを含む正解付き100問を用意します。これらが揃ったら、取り込みパイプラインと検索APIを先に作り、正解根拠が上位へ入ることを確認してから回答生成を接続します。越権0件、重要条件の誤り0件、引用遷移、切り戻し手順、運用担当の五つが揃うまで一般公開へ進めません。

公開判定は、検索担当、生成担当、業務確認者、文書管理者の四者で行います。検索担当は正解根拠が上位5件へ入った割合と権限フィルターの結果、生成担当は引用と回答の一致、不回答、処理IDの連携、業務確認者は金額・期限・例外条件の誤り、文書管理者は改訂・削除の反映時刻を提示します。たとえば限定利用の合格条件を、重要質問20件の誤り0件、権限違反0件、削除依頼から24時間以内の索引除外、引用リンク到達100％と定めます。これは構築チームが採用する基準例であり、サービスの公称値ではありません。未達項目は平均値で相殺せず、責任者と再試験日を決めます。

本番切り替え前には、旧索引へ戻す操作、生成を止めて検索結果だけを表示する縮退運転、問い合わせを有人窓口へ送る経路を実際に試します。文書更新が止まっている、監査ログから利用者と引用文書を結び付けられない、回答の利用先が自動契約や自動決裁で人の確認を挟めない場合は公開対象にしません。

参考文献・出典

1. Lewisほかの原著論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」。RAGシステムの構築原理を示す原著論文、Advances in Neural Information Processing Systems 33, 2020（2026-07-30参照）
2. OpenAI公式ドキュメント「File search」。RAG実装における文書検索と結果取得の公式仕様、現行Web版、版表記なし（2026-07-30参照）
3. OpenAI公式ドキュメント「Vector embeddings」。検索用ベクトル表現の公式仕様、現行Web版、版表記なし（2026-07-30参照）
4. Qdrant公式ドキュメント「Qdrant Documentation」。ベクトル検索基盤の実装仕様、現行Web版、版表記なし（2026-07-30参照）