WebRTCネットワーク診断ガイド(パケットロス調査)

概要

デジタルヒューマンを表示する端末でアニメーションコマ落ち問題が発生している場合に、原因を特定する方法をご案内いたします。

対象環境

用語解説

このガイドで使用する用語を説明します。

用語
説明

配信サーバー

デジタルヒューマンを配信しているサーバーのIPアドレス(例: 192.168.0.100)またはドメイン名(例: render-host.digitalhumans.jp)。

RTT

Round Trip Time(往復遅延時間)。データが送信されてから返答が戻ってくるまでの時間。

パケットロス

ネットワーク上でデータが失われる割合。1%未満が理想的。

ジッター

遅延時間の揺らぎ。値が大きいと映像がカクつきます。

WebRTC

ブラウザでリアルタイム通信を行うための技術。デジタルヒューマンの映像配信に使用。

TURN/STUN

ファイアウォールやNATを越えて通信するための中継サーバー。

P2P

Peer to Peer。端末同士が直接通信する方式。

バッファ

データを一時的に蓄えるメモリ領域。受信データを先読みして保持することで、ネットワーク変動を吸収する。

バッファリング

データを事前に受信してバッファに蓄える処理。遅延と引き換えに安定性を得る。 例:YouTube(数秒先まで蓄える)、WebRTC(数十ms、最小限)。

UDP

User Datagram Protocol。データを高速送信するプロトコル。再送なし。WebRTCで使用。

ICMP

Internet Control Message Protocol。pingコマンドで使用。診断用プロトコル。

MTU

Maximum Transmission Unit。1回で送信できる最大パケットサイズ(通常1500バイト)。

通信経路の確認

デジタルヒューマンとの通信には2つのパターンがあり、それぞれ診断基準が異なります。

どちらの経路か確認する方法:

  1. Chromeで chrome://webrtc-internals/ を開く(URLに入れる)

  2. 接続中のセッションを選択

  3. candidateType を確認

    • host または srflx: P2P直接通信(ケース1に該当)

    • relay: TURN経由(ケース2に該当)

ケース1: P2P直接通信(NAT/ファイアウォールなし)

MiniPremを使用する場合

特徴:

  • 最も高速・低遅延

  • ファイアウォールやNATがない環境(同一ネットワーク上に表示端末(あなたの端末)デジタルヒューマン配信サーバーが存在する場合)

  • RTT基準値: <150ms推奨、<300ms許容

ケース2: TURN/STUN経由(NAT/ファイアウォールあり)

通常のクラウドレンダリングサービスを使用する場合

特徴:

  • 社外や公開ページなど、ネットワーク構成を気にせず利用できる

  • 中継サーバー経由のため遅延増加

  • 企業ネットワークやファイアウォール環境で使用

  • RTT基準値: <250ms推奨、<400ms許容(中継分を考慮)

シーケンスダイアグラム

シーケンスダイアグラムarrow-up-rightを参照してください。

WebRTC vs 動画配信・VoIPのパケット特性比較

「動画が見られる」「IP電話ができる」「インターネットが速い」環境でも、デジタルヒューマンでコマ落ちが発生する可能性があります。

重要な違い:

  • YouTube等の動画配信: 数秒〜数十秒先までバッファリング → 一時的なネットワーク遅延に強い

  • WebRTC(デジタルヒューマンやオンラインミーティング): リアルタイム性重視でバッファリングなし → パケットロスが即座にコマ落ちにつながる

よくある誤解:❌ 「100Mbpsの回線だから大丈夫」と言われますが、実際には帯域よりもパケットロス率が重要です。100Mbpsあっても、WebRTC Videoはリアルタイムに表示するためにバッファを多く確保できないので、パケットロス1〜3%程度でコマ落ちが発生します。

項目
動画配信 (YouTube等)
IP電話 (VoIP)
デジタルヒューマン (WebRTC Video)

パケットサイズ

可変

270バイト

1200-1500バイト

パケット間隔

可変

20ms (50pps)

33ms (30fps) または 16ms (60fps)

プロトコル

TCP (HTTP)

UDP/RTP

UDP/SRTP

ビットレート

可変 (1-50Mbps)

64kbps

2-10Mbps

バッファリング

数秒〜数十秒

数十ms

最小限

パケットロス耐性

強い(再送可能)

中程度

極めて弱い(再送なし)

