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

概要

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

対象環境

ホストスペック: 要件を満たしている

表示端末はデジタルヒューマンを快適に利用するための端末要件をご覧下さい。

MiniPrem（デジタルヒューマン配信サーバー）は環境準備をご覧下さい。

ファイアウォール: 設定なし（FWやプロキシが問題になっている場合はネットワーク管理者に許可してもらうことで解決します。ファイアウォール・を参照してください。）

用語解説

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

用語	説明
配信サーバー	デジタルヒューマンを配信しているサーバーの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を使用する場合

表示端末（MiniPrem） ←→ デジタルヒューマン配信サーバー(MiniPrem) # 同一端末内
表示端末（あなたの端末） ←→ VPNやプライベートネットワーク/LAN ←→ デジタルヒューマン配信サーバー(MiniPrem) # 同一ネットワーク内の別端末

特徴:

最も高速・低遅延

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

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

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

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

表示端末（あなたの端末） ←→ (NAT/ファイアウォール) ←→ インターネット ←→ TURNサーバー ←→ デジタルヒューマン配信サーバー(通常サービス)

特徴:

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

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

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

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

シーケンスダイアグラム

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

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%のパケットロスでも、30fpsの場合は1秒間に約10フレームが失われる

診断フローチャート（簡易版）

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

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

chrome://webrtc-internals/ → candidateType を確認
├─ host / srflx → P2P直接通信（RTT基準: <300ms）
└─ relay → TURN経由（RTT基準: <400ms）

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

Windows:

# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
ping -n 100 192.168.0.100

Linux/Mac:

# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
ping -c 100 192.168.0.100

判定基準:

✅ 平均RTT <100ms: 良好

⚠️ 平均RTT 100-300ms（TURN: 100-400ms）: 許容範囲

❌ 平均RTT >300ms（TURN: >400ms）: WebRTC通信に支障

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

ステップ3: WebRTC相当のping（Linux/Macのみ）

# 30fps、1200バイト
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
sudo ping -i 0.033 -s 1200 -c 1000 192.168.0.100

判定:

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

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

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

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

Windows:

# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
iperf3.exe -c 192.168.0.100 -u -b 5M -t 30

Linux/Mac:

# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
iperf3 -c 192.168.0.100 -u -b 5M -t 30

判定:

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

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

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

ステップ5: 経路診断（Linux/Macのみ）

# mtrで問題箇所特定
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
mtr -r -c 100 192.168.0.100

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

ステップ6: 実WebRTC統計（最終確認）

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

OS別診断方法

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

Windows の場合

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

方法1: WSL2を使用（推奨）

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

WSL2のインストール:

# PowerShellを管理者権限で実行
wsl --install
# 再起動後、Ubuntuを起動

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

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

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

基本ping（標準コマンド）:

# PowerShell または コマンドプロンプト
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
ping -n 100 192.168.0.100

判定基準:

平均RTT <100ms: 良好

平均RTT 100-300ms（TURN経由は100-400ms）: 許容範囲

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

iperf3のインストール（UDP帯域テスト用）:

iperf3 Windows版をダウンロード

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

PowerShellでそのフォルダに移動

# UDP帯域テスト
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
iperf3.exe -c 192.168.0.100 -u -b 5M -t 30

PsPing（Microsoft製ツール）:

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

# インストール後
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
psping -n 100 192.168.0.100:80

Linux/Mac の場合

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

コマンド例の注意事項:

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

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

1. WebRTC 30fps相当のping（標準品質）

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

# パケットサイズ1200バイト、33ms間隔（30fps相当）
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
sudo ping -i 0.033 -s 1200 -c 1000 192.168.0.100

実行時間: 約33秒（1000パケット）

確認項目:

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

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

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

2. WebRTC 60fps相当のping（高品質）

# より高フレームレート（60fps = 16.67ms間隔）
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
sudo ping -i 0.016 -s 1200 -c 2000 192.168.0.100

実行時間: 約33秒（2000パケット）

3. MTU上限テスト（1500バイト）

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

# MTUサイズでのテスト（フラグメンテーション確認）
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
sudo ping -M do -s 1472 -c 100 192.168.0.100 #Linux
sudo ping -D -s 1472 -c 100  192.168.0.100 #macOS

説明:

M do -D: パケット分割禁止（Path MTU Discovery）

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

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

より正確な診断ツール

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

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

MiniPrem側（デジタルヒューマン配信サーバー）

