音声AI電話受付システムの開発費用｜転送・録音・本人確認・人への切替

Λ-51である。ワレワレが地球の企業を観察すると、電話受付は「音声を文字にすれば終わり」と誤解されやすい。実際には、着信、用件の聞き取り、本人確認、担当者への転送、折り返し、録音、記録までを一つの業務として設計する必要がある。

トーンだ。結論から言う。音声AI電話受付システムの開発費用は、会話の長さよりも、どこで人へ切り替えるか、何を記録してよいか、外部システムとどう連携するかで変わる。この記事では見積項目と失敗しやすい境界を整理する。

音声AI電話受付でできること

対象になりやすいのは、営業時間案内、予約の一次受付、注文状況の確認、担当部署への振り分け、折り返し依頼などである。

一方、苦情、緊急性の高い連絡、複雑な契約変更、医療や法律の判断、本人確認が不十分な状態での情報開示は、人の対応を前提にした方が安全な場合がある。

Λ-51「ワレワレの文明では、すべての通信を自動化している、と言いたいところだが、それは物語上の比喩である。地球の現実では、例外を人へ戻す設計が品質を支える」

トーン「その通り。『AIが全部対応』という宣伝文句は仕様じゃない。できない用件を早く見分けて、迷わせず転送する方が重要だ」

着信から対応完了までの流れ

この流れの各段階で、利用する通信サービス、音声認識、会話制御、社内システム連携が異なる。見積では機能名だけでなく、通話件数、平均時間、繁忙時間帯、対応言語も伝える必要がある。

費用を左右する8つの項目

1. 電話回線と同時通話数

代表番号をそのまま使うか、新しい番号を取得するか、既存のPBXやクラウド電話と接続するかで構成が変わる。同時着信数が増えると、通信費や基盤設計も変わる。

Λ-51「月間件数だけでは足りない。地球時間の月曜朝に着信が集中するなら、ピーク時の同時通話数が必要である」

2. 音声認識と合成音声

固有名詞、住所、型番、業界用語、雑音、話者の年齢や話し方によって認識しやすさは変わる。事前に実際の通話例から確認項目を作り、聞き返しの回数や方法を設計する。

音声合成では、声質だけでなく速度、間、数字や記号の読み方、利用規約、商用利用条件を確認する。

トーン「きれいなデモ音声だけで決めるのは危険。携帯電話、車内、店舗のBGM、早口でも試す。録音データを検証に使える権利があるかも確認して」

3. 会話シナリオと自由発話

番号選択に近い固定シナリオは比較的範囲を定めやすい。一方、自由な話し方から用件を分類し、質問を変える設計は、想定発話、例外、検証ケースが増える。

シナリオ数だけでなく、分岐数、聞き返し、訂正、途中終了、沈黙時の処理を見積対象にする。

4. 本人確認

予約状況や契約情報を答える場合、誰に何を開示するかを決める。電話番号だけで本人とみなすのか、会員番号、生年月日、ワンタイムコードなどを組み合わせるのかは、情報の重要度に応じて検討する。

Λ-51「声が似ていることを本人確認の根拠にする場合は、精度、なりすまし、再生音声への耐性を評価する必要がある。万能な識別装置として扱ってはならない」

5. 人への転送と折り返し

転送先が応答できないときの処理まで設計する。

• 部署や用件ごとの転送先
• 営業時間内外の分岐
• 担当者不在時の代替先
• 待ち時間と呼び戻し
• 折り返し希望時間の受付
• 緊急語を検知した場合の案内
• 転送時に担当者へ渡す要約

トーン「AIと人の間で、利用者に同じ説明を二度させるのは最悪の体験。転送前の要約は便利だけど、誤要約の可能性を明示し、録音や原文へ戻れるようにする」

6. 録音・文字起こし・要約

録音する場合は、目的、案内、保存期間、閲覧権限、削除手順を決める。文字起こしや要約には個人情報や機密情報が含まれる可能性があるため、AIサービスの保存・学習設定も確認する。

