AIチャットボットのRFP/要件定義書/提案依頼書について

AIチャットボットの発注では、RFP(提案依頼書)と要件定義書に、費用・利用条件・機能・品質・セキュリティの要件を順に定めておくと、見積もりを同じ条件で比べられます。

一方で、要件が曖昧だと、契約後の機能不足や運用費超過のトラブルが起きがちです。全体像はAIチャットボットの完全ガイドもご覧ください。

▼全体ガイドの記事
・AIチャットボットの完全ガイド

要件定義の前提となる費用相場と隠れコストの把握

AIチャットボットの開発フェーズ別に、小規模なPoC、中規模の本番構築、大規模な全社展開の費用目安を並べた図。
フェーズをそろえると、見積もりの前提を比べやすくなります。

RFPを作る前に費用相場を把握しておくと、受け取った見積もりが妥当かどうかを判断しやすくなります。反対に、相場を知らないまま発注すると、過剰な支払いや、安さだけで品質の低いベンダーを選ぶリスクがあります。

AIチャットボットの開発費は、規模やアプローチによって変わります。要件定義の段階で前提にしておきたいのは、費用相場と、見落としがちな隠れコストです。

フェーズ別の費用相場の目安

社内文書を参照するRAG型のAIチャットボットは、開発フェーズによって費用と期間が変わります。

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

RFPには目指すフェーズと到達目標を書いておきます。PoCで効果を確かめるのか、本番運用を見据えて構築するのかで、必要な予算とスコープが変わるからです。

フェーズが曖昧なままだと、ベンダーごとに想定するスコープがずれ、見積もりを比べられません。だからこそ、目指すフェーズを示すことが、適切な見積もりを得る第一歩になります。

実務では、まずPoCで精度が業務に耐えるかを確かめ、効果を数字で把握してから本番へ進む段階的な方法が推奨されます。大きな失敗を避けるためです。

RFPには、PoCの結果を見てから本番への移行可否を判断する進め方を書きます。さらに、各フェーズの費用を分けて見積もってもらうと、発注リスクを抑えられます。

RFPで明示すべき隠れコストの項目

AIチャットボットの予算管理では、初期開発費以外に発生する隠れコストにも目を向け、予算に含めて見積もる必要があります。

  • 運用保守費:初期開発費の15〜25%程度が一般的な目安です。
  • 生成AIのAPI利用料:利用量に応じた従量課金で、使うほど増えます。
  • ベクトルデータベース費用:データが増えるにつれて、スケーリングの費用がかかります。
  • インフラ増強費:利用者の増加に対応するための費用です。

保守費は年間を通じて継続的にかかります。そのため、要件定義の段階で見込んでおかないと、運用が始まってから予算超過となるおそれがあります。

RFPには、想定利用量における月額ランニングコストの試算を求めます。

初期費用だけで比べると、運用まで含めた総額で評価が逆転するケースもあります。したがって、総保有コスト(TCO)の観点から各社を評価します。

ポイント

見積もりを比べるときは、PoCか本番構築かというフェーズをそろえ、運用保守費や従量課金まで含めた総額で判断するとよいです。

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

機能要件の項目として、参照文書、質問対応、有人対応、外部連携を4枚のカードに並べた図。
対象範囲を項目ごとに整理すると、見積もりの前提がそろいます。

要件定義書では、機能要件と非機能要件の両面を定めておく必要があります。機能要件は「何ができるか」を、非機能要件は「品質・性能・安全性をどの水準で実現するか」を表します。

AIチャットボットでは、精度や応答速度などの非機能要件が見落とされがちです。要件定義書に書く項目は、機能と非機能に分けて考えると整理が進みます。

機能要件の定義の仕方

機能要件では、AIチャットボットに任せる内容と範囲をはっきりさせます。その際は、次の4つの項目を具体的に整理します。

  • 参照文書:対象の種類・量と、PDF・Excel・社内Wikiなどの形式
  • 質問対応:チャットボットが回答する質問の範囲
  • 有人対応:担当者への引き継ぎが必要かどうか
  • 外部連携:他システムとつなぐ必要があるもの

参照文書の一覧と形式を要件定義書に書いておくと、ベンダーは工数を見積もりやすくなります。特に、手書きのスキャンや複雑な表が混ざっている場合は、明記しないと後から工数が膨らむ原因になります。

業務の自動化が目的であれば、AIに任せるタスクの範囲も定めておく必要があります。質問への回答だけにとどめるのか、社内システムを操作してタスクを完了させるのかで、難易度と費用が変わります。

欲しい機能を書き出して優先度を付け、「必須」と「あれば望ましい」に分けておきます。そうすると、予算に応じてスコープを調整できます。

機能要件を整理する際には、RAG導入の成功フレームワークも参考になります。このフレームワークは、データ準備から始まり、チャンキング設計と検索方式の選定、生成の制御を経て、評価で締めくくる5ステップです。

データ準備は、プロジェクト全体の工数の40〜60%を占めるとも言われる重要な工程です。軽く見ると精度不足につながるため、各ステップの作業範囲を文書にして明確にしておきます。

精度・性能などの非機能要件

