ボイスボット（電話自動応答AI）の導入をベンダーに依頼するとき、成否を分けるのが要件定義とRFP（提案依頼書）の質です。「電話対応を自動化したい」という漠然とした依頼だけでは、ベンダーごとに想定する範囲も見積もりもバラバラになり、比較ができません。さらに、要件があいまいなまま開発を進めると、稼働後に「想定した精度が出ない」「連携できると思った基幹システムにつながらない」といった手戻りが発生し、追加開発費がかさみます。だからこそ、何を・どこまで・どの水準で実現するのかを、発注側が明確に言語化したRFPが不可欠です。
本記事は、ボイスボットのRFP・要件定義書・提案依頼書をどう作るかを、発注企業の視点から体系的に整理する「要件定義特化」の解説です。稼働率99.9%・応答3秒以内・回答率目標といったSLA数値要件、トークン課金を前提としたコスト要件、ハルシネーション対策やセキュリティの要件、そしてベンダーの責任範囲の明確化まで、一次データの数値とあわせて具体的に解説します。RFPの精度が上がれば、ベンダー比較が公平になり、見積もりの妥当性も判断できます。なお、ボイスボット導入の全体像をまだ把握していない方は、まずボイスボットの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ボイスボットの完全ガイド
稼働率・応答速度・回答率のSLA要件
ボイスボットのRFPで最も具体的に書くべきなのが、サービスレベルに関する数値要件（SLA）です。電話窓口は顧客接点の最前線であり、つながらない・遅い・答えられないという状態は、そのまま顧客満足の低下と機会損失に直結します。あいまいな「使いやすく」「速く」では評価できないため、稼働率・応答速度・回答率といった指標を数値で定義することが、RFPの骨格になります。
稼働率99.9%と応答3秒以内の要件設定
稼働率は、ボイスボットがどれだけ安定して動き続けるかを示す基本指標です。一次データでは、稼働率99.9%以上が選定基準として一般的であり、神戸市の調達事例でも年間稼働率99.9%が目標として掲げられています。99.9%という水準は、年間のダウンタイムが約8.8時間に相当します。電話窓口が止まることは受電不能を意味するため、稼働率はベンダーに保証を求めるべき重要なSLA項目です。RFPには、目標稼働率だけでなく、未達の場合のペナルティや報告義務まで明記しておくと、運用後のトラブルを避けられます。
応答速度も、顧客満足を左右する重要なSLAです。神戸市の事例では「応答3秒以内、繋ぎ言葉があれば5秒以内」という要件が示されています。生成AIで回答を生成する構成では、回答生成に時間がかかる場合があるため、無音で待たせない繋ぎ言葉の設計まで含めて要件化することが現実的です。RFPでは、平均応答時間だけでなく、ピーク時の応答時間や、同時に何回線まで対応できるかという同時接続数も定義しておくべきです。入電が集中する時間帯に処理能力が不足すると、せっかくのボイスボットが機能しないため、自社の入電のピーク特性を踏まえた要件設定が欠かせません。
段階的な回答率目標の定義
回答率（自動化率）は、ボイスボットが有人につながず自力で完結できた割合を示す、成果に直結する指標です。ここで重要なのは、最初から高い回答率を要求するのではなく、段階的な目標を設定することです。神戸市の調達事例では、回答率を導入月50%、2ヶ月後60%、最終的に70%以上へと段階的に引き上げる目標が示されています。ボイスボットは運用しながらチューニングして精度を高めていくものであり、初月から70%を求めるような非現実的な要件は、かえってプロジェクトを破綻させます。
同じ神戸市の事例では、年間7.5万件の受電のうち、流入率70%・解決率60%を想定すると約2.5万件をボイスボットが対応する、という試算が示されています。このように、自社の受電件数に回答率目標を掛け合わせ、「何件を自動化できるか」を具体的に見積もることが、RFPの説得力を高めます。回答率の要件は、測定方法もあわせて定義することが大切です。何をもって「回答できた」とカウントするのか、ベンダーと認識をそろえておかないと、稼働後に成果の評価でもめる原因になります。段階目標・測定方法・改善計画をセットで要件化することが、現実的なRFPの条件です。
トークン課金を前提としたコスト要件
生成AIを使うボイスボットでは、従来のシステムにはなかった「トークン課金」という変動費の概念をRFPに織り込む必要があります。利用量に応じてコストが膨らむため、初期費用だけでなく、入電量を前提としたランニングコストの試算と上限管理を要件に含めることが、予算超過を防ぐ鍵になります。コスト要件をあいまいにすると、稼働後に想定外の請求に直面しかねません。
入電量とモデル選定によるコスト試算
生成AI型ボイスボットのコストは、利用するLLMのモデルによって大きく変わります。一次データの試算では、月10万リクエスト（入出力各500トークン）で、Gemini 2.0 Flashなら約3,750円、GPT-4o miniなら約5,600円であるのに対し、Claude Sonnet 4では約135,000円と、モデル次第で数十倍の差が出ます。RFPでは、どのモデルを前提とするか、あるいはモデルを切り替えられる柔軟性があるかを要件として確認すべきです。高精度なモデルが必ずしも費用対効果に優れるとは限らないため、業務に必要な精度とコストのバランスを要件で定義することが重要です。
ボイスボットの相場感も、RFPの予算設定の参考になります。一次データでは、従量課金型が1応答あたり約50〜200円、固定型が月額1万〜35万円、オンプレ型は初期数百万〜2,000万円以上とされています。大規模受電（月2万通話）では、初期200万〜400万円・月額80万〜150万円が目安です。riplaのようなフルスクラッチ受託の外注相場では、小規模300万〜600万円、中規模600万〜1,500万円、大規模1,500万〜5,000万円以上が一つの目安となります。RFPには、自社の入電量を明示し、その量を前提とした月額ランニングコストの試算をベンダーに求めることで、見積もりの比較が可能になります。
連携API費など隠れコストの要件化
RFPで見落とされがちなのが、初期費用や月額費用に含まれない「隠れコスト」です。代表的なのが、CRMやCTI、予約システムといった外部システムとの連携API開発費で、一次データでは1件あたり30万〜100万円程度かかるとされています。連携先が複数あれば、その分だけ初期費用が積み上がります。RFPには、どのシステムと連携するかを明記し、各連携の開発費を内訳として提示するようベンダーに求めることが、後の予算超過を防ぎます。
このほか、シナリオ設計やチューニングの費用、運用に必要な人的リソースも要件として明確にしておくべきです。一次データでは、運用には最低でも月5〜10時間程度のリソースが必要とされています。これを社内で賄うのか、ベンダーに運用代行を依頼するのかで、トータルコストは変わります。さらに、トークン課金を月5万円と見込んでいたものが20万円超に膨らんだという失敗事例も報告されており、利用量が想定を超えた場合のコスト上限やアラートの仕組みを要件に含めることが賢明です。初期・月額・連携・運用・変動費という五つの観点でコストを要件化すれば、見積もりの抜け漏れを防げます。
ハルシネーション対策とセキュリティ要件
生成AIを使うボイスボットでは、従来のシステムにはなかった品質・安全面の要件が加わります。とりわけ、事実と異なる回答を生成するハルシネーションへの対策と、個人情報を扱う電話窓口としてのセキュリティは、RFPで明確に定義しておかないと、稼働後に重大なトラブルを招きます。これらは技術要件であると同時に、企業のリスク管理に直結する要件です。
正答率保証とハルシネーション対策の要件
生成AIが誤った情報を自信ありげに回答するハルシネーションは、顧客に誤案内をしてしまう深刻なリスクです。RFPでは、ハルシネーションをどう抑制するかの要件を明記すべきです。具体的には、RAG（検索拡張生成）で社内の正確な情報源に基づいて回答させる仕組み、回答の信頼度が低い場合は推測で答えずに有人へ切り替える制御、そして禁止すべき回答領域の定義などが要件になります。一次データでは、KARAKURIが正答率95%を保証するプランを提供しており、こうした正答率の保証をベンダーに求められるかも、RFPで確認すべきポイントです。
ハルシネーション対策を要件化するには、RAGが参照するデータの整備責任を誰が負うかも明確にする必要があります。RAGの回答品質は、参照するFAQやマニュアルの構造や鮮度に大きく依存するため、データのフォーマット整理やメンテナンスを発注側とベンダーのどちらが担うかを決めておかないと、稼働後に精度が伸びない原因になります。riplaはフルスクラッチ受託と国内開発の立場から、RAG用データの設計とプロンプトのチューニングを含めて要件を整理することを重視しています。ハルシネーション対策は、技術だけでなく運用体制まで含めた要件として捉えることが大切です。
個人情報の外部送信と情報管理の要件
ボイスボットは、顧客の氏名・住所・電話番号・契約内容といった個人情報を音声でやり取りする窓口です。生成AIを使う場合、これらの情報が外部のLLMサービスへ送信される可能性があり、その取り扱いをRFPで厳密に定義する必要があります。送信されるデータが学習に利用されないか、どこのリージョンで処理されるか、通話の録音や文字起こしデータをどう保管・破棄するかといった点を、セキュリティ要件として明記すべきです。一次データでは、情報漏えいが発生した場合の対応に500万円以上かかるケースもあるとされ、軽視できないリスクです。
セキュリティ要件には、アクセス制御、通信の暗号化、監査ログの保存といった一般的な項目に加え、ボイスボット特有の論点も含めます。たとえば、本人確認をどう行うか、機微な情報を扱う用件はAIで完結させず有人に回すか、といった運用ルールも要件の一部です。自社が個人情報保護法や業界のガイドラインで求められる水準を満たせるよう、ベンダーのセキュリティ体制や認証取得状況をRFPで確認することが欠かせません。SLA・コスト・品質・セキュリティという四つの柱で要件を固めることが、安心して任せられるボイスボット調達の前提になります。
責任範囲を明確にするRFPの作り方
SLA・コスト・品質・セキュリティの要件を固めたら、最後にそれらを公平に比較できるRFPの形にまとめます。RFPは、発注側の要望を一方的に並べる文書ではなく、ベンダーの責任範囲を明確にし、提案を同じ土俵で評価するための設計図です。ここの作り込みが甘いと、せっかくの要件も比較や評価に活かせません。
ベンダーの責任範囲と運用分担の明記
RFPで特に重要なのが、ベンダーがどこまでを責任を持って担うかを明確にすることです。シナリオ設計やRAGデータの整備は誰がやるのか、稼働後のチューニングはベンダーの運用代行か社内対応か、回答率目標を達成できなかった場合に誰がどう改善するのか。こうした責任分界を曖昧にしたまま契約すると、稼働後に「それは要件外です」「それは御社の作業範囲です」という押し付け合いが起きます。要件定義の不備による再開発には、一次データで100万〜500万円の追加費用がかかるとされており、責任範囲の明確化はコスト管理そのものでもあります。
運用分担を要件化する際は、導入後の改善サイクルを「誰が・どの頻度で・何を見て」回すのかまで踏み込むと効果的です。ボイスボットは導入時点ではなく運用開始後の改善で成果が決まるため、月次の回答率レビュー、シナリオ追加、認識辞書の更新といった作業を、誰が担当するかを契約に落とし込みます。riplaはフルスクラッチ受託と国内開発、運用伴走を組み合わせる立場から、開発だけでなく運用フェーズの責任分担まで含めて要件を整理することを重視しています。責任範囲が明確なRFPは、稼働後のトラブルを未然に防ぐ最大の保険です。
PoC・評価基準を盛り込んだRFP設計
ボイスボットは、実際の音声品質や認識精度を事前に見極めにくいため、本格契約の前にPoC（概念実証）を組み込むことが有効です。RFPに、自社の代表的な用件でAIがどこまで対応できるかを検証するPoCフェーズを設け、その結果をもって本契約の可否を判断する設計にすれば、いきなり大規模投資して稼働しないという事態を避けられます。PoCの評価項目（認識精度、回答率、応答速度、有人切替の滑らかさなど）を事前に定義しておくことが、客観的な判断につながります。
RFPには、提案を採点するための評価基準も明示します。価格だけで選ぶと、安かろう悪かろうのベンダーに当たるリスクがあるため、SLAの実現性、連携の技術力、運用支援の手厚さ、セキュリティ体制、実績といった項目に重み付けをして評価する仕組みを用意します。複数ベンダーから同じ要件で提案を取れば、各社の強みと弱みが浮かび上がり、自社に最適なパートナーを選びやすくなります。SLA数値・コスト構造・品質・セキュリティ・責任範囲・PoC・評価基準という要素を盛り込んだRFPこそ、ボイスボット導入を成功に導く設計図だと言えます。
まとめ
ボイスボットのRFP・要件定義書を作るうえで核になるのは、SLA・コスト・品質・セキュリティ・責任範囲という五つの柱を数値と分担で明確にすることです。稼働率99.9%、応答3秒以内、回答率を導入月50%から最終70%以上へ段階的に引き上げる目標といったSLA数値、モデルによって数十倍変わるトークン課金と連携API1件30万〜100万円という隠れコスト、正答率95%保証やハルシネーション対策、個人情報の外部送信管理。これらを一次データの数値とともに要件化することで、ベンダー比較が公平になり、見積もりの妥当性を判断できます。
要件定義で大切なのは、機能の網羅性以上に「責任範囲と運用分担を曖昧にしないこと」です。要件定義の不備による再開発には100万〜500万円の追加費用がかかるため、PoCで実力を検証し、評価基準で公平に選び、運用フェーズまで含めて責任を明確にすることが、失敗を避ける近道になります。riplaはフルスクラッチ受託と国内開発、運用伴走を組み合わせ、業務から逆算した要件整理とRFP作成を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。