OSI 参照モデルは今も学ぶべきか｜現場エンジニアが考える実務での使いどころ

はじめに

ネットワークの学習を始めると、ほぼ例外なく最初に登場するのが OSI 参照モデルです。一方で、実際にインターネットやサーバー間通信で使われているのは TCP/IP であり、現場のプロトコルスタックに OSI の 7 階層がそのまま実装されているわけではありません。このギャップから、「OSI 参照モデルを学ぶ意味はあるのか」「初学者には TCP/IP の 4 階層だけ教えれば十分ではないか」と悩む方は少なくないと思います。筆者自身、後輩や初学者への教育の場面で長らく考えてきたテーマです。

結論を先に述べます。OSI 参照モデルは、通信の実装を説明する「設計図」としては TCP/IP に敗れましたが、障害切り分けや設計議論における「共通言語」としては現在も現役です。したがって、初学者には 7 層の丸暗記ではなく、TCP/IP で通信の仕組みを学びつつ、L1〜L4 と L7 の番号を業界の語彙として身につける学び方をおすすめします。

OSI 参照モデルとは｜7 階層の役割を簡潔に整理

OSI 参照モデル（OSI Basic Reference Model）は、ISO と CCITT（現在の ITU-T）が策定した、通信機能を 7 つの階層に分割して整理するための概念モデルです。1984 年に ISO 7498 および ITU-T 勧告 X.200 として発行されました。重要なのは、これが特定のプロトコルの仕様書ではなく、標準化作業の座標軸として作られた「抽象モデル」だという点です。

参考: ITU-T Recommendation X.200（OSI Basic Reference Model）
“This Reference Model does not specify services and protocols for OSI.”
（この参照モデルは、OSI のサービスおよびプロトコルを規定するものではない）
https://www.itu.int/rec/T-REC-X.200-199407-I/en

つまり X.200 自身が、「このモデルは実装仕様ではない」と明記しています。7 階層を「実在する通信の構造」として覚えてしまうと、この時点で原典の意図からずれてしまいます。

各層の役割（L1〜L7）

各層の役割を一覧で整理します。詳細な解説は入門書に譲り、ここでは実務での関連キーワードを添える形にとどめます。

層	名称	主な役割	実務での関連キーワード
L7	アプリケーション層	アプリケーション間のデータ交換	HTTP、DNS、SMTP
L6	プレゼンテーション層	データ表現形式の変換	文字コード、暗号化（概念上）
L5	セッション層	対話の確立・維持・終了	セッション管理（概念上）
L4	トランスポート層	エンドツーエンドの通信制御	TCP、UDP、ポート番号
L3	ネットワーク層	アドレッシングと経路制御	IP、ルーティング
L2	データリンク層	隣接ノード間の伝送	Ethernet、MAC アドレス、VLAN
L1	物理層	ビットの物理的な伝送	ケーブル、光信号、リンクランプ

L5・L6 に「（概念上）」と付記したのは、後述するとおり、この 2 つの層に 1 対 1 で対応する独立した実装が現代のプロトコルスタックにはほぼ存在しないためです。

OSI プロトコルと OSI 参照モデルは別物

「OSI」という言葉が指すものには、実は 2 つの側面があります。

1 つ目は、ここまで説明してきた 7 階層の参照モデル（抽象モデル） です。2 つ目は、そのモデルに準拠して実際に策定された OSI プロトコル群 です。かつては CLNP（ネットワーク層）や TP4（トランスポート層）、X.400（電子メール）、X.500（ディレクトリサービス）など、TCP/IP に対抗する具体的なプロトコル群が存在していました。

「OSI は使われていない」と言うとき、正確に敗れたのはこの 2 つ目のプロトコル群です。一方で 1 つ目の参照モデルは、TCP/IP が標準となった現在でも、エンジニア同士の会話や設計書、製品カタログ（L2 スイッチ、L4 ロードバランサーなど）の中で使われ続けています。この 2 つを区別することが、「OSI を学ぶべきか」という問いに答える出発点になります。なお、OSI プロトコル群の名残は現在のネットワークにもわずかに残っており、たとえば通信事業者ネットワークで使われるルーティングプロトコルの IS-IS は、もともと OSI プロトコル群（CLNP 環境向け）として設計されたものです。

OSI はなぜ「敗北」したのか｜TCP/IP が標準になった歴史的経緯

1980 年代から 1990 年代前半にかけて、次世代ネットワークの標準の座をめぐって OSI プロトコル群と TCP/IP が競合していました。いわゆる「プロトコル戦争」です。当時は各国政府や通信キャリアが OSI を支持しており、米国政府が政府調達において OSI 準拠を要件とする方針（GOSIP）を掲げた時期もありました。国際標準としての正統性は、むしろ OSI 側にあったと言えます。

プロトコル戦争の結末

それでも TCP/IP が事実上の標準となった要因は、複数の観点から説明できます。

動くコードが先にあった

TCP/IP は ARPANET での運用実績があり、BSD UNIX に実装が同梱されて大学・研究機関に広く配布されていました。OSI プロトコル群は仕様策定が先行し、相互接続可能な実装が出揃うのが遅れました。

