RAGシステムの構築手順：社内文書を検索して答えるAIの作り方

社内文書を検索して答えるAI、いわゆるRAG（検索拡張生成）のシステムは、「文書を集める」「前処理する」「ベクトル化して保存する」「検索する」「回答を生成する」「評価する」という六つの段階で構築します。技術的な部品はそろってきており、試作品を動かすだけなら短期間でできるようになりました。しかし、業務で使える精度と運用のしやすさを備えたシステムにするには、各段階で何を判断すべきかを押さえておく必要があります。

構築を成功させるための要点は三つです。一つ目は、最初に対象とする文書と利用者、答えさせたい質問を絞ることです。二つ目は、評価の基準を作ってから作り始めることです。三つ目は、小さな範囲で六つの段階を一通り動かし、評価の結果を見ながら範囲を広げることです。最初からすべての文書を取り込もうとすると、精度の問題がどこから来ているのか分からなくなります。

この記事は、社内文書を使ったAI検索や問い合わせ対応の仕組みを作ろうとしている開発担当者、情報システム部門の担当者、そしてプロジェクトの責任者に向けて書いています。構築の全体像と各段階の作業内容、判断のポイント、よくある失敗と避け方を順に説明します。

RAGシステムの全体像

RAGは、利用者の質問に関係する文書の断片を検索で探し、その断片を生成AIに渡して、内容に基づいた回答を作らせる仕組みです。生成AIは学習した時点の一般的な知識しか持っていませんが、RAGを使えば、社内規程、製品マニュアル、過去の対応記録など、自社固有の情報に基づいて答えさせることができます。また、文書を差し替えれば回答の元になる情報も更新されるため、モデルを作り直す必要がありません。

システムは大きく、文書を取り込んで検索できる状態にする「準備の流れ」と、質問を受けて回答を返す「回答の流れ」の二つで構成されます。

以下、構築の前に決めることと、六つの段階を順に説明します。

構築前に決めること

技術的な作業に入る前に、次の項目を決めておきます。ここが曖昧なまま作り始めると、どの文書を入れるか、どこまでの精度を目指すかが決まらず、試作が終わらなくなります。

1. 利用者と用途：誰が、どんな場面で、何を知るために使うのか。社員の規程確認か、サポート担当者の調べ物か、顧客向けの案内か
2. 対象文書：最初に取り込む文書の範囲。種類、件数、形式、保管場所
3. 答えさせたい質問：実際に想定される質問の例を集める
4. 答えさせない範囲：推測で答えてはいけない話題、人に引き継ぐべき質問
5. 権限：利用者によって見られる文書が異なるかどうか
6. 合格の基準：評価セットでどの程度の結果が出れば使い始めてよいか
7. 利用環境：社内チャットツールから使うのか、専用の画面を作るのか、既存システムに組み込むのか

特に5の権限は、後から追加すると設計のやり直しになりやすい項目です。最初は全員が見られる文書だけを対象にする場合でも、将来、部署限定の文書を扱う可能性があるなら、その前提で設計しておきます。考え方はRAGでの権限管理：見てはいけない文書を回答に混ぜない設計で解説しています。

あわせて、構築に関わる人の役割も決めておきます。RAGの構築には、仕組みを作る開発の担当者だけでなく、文書の中身に責任を持つ業務部門の担当者が欠かせません。評価セットの質問と期待する回答を作る、採点する、文書の誤りや古さを直す、といった作業は、業務を知っている人でなければできないからです。業務部門の担当者がどの程度の時間を割けるかを事前に確認し、計画に組み込んでおくと、評価の段階で作業が止まることを防げます。

段階1・2：文書の収集と前処理

段階1：文書を収集する

最初の段階では、対象の文書を集め、どこから、どの頻度で取り込むかを決めます。

対象文書を選ぶ

文書は多ければよいわけではありません。古い版、内容が重複する文書、下書きや個人のメモが混ざると、検索で無関係な情報が出てきやすくなり、精度が下がります。「正式な最新版」と言える文書だけを選び、どれが正かを文書の管理者と確認します。

