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

AI FAQシステムの開発をベンダーに外注する際、プロジェクトの成否を大きく左右するのが要件定義とRFP（提案依頼書）の精度です。「どの問い合わせ範囲を、どの精度で自動応答させたいのか」が曖昧なまま発注すると、各社の見積もりがバラバラになり、横並びの比較ができなくなります。さらに契約後に「想定した規程やマニュアルが対象に含まれていなかった」「運用フェーズの費用が予想外に膨らんだ」といったトラブルが頻発します。とくにAI FAQシステムは、初期の開発費だけでなく、ベクトルデータベースのスケーリング費用やAPIの従量課金といった「隠れコスト」が見えにくく、要件定義の段階でこれらを織り込めるかどうかが、プロジェクトの予算管理を左右します。

本記事では、AI FAQシステムのRFP・要件定義書・提案依頼書について、費用相場の押さえ方から隠れコストの可視化、データ準備の工数配分やベンダー評価の観点までを、実務で使えるチェックの視点とともに解説します。要件定義の前提として全体像を把握したい方は、あわせてAI FAQシステムの完全ガイドもご覧ください。本記事は、その完全ガイドの内容を発注実務に落とし込み、RFPに具体的に何を書くべきかを掘り下げる内容です。

▼全体ガイドの記事
・AI FAQシステムの完全ガイド

AI FAQシステムのRFP作成で押さえる費用と隠れコストの把握

RFPを作成する前に、まず費用相場の感覚を持っておくことが重要です。相場観がないままベンダーの見積もりを受け取っても、その金額が妥当かどうかを判断できません。AI FAQシステムの開発費は、規模やアプローチによって大きく変動します。相場を知らずに発注すると、過剰な金額を支払ったり、逆に安さだけで品質の低いベンダーを選んだりするリスクが生じます。ここでは、RFP作成の前提となる費用相場と、見落としがちな隠れコストを整理します。

社内の規程やマニュアルを参照するRAG型のAI FAQシステムの開発費は、フェーズによって相場が異なります。小規模なPoC（概念実証）であれば、50万〜200万円程度、期間は1〜2ヶ月が目安です。中規模の本番構築になると、1,500万〜4,000万円程度、期間は3〜6ヶ月が一般的とされています。大規模な全社展開では、5,000万円以上に達することもあります。RFPには、自社がどのフェーズを目指すのかを明記することで、ベンダーが前提を揃えて見積もりを作れます。

「まずPoCで効果を検証したい」のか「最初から本番運用を見据えた構築をしたい」のかで、必要な予算もスコープも大きく変わります。フェーズを曖昧にしたまま発注すると、ベンダーごとに想定するスコープがずれ、見積もりの比較が成立しなくなります。AI FAQシステムで目指すフェーズと到達目標をRFPで明確に示すことが、適切な見積もりを引き出す第一歩です。

実務上は、いきなり中規模の本番構築に踏み込むのではなく、まずPoCで小さく検証してから本番に進む段階的なアプローチが推奨されます。PoCの段階で問い合わせ対応の精度が業務に耐えるかを見極め、効果を数字で確認してから本格投資に移れば、大きな失敗を避けられます。RFPには「PoCの結果を踏まえて本番フェーズへの移行可否を判断する」という段階的な進め方を盛り込み、各フェーズの費用を分けて見積もってもらうと、リスクを抑えた発注ができます。

AI FAQシステムの予算管理で最も注意すべきは、初期開発費以外に発生する隠れコストです。代表的なものとして、運用保守費が挙げられます。これは初期費用の15〜25%程度、ものによっては20〜30%が一般的な目安とされ、年間で継続的に発生します。RFPの段階でこの保守費を明記させておかないと、運用開始後に予算超過に陥ります。FAQの追加や規程改定への追従といった更新作業も保守費に含まれるため、その範囲も合わせて確認することが重要です。

