RAG PoCを検索デモで終わらせない——FDEの実務設計

RAGのPoC（概念実証）で最初に見せやすい成果は、社内文書を検索して回答するチャット画面です。しかし、実務上、先に問うべきなのは「それらしい回答が出るか」ではなく、その回答を業務判断の根拠として扱ってよい範囲はどこまでか、という点です。ここを曖昧にしたまま進めると、検索できるデモは残っても、運用判断に耐える設計が残りません。

先に本稿の立場を述べます。RAG（Retrieval-Augmented Generation：外部データを検索し、その根拠に基づいて生成AIに回答させる手法）のPoCは、生成AIの画面試作ではなく、業務判断の品質管理を設計する作業として始めるべきです。FDE（Forward Deployed Engineering：顧客現場に入り、企画から試作、PoC、MVP〈実用最小限の製品〉、フィードバックまで並走するエンジニアリング）が初日に決めるべきなのは、モデルやUI（ユーザーインターフェース）より先に、判断範囲、根拠文書、評価、権限、PoC後に残す成果物です。

日本企業でRAGを検討するなら、稟議規程、品質マニュアル、製品仕様書、保守手順書のように、判断の根拠が文書に残る業務から考えるのが現実的です。その一方で、最新版、施行日、適用部門、例外運用、閲覧権限がそろっていない文書群を、そのままAI検索に載せても、PoCで検証したい論点がぼやけます。

初日に決めるのは「何を答えるか」ではなく「何を判断してよいか」

PoCの入口で、対象業務を「規程検索」「仕様書への質問応答」「問い合わせ対応」のように名付けるだけでは不十分です。FDEが最初に書面化したいのは、回答が支援してよい判断、支援してはいけない判断、人間の確認を必須にする判断の境界です。

たとえば、社内規程を対象にする場面を考えます。「出張費の上限を確認する」ことと「例外承認の可否を判断する」ことは別の業務です。前者は根拠条文の提示が中心になりますが、後者は権限、過去の運用、承認経路を含みます。PoCでは、この差を同じチャット画面に押し込まない設計を推奨します。

この境界を決めずに評価を始めると、回答の自然さだけが議論されます。外からは完成度が高いデモに見えても、利用部署、監査担当、システム部門、調達担当の間で「何を検証したPoCなのか」が一致しません。

根拠文書の境界をデータ投入前に固定する

Azure AI SearchにおけるRAGの概要では、大量文書をそのまま大規模言語モデル（LLM）に渡すのではなく、関連チャンクを返す設計が必要だと説明されています。つまり、検索対象に入れた文書、分割の粒度、検索戦略が、回答品質の前提になります。[ [5]](https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview?tabs=docs)

Azure AI Searchの説明では、索引作成時のチャンク化がRAG設計の要素として挙げられています。[ [5]](https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview?tabs=docs)

ここからの分析として、FDEはデータ投入の前に、まず文書名、版、施行日、適用部門、所有者を台帳化するべきだと考えます。加えて、参照可否、除外理由、分割方針、更新時の責任者も運用属性として分けて記録します。これは本格的な文書管理プロジェクトに見えるかもしれませんが、RAGでは検索品質の入力条件そのものです。

避けたいのは、手元にあるPDFやWebページを先に投入し、後から「古い文書が混ざっていた」「閲覧できない文書を根拠にした」と気付く進め方です。たとえば、品質マニュアルの旧版と新版が同じ検索インデックスに入っていたとします。回答が旧版の手順を根拠として示したなら、UIの改善ではなく、データ境界の不備として扱うのが妥当です。

評価セットは検索品質と回答品質に分ける

MicrosoftのRAG評価器の説明では、RAGの評価を、検索過程を評価するプロセス評価と、最終回答を評価するシステム評価に分けています。検索側ではRetrieval（検索の妥当性）、回答側ではGroundedness（根拠性）やRelevance（回答の的確さ）が評価対象として挙げられています。Groundednessは、回答が与えられたコンテキストに基づいているかを見る観点です。[ [7]](https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/rag-evaluators)

この分け方は、PoCの失敗原因を切り分けるために有効です。検索が正しい根拠チャンクを返していないのか、根拠は取れているのに回答生成で欠落や飛躍が起きているのかを分けなければ、改善対象が検索設定なのか、プロンプトなのか、文書整備なのか判断できません。

Azure AI Searchの説明では、インデックス作成時のチャンク化、ベクトル検索用の埋め込み、キーワード検索とベクトル検索を組み合わせるハイブリッド検索が挙げられています。同ページは、セマンティックランキング、スコアリングプロファイル、ベクトル重みや閾値調整にも触れています。[ [5]](https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview?tabs=docs)

FDEが用意する評価表の粒度

評価セットは、質問文と期待回答だけでなく、期待する根拠文書、根拠箇所、許容する言い換え、回答してはいけない条件を持たせる設計を推奨します。Groundednessを使う場合も、「根拠に基づいている」という抽象表現で止めず、どの文書のどの範囲を根拠として認めるかを評価表に落とし込みます。[ [7]](https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/rag-evaluators)

たとえば、保守手順書を対象にする場面では、「装置Aの再起動手順は何か」という質問だけでは粗すぎます。期待する根拠が「通常停止後の再起動」なのか、「異常停止後の復旧」なのかを分け、後者では注意事項の欠落を不合格にする、といった採点条件を先に書くべきです。

