tracerouteの結果をどう読めばいいのか整理して解説する

ネットワークが遅い・つながらない問題に当たると、まず ping を打ってみる人は多いと思います。

でもこういう壁に当たることがあります。

• ping は通るのに、体感はめちゃくちゃ遅い
• 特定の時間帯だけ重い
• 自分のPCなのか、社内回線なのか、相手側なのか判断できない
• 「ネットワークが原因っぽい」以上のことが言えず、相談しても話が進まない

こういうときに役立つのが traceroute（Windowsでは tracert）。

通信が「目的地までにどのルーター（ホップ）を通るか」を見える化してくれるので、どこまでが自分側で、どこからが回線・相手側なのかの整理ができます。

ただ、出力がそれっぽく見える分、

• 途中に * * が出た
• あるホップだけ 200ms とか出た

みたいな結果を見て「ここが原因だ！」と早合点しやすいのも事実です。

この記事は、そういう誤解を避けながら、tracerouteの結果をちゃんと読めるように整理して解説します。

tracerouteでわかること・わからないこと

tracerouteでわかること

tracerouteは、あなたのPCから目的のサーバーまでの経路をこういう形で表示します。

• 何番目の経由地（ホップ）か
• そのホップが応答するまでの時間（ms）
• 途中で応答が返らなかった場合（*）

ざっくり言えば「通信の道順表」です。

tracerouteでわからないこと（ここが大事）

逆に、tracerouteの結果だけで原因を断定できないケースも多いです。

たとえば

• あるホップが遅い＝そこが原因 → とは限りません
• *が出た＝詰まっている → とは限りません

この「とは限らない」がネットワークの難しいところで、

だからこそ 読み方のコツが必要になります。

tracerouteとpingの違い：目的が違う

• ping：目的地に届くか、往復時間はどれくらいか
• traceroute：目的地に届くまでに通ったルーターと、その応答時間

例え話にすると、

• ping：ゴールまで行けるかの確認（「通れる？」）
• traceroute：途中でどこを通ったかの確認（「どの道を通った？」）

pingは単体で強いけど、どこで詰まってるのかまでは見えません。

その補助として traceroute がちょうどいい、という関係です。

最低限＋「効く」オプションを少しだけ

「コマンドは必要最低限」というルールに合わせて、ここでは厳選して紹介します。

ただ、評価でも触れられていた通り、オプションがあると実務で助かるので、最低限＋αだけ入れます。

macOS / Linux（基本）

traceroute example.com

macOS / Linux（ICMP寄りにしたいとき）

多くの traceroute はUDPで探査します。

でも現場では「ICMPで見たい」こともあるので、その場合はこれ。

sudo traceroute -I example.com

• -I：ICMP Echo（pingに近い方式）で経路を調べる
• sudo が必要なことが多い

ポイント：

機器やFWの設定によって、UDPは通るけどICMPは落とされる（逆もある）ことがあるので、両方試せると切り分けが一段ラクになります。

Windows（基本）

tracert example.com

Windows（名前解決をしない：表示を速く・シンプルに）

ホップごとのホスト名解決（DNS逆引き）が遅いと、tracert自体が遅く見えることがあります。

そんなときは -d を付けるとDNS逆引きをしません。

tracert-d example.com

• -d：ホップのホスト名解決を省略（IPだけ表示）

実務だと「相手に結果を貼る」ことが多いので、最初から -d で取っておくと読みやすくなることがあります。

まずは「何が書いてあるか」を押さえる

典型的な出力を簡略化して見ます。

1  192.168.x.x     1.1 ms  1.0 ms  1.2 ms
2  10.0.x.x        5.5 ms  4.9 ms  5.1 ms
3  203.0.x.x    15.2 ms  14.8 ms  16.0 ms
4  198.51.x.x  30.1 ms  29.5 ms  31.0 ms
5  example.com    35.0 ms  34.8 ms  35.5 ms

1列目：ホップ数

「何個目のルーターを通ったか」です。

数字が増えるほど目的地に近づいています。

2列目：IPアドレス / ホスト名

そのホップで応答した機器です。

• 192.168.x.x や 10.x.x.x はプライベートIP → 社内や自宅ルーターの内側でよく出ます
• 203.x.x.x のようなものはグローバルIP → インターネット上に出たサイン

3列目以降：応答時間（ms）が3つある理由

tracerouteは通常、同じホップに対して3回試します。

ネットワークは混雑や揺れがあるので、1回だけだと判断できないからです。

読むときは

• 平均として遅いか
• ばらつきが大きいか

を見るのが基本です。

* * * の意味：ここを誤解するとハマってしまう

例：

7  *  *  *

これは「そのホップから応答が返ってこなかった」という意味です。

*が出る理由は「障害」だけじゃない

ここを強調します。

*の原因はけっこう幅があります。

• ICMP応答を制限している（優先度が低い）
• tracerouteの探査パケットへの応答を返さない設定
• FWでブロックされている
• 応答が遅すぎてタイムアウトした
• そのホップだけ応答しないが、実際の通信は通っている

特に現場で多いのが 「ICMPの扱い」です。

ICMPの取り扱いが雑だと、tracerouteは嘘っぽく見える

ネットワーク機器は、実際の転送処理（ルーティング）を最優先します。

tracerouteが使うICMP応答などは「おまけ」扱いにされることが多く、負荷時に優先度が下げられます。

結果として、

• tracerouteでは*が出る
• でもWebアクセスは普通にできる

みたいなことが起きます。

判断のコツはシンプルで、「その後も進むか？」です。

• *が出ても最終的に目的地まで到達する → 多くは問題なし（応答しないだけ）
• *が続き、目的地まで到達しない → どこかで止まっている可能性が高い

遅延の読み方：誤解でありがち「遅いホップ＝犯人かも」

