ネットワークが遅いとき、この記事で分かること

ネットワーク接続が遅いと感じたとき、多くの現場では「回線が混んでいるのかな」で片づけられがちです。しかし実際には、どこで遅くなっているかで確認すべきポイントはまったく変わります。端末の問題なのか、Wi-Fi品質なのか、DNSなのか、デフォルトゲートウェイまでのローカル区間なのか、社内LANなのか、インターネット回線なのか、ファイアウォールやL3機器の負荷なのかを、順番に切り分けないと原因にはたどり着けません。

この記事では、現場でそのまま使えるように、「何から確認し、どのコマンドを打ち、出力のどこを見て、次にどこへ進むか」を具体的に整理します。単に原因候補を並べるのではなく、結果に応じて次の確認先が分かる構成にしています。

対象としているのは、主に次のようなケースです。

  • Webページの表示が遅い
  • 社内システムだけ遅い
  • VPN接続時だけ遅い
  • ファイルコピーが遅い
  • Wi-Fi利用時だけ遅い
  • 特定端末だけ遅い、または拠点全体で遅い

また、Windows端末での切り分けに加え、ネットワーク機器側では Cisco IOS 系スイッチ・ルータ、FortiGate の確認コマンドも載せています。

まず結論｜遅いときはこの順番で確認すると迷いにくい

ネットワーク障害の切り分けは、いきなり機器ログや設定変更に入るより、影響範囲が小さい場所から順番に確認する方が早いです。まずは「利用者の端末から見える事実」を押さえ、その後に共有部分へ進みます。

順番 確認ポイント 何を見るか 主なコマンド例 次に進む判断
1 影響範囲 自分だけか、複数人か、拠点全体か 聞き取り、別端末確認 自分だけなら端末優先、複数なら共有区間へ
2 接続方式 Wi-Fiだけ遅いか、有線でも遅いか 有線接続に切替、Wi-Fi情報確認 Wi-Fi限定なら無線品質を疑う
3 IP設定 IP、GW、DNS、DHCP状態 ipconfig /all 誤設定なら端末側修正
4 ローカル区間 デフォルトGWまで安定しているか ping GW -n 20 ここで不安定なら端末〜L2区間
5 名前解決 URLだけ遅いか、DNS応答が遅いか nslookup DNSだけ遅いならDNS系へ
6 外部到達性 社外IPへの遅延、ロス、経路 ping 8.8.8.8、tracert 遅くなる地点を特定
7 機器側 speed/duplex、CRC、drop、CPU、帯域 show interfaces、FortiGate各種 物理不良か輻輳かを切り分け
8 継続観測 時間帯依存、瞬断、定期的悪化 ping -t、監視グラフ 断続障害や混雑時間帯を確認

この順番が大事なのは、遠回りを避けられるからです。現場では、回線障害そのものより、Wi-Fiの混雑、特定端末の設定不備、DNS遅延、インターフェースエラー、帯域使い切りの方が多く発生します。

最初にやるべきこと｜「遅い」の意味を具体化する

「ネットワークが遅い」という報告は、そのままでは曖昧すぎます。ここを具体化しないと、確認先を誤ります。

どの動作が遅いのかを言葉にする

まずは何が遅いのかを分けます。

症状 疑うポイント 最初に確認すべきこと
Webページの最初の表示だけ遅い DNS、プロキシ、認証、SSLハンドシェイク nslookup、ブラウザのプロキシ設定、名前解決時間
開いた後の表示やダウンロードが遅い 帯域不足、WAN混雑、サーバー応答 ping、速度、IF利用率
ファイルコピーが遅い LAN帯域、NIC速度低下、SMB、サーバー側負荷 有線/Wi-Fi比較、リンク速度、CRC
社内サイトだけ遅い 社内経路、FW、社内DNS、サーバー側 社内宛ping、tracert、サーバー負荷確認
VPN接続後だけ遅い トンネル経路、MTU、VPN装置負荷、スプリットトンネル VPN有無で比較、FortiGate負荷、経路確認
全部遅い ローカル区間、回線、FW、広域障害 GW ping、複数端末確認、共有部分の確認

