何を試したか
コールセンター業務の「オペレーターと顧客がブラウザだけで顔を見ながら話す」フローを、アバター表示を前提に作り直す試作である。
顧客は URL にアクセスして「ヘルプを呼ぶ」を押すだけ。オペレーターはログイン後に「待機開始」を押すと自動マッチングが走り、双方が同じ通話ルームに入る。映像・音声・テキストチャットを 1 つの画面で完結させ、オペレーター側はカメラ映像の代わりに NICE CAMERA のアバターを出すことができるように設計している。
構成
| 層 | 採用技術 |
|---|---|
| バックエンド | ASP.NET Core 6 (C#)、Docker コンテナで常駐 |
| リアルタイム制御 | SignalR Hub による待機キュー・マッチング・切断検知 |
| WebRTC メディア | LiveKit Cloud（SFU、双方向映像・音声・DataChannel） |
| フロントエンド | 静的 HTML/CSS/JavaScript（フレームワーク不使用） |
| 認証 | 外部 API 経由のメール+パスワード、ASP.NET Core Session で 8 時間維持 |
| アバター入出力 | NICE CAMERA |
シグナリングと待機マッチングは自作の SignalR Hub で持ち、映像・音声の中継は LiveKit Cloud に任せている。ブラウザ側に API キーやシークレットを置かないよう、LiveKit 接続用 JWT トークンはバックエンドで都度発行する構成にした。
画面
オペレーターのログイン画面
メールアドレスとパスワードで認証する。開発モードでは認証スキップボタンを出せるようにしており、社内動作確認のオーバーヘッドを抑えている。
顧客側の待機画面
カメラ・マイクのプレビューを確認し、必要なら表示名をカスタム指定したうえで「ヘルプを呼ぶ」を押す流れ。顧客側にもアバターを出せるようにしてあり、顔を出したくない利用シーンに対応できる。
オペレーターの通話画面
相手の映像が全画面、自分の映像は右下の Picture-in-Picture で表示する構成。オペレーター側は実映像の代わりにアバターを送出できる。マイク・カメラの個別 ON/OFF とデバイス切替を通話中に行えるようにしている。
何が分かったか
- 顔を出さずに対応できる選択肢が、オペレーターの稼働可能時間を広げる。化粧・服装・在宅時の背景といった制約から解放されるため、受付業務の人員配置の自由度が上がる
- 待機キュー・マッチング・切断後の再待機を SignalR Hub の薄いインメモリ状態 で実装でき、コールセンター規模の初期 PoC であれば DB を持たずに成立する
- LiveKit Cloud に映像中継を任せると、アプリ側は JWT 発行とマッチングだけ に集中できる。WebRTC の SFU を自前で立てる場合と比較して、初期構築コストが大きく下がる
- ngrok の固定ドメイン + systemd サービス化で、VPS 再起動を跨いでも安定して外部公開できる導線が作れた
- 認証は「セッション + 別端末検知ポーリング」の素朴な構成でも、コールセンター運用の要件（同一アカウントの二重ログイン防止）には十分対応できる
想定する応用
- コールセンター・サポート窓口：実映像とアバターの選択を運用者側に持たせ、顧客接点の心理的負担を下げる
- オンライン受付・案内：自治体・施設のリモート受付。アバター越しでも「人がいる」体感を保ったまま稼働時間を伸ばせる
- 業務委託オペレーター：在宅・出張先からの応対を、画面映りを気にせず行える環境
関連プロダクト
この試作で使用しているアバター入出力基盤は製品化済み:
- アバター入出力: NICE CAMERA
制限・今後
現時点ではオペレーター 1 名 + 顧客キュー方式での動作確認段階。マッチング状態がインメモリのため、複数台スケールアウトや障害再開時の永続化は未対応である。
今後は (1) 複数オペレーター同時稼働時のキュー戦略、(2) 通話履歴・対応ログの永続化、(3) アバター人格の業務別カスタマイズ、(4) モバイルブラウザでの操作性向上を検討する。