RAGの要件定義（RFP）の書き方：外注で迷走しない依頼項目のまとめ

RAGとは何か：要件定義が難しくなる理由

RAG（Retrieval-Augmented Generation）は、生成AIに「社内文書などの根拠」を検索させ、その結果を踏まえて回答させる仕組みです。ChatGPTのような生成AIにそのまま質問するのではなく、ナレッジ（規程、マニュアル、FAQ、議事録、契約書、設計書など）を探してから答えさせるため、業務で使える正確さに近づけやすいのが特徴です。

一方で、RAGの要件定義（RFP）が迷走しやすいのは、単なる「チャット画面の開発」ではなく、検索（データ整備）・生成（回答品質）・運用（更新と監査）を同時に設計する必要があるからです。外注先が優秀でも、発注側が「何を、どの精度で、誰が、いつ使い、どんな失敗を許容しないか」を言語化できないと、見積もりも提案もぶれます。

さらにRAGは、デモが簡単に作れる反面、本番では「情報が見つからない」「引用がズレる」「最新規程が反映されない」「権限外の文書を参照してしまう」などの事故が起こりがちです。よってRFPでは、見た目の機能だけでなく、データの所在、アクセス権、評価方法、運用体制までを依頼項目として明確にすることが重要です。

RFP作成前に決めること：目的・対象業務・成功指標

RAGのRFPで最初に書くべきは「技術」ではなく「業務」です。目的が曖昧だと、外注先は“それっぽいチャット”を作れても、社内で使われず終わります。ここでは、発注側が先に整理すべき最低限の観点をまとめます。

業務ユースケース（使う人・使う場面・入力の型）

まず、想定するユースケースを3〜5個に絞って記載します。例：ヘルプデスク（情シス/総務）での問い合わせ一次回答、営業の提案書作成支援、製造現場の手順確認、法務の契約条項確認などです。各ユースケースごとに、利用者（職種/権限）、頻度、1回の問い合わせに許容される時間を添えます。「誰が」「何を」「どの画面で」行うかが具体的なほど、設計と見積もりが安定します。

期待するアウトプット（回答・根拠・引用）

RAGは「回答の文章」だけでなく、「根拠（どの文書のどの箇所か）」が価値になります。RFPには、引用表示の必要性（必須/任意）、引用の単位（ページ/段落/文書ID）、回答スタイル（箇条書き、手順、表形式、敬体/常体）を明記します。特に規程や品質関連では、回答と同時に根拠を出すことが監査対応の前提になります。

成功指標（KPI）と“失敗の定義”

「精度が高い」では曖昧です。例えば、ヘルプデスクなら一次解決率、平均対応時間、エスカレーション率、FAQ更新回数などをKPIにできます。また失敗の定義として「根拠のない断定をしたらNG」「社外秘を参照したら重大事故」「最新規程でない回答はNG」などの禁止事項も先に書きます。外注先はこの条件から、ガードレール（安全策）や権限制御を設計できます。

RAGのRFPに必須の依頼項目：機能要件（ユーザー視点）

ここからは、RAGシステムとしてユーザーが触れる機能要件を、RFPにそのまま転記できる形で整理します。全部を最初から盛り込む必要はありませんが、「後から必要になるのに抜けがち」な項目ほど優先して記載してください。

検索・回答体験（チャットUI/検索UI）

• 入力方法：自然文入力、テンプレ質問、カテゴリ選択、ファイル添付の可否
• 回答表示：回答本文、要点サマリ、手順化、注意喚起（リスクがある時の警告）
• 根拠表示：参照文書名、更新日、該当箇所の抜粋、リンク、ページ番号相当の識別子
• 再質問：会話履歴を踏まえる/踏まえないの切替、文脈のリセット
• 検索結果の可視化：「どの文書を何件見に行ったか」の表示、類似文書一覧

非エンジニアの方は、社内で既に使っている検索（社内ポータル、SharePoint、Google Drive検索等）を想像するとよいです。RAGの価値は、検索と要約を一体で提供できる点にあります。よってRFPでは、“検索結果だけ/回答だけ”ではなく、両方の表示要件を書いておくと品質が上がります。

フィードバックと改善ループ

