郵便配達と「最長一致」の魔法：VPCルートテーブルの仕組みを解き明かす
こんにちは！SREとして日々クラウドの裏側を覗いていると、ネットワークのトラブルの多くが「パケットが迷子になること」に起因していることに気づかされます。
「なぜ、このパケットは意図した通りに届かないのか？」
その答えの多くは、VPCのルートテーブルという、いわば「地図」の読み方に隠されています。今日は、ネットワーク初心者の方が一番最初につまずきやすい「最長一致ルーティング（Longest Prefix Match）」について、一緒に紐解いていきましょう。
—
1. 郵便配達で例える「ルートテーブル」
ルートテーブルとは、一言で言えば「パケットという手紙の宛先を読み取って、次にどこへ転送すべきかを示す案内板」です。
皆さんが手紙を出すとき、郵便番号を書きますよね？
もし「123-0000」という広い地域をカバーする郵便局と、「123-4567」という特定の町内だけを担当する郵便局があったら、手紙はどちらに渡すべきでしょうか？
もちろん、より詳しく場所を指定している「123-4567」の方ですよね。ネットワークの世界でも、これと全く同じことが行われています。
2. 「最長一致ルーティング」って何？
クラウドのネットワークでは、宛先のIPアドレスと、ルートテーブルに書かれた「宛先範囲（CIDR）」を照らし合わせます。
例えば、宛先IPが 10.0.1.5 だったとしましょう。ルートテーブルには以下の2つのルートがあるとします。
1. 10.0.0.0/16 （広範囲なルート： 10.0.x.x 全体）
2. 10.0.1.0/24 （狭範囲なルート： 10.0.1.x だけ）
このとき、10.0.1.5 はどちらの条件にも当てはまります。しかし、ルールは一つ。「一番詳しく指定しているルートが優先される」、これが最長一致ルーティングの原則です。
10.0.0.0/16は、前から16ビットが一致すればOKという「大まかな地図」10.0.1.0/24は、前から24ビットが一致しなければならないという「詳細な地図」
より多くのビットが指定されている（＝範囲が狭い）後者の方が、パケットにとっての「優先的な目的地」となるのです。
3. 実践：Terraformでルートテーブルを書く
では、実際にクラウドインフラでこの設定をどう書くのか、Terraformの例を見てみましょう。設定の際は、「どのサブネットにどのルートを紐付けるか」が重要になります。
# VPC内のルートテーブル定義例
resource "aws_route_table" "main" {
vpc_id = aws_vpc.main.id
# デフォルトゲートウェイ（インターネット向け）
# 0.0.0.0/0 は「どこへ行くにもここを通る」という一番広い範囲（デフォルトルート）
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.igw.id
}
# 特定のネットワーク（オンプレミス等）へ向かうルート
# 192.168.0.0/16 のような広い範囲より、192.168.1.0/24 が優先される
route {
cidr_block = "192.168.1.0/24"
gateway_id = aws_vpn_gateway.vpn.id
}
tags = {
Name = "my-route-table"
}
}このコードでは、0.0.0.0/0 が一番広範囲なルールとして定義されています。もし特定のIPアドレス宛の通信が、より詳細なルート（例: /24 や /32）に合致すれば、そちらが優先的に選ばれます。合致するものがない場合のみ、この広い 0.0.0.0/0 が選ばれるという仕組みです。
4. なぜこれが大事なのか？
実務で一番怖いのは、「意図しないルートにパケットが吸い込まれること」です。
例えば、「社内ネットワークからのアクセスだけ許可したい」のに、うっかり 0.0.0.0/0 を優先させるような設定をしてしまうと、世界中からアクセス可能な穴が開いてしまいます。
また、サブネットを細かく切り分ける設計（VPC設計）においては、この「最長一致」を理解していると、トラフィックを制御しやすくなります。
「この通信はデータベースサブネットを通したい」「この通信はNATゲートウェイ経由で外に出したい」といった細かいルール作りは、すべてこのビット数のパズルを解くことと同じなのです。
最後に：一歩ずつ理解を深めましょう
ネットワークは、目に見えないパケットの流れを想像する世界です。最初は CIDR やビット計算に抵抗があるかもしれませんが、「範囲が狭いほど、詳細で優先される」というルールさえ覚えていれば、怖いものはありません。
トラブルが起きたときは、「今、パケットはどの地図を信じて進もうとしているのか？」と立ち止まってルートテーブルを確認してみてください。必ず、パケットが迷子になった理由が見えてくるはずですよ！
それでは、良いクラウドライフを！
コメント