ルート確認と疎通確認の違い｜ネットワーク障害の調査手順

ネットワーク運用やトラブルシューティングにおける「疎通確認」と「ルート確認」の決定的な違いは、検証する対象が「目的地の通信可否そのもの」か「目的地に至るまでの通過経路（経由ルーターなど）」かという点にあります。疎通確認（pingやcurlなど）は特定の送信先へデータパケットが届き、双方向のやり取りが成立するかを確認する作業であり、ルート確認（tracerouteやtracertなど）は目的地へ至るまでにどのようなネットワーク機器を経由し、どの区間で遅延や切断が発生しているかを追跡・特定する作業です。

1. ルート確認と疎通確認の違いが一目でわかる比較表

ネットワーク障害の解析において、疎通確認とルート確認は補完し合う関係にあります。まず切り分けの基礎となる主な比較軸（目的、主なコマンド、動作するレイヤー、応答の解釈、障害時の役割）を表にまとめました。

2. 疎通確認とは？通信の「到達可否」を判定する基礎知識

疎通確認とは、あるノード（パソコンやサーバー、通信機器）から別のノードに対してネットワーク経由でデータパケットを送信し、正しく相手に届いて返信が得られるかを調べるテスト全般を指します。

疎通確認の目的とプロトコルの仕組み

疎通確認の最も一般的な手法は、ICMP（Internet Control Message Protocol）を利用したEcho Request（エコー要求）とEcho Reply（エコー応答）の往復テストです。コマンドラインで「ping」を実行すると、送信元から小さなパケットが相手へ送られ、相手機器のカーネルが応答を打ち返すことで「生きているか（生存確認）」を確かめます。

ただし、現代のクラウド環境や企業インフラでは、Webサーバー等の前段でICMP通信（ping）がセキュリティ上の理由からブロックされているケースが少なくありません。そのため、TCPやUDPの特定ポート（80番、443番、22番など）を指定したポート疎通確認も広く用いられています。

OS環境や利用目的に応じた具体的な疎通確認方法については、以下の解説記事も合わせて参考にしてください。

• Windows環境のコマンドプロンプトでPingが通らない原因を切り分ける場合は、コマンドプロンプトのpingで応答なし？原因特定と対処法5ステップをご参照ください。
• Windowsで特定のTCPポートを指定して接続性をテストする手順は、疎通確認をWindowsで！ポート指定コマンドの使い方と手順で解説しています。
• PowerShellを用いた高度なネットワーク診断を行いたい場合は、PowerShell疎通確認！Test-NetConnectionの使い方が便利です。
• Linux上でHTTP/HTTPS等のアプリケーション応答を検証する場合は、Linuxでcurlのポート番号指定による疎通確認と仕組みにて詳細手順を公開しています。

疎通確認で「分かること」と「分からないこと」

疎通確認を実施した際、判明する情報と判定できない情報を整理しておくことが迅速なトラブルシューティングの第一歩です。

分かること：

• 対象IPアドレス/ホスト名へ通信が到達し、応答が返ってくるか（Yes / No）
• パケットの往復時間（RTT：Round Trip Time）と、通信の揺らぎ（レイテンシ）
• 連続送信時におけるパケットロス（データ紛失）の発生率
• 指定したTCPポートが開いているか（Listen状態であるか）

分からないこと：

• 通信が失敗した場合、「どのルーター」「どのネットワーク機器」で遮断されているか
• 通信の途中にどのようなプロバイダや国際回線を経由しているか
• 送信経路と返送経路のどちらでトラブルが起きているか（非対称ルーティング問題の検出）

3. ルート確認とは？通信の「経由経路」を可視化する技術

ルート確認（ルート追跡）とは、自端末から目的地のサーバーまでの間に存在する「すべてのルーター（ホップ）」を順にリストアップし、それぞれの通過ポイントでかかった時間を測定・表示する技術です。

ルート確認の目的とTTL（Time to Live）の仕組み

