検索システムの要件定義書やRFPは、データ整備、PoC、権限と運用費の設計を順に進めて作ると、予算超過や検索結果のずれを抑えられます。
発注企業の視点で、データからTCO、提案評価までを順に説明します。全体像は検索システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・検索システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
検索対象データの整備と範囲の定義
要件定義でまず決めるのは、検索対象にする文書の範囲です。検索の品質はAIの性能だけで決まらず、読み込ませるデータの質にも左右されます。
発注側は、対象文書を明確にしたうえで、要件定義の段階で整備工数とコストを見積もります。範囲が曖昧だと、開発後半に負荷が膨らみ、予算や予定が崩れます。
データ整備費の予算への組み込み
検索システム、とくにRAG型AI検索では、対象データの収集とクレンジングの費用が見落とされがちです。紙やExcel、スキャンPDFの情報はテキストにし、古い版を除く作業が必要になります。
- 文書の前処理：適切な単位への分割とメタ情報の付与
- 予算の確保：要件定義の見積もりへのデータ整備費の計上
この前処理は検索精度を左右する重要な工程です。また、一次データでは、データ分析基盤の構築予算の2〜3割を社内データの収集・クレンジングに要するとされています。
要件定義書には、文書の種類・件数・状態を一覧にして書きます。テキスト化済みか紙のままかも書き添え、整備工数を見積もります。
一次データによれば、データ品質が悪いと開発費が20〜30%上振れします。そのため、RFPで整備の責任範囲と費用をベンダーと合意しておくことが、予算超過を防ぐ要点です。整備を軽視した要件定義は、手戻りにつながります。
検索対象範囲と利用者の絞り込み
全社・全文書を最初から対象にせず、効果が大きく検証しやすい範囲に絞ります。最初は対象に含めない範囲も、あらかじめ決めておきます。
- 対象と利用者：どの部門の誰が、どの文書を検索するか
- 課題と成果指標：解決すべき課題と、問い合わせ削減率や0件ヒット数の目標値
- 検証範囲：PoCで評価する対象と合格基準
対象を広げるほど、データ整備の負荷と権限設計の複雑さが増し、PoCの結論も出にくくなります。
riplaはフルスクラッチ受託の立場から、漠然としたAI検索の希望を、対象データ・利用者・成果指標に分けて整理します。
対象を限定すれば、PoCの合格基準を判定できます。一方で、広い範囲では精度の低い文書を切り分けにくく、改善策も定まりません。
要件定義で「まずここから始める」と決めておくと、PoCの精度が高まり、本格開発へ移れます。そのうえで、効果を確かめてから対象を広げます。
成果指標を明確にすると、ベンダーが要件を提案に落とし込めます。また、目標が明確だと、見積もりの精度にも関わります。
PoCを3ヶ月で区切る進め方の要件化
検索システム、とくにRAG型AI検索では、要件にPoC（概念実証）を組み込みます。実データで検証し、その結果を見て本格開発へ進むかを決める段階的な設計が、無駄な投資を防ぎます。
3ヶ月で結論を出すPoCの設計
PoCの期間は区切り、仮説と合格基準を要件定義書に記します。そのうえで、検証結果を見てから本格開発へ進むかを判断します。
- 期間：3ヶ月以内に結論を出す前提の計画
- 合格基準：誰が見ても判定できる具体的な目標
一次データによれば、AIプロジェクトのPoC成功率は3ヶ月以内なら65%で、6ヶ月を超えると15%まで下がります。また、期間が延びると費用がかさみ、判断も遅れます。
Gartnerによれば、AIプロジェクトの30%がPoC後に放棄されます。そのため、合格基準は具体的な数値で置きます。たとえば、特定部門の問い合わせ上位50件に対し、80%以上で適切に回答できることを基準にできます。
明確な基準があれば、結果を客観的に評価できます。「なんとなく良さそう」という理由で本格開発へ進むリスクも抑えられます。また、3ヶ月で結論を出すことは、最大のコスト削減につながるという知見です。
撤退基準と段階的な発注条件の明記
要件定義とRFPには、継続の条件だけでなく撤退条件も記します。判断基準を先に決めておけば、効果の出ないシステムへの追加投資を避けやすくなります。
- PoCの未達：合格基準に届かない場合の本格開発の見送り
- 導入後の利用率：本番導入後6ヶ月で利用率が70%未満の場合の見直し
- 発注の段階：PoCと本格開発を分けた発注
撤退基準があれば、サンクコスト（すでに投じた費用）に引きずられた投資継続を避けられます。また、契約はPoCと本格開発を分け、成果を確かめてから後者を発注する設計が有効です。
一次データでは、AIプロジェクトの95%が期待した成果に届かないという現実も示されています。そのため、発注先が段階的な進行に対応できるかも確認します。
要件に「PoC→評価→本格開発」の流れを入れることが、リスク管理になります。いきなり全額をコミットする発注は危険です。
権限・セキュリティの非機能要件の定義
検索システムでは、機能要件と同じく非機能要件も欠かせません。特に社内の機密文書を検索対象にする場合、権限やセキュリティを緻密に定めておかないと、検索が情報漏えいの経路になりかねません。
そのため、検索でできることに加えて、誰に何を見せないかを要件にしておくことが、企業利用の前提になります。
アクセス権限とデータマスキングの要件化
権限要件では、役職や部門ごとに検索できる文書の範囲を定めます。誰が何を検索・閲覧できるかは、マトリクスにして整理します。
- 権限管理：権限外の文書を検索結果やAI回答に含めないこと
- データマスキング：対象項目と利用者の指定、機密情報の混入防止
- 既存基盤との連携：ID管理基盤（IdP）への接続の要否
RAG型AI検索では、AIが権限外の文書を根拠に回答する恐れがあります。そのため、検索の入口で権限フィルタリングを働かせる設計が重要です。
マスキングでは、どの利用者にどの項目を隠すかと、生成AIの回答に機密情報が混ざらないようにする制御方法を決めます。
権限とマスキングは、後から付け足すのが難しい根幹の設計です。要件から漏れると、大規模な作り直しにつながります。
RFPには、求めるセキュリティ水準と、準拠すべき規程やガイドラインを記します。
提案の段階で、ベンダーが規程やガイドラインに対応できるかを確認できるようにします。機密文書を扱う場合は、セキュリティ要件をさらに具体化する必要があります。
性能・可用性・ログ監査の要件
非機能要件には、応答速度や同時利用者数などの性能目標も含めます。文書や利用者が増えても、許容できる速度で検索できるかを定めておく必要があります。
- 性能：ピーク時の同時検索数と許容速度
- 可用性：利用者が必要なときに検索できる条件
- ログ監査：検索履歴の記録と、監査や利用状況の分析への活用
目標値がないと、公開後に検索が遅くて使えない事態になりかねません。とくにRAG型検索では、生成AIの回答時間も利用者の満足度を左右します。
誰がいつ何を検索したかを記録しておくと、不正アクセスの検知や利用状況の分析に使えます。検索ログは、監査の証跡であると同時に、精度改善の一次情報でもあります。
RFPに各要件を明記すれば、ベンダーの提案を同じ条件で比べられます。機能以外の要件も漏れなく定めておくことが、調達時の判断材料になります。
TCO（運用80%）を前提にした評価軸の設計
検索システムの要件定義では、TCO（総保有コスト）の視点が見落とされがちです。初期構築費だけで発注先を選ぶと、運用開始後に想定外の費用が生じます。
とくにRAG型AI検索は、運用費が読みにくい特徴があります。そのため、要件定義の段階でTCO全体を見据えた評価軸を設けることが、健全な投資判断につながります。
初期費用はTCOの2割、残り8割は運用
一次データが示す「TCOの80%ルール」では、初期構築費は総保有コストの約20%で、残り80%は運用・保守・教育にかかります。
- 継続する運用費：データ更新や辞書のチューニングの見込み
- 基盤と利用料：生成AIのAPI費用やベクトルデータベースの維持
検索システムは、構築後も費用がかかり続けます。そこで、要件定義では運用費込みのTCOで投資を評価します。
RAG型検索の運用費は、API利用料に加えてベクトルデータベースや監視を含めると、月30万〜130万円が目安です。
また、エージェント処理やリトライによって、生成AIのトークン消費が想定の5〜30倍に膨らむ場合もあります。利用量を制御しないと、運用費が急増します。
発注側は、月間の想定リクエスト数とトークン消費の上限制御について、ベンダーに見積もらせます。月額費用を比べ、初期費用の安さだけで判断しないことが大切です。
30〜40%のバッファとROIの評価ロジック
一次データによれば、企業の85%がコストを10%以上見誤り、初年度に予算を30〜40%超過します。そのため、検索システムの予算計画には、見積もりの不確実さを織り込んでおきます。
- 予算の余裕：見積もりに持たせる30〜40%のバッファ
- 効果の試算：実質人件費と充当率の保守的な設定
データ整備費や運用費は読みにくいため、予算超過に備えたバッファが欠かせません。RFPの見積もりを、そのまま前提としないようにします。
ROI（投資対効果）の評価ロジックは、要件定義の段階で定めておきます。検索で削減する時間を効果に換算する際は、実質人件費を給与の1.5〜2倍で見積もります。
削減時間の50%だけを効果に充てる「充当率50%ルール」で、保守的に試算します。これにより、稟議の説得力が高まり、過大な期待による失望も避けやすくなります。
riplaはフルスクラッチ受託と国内開発の立場から、TCOと保守的なROIを前提とした要件整理を重視しています。要件定義では、機能だけでなくコストとリスクも投資設計に含めます。
RFPの構成と提案評価のポイント
要件を固めたら、RFP（提案依頼書）にまとめて、複数のベンダーから提案を集めます。前提が揃わないと提案を公平に比べられないため、要件定義の成果をRFPに正しく反映しておくことが、適切なパートナー選定につながります。
RFPに盛り込む項目の整理
RFPには、背景と目的、検索対象データの範囲と現状、機能・非機能要件を記載します。PoCを含む進め方、予算と納期、希望する契約形態も示します。
- 課題と成果指標：解決すべき課題と、問い合わせ削減率や0件ヒット数の目標値
- 費用の内訳：費用を整備費から月額運用費まで分けた見積もり
具体的な目標があれば、ベンダーは実現方法を提案に落とし込めます。また、費用はAPI利用料やベクトルデータベース維持費も含む運用費まで分けて見積もらせます。
データ品質が悪いと開発費は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は対象データからTCOまで一貫して整理する要件定義を支援します。
全体像の確認には、あらためて完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。