CASE STUDY ・ WEBサービス ・ コンタクトセンター向けAI受付・監視基盤｜VoiceDesk事例（仮称）
- コンタクトセンター
- AI音声応対
- ライブ監視
- マルチテナント
- WebSocket
※ 機密保持のため、企業名・プロジェクト名・システム画面は仮名およびモックに置き換えています。
この事例の根拠と読み方
根拠は、AMELAのケース移行記録、匿名化したVoiceDeskの開発ストーリー、公開用にモック化された画面アセットです。プロジェクト名と顧客名は機密保持のため匿名化しています。本文で確認できるのは、移行記録に記載された機能範囲、技術構成、開発期間12ヶ月・総工数60人月という開発時の記録です。
画面に表示される受電件数、割合、通話時間、問い合わせ番号などはデモ用の値です。SLA達成、応答率、平均処理時間、顧客データの安全性、運用コストの改善を比較測定した資料ではありません。AI音声応対についても、本文は応対フローと実装範囲を扱い、基盤モデルの再学習や自律的な判断を意味しません。
コンタクトセンター運営で先に決める四つの境界。
匿名化したコンタクトセンター運営企業では、複数の顧客企業から受託した電話受付を運用していました。運用を一つの基盤へまとめる前に、どの問い合わせをAIが一次受付し、どの条件でオペレーターへ転送するかを決めます。次に、SVがライブで確認できる情報と録音後の監査に残す情報、テナントごとの利用者・顧客データ・監査ログの境界、ルール変更の承認経路を定義します。
コンタクトセンターに求められた、4つの設計境界。
- AIが完了できる問い合わせ、転送条件、例外を定義する一次受付の範囲
問い合わせを人手だけで受ければ、繁忙時の判断境界が曖昧になる。
- SVが見る項目、介入条件、録音との関係を決めるライブ監視の責任
録音を後から確認するだけでは、介入の条件が決めにくい。
- データ、権限、監査ログをテナント単位で定義するテナント分離
複数顧客のデータを後から分けると、権限と監査の境界が複雑になる。
- NGワード、転送条件、ロール権限の承認者と反映時刻を残すルール変更の統制
転送条件をコードに固定すると、運用変更の承認経路が見えにくい。
電話受付を、四つの領域でつなぐ。
VoiceDeskでは、PBX接続とAI音声応対、WebSocketによるライブ転写、テナント単位のデータ分離、管理画面からの転送ルール変更を一つのSaaS基盤にまとめました。FastAPI、音声解析モジュール、Redis、Cosmos DB、JWTを用いた構成で、移行記録上の開発期間は12ヶ月、総工数は60人月です。この期間・工数は当該開発範囲の記録であり、他社の見積りや導入効果を保証するものではありません。
実装で確認できることと、導入前の注意点。
実装範囲として確認できるのは、AIが一次受付を担うフロー、SVが通話状況をライブで見る画面、tenantIdを前提にしたAPI条件、管理画面からの転送ルール設定です。これらは、どの業務を機械処理し、どこで人が介入するかを設計するための材料になります。
一方、AIに任せる問い合わせを広げるほどよいとは限りません。誤転送、本人確認、録音・文字起こしの保管、個人情報の取り扱い、障害時の有人切り替えを自社の規程と契約に合わせて確認してください。評価を始める場合は、対象時間帯、問い合わせ種別、転送の完了条件、測定期間、除外条件を固定し、導入前後で同じ定義を使います。
読者が使える実践ツール
以下の表を、AI受付や監視基盤の要件定義で使えます。未確認の成果を先に置かず、責任者と証跡を決めてから測定を始めます。
| 確認領域 | 導入前に決めること | 運用時に残す証跡 | まだ測れていない成果 |
|---|---|---|---|
| 一次受付 | AIが完了できる問い合わせ、転送条件、例外 | 音声フロー版、転送理由、承認者 | 応答率・処理時間は未測定 |
| ライブ監視 | SVが見る項目、介入条件、録音との関係 | 監視イベント、介入者、時刻 | SLA・品質改善は未測定 |
| テナント分離 | データ、権限、監査ログの境界 | tenantId、認可結果、監査ログ | 漏えいリスクの評価は別途必要 |
| ルール変更 | NGワード、転送条件、ロール権限の承認経路 | 変更差分、承認者、反映時刻 | 運用コストの変化は未測定 |
例えば「営業時間外の問い合わせ」を対象にするなら、AIが案内できる範囲、有人転送の条件、録音・文字起こしの保管期間、例外時の責任者を一行ずつ埋めます。これで、AIの導入可否だけでなく、停止条件と人の介入点を先に確認できます。
