こんにちは、かつコーチです。
ここまでTCP/IP、IPアドレス、ポート番号、DNS、HTTP/HTTPSと、通信の要素を一つずつ見てきました。
今回はそれらを一度整理して、通信全体を俯瞰する「地図」にあたるOSI参照モデルを解説します。
「レイヤー3スイッチ」「レイヤー7ファイアウォール」といった言葉を見かけたことがある方は、その「レイヤー」の正体がここでわかります。
OSI参照モデルとは？
郵便物の梱包の階層構造という比喩
引っ越し荷物を送るとき、荷物は何重にも梱包されます。
商品を袋に入れ、緩衝材で包み、ダンボールに詰め、宛名ラベルを貼り、運送会社のトラックに積む、というように役割ごとに層が分かれています。
OSI参照モデル（Open Systems Interconnection、通信の機能を7つの階層に分けて整理した国際標準のモデル）は、これと同じ発想です。
ネットワーク通信を「電気信号を送る層」「宛先を届ける層」「内容を扱う層」というように役割ごとに7つへ分割し、各層が自分の担当だけに専念できるようにしています。
なぜ7階層に分けて考えるのか
もし通信の仕組みが1枚岩だったら、ケーブルの規格が変わるたびにアプリケーションの作り方まで見直す必要が出てきます。
層ごとに役割を分けておけば、物理層のケーブルが光ファイバーから無線に変わっても、上位のアプリケーション層は何も変更せずに済みます。
これは、荷物の梱包方法を変えても、中身の商品自体は変わらないのと同じ考え方です。
こうした階層化の発想のおかげで、私たちは普段HTTPやDNSを扱うときに、電気信号のレベルまで意識せずに開発できています。
7つの階層それぞれの役割
下位層：物理的に届ける仕組み
下位の3階層は、データを物理的に運ぶことを担当します。
| 階層 | 名称 | 郵便物での例え | 主な要素 |
|---|---|---|---|
| 第1層 | 物理層 | トラック・道路そのもの | ケーブル、電気信号 |
| 第2層 | データリンク層 | 同じ地域内での配送 | MACアドレス、スイッチ |
| 第3層 | ネットワーク層 | 住所によるルーティング | IPアドレス、ルーター |
第4回の記事で扱ったIPアドレスは、この第3層（ネットワーク層）の話にあたります。
上位層：内容を扱う仕組み
上位の4階層は、届いたデータの中身を扱うことを担当します。
| 階層 | 名称 | 郵便物での例え | 主な要素 |
|---|---|---|---|
| 第4層 | トランスポート層 | 差出人・受取人の確認 | TCP、UDP、ポート番号 |
| 第5層 | セッション層 | やり取りの継続管理 | 通信の開始・維持・終了 |
| 第6層 | プレゼンテーション層 | 手紙の言語・書式の変換 | 文字コード、暗号化形式 |
| 第7層 | アプリケーション層 | 手紙の中身そのもの | HTTP、DNS、メール |
HTTPやHTTPSは第7層（アプリケーション層）、TCP/UDPやポート番号は第4層（トランスポート層）の話だと整理すると、これまでの記事のつながりが見えてきます。
OSI参照モデルとTCP/IPモデルの関係
実務で使われるのは簡略化されたTCP/IPモデル
実は、実際のインターネット通信で動いているのはOSI参照モデルそのものではなく、TCP/IPモデルという4階層（または5階層）に簡略化したモデルです。
OSI参照モデルの上位3層（アプリケーション・プレゼンテーション・セッション）は、TCP/IPモデルではまとめて「アプリケーション層」として扱われます。
それでもOSI参照モデルが今なお使われ続けているのは、通信を説明したり、問題の切り分けを行ったりする際の共通言語として非常に優れているからです。
「レイヤー〇」という表現の由来
ネットワーク機器の世界で「レイヤー2スイッチ」「レイヤー3スイッチ」と呼ばれるのは、それぞれデータリンク層（第2層）、ネットワーク層（第3層）の情報を使って通信を制御する機器だからです。
同様に「レイヤー7ファイアウォール」は、アプリケーション層（第7層）の内容、つまりHTTPリクエストの中身まで見て制御するファイアウォールを指しています。
よくあるつまずきポイント
「どの層の話か」が噛み合わないすれ違い
以前、インフラ担当者と障害対応の打ち合わせをしていたとき、私は「サイトが表示されない」という現象だけを話していたのに、相手は「ルーティングの問題では」とネットワーク層の話を始め、話が噛み合わなかったことがあります。
原因を整理すると、私が見ていたのはアプリケーション層のエラー画面、相手が疑っていたのはネットワーク層の経路の問題で、そもそも見ている階層がずれていました。
❌Before：「繋がらない」とだけ伝える
→ どの層の問題か分からず、対応の的が絞れない
✅After：「pingは通るがHTTPアクセスだけ失敗する」と伝える
→ 下位層（ネットワーク層）は正常、上位層（アプリケーション層）に問題があると絞り込める
この経験から、障害報告では「どの層までは正常で、どこから異常か」を意識して伝えるようにしています。
応用・一歩先の使い方
トラブルシューティングでの階層思考
OSI参照モデルの階層構造は、トラブルシューティングの際に「下位層から順に確認する」という進め方の土台になります。
ping（ネットワーク層の疎通）→ ポート疎通（トランスポート層）→ HTTPレスポンス（アプリケーション層）というように、下から順番に確認すれば、問題の切り分けが効率的に進みます。
この考え方は、シリーズ最終回のトラブルシューティング編で詳しく扱います。
まとめ
この記事のポイント
- OSI参照モデルは、通信を「郵便物の梱包」のように役割ごとに7階層へ分けた共通の地図
- 下位層（物理・データリンク・ネットワーク）は物理的に届ける役割、上位層（トランスポート〜アプリケーション）は中身を扱う役割
- 実務ではより簡略化されたTCP/IPモデルが動いているが、説明や切り分けの共通言語としてOSI参照モデルが使われる
- 「レイヤー3スイッチ」などの用語は、どの階層の情報を扱う機器かを表している
次に読むべき記事
- TCPとUDPの違い：確実さとスピードのトレードオフ
- pingとtracerouteでネットワークの疎通を調べる
タグ: ネットワーク, 中級者向け, 通信の仕組み