仕様のシンプルさ

OSI は多数の選択肢（コネクション型 / コネクションレス型の並立、プロファイルの乱立）を仕様に抱え込み、実装と相互接続性試験の負担が大きくなりました。TCP/IP は「とりあえずつながる」最小限の仕様から出発しています。

標準化プロセスの速度差

IETF の「ラフコンセンサスと動くコード」という文化は、委員会での合意形成を重視する ISO/ITU-T のプロセスと比べて、改善サイクルが速く回りました。

1990 年代半ばにインターネットが商用化・爆発的普及を迎えた時点で、勝敗は事実上決していました。X.400 や CLNP がインターネットの主役になることはなく、OSI プロトコル群は表舞台から退場します。

なお、この「敗北」はプロトコル群についての話であり、参照モデルの概念（階層化、カプセル化、層間インターフェース）は TCP/IP を含むその後のプロトコル設計に深く影響を与えています。前セクションで触れた IS-IS のように、OSI 由来の技術が現在も基幹ネットワークで稼働している例もあります。

L5・L6 に独立した実装がほぼ存在しない理由

7 階層のうち、現代のプロトコルスタックで最も「実体」が見えにくいのがセッション層（L5）とプレゼンテーション層（L6）です。理由は単純で、TCP/IP の世界ではトランスポート層より上の機能をすべてアプリケーション層に含めて設計するためです。セッション管理もデータ表現の変換も、必要ならアプリケーションプロトコル自身が実装します。

• HTTP の Cookie によるセッション管理や、HTTP/2 のストリーム多重化は、OSI 的に見ればセッション層の機能ですが、実装上はアプリケーションプロトコルの一部です。
• 文字コード変換やシリアライズ（JSON、Protocol Buffers 等）はプレゼンテーション層的な機能ですが、これも独立した「層」ではなくライブラリやアプリケーションの実装として存在します。
• TLS は「セッション層 / プレゼンテーション層に相当する」と説明されることがありますが、実際にはトランスポート層とアプリケーション層の間に挿入されるプロトコルであり、OSI の L5・L6 の仕様に準拠した実装ではありません。

つまり L5・L6 は「間違っている」のではなく、TCP/IP の世界では独立した層として切り出す設計上の必然性がなかった、というのが実態に即した理解です。

TCP/IP 4 階層モデルとの対応関係

TCP/IP 側の階層構造を定義する一次情報は、RFC 1122（Requirements for Internet Hosts — Communication Layers）です。ここではリンク層・インターネット層・トランスポート層・アプリケーション層の 4 階層が示されており、この構造は発行から 35 年以上を経た現在も IETF によって変更されていません。

RFC 1122 は、OSI との対応関係についても自ら言及しています。

参考: RFC 1122（Requirements for Internet Hosts — Communication Layers）
“combines the functions of the top two layers — Presentation and Application”
（インターネットスイートのアプリケーション層は、OSI 参照モデルの上位 2 層（プレゼンテーション層とアプリケーション層）の機能を統合したもの、の意）
https://www.rfc-editor.org/rfc/rfc1122.html

4 階層と 7 階層のマッピング

一般的な対応関係を図で整理します。

対応関係で注意したい点が 2 つあります。

上位 3 層（L5〜L7）は TCP/IP ではアプリケーション層 1 つに対応する

これは RFC 1122 自身が明記している公式見解であり、「TLS は L6」「NetBIOS は L5」といった機械的な当てはめは、原典に基づく分類ではありません。

物理層の扱いはモデルによって揺れがある

RFC 1122 のリンク層は物理媒体そのものを詳細に規定しておらず、書籍によっては物理層を独立させた 5 階層モデルで説明される場合もあります。どの教科書を読むかで層の数が違って見えるのは、このためです。

TLS や HTTP/2 に見る「層をまたぐ」現実

実際のプロトコルは、モデルの層にきれいに収まらないことがあります。

TLS

TCP の上、アプリケーションプロトコルの下に挿入されます。暗号化（プレゼンテーション層的機能）とセッション再開（セッション層的機能）を併せ持ち、7 階層のどこか 1 つに割り当てることは困難です。

HTTP/2・HTTP/3

ストリーム多重化やフロー制御といった、従来トランスポート層が担ってきた機能をアプリケーションプロトコル側に取り込んでいます。特に HTTP/3（QUIC）は UDP 上に信頼性制御を再実装しており、「L4 と L7 の境界」を実装レベルで溶かした例と言えます。

VXLAN や GRE などのトンネリング

L2 フレームを L3/L4 の上に載せるため、「下の層が上の層に運ばれる」という、階層モデルの前提と逆転した構造になります。

これらは「モデルが間違っている」ことを示すのではなく、階層モデルはあくまで思考の整理のための地図であり、現実の地形（実装）とは一致しない場合があることを示しています。この距離感を持って付き合うことが、モデルとの健全な関係だと考えます。

それでも OSI が現場で生きる場面｜切り分けの共通言語

