検索システムのRFP/要件定義書/提案依頼書について

検索システムの外注を成功させられるかどうかは、要件定義とRFP（提案依頼書）の質でほぼ決まります。とくにRAG型の社内AI検索のように、技術が新しく成果が読みにくい領域では、要件があいまいなままベンダーに丸投げすると、見積がばらつき、リリース後に「思っていた検索と違う」という致命的なズレが生じます。一次データでも、要件が不明確なまま進めると開発費が30〜50%増加すると示されており、要件定義の精度がそのままコストとリスクに跳ね返ります。

本記事は、検索システムの要件定義書・RFP・提案依頼書の作り方を、発注企業の視点から実務的に解説する「要件定義特化」の内容です。検索対象データの整備とスコープの定義、PoCを3ヶ月で区切る進め方、権限管理・データマスキングといった非機能要件、そしてTCO（総保有コスト）の80%を占める運用前提の評価軸まで、一次データを交えて具体的に解説します。なお、検索システム全体の費用相場や構築方法をまだ把握していない方は、まず検索システムの完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・検索システムの完全ガイド

検索対象データの整備とスコープを定義する

検索システムの要件定義で最初に固めるべきは、「何を検索対象にするか」というデータのスコープです。検索の品質は、AIの性能よりも食わせるデータの質で決まります。だからこそ、対象とする文書群を明確にし、その整備にどれだけの工数とコストがかかるかを、要件定義の段階で見積もる必要があります。ここを曖昧にしたまま進めると、開発後半でデータ整備の負荷が膨らみ、予算とスケジュールが一気に崩れます。

検索システム、とくにRAG型AI検索の要件定義で見落とされがちなのが、検索対象データの収集・クレンジング費です。紙やExcel、スキャンPDFに散在する情報をテキスト化し、古い版を除き、文書を適切な単位に分割し、メタ情報を付与する。この前処理は地味ですが、検索精度を左右する最重要工程です。一次データでは、データ分析基盤の構築において、社内データの収集・クレンジングに全体予算の2〜3割を要すると示されており、検索システムでも同様の備えが必要です。

要件定義書には、検索対象とする文書の種類・件数・現在の状態（テキスト化済みか、紙のままか）を棚卸しして明記し、整備にかかる工数を見積もります。データ品質が悪いまま進めると、一次データの通り開発費が20〜30%上振れします。RFPの段階で「データ整備はどちらの責任範囲か」「整備にどれだけのコストを見込むか」をベンダーと握っておくことが、後の予算超過を防ぐ最大のポイントです。データ整備を軽視した要件定義は、ほぼ確実に手戻りを招きます。

要件定義では、最初から全社・全文書を対象にしようとせず、効果が大きく検証しやすい範囲に絞ることが賢明です。「どの部門の」「どんな文書を」「誰が」検索するのかを明確に定義し、初期スコープを最小限に保ちます。対象を広げるほどデータ整備の負荷と権限設計の複雑さが増し、PoCの結論も出にくくなります。要件定義は「何をやるか」だけでなく「何を最初はやらないか」を決める作業でもあります。

あわせて、検索システムで解決したい課題と、その成果指標を要件として明文化します。「問い合わせを何割減らしたいのか」「サイト内検索の0件ヒットをどこまで下げたいのか」といった具体的な目標があれば、ベンダーも要件を提案に落とし込みやすくなります。riplaはフルスクラッチ受託の立場から、漠然とした「AI検索を作りたい」を、対象データ・利用者・成果指標まで分解する要件整理を重視しています。スコープと目標を明確にすることが、見積の精度と提案の質を高める出発点です。

初期スコープを絞ることには、データ整備の負荷を抑える以上の意味があります。対象を限定すれば、PoCで検証すべき範囲も明確になり、合格基準を判定しやすくなります。逆に最初から対象を広げると、どの文書で精度が出ていないのか切り分けが難しくなり、改善の打ち手も定まりません。要件定義の段階で「まずここから始める」と明確に決めることが、PoCの精度を高め、本格開発への移行をスムーズにします。広げるのは効果を確認してからで遅くありません。

PoCを3ヶ月で区切る進め方を要件に盛り込む

検索システム、とくにRAG型AI検索の要件定義では、いきなり本番システムを作るのではなく、PoC（概念実証）を要件として組み込むことが重要です。AIを使った検索は、実際にデータを食わせて試してみるまで、本当に実用に耐える精度が出るか分かりません。だからこそ、要件定義の段階で「まずPoCで検証し、結果を見て本格開発に進む」という段階的なプロセスを設計しておくことが、無駄な投資を防ぎます。

PoCを要件に盛り込むときの鉄則は、期間を3ヶ月で区切ることです。一次データによれば、AIプロジェクトのPoC成功率は3ヶ月以内なら65%、6ヶ月を超えると15%まで落ち込みます。3ヶ月で結論を出すことが最大のコスト削減になるという知見です。だらだらとPoCを続けるほど、コストばかりかさんで判断が先送りされ、結局Gartnerの言うAIプロジェクトの30%がPoC後に放棄される、という末路をたどりかねません。