たとえば、「最初だけ遅い」ならDNS待ちや認証待ちを疑います。「転送中ずっと遅い」なら、帯域不足や物理エラー、再送の可能性が上がります。

影響範囲を先に確認する

次に大事なのが、自分だけか、複数人かです。

  • 自分のPCだけ遅い → 端末、Wi-Fi、NIC、OS、セキュリティソフトを優先
  • 同じ島の人が遅い → 同一AP、同一スイッチ、同一VLANを優先
  • 拠点全体で遅い → WAN、FW、L3、回線を優先
  • 特定サービスだけ遅い → サーバー、DNS、アプリ、ポリシーを優先

ここを飛ばすと、「1台の不具合なのに回線を疑う」「拠点障害なのに端末設定ばかり見る」といった無駄が起きます。

端末側で最初に確認するコマンドと見る場所

まずは端末から事実を取ります。端末側の情報が曖昧なままネットワーク機器を見始めると、切り分けに時間がかかります。

1. IP設定が正しいか確認する

Windowsならまずこれです。

ipconfig /all

見るべきポイントは次の通りです。

項目 見るポイント 異常時の例
IPv4 Address 想定セグメントか 169.254.x.x なら DHCP取得失敗
Subnet Mask 設計通りか マスク誤りで近隣通信が不安定
Default Gateway 正しいGWが入っているか 誤GWで外部だけ遅い・不達
DNS Servers 古いDNS、誤ったDNSでないか 名前解決だけ遅い
DHCP Enabled 運用方針と合っているか 本来DHCPなのに固定IP化
Lease Obtained/Expires DHCP更新に異常がないか 頻繁な再取得で断続障害

IPが入っているだけでは正常とは言えません。 ゲートウェイやDNSがズレているだけでも、「つながるけれど遅い」「一部だけ遅い」が起きます。

2. NICの状態とリンク速度を確認する

Windowsではアダプター情報も確認しておくと役立ちます。

Get-NetAdapter | Format-Table -Auto Name, Status, LinkSpeed, MacAddress

見るべき点は Status と LinkSpeed です。想定が 1 Gbps の有線接続なのに 100 Mbps で上がっていれば、体感差は大きくなります。

よくある原因は次の通りです。

  • LANケーブル不良
  • 対向ポートの自動ネゴシエーション失敗
  • ドッキングステーション不具合
  • USB-LANアダプタの相性問題

3. デフォルトゲートウェイまでの応答を見る

近いところから順に確認するのが基本です。まずはデフォルトゲートウェイへ ping を打ちます。

ping 192.168.1.1 -n 20

見るべきポイントは次の3つです。

  • 平均応答時間
  • 最大値の跳ね方
  • ロスの有無
結果例 考えられること 次の確認先
1ms前後で安定、ロスなし 端末〜GWのローカル区間は概ね正常 DNS、上位経路、外部へ進む
数十ms、ばらつき大 Wi-Fi品質、ローカル輻輳、端末負荷 Wi-Fi情報、NIC、AP、L2機器
タイムアウト混在 無線品質悪化、物理不良、L2障害 ケーブル、AP、ポートエラー確認

有線LANで同一セグメントのGWに対してロスが出るなら、正常とは言えません。外部を見る前にローカル区間を優先して疑うべきです。

4. DNS が遅いのかを見分ける

URLでは遅いのに、IP指定では速い場合、DNSが怪しいです。

nslookup example.com

見るべきポイントは次の通りです。

  • どの DNS サーバーに問い合わせているか
  • 応答まで妙に時間がかかっていないか
  • タイムアウトや別DNSへのフォールバックが起きていないか

さらに、複数回実行して揺れがあるかも見ます。

nslookup example.com 192.168.1.53
nslookup example.com 8.8.8.8

社内DNSだけ遅く、外部DNSでは速いなら、回線速度ではなく DNSサーバーまたは社内到達経路 の問題が濃くなります。

5. ARP と近隣解決の異常がないか確認する

同一セグメント通信が不安定なときは、ARP の不整合も疑います。

arp -a

