チャットボットの開発・導入をベンダーに依頼するとき、成否を最初に分けるのが「RFP（提案依頼書）と要件定義をどれだけ精緻に書けるか」です。要件があいまいなままベンダーに丸投げすると、提案各社の見積もり前提がバラバラになって比較できず、契約後には「想定していた回答精度が出ない」「必要な連携が別料金だった」といった食い違いが噴出します。とくに生成AIを使うチャットボットは、トークン課金や回答精度の保証といった、従来のシステムにはなかった要件を盛り込む必要があり、RFPの難易度が上がっています。
本記事は、チャットボットのRFP・要件定義書・提案依頼書の書き方を、発注企業の視点から実務的に整理する「要件定義特化」の解説です。SLA（稼働率・応答時間・回答率）などの非機能要件、生成AI特有のコスト要件とハルシネーション対策要件、機能要件と連携要件の固め方、そしてベンダーの責任範囲を明確にする契約上の論点まで、一次データの数値とあわせて具体的に解説します。チャットボットの全体像をまだ把握していない方は、まずチャットボットの完全ガイドを読んでから本記事に進むと、各要件の背景が理解しやすくなります。読み終えるころには、自社のRFPに盛り込むべき項目の骨格が描けるはずです。
▼全体ガイドの記事
・チャットボットの完全ガイド
SLA（稼働率・応答時間・回答率）の非機能要件
RFPでもっとも見落とされがちでありながら、運用品質を左右するのがSLA（サービス品質保証）に関する非機能要件です。機能だけを並べたRFPでは、提案各社が「どの品質水準で作るか」を自由に解釈してしまい、見積もりに大きな差が出ます。稼働率・応答時間・回答率という3つの軸を数値で示すことが、要件定義の出発点です。
稼働率99.9%・応答3秒以内などの数値要件
稼働率は、チャットボットがどれだけ安定して動き続けるかを示す指標です。公共調達の事例では、年間稼働率99.9%以上を選定基準とするケースがあり、これは民間でも一つの目安になります。99.9%は年間の停止時間に換算すると約8.8時間に相当します。24時間対応を売りにするチャットボットが頻繁に止まれば、その価値は損なわれるため、RFPでは許容停止時間や障害時の復旧目標時間まで明記すると、提案の品質が揃います。
応答時間も具体的な数値で要件化すべき項目です。神戸市の調達要件では、応答3秒以内（つなぎ言葉などの工夫があれば5秒以内）といった水準が示されています。ユーザーは数秒の遅延でも離脱しやすいため、生成AI型でLLMの推論に時間がかかる場合は、回答生成中に待機メッセージを出すといった体験設計まで要件に含めるとよいでしょう。稼働率と応答時間は、ユーザー体験に直結する非機能要件として、RFPの冒頭で数値とともに明示してください。
回答率の段階的な目標設定の要件
チャットボット特有の重要要件が「回答率」です。これは、ユーザーの質問に対して適切に回答できた割合を示し、チャットボットの実効性を測る核心的な指標になります。ここで現実的なのは、回答率を導入直後から高く求めるのではなく、運用しながら育てる前提で段階的に目標設定することです。神戸市の調達では、回答率を導入月50%→2ヶ月後60%→最終的に70%以上、という段階目標が示されています。
この段階目標の考え方は、RFPに盛り込む価値があります。なぜなら、回答率は導入時のFAQやシナリオの完成度だけでなく、運用での改善によって高まるからです。同調達では、年間約7.5万件の受電のうち、チャットへの流入を70%、その解決率を60%と想定し、結果として約2.5万件をチャットで対応する、という具体的な前提も置かれています。RFPでこうした想定件数と回答率目標をセットで示すと、ベンダーは必要なリソースを正しく見積もれ、提案の精度が上がります。回答率は「育てる指標」として、改善計画まで含めて要件化することが肝心です。
生成AI特有のコスト要件とハルシネーション対策要件
生成AI（LLM・RAG）を使うチャットボットには、従来のシステムにはなかった独自の要件があります。トークン課金というランニングコストの構造と、誤った回答（ハルシネーション）への対策です。これらをRFPに明記しないと、運用開始後にコストが暴騰したり、誤回答でトラブルになったりするリスクが高まります。
トークン課金を前提としたコスト要件の明記
生成AI型のRFPで必ず盛り込みたいのが、LLMのトークン課金を前提としたコスト要件です。トークン課金は利用量に応じて増減するため、想定する月間リクエスト数とモデルを明示しないと、ベンダーは月額コストを試算できません。試算では、月10万リクエスト（入出力各500トークン程度）の場合、Gemini 2.0 Flashなら約3,750円、GPT-4o miniなら約5,600円、Claude Sonnet 4なら約135,000円と、モデルによって桁が変わります。
この差を踏まえ、RFPには「想定リクエスト数」「許容する月額トークン上限」「上限を超えそうな場合の通知・抑制の仕組み」を要件として書くべきです。実際、トークン課金を月5万円と見込んでいたのに20万円を超えてしまった、という事例も報告されています。こうした暴騰を防ぐには、利用量のモニタリング機能や、上限アラート、用途に応じたモデル使い分けの提案を求める要件を入れておくことが有効です。生成AI型は初期費用だけでなく、変動するランニングコストを要件で制御することが、予算管理の要になります。
ハルシネーション対策・RAGデータ整備の要件
生成AIは、もっともらしい誤回答（ハルシネーション）を生成するリスクを構造的に抱えています。チャットボットが誤った案内をすれば、ユーザーの不利益や企業の信頼失墜に直結するため、ハルシネーション対策をRFPの要件として明記することが欠かせません。具体的には、回答の根拠となるRAGデータの範囲を限定する、参照元を回答に明示する、自信のない質問は「分かりません」と返して有人へ引き継ぐ、といった対策の実装を求めます。
あわせて、RAGの精度を支えるデータ整備の要件も重要です。生成AIの回答精度は、参照元データの構造や整理状況に大きく依存します。FAQやマニュアルを誤回答が出にくい形に整形・分割する作業をベンダーの責任範囲に含めるのか、自社で行うのかを要件で明確にしておかないと、後で「精度が出ないのは誰の責任か」という論争になります。製品によっては正答率95%保証プランもあるため、求める精度水準を数値で示し、それを担保するためのデータ整備とチューニングの分担を要件化することが、生成AI型のRFPの肝になります。
機能要件・連携要件の固め方
SLAやコストといった非機能要件と並んで、RFPの骨格をなすのが機能要件と連携要件です。どんな会話ができ、どのシステムとつながり、どこまでを自動化するのか。ここを具体的に固めるほど、提案各社の見積もり前提が揃い、比較が正確になります。
回答方式・有人切替などの機能要件
機能要件では、まず回答エンジンの方式（シナリオ型・AI型・生成AI型のどれを求めるか、あるいは併用か）を定義します。次に、有人切替の条件と仕様、対応チャネル（Web、LINE、社内ツール等）、多言語対応の要否、管理画面でのFAQ・シナリオ編集の権限設計などを具体的に列挙します。ここで意識したいのは、機能を「必須」「推奨」「任意」のように優先度づけして示すことです。優先度が明確だと、ベンダーは予算内で最適な提案を組み立てやすくなります。
機能要件を固める前段として、現状業務のヒアリングを丁寧に行うことが、実は最重要です。要件定義の不備は、後から仕様変更・再開発として跳ね返り、100万〜500万円の追加費用につながる事例も報告されています。「現場が実際にどんな質問を受け、何に困っているか」を起点に機能を定義しないと、完成しても使われないシステムになりかねません。AsIs（現状）の課題からToBe（あるべき姿）を描き、その実現に必要な機能を要件化する。この順序を守ることが、手戻りを防ぐ最大のポイントです。
CRM・CTI連携の連携要件と費用前提
連携要件は、RFPで特に丁寧に書くべき領域です。チャットボットをCRM、CTI、予約システム、基幹システムと連携させる場合、それぞれの接続方式や認証、データのやり取りの仕様を要件化します。連携先のシステム名やバージョン、APIの有無を明記しないと、ベンダーは連携工数を見積もれず、提案後に「想定外の追加開発が必要」となりがちです。
費用面でも、連携は要注意です。連携API開発費は1件あたり30万〜100万円が目安で、複数システムと連携すれば積み上がります。RFPでは、連携対象を一覧化し、それぞれを「必須連携」と「将来的に検討」に分けて示すと、初期スコープと拡張余地が明確になります。また、連携データの個人情報を含む場合は、その取り扱いと外部送信の可否もセキュリティ要件として併記します。連携要件をあいまいにしたまま契約すると、隠れコストの温床になるため、対象・方式・費用前提をセットで固めることが大切です。
ベンダーの責任範囲と運用・保守の要件
RFPの最後の山場が、ベンダーの責任範囲と運用・保守の要件です。とくにチャットボットは、導入して終わりではなく、運用しながら精度を育てるツールであるため、開発後の役割分担を契約段階で明確にしておかないと、後々のトラブルや形骸化を招きます。
運用リソースと改善の役割分担の要件
チャットボットは、設置後も最低で月5〜10時間の運用リソース（回答ログの確認、FAQの追加・修正、シナリオの改善）が必要とされます。RFPでは、この運用作業を「ベンダーが代行するのか」「自社が担うのか」「共同で行うのか」を明確に要件化します。前述の回答率の段階目標（導入月50%→最終70%以上）を達成するには継続的な改善が前提となるため、その改善PDCAを誰が回すかを契約に落とし込む必要があります。
この役割分担を曖昧にすると、運用リソースの確保ができず、回答精度が下がってチャットボットが形骸化する、という典型的な失敗に陥ります。要件では、月次のレポート提供、定期的なチューニング、FAQ更新の対応範囲と回数、問い合わせ対応のSLAなどを具体的に定義します。riplaはフルスクラッチ受託と運用伴走の立場から、開発後の改善まで含めた役割分担をRFP段階から一緒に設計することを重視しています。運用を見越した要件定義こそ、定着するチャットボットの条件です。
データ所有権・移行可能性の要件
意外と見落とされるのが、データの所有権とベンダーロックインに関する要件です。チャットボットの運用で蓄積される会話ログ、育てたFAQ・シナリオ、RAG用に整備したデータは、自社にとって貴重な資産です。RFPでこれらの所有権が自社にあることを明記し、将来別のベンダーへ乗り換える際にデータをエクスポートできる仕様を要件化しておかないと、ロックインによってデータ移行ができず、乗り換えが事実上不可能になるリスクがあります。
あわせて、セキュリティ要件として、個人情報の取り扱い、入力データがAIの学習に使われないことの保証、情報漏えい時の責任範囲も契約レベルで定義します。情報漏えいの対応コストは500万円以上に及ぶこともあり、責任の所在を曖昧にしたまま契約すると、有事に大きな負担を抱えかねません。データの所有権・移行可能性・セキュリティ責任という3点を要件として固めることが、長期的に安心して運用できるチャットボット導入の土台になります。
提案の評価基準とPoC・検収条件の要件
RFPを出して提案を受けたあと、各社をどう比較するかも、あらかじめ要件として整理しておくべきです。価格だけで選ぶと、安いが品質が低い提案を掴みかねません。回答精度の保証水準、SLAの達成可能性、運用支援の手厚さ、データの取り扱い、過去の類似実績など、評価軸とその配点をRFPに明示しておくと、提案各社も自社の強みを的確にアピールでき、発注側も客観的に選定できます。
とくに生成AI型では、提案段階での机上の精度説明だけでは実力が分かりにくいため、PoC（概念実証）の実施を要件に含めることが有効です。自社の実際のFAQやドキュメントを使って小規模に試し、回答精度やハルシネーションの発生状況を検証してから本契約に進めば、「導入したが精度が出なかった」という失敗を未然に防げます。あわせて、検収条件、すなわち「何をもって完成・合格とするか」を回答率などの数値で定義しておくことも重要です。検収基準が曖昧だと、品質に不満があっても受け入れざるを得ず、トラブルの火種になります。評価基準・PoC・検収条件を要件として固めることが、提案選定から納品までを公正に進める土台になります。
RFP本体に盛り込む構成項目の整理
最後に、ここまでの要件を実際のRFP（提案依頼書）としてまとめる際の構成項目を整理しておきます。一般的なRFPには、(1)プロジェクトの背景と目的（なぜチャットボットを導入するのか）、(2)現状の課題（問い合わせ件数や対応体制のAsIs）、(3)導入で実現したい姿（ToBe）、(4)機能要件と非機能要件（SLA・コスト・連携）、(5)運用・保守の要件、(6)スケジュールと予算感、(7)提案の評価基準と提出様式、といった項目を盛り込みます。
このうち、発注側がもっとも力を入れるべきは、背景・目的と現状課題の記述です。なぜなら、ベンダーはこの部分を読んで「発注側が本当に解決したいことは何か」を理解し、それに沿った提案を組み立てるからです。機能の羅列だけのRFPでは、各社が表面的な機能比較の提案しか出せませんが、課題と狙いが明確に書かれていれば、ベンダーは課題解決という観点から最適な手段を提案できます。RFPは「作ってほしいものの仕様書」であると同時に「解決したい課題の共有資料」でもあります。riplaはフルスクラッチ受託の立場から、このRFP作成そのものの段階から、現状業務の整理と要件の言語化を支援しています。良いRFPは、良い提案と、ひいては成功する導入を引き寄せる出発点なのです。
まとめ
チャットボットのRFP・要件定義では、(1)稼働率99.9%・応答3秒以内・回答率の段階目標（50%→60%→70%以上）といったSLAの非機能要件、(2)トークン課金を前提としたコスト要件とハルシネーション対策・RAGデータ整備の要件、(3)回答方式・有人切替・CRM/CTI連携（API1件30万〜100万円）といった機能・連携要件、(4)運用リソースの役割分担とデータ所有権・移行可能性・セキュリティ責任、という4つの柱を数値とともに固めることが重要です。要件の不備は100万〜500万円の追加開発につながるため、現状業務のヒアリングからToBeを描き、優先度づけして要件化することが手戻りを防ぎます。
RFPを書くときに大切なのは、機能を並べることよりも、品質水準・コスト構造・責任範囲を数値と分担で明確にすることです。とりわけ生成AI型では、トークンコストとハルシネーション対策という新しい論点を要件に組み込めるかが成否を分けます。riplaはフルスクラッチ受託と運用伴走の立場から、現状業務の整理、SLA・コスト・連携の要件化、開発後の運用設計までを一貫して支援します。各要件の背景をあらためて確認したい場合は、完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。