「ブラウザー通話がOpusに対応しているのに、相手の声が以前と変わらない」。このとき、コーデックの優先順位だけを変えても改善しないことがあります。確認したいのは、その通話の、どの区間で、どのような音声が運ばれているかです。
本記事では、コンタクトセンターの通話経路を例に、Opusの名前だけでは判断できない理由と、切り分けの順序を説明します。図は構成の一例であり、特定のクラウドサービスの標準構成を示すものではありません。
1. 「対応」「使用中」「通話全体」を分ける
Opusは、用途に応じて音声帯域やビットレートなどを扱えるコーデックです。ただし、製品が対応していることと、いまの通話で使用していることは別です。また、担当者のブラウザーでOpusを使っていても、外部回線側まで同じ方式とは限りません。Opusの技術的な位置付けはRFC 6716で確認できます。
| 確認する状態 | 分かること | まだ分からないこと |
|---|---|---|
| 端末・サービスがOpus対応 | 利用できる候補の一つ | この通話で選ばれたか |
| ある区間でOpusを使用 | その区間の符号化方式 | 別区間の方式や入力音の品質 |
| 相手側で音声を評価 | 観測した方向・条件での聞こえ | 別の経路、繁忙時、逆方向の結果 |
方式の基本的な比較は、G.711・G.729・Opusの違いと選び方をご覧ください。ここでは、選んだ方式が通話経路の中でどう使われるかを考えます。
2. 途中の区間で音の情報が制限されることがある
例えば、担当者のブラウザーと音声ゲートウェイの間はOpus、ゲートウェイと外部の電話設備の間はG.711という構成を考えます。相手から届く音が途中で狭い音声帯域に制限されていれば、その後でOpusに符号化しても、失われた高い周波数の情報を元どおりには戻せません。
これはOpusに意味がないという話ではありません。評価したい区間や利用条件が変われば、採用する価値も変わります。ただし、「担当者側がOpusだから、相手の音も必ず広帯域になる」という期待では、改善箇所を取り違えます。
通話の途中で方式を変える処理については、トランスコーディングが品質・遅延に与える影響で説明しています。変換があるだけで障害とせず、必要性と実測結果を確かめます。
3. 音源と端末の状態も確認する
古い音声案内ファイルや録音を再生しているなら、その元音源の帯域や音量も確認します。保存形式を変えただけでは、録音時に欠けた情報や、すでに生じた音割れは解消しません。マイクの距離、入力ゲイン、周囲の騒音、ヘッドセットの再生状態も、相手が聞く音に関係します。
「特定の案内だけ聞き取りにくい」「担当者が話すときだけ割れる」「着信経路によって違う」のように症状を分けると、コーデック以外の条件を調べやすくなります。録音を比較するときは取得位置も記録してください。サーバー側の録音が良好でも、その後の受信や再生まで良好とは断定できません。
4. Opusの表示だけで音声帯域を判定しない
SDPにあるopus/48000/2の48000は、RTPの時刻を扱うクロックレートです。この表示だけで、元の音源に高い周波数まで含まれているとは判断できません。/2も、実際の会話が常にステレオで送られることを意味しません。表記と実際の動作を分けて読む必要があります。RFC 7587のSDPへの対応付けが参考になります。
設定画面、接続時に交換した情報、通話中の統計を照合し、送信側と受信側を別々に記録します。ブラウザーで分かるのは主にその接続の情報なので、外部回線側は基盤やSBCの記録と対応付けます。
5. 改善箇所を見つける比較の順序
- 症状を固定する：こもる、途切れる、遅れる、割れるなど、困っている状態と方向を決めます。
- 通話経路を描く：端末、音声処理、回線、相手先の区間を分け、実使用コーデックと変換点を記録します。
- 音源と取得位置をそろえる：同じ試験音声を使い、同じ場所で比較します。
- 一条件ずつ変える：ヘッドセット、経路、コーデックなどを同時に変えず、変更と結果を対応付けます。
- 両方向と業務操作を確認する：通常会話に加え、必要な保留・転送後も試します。
例えば「内線同士は明瞭で、外部からの着信だけこもる」なら、まず同じ端末のまま着信経路を比較します。これは外部回線が原因だと断定する試験ではなく、次に詳しく調べる区間を絞るための比較です。結果には、変えなかった条件と確認できなかった区間も残します。
途切れを伴う場合は、コーデック変更だけで判断せず、RTP・RTCP・WebRTC統計の読み方を参考に、損失や到着間隔の変動と症状の時刻を照合してください。
6. コーデック名から、通話経路の評価へ
Opus対応は品質を検討する入口です。採用後は、実際の方式、入力音源、途中の変換、端末、通信条件を分けて評価します。問題を「Opusが良い・悪い」にまとめず、どの区間を変えると何が改善したかを残すことが、再現性のある対策につながります。
管理した音源で通話経路の変化を比べる方法は、Software AGDによる音声品質評価をご覧ください。取得できる音声や測定方法は構成により異なります。コーデックと通話経路の評価について相談する際は、困っている方向、利用端末、回線構成をお知らせください。
参照確認日：2026年10月5日。図と比較手順は説明用の構成・試験設計例です。