OSI プロトコル群は退場しましたが、7 階層の「番号」は現場に深く根を下ろしています。ここが本記事の核心です。OSI 参照モデルの現代における実用価値は、通信の仕組みの説明ではなく、エンジニア同士が問題の所在を短い言葉で共有するための共通言語にあります。

L2 / L3 / L4 / L7 という業界の語彙

製品カタログ、設計書、障害報告、日常の会話。ネットワークに関わる文書とコミュニケーションには、OSI の層番号が語彙として組み込まれています。

製品分類

L2 スイッチ、L3 スイッチ、L4 ロードバランサー、L7 ファイアウォール（WAF）。これらは TCP/IP の 4 階層では区別を表現できません。「リンク層スイッチ」「アプリケーション層ファイアウォール」とは誰も言いません。

設計・要件の議論

「この冗長化は L2 で組むか L3 で組むか」「ヘルスチェックは L4 か L7 か」。方式の選択肢を 1 文字で対比できます。

障害報告・エスカレーション

「L3 までは正常、L4 で落ちている」と伝えれば、受け手は疎通確認済みの範囲と次に見るべき箇所を即座に理解できます。

注意したいのは、ここで使われている番号は L1〜L4 と L7 に事実上限られる点です。「L5 スイッチ」「L6 ファイアウォール」という製品カテゴリは存在しません。現場で流通しているのは 7 層すべてではなく、実装と対応関係が明確な 5 つの番号だけです。この事実自体が、「7 層丸暗記」の必要性への一つの答えになっています。

下から潰す障害切り分けの思考法（実例ベース）

層の番号がもっとも力を発揮するのは障害対応です。「下位層が正常でなければ上位層は動作しない」という階層モデルの原則は、切り分け手順にそのまま変換できます。

「Web サーバーにつながらない」という申告を受けたときの典型的な流れは次のとおりです。

この手順の価値は、調査済みの範囲と未調査の範囲が層の番号で明確に区切られ、チーム間の引き継ぎやベンダーへのエスカレーションで「どこまで確認済みか」を誤解なく伝えられることにあります。

なお、実際の障害対応では、経験を積むと「いきなり L3 の ping から入る」「症状から L7 と当たりを付けて逆から潰す」といったショートカットも使うようになります。それでも、行き詰まったときに立ち返る基本の梯子として、下から潰す手順は有効です。

初学者にどう教えるか｜7 層丸暗記を勧めない学習ロードマップ

ここまでの整理を教育論に落とし込みます。結論は「OSI を教えない」でも「7 層を丸暗記させる」でもなく、役割を分けて両方を教えるです。

通信の仕組みは TCP/IP で学ぶ

パケットがどう作られ、どう運ばれるかという「動作の理解」は、実在するプロトコルで学ぶのが最短です。Ethernet フレーム、IP ヘッダー、TCP/UDP、HTTP という実物のスタックを、パケットキャプチャで実際に観察しながら学べば、階層化とカプセル化の概念は自然に身につきます。存在しない L5・L6 の実装を探して混乱する必要はありません。

番号は「名刺代わり」に覚える

一方で、L1〜L4 と L7 の番号は、業界に入る際の語彙として最初期に覚える価値があります。求人票にも設計書にも障害報告にも登場する、事実上の業界標準語だからです。ポイントは、番号を「暗記項目」ではなく「これから毎日使う道具」として提示することです。前セクションの切り分け手順のように、番号が実際に役立つ文脈とセットで教えれば、丸暗記とは定着度が変わります。

L5・L6 は歴史的経緯として正直に伝える

初学者への教育で最も避けたいのは、「TLS は L6、NetBIOS は L5」といった無理な当てはめを正解として教えることです。本記事で見てきたとおり、これは原典（RFC 1122）の立場とも一致しません。おすすめするのは、次のように正直に伝えることです。

• 7 階層のうち L5・L6 は、OSI プロトコル群と共に構想されたが、TCP/IP の世界では独立した層として実装されなかった。
• 現代のプロトコルでは、その機能はアプリケーション層（および TLS のような中間プロトコル）に溶け込んでいる。
• したがって試験対策としての知識は必要でも、実務で L5・L6 を使って会話する場面はほぼない。

まとめ

OSI 参照モデルは、通信プロトコルの実装仕様としては TCP/IP に敗れましたが、階層構造という考え方そのものは形を変えて生き続けています。現場で本当に価値を持つのは、7 層すべてではなく、製品分類や障害切り分けに使われる一部の番号です。

• OSI 参照モデルは実装仕様ではなく標準化のための抽象モデル
• OSI プロトコル群は TCP/IP との競争に敗れ表舞台から退場した
• TCP/IP の 4 階層は RFC 1122 で規定され現在も変更されていない
• L5 と L6 は独立した実装を持たずアプリケーション層に溶け込む
• L2 から L4 と L7 の番号は現場の設計や障害対応で使われ続ける
• 通信の仕組みは TCP/IP で学び番号は共通言語として身につける
• 教科書と現場の差は L5 と L6 の位置づけを正直に伝えれば埋まる

以上、最後までお読みいただきありがとうございました。