PR：本記事にはアフィリエイト広告（プロモーション）を含みます。
RAG導入は、ツール選定ではなく対象業務と合格ラインの定義から始めます。何に答えられれば完成なのかを決めないまま実装に入ると、動くものはできても、それが十分かどうかを誰も判定できません。技術選定は、導入の5段階のうち3段階目にあたる手段です。
文書の整備は、全社の文書ではなく代表的な質問に答えられる範囲に絞ります。最初の構成は標準的な最小構成で足り、検索の高度化は後から足します。評価セットは、作り始める前に用意します。
- 決める順：技術選定より先に、対象業務と合格ラインを決める
- 整える範囲：全社文書ではなく、代表的な質問に答えられる範囲まで
- 完了の定義：元データを更新する仕組みが回り始めた時点
RAG導入は何から始めればよいのか？
RAG導入は、対象業務と合格ラインの定義から始めます。技術選定は3段階目の手段であり、最初に置くと何を作れば終わりなのかが決まらないまま実装が走ります。Microsoftも、RAGソリューションの設計は準備フェーズで業務要件を明確にすることから始めると整理しています。
| 段階 | やること | 飛ばすと起きること |
|---|---|---|
| 1 対象業務と評価基準の定義 | 答えさせる業務、代表的な質問、合格ラインを決める | 「精度が低い」の中身が人によって違い、完成を判定できない |
| 2 文書の棚卸しと整備 | 代表的な質問に答えるために必要な文書だけを対象に、所在・形式・権限を洗い出す | 全社文書の棚卸しに広がり、構築に着手できない |
| 3 小さく構築（技術選定はここ） | 標準的な最小構成でひととおり動かす | 高度な検索構成を効果を測れないまま作り込む |
| 4 評価 | 評価セットで測り、変更の前後を比較する | 変更が改善なのか改悪なのかを判定できない |
| 5 運用体制の設計 | 元データの更新、失効文書の扱い、権限変更の反映を決める | 公開直後から回答が古くなり、精度が落ちていく |
5段階の典拠は、Microsoftのアーキテクチャガイド「Design and develop a RAG solution on Azure」です。Microsoftは同ガイドで、RAGソリューションの開発を準備・チャンク分割・チャンクの拡充・埋め込み・情報検索・言語モデルのエンドツーエンド評価という6つのフェーズに分けて記述しています。
本記事の5段階は、Microsoftの6フェーズを実装作業の単位ではなく、導入する側が意思決定する単位でまとめ直したものです。チャンク分割から埋め込みまでの3フェーズは、発注側にとっては「小さく構築」という1つの決定に畳まれます。
RAGを作る前に確かめることが1つあります。OpenAIは公式ドキュメント「Optimizing LLM Accuracy」で、プロンプトエンジニアリングが通常もっとも良い出発点だとしています。現行のモデルとプロンプトでは解けないこと、かつ解けない理由がモデルの持たない社内情報の不足にあること、の2点を確認してから構築に進みます。
現行モデルで解けるかの確認を飛ばすと、プロンプトの書き方で済んだ問題に検索基盤を作ることになります。社内情報の不足が原因でないなら、RAGを足しても回答の質は変わりません。
RAGとファインチューニングのどちらを採るかという判断は、本記事の対象外です。手法の選び方はRAGとファインチューニングの違いは？選び方を解説で整理しています。
RAGの仕組みそのもの（検索・チャンク分割・生成の流れ）も本記事では扱いません。基本構造はRAGとはなにか？なぜ企業活用で必須なのか？で解説しています。本記事は、RAGを採ると決めた後の進め方に限定します。
導入の前に決めておくべきことは何か？
導入の前に決めるのは、対象業務、代表的な質問、対象文書の範囲、合格ライン、閲覧権限の5つです。Microsoftは準備フェーズでやることとして、解くべき領域の決定と業務要件の明確化、代表的なテスト用ファイルの収集、テストクエリの収集の3つを挙げています。
Microsoftが挙げる準備フェーズの3項目は、そのまま発注側のチェックリストになります。同社は、業務要件を明確に定義すること、収蔵物全体を代表するテスト用のファイルを集めること、テストクエリを集めて自前の資料がカバーしていない質問も作っておくこと、を求めています。
合格ラインを先に決める根拠も、Microsoftのアーキテクチャガイドにあります。同社は、ステップと変数の多さゆえに構造化された評価プロセスに従うことが重要だと述べ、各ステップの受け入れ基準を自分で決める前にプロセス全体を理解しておくよう求めています。順序としては、全体像の把握が先、基準の設定が次です。
合格ラインの決め方には枠組みがあります。①どの質問には必ず答えられなければならないか、②間違えたときに誰がどう気づくか、③どの水準なら利用者に開放してよいか、の3点を、業務側の担当者と合意した文言で残します。技術的な理想値ではなく、業務側が「これなら使える」と言った内容が合格ラインです。
閲覧権限を最初に決める理由は、インデックスの設計に効いてくるためです。検索時に利用者の権限で結果を絞るには、各チャンクに権限を表すメタデータが載っている必要があり、そのメタデータは取り込み時に付与されます。この仕組みから考えると、後から「この人には見せない」を足す変更は、インデックスの作り直しを伴います。
権限の設計は、最初の1本を動かすために必要な範囲に限定します。対象文書がどの権限グループに属するか、利用者をどのグループに割り当てるか、の2点が決まれば構築に進めます。全社のデータ基盤としての権限再設計は、1本目の導入の前提条件ではありません。
AIでこれができるといい、という話はあっても、RAGにこだわる必要性はそこまでない、というのが私の見方です。RAGというより検索システムがあれば済むことも多く、AIの必然性は低い場面があります。「実は検索システムを作りましょう」でも事足りることはあります。
組織内でみんながアクセスできるべき情報を見極めて、データ整備をして検索できるようにする、ということだけでもかなり有用なアプローチです。LLMを載せる前の段階でも価値が出る、というのが私の実務での実感です。
一方で、営業トークに使う、特定の相手向けに報告するといった文脈が入ってくると、間違いなくLLMの出力は必要になってきます。検索で見つけて終わりになる用途かどうかが、私が置いている線引きです。
RAGの場合はゴミデータも取ってきてしまう可能性もあります。負例が混じるとユーザビリティが一気に下がるケースにはやや向いていない、というのが私の見極め方です。
社内データの準備はどこまでやればよいのか？
社内データの準備は、全社の文書を整えるのではなく、先に決めた代表的な質問に答えられる範囲まで整えれば足ります。範囲を絞らずに始めた導入は、文書の棚卸しの段階で止まります。整備の終わりを定義できるかどうかが、この工程の成否を分けます。
範囲はクエリを起点に決めます。代表的な質問を20問書き出し、その20問に答えるために必要な文書だけを最初のインデックスに入れます。文書数を起点にすると「どこまで入れれば十分か」に答えられませんが、クエリを起点にすれば「20問に答えられたら整備は完了」という終了条件が作れます。
導入計画で見積もりを最も外すのは、文書を機械が読める形にそろえる工程です。PDFや表計算やスライドの中身は、そのままではテキストとして取り出せない部分を含み、取り出せた後も本文と付随情報が混ざります。この工程の工数は文書の件数ではなく形式のばらつきに比例するため、件数だけで見積もると外れます。
例えば、問い合わせ対応の担当者が実際に受けた質問から20問を選び、その回答に使った文書だけを最初の対象にする、という決め方が考えられます。想定例であり、20問という数を自社でいくつに置くかは、業務側と合意する対象です。
LLMが必要かどうかはユースケースに大きく依存します。ただ、データの整備は必須である、というのが私の実務で変わらない前提です。
整備の具体的なやり方（メタデータの持たせ方、非テキスト情報の扱い、チャンキング）はRAGにおけるデータクレンジングの重要性で扱っています。本記事が担当するのは、どこまでやるかという範囲と順番です。
最初の構成はどこまで作り込むべきか？
最初の構成は、標準的な最小構成で足ります。Anthropicは、LLMを使うアプリケーションでは可能なかぎり単純な解を見つけ、必要になったときにだけ複雑さを増やすことを推奨しています。検索の高度化は、評価セットで効果を測れるようになってから足します。
Anthropicは「Building effective agents」で、複雑さを足すのは、それが成果を明確に改善すると示せるときだけにすべきだと述べています。同記事が示す順序は、単純なプロンプトから始め、包括的な評価で最適化し、より単純な解では足りないと分かったときにだけ多段の仕組みを足す、というものです。
最小構成の中身は、Anthropicが「Introducing Contextual Retrieval」で標準的なRAGとして記述している手順がそのまま当てはまります。文書を数百トークン以下のチャンクに分割し、BM25で完全一致の上位チャンクを取り、埋め込みで意味的に近い上位チャンクを取ります。両者をランク融合で統合して重複を除き、上位K件をプロンプトに渡して回答を生成します。
Anthropicは同記事で、チャンクのサイズ・境界・重なりの選び方が検索性能に影響しうると注意書きを添えたうえで、常に評価を回すこと（Always run evals）を勧めています。最初の構成をどこまで作り込むかを決めるのは、設計時の議論ではなく評価の結果です。測れる状態を先に作れば、作り込みの是非は数字で決まります。
検索方式そのものの仕組みはベクトル検索とは？仕組みとRAGでの役割で解説しています。埋め込みが何を近いと判断しているかを押さえておくと、標準構成のまま置いてよい箇所と、後から足す候補になる箇所の見当がつきます。
固定の手順で足りない場面があることも、Microsoftは書いています。同社は、標準RAGのオーケストレーターは検索するかどうか・どのインデックスを引くか・何回検索するかを判断しないと明記したうえで、多段の推論や検索先の動的な選択が必要な場面では、エージェントが検索を道具として呼ぶ構成を別に置いています。
標準的なRAGとエージェント検索のどちらを選ぶかは、取り方で分かれます。大量のドキュメントから一括で引っ張ってくるようなケースには、RAGがすごく向いていると個人的には感じています。機械的に取得するケースは、私の実務ではエージェント検索で実施する方がいいと思っています。
何を、どの順でプロンプトへ渡すかという設計はコンテキストエンジニアリングとは？RAG・メモリ・ツールの設計で扱っています。エージェントそのものの定義と、ワークフローとの違いはAIエージェントとは？ワークフローとの違いと実務で使う条件で解説しています。
評価セットはいつ作ればよいのか？
評価セットは、作り始める前に用意します。OpenAIは、20問以上の質問と正解の組があり、失敗の内訳を調べて原因の仮説を持っている状態を、より高度な最適化に進むための土台としています。評価セットがないまま構築を始めると、変更が改善なのか改悪なのかを判定できません。
OpenAIは「Optimizing LLM Accuracy」で、良いプロンプトと、質問と正解からなる評価セットこそが最初の段階の最良の成果物だとしています。同ドキュメントが基準として挙げるのは、20問以上の質問と正解の組があること、失敗の詳細を調べて原因の仮説を持っていること、の2つです。
タスクの書き方には条件があります。Anthropicは「Demystifying evals for AI agents」（2026年1月9日公開）で、良いタスクとは2人の分野の専門家が独立に判定しても同じ合否になるタスクだと定義しています。判定が割れるタスクは、仕様の曖昧さがそのまま指標のノイズになります。
Anthropicは同記事で、評価の出発点を開発中の手動チェックに置いています。リリースのたびに検証している挙動と、利用者がよく試すタスクから始めよ、というのが同社の指示です。すでに本番稼働しているなら、バグ管理と問い合わせのキューから拾うことも勧めています。
開発中に人手で確認している項目は、そのまま評価セットの原型になります。手で確認できているということは、合否の判断基準がすでに人の頭の中にあるということであり、書き出せばタスクになります。この観点に立つと、人手レビューは評価セットの前段階であって、置き換えられる無駄ではありません。
Anthropicは各タスクに参照解を用意することも勧めています。参照解とは、すべての採点基準を通る既知の正解出力を指します。同社は、LLMを採点者に使う場合は人の専門家と綿密に較正し、人の採点と機械の採点のずれが小さいことを確かめるべきだとしています。
評価は1回作って終わりではありません。OpenAIは「Optimizing LLM Accuracy」で、現実には、評価し、最適化の仮説を立て、適用し、また評価して次の一手を見直す、という一連の最適化ステップになると述べています。評価セットは構築の入口で作り、運用に入っても足し続ける資産です。
作った後、運用に乗せるには何が必要か？
運用に乗せるために必要なのは、元データを定期的に更新する仕組みです。文書は追加・改訂・失効を続けるため、更新が止まったRAGは公開直後から精度が落ちていきます。5段階目の運用体制の設計まで終わり、更新が回り始めた時点が導入の完了地点です。
Microsoftはアーキテクチャガイド「Design and develop a RAG solution on Azure」で、RAGのデータパイプラインの流れを、媒体ファイルを取り込み、チャンクに分割し、内容から作ったメタデータのフィールドを付与し、埋め込みでベクトル化し、検索インデックスに保存する、という工程として記述しています。工程の名前がパイプラインであることに意味があります。
取り込みから保存までを手作業で1回通した構成は、次の更新でもう一度同じ手数がかかります。この構造から考えると、初回構築の時点で自動実行の単位を決めておくほうが、後から自動化するより安くつきます。更新の仕組みは、運用フェーズの追加要件ではなく設計の一部です。
失効した文書をいつ、誰が、どうやってインデックスから外すかを決めます。検索結果は文書の新旧ではなく問い合わせとの近さで並ぶため、失効版が残っていれば通常の結果として返ります。運用の決めごとにしないかぎり、失効の反映は誰の担当にもなりません。
文書を追加したら評価セットを回す運転も決めます。インデックスに1件足せば、既存の質問に対する検索結果の並びは変わります。この仕組みから考えると、追加のたびに測る運転を持つチームだけが、劣化を利用者からの苦情ではなく数値で先に検知できます。
閲覧権限が変わったときの反映方法も決めます。権限を表すメタデータは取り込み時にチャンクへ付与されるため、人事異動や組織変更で元の権限台帳が変わっても、インデックス側は自動では変わりません。権限台帳の変更をパイプラインの起動条件に含めるかどうかが、設計上の分かれ目です。
例えば、月次で改訂される規程類は月1回、日々増える議事録は日次で取り込む、というように文書の種類ごとに更新間隔を分ける設計が考えられます。想定例であり、どの間隔が必要かは、その文書が古いまま返ったときに何が起きるかで決まります。
精度が落ちたとき、検索と生成のどちらを疑うかの切り分けはRAGの精度が上がらない原因は？検索・データ・生成で切り分けるで解説しています。
よくある質問
RAGの構築期間はどれくらい見ておけばよいですか？
期間を決める変数は、対象文書の量ではなく、合格ラインの合意・権限要件・評価セットの有無の3つです。文書が少なくても、何ができれば完成かを業務側と合意できていなければ実装は終わりません。逆に代表的な質問と合格ラインが先に決まっていれば、最初の構成は標準的な最小構成で足りるため、見積もりは文書を機械が読める形にそろえる工数にほぼ収束します。
RAGは自社構築と既製ツールのどちらで始めるべきですか？
判断軸は4つです。文書の所在（社外のサービスに預けられるか）、権限要件（利用者ごとに見せる文書を分ける必要があるか）、更新頻度（元データを自動で取り込む必要があるか）、検索結果を検証できるか（どの文書を根拠に答えたかを確認できるか）。4つとも要件が緩いなら既製ツールで始め、権限の分離と検証可能性が要件に入るなら自社構築側に寄ります。
社内文書のアクセス権限はどう扱えばよいですか？
取り込み時にチャンクへ権限情報を持たせ、検索時に利用者の権限で絞るのが基本形です。最初の1本では、対象文書がどの権限グループに属するかと、利用者をどのグループに割り当てるかの2点だけを決めれば足ります。権限が分かれない文書から始めれば、この工程を後回しにできるため、権限設計が難所になる場合は対象範囲の選び方で回避できます。
RAG導入を担当することになったら、何から学べばよいですか？
評価の作り方からです。導入担当者の仕事は実装そのものより、何ができれば完成かを業務側と合意し、その合意を測れる形にすることに寄ります。次に文書を機械が読める形に整える工程、最後に検索方式の選択という順序が依存関係に沿っており、手を動かしながら体系的に学び直すならキカガクの生成AI講座のような社会人向けのコースも選択肢になります。
まとめ
RAG導入は、対象業務と合格ラインの定義から始めます。技術選定は3段階目の手段であり、出発点には置けません。文書の整備は代表的な質問に答えられる範囲まででよく、最初の構成は標準的な最小構成で足ります。
評価セットは作り始める前に用意します。そして、元データを更新する仕組みが回り始めた時点が、RAG導入の完了地点です。
PR
導入の段取りを、自分の業務で試せる状態にする
評価セットの作り方や文書整備の勘所は、公式ドキュメントを読むだけでは自分の業務に落ちません。手を動かしながら学ぶなら、AI・データサイエンスに特化した社会人向けオンラインスクールのキカガクが、生成AIを業務で使うためのコースを提供しています。講座の選び方そのものは生成AI講座の選び方｜社会人が失敗しない4つの基準で整理しています。
※ 説明会の参加は無料です。受講費用、開講日程、カリキュラムの詳細は公式サイトで最新情報を確認してください。
にほんブログ村
