コールセンターでSpeech2Speech AIを繋ぐときに知っておきたい3つの接続方式

はじめに

現在、弊社のコールセンターでは、従来型音声AI(音声→テキスト→回答生成→音声変換)を導入しています。このようなAIは、お客様の音声をテキストに変換し、AIが処理した後、再び音声に変換するという流れでした。

それに対し、昨年話題となったSpeech-to-Speech型のリアルタイムAI API(以下、S2S API)は、音声から直接音声で回答を生成できるようになり、より自然な会話が可能になりました。そこで、弊社でもS2S APIの導入を検討することになりました。

既存電話システムの仕組み

まず一般的なVoIPシステム(IP電話)の仕組みですが、以下の2つのプロトコルで構成されています。

SIP(Session Initiation Protocol)

  • 役割: 通話の開始、終了、転送などの制御
  • 特徴: 音声データ自体は送らない

RTP(Real-time Transport Protocol)

  • 役割: 実際の音声データの転送
  • 特徴: SIPとは別経路で送信される
[電話システム] --SIP(制御)--> [相手先]
               --RTP(音声)-->

このように、制御と音声が分離された2チャネル構成が電話システムの特徴です。

S2S APIを利用する上での3つの接続方式

S2S APIは、主に3つの接続方式に対応しています。

※対応状況はサービスによって異なります。導入するS2S APIの仕様を確認してください。

1. WebSocket

双方向通信チャネルを提供するプロトコルです。

通信モデル:

[クライアント] <--WebSocket(制御+音声)--> [S2S API]
  • HTTPでハンドシェイク後、TCP接続を維持
  • 制御信号と音声データを単一チャネルで送受信
  • 実装がシンプル
  • サーバー間(サーバー to サーバー)での処理に向いている

⚠️ 注意: WebSocketはTCPベースのため、ネットワーク上でパケットロスが発生した場合、再送処理により遅延が増大するリスクがあります。

2. SIP

電話システムと同じシグナリングプロトコルです。

通信モデル:

[電話システム] <--SIP+RTP--> [S2S API]
  • 既存のVoIPシステムと同じプロトコル
  • SIP(制御) + RTP(音声)の2チャネル構成
  • 電話システムとの親和性が高い

3. WebRTC

リアルタイム通信のためのフレームワークです。ブラウザ間のP2P通信向けに設計されましたが、S2S APIとの接続ではクライアントとAPIサーバー間の通信に利用します。

通信モデル:

[ブラウザ] <--WebRTC P2P--> [S2S API]
  • SRTP(Secure RTP)でメディア転送
  • 超低遅延(50-150ms)
  • ブラウザから直接接続可能

3つの接続方式の比較

項目WebSocketSIPWebRTC
遅延100-300ms(パケットロス時はさらに増大)100-300ms50-150ms
実装難易度
電話システム連携変換必要直接可能変換必要
ブラウザ対応×
主な利用用途サーバー間処理電話システム直結Webブラウザ通話
メリット実装が簡単
デバッグしやすい
既存インフラ活用
変換不要
低遅延
デメリットTCP特性上、パケットロス時に遅延増大リスクカスタマイズ性低
API実装に依存
実装複雑
ネットワーク環境によっては追加のインフラ構成が必要になるケースあり

※S2S APIサービスによって対応している接続方式は異なります。

コールセンターでの接続方式の選び方

コールセンターとS2S APIを繋ぐ場合、要件に応じて適切な接続方式が変わります。

既存の電話システムと直接接続する場合: SIP接続

既存インフラをそのまま活用できる

  • 電話システムと同じプロトコル
  • 追加の変換処理が不要

統合が容易

  • 電話番号からの着信に対応
  • 既存の通話フローに組み込みやすい

安定性

  • 電話業界で長年使われている実績

接続イメージ:

[お客様の電話] → [電話システム] –SIP/RTP–> [S2S API]

柔軟性やセキュリティを重視する場合: SBC経由WebSocket/WebRTC接続

音声処理のカスタマイズやセキュリティ管理を細かく行いたい場合は、SBC(後述)を経由してWebSocketやWebRTCで接続する方式が適しています。

接続イメージ:

[お客様の電話] → [電話システム] --SIP/RTP--> [SBC] --WebSocket/WebRTC--> [S2S API]

Webブラウザから利用する場合: WebRTC接続

電話システムを介さず、ブラウザから直接S2S APIと通話する場合は、WebRTC接続が低遅延で最適です。AIアバターなどで回答させたい場合はこちらの方式が適しています。

接続イメージ:

[Webブラウザ] --WebRTC P2P--> [S2S API]

参考情報: SBCとは

実際の運用では、電話システムとS2S APIの間にSBC(Session Border Controller)を配置するのが一般的です。

SBCの役割

SBCは、異なる通信モデル間の「橋渡し」をする機器です。

主な機能:

  • プロトコル変換: SIP ⇔ WebSocket/WebRTC
  • セキュリティ制御: アクセス制限、暗号化
  • 音声処理: コーデック変換、ノイズ除去、録音
  • 柔軟性: 複数のS2S APIサービスへの対応

SBC経由の構成:

[電話システム] --SIP/RTP--> [SBC] --WebSocket/WebRTC--> [S2S API]

SBCを挟むことで、セキュリティ強化や柔軟な音声処理が可能になります。

まとめ

コールセンターでS2S APIを繋ぐ接続方式は主に3つあります:

  • WebSocket: 実装がシンプル、サーバー間処理向き(ただしTCPの特性上、パケットロス時は遅延増大に注意)
  • SIP: 電話システムと親和性が高い、直接接続可能
  • WebRTC: 低遅延、ブラウザ向き

コールセンターでは、要件に応じて接続方式を選択します:

  • 既存インフラ活用 → SIP接続
  • 柔軟性・セキュリティ重視 → SBC経由WebSocket/WebRTC接続
  • Webブラウザ利用 → WebRTC接続

この記事で紹介した技術は、現在弊社内で導入に向けた検討・検証を進めています。今後お問い合わせの際に「なんだかスムーズだな」と感じることがあれば、このブログの技術が生かされているかもしれません。そんなことをふと思い出していただけたら嬉しいです。

ブログの著者欄

宇山 幸男

GMOインターネット株式会社

メーカー系保守会社、電力関連会社でインフラエンジニアとして勤務後、GMOインターネットグループに入社 / インフラ・運用本部 アーキテクチャー統括 アーキテクトチーム所属 / 業務効率化を主軸に活動しています。

採用情報

関連記事

KEYWORD

TAG

もっとタグを見る

採用情報

SNS FOLLOW

GMOインターネットグループのSNSをフォローして最新情報をチェック