【実務・中級編】 pingの往復遅延時間（RTT）の計測メカニズムと揺らぎ（ジッタ）の評価 – トラブルシューティング＆ネットワーク運用監視実践ガイド

深夜3時、スマホの着信音で叩き起こされる。モニタリングツールからの「APIレスポンス急増・レイテンシ悪化」のアラートだ。こういう時、君なら最初にどのコマンドを叩く？

「とりあえず ping だろ」――そう答えたなら、半分正解で半分は甘い。
ただパケットを飛ばして「あ、通ってるな」「応答が遅いな」と画面をぼんやり眺めているだけでは、夜間障害の泥沼から抜け出すことはできない。

NOC（ネットワークオペレーションセンター）の最前線では、ping が返す数字の羅列、そしてその背後にある「揺らぎ（ジッタ）」の微小な変化こそが、ネットワークの悲鳴を聞き取るための重要な手がかりになる。今回は、ICMPエコーの裏側で何が起きているのか、そしてそれをどう実務のトラブルシューティングやインフラ監視に応用すべきか、現場の泥臭い知見を交えて徹底的に解説しよう。

—

1. pingの往復遅延時間（RTT）計測メカニズムとICMPの正体

まず、私たちが普段何気なく使っている ping コマンドが、OSのカーネルやルーターのハードウェアレベルでどのように処理されているか、その通信のライフサイクルを正確に把握しておこう。

ping は、RFC 792で定義された ICMP（Internet Control Message Protocol） の Echo Request（タイプ8、コード0） と Echo Reply（タイプ0、コード0） を利用している。

パケットが駆け抜ける往復のドラマ

1. 送信側（クライアント）でのタイムスタンプ打刻:
ユーザーが ping を実行すると、OSのネットワークスタックがICMPパケットを生成する。この瞬間、カーネルは高精度タイマー（CPUのTSCなど）を参照し、パケットの送信時刻をメモリ上に記録する。
2. L2/L3カプセル化と送出:
IPヘッダー、イーサネットフレームヘッダーが付与され、NIC（ネットワークインターフェースカード）の物理層から電気信号（あるいは光信号）としてワイヤー上に送り出される。
3. 転送とルーティング:
パケットは途中のL2スイッチやL3ルーターを通過する。このとき、ルーターのキューイング遅延や処理遅延（パケットフォワーディング）がRTTに加算される。
4. 宛先での即時折り返し:
宛先ホストのOS（またはネットワークスタック）に到達すると、通常、上位レイヤー（TCP/UDP）の処理を通すことなく、カーネルの割り込みハンドラレベルで即座に Echo Reply が組み立てられ、送り返される。
5. 受信側での引き算とRTT算出:
自ホストに戻ってきた Echo Reply をキャッチした瞬間、再びタイムスタンプを取得。送信時の記録との差分を計算し、往復遅延時間（RTT: Round Trip Time）として画面に出力する。

ここで重要なのは、「pingの遅延は、往路と復路の合計値である」という点だ。片方が激しく輻輳していれば、RTT全体が跳ね上がる。片方向だけの遅延を切り分けるには、単純な ping だけでなく、ルーティングパス全体を分解するアプローチが必要になる。

—

2. 実務で直面する「ジッタ（Jitter）」の恐怖と評価指標

API設計やクラウドインフラの運用において、平均RTT（Average RTT）の数値だけに安心してはいないだろうか？

実務で本当に恐ろしいのは、遅延の絶対値そのものよりも、その揺らぎ（ジッタ / Delay Variation）だ。
例えば、VoIPやリアルタイム通信、あるいはマイクロサービス間の同期通信において、パケットの到着間隔がバラバラになると、バッファアンダーランやパケットロスを引き起こし、システムの致命的なパフォーマンス低下を招く。

標準偏差（Standard Deviation）とパケットロス率の重要性

一般的なOSの ping コマンドを実行した際、最後に表示される統計情報に注目してほしい。