ルート確認コマンド（WindowsのtracertやLinux/macOSのtraceroute）は、IPパケットのヘッダに含まれる「TTL（Time to Live：生存時間）」フィールドの仕組みを応用しています。

TTLは本来、ネットワーク上でパケットがルーター間を無限にループし続けるのを防ぐための数値です。ルーターを1つ通過（1ホップ）するごとにTTLの値は「1」ずつ減算され、0になった瞬間にそのルーターはパケットを破棄し、送信元へ「ICMP Time Exceeded（時間切れ）」エラーを通知します。

ルート確認ツールは、この挙動を意図的に利用します。

1. 最初のパケットのTTLを「1」に設定して送信 → 最初のルーターでTTLが0になり、1番目のルーターのIPアドレスが判明する。
2. 次のパケットのTTLを「2」に設定して送信 → 2番目のルーターでTTLが0になり、2番目のルーターのIPアドレスが判明する。
3. これをTTLを1ずつ増やしながら目的地に到達するまで繰り返す。

この仕組みにより、まるでバケツリレーのように通過するすべてのルーターのアドレスと応答時間が画面上に表示されます。

ルート確認で「分かること」と「分からないこと」

分かること：

• 目的地に届くまでに経由しているルーターの数（ホップ数）とIPアドレス/ホスト名
• 各中継ポイント（ホップ）における具体的な応答遅延時間（ミリ秒単位）
• 途中で通信が中断している場合、「何番目のルーターまで届き、どこで途切れたか」という障害ポイント
• 社内ネットワーク内部でのボトルネックか、外部のISP（インターネットサービスプロバイダ）回線での遅延かという境界線の特定

分からないこと：

• 相手のWebアプリケーション内部で発生しているプログラムエラー（HTTP 500 Server Errorなど）の原因
• 中継ルーターがセキュリティ設定により「ICMP Time Exceeded」の返答を拒否している場合（「* * *」と表示される）、本当にそこで通信が途絶しているのか、単にルーターが応答を隠蔽しているだけなのかの厳密な識別

4. ネットワーク障害発生時の正しい切り分けフロー

ネットワーク障害が発生した際、「いきなり複雑な確認コマンドを打ち込む」のは効率的ではありません。基本は「疎通確認（広い調査）」から始まり、「ルート確認（絞り込み調査）」へとステップを進めるのが鉄則です。

ステップ1：まず疎通確認で障害の有無と影響範囲を把握する

接続できないトラブルの報告を受けた場合、まずは基本的な疎通確認を実施します。

1. ローカル環境の確認： デフォルトゲートウェイ（ルーター）へpingを実施。通らなければ自室のLANケーブル外しやWi-Fi不具合、PCのIP設定ミス。
2. DNS・パブリック接続の確認： 8.8.8.8などの外部IPへpingを実施後、domain.comなどのドメイン名へpingを実施。IPで通りドメインで通らなければDNS解決障害。
3. 目的ポートの疎通確認： ポート80/443など特定のサービス疎通を確認。TCPポート疎通が失敗する場合、ファイアウォールやセキュリティグループでの拒否が疑われます。

特にAWSやクラウドインフラを利用している場合、セキュリティグループやACLの設定漏れによって特定の通信のみが遮断されるパターンが多く見られます。AWS環境の切り分けノウハウについてはAWSセキュリティグループで疎通確認できない原因と解決策5選をご確認ください。

ステップ2：通信不通時にルート確認を実施し障害箇所を特定する

疎通確認で「ターゲットに届かない」「途中で著しい遅延がある」と分かった段階で、ルート確認コマンドを発行します。

# Windowsの場合
tracert target-server.com

# Linux/macOSの場合
traceroute target-server.com

出力された結果から、次のように診断します。

• 1〜2ホップ目で応答が止まる： 社内LAN、社内ルーター、ファイアウォール機器の不具合
• 3〜5ホップ目（プロバイダ名が含まれるドメイン）で止まる： 契約しているISP（プロバイダ）回線内の障害
• 目的地の直前ホップで止まる： 相手方ネットワークのファイアウォールやクラウドの仮想ネットワーク設定問題

