OSI参照モデルは、コンピュータ同士の通信に必要な機能を7つの層に分け、層ごとの役割を定めた国際標準のモデルです。規格はISO/IEC 7498-1で、ITU-TのX.200も同じ内容です。日本では初版をもとにJIS X 5003(1987年)が制定されています。この記事では、7階層の役割と代表プロトコル、データが層を下りるときに付くヘッダ、TCP/IPモデルとの違いを押さえたうえで、層ごとの障害切り分けを実際のコマンド出力で示し、覚え方と試験で問われる点までまとめます。
まとめ:OSI参照モデル7階層の要点
- 7階層は下から物理層・データリンク層・ネットワーク層・トランスポート層・セッション層・プレゼンテーション層・アプリケーション層です。番号はL1〜L7と書きます。
- ISOが1984年にISO 7498として発行し、現行版はISO/IEC 7498-1:1994です。デジュール標準(標準化機関が定めた規格)であり、デファクトスタンダードではありません。
- インターネットで実際に動いているのはTCP/IPで、RFC 1122は層をリンク・インターネット・トランスポート・アプリケーションの4つで説明します。OSIの上位3層はTCP/IPではアプリケーション層1つにまとまります。
- OSIのプロトコル群は普及しませんでしたが、7階層の番号は「L2スイッチ」「L7ロードバランサー」のように機器や障害の位置を伝える共通語として残っています。
- 障害は下の層から順に確かめると早く絞れます。リンク状態→ARP→ping→DNS→TCP接続→TLS→HTTPの順にコマンドを当てる手順を後半で示します。
- 覚え方は上から「アプセトネデブ」(アプリケーション・プレゼンテーション・セッション・トランスポート・ネットワーク・データリンク・物理)が定番です。
以下、規格の位置づけ、各層の役割、カプセル化、TCP/IPとの違い、切り分けの手順の順に根拠を示します。
OSI参照モデルの定義:ISOが定めた通信機能の7階層
規格番号と発行年:ISO/IEC 7498-1・ITU-T X.200・JIS X 5003
OSIはOpen Systems Interconnection(開放型システム間相互接続)の略です。1970年代には各メーカーが独自のネットワーク体系を持ち、他社の機器とはつながりませんでした。そこでISOは、どのメーカーの機器でも相互に通信できるよう、通信機能を層に分けて各層の責任範囲を定めるモデルを作りました。これがISO/IEC 7498-1で、初版のISO 7498は1984年、現行の第2版は1994年の発行です。同じ内容はITU-Tの勧告X.200(1994年7月版)としても出ています。日本では初版のISO 7498:1984に対応するJIS X 5003が1987年に制定されました。「OSI基本参照モデル」という呼び方は、この規格名(Basic Reference Model)の訳に由来し、OSI参照モデルと同じものを指します。
モデルが定めるのは各層の役割と、隣り合う層の間で受け渡す単位です。ある層は直下の層が提供するサービスだけを使い、直上の層にサービスを提供します。この約束があるため、物理層を銅線から光ファイバーに替えても、上の層のソフトウェアは書き換えずに済みます。
OSIプロトコルが普及せず、モデルだけが残った経緯
ISOはモデルと並行して、各層の具体的なプロトコル(OSIプロトコル群)も標準化しました。ところが1990年代にインターネットが広がると、すでに動いていたTCP/IPが事実上の標準になり、OSIプロトコルの製品は広まりませんでした。現在、OSIのプロトコルそのものが使われている場面は、経路制御のIS-ISなど一部に限られます。TLS証明書の形式であるX.509も、OSIのディレクトリ規格(ITU-T X.500シリーズ)から生まれたものです。
それでも7階層の考え方は、ネットワーク機器の分類(L2スイッチ・L3スイッチ)、クラウドの負荷分散(L4/L7)、障害の報告(「L2までは疎通している」)の共通語として使われ続けています。資格試験もこのモデルで出題されます。
7階層それぞれの役割と代表プロトコル
各層の役割、層ごとのデータの呼び名(PDU)、代表的なプロトコルと機器を1枚にまとめます。
| 層 | 名称 | 役割 | データの単位 | 代表プロトコル・機器 |
|---|---|---|---|---|
| L7 | アプリケーション層 | アプリに通信機能を提供 | データ(メッセージ) | HTTP、DNS、SMTP、SSH |
| L6 | プレゼンテーション層 | 表現形式の変換・暗号化 | データ | ASN.1(BER)、MIME |
| L5 | セッション層 | 対話の開始・維持・終了 | データ | NetBIOSセッション、RPC |
| L4 | トランスポート層 | 端末間の信頼性とアプリの識別 | セグメント/データグラム | TCP、UDP、ファイアウォール |
| L3 | ネットワーク層 | 宛先までの経路選択 | パケット | IP、ICMP、ルーター |
| L2 | データリンク層 | 隣接機器へのフレーム転送 | フレーム | Ethernet、Wi-Fi、スイッチ |
| L1 | 物理層 | ビットを電気・光・電波に変換 | ビット | ケーブル、コネクタ、リピーター |
下位の層ほど機器やケーブルといった実体に近く、上位の層ほどアプリケーションの機能に近くなります。以下、実装で境界がはっきりしている下位4層と、まとめて扱われる上位3層に分けて説明します。
物理層とデータリンク層:隣の機器までビットとフレームを届ける
物理層(L1)は、0と1のビット列を電圧・光・電波に変える層です。ケーブルの種類、コネクタの形、伝送速度がここで決まります。LANケーブルの断線やWi-Fiの電波不良はL1の障害です。
データリンク層(L2)は、同じネットワークにつながった隣の機器までフレームを届けます。宛先はMACアドレス(48ビット)で指定し、フレーム末尾のFCS(CRC-32による4バイトの誤り検出符号)で壊れたフレームを捨てます。IEEEはこの層をLLC(論理リンク制御)とMAC(媒体アクセス制御)の2つの副層に分けて規格化しており、Ethernet(IEEE 802.3)とWi-Fi(IEEE 802.11)は、MAC副層とその下の物理層をまとめて定める規格です。スイッチはMACアドレスを見て転送するL2機器で、VLANもこの層の仕組みです。詳しくはイーサネットのIEEE 802.3規格と配線、IEEE 802.1QによるタグVLANの解説にまとめています。
ネットワーク層とトランスポート層:宛先まで運び、アプリへ振り分ける
ネットワーク層(L3)は、複数のネットワークをまたいで宛先まで届ける層です。IPアドレスで宛先を表し、ルーターが経路表を見て次の転送先を選びます。IPv4のアドレスは32ビット、IPv6は128ビットです。どこまでが同じネットワークかはサブネットマスクで決まり、その計算はサブネットマスクの仕組みと計算方法で扱っています。到達できないときに理由を返すICMPもこの層に属します。pingはICMPを送り、tracerouteは途中のルーターが返すICMPのTime Exceededで経路を調べます。
トランスポート層(L4)は、届いたデータをどのアプリケーションに渡すかをポート番号で区別し、必要に応じて信頼性を確保します。TCPは接続を確立し、順序の入れ替わりや欠落を再送で補います。UDPは確認をせずに送るため、ヘッダが8バイトと小さく、DNSの問い合わせのように1往復で済む通信や、音声・映像のように遅れて届くより捨てた方がよい通信に向きます。アプリからこの層を使う窓口がソケットで、OSごとの挙動差はソケット通信のAPI手順とOSで違う落とし穴で実測しています。
セッション層・プレゼンテーション層・アプリケーション層:実装では1つにまとまる上位3層
セッション層(L5)は通信の開始から終了までの対話を管理し、プレゼンテーション層(L6)は文字コードやデータ形式の変換、暗号化を受け持ちます。アプリケーション層(L7)は、HTTPやSMTPのようにアプリケーションが直接使う通信サービスを提供します。ここでいう「アプリケーション」はブラウザやメールソフトそのものではなく、それらが使うプロトコルを指します。
実際のプロトコルは、この3層の機能をまとめて持つのが普通です。HTTPはリクエストとレスポンスのやり取り(L5的な機能)も、Content-Typeによる形式の指定(L6的な機能)も自分で決めています。上位3層を個別のソフトウェアとして実装した例はほとんどないため、試験以外では「L5〜L7=アプリケーション側」とまとめて捉えて差し支えありません。
カプセル化:1つのHTTPリクエストに各層が付けるヘッダ
送信側では、上の層から受け取ったデータに各層が自分のヘッダを付けて下の層へ渡します。これがカプセル化です。受信側は逆に、下の層から順にヘッダを外して上の層へ渡します(非カプセル化)。HTTPのリクエストがEthernet上を流れるときは、次のように包まれます。
| 層 | 付けるもの | 大きさ | 主な中身 | 規格 |
|---|---|---|---|---|
| L7 | HTTPリクエスト | 可変 | メソッド、URL、ヘッダ | RFC 9110/9112 |
| L4 | TCPヘッダ | 20バイト〜 | 送信元・宛先ポート、シーケンス番号 | RFC 9293 |
| L4 | UDPヘッダ(UDPの場合) | 8バイト | ポート、長さ、チェックサム | RFC 768 |
| L3 | IPv4ヘッダ | 20バイト〜 | 送信元・宛先IPアドレス、TTL | RFC 791 |
| L3 | IPv6ヘッダ | 40バイト固定 | 送信元・宛先IPアドレス、ホップ制限 | RFC 8200 |
| L2 | Ethernetヘッダ+FCS | 14+4バイト | 宛先・送信元MACアドレス、誤り検出符号 | IEEE 802.3 |
EthernetのMTU(1回に送れるIPパケットの最大長)は通常1500バイトです。ヘッダを差し引くと、1フレームに載るアプリケーションのデータ量は次のように計算できます。
# 各層のヘッダ長から、イーサネットの1フレームに載るアプリデータ量を計算する
MTU = 1500 # IPパケットの最大長
L2 = {"Ethernetヘッダ": 14, "FCS": 4}
for ip_name, ip_len in (("IPv4", 20), ("IPv6", 40)):
for l4_name, l4_len in (("TCP", 20), ("UDP", 8)):
payload = MTU - ip_len - l4_len
frame = MTU + sum(L2.values())
ratio = payload / frame * 100
print(f"{ip_name}+{l4_name}: 載るデータ {payload}バイト / フレーム {frame}バイト = {ratio:.1f}%")
# TCPのタイムスタンプオプション(10バイト+埋め2バイト)を付けた場合
print("IPv4+TCP(タイムスタンプ付き):", MTU - 20 - 32, "バイト")
Python 3.9.6で実行した出力です。
IPv4+TCP: 載るデータ 1460バイト / フレーム 1518バイト = 96.2%
IPv4+UDP: 載るデータ 1472バイト / フレーム 1518バイト = 97.0%
IPv6+TCP: 載るデータ 1440バイト / フレーム 1518バイト = 94.9%
IPv6+UDP: 載るデータ 1452バイト / フレーム 1518バイト = 95.7%
IPv4+TCP(タイムスタンプ付き): 1448 バイト
IPv4+TCPの1460バイトが、TCPのMSS(最大セグメント長)としてよく見る値です。Linux同士の通信はTCPのタイムスタンプを付けるのが既定のため、実際に1セグメントに載るのは1448バイトになります。VPNやPPPoEのように外側へさらにヘッダを足す構成では、この余白が減ってパケットが分割されたり、途中で捨てられたりします。「小さい通信は通るのに大きなファイルだけ止まる」症状の多くはこれが原因で、調べ方はMTUの仕組みとPMTUD・MSS調整の測定手順で扱っています。
OSI参照モデルとTCP/IPモデルの違い
TCP/IPモデルは、インターネットで実際に使われているプロトコル群から逆算した階層モデルです。ホストの要件を定めたRFC 1122は、層をアプリケーション層・トランスポート層・インターネット層・リンク層の4つで説明しています。
| OSI参照モデル | TCP/IPモデル(RFC 1122) | 代表プロトコル |
|---|---|---|
| L7 アプリケーション層 | アプリケーション層 | HTTP、DNS、SMTP、TLS |
| L6 プレゼンテーション層 | ||
| L5 セッション層 | ||
| L4 トランスポート層 | トランスポート層 | TCP、UDP |
| L3 ネットワーク層 | インターネット層 | IP、ICMP |
| L2 データリンク層 | リンク層 | Ethernet、Wi-Fi、ARP |
| L1 物理層 |
違いは層の数だけではありません。OSIは先にモデルを決めてからプロトコルを作ろうとした「規格先行」で、TCP/IPは動くプロトコルが先にあり、モデルは後からの整理です。そのためTCP/IPは層の分離に厳格ではなく、RFC 3439は第3節「Layering Considered Harmful」で、層を厳密に分けすぎると最適化を妨げ、複雑さを増すと指摘しています。
使い分けは単純です。機器や障害の位置を話すときはOSIの番号(L2・L3・L4・L7)を使い、プロトコルの仕様を読むときはTCP/IPの4層で考えます。TCP/IP側から見た各層の詳細はTCP/IPの4階層モデルとOSI参照モデルの違いで解説しています。
どの層か迷うプロトコルの位置づけ
実在のプロトコルはOSIより後に、OSIを前提とせずに作られたものが大半です。そのため、どの層に置くかで教科書ごとに答えが割れるものがあります。実務では、層の番号より「何の上で動き、何を提供するか」で捉えるのが確実です。
| プロトコル | よくある分類 | 迷う理由 |
|---|---|---|
| ARP | L2またはL3 | IPアドレスからMACアドレスを引く |
| ICMP | L3 | IPパケットの中身として運ばれる |
| TLS | L4〜L7の間 | TCPの上で動き、暗号化を担う |
| BGP | L7またはL3 | TCP上で動くが、役割は経路制御 |
| QUIC | L4またはL7 | UDP上で再送と暗号化を自前で持つ |
ARPはRFC 826で定義され、IPアドレス(L3の情報)に対応するEthernetの48ビットアドレス(L2の情報)を問い合わせます。Ethernetフレームに直接載り、IPパケットにはならないため、L2とする説明とL3の補助とする説明が併存しています。TLSはRFC 8446で、下位のトランスポートに求めるのは「信頼性があり順序どおりに届くデータの流れ」だけと定められています。実際にはTCPの上で動き、暗号化という役割からはL6、HTTPから見ればL4の延長として扱われます。仕組みはTLSとSSLの違いとバージョン選定で、UDPの上で再送と暗号化をまとめて持つQUICはQUICの仕組みとTCPとの違いで詳しく扱っています。
層ごとの障害切り分け:macOSのコマンドと実行結果
OSI参照モデルが実務で役立つ代表的な場面は、通信できないときにどの層で止まっているかを下から順に確かめる場面です。下の層が通っていなければ、上の層を調べても答えは出ません。macOS 26.6.2のWi-Fi環境で、2026年10月22日に実行した結果で手順を示します(Linuxではip link、ip neighが相当します)。
| 層 | 確かめること | macOSのコマンド | 正常時の手がかり |
|---|---|---|---|
| L1 | リンクが上がっているか | ifconfig en0 |
status: active |
| L2 | ゲートウェイのMACを引けるか | arp -n 192.168.86.1 |
MACアドレスが表示される |
| L3 | 宛先まで届くか・どこで止まるか | ping、traceroute |
packet loss 0% |
| L7(DNS) | 名前が引けるか | dig +short |
IPアドレスが返る |
| L4 | ポートが開いているか | nc -vz |
succeeded |
| L6相当 | TLSが確立するか | openssl s_client |
Verification: OK |
| L7 | HTTPが応答するか | curl -I |
ステータスコード |
L1〜L3の出力です。ゲートウェイのアドレスは環境ごとに違うので、自分の環境ではroute -n get defaultで確かめます。リンクが上がり、ゲートウェイのMACアドレスが引け、外部(1.1.1.1)まで損失なく届いています。
$ ifconfig en0 | grep -E "status|mtu"
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
status: active
$ arp -n 192.168.86.1
? (192.168.86.1) at 28:bd:89:d7:13:38 on en0 ifscope [ethernet]
$ ping -c 3 1.1.1.1 | tail -2
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.653/12.769/14.986/1.568 ms
L4では、失敗の出方で原因の層が変わる点が要点です。相手のホストまで届いているが待ち受けがない場合は、相手がTCPのリセットを返すので即座に「Connection refused」になります(REJECT設定のファイアウォールがリセットを返した場合も同じ表示です)。経路の途中で捨てられている(ファイアウォールで遮断、宛先が存在しない)場合は応答がなく、タイムアウトまで待たされます。
$ nc -vz -G 3 example.com 443
Connection to example.com port 443 [tcp/https] succeeded!
$ nc -vz -G 3 127.0.0.1 9
nc: connectx to 127.0.0.1 port 9 (tcp) failed: Connection refused
$ nc -vz -G 3 10.255.255.1 443
nc: connectx to 10.255.255.1 port 443 (tcp) failed: Operation timed out
refusedなら相手のサーバーでプロセスが動いているかを、timed outならL3の経路かファイアウォールのルールを疑います。ファイアウォールが接続の状態を見てどう通すかはステートフルインスペクションとパケットフィルタリング3方式の違いを参照してください。
curlは1回の実行で、名前解決・TCP接続・TLS確立・最初の応答までの時刻を分けて出せます。各値の差を取れば、どの層に時間がかかったかを求められます。
$ curl -so /dev/null -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} http=%{http_code}\n" https://example.com
dns=0.004181 tcp=0.017536 tls=0.051357 ttfb=0.088367 http=200
値は開始からの累積秒数です。差を取ると、この例ではDNSが約4ミリ秒、TCP接続が約13ミリ秒、TLS確立が約34ミリ秒、HTTPの最初の応答が約37ミリ秒でした。ただし同じコマンドを3回実行すると、TCP接続は13〜32ミリ秒、TLS確立は22〜34ミリ秒とばらつきました。どの層に時間がかかるかは1回の結果で決めず、複数回の差分で見ます。失敗した場合もcurlの終了コードで層がわかります。名前解決の失敗は6(Could not resolve host)、TLSのハンドシェイクの失敗は35(SSL connect error)、証明書の検証の失敗は60を返します。
L4とL7の違い:ロードバランサーとファイアウォールで層が効く場面
ネットワーク製品の名前によく付く層番号はL4とL7です。L4で動く製品はIPアドレスとポート番号だけを見て判断し、L7で動く製品はHTTPのURLやヘッダ、Cookieまで読んで判断します。
| 観点 | L4で判断する製品 | L7で判断する製品 |
|---|---|---|
| 見る情報 | IPアドレス、ポート | URL、ヘッダ、Cookie、本文 |
| ロードバランサー | AWS NLB、HAProxyのTCPモード | AWS ALB、HAProxyのHTTPモード |
| 防御 | パケットフィルタ型ファイアウォール | WAF |
| TLS | そのまま通せる | 終端して中身を読む |
| 処理の重さ | 軽い | 重い |
L7ロードバランサーを選ぶ理由は、URLのパスごとに振り分け先を変えたい(/apiはAPIサーバー、/staticは配信サーバー)、Cookieで同じ利用者を同じサーバーに寄せたい、といった要件があるときです。逆に、HTTP以外のプロトコルを通す場合や、TLSを途中で復号したくない場合はL4を選びます。振り分け方式の比較はロードバランサーの仕組みと振り分け方式、L4とL7を設定で切り替える具体例はHAProxyのL4/L7ロードバランサー設定にあります。SQLインジェクションのようなL7の攻撃はL4のファイアウォールでは止められず、WAFとファイアウォール・IPSの違いで整理した層の分担が必要です。クラウド上でこうした層ごとの構成を組む場合は、AWS・Google Cloud・Azureのインフラ構築支援でも設計から対応しています。
OSI参照モデルの覚え方と試験で問われるポイント
7階層の覚え方:「アプセトネデブ」
上の層(L7)から頭文字を並べた「アプセトネデブ」が定番の覚え方です。ア=アプリケーション、プ=プレゼンテーション、セ=セッション、ト=トランスポート、ネ=ネットワーク、デ=データリンク、ブ=物理です。英語圏では下の層から「Please Do Not Throw Sausage Pizza Away」、上の層から「All People Seem To Need Data Processing」という文が使われます。
番号と結びつけるには、身近な例を3つ覚えるのが近道です。スイッチがL2、ルーターがL3、ポート番号を扱うTCPとUDPがL4です。この3点を起点にすれば、その上下は順番で埋まります。
試験で問われる特徴:デジュール標準・カプセル化・相互接続
資格試験では、OSI参照モデルの特徴を選ぶ正誤問題が出ます。選択肢に使われる記述と正誤は次のとおりです。
- 通信機能を階層別に分けて定義している:正しい
- 異なるメーカーの機器・ソフトウェアの相互接続を目的とする:正しい
- 上位層のデータに下位層がヘッダを付けるカプセル化を採用している:正しい
- デファクトスタンダード(事実上の標準)である:誤り。ISOが定めたデジュール標準で、事実上の標準になったのはTCP/IP
もう1つの頻出は、機器と層の対応です。リピーターとハブはL1、ブリッジとスイッチはL2、ルーターはL3、ゲートウェイはL4以上を中継する機器として扱われます。
よくある質問
OSI参照モデルとは何ですか?
コンピュータ同士の通信機能を、物理層からアプリケーション層までの7つの層に分けて定義した国際標準のモデルです。ISO/IEC 7498-1(ITU-T X.200)で定められ、日本ではJIS X 5003(1987年)として規格化されています。
OSI参照モデルの7つの階層は何ですか?
下からL1物理層、L2データリンク層、L3ネットワーク層、L4トランスポート層、L5セッション層、L6プレゼンテーション層、L7アプリケーション層です。上から「アプセトネデブ」と覚えます。
OSI参照モデルとTCP/IPモデルの違いは何ですか?
OSIは7層、TCP/IPは4層(RFC 1122ではリンク・インターネット・トランスポート・アプリケーション)です。OSIのL5〜L7はTCP/IPのアプリケーション層1つに、L1とL2はリンク層1つにまとまります。実際のインターネットで動いているのはTCP/IPです。
OSI参照モデルは実際には使われていないのですか?
OSIのプロトコル群はほとんど普及しませんでしたが、7階層の番号は今も使われています。L2スイッチ、L7ロードバランサーのような製品の分類や、障害の切り分けで「どの層まで通っているか」を伝える共通語になっています。
OSI基本参照モデルとOSI参照モデルは同じものですか?
同じものです。規格の正式名に「Basic Reference Model」とあるため、JISや試験では「OSI基本参照モデル」と表記されることがあります。