traceroute（tracert）で経路を可視化し問題箇所を特定する方法【実務向け】

ネットワークが遅い・通信が不安定・特定のサービスだけ到達しない…。 こういったトラブルの原因特定に強力な武器となるのが traceroute（Linux/UNIX系） と tracert（Windows） です。

本記事では、traceroute の仕組み、実務での使い方、問題箇所の特定ポイント、注意点までまとめて解説します。 初心者から実務で原因調査を行うエンジニアまで役立つ内容となっています。

1. traceroute（tracert）とは？

traceroute とは、通信が宛先へ向かうまでに通過するルーター（ホップ）の一覧を表示し、どこで遅延やパケットロスが発生しているかを調査できるコマンドです。

[PC] → [ルーター] → [ISP] → [インターネット] → [宛先サーバ]

主に次を確認できます：

• どの経路を通って通信されているか
• どのノード（ホップ）で遅延が発生しているか
• どこでパケットロスが発生しているか
• 経路変更（ルーティング変更）が起きていないか

2. traceroute の仕組み（TTL利用）

traceroute は IP ヘッダの TTL（Time To Live） を利用して経路を可視化します。

仕組みの流れ

1. TTL=1 のパケットを送る → 1 番目のルーターで TTL が 0 になり、
   ICMP Time Exceeded が返ってくる
2. TTL=2 のパケットを送る → 2 番目のルーターで TTL が 0 に
3. TTL を増やしながら繰り返すことで経路が可視化される

図示すると次のイメージです：

(TTL=1)  PC → R1 ✖  
            ↑ R1から応答

(TTL=2)  PC → R1 → R2 ✖  
                      ↑ R2から応答

(TTL=3)  PC → R1 → R2 → R3 ✖  
                                ↑ R3から応答

最終的に宛先に到達すると “到達成功” を示す応答が返ります。

3. OS別コマンドの使い方

■ Linux / macOS（traceroute）

traceroute example.com

ポート指定（UDPではなくTCPで試す）

traceroute -T -p 443 example.com

■ Windows（tracert）

tracert example.com

■ 実行例（Linux）

$ traceroute google.com
 1  192.168.1.1      1.1 ms  0.9 ms  1.0 ms
 2  10.10.0.1        5.2 ms  4.9 ms  5.1 ms
 3  203.0.xxx.xxx   12.4 ms 12.3 ms 12.5 ms
 4  142.250.xxx.xxx 20.1 ms 20.0 ms 20.3 ms
 5  google.com       28.4 ms 28.1 ms 28.3 ms

4. traceroute の見方：どこを見れば原因が特定できる？

① 遅延が急増しているホップ

例：

 3  20 ms  
 4  21 ms  
 5  350 ms ← 🚨 遅延が急増

この場合、ホップ5 またはその近辺で遅延が発生している可能性が高いです。

② “* * *” の表示（応答なし）

例：

 4  * * *  

応答なしの意味は以下のいずれか：

• ICMP応答がフィルタされている（正常）
• ルーターが負荷高騰で応答できていない
• 本当に通信断が起きている

単純に「*だから故障」とは判断しないことが重要です。

③ ループしている（経路が巡回）

 5  10.10.1.1  
 6  10.10.2.1  
 7  10.10.1.1 ← 再び登場（ループ）

これは ルーティングループ の典型で、重大障害の可能性があります。

④ 経路が普段と変わっている（ルーティング変更）

BGPの経路変更や障害時迂回が起きるとルートが変化します。

普段：
 1 → 2 → 3 → 4 → サーバ

今日：
 1 → 9 → 10 → 11 → 4 → サーバ

急に遅くなった場合、経路変更が原因の可能性は非常に高いです。

5. 業務でよくある traceroute トラブル分析例

■ ケース1：社内から特定の SaaS だけ遅い

原因例：

• ISP側の一部ルーターが混雑している
• 海外経路に迂回されている
• ファイアウォールで特定ポートだけ遅延

対応：

• 宛先のIPに traceroute + TCPポート指定で確認
• 通信経路に異常があればISPへ問い合わせ

■ ケース2：特定拠点だけ遅い

原因例：

• 拠点→本社間のVPNルーターが輻輳
• 特定 WAN 回線の品質低下

対応：

• 拠点と本社双方から traceroute を実施（双方向確認）
• 問題箇所のホップを特定

6. traceroute を実務で使う際の注意点

• “*” は故障を意味しない（ICMPフィルタが多い）
• 遅延が高いホップ＝障害とは限らない（中間のICMP応答が低優先度）
• ファイアウォールで遮断されるケースが多い
• 複数回実行して平均傾向を見ること
• 双方向（A→B、B→A）を確認することが重要

7. まとめ

traceroute（tracert）はネットワークトラブルの原因特定に必須のツールです。

本記事では以下を解説しました：

• traceroute の仕組み（TTLの利用）
• OS別の使い方
• 遅延・ロス・ループの見方
• 実務トラブルでの分析例
• 誤解しやすい注意点

「どこで遅れているのか」「経路は正常か」を把握するだけでも、原因切り分け効率は大きく向上します。