ステップ3：確認結果に基づく適切なアクションと仕様書化

障害箇所が特定できたら、対象機器の管理部門や回線事業者へ迅速に連絡します。また、システム運用や構築プロジェクトにおいては、これらの検証手順を再現可能な標準テストとして仕様書に落とし込んでおくことが極めて重要です。

テスト計画や結果レポートの作成方法については、疎通確認テスト仕様書の書き方とテンプレート｜作成の手順も解説で標準フォーマットを詳しく提示しています。

5. ネットワークトラブル対応・社内問い合わせの効率化とツール選定

ネットワーク障害の調査手順をマスターすることはインフラ担当者にとって不可欠ですが、実際の運用現場では「システムに繋がらない」という社内ユーザーや顧客からの問い合わせが殺到し、技術調査に集中できないケースが多発します。

トラブル発生時の一次問い合わせ対応や障害通知の自動化において、どのような対応体制やAIツールが適しているか、自社の状況に合わせた比較が重要となります。

問い合わせ対応自動化の適正比較表

ネットワーク障害や社内ITサポートの問い合わせ対応を効率化する際、自社の体制によって最適な解決策は異なります。

社内ITヘルプデスクや問い合わせ業務を効率化するソリューション

自社でシステム障害やITインフラに関する一次問合せ対応を自動化・効率化したい場合、株式会社LaruVisona（東京都豊島区）が提供する各種統合AIツールの活用が有効です。

社内マニュアルやFAQ、障害対応フローをPDFやWebサイトURL経由で簡単に学習させられるAIチャットボット（LARUbot）は、最短1分のアカウント作成と約10分の初期設定でWebサイトや社内ポータルに導入可能です。自動応答から必要に応じて人間の担当者へ1:1相談を引き継ぐ運用も可能で、管理者がいつでも介入制御できます。

また、ネットワーク緊急障害時に電話での問い合わせが殺到する課題に対しては、AIが一次応答してご用件や折り返し先を自動受付票にする法人向けAI電話受付サービスAI電話受付 LARU CALLが効果を発揮します。電話会社の転送サービスでそのまま利用でき、不要な営業電話の自動お断り機能や同意に基づく通話録音機能も備えています。

さらに、受託案件や顧客ごとのネットワーク導入管理・ITサポート履歴を一括管理したい場合は顧客・案件管理（CRM/SFA）機能が統合されたLARU Cloudプランが対応し、自社メディアの集客強化を図る場合は月額15,000円からのSEO自動化 LARU SEOオプションを組み合わせることもできます。最新の料金体系については料金プランページよりご確認いただけます。

6. よくある質問（FAQ）

Q1. pingなどの疎通確認が成功するのに、Webブラウザでページが開かないのはなぜですか？

疎通確認（ICMP）が成功していても、Web表示に必要な「TCPポート80/443」の遮断、Webサーバープロセス（NginxやApacheなど）の停止、あるいはSSL/TLS証明書のエラーやプロキシ設定の不備が原因でブラウザ接続が失敗する場合があります。この場合は、`curl -v https://...` や `Test-NetConnection` を用い、アプリケーション層・ポートレベルでの疎通確認を行ってください。

Q2. traceroute（tracert）の実行結果の途中で「* * *」（タイムアウト）が表示されるのは障害ですか？

必ずしも障害ではありません。インターネット上の中継ルーターや企業網の境界ファイアウォールの中には、セキュリティ確保や負荷軽減のために「ICMP Time Exceeded」応答を返さない設定にしている機器が多く存在します。その先のホップで再び正常なIPアドレスと応答時間が表示されて目的地まで到達している場合は、通信経路として正しく機能しています。

Q3. ルート確認と疎通確認はどちらを先に実施すべきですか？

まずは「疎通確認」を優先してください。疎通確認によって「全体として繋がっているか・繋がっていないか」を数秒で判断できます。疎通確認で失敗した際や、通信速度が極端に遅い原因を深掘りしたい段階で初めて「ルート確認」を実行するのが、最も無駄のない障害調査手順です。