はじめに
AWSをTerraformで触るハンズオンをやっていて、ロードバランサの説明で「ALBはL7、NLBはL4」という一文に出くわしました。L7、L4——見覚えはあります。基礎情報の資格勉強でOSI参照モデルの7層を丸暗記した、あれです。でも正直に言うと、暗記して以来、実務でこの7層を使った記憶がほとんどありませんでした。
7層、暗記したのに使ってなくないですか？ 少なくとも自分はそうでした。この記事は、その「暗記して終わったOSI」を「デバッグで毎日使える地図」に読み替えるまでの整理です。7層を空で言えるかどうかはどうでもよくて、価値は別のところにあった、という話をします。
※私はコンピュータサイエンス専攻ではないので、CS的な厳密さは今回は理解のためにある程度許容いただきたいです。
忙しい人向けの結論
| 問い | 答え |
|---|---|
| 7層の暗記は役に立つ？ | 名前を暗記すること自体はほぼ役に立たない |
| じゃあ何が価値なの？ | 「この不具合はどの層の話か」を切り分ける地図として使えること |
| 具体的にどう効く？ | 「つながらない」を下の層から順に潰していける。当てずっぽうが消える |
| TCP/IPとは別物？ | 考え方は同じ。層を7個から4個にまとめただけ |
対象読者はこのあたりを想定しています。
- OSIの7層を暗記したが、実務での使いどころがピンときていない人
- 「つながらない」「なぜか動かない」の調査で、いつも手当たり次第になってしまう人
- AWSのSGやALB/NLBの説明に出てくる「L4」「L7」を雰囲気で読み流している人
参考リンク
OSI7層は「暗記するもの」ではなく「切り分けの地図」
まず7層のおさらいだけ、ざっと置いておきます。ここは読者も一度は見たはずなので、表を眺めるだけで十分です。
| # | 層 | 役割 | 代表例 |
|---|---|---|---|
| 7 | アプリケーション | アプリが使う通信サービスそのもの | HTTP, DNS, SMTP |
| 6 | プレゼンテーション | 表現形式の変換（文字コード・暗号化） | TLS/SSL |
| 5 | セッション | 通信の開始〜終了の管理 | セッション管理 |
| 4 | トランスポート | 端点間の信頼性・ポートの振り分け | TCP, UDP |
| 3 | ネットワーク | ネットワーク間の経路制御（住所=IP） | IP, ICMP |
| 2 | データリンク | 同一ネットワーク内の隣接ノード間転送 | Ethernet |
| 1 | 物理 | 電気信号・光・電波で物理的に伝送 | ケーブル |
で、ここからが本題です。この表を暗記しても、実務では一度も「第5層は何でしょう？」とは聞かれません。効いてくるのは、通信を 層のスタックとして眺める視点 のほうでした。「つながらない」という漠然とした症状を、「これはL3の話？ L4？ それともL7？」と切り分けるための座標軸。地図だと思うと、急に使いどころが見えてきます。
通信は「送信は降りる・受信は昇る」──途中の機器はてっぺんまで昇らない
地図として使う前に、通信がこの層をどう通るかだけ押さえます。ここを誤解している人が多い（自分もそうでした）ので、図にしました。
ポイントは2つです。
ひとつ目。同じ1台の中で「L1からL7へ昇って、また降りる」わけではありません。送信側は上から下へ降りるだけ、受信側は下から上へ昇るだけ。降りるときに各層が自分のヘッダを付け足し（これをカプセル化と呼びます）、昇るときに剥がしていきます。「通信が行って戻ってくる」の正体は、リクエストとレスポンスという逆向きの2つの旅であって、1台の中の往復ではないんですね。
ふたつ目。通常のルータやスイッチは、てっぺんまで昇りません。ルータは宛先を決めるのに必要なIP（L3）まで昇ったらすぐ折り返し、スイッチはMAC（L2）までしか見ない。ただし例外があって、ALB・WAF・プロキシ・CDNのような「L7の中間機器」は、あえてL7まで開いて中身を見ます（この話は最後のAWS節で戻ってきます）。この「機器ごとに開ける層が違う」がわかると、次のロードバランサの話がスッと入ってきます。
カプセル化のイメージは、荷物を段ボールに入れて、それをさらに大きな箱に入れて…と包んでいく感じです。受け取った側は外側から順に開けていく。中身（アプリのデータ）は変えずに、各層が自分用の宛名ラベルを外側に貼っていく、と考えると腑に落ちます。
TCP/IPは別物じゃない──同じ思想を4層にまとめただけ
「じゃあ実際のインターネットもこの7層で動いてるの？」というと、そこは少しややこしい。現実に動いているのはTCP/IPモデルという4層の分け方です。ただ、これはOSIと敵対する別の考え方ではありません。層で積み上げるという思想はまったく同じで、分け方の粒度が違うだけ です。
OSIがL7・L6・L5と3つに分けたアプリ周りを、TCP/IPは「アプリケーション層」ひとつにまとめています。実装上、HTTPやTLSはアプリがまとめて面倒を見るので、細かく分ける実益が薄いんですね。物理まわり（L1・L2）も「リンク層」にまとめられています。
面白いのは、現場でよく聞く「L4ロードバランサ」「L7ロードバランサ」という言い方です。この番号はOSI由来なのに、指している中身のTCP（L4）やHTTP（L7）はTCP/IPの現実。つまり実務では、OSIの番号を借りてTCP/IPの実物を語っているわけです。両方を知っておくと、この混ざり方に戸惑わずに済みます。
なお歴史的には、TCP/IPのほうが先に普及して事実上の標準になり、OSIは後から整備された理論モデルという立ち位置です。試験ではOSIで問われ、現場ではTCP/IPで動いている——このねじれを頭の隅に置いておくと混乱しません。TCP/IPの層構成はRFC 1122で定義されています。
層で切り分けるデバッグ──下から順に土台を潰す
ここが、自分がこの記事で一番伝えたかったところです。「地図として使う」の具体がこれ。
Webアプリで「APIにつながらない」とき、原因は複数の層に散らばっています。ありがちなのは、いきなりアプリのコードを疑って延々とログを読む、でも実はSG（セキュリティグループ）でポートが閉じていただけ、みたいなやつ。自分も何度かやりました。恥ずかしい話ですが、原因が下の層にあるのに上の層をいじり続けると、時間だけが溶けていきます。
これを防ぐのが「下から順に土台を潰す」やり方です。
具体的なコマンドで追うと、こんな順番になります。
# ① 名前解決できる？（DNS = L7）
nslookup api.example.com
# → IPが返らないなら DNS の問題。ここで止まる
# ② 相手に届く？（L3 ネットワーク）
ping api.example.com
# → 応答なしなら経路 or ファイアウォールで遮断されている可能性
# ③ ポートは開いてる？（L4 トランスポート）
nc -zv api.example.com 443
# → refused: ホストまでは到達、待ち受けプロセスがない（TCP RSTが返る）
# → timed out: SG/NACL/FW/経路のどこかで破棄されている（refusedとは別物！）
# ④ TLSは成立する？（L6 プレゼンテーション）
openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null
# → 証明書エラーなら期限切れ or ドメイン不一致
# ⑤ HTTPは正しく返る？（L7 アプリケーション）
curl -v https://api.example.com
# → 502/503: LBまでは到達、後ろのターゲットが応答していない
# → curlは通るのにブラウザだけ失敗するなら CORS など「ブラウザ側の制約」を疑う
この順で追うと、①〜④が全部OKなら、L3・L4・TLSまでは概ね成立している と言えます。あとはHTTP層——アプリのコード、LBやWAFのルール、ブラウザ側の制約——に絞って見ればいい。逆に②で止まれば、アプリのコードをいくら読んでも無駄で、経路かファイアウォールを見に行くべきだとわかる。切り分けができると、調べる場所が一気に絞れるんです。
ICMPを塞いでいるサーバは珍しくないので、「pingが通らない = 到達不可」とは限りません。②が失敗しても、③のポート確認まではやってから経路の問題と判断するのが安全です。層で切り分けるときも、1つの結果だけで断定せず、隣の層と突き合わせるのが実戦のコツです。
エラーメッセージは「どの層で失敗したか」を教えてくれる
切り分けの視点を持つと、エラーメッセージの解像度も上がります。あの無味乾燥なメッセージたちは、実は「どの層で失敗したか」を教えてくれていました。
| エラー | 失敗している層 | 意味 |
|---|---|---|
Connection refused |
L4 | ポートまで届いたが、誰も待ち受けていない |
Connection timed out |
L3/L4 | そもそも届いていない（経路 or FWで遮断） |
| TLS handshake failed | L6 | 暗号化のネゴシエーションで失敗 |
502 Bad Gateway |
L7 | LBまでは到達、後ろのターゲットが応答しない |
| CORS error | L7 | 通信は成功、ブラウザが同一オリジンポリシーで結果をブロック |
個人的に一番効いたのは、refused と timed out は別の層の症状だと腹落ちしたことでした。refusedは「ポートまでは届いている」、timed outは「そもそも届いていない」。届いているかどうかが違うので、次に見る場所がまったく変わります。ここを混同していると、ファイアウォールを疑うべき場面でアプリの設定をいじってしまう。
AWSに引きつける──SG・ALB・NLBはどの層の話か
最後に、この地図をAWSに重ねてみます。冒頭の「ALBはL7、NLBはL4」に戻ってくる話です。
- ALB（Application Load Balancer）は L7で動きます。HTTP/HTTPSの中身——URLのパスやホスト名、ヘッダ——を見て振り分けられる。だから「
/apiはこっち、/imgはあっち」ができる - NLB（Network Load Balancer）はL4で動きます。TCP/UDPのレベルでIPとポートだけを見て高速に捌く。中身は見ない
- セキュリティグループはL3（IP）とL4（プロトコル・ポート）の条件で許可ルールを定義します。明示的なdenyは書けず、ルールに一致しない通信は暗黙的に拒否。ステートフルなので、許可した通信の戻りは自動で通る
- WAF（Web Application Firewall）はL7で、リクエストの中身を見て防御します
この対応がわかると、設計判断が理由つきでできるようになります。たとえば「特定のURLパスだけブロックしたい」と思っても、それはSGでは不可能です。SGはL3/L4までしか見ないので、URL（L7の情報）を条件にできない。だからL7を見るWAFが必要になる——と論理的にたどり着けます。「なんとなくWAF」ではなく「層が足りないからWAF」。この差は地味に大きいです。
おわりに
OSIの7層を暗記していたときの自分は、正直この知識に何の意味があるのかわかっていませんでした。でも「暗記するもの」ではなく「切り分けの地図」だと読み替えた瞬間に、急に手に馴染む道具になった感覚があります。
7層をそらで言える必要はないと思っています。大事なのは、目の前の「つながらない」を層にマッピングして、下から順に潰していけること。それだけで、推測と再起動の繰り返しから、根拠のある切り分けに変わります。
みなさんは最近どんな「つながらない」で溶かした時間がありますか。もしそれが下の層の見落としだったなら、次は下から順に潰してみてください。自分は今のところ、これで調査時間がだいぶ短くなっています。