遅延許容度

数秒OK

<150ms

<150ms(P2P) <250ms(TURN)

WebRTCの特性:

  1. リアルタイム性最優先: 遅延を最小限にするため、バッファリングをほとんど使わない

  2. 再送信なし: パケットが失われても再送信せず、そのフレームは欠落 → コマ落ち

  3. パケットロスの影響: たった1%のパケットロスでも、30fpsの場合は1秒間に約10フレームが失われる

診断フローチャート(簡易版)

ステップ1: 通信経路の確認

ChromeでURLにアクセス chrome://webrtc-internals/

ステップ2: 基本レイテンシー確認

Windows:

Linux/Mac:

判定基準:

  • ✅ 平均RTT <100ms: 良好

  • ⚠️ 平均RTT 100-300ms(TURN: 100-400ms): 許容範囲

  • ❌ 平均RTT >300ms(TURN: >400ms): WebRTC通信に支障

  • ❌ パケットロス >1%: 要調査

ステップ3: WebRTC相当のping(Linux/Macのみ)

判定:

  • ✅ パケットロス 0%、RTT安定: OK

  • ⚠️ パケットロス 1-3%: コマ落ちの可能性

  • ❌ パケットロス >3%: コマ落ち確実

ステップ4: UDP帯域・ジッターテスト(iperf3必須)

Windows:

Linux/Mac:

判定:

  • ✅ Jitter <30ms、Loss <1%: 良好

  • ⚠️ Jitter 30-50ms、Loss 1-3%: コマ落ちの可能性

  • ❌ Jitter >50ms、Loss >3%: コマ落ち確実

ステップ5: 経路診断(Linux/Macのみ)

どのホップでパケットロスが発生しているか確認

ステップ6: 実WebRTC統計(最終確認)

chrome://webrtc-internals/ で実際の通信状況を確認(最も正確)

OS別診断方法

お使いのOSに応じた診断手順を説明します。

Windows の場合

Windowsでは一部のLinux/Macコマンドが使えないため、以下の方法を推奨します。

方法1: WSL2を使用(推奨)

Windows 10/11ではWSL2(Windows Subsystem for Linux)を使うことで、Linux向けコマンドがそのまま使えます。

WSL2のインストール:

インストール後は「Linux/Mac編」の手順をそのまま実行できます。

方法2: Windowsネイティブツール

WSL2が使えない場合、以下のツールで代替できます。

基本ping(標準コマンド):

判定基準:

  • 平均RTT <100ms: 良好

  • 平均RTT 100-300ms(TURN経由は100-400ms): 許容範囲

  • パケットロス <1%: 良好

iperf3のインストール(UDP帯域テスト用):

  1. iperf3 Windows版arrow-up-rightをダウンロード

  2. 解凍して iperf3.exe を任意のフォルダに配置

  3. PowerShellでそのフォルダに移動

PsPing(Microsoft製ツール):

より詳細な診断が必要な場合、MicrosoftのPsPingarrow-up-rightが便利です。

Linux/Mac の場合

以下のコマンドがそのまま使用できます。

コマンド例の注意事項:

  • 以下のコマンドの 192.168.0.100render-host.digitalhumans.jp は例です

  • 実際のIPアドレスまたはドメイン名に置き換えてください

1. WebRTC 30fps相当のping(標準品質)

なぜ必要? デジタルヒューマンの実際の通信パターン(1200バイト、30fps)を模擬してネットワーク品質を確認します。

実行時間: 約33秒(1000パケット)

確認項目:

  • P2P直接通信: 平均RTT <150ms推奨、<300ms許容

  • TURN経由: 平均RTT <250ms推奨、<400ms許容

  • パケットロス: <1%推奨、<3%許容

2. WebRTC 60fps相当のping(高品質)

実行時間: 約33秒(2000パケット)

3. MTU上限テスト(1500バイト)

ネットワーク経路でパケット分割が発生していないか確認します。分割が起きるとパフォーマンスが低下します。

説明:

  • M do -D: パケット分割禁止(Path MTU Discovery)

  • 1472 = 1500 (Ethernet MTU) - 28 (IP+ICMP header)

  • エラーが出る場合、MTU問題あり

より正確な診断ツール

iperf3による帯域・ジッター・パケットロス測定

ping(ICMP)は優先度が低く扱われることがあります。iperf3はWebRTCと同じUDPプロトコルで、より正確な診断が可能です。

