なぜ今さら「クラスフル」を語るのか？――CIDRとVLSMで紐解く、ネットワーク設計の「作法」
ネットワークエンジニアとして現場の最前線に立っていると、若手から「なぜサブネットマスクの計算でこんなに苦労するんですか？」と聞かれることがあります。クラウド環境（AWSのVPCやAzureのVNet）ではGUIでポチポチするだけでネットワークが完成してしまう時代ですが、その裏で何が起きているのかを理解していないと、いざという時のトラブルシューティングで必ず手痛いしっぺ返しを食らいます。
今日は、インターネットの歴史を変えた「CIDR（Classless Inter-Domain Routing）」と「VLSM（Variable Length Subnet Masking）」について、教科書的な説明はすっ飛ばして、現場の知見を交えて深掘りしていきましょう。
—
1. 昔話：クラスフルアドレッシングという「終わりの始まり」
TCP/IPの黎明期、IPアドレスは Class A, Class B, Class C という固定サイズで分割されていました。
- Class A: 最初の8ビットがネットワーク部。巨大なネットワーク向け。
- Class B: 最初の16ビットがネットワーク部。中規模向け。
- Class C: 最初の24ビットがネットワーク部。小規模向け。
この方式、一見シンプルですが、致命的な欠陥がありました。例えば「500台のホストをつなぎたい」と考えたとき、Class C（最大254台）では足りず、やむを得ず Class B（約6.5万台）を割り当てることになります。結果として、使われない数万個のアドレスが「ゴミ」として消えていく。これが「IPアドレスの枯渇」を加速させた最大の犯人です。
—
2. CIDR：自由を手に入れたネットワーク
この無駄を解消するために登場したのが CIDR です。これは「ネットワーク境界は8ビット単位である必要はない」という革命的な考え方です。
例えば、192.168.0.0/23 という表記を見たことはありますか？
これは「最初の23ビットをネットワーク部とする」という意味です。これにより、192.168.0.0 から 192.168.1.255 までを一つのネットワークとして扱えるようになります。
実務でのルーティング集約（ルート集約）
CIDRの真骨頂は、ルーターが保持するルーティングテーブルの軽量化にあります。バラバラのサブネットを一つにまとめて上位ルーターに伝えることで、インターネット全体の負荷を下げています。
# Linuxでルーティングテーブルを確認するコマンド例
ip route show
# 出力例: 10.0.0.0/16 via 192.168.1.1 dev eth0
# このように /16 で集約することで、無数の個別ルートを記述せずに済む—
3. VLSM：現場で必須の「節約術」
VLSM（可変長サブネットマスク）は、CIDRの概念をさらに推し進め、一つのネットワーク内でさらに細かくサブネットを分ける技術です。
例えば、ある拠点で「サーバー用（30台）」「クライアント用（100台）」「ルーター間接続（2台）」のネットワークが必要だとします。すべて同じサイズのサブネットを割り当てては効率が悪すぎますよね？
- サーバー用:
192.168.1.0/27(32アドレス) - クライアント用:
192.168.1.32/25(128アドレス) - ルーター間:
192.168.1.160/30(4アドレス)
このように、必要な分だけを切り出す。これが「インフラエンジニアの腕の見せ所」です。
—
4. API設計とインフラ連携への応用
現代のWeb API設計では、Security Group や WAF のアクセス制御リスト（ACL）でCIDRを指定する機会が多いはずです。ここでミスをすると、サービス停止という大事故につながります。
Pythonを使って、特定のIPがCIDR範囲内に含まれるか判定するスクリプトを書いてみましょう。
import ipaddress
def check_access(client_ip, allowed_cidr):
# ipaddressモジュールを使うのが現代の鉄則
net = ipaddress.ip_network(allowed_cidr)
ip = ipaddress.ip_address(client_ip)
if ip in net:
print(f"許可: {client_ip} は {allowed_cidr} の範囲内です")
else:
print(f"拒否: {client_ip} はアクセスできません")
# 使用例
check_access("192.168.1.5", "192.168.1.0/24")また、外部APIと疎通確認をする際の curl コマンドでも、ネットワークの出口（インターフェース）を指定して疎通確認を行うスキルは必須です。
# 特定のインターフェース経由でAPIを叩く（トラブルシューティング用）
curl --interface eth0 https://api.example.com/v1/data \
-H "Authorization: Bearer <TOKEN>" \
-v # 詳細ログを表示してパケットの経路を確認する—
最後に：ネットワークを「直感」で捉える
CIDRやVLSMを理解することは、単なる計算練習ではありません。「パケットがどのゲートウェイを通り、どの経路で宛先に届くか」をイメージする力を養うことです。
Web APIのレスポンスが遅いとき、それはアプリケーションのコードが悪いのか、それともネットワークのルーティングが最適化されていないのか。CIDRの知識があれば、ルーティングテーブルを覗き込み、ルート集約が正しく行われているかを確認する――そんな泥臭いデバッグが最短で行えるようになります。
「設定しておけば動く」ではなく、「なぜそのアドレス範囲なのか」を常に問い続けること。それが、ネットワークの荒波を生き抜くエンジニアの唯一の生存戦略です。
次回は、これらの知識を応用した「ゼロトラスト環境におけるマイクロセグメンテーション」についてお話ししましょう。現場からは以上です。
コメント