WebRTCネットワーク診断ガイド（パケットロス調査）
概要
デジタルヒューマンを表示する端末でアニメーションコマ落ち問題が発生している場合に、原因を特定する方法をご案内いたします。
対象環境
ホストスペック: 要件を満たしている
表示端末は デジタルヒューマンを快適に利用するための端末要件 をご覧下さい。
MiniPrem（デジタルヒューマン配信サーバー）は 環境準備 をご覧下さい。
ファイアウォール: 設定なし（FWやプロキシが問題になっている場合はネットワーク管理者に許可してもらうことで解決します。 **ファイアウォール・**ネットワーキングとWebRTC + TURN を参照してください。）
用語解説
このガイドで使用する用語を説明します。
配信サーバー
デジタルヒューマンを配信しているサーバーの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つのパターンがあり、それぞれ診断基準が異なります。
どちらの経路か確認する方法:
Chromeで
chrome://webrtc-internals/を開く（URLに入れる）接続中のセッションを選択
candidateTypeを確認hostまたはsrflx: P2P直接通信（ケース1に該当）relay: TURN経由（ケース2に該当）
ケース1: P2P直接通信（NAT/ファイアウォールなし）
MiniPremを使用する場合
特徴:
最も高速・低遅延
ファイアウォールやNATがない環境（同一ネットワーク上に
表示端末（あなたの端末）とデジタルヒューマン配信サーバーが存在する場合）RTT基準値: <150ms推奨、<300ms許容
ケース2: TURN/STUN経由（NAT/ファイアウォールあり）
通常のクラウドレンダリングサービスを使用する場合
特徴:
社外や公開ページなど、ネットワーク構成を気にせず利用できる
中継サーバー経由のため遅延増加
企業ネットワークやファイアウォール環境で使用
RTT基準値: <250ms推奨、<400ms許容（中継分を考慮）
シーケンスダイアグラム
シーケンスダイアグラムを参照してください。
WebRTC vs 動画配信・VoIPのパケット特性比較
「動画が見られる」「IP電話ができる」「インターネットが速い」環境でも、デジタルヒューマンでコマ落ちが発生する可能性があります。
重要な違い：
YouTube等の動画配信: 数秒〜数十秒先までバッファリング → 一時的なネットワーク遅延に強い
WebRTC（デジタルヒューマンやオンラインミーティング）: リアルタイム性重視でバッファリングなし → パケットロスが即座にコマ落ちにつながる
よくある誤解：❌ 「100Mbpsの回線だから大丈夫」と言われますが、実際には帯域よりもパケットロス率が重要です。100Mbpsあっても、WebRTC Videoはリアルタイムに表示するためにバッファを多く確保できないので、パケットロス1〜3%程度でコマ落ちが発生します。
パケットサイズ
可変
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%のパケットロスでも、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帯域テスト用）:
iperf3 Windows版をダウンロード
解凍して
iperf3.exeを任意のフォルダに配置PowerShellでそのフォルダに移動
PsPing（Microsoft製ツール）:
より詳細な診断が必要な場合、MicrosoftのPsPingが便利です。
Linux/Mac の場合
以下のコマンドがそのまま使用できます。
コマンド例の注意事項:
以下のコマンドの
192.168.0.100やrender-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の違い
プロトコル
ICMP のみ
ICMP / UDP
パケットロス率
❌ 表示なし
✅ Loss%
ジッター
❌ 表示なし
✅ StDev
統計精度
★☆☆
★★★
WebRTC診断精度
★☆☆（参考程度）
★★★（最適）
Windowsでのmtrインストール
WSL2を使えば、Linux/Macと同じmtrコマンドが使えます（推奨）。
WSL2のメリット:
UDP診断が可能：WebRTC相当の正確な診断ができる
詳細な統計：tracertよりも多くの情報（Loss%, StDev等）が得られる
inux/Macと同じコマンド：本ドキュメントの全てのmtrコマンドがそのまま使える
WSL2セットアップ（初回のみ）:
PowerShell（管理者権限）で以下を実行：
再起動後、Ubuntuを起動してユーザー名・パスワードを設定
mtrをインストール：
macOSでのmtrインストール
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まで遅延
結論: コマ落ちやカクつきが発生する可能性高、ネットワーク不安定
重要な指標の優先順位:
Loss%（パケットロス率）: 0%が理想、1%未満を目指す、3%超で即コマ落ち
StDev（標準偏差 = ジッター）: 10ms未満が理想、30ms超でカクつき
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通信の内部データを直接確認できるため、推測ではなく事実がわかります。
手順:
Chromeでデジタルヒューマンに接続
別タブで
chrome://webrtc-internals/を開く「Stats graphs for」セクションで接続を選択
以下の項目を確認
重要な統計項目:
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共通:
実効帯域の確認（iperf3）
QoS（Quality of Service）設定
ルーターでWebRTC（UDP 22000-23000）を優先
同一ネットワーク上の他トラフィック確認
Zoom、Teams、ダウンロードなどが同時実行されていないか
Windows:
実践的な診断手順（推奨）
クライアント側（表示端末（あなたの端末））で実行
Windows（PowerShell）:
Linux/Mac（Bash/Zsh）:
クイックリファレンス
判定基準早見表
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 コマンドが使えない
sudo コマンドが使えないA: 2つの方法があります：
1. ネイティブWindows（sudo不要）: PowerShellまたはコマンドプロンプトでは sudo は不要です。直接コマンドを実行してください：
2. WSL2（推奨）: WSL2をインストールすれば、Linux/Macと同じ sudo コマンドが使えます：
Q3: iperf3サーバーが起動できない
A: デジタルヒューマン配信サーバー側でiperf3サーバーを起動する必要があります。サーバー管理者に依頼してください。
Q4: TURN経由でRTTが400ms以上になる
A: 以下を確認してください：
TURNサーバーの位置が遠すぎないか
ファイアウォール設定を見直してP2P直接通信が可能か
ネットワーク管理者にWebRTC用ポート（UDP 22000-23000）の開放を依頼
Q5: パケットロスが3%以上発生している
A: 以下の順序で対策してください：
Wi-Fi → 有線LANに切り替え
mtrコマンド（Linux/Mac）またはtracert（Windows）でどこでパケットロスが発生しているか特定ルーターのQoS設定を確認
ネットワーク管理者に相談
Q6: コマンドの 192.168.0.100 は何に置き換えればいい？
192.168.0.100 は何に置き換えればいい？A: デジタルヒューマンを配信しているサーバーのIPアドレスまたはドメイン名に置き換えてください。
IPアドレスの例:
192.168.0.100、10.0.0.50ドメイン名の例:
render-host.digitalhumans.jp、dh-server.company.local
不明な場合は、システム管理者またはサポート窓口にお問い合わせください。
診断結果をサポートに送っていただく際の情報
以下の情報を含めると、より迅速なサポートが可能です：
OS情報（Windows/Mac/Linux、バージョン）
通信経路（P2P/TURN経由）
配信サーバーのIPアドレスまたはドメイン名
chrome://webrtc-internals/のスクリーンショットpingまたはiperf3の実行結果
mtr/tracertの実行結果（可能であれば）
最終更新