取得元と更新方法を決める

文書の保管場所（ファイルサーバー、クラウドストレージ、社内Wiki、業務システムなど）ごとに、取り込みの方法を決めます。一度きりの手作業での取り込みか、定期的に自動で取り込むのかで、必要な仕組みが変わります。文書が更新されたときに、古い内容を削除し新しい内容に置き換える処理も、この段階で設計しておきます。更新のたびに全件を取り込み直す方法は単純ですが、文書が多いと時間と費用がかかるため、変更があった文書だけを差し替える仕組みが必要になることもあります。

段階2：前処理とチャンク分割

集めた文書から、検索と回答に使えるテキストを取り出し、適切な大きさに分けます。精度への影響が大きい段階です。

テキストを取り出す

PDF、Word、表計算ファイル、Webページなど、形式ごとにテキストを取り出します。このとき、ページのヘッダーやフッター、ページ番号、目次など、検索の邪魔になる部分を取り除きます。PDFは見た目どおりにテキストが取り出せないことが多く、段組みの順番が入れ替わる、表が崩れる、画像の中の文字が抜け落ちる、といった問題が起きます。PDFや表の扱いはPDFや表を含む社内資料をRAGで扱うときの前処理の工夫で詳しく解説しています。

構造を残す

見出し、条番号、箇条書き、表の行と列の関係といった構造は、できるだけ残します。構造が失われると、どの見出しの下の記述なのか、どの条件に対応する値なのかが分からなくなり、回答の誤りにつながります。

チャンクに分ける

取り出したテキストを、検索の単位となる断片（チャンク）に分けます。分け方の基本は、見出しや条、Q&Aの項目など、意味のまとまりに沿って区切ることです。文字数だけで機械的に区切ると、文の途中や表の途中で切れてしまいます。各チャンクの先頭に文書名と見出しの階層を付けておくと、チャンク単体でも何についての記述かが分かります。文書の種類別の分け方はRAGのチャンク分割の考え方で扱っています。

段階3：ベクトル化して保存する

チャンクを検索できるように、意味を表す数値の並び（ベクトル）に変換して保存します。

埋め込みモデルを選ぶ

文章をベクトルに変換する処理を埋め込み（エンベディング）と呼び、そのためのモデルを埋め込みモデルと呼びます。モデルによって、日本語の扱いの得意不得意、扱える文章の長さ、費用、データの送信先が異なります。社内文書を外部のサービスに送ることになるため、データの取り扱い条件も選定の観点に含めます。埋め込みモデルを後から変えると、すべてのチャンクを変換し直す必要があるため、試作の段階で評価セットを使って比較しておくのが安全です。

保存先を選ぶ

ベクトルとチャンクの本文、メタデータを保存し、高速に検索できるデータベースを用意します。専用のベクトルデータベースを使う方法のほか、既存のデータベースや検索エンジンのベクトル検索機能を使う方法もあります。文書の量、更新の頻度、キーワード検索との併用のしやすさ、権限による絞り込みのしやすさ、運用の手間を比べて選びます。

メタデータを付ける

各チャンクに、文書名、見出し、文書の種類、担当部署、公開範囲、更新日などのメタデータを付けます。メタデータは、検索時の絞り込み、権限の制御、古い版の除外、回答での出典の提示に使います。後から付け足すのは手間がかかるため、この段階で必要な項目を決めておきます。

段階4・5：検索と回答生成の仕組みを作る

段階4：検索の仕組みを作る

質問を受けたら、関係するチャンクを探してAIに渡します。

1. 質問を検索に適した形に整える：会話の文脈を補う、略語を展開する、必要に応じて複数の検索文に分ける
2. 権限とメタデータで検索対象を絞る：質問者が見られる文書、対象の製品や部署などで絞り込む
3. ベクトル検索で意味の近いチャンクを探す
4. 必要に応じてキーワード検索を併用する：型番、固有名詞、条番号などの一致に強い
5. 候補を関連の強い順に並べ替え、上位を回答生成に渡す

