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

AI FAQシステムの発注は、対象と精度を定め、費用と役割を明記し、同じ基準で提案を比べる順に進めると、適切な選定につながります。

費用、要件、セキュリティ、データ準備とベンダー評価の順に見ていきます。全体像はAI FAQシステムの完全ガイドもご覧ください。

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

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

AI FAQシステムの小規模PoC、中規模の本番構築、大規模な全社展開にかかる費用を並べた図
検証から全社展開へ進むにつれて、費用の規模も大きくなります。

RFPを作る前に費用相場を把握しておくと、見積もりの妥当性を判断できます。相場を知らずに発注すると、過剰な支払いを招いたり、安さだけで品質の低いベンダーを選んだりするリスクがあります。

AI FAQシステムの開発費は規模やアプローチによって変わるため、費用相場と、見落としやすい隠れコストを順に確認します。

RFPに織り込むフェーズ別の費用相場

社内規程やマニュアルを参照するRAG型では、フェーズごとに費用と期間が異なります。

  • 小規模PoC(概念実証):50万〜200万円程度、期間は1〜2ヶ月が目安です。
  • 中規模の本番構築:1,500万〜4,000万円程度、期間は3〜6ヶ月が一般的です。
  • 大規模な全社展開:費用が5,000万円以上に達することもあります。

PoCで効果を検証するのか、本番運用を見据えて構築するのかで、予算とスコープは変わります。フェーズが曖昧なままだと、各社の想定スコープがずれ、見積もりを比べられなくなります。

発注側は、目指すフェーズと到達目標をRFPに明記し、ベンダー間で前提を揃えたうえで見積もりを求めます。

実務では、PoCで小さく検証してから本番へ進む段階的な方法が推奨されます。PoCで問い合わせ対応の精度が業務に耐えるかを確かめ、効果を数字で見てから本格投資すれば、大きな失敗を避けられます。

RFPには、PoCの結果を踏まえて本番への移行可否を判断する進め方を盛り込みます。各フェーズを分けて見積もってもらえば、発注時のリスクを抑えられます。

RFPで明示させるべき隠れコスト

予算を組むときは、初期開発費以外に発生する費用も見積もっておきます。

運用保守費は代表的な隠れコストで、初期費用の15〜25%程度、ものによっては20〜30%が目安とされ、毎年継続してかかります。

RFPに保守費を明記させないままだと、運用開始後に予算を超えるおそれがあります。

FAQの追加や規程改定への対応が保守費に含まれるのか、その範囲も確認しておきます。

利用量に応じて変動する費用には、次のようなものがあります。想定する利用量をもとに、月額のランニングコストを試算します。

  • 生成AIのAPI:利用量に応じた従量課金が発生します。
  • ベクトルデータベース:FAQデータの増加に伴い、拡張費用が生じます。
  • インフラ:問い合わせ件数の増加に応じて、増強費が必要です。

利用が広がるにつれて、これらの費用は膨らんでいきます。

RFPでは、想定する問い合わせ量での月額費用の試算を求めます。

初期費用だけで比べると、運用フェーズを含めた総額が逆転するケースもあります。

AI FAQシステムは、総保有コスト(TCO)で比べます。

ポイント

費用は初期開発費だけでなく、保守費と利用量に応じた費用を含む総額で比べます。迷ったときは、PoCで効果を確かめてから本番に進むと、見積もりの前提がずれにくくなります。

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

要件定義書では、機能要件と非機能要件の両面を扱います。

機能要件は「何ができるか」、非機能要件は品質・性能・安全性を定義します。

対象FAQの範囲や回答精度は見落とされやすい項目です。

要件定義書に盛り込む内容を、機能と非機能に分けて見ていきます。

対象FAQ範囲と元データの棚卸し

まず、AI FAQシステムに答えさせる内容を具体的に記します。

機能要件では、対象FAQと元データの種類・量を明確にします。

有人対応への引き継ぎや、連携する社内システムも併せて書きます。

参照する文書は回答精度に直結します。

発注側が規程、業務マニュアル、過去の問い合わせ履歴を棚卸しし、要件定義書に記しておくと、工数を見積もりやすくなります。

手書きのスキャンや複雑な表など、文書の形式が多様な場合は、その旨も事前に伝えます。

共有しないまま進めると、後から工数が膨らむ原因になります。

社内向けのFAQと顧客向けサポートでは、必要な機能要件が異なります。社内向けでは権限に応じた回答、顧客向けでは回答のトーンや有人への引き継ぎ設計が、特に大切になります。