# iperf3サーバー起動
iperf3 -s -p 5201

クライアント側（表示端末（あなたの端末））

テスト1: UDP帯域テスト（WebRTC相当）

# 5Mbps UDPストリーム、30秒間
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
iperf3 -c 192.168.0.100 -u -b 5M -t 30 -i 1

オプション説明:

u: UDPモード（WebRTCと同じ）

b 5M: 5Mbps帯域（標準ビットレート）

t 30: 30秒間

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

確認項目:

Jitter（ジッター）: <30ms推奨

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

Transfer: 実際の転送量

テスト2: 双方向テスト

# 双方向同時テスト（WebRTCは双方向通信）
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
iperf3 -c 192.168.0.100 -u -b 5M -t 30 --bidir

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

# 2Mbpsから開始
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
iperf3 -c 192.168.0.100 -u -b 2M -t 10

# 5Mbps（標準）
iperf3 -c 192.168.0.100 -u -b 5M -t 10

# 10Mbps（高品質）
iperf3 -c 192.168.0.100 -u -b 10M -t 10

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セットアップ（初回のみ）:

PowerShell（管理者権限）で以下を実行：

wsl --install -d Ubuntu

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

mtrをインストール：

# WSL2 Ubuntu内で実行
sudo apt update
sudo apt install -y mtr

macOSでのmtrインストール

# Homebrewでインストール（初回のみ。Homebrewは別途インストールしてください）
brew install mtr

# インストール確認
mtr --version

Homebrew

The Missing Package Manager for macOS (or Linux).

https://brew.sh/ja/

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

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

# 経路上の全ホップのパケットロス・レイテンシーを可視化
# WebRTC相当（1200バイト、33ms間隔、約33秒）
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
sudo mtr -u -s 1200 -i 0.033 -r -c 1000 192.168.0.100　# レポートモード
sudo mtr -s 1200 -i 0.033 192.168.200.1　# rオプションなしでリアルタイムモード

オプション説明:

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	指定パケット数送信後、統計を表示して自動終了	スクリプト実行、ログ取得

出力例:

Host                Loss%   Snt   Last   Avg  Best  Wrst StDev
1. router           0.0%   100    1.2   1.3   1.0   2.5   0.2
2. isp-gateway      0.0%   100    8.5   9.1   7.2  15.3   1.8
3. 192.168.0.100    2.0%   100   45.2  48.3  42.1  85.7   8.5

問題箇所の特定:

特定のホップで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: 良好な接続

Host                Loss%   Snt   Last   Avg  Best  Wrst StDev
1. router           0.0%   100    1.2   1.3   1.0   2.5   0.2
2. isp-gateway      0.0%   100    8.5   9.1   7.2  15.3   1.8
3. 192.168.0.100    0.0%   100   45.2  48.3  42.1  55.0   3.2

✅ Loss% = 0%: パケットロスなし（理想的）

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

✅ StDev = 3.2ms: ジッターが小さい（安定）

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

例2: パケットロスあり（問題）

Host                Loss%   Snt   Last   Avg  Best  Wrst StDev
1. router           0.0%   100    1.2   1.3   1.0   2.5   0.2
2. isp-gateway      0.0%   100    8.5   9.1   7.2  15.3   1.8
3. 192.168.0.100    5.0%   100   45.2  48.3  42.1  85.7   8.5  ← ★問題

❌ Loss% = 5.0%: 問題あり（3%超）

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

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

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

Host                Loss%   Snt   Last   Avg  Best  Wrst StDev
1. router           0.0%   100    1.2   1.3   1.0   2.5   0.2
2. isp-gateway      3.0%   100    8.5   9.1   7.2  15.3   1.8  ← ★問題箇所
3. 192.168.0.100    0.0%   100   45.2  48.3  42.1  55.0   3.2

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

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

例4: 高ジッター（不安定）

Host                Loss%   Snt   Last   Avg  Best  Wrst StDev
1. router           0.0%   100    1.2   1.3   1.0   2.5   0.2
2. isp-gateway      0.0%   100    8.5   9.1   7.2  15.3   1.8
3. 192.168.0.100    0.0%   100   45.2  48.3  42.1 150.0  35.5  ← ★高ジッター

✅ 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サーバーへの接続診断

# TURNサーバーのIPアドレス/ドメインを確認
# chrome://webrtc-internals/ の relay candidate から取得

# TURNサーバーへのping
# ※ turn.example.com は実際のTURNサーバーアドレスに置き換えてください
ping -c 100 turn.example.com