最初の試作では3だけで動かし、評価の結果を見ながら1、2、4、5を加えていく進め方が現実的です。検索の工夫ごとの効果は、文書と質問の性質によって変わるため、評価セットで確かめながら足していきます。

段階5：回答を生成する

検索で得たチャンクを生成AIに渡して、回答を作らせます。

指示文を設計する

指示文では、次の振る舞いを明確にします。

• 渡した文書の内容だけを根拠に答える
• 根拠がない場合は推測せず、分からないと答える
• 条件によって答えが異なる場合は、条件ごとに答えるか、条件を確認する
• 回答の根拠となった文書名と箇所を示す
• 答えさせない話題の場合は、定められた案内を返す

出典を示す

回答とともに、根拠となった文書名、見出し、可能であれば原文へのリンクを示します。利用者が回答の正しさを確かめられることは、システムへの信頼につながり、誤った回答に気づくきっかけにもなります。

モデルを選ぶ

回答生成に使うモデルは、精度、応答速度、費用、データの取り扱い条件で選びます。長い文書を読んで条件を整理する力が必要な用途と、短い定型の案内で十分な用途とでは、適したモデルが異なります。

会話の続きを扱う

利用者は一度の質問で終わらず、「それは契約社員も同じ？」のように前のやり取りを前提にした質問を続けます。会話の履歴を回答生成に渡すだけでなく、検索の前に履歴を踏まえて質問を補う処理を入れておかないと、続きの質問で検索が空振りします。一方で、履歴を長く渡すほど一回あたりの費用と応答時間が増えるため、直近の数往復に限る、古いやり取りは要約して渡す、といった工夫で量を調整します。

段階6：評価して改善する

評価は最後の段階として書いていますが、実際には構築前に評価セットを用意し、各段階の作業ごとに評価しながら進めます。

評価セットは、実際に想定される質問、期待する回答の要点、根拠の文書と箇所、の組として作ります。言い換えやあいまいな質問、答えが文書にない質問も含めます。回答を採点し、間違ったものについて、検索で根拠のチャンクが取れていたかどうかを確認すると、検索の失敗か生成の失敗かを切り分けられます。改善の具体的な方法はRAGの回答精度を改善する方法で詳しく解説しています。

構築の進め方の例

架空の例として、社員数百名規模の会社が、情シスへの問い合わせ対応を目的にRAGを構築する場合を考えます。まず、問い合わせの多い「アカウント」「ソフトウェア申請」「機器の貸し出し」の手順書だけを対象にし、過去の問い合わせから評価用の質問を集めます。手順書の見出し単位でチャンクに分け、ベクトル検索だけで最初の版を動かし、評価セットで採点します。ソフトウェア名や機器の型番を含む質問で検索の失敗が多いと分かれば、キーワード検索を併用します。合格の基準に達したら情シスの担当者だけで使い、次に一部の部署に公開し、その後に総務の手順書へと対象を広げます。

運用を見据えた準備

公開の前に、運用の仕組みも用意しておきます。質問、検索結果、回答、利用者の評価を記録するログは、精度の改善に欠かせない材料です。回答の下に「役に立った・役に立たなかった」を押せる仕組みを置くと、改善すべき質問を見つけやすくなります。また、生成AIや埋め込みのサービスの利用料は使った分だけかかるため、利用量と費用を確認できるようにし、想定を超えたときに気づける仕組みを入れておきます。外部サービスの障害や応答の遅延に備えて、エラー時に利用者へどう案内するかも決めておきます。

公開前チェックリスト

• 対象文書が正式な最新版に限られている
• 文書の更新時に古い内容が置き換わる仕組みがある
• 表や見出しの構造がチャンクに残っている
• チャンクに文書名・見出し・更新日・公開範囲のメタデータが付いている
• 質問者が見られない文書が検索対象に含まれない
• 評価セットで合格の基準を満たしている
• 文書にない質問に推測で答えない
• 回答に出典が示される
• 質問と検索結果、回答のログが記録され、閲覧者と保存期間が決まっている
• 生成AIや埋め込みのサービスに送るデータの取り扱い条件を確認した

