【前回の振り返り】
前回、Tera Termで安全に接続し、ログを取る「証跡の作法」を学びました。
【本連載について】
本連載は、ネットワークエンジニアだけでなく、サーバーエンジニア、クラウドエンジニア、およびネットワーク機器担当など、インフラに関わるすべての職種に共通する「問題解決の思考プロセス」を扱っています。担当領域が違っても、トラブルの切り分けという「共通言語」を身につけることで、トラブルシューティングの精度とスピードが劇的に向上します。
はじめに：なぜこの3つなのか？
障害対応の現場では、「何が原因かわからない」という状態が一番のストレスです。まずはこの3つのツールを使い、障害の範囲を「ネットワークなのか」「DNSなのか」「経路なのか」と切り分けることが、プロとしての第一歩です。
今回からは、ネットワークの状態を読み解くための「コマンド」の実践に入ります。
⚠️ 学習を始める前の前提条件
本連載では、Linuxサーバー上での 「ネットワークコマンドの実行権限」や「環境変数の設定（PATHの追加）」 などは、あらかじめ現場の管理者によって適切に付与・設定されていることを前提として進めます。
もし、解説するコマンドを打っても Command not found（見つかりません）や Permission denied（権限がありません）と表示される場合は、操作ミスではなく権限や環境設定の問題である可能性が高いです。その際は、現場のルールに従って管理者に確認しましょう。
📚 前の記事
→ 【第5回】：「『接続』と『証跡』の作法：インフラ操作の第一歩（Tera Term / SSH）
📚 次の記事
→ 【第7回】：パケットの「通り道」を可視化する（OSI参照モデルの実務的活用）
📚 このシリーズ全体のまとめはこちら
→ 【新卒・未経験向け】NWエンジニア現場デビューへの道【全11回】：記事一覧・重要ポイントまとめ
📋 目次
- Ping（ピン/ピング）：疎通の第一歩
- Traceroute（トレースルート）：経路の可視化
- NSLookup（エヌエスルックアップ）：名前解決の検証
- まとめ：結果から「推論」する
- 次回予告
- 連載一覧：【新卒・未経験向け】NWエンジニア現場デビューへの道
- 他連載シリーズへの招待
1. Ping（ピン/ピング）：疎通の第一歩
相手の機器までパケットが届き、戻ってきているかを確認する「山びこ」のようなコマンドです。
実行例：
ping -c 4 8.8.8.8
出力結果の読み解き方：
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=12.3 ms
ここを見る： time=12.3 ms（応答速度）。ここが100msを超えていたり、数値に大きなバラつきがある場合は、ネットワークの混雑や経路の不安定さを疑います。
異常時の例（Time Out）：
Request timeout for icmp_seq 1
ここを見る： 相手がダウンしているか、途中のファイアウォール（FW）等で遮断されています。
2. Traceroute（トレースルート）：経路の可視化
目的地にたどり着くまでに、どのルータ（ホップ）を経由しているかを追跡します。
実行例：
traceroute 8.8.8.8
出力結果の読み解き方：
1 192.168.1.1 (192.168.1.1) 1.125 ms
2 10.0.0.1 (10.0.0.1) 5.421 ms
3 * * *
ここを見る： * * *（アスタリスク）。ここで通信が途切れています。この一歩手前の「2」の機器までは届いている、という切り分けができます。
3. NSLookup（エヌエスルックアップ）：名前解決の検証
ドメイン名（URLなど）とIPアドレスの紐付けが正しく行われているかを確認します。
実行例：
nslookup google.com
出力結果の読み解き方：
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: google.com
Address: 172.217.161.238
ここを見る： Server。自分が**「どのDNSサーバー」**に聞きに行っているかを確認します。意図しないサーバーを参照していて失敗するケースは、実務において非常に多いです。
4. まとめ：結果から「推論」する
単にコマンドを打つのではなく、複数の結果を組み合わせて原因を絞り込みます。
-
Pingが通らない ＋ Tracerouteが途中で止まる
＝ 経路（ルータ等）の問題 -
Pingが通らない ＋ NSLookupも失敗する
＝ 名前解決（DNS）の問題 -
Pingは通る ＋ 特定のアプリだけ動かない
＝ 上位レイヤー（ポート番号やアプリ設定）の問題
5. 次回予告
今回紹介した「三種の神器」を使えば、障害がどこで起きているかの「アタリ」を付けることができます。
しかし、現場ではさらに一歩踏み込んで 「なぜそこがボトルネックになるのか？」 を論理的に説明する力が求められます。そこで次回は、新人エンジニアが最初につまずきやすい「OSI参照モデル」を、教科書上の知識ではなく 「実務でどう使うか」 という視点で徹底解説します。
第7回：パケットの「通り道」を可視化する（OSI参照モデルの実務的活用）
「Pingは通るのに、なぜWebページが見られないのか？」——この謎を解く鍵は、レイヤーの考え方にあります。お楽しみに！
📚 前の記事
→ 【第5回】：「『接続』と『証跡』の作法：インフラ操作の第一歩（Tera Term / SSH）
📚 次の記事
→ 【第7回】：パケットの「通り道」を可視化する（OSI参照モデルの実務的活用）
📚 このシリーズ全体のまとめはこちら
→ 【新卒・未経験向け】NWエンジニア現場デビューへの道【全11回】：記事一覧・重要ポイントまとめ
6. 連載一覧：【新卒・未経験向け】NWエンジニア現場デビューへの道
| 回数とタイトル | 内容（概要） |
|---|---|
| 第0回：IT業界の地図を読み解く | インフラエンジニアが活躍するフィールドの全体像を把握する。 |
| 第1回：組織という「面」で動く（組織図とステークホルダー） | 現場は一人では回らない。周囲との関係性とチームプレーの重要性。 |
| 第2回：技術より先に身につけるべき「現場サバイバル術」 | 「報・連・相」の型と、周囲から信頼されるための振る舞い方。 |
| 第3回：ログイン前に「情報の地図」を揃える：設計書と業務の全体像 | 実機を触る前に把握すべき、ドキュメントの読み方と業務分類。 |
| 第4回：実作業の極意：地雷を避け、道を整備するエンジニアの作法 | 作業の正確性を担保し、次へ繋げるためのドキュメントメンテナンス術。 |
| 第5回：「接続」と「証跡」の作法：インフラ操作の第一歩（Tera Term / SSH） | プロの「初期設定」を学び、確かな裏付け（エビデンス）を残す準備を整える。 |
| 第6回：インフラエンジニアの「三種の神器」（Ping / Traceroute / NSLookup） | 特定のOSに依存しない、通信の生死と経路、名前解決を確認する技術。単に打つだけでなく、「結果から何が言えるか」を読み解く力。 |
| 第7回：パケットの「通り道」を可視化する（OSI参照モデルの実務的活用） | 教科書上の知識ではなく、現場で「どこで止まっているか」をL1〜L4のレイヤーで迅速に切り分ける思考プロセス。 |
| 第8回：実機操作の「安全装置」とロールバック | 設定変更における共通の作法。バックアップ、投入前の差分確認（diff）、そして「もし通信が切れたらどう戻すか」の計画策定。 |
| 第9回：現場で信頼される「エビデンス」と報告の技術 | 「動きました」ではなく、何を根拠に正常と判断したのか。第三者が納得する作業報告書の書き方。 |
| 第10回：【最終回】「点」を「線」にする：自走し続けるための学習術 | 現場デビューは通過点。実務から得た知識を、どうやって汎用的な技術（資格や深い理論）へ昇華させていくか。 |
📚7. 他連載シリーズへの招待
本記事の内容をさらに深掘りする「思考法」や、現場での「立ち回り」「基礎知識」など、他の連載シリーズは以下の統合ブログにまとめています。
「技術だけでは評価されない」現場で生き残るエンジニア戦略まとめ【全連載ガイド】
（今の自分に必要な「武器」を、全シリーズから逆引きで探せます）