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