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