【前回の振り返り】
前回は、インフラ全般の共通スキルとして、通信の生死・経路・名前解決を確認するための「三種の神器（Ping / Traceroute / NSLookup）」の読み解き方と、そこからトラブルの原因を推論する方法を学びました。
【本連載について】
本連載は、ネットワークエンジニアだけでなく、サーバーエンジニア、クラウドエンジニア、および設計・構築を担うすべてのインフラエンジニアに向けた 「問題解決の共通思考プロセス」 を扱っています。OSI参照モデルは、どの領域のエンジニアであっても「システムで何が起きているか」を論理的に説明し、責任境界を明確にするための 「インフラエンジニアの共通言語」 です。
📚 前の記事
📚 次の記事
📚 このシリーズ全体のまとめはこちら
→ 【新卒・未経験向け】NWエンジニア現場デビューへの道【全11回】：記事一覧・重要ポイントまとめ
📋 目次
- はじめに：なぜOSI参照モデルを「現場」で使うのか？
- 教科書と現場の「OSI参照モデル」の決定的な違い
- レイヤー別「ここを疑え」の優先順位（実務編））：名前解決の検証
- 「Pingは通るのにアプリが使えない」を解剖する
- まとめ：境界線を越えて「共通言語」を持つ
- 次回予告
- 連載一覧：【新卒・未経験向け】NWエンジニア現場デビューへの道
- 他連載シリーズへの招待
1. はじめに：なぜOSI参照モデルを「現場」で使うのか？
「Pingは通るのに、なぜWebページが見られないのか？」「設計した通りに構築したのに、なぜ通信が疎通しないのか？」——。この謎を解くとき、私たちは無意識のうちにOSI参照モデルを使い、問題をレイヤーごとに切り分けています。
「トラブルシューティング」と聞くと、運用現場だけの話に聞こえるかもしれません。しかし、優れた設計・構築者ほど、システム完成後の『運用と障害対応の姿』を設計段階で論理的に可視化できています。
OSI参照モデルを現場の武器として使いこなすことは、ネットワークエンジニアに丸投げするのではなく、 自らの領域（サーバー・クラウド・ネットワーク）で何が起きているかを正確に特定し、強固なシステムを構築するための「必須の設計・構築スキル」なのです。
2. 教科書と現場の「OSI参照モデル」の決定的な違い
教科書では「L1は物理層、L2はデータリンク層…」と下から順に積み上げますが、現場でのトラブルシューティングおよび設計検証においては 「上から下へ、あるいは切り分けやすいところから」 アプローチします。
- アプリ（L7）が動かないとき、本当にレイヤー4（ポート）まで届いているか？
- 設計した論理経路において、L3（ネットワーク層）でパケットが廃棄されるリスクはないか？
このように、OSI参照モデルを「どこに注目し、何を確認すべきか」という優先順位を決めるための共通の物差しとして使いこなすことが、早期解決と堅牢なシステム構築への最短ルートです。
3. レイヤー別「ここを疑え」の優先順位（実務編）
現象から「どのレイヤーが怪しいか」をあたりを付け、漫然とした調査や設計上の考慮漏れを避けます。
| レイヤー | 確認ポイント（実務編） |
|---|---|
| L1（物理層） | 物理的な断線、光ケーブルの汚れ、リンクアップ（ランプ点灯）状態。 |
| L2（データリンク層） | MACアドレス学習、VLAN設定、仮想スイッチ上のポート設定。 |
| L3（ネットワーク層） | IP到達性（Ping）、ルーティングテーブルの経路情報。 |
| L4（トランスポート層） | FW/Security GroupのACL設定、サービスがリッスンしているポート番号。 |
4. 「Pingは通るのにアプリが使えない」を解剖する
インフラ現場で最も多いのが「L3までは正常だが、それ以上で詰まっている」という事象です。これを「ネットワークエンジニアのせいだ」と即断せず、レイヤーの境界線で議論できることがプロのエンジニアの証明です。
-
L4（ポート番号）の問題か？
- FWやセキュリティグループでTCP 80/443などの必要なポートが開いているか。
-
L7（アプリ設定）の問題か？
- サーバー側でプロセスが正しく起動し、対象のポートをリッスン（バインド）しているか。
この境界線を論理的に切り分けることで、構築ミスか、運用設定か、外部要因かを明確に指摘できるようになります。
5. まとめ：境界線を越えて「共通言語」を持つ
OSI参照モデルを共通言語として持っていれば、インフラに関わるあらゆる職種が同じ地図を見ながら議論できます。「L3までは届いているので、L4のファイアウォールの設定を一緒に確認しませんか？」というやり取りは、運用の現場だけでなく、設計レビューや構築時の検証においても非常に建設的です。
エンジニアとしての技術力とは、個別のコマンドを打つ力だけではなく、この「パケットの通り道」を可視化し、職種という壁を越えて関係者全員で原因へ辿り着く力のことなのです。
6. 次回予告
レイヤーの切り分けができるようになったら、次は「設定変更」の番です。いかなる環境でも失敗を許されないのがインフラの厳しいところ。次回は、構築・運用作業すべてに通じる「安全装置」の概念を解説します。
第8回：実機操作の「安全装置」とロールバック
「もし通信が切れたらどう戻すか」。作業計画に必ず盛り込むべき「切り戻し」の作法を学びます。お楽しみに！
📚 前の記事
📚 次の記事
📚 このシリーズ全体のまとめはこちら
→ 【新卒・未経験向け】NWエンジニア現場デビューへの道【全11回】：記事一覧・重要ポイントまとめ
7. 連載一覧：【新卒・未経験向け】NWエンジニア現場デビューへの道
| 回数とタイトル | 内容（概要） |
|---|---|
| 第0回：IT業界の地図を読み解く | インフラエンジニアが活躍するフィールドの全体像を把握する。 |
| 第1回：組織という「面」で動く（組織図とステークホルダー） | 現場は一人では回らない。周囲との関係性とチームプレーの重要性。 |
| 第2回：技術より先に身につけるべき「現場サバイバル術」 | 「報・連・相」の型と、周囲から信頼されるための振る舞い方。 |
| 第3回：ログイン前に「情報の地図」を揃える：設計書と業務の全体像 | 実機を触る前に把握すべき、ドキュメントの読み方と業務分類。 |
| 第4回：実作業の極意：地雷を避け、道を整備するエンジニアの作法 | 作業の正確性を担保し、次へ繋げるためのドキュメントメンテナンス術。 |
| 第5回：「接続」と「証跡」の作法：インフラ操作の第一歩（Tera Term / SSH） | プロの「初期設定」を学び、確かな裏付け（エビデンス）を残す準備を整える。 |
| 第6回：インフラエンジニアの「三種の神器」（Ping / Traceroute / NSLookup） | 特定のOSに依存しない、通信の生死と経路、名前解決を確認する技術。単に打つだけでなく、「結果から何が言えるか」を読み解く力。 |
| 第7回：パケットの「通り道」を可視化する（OSI参照モデルの実務的活用） | 教科書上の知識ではなく、現場で「どこで止まっているか」をL1〜L4のレイヤーで迅速に切り分ける思考プロセス。 |
| 第8回：実機操作の「安全装置」とロールバック | 設定変更における共通の作法。バックアップ、投入前の差分確認（diff）、そして「もし通信が切れたらどう戻すか」の計画策定。 |
| 第9回：現場で信頼される「エビデンス」と報告の技術 | 「動きました」ではなく、何を根拠に正常と判断したのか。第三者が納得する作業報告書の書き方。 |
| 第10回：【最終回】「点」を「線」にする：自走し続けるための学習術 | 現場デビューは通過点。実務から得た知識を、どうやって汎用的な技術（資格や深い理論）へ昇華させていくか。 |
📚8. 他連載シリーズへの招待
本記事の内容をさらに深掘りする「思考法」や、現場での「立ち回り」「基礎知識」など、他の連載シリーズは以下の統合ブログにまとめています。
「技術だけでは評価されない」現場で生き残るエンジニア戦略まとめ【全連載ガイド】
（今の自分に必要な「武器」を、全シリーズから逆引きで探せます）