要件定義書には、PoCで検証する仮説と、合格基準を具体的に記載します。たとえば「特定部門の問い合わせ上位50件に対し、80%以上で適切な回答を返せること」といった、誰が見ても判定できる基準です。この合格基準があれば、PoCの結果を客観的に評価でき、本格開発に進むか撤退するかをデータで判断できます。あいまいな「なんとなく良さそう」で本格開発に進む要件定義こそ、最も危険です。

要件定義とRFPでは、進める基準だけでなく、撤退する基準も明記しておくことが大切です。たとえば「PoCで合格基準に達しなければ本格開発に進まない」「本番導入後6ヶ月で利用率が70%未満なら見直す」といった撤退条件です。撤退基準を事前に決めておけば、サンクコスト（すでに投じた費用）に引きずられて、効果の出ないシステムに投資を続ける愚を避けられます。

RFPの契約形態としては、PoC段階と本格開発段階を分けて発注する設計が有効です。PoCで成果を確認してから本格開発を発注すれば、リスクを段階的に管理できます。一次データでは、AIプロジェクトの95%が期待した成果に届かないという厳しい現実も示されており、いきなり全額をコミットする発注は危険です。要件定義に「PoC→評価→本格開発」という段階を組み込むこと自体が、最大のリスク管理になります。発注先には、この段階的な進め方に対応できるかを必ず確認してください。

権限・セキュリティの非機能要件を定義する

検索システムの要件定義で、機能要件と同じくらい重要なのが非機能要件です。とくに社内の機密文書を検索対象にする場合、権限管理とセキュリティの要件を緻密に定義しなければ、便利な検索が一転して情報漏えいの経路になりかねません。検索で「何ができるか」だけでなく、「誰に何を見せないか」を要件として明文化することが、企業利用の前提条件です。

権限要件では、役職・部門ごとに検索できる文書範囲を定義します。誰が何を検索・閲覧できるかをマトリクスで整理し、権限のない文書は検索結果や生成AIの回答に一切含まれないことを要件として明記します。とくにRAG型AI検索では、AIが権限外の文書を根拠に回答してしまうリスクがあるため、検索の入口で権限フィルタリングを効かせる設計が要件上きわめて重要です。既存のID管理基盤（IdP）と連携するかどうかも、ここで定義します。

あわせて、個人情報や機密数値を伏せるデータマスキングの要件も定義します。どの項目をどの利用者に対してマスクするか、生成AIの回答に機密情報が混入しないようどう制御するか、を具体的に記述します。これらは後付けが難しい根幹の設計であり、要件定義の段階で漏らすと大規模な作り直しにつながります。RFPには、求めるセキュリティ水準と、自社が準拠すべき規程やガイドラインを明記し、ベンダーがそれに対応できるかを提案で確認できるようにしておきましょう。

非機能要件には、検索の応答速度や同時利用者数といった性能要件も含めます。文書が増えユーザーが増えても、許容できる速度で結果が返るか。ピーク時に何人が同時に検索しても耐えられるか。こうした性能の目標値を要件として定義しておかなければ、リリース後に「遅くて使えない」という事態に陥ります。RAG型検索では、生成AIの回答が返るまでの応答時間も、利用者の満足度を左右する重要な指標です。

さらに、検索ログの記録と監査の要件も定義します。誰がいつ何を検索したかを記録し、不正アクセスの検知や利用状況の分析に使えるようにします。検索ログは、ガバナンス上の監査証跡であると同時に、検索精度を改善するための一次情報でもあります。これらの非機能要件は、RFPで明確に求めておくことで、ベンダー間の提案を同じ土俵で比較できるようになります。機能だけでなく、こうした足回りの要件を抜け漏れなく定義することが、後悔しない検索システム調達の条件です。

TCO（運用80%）前提で評価軸を設計する

検索システムの要件定義とRFP評価で、最も見落とされがちなのがTCO（総保有コスト）の視点です。初期の構築費だけを見て発注先を選ぶと、運用が始まってから想定外の費用に苦しみます。とくにRAG型AI検索は、運用コストの読みにくさが特徴であり、TCO全体を見据えた評価軸を要件定義の段階で組み込んでおくことが、健全な投資判断につながります。

一次データが示す重要な原則が「TCOの80%ルール」です。これは、システムの総保有コストのうち初期構築費は約20%にすぎず、残り80%は運用・保守・教育にかかる、という考え方です。検索システムでも、構築して終わりではなく、データの更新、辞書のチューニング、生成AIのAPI利用料、ベクトルデータベースの維持といった運用コストが継続的に発生します。要件定義では、この運用費を含めたTCOで投資を評価する設計が不可欠です。