よくある失敗と避け方

全文書を一度に取り込む

最初から大量の文書を取り込むと、精度の問題の原因が特定できなくなります。用途と文書を絞り、小さな範囲で六段階を一通り動かしてから広げます。

評価の基準を作らずに作り始める

基準がないと、改善が終わったかどうかを判断できません。試作の前に評価セットと合格の基準を決めます。

前処理を軽く見る

テキストの取り出しや表の扱いの問題は、後段の工夫では取り戻せません。取り出した結果を人の目で確認する工程を入れます。特に、表の多い資料、段組みのある資料、スキャンした紙の資料は、代表的な数ページを抜き出して、取り出したテキストと原本を見比べるだけでも、多くの問題を事前に見つけられます。

文書の更新の仕組みを後回しにする

公開後に文書が改定されたとき、取り込み直しの仕組みがないと、古い情報を答え続けることになります。更新の担当者と反映の手順を、構築の段階で決めておきます。取り込みの処理が失敗したときに気づける通知も合わせて用意しておくと安心です。

試作の成功を本番の成功と思い込む

開発者が用意した質問で試作がうまく動いても、実際の利用者は想定外の言い回しや、文書にない質問を投げかけます。限定公開の期間を設け、実際の質問で評価し直してから本公開に進みます。限定公開で集まった質問は、評価セットに追加しておくと、その後の改善の基準にもなります。

よくある質問

Q. RAGの構築にはどのくらいの期間がかかりますか？

対象文書の量と形式、権限の要件、既存システムとの連携の有無で大きく変わります。対象を絞った試作であれば短期間で動かせますが、業務で使える精度に仕上げるには、評価と改善を繰り返す期間を見込む必要があります。

Q. 既製のサービスを使わず、自社で作る必要はありますか？

文書を取り込んで答える機能を持つサービスも増えており、対象が限られ、権限の制御も単純であれば、既製のサービスで十分な場合があります。権限の細かい制御、既存システムとの連携、前処理の作り込みが必要な場合に、個別の構築が選択肢になります。

Q. 社内文書を生成AIのサービスに送っても問題ありませんか？

サービスごとに、送ったデータの保存期間や学習への利用の扱いが異なります。利用規約と設定を確認し、社内のデータの取り扱いルールに照らして判断してください。個人情報を含む場合は、専門家への確認もおすすめします。

Q. 文書が更新されたら、毎回作り直す必要がありますか？

作り直す必要はありません。更新された文書のチャンクを削除し、新しい内容を前処理してベクトル化し直せば反映できます。ただし、埋め込みモデルを変更した場合は、すべてのチャンクを変換し直す必要があります。

Otsumuに相談できること

対象の文書が少なく形式もそろっていて、権限の制御も必要ない場合は、文書を取り込んで答える既製のサービスを使ったり、社内のエンジニアがこの記事の六段階に沿って試作したりすることで、自社で進められることは多いはずです。まずは対象を絞って評価セットを作り、小さく動かしてみることをおすすめします。

PDFや表を多く含む資料が中心で前処理の工夫が必要な場合、部署や役職による権限の制御が必要な場合、既存の業務システムに組み込みたい場合、試作は動いたが精度が業務の水準に届かない場合は、設計と開発の経験が結果を左右します。社内に開発の手が足りないときも、外部の力を借りた方が早く進みます。

Otsumuでは、対象文書と用途の整理、評価セットの設計から、前処理、検索、回答生成の開発、権限の設計、公開後の精度改善までを一貫して支援しています。目的から逆算して必要な機能に絞り、AIを活用した少人数・短期間の開発で、小さく動かして評価しながら広げる進め方を取ります。詳しくはRAG開発のページをご覧ください。試作で効果を確かめたい場合は、PoC / MVP Sprint（300万円〜・税別の参考価格、6週間を目安に設計）という形もあります。

どの文書から始めるとよいか、状況を伺いながら一緒に整理することもできます。30分の無料相談からお気軽にご連絡ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01