ジッターとは、音声パケットが届くタイミングのばらつきのことです。VoIP通話はあなたの声を小さなパケットに刻み、20ミリ秒ごとに1つを送り、それが同じ一定のリズムで届くことを前提にしています。それが遅れたり早まったり順不同で届くと、その不規則さがジッターであり、相手には言葉の途切れ、ロボット音声、空白として聞こえます。
音声エージェントを運用しているなら、ジッターは二重に効きます。入力側では発話者の音声を劣化させ、音声認識モデルには質の悪い信号が届きます。出力側ではエージェントの音声を劣化させ、発話者にはあなたの製品が壊れていると思われます。ブラウザでは問題ないのに電話でロボットっぽく聞こえるなら、モデルに触れる前にネットワークを調べてください。
このガイドでは、ジッターとは何か、何が原因か、実際の通話でどう測るか、どう直すかを、音声エージェントの開発者が実際に制御できる部分も含めて説明します。
ジッターの早見表
| 指標 | 快適 | 気になる | 使えない |
|---|---|---|---|
| ジッター | 30ms未満 | 30〜50ms | 50ms超 |
| パケット損失 | 1%未満 | 1〜3% | 3%超 |
| 片道遅延 | 150ms未満 | 150〜400ms | 400ms超 |
これは保証ではなく目安です。150msと400msという遅延の数字は、許容できる片道遅延について定めたITUの勧告G.114から、30msというジッターの数字はCiscoのジッター解説のようなベンダー文書で見られる指針です。優れた適応型ジッターバッファなら30msを超えるジッターも隠せますが、遅延の追加という代償が伴います。これらの指標をまとめた聴取体験を1つの数値に圧縮しようとするのがMOS（平均オピニオン評点）です。
ジッターの正体
VoIPの音声はRTP（Real-time Transport Protocol）に乗ります。送信側はすべてのパケットにシーケンス番号とタイムスタンプを刻み（RFC 3550）、受信側はパケットが送られた順番と、20ms分の音声のかたまりを再生すべき正確な時刻の両方を知っています。
ジッターは、その予定と現実のずれです。41番のパケットが40番の20ms後に届いたのに、42番が41番の60ms後に届いたら、そのストリームにはジッターがあります。同じRFCは報告の仕方も定めています。すべてのRTPストリームにはRTCP制御メッセージが対で付き、受信側は測定した到着間ジッターを含むレシーバーレポートを定期的に送り返します。まともな電話システムなら追加の計測なしにジッターを教えてくれるのはそのためです。プロトコルが最初からずっと点数をつけ続けています。
似ているけれど直し方が違う隣人を2つ、区別しておきましょう。
- レイテンシ（遅延）。 パケットが全体としてどれだけ遅れて届くかです。会話のかぶりを生みますが、音声そのものは歪めません。
- パケット損失。 届かないパケット（あるいは遅すぎて使えず、受信側が損失と数えるパケット）です。損失は音声のかたまりを消し、ジッターは不規則に届けるだけです。順序が入れ替わったパケットの束は、デコーダーが遅れ者を待っていられないため、受信側からは損失に見えます。
ジッターはどう聞こえるか
ジッターが大きくなっていく通話では、誰もが同じ進行を説明します。まず言葉の端がかけ始めます。デコーダーが失われたフレームを補間するようになると、声が金属的・ロボット的になります。次に空白が来ます。受信側がパケットを待つ間の0.5秒の沈黙で、待っていたパケットは一瞬後にまとめて到着します。極端になると通話が切れます。
どれも、ジッターバッファが仕事をして持ちこたえられなくなった姿です。となると、当然の疑問が浮かびます。
ジッターバッファとその代償
ジッターバッファは受信側の小さなキューです。パケットを届き次第すぐ再生するのではなく、少しの間保持してから一定の間隔で再生に回すので、30ms遅れで届いたパケットも自分の順番に間に合います。一般的なバッファは30〜50ms分の音声を保持します。適応型は状況に合わせて伸縮し、100〜200msまで膨らむこともあります。
この取引は、遅延と引き換えの滑らかさです。バッファの1ミリ秒は往復に追加される1ミリ秒で、追加遅延がおよそ150msを超えると会話はトランシーバーのやり取りのようになります。お互いが待って、話して、また待つ。小さすぎるバッファは遅延パケットを捨てるので音の欠落が聞こえます。大きすぎるバッファはジッターを隠す代わりに遅延を渡します。両方を得られる設定はありません。だからこそ、バッファ調整よりネットワークの修正が勝つのです。
バッファがどこにあるかは通話次第です。
- ブラウザやアプリの通話（WebRTC） には適応型ジッターバッファとパケット損失の隠蔽が標準搭載です。WebRTCとWebSocketのガイドで解説しています。自分で調整することはほとんどありません。
- SIP電話、PBX、SBC（セッションボーダーコントローラー） には設定可能なバッファがあり、デフォルト値があなたのネットワークに合っているとは限りません。
- 生のRTPインテグレーション では、バッファの実装はあなたの仕事です。SIPトランクから自分のスタックに音声を流し込むなら、そのバッファのサイズ決めはあなたの担当です。
ジッターの発生源
ジッターはほぼ必ずキューイングの問題です。経路上のどこかで、パケットがそれぞれ違う時間だけ待たされています。
- 輻輳。 いっぱいになっては空になるルーターやスイッチのポートは、パケットを予測不能な時間だけ保持します。典型的な原因で、混雑時間帯に現れます。
- Wi-Fiと携帯回線。 無線リンクは送信タイミングを調整し、静かに再送するため、到着時間のばらつきは有線Ethernetよりはるかに大きくなります。ホテルのWi-Fiからかけている発話者は、気のせいではありません。
- QoSの欠如。 QoSマーキングがなければ、音声パケットは大量ダウンロードの後ろに並びます。音声トラフィックにマーク（一般的にはDSCP EF）を付ければ、自分のルーターや多くのキャリアのバックボーンで優先できます。ただしマーキングは公共インターネットを越えられないことが多いです。
- 経路変更。 通話中にトラフィックが別経路に切り替わると、新しい経路はタイミングが異なり、バッファが適応するまでストリームが乱れます。
- 大きすぎるバッファ。 バッファブロートはジッターの地味な親戚です。どこかにある巨大なキューが負荷で変動する常駐遅延を追加し、どこにもパケット損失としては現れません。
ジッターの測り方
特別な機材は要りません。通話はすでに自分自身を測っています。
- RTCPレシーバーレポートを読む。 ジッター欄は、相手側が実際に経験したことの正規の数値で、ストリームのタイムスタンプ単位で表されます。G.711通話では8で割るとミリ秒になります（ほとんどのダッシュボードは換算済みです）。PBX、SBC、CPaaSのダッシュボードが通話ごとに表示しています。
- Wiresharkでストリームをキャプチャする。 Telephony → RTP → Stream Analysis が方向ごとのジッターと損失を報告し、受信側が実際に手にした音声をそのまま聞かせてくれます。
- WebRTCなら通話中に chrome://webrtc-internals を開き、
jitter、packetsLost、jitterBufferDelayをリアルタイムで見ます。 - 手軽な探針として、相手にpingを打つ。 往復時間の平均と最大の差が大きければ、経路上のジッターが疑われます。RTPジッターは音声ストリーム自身のタイムスタンプ単位で測るので、これは推定であって指標そのものではありません。
実際の通話で、一番混む時間帯に測ってください。混雑する火曜日の問題を閑散とした日曜日に測っても、すべて問題なしという答えが返るだけです。
ジッターの直し方
自分が制御できる区間から外側へ進みましょう。
- 自分のネットワークで音声を優先する。 RTPにDSCP EFのマークを付け、ルーターがそれを尊重することを確認します。他の何より先に、通話トラフィックを有線接続に移しましょう。
- ジッターバッファのサイズを意図的に決める。 設定できる機器では30〜50msあたりから始め、適応型バッファがあればそちらを選びます。
- 損失に強いコーデックを選ぶ。 コーデックを選べる区間では、Opusが帯域内前方誤り訂正を内蔵しています（RFC 6716）。公衆電話網ではG.711になります。こちらにはその保護がなく、頼れるのはバッファだけです。
- 経路を短くする。 発話者の近くに拠点を持つプロバイダーを選びます。余分なネットワーク区間は、いっぱいになりうるキューがもう1つ増えることを意味します。
- ラストワンマイルは受け入れる。 発話者がいるカフェのWi-Fiは直せません。できるのはそれを測ることです。他人のルーターのせいで自分のスタックをデバッグするのをやめるために。
ジッターと音声エージェント
エージェントの通話は、人同士の通話より多くの区間を経由します。発話者の電話、そのキャリア、あなたのテレフォニープロバイダーかSIPトランク、あなたのエージェントスタック、そして復路。ジッターはどの区間からでも入り込み、発話者の体験ではモデルの遅延に積み上がります。発話者に「ネットワークが120msのバッファを追加し、その後モデルが90msかかった」とは聞こえません。遅くて途切れる、ひとつのエージェントが聞こえるだけです。
ネットワークを正直に保つ習慣は2つです。
- 区間ごとに測る。 テレフォニープロバイダーのRTCP統計を読み、音声認識と音声合成の各ホップを別々に計測します。CartesiaはSonicのモデルレイテンシが90ms未満であることを公開しています。それはモデルの話であり、ネットワーク区間はその上に独自の遅延を積みます。まさにその遅延を捕らえるためにP95・P99の計測があります。モデルが速いのに通話が遅い、あるいは乱れているなら、それはジッターです。
- 実際の電話経路でテストする。 電話音声は8kHzのG.711 mu-lawまたはA-lawで流れ、他人のジッターバッファを通ります。あなたのノートPCで綺麗に聞こえるエージェントが、輻輳したキャリア経路では壊れて聞こえることがあります。音声モデルのせいにする前に、実際の電話番号から、混雑時間帯に、テスト通話をかけましょう。
Cartesia側では、Sonicは8kHzの生のmu-law・A-lawを直接返せるので（"encoding": "pcm_mulaw"、"sample_rate": 8000）、テレフォニー音声に余計な変換ホップが入りません。Inkはストリーミング音声認識で同じフォーマットを受け付けます。Managed AgentsはCartesia番号、Twilio、またはあなた自身のSIPトランクで通話に応答し、テレフォニー区間をあなたの代わりに運用します。エージェント通話は1分あたり0.03ドルで、1分あたり0.014ドルのテレフォニー追加料金はCartesia提供番号にのみ適用されます。デプロイリージョンは米国、EU、英国、インド、オーストラリアにあり、ネットワーク経路を短く保てます。SIPトランクはSRTPメディアでTLS接続し、設定はSIPトランキングガイドで説明しています。
それでもジッターに問題がなく、エージェントがロボットっぽいままなら、そのときはモデルのせいにしてよい、と私たちが許可します。