具体的には、RAG型検索の運用はAPI利用料に加え、ベクトルデータベースや監視を含めて月30万〜130万円が目安とされます。生成AIのトークン消費は、エージェント処理やリトライで想定の5〜30倍に膨らむこともあり、利用量を制御する仕組みがなければ運用費が暴騰します。要件定義では「月間の想定リクエスト数」「トークン消費の上限制御」をベンダーに見積もらせ、運用フェーズの月額コストを数字で比較できるようにしておきましょう。初期費の安さだけで選ぶと、運用で逆転されます。

一次データによれば、企業の85%がコストを10%以上見誤り、初年度で予算を30〜40%超過するとされます。だからこそ、見積には30〜40%のバッファを持たせることが推奨されます。要件定義とRFPの評価では、提示された見積をそのまま信じるのではなく、この超過リスクを織り込んで予算計画を立てることが現実的です。とくにデータ整備や運用費が読みにくい検索システムでは、バッファの確保が欠かせません。

投資判断のためのROI（投資対効果）ロジックも、要件定義の段階で固めておきます。検索による削減時間を効果に換算する際は、実質人件費を給与の1.5〜2倍で見積もり、さらに削減時間の50%のみを効果に充当する「充当率50%ルール」で保守的に試算します。こうした堅実なロジックで効果を見積もれば、稟議でも説得力が増し、過大な期待による失望も避けられます。riplaはフルスクラッチ受託と国内開発の立場から、TCOと保守的なROIを前提とした要件整理を重視しています。要件定義は機能の列挙ではなく、コストとリスクを織り込んだ投資設計だと捉えることが、成功への近道です。

RFPの構成と提案評価のポイント

要件を固めたら、それをRFP（提案依頼書）に落とし込み、複数のベンダーから提案を集めて比較します。RFPの構成が整っていなければ、各社の提案がバラバラの前提で出てきて、横並びの比較ができません。要件定義の成果を正しくRFPに反映し、提案を公平に評価する仕組みを作ることが、最適なパートナー選定につながります。

検索システムのRFPには、プロジェクトの背景と目的、検索対象データの範囲と現状、求める機能要件と非機能要件、PoCを含む進め方、予算と納期、契約形態の希望を盛り込みます。とくに重要なのが、解決したい課題と成果指標を明記することです。「問い合わせを何割減らしたいか」「サイト内検索の0件ヒットをどこまで下げたいか」という目標があれば、ベンダーはそれを実現する具体的な提案を返せます。

また、RFPには見積の内訳を項目ごとに分けて提示するよう求めます。データ整備費、構築費、PoC費、運用費（月額のAPI利用料やベクトルデータベース維持費）を分けて出してもらえば、初期費だけでなくTCOで比較できます。一次データの通り、データ品質が悪ければ開発費は20〜30%、要件が不明確なら30〜50%上振れします。RFPで前提条件を揃えておくことが、こうした上振れリスクを各社に正しく見積もらせ、現実的な提案を引き出す前提になります。

集まった提案を評価する際は、価格の安さだけで選ばないことが鉄則です。検索システム、とくにRAG型AI検索は不確実性が高く、安すぎる見積はデータ整備や運用の手間を過小評価している可能性があります。提案を評価する軸としては、要件への適合度、データ整備への向き合い方、PoCの設計、運用フェーズのコスト見積、撤退基準への対応、そして実績や技術力を総合的に見ることが大切です。

とくに見積の妥当性を見極めるには、各社がデータ整備費や運用費をどう見積もっているかを比較するとよく分かります。これらを軽く見積もっているベンダーは、後から追加費用が発生するリスクが高いと言えます。逆に、データ整備の重要性をきちんと提案に織り込み、PoCと撤退基準に対応できるベンダーは、現実的なパートナーと言えます。riplaはフルスクラッチ受託と国内開発の立場から、データ整備から運用までを見据えた現実的な見積と、段階的な進め方の提案を重視しています。RFPと提案評価は、要件定義の成果を実際の調達につなげる最後の関門であり、ここを丁寧に進めることが投資の成否を分けます。

まとめ

検索システムの要件定義とRFPを振り返ると、成功の鍵は四つに集約されます。検索対象データの整備費を予算の2〜3割として見込みスコープを絞ること、PoCを3ヶ月で区切り合格基準と撤退基準を明記すること、権限管理・データマスキング・性能・ログという非機能要件を緻密に定義すること、そしてTCOの80%が運用であることを前提に評価軸を設計することです。要件が不明確なら開発費は30〜50%増え、データ品質が悪ければさらに20〜30%上振れします。

要件定義で大切なのは、流行のAI機能を盛り込むことではなく、データ・PoC・セキュリティ・TCOという現実的な論点を、数字で評価できる形に落とし込むことです。見積には30〜40%のバッファを持たせ、ROIは実質人件費1.5〜2倍・充当率50%で保守的に試算してください。riplaはフルスクラッチ受託と国内開発を組み合わせ、対象データ・PoC設計・権限要件・TCOまでを一貫して整理する要件定義を支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。