RAGは運用で育ちます。RFPには、利用者が「良い/悪い」「役に立った/違う」「根拠が不足」などをワンクリックで返せる仕組み、コメント欄、改善チケット化の流れを依頼項目として入れます。最低でも、回答ログとフィードバックを管理画面で確認できることが重要です。改善できないRAGは、使われなくなるのが早いためです。

権限・監査（情シスが気にするところ）

• 認証：社内SSO（Microsoft Entra ID/Google Workspace等）連携の可否
• 認可：部署/役職/プロジェクト単位で参照可能な文書を制限できるか
• ログ：誰がいつ何を質問し、どの文書を参照し、何を回答したか
• マスキング：個人情報や機密語の伏字、回答時の自動注意

RAGは「回答の見た目」よりも、裏でどの文書にアクセスしたかが本質です。外注するなら、権限制御とログ要件を最初から固定し、後付けで高額にならないようにします。

業務システム連携（必要な場合のみ）

RAGの出力を業務で使うには、チケット発行（Jira/Redmine/ServiceNow）、CRM（Salesforce等）、グループウェア（Teams/Slack）との連携が効きます。RFPでは「どのツールに」「どの情報を」「どのタイミングで」連携するかを、できる範囲で書きます。迷う場合は「通知連携のみ」「URL共有のみ」など最小構成から始める方が安全です。

非機能要件が成否を分ける：品質・性能・セキュリティ・運用

RAG外注が迷走する最大要因は、非機能要件（動作条件・品質条件）が曖昧なことです。提案の比較もできず、PoCでは良かったのに本番で炎上します。ここでは、RFPに必ず入れたい非機能要件のテンプレ観点をまとめます。

回答品質の要件（正しさ・一貫性・安全性）

• 根拠必須ルール：根拠が見つからない場合は「不明」と回答し、推測で断定しない
• 引用優先：社内文書の記載を優先し、一般知識は補足として分離
• トーン：社内向けの丁寧語、断定表現の制御、注意事項の明示
• 禁止事項：個人情報の出力、機密区分の混在、社外共有前提の文章生成など

「ハルシネーション（それっぽい嘘）」が怖いという声は多いですが、RFPでルール化できます。例えば「根拠がない時は必ず追加質問を返す」「引用箇所がなければ回答を出さない」などです。“賢いAIを作る”ではなく、“事故らない挙動を定める”のがポイントです。

性能・可用性（現場で止まらない条件）

RFPには、同時利用人数、応答時間の目標、利用時間帯（24/365か、平日日中か）、障害時の対応時間（SLAの考え方）を記載します。例として「通常時は10秒以内に初回応答」「ピーク時同時50ユーザー」「月1回のメンテナンス枠」など。曖昧だと、コストを抑える提案が来て、後から遅い・落ちる問題が出ます。

セキュリティと法務・コンプライアンス

• データの持ち出し：入力した質問文/文書が学習に使われない設定、保存期間
• 保管場所：クラウド（AWS/Azure/GCP）かオンプレ、リージョン（日本国内など）
• 暗号化：転送時/保存時の暗号化、鍵管理
• 監査：ログの保全、エクスポート、監査証跡の保持期間

情シスや大企業では、ここが通らないと導入が止まります。外注先に丸投げせず、社内規程（情報区分、委託先管理、クラウド利用基準）に合わせてRFPに落とし込みます。「使ってよいLLM」「保存してよいログ」などの社内ルールが未整備なら、先に確認しましょう。

運用要件（更新・改善・問い合わせ対応）

RAGは文書が増えるほど価値が上がりますが、更新されないとすぐ陳腐化します。RFPには、文書追加の頻度（毎日/毎週/都度）、更新手順（担当部署がアップロード、情シスが承認など）、失敗時のロールバック、運用担当者の人数とスキルを記載します。外注先に求める範囲も明確にし、「運用保守契約に含める作業」「別途費用の作業」を切り分けます。

データ要件が8割：ナレッジ整備・取り込み・検索設計

RAGは「社内データが整っていないと精度が出ない」と言われます。これは事実ですが、裏を返すと、RFPでデータ要件を丁寧に書けば成功確率が一気に上がります。外注先はデータを見ないと正確な見積もりができないため、可能な範囲で“現状”を伝えることが重要です。

対象データ（何をRAGに入れるか）

