IVR（自動音声応答）の開発をベンダーに依頼するとき、成否を分けるのが要件定義とRFP（提案依頼書）の質です。「電話の一次対応を自動化したい」という漠然とした要望のまま見積りを取ると、ベンダーごとに前提がばらばらで提案を比較できず、契約後に「思っていたものと違う」という認識のずれが噴出します。とくにIVRは、稼働率や応答速度、回答率といった数値で品質を縛るべき要素が多く、これらをRFPに明記できているかどうかが、プロジェクトの安定性を大きく左右します。
本記事は、IVR導入の要件定義書とRFPに何を盛り込むべきかを、発注企業の視点から体系的に整理する「要件定義特化」の解説です。現状の電話業務の可視化から、稼働率99.9%・応答3秒といった非機能要件の数値化、トークン課金を前提としたコスト要件、ハルシネーション対策の要件、そしてRFPの必須項目と見積り評価軸まで、一次データとあわせて解説します。なお、IVR導入の全体像をまだ把握していない方は、まずIVRの完全ガイドから読むことをおすすめします。要件を固める力こそ、発注側がベンダーと対等に向き合うための武器です。
▼全体ガイドの記事
・IVRの完全ガイド
現状の電話業務を可視化する要件定義
IVRの要件定義は、現状の電話業務を数値で可視化するところから始まります。月間の入電件数、時間帯別の集中度、用件の内訳、平均応答時間、放棄呼率といった現状（AsIs）の指標を把握しないまま要件を作ると、何をどれだけ自動化すべきかの目標が定まりません。可視化された現状こそが、要件定義の出発点であり、導入後の効果測定の基準にもなります。
入電量・用件内訳・放棄呼を数値化する
現状把握でまず行うのは、入電データの分析です。1日・1ヶ月あたりの入電件数、ピーク時間帯、用件ごとの割合を洗い出します。たとえば「問い合わせの6割は営業時間や在庫の定型確認」と分かれば、その6割を自動化のターゲットに設定できます。逆に、判断や交渉を伴う複雑な用件が大半なら、IVRで自動化できる範囲は限られるため、過度な期待を持たずに要件を組むべきだと判断できます。
放棄呼率も重要な指標です。応答前に切れてしまう電話がどれだけあるかを把握すれば、「待たせない」ことの効果がどれほど大きいかを定量化できます。自治体の事例では、年間7.5万件の受電のうち、自動応答への流入を70%、解決率を60%と想定し、約2.5万件をシステムで対応する設計が示されました。こうした想定値を要件定義で先に置くことで、導入後に達成度を評価でき、ベンダーとの責任範囲も明確になります。
コールフローとVUIシナリオを要件化する
現状を数値で把握したら、次にあるべき応対の流れ（コールフロー）を設計します。どの用件をどう振り分け、どこまでを自動応答で完結させ、どの条件で有人に切り替えるか。この一連の流れを、音声ユーザーインターフェース（VUI）のシナリオとして要件定義書に落とし込みます。メニューの選択肢は一度に3〜4個まで、よくある用件を先頭に、という設計原則を要件に織り込むことで、多階層メニューによる離脱を防げます。
VUIシナリオの要件化では、聞き返しや認識失敗時の挙動、オペレーターへのエスカレーション条件まで具体的に定義することが大切です。「認識できなかったら2回まで聞き返し、3回目で有人につなぐ」といった分岐を曖昧にしたまま開発に進むと、リリース後に顧客が迷子になります。要件定義書に具体的なシナリオ図を添付し、ベンダーと認識を合わせておくことが、後の手戻りを防ぐ最大のポイントです。
稼働率・応答速度などの非機能要件を数値化する
IVRの要件定義で機能要件と並んで重要なのが、非機能要件です。IVRは顧客が直接触れる接点であり、止まれば即座に機会損失と信頼低下につながります。だからこそ、稼働率・応答速度・回答率といった品質を数値（SLA）で明記し、ベンダーに約束させることが欠かせません。曖昧な「安定稼働」ではなく、具体的な数値で縛ることが、トラブル時の責任所在を明確にします。
稼働率99.9%・応答3秒のSLAを明記する
稼働率は、IVRの非機能要件の筆頭です。神戸市の音声自動応答の調達では、年間稼働率99.9%以上を目標とする要件が示されました。稼働率99.9%は、年間の停止時間に換算すると約8.8時間に相当します。この水準を要件に置くことで、ベンダーには冗長構成や監視体制の整備が求められ、提案の本気度を見極められます。逆に、稼働率に言及しない要件では、障害時の対応がベンダーの善意頼みになってしまいます。
応答速度も明記すべき数値です。同じく神戸市の要件では、応答は3秒以内、繋ぎ言葉があれば5秒以内という基準が掲げられました。顧客は数秒の無音でも「つながっていないのでは」と不安になるため、応答速度はVUI品質を直接左右します。さらに回答率については、導入月50%、2ヶ月後60%、最終的に70%以上と段階的に引き上げる目標が設定されました。回答率を一度に高く設定せず、運用とチューニングで到達するスケジュールごと要件化する現実的な進め方が参考になります。
セキュリティ・個人情報保護の要件を定める
IVRは顧客の氏名や契約番号、ときには支払い情報など、機微な個人情報を扱います。そのため、通話録音データの保管・暗号化、アクセス権限の管理、ログの保持期間といったセキュリティ要件を明確に定める必要があります。とくに生成AIを使う場合、入力された顧客情報が外部のAIサービスに送信され、学習に利用されるリスクがないかを要件で確認すべきです。無料版や一般向けのAIサービスでは、入力データが学習に使われる契約になっていることがあり、業務利用には不向きな場合があります。
情報漏えいが起きた場合の損害は甚大です。一次データでは、情報漏えいへの対応には500万円以上のコストがかかる事例が示されています。要件定義の段階で、データの取り扱い範囲、外部送信の有無、委託先のセキュリティ体制を明文化し、RFPで各ベンダーに回答を求めることが、リスクを未然に防ぎます。セキュリティ要件は「あとで詰める」では済まされない、最初から要件定義に組み込むべき必須項目です。
トークン課金とハルシネーション対策の要件
生成AI（LLM）を組み込んだIVRでは、従来のシステムにはなかった新しい要件が必要になります。それが、トークン課金を前提としたコスト要件と、誤った回答（ハルシネーション）を防ぐ品質要件です。この2つを要件定義で押さえておかないと、稼働後にコストが暴騰したり、誤回答でトラブルになったりするリスクがあります。生成AI時代ならではの要件として、しっかり織り込む必要があります。
トークン課金を前提にコスト上限を要件化する
生成AIのコストは、リクエスト数とモデル選定に大きく依存します。月10万リクエスト（入出力各500トークン）の試算でも、Gemini 2.0 Flashで約3,750円、GPT-4o miniで約5,600円、Claude Sonnet 4で約135,000円と、モデルによって数十倍の差が出ます。要件定義では、想定リクエスト数の上振れも見込んだうえで、どのモデルを使い、月額コストの上限をいくらに置くかを明記すべきです。実際、月5万円を見込んでいたトークン費用が20万円を超えた、という事例も報告されています。
コスト要件では、リクエスト数が想定を超えた場合のアラートや上限制御の仕組みも盛り込みたいところです。利用量に応じて課金額が青天井に増える構造のままだと、想定外の入電増がそのままコスト増に直結します。月間のリクエスト数に上限を設け、超過時には簡易な応答に切り替える、といった制御を要件化しておけば、予算管理が安定します。生成AIのコストは「使ってみないと分からない」では済まされない、要件で縛るべき重要項目なのです。
ハルシネーション対策とRAG精度を要件化する
生成AIが事実と異なる回答を作り出すハルシネーションは、顧客対応では致命的なリスクです。これを防ぐには、社内のFAQやマニュアルを根拠に回答を生成するRAG（検索拡張生成）の精度を要件で定めることが有効です。RAGが参照するデータの構造やフォーマットの整理、誤回答を防ぐプロンプトの設計、そして回答の根拠を提示できる仕組みを要件に盛り込むことで、AIの暴走を抑えられます。正答率を品質保証の対象とするサービスもあり、KARAKURIのように正答率95%保証のプランを掲げる例もあります。
ハルシネーション対策の要件では、「AIが確信を持てない場合は推測で答えず、有人につなぐ」という安全側の挙動を定義することが重要です。間違った回答を自信満々に返すより、分からないと認めて人につなぐほうが、顧客の信頼を損ないません。RAG用データの整備は発注側の責任範囲に含まれることも多いため、誰がどのデータをどう用意するかを要件定義の段階で明確にしておくことが、稼働後の品質を左右します。AIの品質は、与えるデータと逃げ道の設計で決まるのです。
RFPの必須項目と見積りの評価軸
要件定義を固めたら、それをRFP（提案依頼書）にまとめ、複数のベンダーから提案と見積りを取ります。RFPの完成度が低いと、ベンダーごとに前提がばらばらになり、提案を横並びで比較できません。逆に、必要な情報が網羅されたRFPは、ベンダーの理解度や提案力を正確に引き出し、見積りの妥当性を判断する土台になります。
RFPに盛り込むべき必須項目
RFPには、プロジェクトの目的と背景、現状の電話業務の数値、自動化の対象範囲、コールフローとVUIシナリオ、機能要件、非機能要件（稼働率・応答速度・回答率のSLA）、連携先システム、セキュリティ要件、想定予算とスケジュール、そして保守・運用の体制を盛り込みます。とくにIVRでは、回答率の目標値や、トークン課金を含むランニングコストの前提を明記することで、見積りの抜け漏れを防げます。
連携先の明示も欠かせません。CRM・CTI・予約システム・基幹システムとの連携は、API開発に1件30万〜100万円かかるため、連携先を曖昧にしたまま見積もると、後から大幅な追加費用が発生します。RFPで「どのシステムと、何を、どの方向に連携するか」を具体的に示すことで、各ベンダーが同じ前提で見積もれるようになり、比較の精度が上がります。RFPの精度は、そのまま見積りの精度に跳ね返るのです。
初期費用とランニングコストの妥当性を見極める
見積りを評価するときは、初期費用だけでなく、ランニングコストを含めた総保有コスト（TCO）で比較することが鉄則です。IVR・ボイスボットの相場は、従量課金型なら1応答約50〜200円、固定型なら月額1万〜35万円、オンプレ型なら初期数百万〜2,000万円以上が目安です。フルスクラッチの外注では、小規模300万〜600万円、中規模600万〜1,500万円、大規模1,500万〜5,000万円以上が相場とされます。提示された見積りがこのレンジから大きく外れる場合は、その理由を必ず確認すべきです。
とくに注意したいのが、要件定義の不備による追加開発です。一次データでは、要件定義が不十分だと再開発に100万〜500万円が追加でかかる事例が示されています。安い見積りに飛びつくと、後から仕様変更や追加開発で総額が膨らむことが少なくありません。見積りの安さではなく、要件への理解の深さと、運用フェーズまで含めた提案の現実性で評価することが、失敗を避ける判断軸です。なお、SaaS型とスクラッチ型のどちらを選ぶかといった判断は、メリット・デメリットを扱う関連記事もあわせてご覧ください。
まとめ
IVRの要件定義とRFPを整理すると、現状の電話業務の数値による可視化を出発点に、コールフローとVUIシナリオの設計、稼働率99.9%・応答3秒・回答率70%といった非機能要件の数値化、トークン課金とハルシネーション対策という生成AI特有の要件、そしてRFPの必須項目と見積り評価軸という流れで組み立てるべきことが見えてきます。とくに非機能要件をSLAとして数値で縛ること、生成AIのコストを上限で要件化することが、稼働後のトラブルを防ぐ要になります。
要件定義で大切なのは、「ベンダーに任せる」のではなく「発注側が業務を起点に要件を固める」という姿勢です。現状の数値、達成すべきSLA、連携先、コスト上限を明文化したRFPがあって初めて、ベンダーの提案を正しく比較し、妥当な見積りを見極められます。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を創業。