必要な機能を洗い出し、「必須」と「あれば望ましい」に分けて優先度を付けます。そうしておけば、予算に合わせてスコープを調整できます。

機能要件を整理するときは、RAG導入の成功フレームワークも参考になります。一般には、次の流れで構成されます。

  • データ準備
  • チャンキング設計
  • 検索方式の選定
  • 生成の制御
  • 評価

特に、データ準備はプロジェクト工数の40〜60%を占めるとも言われます。

データ準備を軽く見ると精度不足につながるため、各段階で何をどこまで作るかを文書に残しておきます。

精度目標と非機能要件の定義

非機能要件では、回答精度の評価基準を定めます。「精度が高いこと」だけでは曖昧なので、評価の水準まで書き込みます。

  • Context Precision(検索精度):検索文書の的確さを示します。
  • Faithfulness(忠実性):回答が文書に忠実かを示す指標です。

要件定義書に精度目標を盛り込むと、品質を客観的に検証できます。また、数値で評価できる体制は、ベンダーの技術力を見極める材料にもなります。

非機能要件には、応答速度や同時アクセスへの耐性、可用性を含めます。さらに、アクセス権限と操作ログの保全も書いておきます。

部署や役職によって閲覧できる情報が異なる場合は、権限に応じた回答制御も明記します。

要件が曖昧なままだと、完成後に精度や情報制御への不満があっても、契約上の根拠をもって改善を求めることが難しくなります。そのため、測定できる基準が品質を支えます。

評価と検収(受け入れ判定)の基準も、発注時に合意しておきます。完成の水準をRFPで決めないと、納品時の評価が主観的になり、トラブルにつながります。

たとえば、代表的なFAQ100件に対する正答率を検収条件にできます。測定方法と判定基準をセットで定めておくと、認識のずれを防ぎ、円滑に検収できます。

ポイント

機能要件と非機能要件を分けて書き、精度は評価の水準で示します。曖昧なまま発注すると、完成後に改善を求める契約上の根拠を持てなくなります。

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

AI FAQシステムを中央に置き、データ利用、事故対応、監査・ログ、透明性の要件で囲んだ図
データの扱いから判断根拠の確認まで、複数の観点を組み合わせます。

AI FAQシステムは社内の機密情報を扱うため、セキュリティとガバナンスの要件を要件定義書に明記します。

明記する際に参考になるのが、デジタル庁の調達向けチェックシートです。

官公庁向けの評価項目は、民間企業のRFPにも応用でき、見落としやすいリスクを押さえられます。

民間RFPに転用する調達チェックシートの観点

デジタル庁の調達チェックシートには、AIガバナンス、インシデント対応体制、透明性の観点があります。加えて、プロンプトの隠蔽を避ける運用の観点もあります(出典:デジタル庁)。

これらは、AIを安全かつ責任をもって運用できるかを問う観点です。

民間のAI FAQシステムの発注にも当てはまるため、RFPには次の要件を盛り込みます。

  • データ利用:社内データがAI学習に使われない契約・設定になっているか。
  • 事故対応:インシデント対応体制と連絡フローが整っているか。
  • 監査・ログ:回答の監査やログ保全の仕組みを備えているか。
  • 透明性:プロンプトや判断根拠を確認できるか。

要件定義書に明記しておくと、安全性を軽く見るベンダーを選定の段階で見極めやすくなります。公的な調達の観点を転用することは、リスクの高い発注を避ける方法です。

生成AIの技術は進歩が速く、安全性の論点も更新されます。公的機関の調達観点を土台にすれば、自社の知見が乏しくても要件の漏れを減らせます。

要件定義には専門知識が要りますが、公開された枠組みを使えば一定の品質を担保できます。社内に知見がない場合ほど、信頼できる枠組みを活用する意味は大きくなります。

権限制御とデータ保護の要件

社内FAQには、人事規程や経理マニュアルなど、部署や役職で閲覧可否が分かれる情報が含まれます。

  • 参照データ制御:閲覧権限に応じたアクセス制御を、RFPに盛り込みます。
  • 入力とデータ保護:不正入力の検知・遮断と、参照データの改ざん検知を定めます。
  • 費用との調整:セキュリティ要件は機能要件や費用とトレードオフになる場合があります。厳格な制御や監査機能を求めると、工数と費用が増えます。
  • 必要な水準:すべてに最高水準を求めず、機密度の高い情報を扱う部分に重点対策を講じると、費用と安全性を両立できます。

