【前回の振り返り】
前回、Tera Termで安全に接続し、ログを取る「証跡の作法」を学びました。

【本連載について】
本連載は、ネットワークエンジニアだけでなく、サーバーエンジニア、クラウドエンジニア、およびネットワーク機器担当など、インフラに関わるすべての職種に共通する「問題解決の思考プロセス」を扱っています。担当領域が違っても、トラブルの切り分けという「共通言語」を身につけることで、トラブルシューティングの精度とスピードが劇的に向上します。

はじめに：なぜこの3つなのか？
障害対応の現場では、「何が原因かわからない」という状態が一番のストレスです。まずはこの3つのツールを使い、障害の範囲を「ネットワークなのか」「DNSなのか」「経路なのか」と切り分けることが、プロとしての第一歩です。

今回からは、ネットワークの状態を読み解くための「コマンド」の実践に入ります。

⚠️ 学習を始める前の前提条件

本連載では、Linuxサーバー上での 「ネットワークコマンドの実行権限」や「環境変数の設定（PATHの追加）」 などは、あらかじめ現場の管理者によって適切に付与・設定されていることを前提として進めます。

もし、解説するコマンドを打っても Command not found（見つかりません）や Permission denied（権限がありません）と表示される場合は、操作ミスではなく権限や環境設定の問題である可能性が高いです。その際は、現場のルールに従って管理者に確認しましょう。

📚 前の記事

→ 【第5回】：「『接続』と『証跡』の作法：インフラ操作の第一歩（Tera Term / SSH）

📚 次の記事

→ 【第7回】：パケットの「通り道」を可視化する（OSI参照モデルの実務的活用）

📚 このシリーズ全体のまとめはこちら

→ 【新卒・未経験向け】NWエンジニア現場デビューへの道【全11回】：記事一覧・重要ポイントまとめ

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. 他連載シリーズへの招待

本記事の内容をさらに深掘りする「思考法」や、現場での「立ち回り」「基礎知識」など、他の連載シリーズは以下の統合ブログにまとめています。

「技術だけでは評価されない」現場で生き残るエンジニア戦略まとめ【全連載ガイド】

（今の自分に必要な「武器」を、全シリーズから逆引きで探せます）

↑ 目次に戻る