AI電話自動応答システムの導入をベンダーに依頼するとき、成否を大きく左右するのがRFP（提案依頼書）と要件定義書の出来です。電話対応というのは、一見シンプルに見えて、稼働率・応答速度・回答率・連携範囲・セキュリティといった多くの要素が絡み合う業務です。これらを曖昧なままベンダーに丸投げすると、提案が比較できず、導入後に「想定した精度が出ない」「料金が想定外に膨らんだ」といったトラブルに直結します。だからこそ、何をどこまで要件に書くかが、プロジェクトの命運を握ります。
本記事は、AI電話自動応答システムのRFP・要件定義書・提案依頼書を「要件特化」で整理する解説です。稼働率99.9%や応答3秒といったSLA（サービス品質保証）の数値要件、生成AIのトークン課金を前提としたコスト要件、ハルシネーション対策やセキュリティの非機能要件、そしてベンダーの責任範囲の明文化まで、何を書くべきかを一次データとあわせて具体的に解説します。読み終えるころには、自社のRFPに盛り込むべき項目の骨子が描けるはずです。なお、費用相場や導入手順を含む全体像をまだ把握していない方は、まずAI電話自動応答システムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・AI電話自動応答システムの完全ガイド
SLA（稼働率・応答速度・回答率）の数値要件
AI電話自動応答のRFPで、もっとも具体的に数字で書くべきなのがSLAに関わる要件です。「使いやすいものを」「精度の高いものを」といった定性的な表現では、ベンダーごとに解釈がバラつき、提案の比較ができません。稼働率・応答速度・回答率という三つの軸を、明確な数値で示すことが要件定義の出発点になります。
稼働率99.9%・応答3秒以内をどう書くか
SLAの基準値として参考になるのが、自治体の調達仕様です。一次データでは、神戸市の調達において年間稼働率99.9%を目標とし、応答は3秒以内（繋ぎ言葉があれば5秒以内）という要件が示されています。稼働率99.9%以上は、AI電話自動応答を選定する一般的な基準にもなっています。電話は止まると顧客がつながらず即座に機会損失になるため、稼働率は妥協できない要件です。
RFPには、これらを「年間稼働率99.9%以上」「平均応答時間3秒以内」といった測定可能な形で明記します。あわせて、その数値を「どう測定し、未達の場合どうするか」まで踏み込んで記載すると、提案の質が上がります。稼働率の計測単位（月次か年次か）、メンテナンス時間の扱い、未達時のペナルティや改善義務などを要件化しておくと、導入後に「言った言わない」の争いを避けられます。曖昧な品質目標ではなく、検証可能な数値とその測定方法をセットで書くことが、要件定義の質を決めます。
回答率の段階目標とKPIの要件化
回答率（AIが対応を完結できた割合）は、SLAの中でもとくに慎重に要件化すべき項目です。AIは導入初日から完璧に答えられるわけではないため、回答率を一律100%と要求するのは非現実的です。一次データでは、回答率を導入月50%、2ヶ月後60%、最終的に70%以上へと段階的に引き上げる目標設計が示されています。RFPでも、こうした段階目標として書くのが現実的です。
さらに、神戸市の事例では年間約7.5万件の受電のうち、AIへの流入率70%・解決率60%を想定し、約2.5万件をAIで対応する想定が示されていました。このように「全受電のうち何件をAIが処理する想定か」までKPIに落とすと、ベンダーは現実的な構成と費用を提案しやすくなります。要件定義では、回答率を「導入時・3ヶ月後・最終目標」の三段階で示し、それを達成するためのチューニング体制やデータ整備の役割分担まで記載しておくことが、運用フェーズでの空回りを防ぎます。KPIは到達点だけでなく、その過程まで要件にすることが肝要です。
トークン課金を前提としたコスト要件
生成AIを使うAI電話自動応答ならではの要件が、トークン課金を前提としたコスト要件です。従来のシステムと違い、生成AIは利用量（トークン量）に応じて費用が変動するため、コスト要件を曖昧にすると、稼働後に料金が想定外に膨らむリスクがあります。RFPには、コストの変動構造まで踏み込んで要件化することが欠かせません。
モデル別トークンコストと上限の要件
トークンコストは、使う生成AIモデルによって大きく異なります。一次データの試算では、月10万リクエスト（入出力各500トークン）の場合、Gemini 2.0 Flashで約3,750円、GPT-4o miniで約5,600円、Claude Sonnet 4で約13.5万円と、モデルによって数十倍の差が出ます。RFPでは、想定するリクエスト数（通話数）を提示し、ベンダーにモデル別のコスト試算を求めることで、コスト構造を可視化できます。
コスト要件で必ず盛り込みたいのが、利用量が想定を超えた場合の扱いです。一次データには、トークン課金を月5万円と見込んでいたところ20万円を超過した事例があり、上限設定や超過時のアラートが要件として重要であることが分かります。RFPには、想定通話量と、それを超えた際のコスト上限・通知の仕組み、モデル選定の方針を明記しておきましょう。料金を「月額いくら」とだけ問うのではなく、「通話量がX件のときいくら、2倍になったらいくら」という変動を提案させることが、想定外の支出を防ぐ要件設計です。
初期・連携費・TCOと補助金の要件確認
コスト要件は、月々のトークン費だけでは完結しません。初期構築費、CRM/CTIとの連携開発費、運用・チューニングの費用までを含めたTCO（総保有コスト）で比較する必要があります。一次データでは、連携API費が1件あたり30万〜100万円、要件定義の不備による再開発が100万〜500万円の追加になる例が示されています。RFPでは、これらの追加費が発生する条件と単価を、あらかじめ提示させることが大切です。
あわせて、SaaSとスクラッチのTCO比較も要件確認の論点です。一次データでは、月30万円のSaaSと初期1,000万円のスクラッチは、5年TCOで見ると約3.5年が損益分岐点とされています。長期利用なら自社構築が有利になる場合があるため、想定利用年数を前提にした比較を求めましょう。補助金を活用する場合は、交付決定前の契約・着手が全額不支給につながる致命的なミスになり得るため、スケジュール要件として「交付決定後に契約・着手する」ことを明記し、ベンダーにも順守を求めることが重要です。費用は短期だけでなく中長期で要件化しましょう。
非機能要件（ハルシネーション対策・セキュリティ・責任範囲）
機能要件と同じくらい重要なのが、品質や安全性を担保する非機能要件です。生成AIならではのハルシネーション対策、個人情報を扱う電話業務のセキュリティ、そしてトラブル時に誰が責任を負うかという責任範囲の明確化は、RFPで必ず押さえるべき項目です。ここを曖昧にすると、稼働後に深刻なリスクが顕在化します。
ハルシネーション対策とセキュリティの要件
生成AIを使う以上、事実と異なる回答を返すハルシネーションのリスクは避けられません。RFPには、RAGによる参照情報の限定、回答できない場合に憶測で答えず有人へ引き継ぐ制御、回答内容のログ監視といった、ハルシネーション対策の具体策を要件として求めます。KARAKURIのように正答率95%を保証するプランも存在するため、正答率の保証や測定方法を提案させることも有効です。誤回答が顧客被害に直結する業務では、この要件の優先度は極めて高くなります。
セキュリティ要件も非機能の柱です。電話対応では氏名・連絡先・契約情報といった個人情報を扱うため、データの保管場所・暗号化・アクセス制御を明確に要件化します。とくに生成AIでは、入力した情報が外部のAIモデルの学習に使われないか、外部送信のリスクはないかを必ず確認すべきです。一次データでは、情報漏えいへの対応に500万円以上かかる例も示されており、事前のセキュリティ要件こそが最大の防御になります。無料版AIの安易な利用は、学習データへの取り込みリスクがあるため業務利用では避けるべきだと明記しましょう。
ベンダーの責任範囲と運用体制の要件
RFPで見落とされがちですが、トラブル時に「誰がどこまで責任を負うか」を明確にする責任範囲の要件は極めて重要です。AIが誤った回答をして顧客被害が出た場合、回答ナレッジの不備なのか、AIモデルの問題なのか、データ整備の漏れなのかで責任の所在が変わります。これを契約前に曖昧にすると、稼働後の問題対応で押し付け合いが起きます。要件定義の段階で、構築・運用・チューニングの各工程の役割分担を明文化しておきましょう。
あわせて、運用体制の要件も忘れてはいけません。一次データでは、AI電話自動応答の運用には最低でも月5〜10時間のリソースが必要とされています。回答ナレッジの更新、答えられなかった質問の分析、チューニングといった作業を、自社とベンダーのどちらが担うのかをRFPで明示します。riplaはフルスクラッチ受託と運用伴走の立場から、こうした責任範囲と運用体制を要件段階で具体化することを重視しています。導入して終わりではなく、継続的に育てていく前提を要件に織り込むことが、形骸化を防ぐ最後の砦です。
対応範囲・PoC・連携の要件を切り分ける
SLA・コスト・非機能の要件を固めたら、次に詰めるべきは「AIにどこまで対応させ、どこから人に渡すか」という対応範囲の線引きと、本番前の検証（PoC）、外部システムとの連携範囲です。これらを曖昧にしたまま開発に進むと、後から大きな手戻りや追加費用を招きます。要件定義の仕上げとして、この三点の切り分けを整理します。
対応範囲の線引きとPoC（検証）の要件
要件定義でまず明確にすべきは、AIが対応する問い合わせの範囲です。すべての電話をAIに任せようとすると、非定型の複雑な問い合わせで回答率が下がり、顧客の不満を招きます。一次データの神戸市の事例では、年間約7.5万件の受電のうち、AIへの流入率70%・解決率60%を想定し、約2.5万件をAIで対応する想定でした。このように「全件のうちどの範囲をAIが担い、残りは有人へ」という線引きを、要件として具体的に定めることが重要です。
あわせて、本番導入前にPoC（概念実証）を行う要件を盛り込むことを強くおすすめします。実際の問い合わせデータを使い、AIがどの程度の回答率を出せるかを小規模に検証してから本格導入に進めば、「想定した精度が出ない」という致命的な失敗を回避できます。RFPには、PoCの対象範囲・評価指標（回答率や正答率）・期間・合否基準を明記し、検証結果を踏まえて本番要件を確定する、という段取りを要件化しておきましょう。いきなり全面導入を約束させるのではなく、検証を経て判断する設計が、リスクを大きく下げます。
連携範囲とRAGデータ整備の要件
連携要件も、対応範囲と同じく明確な切り分けが必要です。CRM・CTI・予約システムなど、どのシステムとどこまで連携するかを要件として確定しないと、開発途中で「あの連携も必要だった」と判明し、費用が膨らみます。一次データでは、連携API費が1件あたり30万〜100万円かかる例が示されており、連携は安易に増やすと費用を押し上げます。RFPには、必須の連携と任意の連携を分けて記載し、それぞれの目的を明示することが大切です。
意外と見落とされるのが、RAGで参照させるデータの整備に関する要件です。AIが正確に回答するには、FAQやマニュアルが構造化され、AIが拾いやすい形式に整理されている必要があります。雑然とした資料をそのまま渡しても、回答率は上がりません。RFPには、データ整備を「自社が行うのか、ベンダーに委託するのか」という役割分担と、整備対象の範囲を明記しておきましょう。riplaはフルスクラッチ受託と運用伴走の立場から、対応範囲・連携・データ整備の切り分けを要件段階で具体化し、手戻りのない要件定義を支援します。曖昧さを残さないことが、後の追加費用を防ぐ最善策です。
まとめ
AI電話自動応答システムのRFP・要件定義書では、稼働率99.9%・応答3秒・回答率を段階的に70%以上といったSLAの数値要件、モデル別トークンコストと上限・TCO・補助金スケジュールを含むコスト要件、そしてハルシネーション対策・セキュリティ・責任範囲という非機能要件の三つを、測定可能な形で具体化することが核心です。とくに生成AI特有のトークン課金とハルシネーションは、従来システムにはなかった要件であり、ここを曖昧にすると稼働後の費用暴騰や誤回答トラブルに直結します。
要件定義で大切なのは、「ベンダーに任せる」のではなく「比較できる数値とその測定方法、役割分担まで書き切る」という姿勢です。神戸市の段階目標や、再開発100万〜500万円・連携費30万〜100万円といった一次データを物差しに、自社の通話量と業務に置き換えて要件を組み立ててください。riplaはフルスクラッチ受託と運用伴走の立場から、SLA・コスト・非機能を含む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を創業。