非機能要件では、回答精度の評価基準を定めることが特に重要です。「精度が高いこと」のような曖昧な表現では判断できないため、評価方法と達成水準を具体的に決めておきます。精度評価には、次の指標があります。

  • Context Precision(検索精度):検索した文書の的確さを測る指標
  • Faithfulness(忠実性):回答が文書の内容に忠実かどうか

どの水準で評価するかを決めたうえで、RagasやDeepEvalなどの評価フレームワークをRFPに盛り込めば、発注の時点から精度を客観的に検証できます。また、精度を数値で評価できる体制があるかどうかは、ベンダーの技術力を見極める材料にもなります。

性能面でも、応答速度、同時アクセス数への耐性、可用性などの要件を定めます。利用者が多い顧客向けのチャットボットでは、応答時間の許容範囲を示します。

基準が曖昧なままだと、完成後に精度や速度に不満があっても、契約上の根拠をもって改善を求められません。そのため、測定できる基準を決めておくことで、品質を担保できます。

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

たとえば、代表的な質問100件に対して正答率が一定以上であることを、検収の条件にできます。測定方法と判定基準をあわせて定めると、発注側と開発会社の双方の認識がそろい、円滑に検収を進められます。

ポイント

発注時に機能の範囲だけでなく、精度・性能の測定方法と達成水準まで書いておくと、完成後の評価で食い違いが起きにくくなります。

セキュリティ・ガバナンス要件の盛り込み方

社内の機密情報を中央に置き、アクセス制御、不正入力の検知、改ざん検知で囲んだセキュリティ要件の図。
参照データへの対策を組み合わせて、情報を守る構成です。

AIチャットボットは社内の機密情報を扱うため、セキュリティとガバナンスの要件をはっきり定めておく必要があります。官公庁向けの評価項目は、民間企業のRFPにも応用でき、見落としがちなリスクを幅広く押さえられます。

デジタル庁の調達観点の民間RFPへの転用

デジタル庁の調達チェックシートは、次のような観点を示しています(出典:デジタル庁)。

  • AIガバナンス:構築や運用の体制
  • インシデント対応:発生時の対応体制
  • システムの透明性:仕組みや判断過程の明確さ

行政向けの項目ではありますが、AIを安全かつ責任をもって運用できるかを問うものなので、民間企業の発注にも当てはまります。そのため、RFPには社内データをAIの学習に使わないための契約や設定、インシデント時の対応体制と連絡フロー、回答の監査やログの保全を盛り込みます。

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

生成AIは技術の進歩が速く、安全性の論点も日々更新されています。だからこそ、公的機関の調達観点を手がかりにすると、自社にノウハウが乏しい場合でも、要件の抜け漏れを減らせます。

要件定義には専門知識が必要ですが、公開された枠組みを使えば、発注側でも一定の品質を担保したRFPを作れます。社内に知見がないときは、信頼できる枠組みを参考にします。

情報漏洩・データ汚染への対策要件

データの取り扱いに加えて、AI特有の攻撃への対策も定めておく必要があります。BadRAGに関する研究では、検索対象データのわずか0.04%を汚染すると、悪意ある文書の検索成功率が98.2%に達するという結果も示されています。

社内文書を参照するAIチャットボットでは、参照データの改ざんや混入が深刻なリスクになります。そこで、RFPには次の対策要件を盛り込みます。

  • アクセス制御:参照データを使える範囲の絞り込み
  • 不正入力の検知:不正な入力の見極めと遮断
  • 改ざん検知:参照データが書き換えられていないかの確認

発注の時点で対策を示しておけば、ベンダーは設計の段階からセキュリティを考慮できます。後から対策を加えるとコストと工数が膨らむため、要件定義の段階で安全性を織り込んでおくことが大切です。

セキュリティ要件は、機能要件や費用とトレードオフになることがあります。たとえば、厳格なアクセス制御や監査機能を求めるほど、開発工数と費用が増えます。

扱うデータの機密度に応じて、必要なセキュリティ水準を決めます。機密度の高い情報を重点的に守る設計は、最高水準を一律に求めるよりも、費用と安全性を両立させる現実的な方法です。

ポイント

判断に迷うときは、扱うデータの機密度を見て守る範囲を決めます。機密度の高い情報から重点的に守ると、費用と安全性の両立を図りやすくなります。

まとめ

AIチャットボットのRFPでは、費用相場と隠れコスト、機能・非機能要件、セキュリティ・ガバナンスを順に整理しておくことが大切です。相場の目安は、PoCが50万〜200万円、中規模構築が1,500万〜4,000万円です。

運用保守費(初期費用の15〜25%)やAPIの従量課金も、要件定義の段階で予算に含めておきます。また、精度の評価基準を測定可能にし、デジタル庁の調達観点を使ってセキュリティ要件を整えると、発注後のトラブルを減らせます。

RFPは、自社の要求水準をはっきり示し、各社を同じ条件で比べるための文書です。ここに時間をかけることが、プロジェクト全体の成否を左右します。要件定義書に必要な事項を盛り込み、納得できるベンダー選定につなげてください。

会社紹介

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

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

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

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

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

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