見るべき点は、デフォルトゲートウェイの MAC アドレスが頻繁に変わっていないか、意図しないアドレスに解決していないかです。通常は大きく問題になる場面は多くありませんが、重複IPやL2ループ、誤接続があると変な振る舞いを見せます。

どこから遅くなるかを調べるコマンド

端末設定に大きな異常がなければ、次は「どこから遅くなるのか」を見ます。近い場所から段階的に確認し、悪化する地点を絞ります。

1. ping は単発で終わらせない

1回だけの ping では判断しにくいです。最低でも 10〜20 回、できれば時間帯を変えて複数回確認します。

ping 8.8.8.8 -n 20

見るべきポイントは、平均値だけではありません。

  • 最大値が大きく跳ねていないか
  • 途中でタイムアウトが混ざらないか
  • 時間帯によって悪化しないか

平均 10ms でも、たまに 300ms が混ざるなら、利用者体感は「遅い」「不安定」になります。

2. 経路上のどこで悪化するかを見る

Windowsなら tracert を使います。

tracert 8.8.8.8

見るべきポイントは、どのホップから遅延が増え、その後も遅いままかです。

ここは誤解が多いところです。途中の1ホップだけが遅く見えても、その後のホップが普通なら、その機器が ICMP 応答を低優先にしているだけ の可能性があります。つまり、

  • ある1ホップだけ遅い → そのホップの見え方の問題かもしれない
  • そのホップ以降ずっと遅い → その地点か、その直後が怪しい

この見方をしないと、誤って無関係な中継装置を疑ってしまいます。

3. パスの揺れや断続障害を拾う

一瞬だけ遅い、時間帯だけ遅い、という問題は単発確認だと見逃します。

ping 192.168.1.1 -t

数分〜数十分流して、次を見ます。

  • 一定間隔で Reply time が跳ねるか
  • Request timed out が混ざるか
  • 利用者が「重い」と感じる時間帯に一致するか

たとえば昼休みだけ遅いなら、回線混雑やAP収容過多の可能性が高くなります。常時不安定なら、帯域より物理・設定・装置負荷を疑いやすいです。

Wi-Fiか有線かで見る場所は大きく変わる

「ネットが遅い」の原因として非常に多いのが Wi-Fi です。ここを有線LANと同じ感覚で見てしまうと、原因を外しやすくなります。

Wi-Fiで必ず見るべき項目

確認項目 見るポイント 異常の例 対処の方向
受信強度 電波が弱すぎないか 席が遠い、壁や棚で減衰 場所変更、AP増設
周波数帯 2.4GHz/5GHz のどちらか 2.4GHz で周辺干渉が多い 5GHz 優先、チャネル設計
リンク速度 極端に低くないか 接続速度が数十Mbpsまで低下 電波改善、端末設定確認
AP収容数 同一APに集中していないか 会議室利用時だけ遅い AP分散、設計見直し
ローミング 不適切なAPに張り付き続けないか 遠いAPのままで速度低下 再接続、無線設計調整

Windows で Wi-Fi 情報を見るなら次も使えます。

netsh wlan show interfaces

見るべきポイントは次の通りです。

  • SSID：意図したネットワークに接続しているか
  • Radio type：802.11ac/ax など想定通りか
  • Signal：低すぎないか
  • Receive rate / Transmit rate：極端に低くないか
  • Channel：混雑しやすい帯域に偏っていないか

切り分けとして強いのは、同じ場所で有線に切り替えて速くなるかを見ることです。有線で正常なら、回線や上位ルータではなく、無線区間の可能性が高くなります。

有線で見るべき項目

有線なら、主に次を確認します。

  • リンク速度が 1G/10G で上がっているか
  • duplex 不一致がないか
  • CRC や input errors が出ていないか
  • ケーブルやドッキングステーションに問題がないか

古い環境では今でも 100Mbps でリンクアップ していたり、対向と速度交渉がうまくいっていない例があります。特に「昨日まで速かったのに今日から遅い」場合、物理交換直後のトラブルも疑います。

Linux/macOS での基本確認コマンド

現場によっては Windows 以外の端末もあります。最低限の見方をそろえておくと便利です。