生成AIワークロードの性能評価について、AWSのGenerative AI Lensは、正解データ（グラウンドトゥルース）を用いた評価を定期的に実行し、出力を既知の正解と比較して性能を追跡することを勧めています。[ [8]](https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/genops01-bp01.html)

PoC段階では、評価セットを大きくするより、判断境界ごとに代表ケースを広く薄く置くほうが設計意図を確認しやすいと考えられます。網羅性を装うより、「この業務判断には使う候補になる」「この例外判断には使わない」と説明できる評価表を残すことを優先します。

権限管理は後付けにしない

実務上は、PoCであってもUIのログイン制御だけで済ませないことを勧めます。誰がどの文書群を検索対象にできるのかを、データストア、検索インデックス、チャンクのメタデータのどこで表現するかを先に決めます。

ここで避けたいのは、「PoCなので全員同じインデックスで試す」という割り切りです。画面上のログインだけを分けても、検索対象のチャンクが共通であれば、回答の根拠に本来見せるべきでない文書が混ざる設計になり得ます。PoCであっても、権限はUIではなく検索対象とデータストアの設計として扱うべきです。

人事規程と部門別運用メモを同じRAG基盤に載せる場合を考えます。利用者の役割ごとに参照できる文書を分ける必要があるなら、その条件は回答生成の指示文ではなく、検索前のフィルタやインデックス分離の設計に置くのが自然です。生成AIの回答を丁寧に制御しても、検索段階で取得された根拠が不適切なら、後段の生成だけで設計上の不備を埋め合わせるのは困難です。

PoC後に残す成果物を契約と調達の言葉にする

PoCの成果物は、動く画面だけにしないことを推奨します。RAGでは、文書の取り込み、分割、インデックス作成、検索、回答生成、評価が連鎖します。どの部分を自社に残す設計資産にし、どの部分をサービス機能として利用するのかを、開始時に確認します。

FDEの実務では、この論点をPoC終了時ではなく開始時に置くべきです。なぜなら、PoCで作ったインデックス、分割ルール、評価セット、権限対応表、失敗例の記録は、次のMVPや本番調達で再利用する可能性があるからです。何を納品物とし、何をサービス機能として利用するのかを書かないまま進むと、技術検証の結果を組織の資産に変えにくくなります。

• 文書台帳：対象文書、版、所有者、適用範囲、除外理由を一覧にします。
• 分割・インデックス設計書：チャンク化方針、検索方式、閾値、上位取得件数の考え方を記録します。
• 評価セット：質問、期待根拠、期待回答、不合格条件、利用者役割を記録します。
• 権限対応表：ユーザーまたは役割と、参照可能なデータストアや文書群の対応を整理します。
• 未解決課題一覧：文書の欠落、版管理の不備、例外運用、評価不能だった判断を記録します。

この一覧は、ベンダー選定表ではありません。PoCで分かったことを、次に誰が引き継いでも検証を再開できる粒度にするための最低限の設計資産です。AIX（AI transformation：AIを前提に業務・組織・システムを変える取り組み）の観点では、RAG PoCはAI導入であると同時に、文書、監査、契約、品質評価を接続する訓練だと位置付けるのが妥当です。

この進め方が向かない場合

本稿の設計は、すぐに一般公開向けの雑談ボットを試したい場合や、根拠文書より創作性を重視する用途には向きません。評価対象が業務判断ではなく利用体験そのものなら、文書台帳や権限対応表を厚く作る優先度は下がります。

一方で、規程、仕様、手順、契約、品質基準のように、回答の根拠が後から問われる用途では、検索デモを急ぐほど手戻りが増えると考えられます。FDEには、最初の一週間で動く画面を作る力だけでなく、動く前に決めるべき境界を合意する力が必要です。

実務への示唆

第一に、PoCキックオフの議題を「対象文書の収集」から始めないことを勧めます。先に、支援する業務判断、支援しない判断、人間確認を必須にする判断を一枚にまとめます。その後で、必要な根拠文書を逆算します。

第二に、評価は検索と回答を分けます。検索評価では期待する根拠チャンクが取れているかを見ます。回答評価では、根拠に基づいているか、必要事項を欠いていないか、答えてはいけない条件で抑制できているかを見ます。

第三に、権限と成果物を初日に契約・調達の言葉へ翻訳します。PoCで作るインデックス、分割ルール、評価セット、権限対応表、失敗例の記録を、納品物にするのか、サービス利用の前提にするのかを確認します。

FDEが担うべき役割は、AIを現場に置くことにとどまりません。業務判断の境界、根拠文書の扱い、評価の観点、権限、引き継げる成果物を言語化し、現場がAIを使ってよい条件を設計することです。

---

参考資料

[[1] デジタル社会推進標準ガイドライン（2026-09-01）](https://www.digital.go.jp/resources/standard_guidelines)

[[5] Retrieval-augmented generation (RAG) in Azure AI Search](https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview?tabs=docs)

[[7] Retrieval-Augmented Generation (RAG) Evaluators for Generative AI](https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/rag-evaluators)

[[8] GENOPS01-BP01 Periodically evaluate functional performance - Generative AI Lens](https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/genops01-bp01.html)

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-09-21。