このほかにも、利用量に応じて変動する隠れコストがあります。
・生成AIのAPI利用にかかる従量課金
・FAQデータの増加に伴うベクトルデータベースのスケーリング費用
・問い合わせ件数の増加に対応するためのインフラ増強費

これらは利用が拡大するほど膨らむため、RFPでは「想定問い合わせ量における月額ランニングコストの試算」をベンダーに求めることが重要です。初期費用だけで比較すると、運用フェーズで総額が逆転するケースもあります。AI FAQシステムは総保有コスト（TCO）の観点で各社を評価することをお勧めします。

要件定義書に盛り込むべき機能・非機能要件の整理

要件定義書は、機能要件と非機能要件の両面から作成する必要があります。機能要件は「何ができるか」、非機能要件は「どれだけの品質・性能・安全性で動くか」を定義します。AI FAQシステムでは、とくに対象とするFAQの範囲や回答精度といった項目の定義が見落とされがちです。ここでは、要件定義書に盛り込むべき項目を整理します。

機能要件では、AI FAQシステムに何を答えさせたいのかを具体的に記述します。対象とするFAQの範囲、参照する元データの種類と量、有人対応への引き継ぎの要否、連携が必要な社内システムなどを明確にします。とくにAI FAQシステムでは「どの文書を読み込ませるか」が回答精度に直結するため、対象とする規程・業務マニュアル・過去の問い合わせ履歴といった元データの棚卸しを要件定義書に明記しておくと、ベンダーが工数を正確に見積もれます。文書の形式が多様で、手書きのスキャンや複雑な表が混在している場合は、その旨を伝えておかないと、後から工数が膨らむ原因になります。

FAQの対象範囲は、社内向けのバックオフィス問い合わせなのか、顧客向けのサポート対応なのかで、求められる要件が変わります。社内向けであれば権限に応じた回答の出し分けが、顧客向けであれば回答トーンや有人エスカレーションの設計が重要になります。機能要件は、欲しい機能を漏れなく書き出したうえで、優先度をつけて「必須」と「あれば望ましい」を区別しておくと、予算に応じたスコープ調整がしやすくなります。

機能要件を整理する際は、RAG導入の成功フレームワークを参考にすると漏れを防げます。一般に、データ準備・チャンキング設計・検索方式の選定・生成の制御・評価という5つのステップで構成され、それぞれに要件を定義していきます。とくにデータ準備の工程は、プロジェクト全体の工数の40〜60%を占めるとも言われるほど重要であり、ここを軽視した要件定義は精度不足という形で跳ね返ってきます。各ステップでAI FAQシステムとして何をどこまで作るのかを明文化することが、機能要件の精度を高めます。

非機能要件では、回答精度の評価基準を定義することが特に重要です。「精度が高いこと」といった曖昧な表現ではなく、検索した文書の的確さを示すContext Precision（検索精度）や、回答が文書に忠実かを示すFaithfulness（忠実性）といった指標を、どの水準で評価するかを定めます。これらの精度目標を要件定義書に盛り込めば、AI FAQシステムの品質を客観的に検証する体制を発注時から組み込めます。精度を数値で語れる体制があるかどうかは、ベンダーの技術力を見極める指標にもなります。

このほか、応答速度、同時アクセス数への耐性、可用性、アクセス権限の制御、操作ログの保全といった非機能要件も定義します。社内のFAQ対応であっても、部署や役職に応じて閲覧できる情報が異なる場合は、権限に応じた回答制御を要件として明記する必要があります。非機能要件を曖昧にすると、完成後に「精度が低い」「権限を超えた情報が出る」といった不満が生じても、契約上の根拠を持って改善を求められません。測定可能な基準を要件定義書に盛り込むことが、品質を担保する鍵です。