ここは重要なので、より丁寧に整理します。

まず前提：tracerouteの時間は「そのホップの応答時間」

tracerouteは「そのホップが返信した時間」を測っています。

つまり

• そのホップが返信を後回しにすると遅く見える
• でも通信転送自体は普通にやっているかもしれない

というズレが起きます。

パターン1：あるホップから遅延が増え、その後も遅い（怪しい）

4  ...  30 ms
5  ... 120 ms
6  ... 130 ms
7  ... 125 ms

この場合、ホップ5付近から「本当に」遅延が増えている可能性が高いです。

後続ホップもずっと遅いので、経路全体の遅延として乗っています。

パターン2：あるホップだけ遅いが、その後が速い（犯人とは限らない）

4  ...  30 ms
5  ... 200 ms
6  ...  35 ms

この場合、ホップ5が遅いのではなく、ホップ5が応答を返信の優先度が低いだけのことがあります。

この違いは重要で、

「ホップ5が遅いからそこが原因」と断定すると、原因究明が迷子になりがちです。

「到達しているか」の確認：最終ホップの見方の注意点

評価の改善提案にもあったポイントです。

ここも実務的に押さえておくと事故が減ります。

最終ホップに名前（ホスト名）が出ないこともある

目的地まで到達していても、

• 逆引きDNSが設定されていない
• -d オプションで名前解決をしていない

などの理由で、最終ホップにホスト名が出ず、IPだけになることがあります。

つまり、

• ホスト名が出ない＝到達してない ではありません。

到達の判断は

• 最後にIPが出ているか
• tracerouteが途中で打ち切られていないか

で判断する方が安全です。

逆に「目的地のホスト名が出たのに届いていない」こともある

DNSの解決ができているだけで、通信ができていないケースもあります。

この場合は traceroute の最後まで結果が出ない（* で終わる）ことが多いです。

実務でのポイント：tracerouteを「使える武器」にする

1) 単発ではなく「比較」で見る（これが強い）

tracerouteは比較すると、急に情報量が増えます。

• 重い時間帯と軽い時間帯で取る
• 別PCで取る
• 別回線（テザリングなど）で取る

例えば

• 社内回線だと遅い
• スマホテザリングだと速い

なら、原因は社内回線側に寄ります。

こういう「比較結果」があると、ネットワーク担当やベンダーに相談したときの進み方がまったく変わります。

2) パケットロスと遅延は切り分ける（pingを組み合わせる）

tracerouteは経路と遅延の確認に強いですが、

パケットロスの判断は ping の方が得意です。

ただ「pingを連続で」と言われても、初心者だと回数や目安がわかりづらいので、再現性が上がる例を置きます。

macOS / Linux：100回pingしてロスを確認

ping -c 100 example.com

• -c 100：100回送る
• 結果に packet loss が出るので確認しやすい

Windows：100回pingしてロスを確認

ping -n 100 example.com

もっと実務っぽい「時間帯チェック」の例（短時間でOK）

たとえば「夜だけ重い」なら、夜に100回打ってロスが出るかを見るだけでも効果があります。

さらに厳密にやるなら、

「10秒おきに 60回（10分）」みたいに、時間を切って様子を見るのもアリです。

※ただし、現場によっては大量のpingが嫌がられることもあるので、まずは100回くらいが無難です。

3) 報告は「貼る」より「言語化」が強い

tracerouteの結果をそのまま貼っても、読めない人には伝わりません。

だから実務では、結果に一言添えるだけで価値が跳ね上がります。

例：

• 「ホップ5から遅延が120ms以上に増え、その後も継続」
• 「ホップ7以降が *で目的地まで到達しない」
• 「テザリングだと再現せず、社内回線のみで再現」

これだけで「調査の方向性」が共有できるので、対応が早くなります。

一問一答：ちょっとしたまとめ

* * * が出たら障害確定？

確定ではありません。

ICMP応答を制限している機器は多く、tracerouteへの返信だけ落とすことがあります。

「その後も進むか」「目的地まで到達するか」で判断します。

途中のホップが異常に遅い。そこが原因？

そこが原因とは限りません。

次のホップが普通の速度なら「そのホップの応答だけ遅い」可能性があります。

遅延が後続ホップへ連なっているかを見るのがコツです。

tracerouteが途中で止まるのはなぜ？

FWでブロックされている、経路が不安定、目的地がICMPを落としている、などがあり得ます。

この場合は ping を併用し、到達性とロスの有無を確認すると整理しやすいです。

パケットロスがあるか確かめるには？

ping を一定回数（例：100回）実行して packet loss の割合を見るのが簡単です。

tracerouteは経路を見る道具、pingは到達性とロスを見る道具、という役割分担で考えると混乱しません。

まとめ：tracerouteは「犯人探しの断定」より「切り分けの道しるべ的な感じ」

tracerouteは「このホップが遅い＝ここが原因」と決め打ちするための道具ではなく、

どこまでが自分側で、どこからが回線・相手側かを整理する道具です。

ポイントを整理すると、

• *は即障害ではない（ICMP制限や優先度の問題が多い）
• 遅いホップが原因とは限らない（後続ホップまで遅いかを見る）
• 到達しているかは「ホスト名が出るか」ではなく「最後まで到達しているか」で見る
• ロス確認は ping を組み合わせる（例：100回）
• 実務では比較が最強（時間帯・回線・端末）

この読み方ができるようになると、ネットワーク問題に直面したときに

なんとなく不安 から

ここまでは自分側、ここから先が怪しい に変わります。

この差が、実務ではかなり大きいです。

次に「遅い」「つながらない」が起きたら、tracerouteを取って、この記事の観点で整理してみてください。

状況が言語化できるだけでも、対応が進めやすくなります。