利用者の権限に応じて回答を出し分ける仕組みを要件に明記しないと、本来見せるべきでない情報が回答されるリスクがあります。

発注時にこの要件を示しておくと、ベンダーは設計段階から対策を組み込めます。

セキュリティ対策を後から付け足すと費用と工数が膨らむため、要件定義の段階で安全性を織り込むことが、コストを抑える方法になります。

ポイント

社内機密を扱うため、セキュリティ要件は公的な調達チェックシートの観点を土台に、選定の段階で見極めます。後から足すと費用と工数が膨らむので、発注時に示しておきます。

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

データ準備、改善体制、データ整備支援、費用を確認項目として並べ、データ準備には全体工数の40〜60%を示した図
工数の大きいデータ準備と、導入後の支援内容を一緒に確認できます。

AI FAQシステムの精度は、元データの整備と工数配分に左右されます。そのため、RFPと要件定義書にはデータ準備に充てる工数を示し、発注者とベンダーの担当範囲を分けます。

工数配分とベンダー評価の観点を、続けて見ていきます。

要件で明示するデータ準備の工数配分

RAGを用いる導入は、一般に次の段階を踏んで進みます。

なかでもデータ準備には全体工数の40〜60%を割くべきとされ、精度を決定づけます。そのため、RAG導入の各工程に配分する工数を、要件定義書に工程ごとに示しておきます。

  • データ準備
  • チャンキング設計
  • 検索方式の選定
  • 生成の制御
  • 評価

要件定義書には、対象FAQの元データをどこまで整備するかと、その作業の責任分担を明記します。曖昧なまま発注すると整備が不十分になり、回答精度が伸びないおそれがあります。

元データには規程、業務マニュアル、過去の問い合わせ履歴など、形式や品質が異なる文書が含まれます。そのため、検索しやすい形に整える前処理が欠かせません。前処理は地道ですが、AI FAQシステムの精度に大きな差が出ます。

RFPでは、データ整備の工数を見積もりに記し、作業の責任を契約上はっきりさせます。責任の押し付け合いを防ぎ、必要な工数を確保することが、成果につながります。

ベンダー選定で評価すべき基準

AI FAQシステムは構築後も運用しながら精度を高めていくため、選定では導入後の支援内容も確認します。

  • 改善体制:改善サイクルを回せる体制かどうかを重視します。
  • データ整備支援:支援の有無も、評価の軸の一つです。
  • 費用:安さだけでベンダーを決めず、支援内容も踏まえて評価します。

回答できなかった問い合わせを集め、元データや調整に反映する仕組みを持つか、その運用を継続して支援できるかを確認します。

RFPでは、改善の方法と定期レビューの体制を提案してもらいます。

データ準備は精度を左右する工程なので、発注者だけに任せきりにするベンダーでは、十分な精度に届かないことがあります。

発注者は、元データを洗い出す作業や前処理を共に進める体制と、データ整備のノウハウを提案の段階で確認します。

比較を客観的に行うには、各社に同じ前提と評価項目を提示します。費用やスコープ、精度目標に加えて、改善体制とデータ整備支援も揃えて提案を求めます。

要件定義書とRFPに評価観点を含めると、感覚ではなく根拠に基づいて各社を選べます。

ポイント

精度は元データの整備と工数配分に左右されるため、ベンダーには同じ前提と評価項目を示します。そのうえで、改善体制とデータ整備支援を含めて提案を求めます。

まとめ

ここまで、AI FAQシステムのRFP・要件定義書・提案依頼書について見てきました。

費用相場と隠れコスト、機能・非機能要件を扱いました。さらに、デジタル庁調達チェックシートを転用したセキュリティ・ガバナンス要件、データ準備の工数配分とベンダー評価も解説しました。

PoCは50万〜200万円、中規模構築は1,500万〜4,000万円が相場です。保守費は初期費用の15〜25%を目安とし、API従量課金なども要件定義で考慮します。

対象FAQと元データを棚卸しし、測定できる精度目標を定めます。そのうえで、データ準備に工数の40〜60%を割く前提で、スコープを設計します。

改善体制とデータ整備支援を軸にベンダーを評価すると、発注後のトラブルを減らせます。RFPは、要望を伝えるとともに、自社の要求水準を一覧にして各社を同じ条件で比べるための設計図です。

要件定義書に必要事項を盛り込み、納得できるベンダー選定とAI FAQシステムの導入につなげます。RFPに時間をかけることが、プロジェクト全体の成否を左右します。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。