非機能要件を定義するうえで欠かせないのが、評価と検収（受け入れ判定）の基準を発注時に合意しておくことです。「どの水準に達したら完成とみなすか」をRFPの段階で定めておかないと、納品時に評価が主観的になり、トラブルの火種となります。たとえば「代表的なFAQ100件に対して、正答率が一定以上であること」といった具体的な検収条件を設けておけば、ベンダーと発注者の認識のずれを防げます。測定方法と判定基準をセットで定義することが、円滑な検収につながります。

デジタル庁調達チェックシートを転用したセキュリティ・ガバナンス要件

AI FAQシステムは社内の機密情報を扱うため、セキュリティとガバナンスの要件を要件定義書に明確に盛り込む必要があります。ここで参考になるのが、デジタル庁が公開している調達向けのチェックシートの観点です。官公庁向けに整備された評価項目は、民間企業のRFPにも応用でき、見落としがちなリスクを網羅的に押さえられます。

デジタル庁の調達チェックシートでは、AIガバナンスの構築、セキュリティインシデントへの対応体制、システムの透明性の確保、プロンプトの隠蔽を避ける運用といった観点が示されています（出典：デジタル庁）。これらは行政向けに作られたものですが、その本質は「AIを安全かつ責任を持って運用できるか」を問うものであり、民間企業のAI FAQシステムの発注にもそのまま当てはまります。

具体的には、RFPに次のような要件を盛り込みます。
・社内データがAIの学習に利用されない契約・設定になっているか
・インシデント発生時の対応体制と連絡フローが定義されているか
・FAQの回答に対する監査やログ保全の仕組みがあるか
・利用するプロンプトや判断根拠を確認できる透明性があるか

これらの観点を要件定義書に明記することで、安全性を軽視するベンダーを選定段階で見極められます。デジタル庁の調達観点を転用することは、リスクの高い発注を避けるための実践的な手法です。

とくに生成AIの分野は技術の進歩が速く、安全性に関する論点も日々更新されています。公的機関が整理した調達観点を土台にすれば、自社にノウハウが乏しくても、押さえるべき要件の抜け漏れを大幅に減らせます。要件定義は専門知識を要する作業ですが、こうした公開された枠組みを活用することで、発注者側でも一定の品質を担保したRFPを作成できます。社内に知見がない場合ほど、信頼できる枠組みを下敷きにすることをお勧めします。

セキュリティ要件では、FAQの元データへのアクセス制御と、回答時の権限制御を定義しておくべきです。社内のAI FAQシステムでは、人事規程や経理マニュアルなど、部署や役職によって閲覧可否が分かれる情報が含まれます。利用者の権限を踏まえて回答内容を出し分けられる仕組みを要件として明記しないと、本来見せるべきでない情報が回答として返ってしまうリスクがあります。RFPには「閲覧権限に応じた回答制御」「参照データへのアクセス制御」を要件として盛り込むことが望まれます。

あわせて、不正な入力を検知・遮断する仕組みや、参照データの改ざんを検知する仕組みといった要件も検討します。これらの要件を発注時に明示しておけば、ベンダーは設計段階からセキュリティを考慮した構築を行います。後付けでセキュリティ対策を加えると、コストも工数も膨らみます。要件定義の段階で安全性を織り込むことが、結果的にコストを抑える最善策です。

セキュリティ要件は、機能要件や費用とトレードオフの関係になることがあります。厳格なアクセス制御や監査機能を求めれば、その分の開発工数と費用は増えます。だからこそ、扱うFAQデータの機密度に応じて、どこまでのセキュリティ水準を求めるかを判断することが重要です。すべてに最高水準を求めるのではなく、機密度の高い情報を扱う部分に重点的に対策を講じるという、メリハリのある要件設計が、コストと安全性を両立させる現実的なアプローチとなります。

データ準備と工数配分・ベンダー評価のフレームワーク

AI FAQシステムの精度を左右するのは、元データの整備と工数の配分です。RFPと要件定義書では、データ準備にどれだけのリソースを割くかを明示し、その作業を発注者とベンダーのどちらが担うのかを切り分けておくことが重要です。ここでは、工数配分の考え方と、それを踏まえたベンダー評価の観点を整理します。

