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