meguli
業務効率化読了 約12分

AI RAGの作り方｜検証から始める小規模導入の設計手順

AI RAGを小さく試すための設計手順を解説。対象業務の選定、自社データの準備、検索と回答の試作、評価、セキュリティや費用の確認まで、導入前に押さえたい判断ポイントをまとめます。

こんにちは、平岡です。AI RAGは、対象業務を絞り、質問と正解資料を用意して、検索・回答の順に検証してから導入範囲を広げます。最初から社内の全資料をつなぐのではなく、検索結果が妥当か、回答に根拠があるかを別々に確かめるのがポイントです。

RAGとは何か、生成AIとの違いを押さえる

RAGの基本構成

RAGは、社内などの独自コンテンツを検索し、その情報を根拠に大規模言語モデル（LLM）が回答を生成する方式です。検索拡張生成とも呼ばれます。生成AI単体が学習済みの情報をもとに回答するのに対し、RAGは質問に関連する自社資料を探し、その結果を回答に利用します。

基本の流れは、質問を受け取る、検索用データから関連情報を取得する、取得した情報をLLMに渡して回答を作る、の順です。たとえば総務への「出張時の宿泊費の上限は？」という質問に対し、旅費規程の該当箇所を検索し、その記述をもとに回答します。

ただし、RAGを使えば回答が自動的に正しくなるわけではありません。検索で別の規程や古い資料が選ばれれば、回答にもその内容が反映されます。回答文だけを見ず、根拠として渡された資料が適切かを確認する必要があります。

Azure AI Searchのハイブリッド検索は、全文検索とベクトル検索を並列で実行し、Reciprocal Rank Fusion（RRF）で結果を統合します。キーワードの一致と意味の近さを組み合わせて検索する仕組みの例ですが、検索方式を選ぶ前に、実際の質問で目的の資料が上位に出るかを試します。

まず分けて考える

RAGの回答品質は、検索で取れた情報と、その情報を使った回答の両方で決まります。検証でも「正しい資料が見つかったか」と「資料に沿った回答か」を分けて記録します。

検証する業務を絞り、試す範囲を決める

検証対象の選定

最初の候補は、質問の内容と正解となる資料を特定しやすい業務です。例として、総務が受ける社内規程の問い合わせや、営業が製品資料を探す業務が考えられます。問い合わせが曖昧で正解の判断もしにくい業務より、質問と参照先が対応する仕事から始めます。

検証前に、利用者、質問の範囲、確かめたいことを決めます。たとえば対象者を総務担当者、資料を旅費規程、質問を出張費用に関するものに限定し、「該当する規程箇所を検索できるか」「回答が規程の記述を越えていないか」を確認します。

  • 利用者：誰が質問するか。例は営業部の担当者、総務への問い合わせ担当者
  • 質問の範囲：旅費、経費精算、製品仕様など、検証するテーマ
  • 確かめたいこと：該当資料の検索、回答の根拠表示、判断できない質問への応答
  • 対象資料：正解の根拠として使う規程、手順書、製品資料

対象を広げすぎると、どの資料・質問で問題が起きたのか切り分けにくくなります。一つの業務と関連資料に範囲を絞り、評価できる状態になってから対象を追加する進め方が現実的です。

自社データを準備し、使う範囲を決める

データ準備の確認点

検索に使う資料を選ぶ際は、内容の正確性、更新状況、重複、表記ゆれを見直します。同じ手当について複数の規程に異なる金額が書かれている場合、どれを正とするのか決めないまま登録すると、検索結果の評価が難しくなります。改定前の資料や確認中の草案も、検証対象に含めるかを整理します。

データ形式や取り込み方は利用環境によって異なります。MicrosoftのRAGコンテンツ準備資料では、Azure AI Searchの機能例として、大きな文書の自動チャンク化、PDFのOCR、シノニムマップが挙げられています。こうした機能を使えるかどうかだけでなく、分割後に規程の見出しと本文が離れていないか、略称や社内用語で検索できるかも確認します。

OpenAIのFile SearchはResponses APIで利用でき、事前にベクトルストアを作成してファイルをアップロードします。OpenAIのベクトルストアでは、ファイルの追加時に自動でチャンク化・埋め込み・インデックス登録が行われます。既定の自動チャンク設定は最大800トークン、チャンク重複は400トークンです。

自動処理を使う場合でも、資料が意図したまとまりで分割されているかは検証対象です。ファイルを登録できることと、利用目的に合う検索結果が得られることは別の確認事項です。アクセス権限のある情報か、検証用の利用範囲に含めてよいかも、登録前に資料単位で決めます。

検索の仕組みを小さく試作する

検索の試作

回答生成に進む前に、質問から関連資料を取得できるかを試します。質問ごとに、期待する資料と検索結果を並べ、目的の箇所が見つからないケースと、関連性の低い資料が混ざるケースを分けて記録します。

正しい資料が見つからない場合は、資料自体が取り込まれているか、分割の単位が適切かを見ます。目的の資料は出ているのに別資料も多く混ざる場合は、検索条件や絞り込みの見直しを検討します。Azure AI Searchのハイブリッド検索を使う場合も、全文検索とベクトル検索を並列実行してRRFで統合した結果が、質問に合っているかを実データで比べます。

質問：
期待する資料：
実際に取得した資料：
目的の箇所が見つかったか：
関連性の低い資料が混ざったか：
課題の分類：資料／検索

資料の内容を直すべき問題と、検索の設定を調整する問題が混ざったままでは、変更の効果を判断しにくくなります。まず検索結果だけを確認し、課題の種類を記録してから回答生成へ進みます。