目的 Linux例 macOS例 見るポイント
IP確認 ip addr / ip route ifconfig / netstat -rn IP、GW、DNS
GW到達確認 ping -c 20 192.168.1.1 ping -c 20 192.168.1.1 遅延、ロス、揺れ
経路確認 traceroute 8.8.8.8 / tracepath traceroute 8.8.8.8 どこから悪化するか
DNS確認 dig example.com dig example.com Query time、利用DNS

たとえば Linux/macOS の DNS 確認なら、Query time が分かりやすいです。

dig example.com

;; Query time: 12 msec

数ms〜数十ms程度で安定していれば大きな問題は出にくいですが、毎回数百ms〜秒単位なら DNS 側の確認が必要です。

Cisco機器で確認するコマンドとチェックポイント

端末側でローカル区間や機器側が怪しいと見えたら、次はスイッチやルータを見ます。重要なのは、link up しているかだけでは不十分で、速度・duplex・エラー・ドロップ・帯域をセットで確認することです。

1. ポート状態を一覧で見る

show interfaces status

見るべきポイントは、対象ポートの status、speed、duplex です。

見え方 意味 疑うこと
connected / a-full / a-1000 1G 全二重で正常寄り 次はエラーと帯域を見る
connected / a-full / a-100 100Mでリンクアップ ケーブル品質、ネゴ失敗、対向機器
notconnect 物理リンクなし ケーブル抜け、ポート障害
err-disabled 保護機能により停止 BPDU Guard、Port Security など

2. 個別インターフェースの詳細を見る

show interfaces gigabitEthernet 1/0/10

このコマンドで特に見るべき項目は次です。

  • input errors
  • CRC
  • frame
  • giants / runts
  • output drops
  • input queue / output queue
  • 5 minute input rate / output rate
  • Last input / output

判断の目安は以下です。

項目 増えていたら何を疑うか よくある原因
CRC 物理品質不良 ケーブル不良、SFP不良、ノイズ
input errors 受信側エラー全般 物理不良、相性、速度問題
output drops 輻輳、バッファ不足 帯域不足、バーストトラフィック
5 minute rate が高い 帯域使い切りに近い 大容量転送、バックアップ、更新配布

リンクアップしているから物理的に正常という判断は危険です。CRC が増え続けていれば、実際には再送や遅延の原因になります。

3. エラーを一覧で素早く確認する

show interfaces counters errors

特定ポートだけエラーが多いなら、端末側ケーブルや NIC 周辺を疑いやすいです。複数ポートで同時に増えているなら、上位装置、モジュール、環境要因も視野に入ります。

4. CPU負荷を見る

show processes cpu sorted

見るべきポイントは、CPU が高止まりしていないか、特定プロセスが異常に高くないかです。CPU が張り付くと、管理応答や制御プレーン処理に影響します。ただし、CPU 高騰だけでデータプレーン全体の遅延と決めつけないことも大切です。インターフェース輻輳やエラーとセットで判断します。

5. 経路やARPの確認も必要な場合がある

特定宛先だけ遅い・到達不安定な場合は、ルーティングやARPも確認対象です。

show ip route 10.10.10.10
show arp | include 192.168.1.10

見るべき点は、想定外のネクストホップになっていないか、ARP が揺れていないかです。経路変更が起きると、普段より遠回りになって遅延が増えることがあります。

FortiGateで遅さを確認するときの見方

FortiGate 配下で「社内も外も遅い」「VPNだけ遅い」「特定通信だけ遅い」という場合は、インターフェース状態、装置負荷、セッション、ポリシー通過、VPN状態を見ます。

1. インターフェースの物理状態

get system interface physical

見るべきポイントは、対象インターフェースの status、speed、duplex です。想定が 1G/Full なのに 100M で上がっていれば、その区間がボトルネックになりえます。

2. NIC のエラーやドロップを見る

diagnose hardware deviceinfo nic port1

見るべき点は、CRC や drop 系のカウンタです。これらが増えているなら、FW の前後どちらかに物理品質や輻輳の問題がある可能性があります。

3. 装置負荷の確認

get system performance status