MiniPrem側(デジタルヒューマン配信サーバー)

クライアント側(表示端末(あなたの端末))

テスト1: UDP帯域テスト(WebRTC相当)

オプション説明:

  • u: UDPモード(WebRTCと同じ)

  • b 5M: 5Mbps帯域(標準ビットレート)

  • t 30: 30秒間

  • i 1: 1秒ごとに統計表示

確認項目:

  • Jitter(ジッター): <30ms推奨

  • Lost/Total Datagrams: パケットロス率 <1%

  • Transfer: 実際の転送量

テスト2: 双方向テスト

テスト3: 段階的帯域増加テスト

mtrによる経路全体の診断

mtrコマンドを使用すると、どの中継地点(ルーター)で問題が発生しているか特定できます。特にNATを超えるパターンの場合はプロバイダーのパケットロスなども検討がつきます。

tracerouteとmtrの違い

機能
tracert や traceroute
mtr (**Linux/Mac/**WSL2)

プロトコル

ICMP のみ

ICMP / UDP

パケットロス率

❌ 表示なし

✅ Loss%

ジッター

❌ 表示なし

✅ StDev

統計精度

★☆☆

★★★

WebRTC診断精度

★☆☆(参考程度)

★★★(最適)

Windowsでのmtrインストール

WSL2を使えば、Linux/Macと同じmtrコマンドが使えます(推奨)。

WSL2のメリット:

  • UDP診断が可能:WebRTC相当の正確な診断ができる

  • 詳細な統計:tracertよりも多くの情報(Loss%, StDev等)が得られる

  • inux/Macと同じコマンド:本ドキュメントの全てのmtrコマンドがそのまま使える

WSL2セットアップ(初回のみ):

  1. PowerShell(管理者権限)で以下を実行:

  1. 再起動後、Ubuntuを起動してユーザー名・パスワードを設定

  2. mtrをインストール:

macOSでのmtrインストール

Homebrewarrow-up-right

mtrで経路全体の診断を行う

実際のWebRTC映像パケットに最も近い条件でテストします。

オプション説明:

  • u: UDPプロトコル(WebRTCはUDP/RTPを使用)

  • s 1200: パケットサイズ1200バイト(WebRTC映像RTPパケット相当)

  • i 0.033: 33ms間隔(30fps = 1000ms ÷ 30)

  • -r: レポートモード(統計を1回表示して終了、オプションなしはリアルタイム表示)

  • c 1000: 1000パケット送信(約33秒のテスト)

なぜこのパラメータなのか:

  • WebRTCの映像ストリームは、1200バイト前後のRTPパケットを30fps(約33msごと)で送信します

  • UDPは再送なし・優先度制御なしのため、実際のネットワーク品質が如実に現れます

  • ICMPは優先制御されることがあり、実際のUDPパフォーマンスと異なる場合があります

モードの違い:

モード
コマンド例
動作
用途

リアルタイムモード

mtr 192.168.0.100

ncurses画面でリアルタイム更新、Ctrl+Cで停止

対話的な診断、変動の観察

レポートモード(-r)

mtr -r -c 100 192.168.0.100

指定パケット数送信後、統計を表示して自動終了

スクリプト実行、ログ取得

出力例:

問題箇所の特定:

  • 特定のホップでLoss%が高い → そのネットワーク区間に問題

  • StDev(標準偏差)が高い → ジッター(遅延の揺らぎ)が大きい

各フィールドの意味:

フィールド
意味
読み方
判定基準

Loss%

パケットロス率

このホップで失われたパケットの割合

✅ 0% ⚠️ 0.1-3% ❌ >3%

Snt

送信パケット数

診断のために送信したパケット総数

多いほど精度高(通常100)

Last

最新RTT

最後に送信したパケットの往復時間(ms)

参考値(瞬間値)

Avg

平均RTT

全パケットの平均往復時間(ms)

最重要 ✅ <100ms ⚠️ 100-300ms ❌ >300ms

Best

最良RTT

最も速かった往復時間(ms)

理論上の最速値

Wrst

最悪RTT

最も遅かった往復時間(ms)

瞬間的な遅延を示す

StDev

標準偏差

RTTのばらつき(ジッター)(ms)

ジッター指標 ✅ <10ms ⚠️ 10-30ms ❌ >30ms

実践的な読み方:

例1: 良好な接続

  • ✅ Loss% = 0%: パケットロスなし(理想的)

  • ✅ Avg = 48.3ms: 平均遅延が良好

  • ✅ StDev = 3.2ms: ジッターが小さい(安定)

  • 結論: 接続品質良好、コマ落ちの心配なし

例2: パケットロスあり(問題)

  • ❌ Loss% = 5.0%: 問題あり(3%超)

  • ⚠️ StDev = 8.5ms: ジッターもやや高め

  • 結論: 最終ホップ(配信サーバー)でパケットロス → コマ落ち確実

例3: 中間ホップでパケットロス

  • ❌ ホップ2でLoss% = 3.0%: ISPゲートウェイで問題

  • 結論: ISP側の問題、ISPに連絡または回線変更を検討

例4: 高ジッター(不安定)

  • ✅ Loss% = 0.0%: パケットロスなし

  • ❌ StDev = 35.5ms: ジッターが高い(不安定)

  • ❌ Wrst = 150.0ms: 瞬間的に150msまで遅延

  • 結論: コマ落ちやカクつきが発生する可能性高、ネットワーク不安定

重要な指標の優先順位:

  1. Loss%(パケットロス率): 0%が理想、1%未満を目指す、3%超で即コマ落ち

  2. StDev(標準偏差 = ジッター): 10ms未満が理想、30ms超でカクつき

  3. Avg(平均RTT): P2P <150ms推奨、TURN <250ms推奨

TURN/STUN経由の追加診断

TURN/STUN経由で通信している場合、以下の追加診断が有効です。

1. TURNサーバーへの接続診断

判定基準:

  • RTT <50ms: 良好(TURNサーバーは近い方が有利)

  • RTT 50-100ms: 許容範囲

  • RTT >100ms: TURN経由の遅延が大きくなる原因

2. TURN経由の総合RTT確認

判定基準(TURN経由):

  • RTT <250ms: 良好

  • RTT 250-400ms: 許容範囲

  • RTT >400ms: コマ落ちの可能性高

計算例:

Chrome WebRTC統計(最も正確)

なぜ最も正確? 実際のWebRTC通信の内部データを直接確認できるため、推測ではなく事実がわかります。

手順:

  1. Chromeでデジタルヒューマンに接続

  2. 別タブで chrome://webrtc-internals/ を開く

  3. 「Stats graphs for」セクションで接続を選択

  4. 以下の項目を確認

重要な統計項目:

項目
説明
推奨値

googFrameRateReceived

受信フレームレート

30fps

googFrameRateDecoded

デコードフレームレート

30fps

packetsLost

パケットロス数

最小

googJitterBufferMs

ジッターバッファ

<100ms

googCurrentDelayMs

現在の遅延

P2P: <150ms / TURN: <250ms

bytesReceived

受信バイト数

ビットレート計算用

candidateType

接続タイプ

host/srflx (P2P) / relay (TURN)

コマ落ちの原因別対策

パターンA: パケットロス > 3%

原因: ネットワーク輻輳、機器の問題

対策:

Linux/Mac:

Windows:

  • ルーターの設定画面でQoS(Quality of Service)を確認

  • Wi-Fi → 有線LANに切り替え

  • ネットワークアダプターのドライバー更新

パターンB: ジッター > 50ms

原因: ネットワークの不安定性

対策:

Linux/Mac:

パターン分析:

  • ジッターが周期的 → 他のトラフィックの影響

  • ジッターが不規則 → 機器の問題

Windows:

  • タスクマネージャーでネットワーク使用状況を確認

  • 他のアプリケーション(OneDrive、Windows Update等)が帯域を使用していないか確認

パターンC: レイテンシー > 300ms(TURN: >400ms)

原因: 物理的距離、ルーティングの問題、TURN経由の遅延

対策:

Linux/Mac:

Windows:

TURN経由の場合:

  • TURNサーバーの位置を確認(近い方が有利)

  • 可能であれば、ファイアウォール設定を見直してP2P直接通信を試みる

パターンD: 帯域不足

原因: 他のトラフィックとの競合

対策:

全OS共通:

  1. 実効帯域の確認(iperf3)

  2. QoS(Quality of Service)設定

    • ルーターでWebRTC(UDP 22000-23000)を優先

  3. 同一ネットワーク上の他トラフィック確認

    • Zoom、Teams、ダウンロードなどが同時実行されていないか

Windows:

実践的な診断手順(推奨)

クライアント側(表示端末(あなたの端末))で実行

Windows(PowerShell):

Linux/Mac(Bash/Zsh):

クイックリファレンス

判定基準早見表

指標
良好
許容(P2P)
許容(TURN)
要対策

RTT

<100ms

100-300ms

100-400ms

P2P: >300ms / TURN: >400ms

パケットロス

<1%

1-3%

1-3%

>3%

ジッター

<30ms

30-50ms

30-50ms

>50ms

フレームレート

30fps

25-30fps

25-30fps

<25fps

コマンド早見表(Linux/Mac)

注意: 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください。

目的
コマンド

基本ping

ping -c 100 192.168.0.100

WebRTC ping (30fps)

sudo ping -i 0.033 -s 1200 -c 1000 192.168.0.100

経路診断(簡易/ICMP)

mtr -r -c 100 192.168.0.100

経路診断(WebRTC/UDP)★推奨

sudo mtr -u -s 1200 -i 0.033 -r -c 1000 192.168.0.100

UDP帯域テスト

iperf3 -c 192.168.0.100 -u -b 5M -t 30

MTUテスト (Linux)

sudo ping -M do -s 1472 -c 100 192.168.0.100

MTUテスト (macOS)

ping -D -s 1472 -c 100 192.168.0.100

コマンド早見表(Windows)

注意: 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください。

目的
コマンド

基本ping

ping -n 100 192.168.0.100

経路診断(tracert/標準)

tracert 192.168.0.100

経路診断(WSL2/簡易)

mtr -r -c 100 192.168.0.100

経路診断(WSL2/WebRTC)★推奨

sudo mtr -u -s 1200 -i 0.033 -r -c 1000 192.168.0.100

UDP帯域テスト(PowerShell)

iperf3.exe -c 192.168.0.100 -u -b 5M -t 30

UDP帯域テスト(WSL2)

iperf3 -c 192.168.0.100 -u -b 5M -t 30

よくある質問(FAQ)

Q1: P2PとTURN経由、どちらが使われているかわからない

A: chrome://webrtc-internals/ を開いて、接続中のセッションで candidateType を確認してください。

  • host または srflx: P2P直接通信

  • relay: TURN経由

Q2: Windowsで sudo コマンドが使えない

A: 2つの方法があります:

1. ネイティブWindows(sudo不要): PowerShellまたはコマンドプロンプトでは sudo は不要です。直接コマンドを実行してください:

2. WSL2(推奨): WSL2をインストールすれば、Linux/Macと同じ sudo コマンドが使えます:

Q3: iperf3サーバーが起動できない

A: デジタルヒューマン配信サーバー側でiperf3サーバーを起動する必要があります。サーバー管理者に依頼してください。

Q4: TURN経由でRTTが400ms以上になる

A: 以下を確認してください:

  1. TURNサーバーの位置が遠すぎないか

  2. ファイアウォール設定を見直してP2P直接通信が可能か

  3. ネットワーク管理者にWebRTC用ポート(UDP 22000-23000)の開放を依頼

Q5: パケットロスが3%以上発生している

A: 以下の順序で対策してください:

  1. Wi-Fi → 有線LANに切り替え

  2. mtr コマンド(Linux/Mac)または tracert(Windows)でどこでパケットロスが発生しているか特定

  3. ルーターのQoS設定を確認

  4. ネットワーク管理者に相談

Q6: コマンドの 192.168.0.100 は何に置き換えればいい?

A: デジタルヒューマンを配信しているサーバーのIPアドレスまたはドメイン名に置き換えてください。

  • IPアドレスの例: 192.168.0.10010.0.0.50

  • ドメイン名の例: render-host.digitalhumans.jpdh-server.company.local

不明な場合は、システム管理者またはサポート窓口にお問い合わせください。

診断結果をサポートに送っていただく際の情報

以下の情報を含めると、より迅速なサポートが可能です:

  1. OS情報(Windows/Mac/Linux、バージョン)

  2. 通信経路(P2P/TURN経由)

  3. 配信サーバーのIPアドレスまたはドメイン名

  4. chrome://webrtc-internals/ のスクリーンショット

  5. pingまたはiperf3の実行結果

  6. mtr/tracertの実行結果(可能であれば)

最終更新