判定基準:

RTT <50ms: 良好（TURNサーバーは近い方が有利）

RTT 50-100ms: 許容範囲

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

2. TURN経由の総合RTT確認

# TURNサーバー経由でデジタルヒューマン配信サーバーへping
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
ping -c 100 192.168.0.100

判定基準（TURN経由）:

RTT <250ms: 良好

RTT 250-400ms: 許容範囲

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

計算例:

あなた → TURNサーバー: 30ms
TURNサーバー → 配信サーバー: 80ms
総RTT = (30 + 80) × 2 = 220ms （許容範囲）

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:

# 1. 経路上の問題箇所特定
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
mtr -r -c 200 192.168.0.100

# 2. ルーターのQoS設定を確認
# 3. 有線接続を確認（Wi-Fi→有線）
# 4. ネットワークスイッチの負荷確認

Windows:

ルーターの設定画面でQoS（Quality of Service）を確認

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

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

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

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

対策:

Linux/Mac:

# 1. 長期間のジッター監視
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
ping -D -i 0.033 -s 1200 192.168.0.100 > ping_log.txt &

# -D: タイムスタンプ付き
# バックグラウンドで継続実行し、数時間後に解析

パターン分析:

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

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

Windows:

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

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

パターンC: レイテンシー > 300ms（TURN: >400ms）

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

対策:

Linux/Mac:

# 1. tracerouteで経路確認
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
traceroute 192.168.0.100

# 2. 不要な中継を経由していないか確認
# 3. CDN/エッジノードの利用検討

Windows:

# tracertで経路確認
# ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください
tracert 192.168.0.100

TURN経由の場合:

TURNサーバーの位置を確認（近い方が有利）

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

パターンD: 帯域不足

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

対策:

全OS共通:

実効帯域の確認（iperf3）

QoS（Quality of Service）設定

ルーターでWebRTC（UDP 22000-23000）を優先

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

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

Windows:

# ネットワーク使用状況の確認
Get-NetAdapter | Get-NetAdapterStatistics

実践的な診断手順（推奨）

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

Windows（PowerShell）:

# ※ 以下のコマンドの 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください

# 1. 基本疎通確認（10秒）
ping -n 100 192.168.0.100

# 2. iperf3でUDP帯域テスト（30秒、要iperf3サーバー）
iperf3.exe -c 192.168.0.100 -u -b 5M -t 30

# 3. 経路確認
tracert 192.168.0.100

# 4. 実際のWebRTC統計確認
# chrome://webrtc-internals/ で接続中の統計を確認

Linux/Mac（Bash/Zsh）:

# ※ 以下のコマンドの 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください

# 1. 基本疎通確認（10秒）
ping -c 100 192.168.0.100

# 2. WebRTC相当のping（30秒）
sudo ping -i 0.033 -s 1200 -c 1000 192.168.0.100

# 3. 経路診断（1分）
mtr -r -c 100 192.168.0.100

# 4. UDP帯域テスト（30秒、要iperf3サーバー）
iperf3 -c 192.168.0.100 -u -b 5M -t 30

# 5. 実際のWebRTC統計確認
# chrome://webrtc-internals/ で接続中の統計を確認

クイックリファレンス

判定基準早見表

指標	良好	許容（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 は不要です。直接コマンドを実行してください：

ping -n 100 192.168.0.100
tracert 192.168.0.100

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

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

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` は何に置き換えればいい？

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の実行結果（可能であれば）

概要

用語解説

通信経路の確認

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

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

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

シーケンスダイアグラム

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

診断フローチャート（簡易版）

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

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

ステップ3: WebRTC相当のping（Linux/Macのみ）

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

ステップ5: 経路診断（Linux/Macのみ）

ステップ6: 実WebRTC統計（最終確認）

OS別診断方法

Windows の場合

Linux/Mac の場合

より正確な診断ツール

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

MiniPrem側（デジタルヒューマン配信サーバー）

クライアント側（表示端末（あなたの端末））

mtrによる経路全体の診断

Windowsでのmtrインストール

macOSでのmtrインストール

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

TURN/STUN経由の追加診断

Chrome WebRTC統計（最も正確）

コマ落ちの原因別対策

実践的な診断手順（推奨）

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

クイックリファレンス

判定基準早見表

コマンド早見表（Linux/Mac）

コマンド早見表（Windows）

よくある質問（FAQ）

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

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

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

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

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

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

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

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

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