コンタクトセンターや VoIP を運用していると、「あの通話は MOS が低かった」「品質が悪いとエージェントから報告があった」という話に必ず出会います。MOS(Mean Opinion Score)は音声品質を語る共通言語ですが、その数字を額面どおりに受け取ると誤った切り分けにつながる厄介さも持っています。
本稿では、MOS とは何か、どう計算されるのか、そして「MOS」という言葉に潜む落とし穴を整理したうえで、低 MOS インタラクションをどう調査するかを、CCaaS プラットフォーム(Genesys Cloud)を例に実務目線でまとめます。対象はエンタープライズの音声基盤に関わるエンジニア/ネットワーク担当です。
1. MOS とは何か
MOS は音声通話の品質を 1.0〜5.0 で表す指標です。数値が高いほど品質が良く、もともとは「人間が聞いてどう感じるか」を主観評価した値でした(ITU-T P.800、ACR = 絶対範疇評価)。現在はネットワーク品質メトリクスからアルゴリズムで自動算出されるのが一般的です。
品質の目安はおおむね次のとおりです。
| MOS | 品質の体感 |
|---|---|
| 4.3〜5.0 | 非常に良い |
| 4.0〜4.3 | 良い(固定電話相当) |
| 3.6〜4.0 | 許容範囲 |
| 3.1〜3.6 | 不満を感じ始める |
| 2.6〜3.1 | 多くが不満 |
| 〜2.6 | 品質が悪い |
重要な前提として、コーデックごとに到達できる理論上の最大 MOS が決まっています。G.711 は約 4.4、G.729 は約 4.1 が上限です。つまり「G.729 のコールが 4.4 に届かない」のは異常ではなく仕様です。この一点を知らないだけで、正常なコールを不良と誤判定してしまいます。
2. MOS はどう計算されるのか(E-model)
自動算出される MOS の中核は ITU-T G.107 の E-model です。E-model はネットワークとコーデックのパラメータから R 値(R-factor) を求め、それを MOS に写像します。
R 値の算出(概念)
R(LQ) = R0 - Is - Ie-eff + A … 聴取品質(遅延項を含まない)
R(CQ) = R(LQ) - Id … 会話品質(遅延項を含む)
Ie-eff = Ie + (95 - Ie) × Ppl / (Ppl + Bpl)
Ie = コーデック固有の Equipment Impairment Factor
Ppl = パケットロス率(%)
Bpl = コーデック固有の Packet Loss Robustness Factor
Id = 遅延・エコーに起因する impairment(片道遅延 Ta に依存)R 値 → MOS への変換
0 ≤ R < 100 → MOS = 1 + 0.035·R + 7·R·(R-60)·(100-R) / 10^6ここから読み取れる本質は、MOS を支配するのは主に パケットロス・遅延・コーデック種別 の 3 因子だということです。ジッタは式に直接現れませんが、ジッタバッファで吸収しきれない分が実質的なパケットロスとして効いてきます。
注意:プラットフォームの「正確な式」は公開されていないことが多い
実務で重要な但し書きです。たとえば Genesys Cloud の公式ドキュメントは、MOS の厳密な計算式や係数を公開していません。「業界標準の測定手法を用いて 1〜5 でランク付けする」とだけ記載されています。上記の詳細式は Genesys の別製品(SIP Endpoint SDK / Engage On-Premises)のドキュメントで公開されている E-model 実装であり、同じ E-model という手法は共通でも、Cloud 側が同一の係数を使っているかは公式には確認できません。
したがって設計・検証の場面では、「E-model ベースの推定値である」ところまでは公式根拠で言えますが、係数レベルの厳密一致は前提にしないのが安全です。
3. 「MOS」は一つではない ― P.800.1 の落とし穴
ここが本稿で最も強調したい点です。「MOS」と呼ばれる値は単一ではなく、由来の異なる複数の指標が同じ名前で流通しています。
ITU-T P.800.1 は、この混同を防ぐために用語体系を定義しています。区分は「主観 / 客観 / 推定」×「聴取のみ / 会話 / 発話」で、さらに帯域記号(N=ナローバンド、W=ワイドバンド、S=スーパーワイドバンド)が付きます。
| 聴取のみ (LQ) | 会話 (CQ) | 発話 (TQ) | |
|---|---|---|---|
| 主観 (S) | MOS-LQS | MOS-CQS | MOS-TQS |
| 客観 (O) | MOS-LQO | MOS-CQO | MOS-TQO |
| 推定 (E) | MOS-LQE | MOS-CQE | MOS-TQE |
そしてこの体系の要点は、「MOS-xxx は MOS-yyy と比較可能ではない」と明記されていることです。実運用で出会う「MOS」は主に次の 3 系統で、いずれも別物です。
- 主観 MOS(P.800):人間のパネルによる実聴取。最も純粋だが、録音済みサンプルにしか使えず、進行中の通話には適用できない。
- 客観 MOS(PESQ / POLQA、P.862 / P.863):原音と劣化音を突き合わせる full-reference アルゴリズム。能動計測ツールが多く採用。なお PESQ の素点レンジは −0.5〜4.5 で、主観の 1.0〜5.0 とスケール自体が異なる。
- 推定 MOS(E-model / G.107):ネットワークパラメータからパッシブに算出。ライブ通話向け。Genesys Cloud はこの系統。
実務上の含意:方式が違えば数値がずれるのは正常
CCaaS プラットフォームの MOS(推定系)を、外部の能動計測ツール(客観系)の値と突き合わせて「どちらかが間違っている」と結論づけるのは危険です。方式が違えば数値がずれるのはむしろ当然で、比較するなら以下を揃える必要があります。
- 同じ測定方式(主観 / 客観 / 推定)同士か
- 同じ帯域基準(ナロー / ワイド)同士か ― ナローバンドの 4.4 とワイドバンドの 4.4 は同じ音質を意味しない
- 会話品質(遅延込み)か聴取品質(遅延なし)か
MOS は「思想としてはデバイス/プロトコル非依存の共通知覚尺度」ですが、「現場の MOS 値はどの方式・どの帯域で出したかに依存する」 ― この二面性を理解しておくことが、誤った切り分けを避ける最初の一歩です。
4. 低 MOS インタラクションの調査手順
ここからは実務です。MOS が低いコールは「どの区間(レッグ)で、どの指標が悪化したか」を切り分けます。Genesys Cloud では MOS はレッグごとに算出され、その最低値が全体値になるため、まず「悪いレッグの特定」から入ります。
Step 1. トリアージ(単発か、系統的か)
最初に発生パターンを見分けます。ここで原因の当たりが大きく変わります。
- 特定エージェント/ステーションだけ → 端末側・ローカル NW(Wi-Fi、VPN、PC 負荷)
- 特定キュー/拠点/時間帯に集中 → 拠点回線・WAN・キャリア区間
- 特定の外線番号・SIP トランク → BYOC トランク/キャリア区間
- 全体的に散発 → リージョンまでの経路 or コーデック設定
Step 2. レッグ別メトリクスを読む
対象コールの詳細から、MOS を決める 3 因子を確認します。判断の目安は Genesys の WebRTC Diagnostics が用いる閾値が実務的です。
| 指標 | 目安 | 悪化時に疑うもの |
|---|---|---|
| パケットロス | 1% 未満 | 経路輻輳、Wi-Fi、QoS 未設定 |
| RTT(往復) | 300ms 未満(片道 150ms) | 地理的距離、リージョン選択、VPN 迂回 |
| ジッタ | 30ms 未満 | バースト輻輳、優先制御なし、無線干渉 |
Step 3. コール経路のセグメント分割
「悪いレッグ」がエージェント側かキャリア側かを物理的に切り分けます。ハイブリッドメディア(BYOC Cloud + Premises)では、PCAP が premise edge〜宛先 または cloud edge〜宛先 の部分しか映さず、全経路を 1 つの PCAP で追えない点に注意します。
Step 4. 深掘りツール
- SIP Diagnostics(PCAP / SIP トレース):詳細画面からダウンロードし Wireshark 等で解析。保持期間は 21 日間、生成には Telephony 権限が必要、ステーション間(内線同士)通話は PCAP が生成されない、生成はベストエフォート(高負荷時は通話処理を優先し遅延/中断あり)。PCAP からは RTP を抽出して実測のロス/ジッタを確認でき、推定 MOS を一次データで裏付けられます。
- WebRTC Diagnostics アプリ:エージェント環境から MOS・パケットロス・RTT・ジッタを実測し、ネットワーク到達性も検証。事象の再現とアプリ/NW の切り分けに有効。
Step 5. 権限の確認
詳細情報や診断が見えない場合、権限不足がよくある原因です。少なくとも Analytics > Conversation Detail > View Conversation、Communication > View Recording、PCAP 側は Telephony 権限が要ります。Divisions によって可視範囲が絞られているケースもあります。
5. 設計・運用の勘所(メリット/デメリット)
エンタープライズ運用の観点で、押さえておきたいトレードオフを整理します。
- 可用性:PCAP 取得は best-effort で高負荷時に犠牲になる仕様です。恒常的な品質監視を PCAP 頼みにせず、API 経由で MOS/QoS メトリクスを外部監視基盤に吸い上げる構成が堅牢です。
- 保守性:PCAP は 21 日保持のため、しきい値超過を検知したら自動で証跡取得・アラートするフローを組んでおくと後追い調査が容易になります。
- セキュリティ:PCAP や SIP トレースには発着番号などの情報が含まれ得ます。ダウンロード権限を最小権限で運用し、取得ログを残すことが望ましいです。
- 指標の扱い:MOS は E-model ベースの推定値です。単発の低スコアで判断せず、母集団・傾向で評価するほうが誤検知を避けられます。
まとめ
- MOS は知覚品質の共通尺度として便利だが、「MOS」という語は複数の異なる指標を指す。主観 / 客観(PESQ・POLQA)/ 推定(E-model)、および帯域(ナロー/ワイド)を揃えないと比較は成立しない。
- CCaaS プラットフォームの MOS は多くが E-model ベースの推定値。正確な計算式が非公開なこともあり、外部ツールとの数値差は「異常」とは限らない。
- 低 MOS の調査は「悪いレッグの特定 → 3 因子(ロス/遅延/ジッタ)の確認 → 区間分割 → PCAP/診断ツールで裏付け」の順で。コーデックの理論上限も忘れずに。
- 恒常監視は API メトリクス、深掘りは PCAP、という役割分担が可用性・保守性の面で現実的。
MOS の数字そのものより、「その数字がどう作られたか」を理解していることが、音声品質トラブルを正しく切り分けるエンジニアの武器になります。
注記:本稿に記載した閾値・保持期間・権限名・製品仕様は執筆時点の各種公式ドキュメント(ITU-T 勧告および各製品の公式資料)に基づきます。UI や仕様はバージョンで変わり得るため、実装時点で公式ドキュメントを再確認してください。