RAGを用いたAI FAQシステムの導入は、一般にデータ準備・チャンキング設計・検索方式の選定・生成の制御・評価という5つのステップで進みます。このうちデータ準備の工程には、プロジェクト全体の工数の40〜60%を割くべきとされており、ここが精度を決定づけます。要件定義書には、対象FAQの元データをどこまで整備するのか、整備作業の責任分担をどうするのかを明示しておくことが重要です。工数配分を曖昧にしたまま発注すると、データ整備が中途半端になり、回答精度が伸びないという結果を招きます。

元データには、規程・業務マニュアル・過去の問い合わせ履歴など、形式も品質もばらばらの文書が含まれます。これらを検索しやすい形に整える前処理は地味な作業ですが、AI FAQシステムの精度はここで大きく差がつきます。RFPには「データ整備の範囲と工数を見積もりに明記すること」を求め、その作業を誰がどこまで担うのかを契約上はっきりさせておくと、後の責任の押し付け合いを防げます。データ準備にきちんと工数を割く前提でスコープを設計することが、成果につながる要件定義の核心です。

AI FAQシステムは、構築して終わりではなく、運用しながら精度を高めていくシステムです。そのため、ベンダー選定では「改善サイクルを回せる体制かどうか」を重視すべきです。回答できなかった問い合わせを収集し、元データやチューニングに反映する仕組みを持っているか、その運用を継続的に支援できるかを評価します。RFPには、改善の進め方や定期的なレビューの体制を提案させることで、運用フェーズまで見据えたベンダーかどうかを見極められます。

もう一つの重要な評価軸が、データ整備への支援の有無です。前述のとおりデータ準備は精度を左右する工程であり、ここを発注者だけに丸投げするベンダーでは、十分な精度に到達できません。元データの棚卸しや前処理を一緒に進めてくれる体制があるか、データ整備のノウハウを持っているかを、提案内容から見極めます。費用の安さだけでなく、改善体制とデータ整備支援という2つの軸で評価することが、AI FAQシステムのベンダー選定を成功させる鍵です。

評価を客観的に行うためには、RFPで各社に同じ前提を与え、同じ項目で提案を求めることが欠かせません。費用・スコープ・精度目標・改善体制・データ整備支援といった評価項目をあらかじめ整理し、各社の提案を同じ土俵で比較できるようにしておきます。要件定義書とRFPに評価の観点まで織り込んでおくことで、感覚ではなく根拠に基づいたベンダー選定が可能になります。

まとめ

本記事では、AI FAQシステムのRFP・要件定義書・提案依頼書について、費用相場と隠れコストの把握、機能・非機能要件の整理、デジタル庁調達チェックシートを転用したセキュリティ・ガバナンス要件、データ準備の工数配分とベンダー評価のフレームワークを解説しました。PoCは50万〜200万円、中規模構築は1,500万〜4,000万円という相場感を持ち、運用保守費（初期費用の15〜25%）やAPI従量課金といった隠れコストを要件定義の段階で織り込むことが、予算管理の要です。

対象FAQの範囲と元データの棚卸しを行い、精度目標を測定可能な非機能要件として定義したうえで、データ準備に工数の40〜60%を割く前提でスコープを設計し、改善体制とデータ整備支援を軸にベンダーを評価する。これらを要件定義書とRFPに織り込むことで、発注後のトラブルを大幅に減らせます。RFPは、単にベンダーへ要望を伝える書類ではなく、自社の要求水準を可視化し、各社を同じ土俵で比較するための設計図です。ここに時間をかけることが、結果的にプロジェクト全体の成否を左右します。本記事の観点を盛り込んだ要件定義書を作成し、納得のいくベンダー選定とAI FAQシステムの導入につなげてください。

株式会社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を創業。