# Linux環境での標準的なping実行例（Google Public DNS宛て）
$ ping -c 10 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=14.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=13.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=28.5 ms  <-- ここで跳ねている
64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=14.1 ms
...
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 13.852/16.104/28.512/4.321 ms

この最後の mdev（Mean Deviation: 平均偏差、環境によっては標準偏差に近い値）こそが、ジッタの大きさを表すバロメーターだ。
平均値が 16.1ms で一見良好に見えても、最大値が 28.5ms に達し、mdev が 4.3ms ある。これは、途中のバックボーンやルーターのキューが一時的に飽和し、パケットが待たされている（バッファブートジックの兆候）ことを意味している。

—

3. 実践：コードとCLIによる高度な遅延・ジッタ計測手法

では、単発の ping ではなく、実務の現場でインフラの健康状態をプログラムやスクリプトから継続的に監視・評価するための具体的な手法を見ていこう。

① Pythonによる動的RTT・ジッタ計測スクリプト

生のソケットを叩いてICMPを自前で実装するのは権限やOS依存の壁が高いため、実務では subprocess を利用してOSの ping コマンドの結果をパースし、時系列でジッタを評価するアプローチが手堅く実用的だ。

以下のPythonスクリプトは、指定したエンドポイントに対するRTTの揺らぎをリアルタイムで検知し、ジッタが閾値を超えた場合に警告を出力するツールの一例だ。

import subprocess
import re
import sys
import statistics

def monitor_ping(target_host, count=20, jitter_threshold=5.0):
    """
    指定されたホストに対してpingを連続実行し、RTTとジッタ（標準偏差）を評価する
    """
    print(f"[*] ターゲット {target_host} への診断を開始します (パケット数: {count})...")
    
    # Linux環境を想定したpingコマンドの構築（-cで回数指定）
    cmd = ["ping", "-c", str(count), target_host]
    
    try:
        result = subprocess.run(cmd, capture_output=True, text=True, check=True)
    except subprocess.CalledProcessError as e:
        print(f"[!] エラー: pingの実行に失敗しました。ターゲットがダウンしているか、ネットワークが遮断されています。\n{e.stderr}", file=sys.stderr)
        return

    # 各パケットの応答時間（time=XX ms）を正規表現で抽出
    rtt_pattern = re.compile(r"time=([\d\.]+)\s*ms")
    rtt_values = [float(match.group(1)) for match in rtt_pattern.finditer(result.stdout)]

    if not rtt_values:
        print("[!] 警告: 有効な応答パケットを取得できませんでした。")
        return

    # 統計情報の算出
    min_rtt = min(rtt_values)
    max_rtt = max(rtt_values)
    avg_rtt = statistics.mean(rtt_values)
    
    # サンプル数が2つ以上の場合のみ標準偏差（ジッタの指標）を計算
    jitter = statistics.stdev(rtt_values) if len(rtt_values) > 1 else 0.0

    print("\n--- ネットワーク診断サマリー ---")
    print(f"送信パケット数: {len(rtt_values)} / 受信成功")
    print(f"最小 RTT     : {min_rtt:.2f} ms")
    print(f"平均 RTT     : {avg_rtt:.2f} ms")
    print(f"最大 RTT     : {max_rtt:.2f} ms")
    print(f"ジッタ (偏差): {jitter:.2f} ms")

    # 閾値判定によるアラート発報のシミュレーション
    if jitter > jitter_threshold:
        print(f"\n[CRITICAL] ネットワークの揺らぎ（ジッタ）が許容閾値 ({jitter_threshold}ms) を超過しています！")
        print("-> ルーターのキュー枯渇、Wi-Fiの干渉、または上流プロバイダの輻輳を疑ってください。")
    else:
        print("\n[OK] ネットワークの遅延変動は安定しています。")

if __name__ == "__main__":
    # 実行例: 外部APIサーバーや社内ゲートウェイを指定
    target = "1.1.1.1"
    monitor_ping(target, count=15, jitter_threshold=3.0)