RFPには、対象文書の種類、保存場所、形式、量の目安を書きます。例：PDF 2,000件、Word 500件、Excel 300件、SharePointサイト20、Boxフォルダ10、Confluenceスペース3など。加えて機密区分（公開/社内/部門限定/秘）と、更新頻度（年1改定、月次更新、都度）も添えます。“どのデータが正”かを定義しないと、古い資料を根拠に回答して事故ります。

取り込み（インジェスト）と前処理

• 取り込み方法：手動アップロード、フォルダ同期、API連携、定期バッチ
• テキスト化：PDFの文字抽出、スキャンPDFのOCR、図表の扱い
• メタデータ：文書名、版数、制定日/改定日、部門、タグ、機密区分
• 分割（チャンク）：見出し単位、段落単位、固定文字数などの方針

特にOCRが必要な場合、費用と工数が跳ねます。RFPには「スキャンPDFが何割か」「図表中心の資料があるか」を正直に書き、外注先に前処理（整形）まで含めるか、社内で先に直すかを決めます。

検索設計（見つかることが最優先）

RAGはベクトル検索（意味で探す）を使うことが多いですが、キーワード検索（文字で探す）やフィルタ（部門、年度、版数）も重要です。RFPには、検索に必要な絞り込み条件、同義語（例：旅費=出張費=交通費）、略称（稟議=申請）、製品名の表記ゆれなどを列挙します。現場が普段使う言葉で検索できる設計が、利用率を決めます。

回答の根拠の出し方（引用の品質）

「引用を出す」と言っても、文書へのリンクだけでは足りない場合があります。監査や品質部門向けなら、回答の各項目に対して引用を紐づける、引用箇所の前後文を表示する、版数と改定日を必ず併記するなどをRFPに書きます。逆に、現場のスピード重視なら「引用は折りたたみ表示」などUI要件に落とすとよいです。

外注で迷走しないRFPテンプレ：そのまま使える依頼項目リスト

ここでは、RAGのRFPに入れると「提案が揃い、比較でき、炎上しにくい」依頼項目を、チェックリスト形式でまとめます。自社の状況に合わせて削りながら使ってください。重要なのは、外注先に“判断材料”を渡すことです。

特に「想定質問例20件」は効果が大きいです。専門知識がなくても作れます。現場にヒアリングして「実際に飛んでくる質問」を集め、分類（規程、手順、例外、判断基準）して渡すだけで、外注先はデータ整備・評価設計・プロンプト設計の精度を上げられます。質問例は、RAGの要件定義そのものです。

評価（受入）をRFPに書く：PoC止まりを防ぐ

RAGは「なんとなく良さそう」で終わりがちなので、受入基準を先に定義します。例：テスト質問100件に対し、根拠付きで正答70%以上、誤答のうち重大事故0件、応答時間中央値10秒以内、参照文書の誤権限参照0件、など。加えて、評価レポートの提出（どの文書が引けないか、どの質問で失敗するか）を納品物に含めます。受入が定義されると、外注先の提案が「品質に責任を持つ設計」になります。

価格がブレる項目を先に固定する

見積がバラつく代表例は、(1)OCRや文書整形の範囲、(2)権限制御の粒度、(3)運用ツール（管理画面）作り込み、(4)クラウド基盤の要件、(5)評価と改善の回数、です。RFPでは「どこまでを初期費用に含め、どこからを運用で改善するか」を明記します。迷う場合は、初期は最小スコープで本番稼働し、改善枠（毎月◯時間）を運用契約に含める形が現実的です。

まとめ

RAGは「生成AIの画面を作るプロジェクト」ではなく、社内ナレッジを検索して根拠付きで回答し、運用で改善していく仕組みづくりです。外注で迷走しないためには、RFP（要件定義）で目的・ユースケース・データ要件・権限/監査・評価方法までを書き、提案と見積の前提を揃えることが重要です。

• RAGの価値は「回答」よりも「根拠（どの文書か）」にある。引用要件を明確にする
• 失敗を防ぐには、非機能要件（セキュリティ、性能、ログ、運用）を先に固める
• データ要件が品質の8割。対象文書、更新頻度、版管理、OCRの有無をRFPに書く
• 受入基準（テスト質問セットと合格条件）を書けば、PoC止まりを回避しやすい

「どこまでRFPに書くべきか分からない」「文書が散らばっていてデータ要件を整理できない」「情シス基準のセキュリティを満たしつつRAGを進めたい」といった場合は、要件定義の段階から伴走支援を入れると最短で前に進みます。