研究開発データにRAGを導入するには？設計手順・評価方法・失敗例を解説
生成AIに社内文書を参照させる方法として、RAG（Retrieval-Augmented Generation、検索拡張生成）の導入を検討する企業が増えています。しかし、研究開発データを対象にする場合、報告書をベクトルデータベースへ登録するだけでは、信頼できるシステムにはなりません。
研究開発では、同じ数値でも試料、測定条件、単位、版によって意味が変わります。旧版の報告書や閲覧権限のない文書が検索結果に混入すれば、文章としては自然でも、業務上は誤った回答になります。
先に結論を述べると、研究開発向けRAGでは、生成モデルの選択以上に、次の設計が重要です。
- 利用目的と回答可能範囲を限定する
- データの意味、出典、版、権限を保持する
- 文書構造に沿ってチャンクを作る
- キーワード検索とベクトル検索を組み合わせる
- 検索と回答生成を分けて評価する
- 根拠がない質問には回答しない
本記事では、研究開発データへRAGを導入する手順を整理し、架空の隕石試料データを使った検索設計の比較試験も紹介します。
RAGの基本的な仕組みや限界を先に確認したい場合は、RAGとは？研究開発での活用方法・仕組み・限界をご覧ください。
研究開発データへのRAG導入が難しい理由
一般的な社内FAQでは、質問に対応する規程や説明文を見つければ回答できる場合があります。一方、研究開発データでは、情報の意味が周辺条件に強く依存します。
文書、表、図、画像、測定データが混在する
研究開発部門が保有する情報は、文章だけではありません。
- 研究報告書や論文
- 特許
- 実験ノート
- ExcelやCSVの実験表
- スペクトルや顕微鏡画像
- 装置ログ
- 標準作業手順書
- 会議資料や考察メモ
PDFをテキスト化しただけでは、表の行と列、図とキャプション、測定結果と試料条件の関係が失われることがあります。科学文書を扱う最近の研究でも、テキスト、表、画像、知識グラフなどを分けて扱い、検索処理を部品ごとに評価する必要性が示されています。
数値は条件と切り離すと意味を失う
「強度は50 MPaだった」という記載だけでは、研究データとして十分ではありません。少なくとも、次の情報との対応が必要です。
- 試料とロット
- 組成と前処理
- 温度、時間、雰囲気
- 試験片形状
- 測定規格
- 測定装置
- 反復数
- データ処理方法
チャンク分割によって数値と条件が別々になれば、正しい文書を検索できても、誤った条件と組み合わせて回答する可能性があります。
同じ用語が異なる意味で使われる
研究現場では、社内略語、開発コード、試料番号、装置固有の項目名が多く使われます。さらに、同じ単語でもテーマによって意味が異なることがあります。
このため、一般的な言葉の近さだけで検索するベクトル検索では、試料番号、化合物名、規格番号などの完全一致を取りこぼす場合があります。反対に、キーワード検索だけでは、言い換えや概念的に近い質問を見つけにくくなります。
最新版と過去版が混在する
研究報告書には、暫定版、中間報告、再解析版、最終承認版が存在します。旧版も研究経緯を理解するうえでは重要ですが、現在の判断根拠として使うべきとは限りません。
単に類似度が高い文書を取得するのではなく、版、承認状態、有効期間を検索条件へ含める必要があります。
閲覧権限が文書ごとに異なる
研究開発データには、知的財産、共同研究、顧客情報、個人情報などが含まれます。回答生成後に機密部分を削除する設計ではなく、検索候補を作る段階で、利用者が閲覧できない情報を除外しなければなりません。
RAGを構築する前に利用目的を決める
RAG導入で最初に決めるべきなのは、モデルやベクトルデータベースではありません。「誰が、何を質問し、何を得たいのか」です。
「研究開発の知識をすべて検索できるようにする」という目標では、対象が広すぎます。例えば、次のように限定します。
指定した試料について、過去の承認済み報告書から測定条件、結果、出典を一覧化する。
この場合、少なくとも次の成功条件を定義できます。
- 正しい試料の文書を取得する
- 最新の承認済み文書を優先する
- 数値と単位を正しく抽出する
- 測定条件を回答に含める
- 文書名、版、ページまたは節を示す
- 記載がなければ「確認できない」と回答する
利用目的によっては、RAGを使わない方がよい場合もあります。数値を厳密に集計するならSQLやデータベース検索、処理手順が固定されているならワークフロー、対象文書が少ないなら全文をモデルへ渡す方法も候補です。
RAGは目的ではなく、情報取得の選択肢の一つです。
研究開発RAGの全体像
研究開発向けRAGは、次の処理から構成されます。
データ選定 → 解析・構造化 → チャンク作成 → インデックス作成 → 検索 → 再ランキング → 回答生成 → 評価・改善
回答が誤っていた場合、原因が生成モデルにあるとは限りません。
- 対象文書が登録されていなかった
- PDF解析で表が崩れた
- チャンクが不適切だった
- 正解チャンクが検索されなかった
- 旧版が上位になった
- 検索結果は正しかったがモデルが読み違えた
- 数値の計算を誤った
したがって、RAGを一つのブラックボックスとして評価するのではなく、各工程を分けて確認します。
ステップ1：対象データを棚卸しする
最初から部門内の全データを取り込む必要はありません。対象ユースケースに必要なデータから始めます。
データ台帳には、少なくとも次の情報を記録します。
| 項目 | 確認する内容 |
|---|---|
| データ種別 | PDF、Office、CSV、画像、データベースなど |
| 所有者 | 部署、テーマ、担当者 |
| 原本 | 正式な文書を管理している場所 |
| 更新頻度 | 日次、月次、テーマ終了時など |
| 機密区分 | 公開、社内、部署限定、テーマ限定 |
| 状態 | 下書き、レビュー中、承認済み、廃止 |
| 品質 | OCR誤り、欠損、重複、表崩れの有無 |
| 検索価値 | 想定質問への回答に必要か |
「保有しているから入れる」のではなく、「想定質問に必要だから入れる」という基準で選ぶことが重要です。
ステップ2：取り込み時に文書構造を保持する
PDFを単純な文字列へ変換しない
PDFからは、可能な限り次の構造を取得します。
- 文書名と版
- 見出し階層
- ページ番号
- 表と表題
- 図とキャプション
- 脚注
- 数式
- 参考文献
特に表では、列名、単位、試料IDと値の関係を維持します。表を文章へ変換する場合も、各行に列名と単位を付けます。
画像やスペクトルは原データへ戻れるようにする
画像をマルチモーダルモデルで説明文へ変換する方法は有効ですが、説明文だけを検索対象にして原画像を失ってはいけません。
少なくとも、次の関係を保存します。
- 原画像または元データ
- 画像の説明
- 試料ID
- 測定条件
- 解析方法
- 元文書とページ
AIが生成した画像説明は検索補助情報であり、原データそのものではありません。
ステップ3：チャンクを設計する
RAGでは長い文書を検索しやすい単位へ分割します。この単位がチャンクです。
文字数だけで分割しない
「500文字ごと」のような固定長分割は簡単ですが、表の途中、測定条件と結果の間、結論と但し書きの間で切れることがあります。
研究開発文書では、次の意味的なまとまりを優先します。
- 一つの実験
- 一つの試料
- 一つの測定
- 一つの表
- 結果と対応する条件
- 結論と適用範囲
親文書とチャンクの関係を保持する
各チャンクには、本文だけでなく次のメタデータを持たせます。
- 文書ID
- 文書名
- 版
- 作成日
- 承認状態
- テーマ
- 試料ID
- 測定方法
- ページまたは節
- 機密区分
- 原本へのリンク
チャンクへ短い文脈を加える
例えば「処理後は6.8%へ増加した」というチャンクだけでは、対象試料や測定項目が分かりません。
そこで、次のような文脈を加えます。
文書：MT-12加熱試験最終報告v3。試料：MT-12。節：加熱後の結果。処理後は磁硫鉄鉱が6.8%へ増加した。
Anthropicが公開したContextual Retrievalの検証では、文書全体を踏まえた短い説明をチャンクへ付加し、キーワード検索とベクトル検索を併用することで、検索失敗が減少しました。ただし、効果は対象データや評価条件に依存するため、自社データでの検証が必要です。
ステップ4：検索方式を設計する
キーワード検索とベクトル検索を組み合わせる
研究開発では、試料番号、化合物名、規格番号、ピーク位置など、文字列の一致が重要です。一方、「液体の水による変質」と「水質変成」のような言い換えには意味検索が有効です。
そのため、基本構成として次を検討します。
- キーワード検索で完全一致に近い候補を取得する
- ベクトル検索で意味的に近い候補を取得する
- 両方の順位を統合する
- メタデータで版、状態、権限を絞る
- 必要に応じて再ランキングする
MicrosoftやOpenAIの技術資料でも、キーワードとベクトルを併用するハイブリッド検索、属性フィルター、スコア閾値などが説明されています。
top-kを固定的な正解にしない
top-kは、モデルへ渡す検索結果の件数です。増やせば正解根拠を含みやすくなりますが、無関係な情報、矛盾する記載、古い文書も入りやすくなります。
最適値は、次の条件で変わります。
- チャンクサイズ
- 質問の複雑さ
- 再ランキングの有無
- モデルのコンテキスト長
- 1問に必要な根拠数
自社の評価質問を使い、top-kを変えながら正解根拠の取得率とノイズ量を測ります。
ステップ5：回答生成を設計する
検索結果が正しくても、生成モデルが値を取り違えたり、要求項目を落としたりすることがあります。
プロンプトには、少なくとも次のルールを含めます。
- 提示された根拠だけを使う
- 記載がなければ推測しない
- 原文の記載とAIの推論を区別する
- 数値には単位と条件を付ける
- 矛盾する資料があれば両方を示す
- 文書名、版、ページまたは節を引用する
- 計算が必要なら専用の計算処理へ渡す
出力形式を固定することも有効です。
| 出力項目 | 内容 |
|---|---|
| 結論 | 質問への短い回答 |
| 根拠 | 回答を支持する記載 |
| 条件 | 試料、測定、処理条件 |
| 出典 | 文書名、版、ページまたは節 |
| 不確実性 | 不明点、矛盾、推測の有無 |
| 次の確認 | 人が確認すべき事項 |
数値計算の注意点は、生成AIに統計解析を任せてよい？よくある誤りと検証方法でも解説しています。
ステップ6：権限とセキュリティを設計する
権限は検索時に適用する
利用者が閲覧できない文書は、モデルへ渡す候補に含めないことが原則です。
- 文書管理システムの権限を検索インデックスへ反映する
- 利用者、部署、テーマ単位でフィルターする
- 異動や退職による権限変更を同期する
- ログにも機密情報を残し過ぎない
検索文書を命令として信用しない
RAGでは、文書内に「以前の指示を無視せよ」といった文字列が含まれる可能性があります。これは間接プロンプトインジェクションにつながります。
NISTは、プロンプトインジェクションやデータポイズニングを生成AIシステムの情報セキュリティ上のリスクとして挙げています。
対策として、次を組み合わせます。
- 検索文書をデータとして明確に区切る
- 文書中の命令に従わないよう指示する
- 登録元と改訂履歴を管理する
- 不審な文書を隔離する
- 外部送信、削除、更新には承認を置く
- 想定攻撃を含む評価を行う
RAGをAIエージェントのツールとして利用する場合は、AIエージェントとは？RAGとの違いと研究開発での活用・注意点も参照してください。
ステップ7：検索と回答を分けて評価する
最終回答だけを見ても、失敗原因は分かりません。少なくとも、検索、生成、運用を分けて評価します。
検索の評価
| 指標 | 確認する内容 |
|---|---|
| Hit@k | 上位k件に正解根拠が含まれるか |
| Recall@k | 必要な根拠をどれだけ取得できたか |
| Precision@k | 上位結果に不要な情報が少ないか |
| MRR | 最初の正解が何位に現れるか |
| 版の正確性 | 最新・承認済み文書を取得したか |
| 権限違反率 | 閲覧不可文書が混入していないか |
回答の評価
- 最終回答の正確性
- 根拠への忠実性
- 引用箇所の正確性
- 数値と単位の正確性
- 要求項目の網羅性
- 矛盾の検出率
- 回答不能質問への棄権率
運用の評価
- 応答時間
- 1質問当たりの費用
- 人による確認・修正時間
- 再検索率
- 利用率
- 問題報告数
RAGASなどの自動評価は反復試験に便利ですが、LLMによる評価値だけを正解とせず、専門家評価と組み合わせます。
実測検証：検索設計を変えると何が変わるか
研究開発RAGでは、生成モデル以前に検索層の設計が重要です。そこで、架空の隕石試料データを使い、検索方式を変えた比較試験を行いました。実在する企業、研究機関、製品、研究データとは関係ありません。
検証データ
10件の架空文書を作成しました。
- 隕石試料MT-07の暫定版と承認済み最新版
- MT-07の権限限定内部メモ
- MT-12の旧版と承認済み最新版
- MT-21とMT-33の鉱物分析報告
- XRDとRamanの標準手順書
- 鉱物分析用語集
質問は12問です。回答可能な10問に加え、文書に記載がない質問と、公開利用者には回答してはいけない権限限定情報の質問を各1問含めました。
比較した3条件
| 条件 | 検索設計 |
|---|---|
| 文書単位キーワード検索 | 1文書を1単位とし、文字2～4-gram TF-IDFとコサイン類似度で検索 |
| 単純な低次元検索 | 120文字固定チャンク、オーバーラップ0、文字TF-IDFを64次元LSAへ圧縮 |
| 設計済みハイブリッド検索 | 承認済み・最新版・公開文書に限定し、節単位チャンクへ文脈を付加。キーワード検索とLSA検索をRRFで統合 |
すべてtop-k=3です。設計差を検索層に限定するため、回答生成は実行していません。この試験の「dense」はニューラル埋め込みではなく、TF-IDFをLSAで低次元化した比較用ベースラインです。
実行条件
| 項目 | 条件 |
|---|---|
| 実行日 | 2026年9月30日（日本時間） |
| Python | 3.12.14 |
| scikit-learn | 1.8.0 |
| 乱数シード | 42 |
| 文書数 | 10件 |
| 質問数 | 12問 |
| top-k | 3 |
| RRF定数 | 60 |
| 生成モデル | 使用なし |
| 再ランキング | 使用なし |
実測結果
| 条件 | 正解根拠Hit@3 | 全根拠取得 | MRR | 旧版がtop-3に混入した質問 | 権限限定文書が混入した質問 |
|---|---|---|---|---|---|
| 文書単位キーワード検索 | 10/10 | 10/10 | 0.833 | 9/12 | 3/12 |
| 単純な低次元検索 | 9/10 | 9/10 | 0.770 | 7/12 | 1/12 |
| 設計済みハイブリッド検索 | 10/10 | 10/10 | 0.950 | 0/12 | 0/12 |
キーワード検索は、回答可能な10問すべてで正解文書をtop-3に含めました。しかし、12問中9問で旧版、3問で権限限定文書もtop-3に入りました。
例えば「MT-12の承認済み最終報告における加熱条件」を質問しても、キーワード検索と単純検索では、旧版の600 ℃・1時間が最新版の650 ℃・2時間より上位になりました。正解文書が検索結果に含まれているだけでは不十分です。生成モデルへ両方を渡せば、旧条件を採用する可能性があります。
単純な低次元検索は、言い換えを含む1問で正解根拠をtop-3に取得できませんでした。また、固定長チャンクでは表の列名、単位、値が分断される可能性がありました。
設計済み検索は、回答可能な10問すべてで必要な根拠を取得し、MRRは0.950でした。さらに、検索前のメタデータフィルターによって、旧版と権限限定文書の混入を防ぎました。
この結果から分かること
今回、キーワード検索でもHit@3は10/10でした。この結果は、ベクトル検索を導入すれば必ず検索精度が上がるわけではないことを示しています。
研究開発RAGで重要なのは、単純な正解文書取得率だけではありません。
- 正しい版を取得したか
- 利用者が閲覧可能な文書だけを取得したか
- 回答に必要な節を取得したか
- 複数の根拠を同時に取得できたか
- 上位何位に正解が現れたか
つまり、RAGの価値は「意味検索を使うこと」ではなく、質問に必要な根拠を、正しい条件と権限のもとで生成モデルへ渡すことにあります。
検証の限界
この試験は、10文書・12質問の小規模な説明用試験です。実在データ、ニューラル埋め込み、再ランキング、回答生成は使用していません。また、メタデータが正しく付与されていることを前提としています。
実運用前には、次を追加する必要があります。
- 実際の利用者が行う質問
- OCR誤りや表崩れを含む文書
- 同義語、略語、複数言語
- 複数文書を横断する質問
- ニューラル埋め込みモデルの比較
- 再ランキングの比較
- 生成モデルによる回答評価
- プロンプトインジェクション試験
- モデルやインデックス更新後の回帰試験
本試験は特定の製品やモデルの性能を示すものではなく、版、権限、チャンク、検索方式を分けて設計・評価する必要性を示すケーススタディです。
小規模実証から始める導入手順
研究開発部門でRAGを試す場合、次の順序が現実的です。
- 対象業務を一つ選ぶ
- 代表的な文書を数十～数百件集める
- 実際の質問から評価セットを作る
- 既存のキーワード検索をベースラインにする
- 単純RAGを構築する
- チャンク、メタデータ、検索方式を一つずつ改善する
- 専門家評価と利用者テストを行う
- 権限、更新、監査ログを確認する
- 本番対象を段階的に広げる
最初から全社共通基盤を目指すより、成功条件を測定できる狭いユースケースから始めた方が、効果とリスクを判断しやすくなります。
RAG導入でよくある失敗
全データを最初から登録する
不要な文書、旧版、重複文書が増えるほど、検索ノイズと管理負荷が増えます。
固定長チャンクをそのまま採用する
実験条件と結果、表の見出しと値が分断される可能性があります。
ベクトル検索だけで十分と考える
試料ID、化合物名、規格番号などではキーワード検索が有効です。
出典URLだけを表示する
文書名だけでなく、版、ページ、節、該当記載まで示さなければ、利用者の確認負担は減りません。
検索と生成をまとめて評価する
最終回答だけでは、検索失敗なのか生成失敗なのか判断できません。
回答可能な質問だけで評価する
記載がない質問、矛盾する文書、権限外情報、悪意ある文書も評価セットへ含めます。
RAG導入そのものを成果にする
評価すべきなのは、調査時間、確認時間、再作業、判断の正確性、事故リスクなどの改善です。
まとめ
研究開発データへRAGを導入する場合、生成モデルやベクトルデータベースの選択だけでは十分ではありません。
研究開発向けRAGでは、次の設計が重要です。
- ユースケースと回答範囲を限定する
- 数値と条件、出典、版を保持する
- 文書構造に沿ってチャンクを作る
- キーワード検索、ベクトル検索、メタデータを組み合わせる
- 利用者の権限を検索時に適用する
- 検索と回答生成を分けて評価する
- 回答不能質問や攻撃を含む評価セットを用意する
今回の小規模試験では、キーワード検索も正解文書を取得できました。しかし、旧版や権限限定文書が上位へ混入しました。設計済み検索は、正解根拠を維持しながら、それらの混入を防ぎました。
RAGの目的は、検索技術を高度化することではありません。研究者が根拠を確認しながら、より速く、より質の高い判断を行える状態を作ることです。
生成AI全体の研究利用については、研究者向け生成AIもご覧ください。
よくある質問
研究開発データをすべてベクトル化すべきですか？
必要ありません。利用目的に必要な文書から始め、検索価値、品質、権限、更新方法を確認して対象を広げます。数値集計に向く構造化データは、ベクトル検索ではなくデータベースへ問い合わせる方が適切な場合があります。
最適なチャンクサイズは何文字ですか？
すべての文書に共通する正解はありません。文字数より、実験、試料、測定、表、結論などの意味的なまとまりを優先し、評価質問に対する根拠取得率で調整します。
ベクトル検索とキーワード検索はどちらが優れていますか？
用途によります。言い換えにはベクトル検索、試料IDや化合物名の完全一致にはキーワード検索が有効です。研究開発では両方を組み合わせる構成が有力ですが、既存検索をベースラインとして比較すべきです。
RAGを導入すればハルシネーションはなくなりますか？
なくなりません。誤った文書や旧版を検索する、根拠を読み違える、計算を誤る、根拠のない部分を補うといった問題は残ります。検索と生成を分けて評価し、根拠がない場合の棄権を設計します。
RAGとAIエージェントはどちらを導入すべきですか？
指定資料に基づく質問回答が目的なら、まずRAGを検討します。検索後に解析、再検索、ファイル作成などを状況に応じて行う必要がある場合は、RAGをツールとして使うAIエージェントが候補になります。
参考文献
- Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
- Microsoft. RAG and Generative AI – Azure AI Search.
- OpenAI. Retrieval.
- Anthropic. Contextual Retrieval in AI Systems.
- Es, S. et al. (2023). RAGAS: Automated Evaluation of Retrieval Augmented Generation.
- Xu, C. et al. (2025). mmRAG: A Modular Benchmark for Retrieval-Augmented Generation over Text, Tables, and Knowledge Graphs.
- Gao, S. et al. (2025). Scaling Beyond Context: A Survey of Multimodal Retrieval-Augmented Generation for Document Understanding.
- Saucă, A.-A. and Rusnac, A.-L. (2026). Multimodal Hybrid Retrieval-Augmented Generation for Scientific Document Understanding using Open-Source SLMs.（プレプリント）
- NIST (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.