② Webアプリケーション・API側からの死活・遅延監視（Node.js / Fetch APIの応用思考）

インフラエンジニアだけでなく、Webアプリケーションエンジニアも「ブラウザやサーバーサイドからのレイテンシ計測」を求められることがある。ただし、ブラウザの Fetch API ではICMP（ping）は使用できず、HTTP/HTTPSのハンドシェイクを含めたTCPレイヤーのラウンドトリップタイム（TTFB: Time to First Byte）を計測することになる。

以下のJavaScript（Node.js環境またはフロントエンド）のコードは、APIエンドポイントへのリクエスト時間を高精度に計測し、ネットワークの健全性を擬似的に評価するスニペットだ。

/**
 * 指定されたAPIエンドポイントのレスポンス遅延（RTT的な指標）を計測する関数
 * @param {string} endpointUrl 診断対象のURL
 */
async function measureApiLatency(endpointUrl) {
    const startTime = performance.now(); // 高精度タイマーの取得
    
    try {
        // キャッシュをバイパスして純粋なネットワーク遅延を測るため、ヘッダーを調整
        const response = await fetch(endpointUrl, {
            method: 'HEAD',
            cache: 'no-store',
            headers: {
                'Pragma': 'no-cache',
                'Cache-Control': 'no-cache'
            }
        });

        const endTime = performance.now();
        const latency = endTime - startTime;

        if (!response.ok) {
            console.warn(`[WARNING] APIは応答しましたが、ステータスコードが異常です: ${response.status}`);
        }

        console.log(`[Metrics] Endpoint: ${endpointUrl} | Response Time (TTFB): ${latency.toFixed(2)} ms`);
        return latency;

    } catch (error) {
        console.error(`[ERROR] ネットワーク接続エラーが発生しました (${endpointUrl}):`, error.message);
        return null;
    }
}

// 実行例（定期的なヘルスチェックのイメージ）
// setInterval(() => measureApiLatency('https://api.example.com/healthz'), 10000);

—

4. 現場のシニアが教えるトラブルシューティングの極意

最後に、実務で遅延やジッタの悪化に直面したとき、パケットの動きから何を見抜くべきか、その実践的な思考プロセスを伝授しよう。

1. 「平均値」に騙されるな、常に「最大値」と「パケットロス」を見ろ
平均RTTが数ミリ秒であっても、数秒に1回パケットがロスしたり、急激にRTTが跳ね上がったりする場合、それは「QoS（Quality of Service）によるレートリミット（優先度の低いICMPの破棄・後回し）」である可能性が高い。必ず traceroute や mtr を併用し、どのホップ（ルーター）で遅延が拡大しているかを特定すること。
2. クラウド環境（AWS/GCP/Azure）におけるpingの限界を理解する
パブリッククラウドの仮想ルーター（VPCルーターやロードバランサー）は、セキュリティとパフォーマンスの観点から、ICMPパケットの処理優先度を意図的に低く設定していることが多い。そのため、「クラウド上のインスタンス宛てのpingがロスする、あるいは遅い＝アプリが遅い」とは限らない。必ずTCPベースの診断（nc や telnet、専用のヘルスチェックAPI）を組み合わせて裏を取るべきだ。
3. バッファブートジック（Bufferbloat）の存在を疑う
高負荷時にルーターの送信キューが大きすぎると、パケットが溜まりすぎてRTTが数百ミリ秒〜数秒に膨れ上がる現象が起きる。これを見抜くには、小サイズと大サイズのパケット（ping -s オプションでサイズ変更）を打ち比べ、パケットサイズによる遅延の乖離をチェックするのがプロの技だ。

ネットワークは生き物だ。そして ping やRTT、ジッタの数値は、その生き物が発する微弱な脈拍に他ならない。表面的な数字に一喜一憂せず、その裏でパケットがどのルーターを通り、どんなキューで待たされているのかを脳内でイメージできるようになれば、君も立派なネットワークの守護神だ。障害対応のその瞬間まで、パケットに愛を注いでいこう。