検索結果を使った回答を設計する

回答の設計

検索で取得した情報を根拠として回答するよう、試作時の指示を用意します。回答に資料名や該当箇所を添える設計にすると、利用者が回答の根拠をたどれるかも評価できます。どの程度の位置情報まで表示できるかは、利用環境とデータの持ち方に応じて決めます。

回答は検索で取得した資料の記載に限定する
根拠となる資料名と該当箇所を示す
資料から判断できない場合は、判断できないと伝える
質問の条件が不足している場合は、確認質問を返す

社内規程の「対象者」が書かれていない質問なら、条件を確認してから回答するようにします。規程に記載がない内容を一般論で補って断定しないことも、試作段階で確かめる項目です。資料が見つからない場合、回答を出さずに担当部署へ確認を促すなど、次の行動も決めておきます。

根拠のない補完に注意

検索結果に必要な記述がない場合、回答が自然な文章でも正しいとは限りません。回答に根拠資料が付いているか、資料の記載を越えた断定がないかを質問ごとに点検します。

評価用の質問を作り、課題を切り分ける

評価の進め方

実際の問い合わせを想定した質問と、期待する回答の要点をセットで用意します。たとえば旅費規程を対象にするなら、「宿泊費の上限は何円か」という質問に対し、正解となる金額と、根拠となる規程の箇所を記録します。正解の全文を決めにくい質問は、回答に含めるべき要点を先に定めます。

評価では、取得された検索文書と、生成された回答を別々に見ます。検索文書が正解の根拠を含んでいるのに回答が要点を落としているなら回答側の課題です。逆に、回答の前提となる資料が見つかっていないなら、回答指示だけを直しても検索課題は残ります。

Microsoft FoundryのRAG評価資料では、検索文書を正解ラベルと比べる指標として、Fidelity、NDCG、XDCG、Max Relevance、Holesが挙げられています。これらを評価に使う場合も、指標の値だけで判断するのではなく、実際の質問と取得文書を見て、現場で困る誤りが減ったかを確認します。

  • 資料の問題：誤り、古さ、重複、正解となる記述の不足
  • 検索の問題：正解資料が出ない、関連性の低い資料が混ざる
  • 回答の問題：根拠の読み違い、必要な要点の不足、資料にない断定

修正した後は、同じ質問をもう一度実行して、前回との差を記録します。質問を変えると改善したのかどうか比べにくくなるため、まず評価用の質問を固定し、課題の分類ごとに修正の効果を見ます。

セキュリティと運用を確認し、本格導入を判断する

導入前の確認

検証で使ったデータ範囲や権限が、本番運用でも保てるかを確認します。Azure AI SearchのRAG解説では、文書単位のアクセス制御、クエリ時のフィルターによるセキュリティ、プライベートエンドポイントが構成例として説明されています。営業部には営業資料だけ、総務には規程資料も見せる、といった利用者ごとの範囲を想定し、検索時に権限が反映されるかを試します。

OpenAI APIの既定では、不正利用監視ログは最大30日保持され、ベクトルストアのアプリケーション状態は削除するまで保持されます。Zero Data Retentionは事前承認が必要で、ベクトルストアなど同機能の対象外エンドポイントではアプリケーション状態が保存される場合があります。ログの保持とベクトルストアの状態は別に確認し、削除の担当と手順も運用に含めます。

基盤の管理範囲も選定材料です。Amazon Bedrock Knowledge Basesには、AWS管理のデータ取り込み・索引作成・保存・検索を使うManaged Knowledge Baseと、利用者が基盤を管理するCustomer-managed Knowledge Baseがあります。機能ごとに対応リージョンやモデルが異なり、AWS公式資料には埋め込みモデル別の単一リージョン対応表が掲載されています。利用したいモデルとリージョンの組み合わせを選定時に照合します。

費用も検証条件に含めます。OpenAIのFile Searchストレージは、全ベクトルストア合計で1GBまで無料、超過分は1GB・1日あたり0.10米ドルです。Responses APIにおけるFile Searchのツール呼び出し料金は1,000回あたり2.50米ドルです。検証では、保存するデータ量とツール呼び出し回数を分けて記録し、導入候補の提供条件に照らして費用を見積もります。

導入判断の基準

評価用の質問で検索と回答の課題を把握でき、アクセス範囲や資料更新の担当も決まっているなら、対象業務の拡大を検討できます。権限やデータ更新を運用で保てない場合は、条件を見直して再検証するか、導入を見送る判断も選択肢です。

まとめ

AI RAGの小規模導入では、対象業務を選び、自社データを整え、検索を試してから回答を設計します。その後、評価用の質問で検索結果と回答を分けて点検し、データ・検索・回答のどこに課題があるかを切り分けます。

次の一歩は、検証する業務を一つ選び、利用者、参照資料、確かめたい質問を決めることです。小さな範囲で検索と回答を評価し、運用条件を満たせると確かめてから対象を広げましょう。

参考・出典

#AI RAG#生成AI#業務効率化#社内ナレッジ
この記事をシェア
𝕏 でポストB! はてブ
m
株式会社meguli

AI×DXで、社会の巡りをよくする。中小企業の現場で使えるAI活用・業務改善の実践情報を発信しています。

ご相談・お問い合わせはこちら →

あわせて読みたい

AI導入の進め方｜業務選びから検証・展開までの実践ガイド

Claude Code セキュリティ｜機密情報を扱う前の判断基準

基幹システム入れ替え費用は何で変わる？見積もり前の範囲整理

記事一覧へ戻る