必要以上にすべてを残すと、保管費だけでなく漏えい時の影響も増える。目的に応じて、音声、全文、要約、受付結果のどれを保存するか分ける。

7. 顧客管理・予約・チケット連携

電話で受け付けた内容をCRM、予約システム、問い合わせ管理へ登録する場合、APIの有無、認証、項目、重複判定、失敗時の再送が必要になる。

Λ-51「連携成功の画面だけでは不十分である。相手側が停止した場合、受付内容を失わず、人が再処理できる待機箱を用意する」

8. 監視・改善・運用

導入後は、認識失敗、途中切断、転送率、有人対応後の修正を確認する。会話内容を無断で学習へ回すのではなく、利用目的と権限を明確にする。

トーン「運用費を隠した初期見積は比較できない。通信、音声認識、生成AI、監視、保守、シナリオ修正を月額で分けてもらうべきだ」

費用の考え方

実際の金額は、件数、通話時間、外部サービス、連携範囲、セキュリティ要件で変わる。見積は次の区分で比較する。

1. 初期調査・業務整理
2. 会話設計とプロトタイプ
3. 電話基盤・音声AI実装
4. 外部システム連携
5. テスト・セキュリティ確認
6. 導入・教育・移行
7. 月額の通信・AI利用料
8. 保守・監視・改善費

固定価格だけを見ると、従量課金の前提やシナリオ修正の範囲を見落としやすい。想定件数を少ない月、平均、繁忙月に分けて試算すると比較しやすい。

SaaSと個別開発の選び方

SaaSが向く場合

• 用件が定型的
• 既存の連携先が標準対応している
• 短期間で小さく試したい
• 標準の音声や管理画面で運用できる
• 初期費用を抑えたい

個別開発が向く場合

• 独自の本人確認や業務分岐がある
• 複数の基幹システムと連携する
• 業界固有の言葉や例外が多い
• データ保管や権限に厳しい要件がある
• 会話結果を独自の業務へつなげたい

すべてを自作する必要はない。電話、音声認識、生成AIなどは外部サービスを使い、独自部分だけを開発する構成もある。

見積依頼で伝える資料

• 月間着信数、平均通話時間、ピークの同時通話数
• 主な用件と、現在の対応手順
• 自動対応してよい範囲
• 必ず人へ渡す条件
• 本人確認と情報開示のルール
• 対応時間、言語、電話番号
• 録音・文字起こしの保存方針
• 連携するシステムとAPI資料
• 想定する障害時の代替手段
• 初期公開で必要な機能と将来機能

Λ-51「地球人は、成功時の流れだけを書きがちである。聞き取れない、連携できない、人が出ない。そのときの流れを資料に含めるべきだ」

トーン「そして実際の通話を匿名化して数件用意する。机上のシナリオより、想定外の言い方が早く見つかる」

小さく試す検証手順

まず一つの用件、限定時間、少ない番号で試す。営業時間案内や折り返し受付から始め、認識率だけでなく、完了率、転送後の手戻り、利用者の離脱を確認する。

Λ-51「AIの回答率を上げることだけが目的ではない。短い時間で適切な窓口へ着地できたかを見る」

トーン「自動化率が低くても、受付内容が整理されて担当者の負担が減るなら価値はある。逆に、自動化率が高くても誤案内が増えるなら止める判断が必要だ」

まとめ：人へ切り替える設計までがシステム

Λ-51「音声AI電話受付は、音声認識の精度だけで決まらない。本人確認、転送、記録、外部連携、障害時の戻し方までが一つの設計である」

トーン「見積では、初期開発費と月額費用、変更費用を分ける。宣伝文句より、失敗時の挙動を見る。そこまで確認して初めて比較できる」

自社の電話業務に合う範囲と開発費用を整理したい場合は、現在の対応フローと着信量を添えて見積をご相談ください。