特に見るべきは次の項目です。

  • CPU states
  • Memory
  • Session count
  • NPU offload が効いている前提との差

CPU 使用率が高く、セッション数も普段より急増しているなら、装置負荷の影響を考えます。ただし、セッション数が多いだけで即異常ではありません。平常時と比較して増えているかが重要です。

4. セッションの流れを確認する

特定通信だけ遅いときは、その通信が想定どおりに流れているかを見ます。

diagnose sys session filter src 192.168.1.10
diagnose sys session list

見るべきポイントは、対象通信がどのインターフェースを通っているか、NAT が想定通りか、セッションが安定して存在しているかです。セッションが頻繁に張り直されているなら、上流不安定、タイムアウト、アプリ再接続などを疑います。

5. ポリシーやフローデバッグで詰まりを確認する

許可されているはずの通信で遅延や再接続が疑われる場合は、フローデバッグも有効です。

diagnose debug reset
diagnose debug flow filter addr 192.168.1.10
diagnose debug flow show console enable
diagnose debug enable
diagnose debug flow trace start 20

見るべきポイントは、どのポリシーにマッチしたか、deny が出ていないか、逆引き経路が想定通りかです。長時間の debug は負荷やログ量に注意し、必要最小限で使います。

6. VPNだけ遅いときに見るべきこと

VPN 利用時だけ遅いなら、次の切り分けが重要です。

症状 疑うポイント 確認例
VPN接続後、全通信が遅い フルトンネル、WAN帯域、FW負荷 ルーティング、FW CPU、トンネル先帯域
特定アプリだけ遅い MTU、MSS、アプリの再送 大きいパケットで失敗しないか
時間帯だけ遅い 同時接続数増加、VPN装置混雑 Session/CPU/帯域推移

VPN では MTU/MSS 不整合も地味に効きます。Web は見えるがファイル転送や特定アプリだけ遅い場合、この観点も必要です。

帯域不足と物理エラーをどう見分けるか

「遅い」という体感は似ていても、帯域不足と物理エラーでは見え方が違います。ここを混同すると、回線増速すべきなのにケーブル交換を続けたり、その逆が起きます。

比較項目 帯域不足 物理エラー
発生タイミング 特定時間帯に偏りやすい 常時または断続的
ping 混雑時に遅延増加 ロス、揺れ、タイムアウト
インターフェース rate高い、drop増加 CRC、input errors増加
利用者体感 時間帯依存で遅い いつでも不安定、たまに切れる
主な対処 QoS、通信量分析、増速 ケーブル、SFP、ポート交換

たとえば、昼休みだけ rate が張り付いて output drops が増えるなら帯域不足寄りです。一方で、深夜でも CRC が増え続けているなら、混雑ではなく物理問題を優先すべきです。

実際の切り分け例｜この結果なら次はここを見る

ここでは、現場で起きやすいパターンを具体的に示します。

例1：Wi-Fi利用時だけWebが遅い

  • 有線だと正常
  • GW ping が Wi-Fi 時だけ 1ms〜80ms で揺れる
  • netsh wlan show interfaces で Signal が低い、接続速度も低下

判断： 回線やDNSより、無線品質が本命です。AP の過密、電波弱化、干渉、遠い AP への張り付きが疑わしいです。

次に見ること： AP収容数、チャネル、配置、5GHz利用状況。

例2：URLだけ遅く、IP直打ちは速い

  • ping 8.8.8.8 は安定
  • nslookup example.com が毎回数秒かかる
  • 参照DNSが古いサーバーを向いている

判断： 通信速度ではなく DNS 問題です。

次に見ること： DNS サーバーの到達性、応答時間、端末の DNS 設定、DNS フォワーダ、上位DNS。

例3：拠点全体で昼だけ遅い

  • 複数ユーザー同時発生
  • GW までは正常
  • WAN側IFの 5 minute rate が回線上限近い
  • output drops が増える

判断： WAN 帯域不足または特定通信の集中です。

次に見ること： トラフィック内訳、バックアップ、クラウド同期、動画視聴、QoS、増速検討。

例4：1台だけ常に遅い

  • 同じ島の他PCは正常
  • そのPCだけリンク速度が100Mbps
  • スイッチポートに CRC が増えている

判断： 端末側ケーブル、NIC、ドックが本命です。

次に見ること： ケーブル交換、別ポート接続、ドックを外す、NICドライバ更新。

例5：VPN接続時だけファイル転送が極端に遅い

  • Web閲覧はそこまで問題ない
  • 大きなファイルだけ遅い
  • VPN装置負荷は高くない

判断： MTU/MSS、再送、アプリ特性を疑います。

次に見ること： PMTU、TCP MSS 調整、VPN 経路、アプリ側再送ログ。

よくある勘違いと、判断を誤りやすいポイント

speed testだけで判断しない

インターネット速度測定サイトの結果は、あくまで特定条件での対外通信の一例です。社内システムが遅いのに speed test だけ速いなら、WAN 回線ではなく、社内経路、DNS、FW、サーバー側の問題を疑うべきです。

pingが通る＝正常ではない

ping が返るだけでは正常とは言えません。平均値、最大値、ロス、揺れ、時間帯依存を見ないと、実利用に近い判断はできません。

途中ホップが遅い＝そこが犯人、とは限らない

tracert は便利ですが、ICMP 応答の優先度差に惑わされやすいです。そのホップ以降も遅いかを必ず見てください。

1台だけ遅いのに回線障害を疑う

現場で非常に多い誤りです。1台だけ遅いなら、まず端末・NIC・Wi-Fi・セキュリティソフト・VPNクライアントを疑うべきです。

リンクアップしているからポート正常、は危険

リンクアップは最低条件でしかありません。速度低下、duplex 不一致、CRC、drop を見ないと不十分です。

現場で使いやすいチェックリスト

実務では、毎回同じ順番で見るだけで判断ミスが減ります。以下をそのままチェックリストとして使えます。

No. 確認内容 コマンド例 見るポイント
1 何が遅いかを特定 聞き取り Web、VPN、ファイル、社内限定か
2 影響範囲を確認 別端末確認 自分だけか複数人か
3 Wi-Fi/有線を切り分け 有線接続に変更 Wi-Fiだけ遅いか
4 IP/GW/DNS確認 ipconfig /all 誤設定、古いDNS、169.254
5 NIC速度確認 Get-NetAdapter 1G想定なのに100Mでないか
6 GW疎通確認 ping GW -n 20 ロス、揺れ、局所遅延
7 DNS確認 nslookup 応答遅延、参照DNS
8 外部IP確認 ping 8.8.8.8 -n 20 外部だけ遅いか
9 経路確認 tracert 8.8.8.8 どこから遅くなるか
10 スイッチ/FW確認 show interfaces / FortiGate各種 speed、duplex、CRC、drop、CPU
11 時間帯依存を確認 ping -t、監視グラフ 混雑、断続障害、定期発生

実務での最終まとめ

ネットワークが遅いときに本当に大事なのは、原因候補をたくさん暗記することではありません。順番に切り分けて、どこから遅くなっているかを狭めることです。

まずは、

  1. 何が遅いのかを具体化する
  2. 自分だけか複数人かを確認する
  3. Wi-Fiか有線かを分ける
  4. 端末で IP・GW・DNS を確認する
  5. GW、社内、外部の順に ping する
  6. URLだけ遅いなら DNS を見る
  7. 必要に応じて tracert で悪化地点を探す
  8. 機器側で speed/duplex、CRC、drop、rate、CPU を確認する
  9. 帯域不足か物理エラーかを見分ける

この流れで見れば、思いつきで設定を触るリスクを減らせます。

特に重要なのは、コマンドを打つこと自体ではなく、その出力のどこを見るかです。ping なら平均値だけでなく揺れとロス、tracert なら1ホップだけでなく以降も遅いか、show interfaces なら link up だけでなく CRC や drop、5 minute rate を見る。この見方ができるだけで、切り分けの速さはかなり変わります。

現場で毎回迷うなら、この記事の順番をそのままチェックシート化しておくと便利です。同じ手順で確認できれば、見落としや誤判定を減らせます。

関連記事