サブネットマスクとCIDR表記の計算方法｜/24や/16を読めるようになるネットワーク入門

「VPCのCIDRは10.0.0.0/16で、サブネットは/24ずつ切ってください」と言われて、なんとなく真似はできても、/16と/24で何がどう違うのか、10.0.5.0/24に何台入るのか、と聞かれると答えに詰まる。セキュリティグループの送信元に「203.0.113.0/28」と書いてある意味が読み取れない。そうした状態のまま設定をコピーして運用しているケースは珍しくありません。

この記事では、サブネットマスクとCIDR表記を2進数レベルから計算できるようになることを目標に、ネットワークアドレス・ブロードキャストアドレス・利用可能ホスト数の求め方、暗算のコツ、VPC設計で頻出する/16と/24の分割パターン、そして重複CIDRがVPNやピアリングを壊す仕組みを解説します。AWSやGCPでVPCを実際に構築する手順はAWS VPCのネットワーク設計入門とGCP VPCネットワーク設計入門で扱っているため、本記事は「計算」と「設計判断」に絞ります。

CIDR表記の意味：IPアドレスを2進数で見る

32ビットを「ネットワーク部」と「ホスト部」に分ける

IPv4アドレスは32ビットの数値を8ビットずつ4つに区切り、10進数で表記したものです。192.168.10.0なら、2進数では11000000.10101000.00001010.00000000になります。この32ビットのうち、先頭の何ビットまでが「同じネットワークに属するかを決める部分（ネットワーク部）」で、残りが「その中の個々の端末を区別する部分（ホスト部）」かを示すのがサブネットマスクです。

CIDR表記の/24は「先頭24ビットがネットワーク部」という意味で、サブネットマスクで書くと先頭24ビットが1、残り8ビットが0の11111111.11111111.11111111.00000000、つまり255.255.255.0です。/16なら255.255.0.0、/8なら255.0.0.0になります。CIDR（Classless Inter-Domain Routing）という名前のとおり、かつてのクラスA/B/Cという8ビット単位の固定区切りをやめ、任意のビット数で区切れるようにした表記法です。

ホスト部のビット数がアドレス数を決める

ホスト部がnビットあれば、そのサブネットには2のn乗個のアドレスが含まれます。ただし、そのうち先頭（ホスト部がすべて0）はネットワークアドレス、末尾（ホスト部がすべて1）はブロードキャストアドレスとして予約されるため、端末に割り当てられるのは「2のn乗 − 2」個です。

CIDR	サブネットマスク	ホスト部ビット	総アドレス数	利用可能ホスト数（一般）	AWSでの利用可能数
/16	255.255.0.0	16	65,536	65,534	65,531
/20	255.255.240.0	12	4,096	4,094	4,091
/22	255.255.252.0	10	1,024	1,022	1,019
/24	255.255.255.0	8	256	254	251
/26	255.255.255.192	6	64	62	59
/28	255.255.255.240	4	16	14	11
/32	255.255.255.255	0	1	1台を指す表記	—

AWSのVPCでは、各サブネットの先頭4アドレス（ネットワークアドレス、VPCルーター、DNS、将来予約）と末尾1アドレス（ブロードキャスト）の計5個が予約されるため、利用可能数は「総数 − 5」になります。AWSでサブネットとして作れる最小は/28、最大は/16です。GCPも先頭2・末尾2の計4個を予約します。表の値は「一般的な計算」と「クラウドの実際」で少しずれることを覚えておいてください。なお/32は「アドレス1個」を意味し、セキュリティグループで特定の1台だけを許可するときに203.0.113.7/32のように使います。

ネットワークアドレスとブロードキャストを計算する

手順：マスクとのANDで求める

「192.168.10.77/26は、どのネットワークに属し、同じサブネットの範囲はどこからどこまでか」を求める手順です。

1. マスクを2進数にする。/26は先頭26ビットが1なので、4オクテット目は11000000＝192。マスクは255.255.255.192
2. アドレスとマスクの各ビットをAND（両方1のときだけ1）する。4オクテット目：77＝01001101、192＝11000000、ANDは01000000＝64。よってネットワークアドレスは192.168.10.64
3. ホスト部（下位6ビット）をすべて1にするとブロードキャスト。01111111＝127。よって192.168.10.127
4. 利用可能なホストはその間の192.168.10.65〜192.168.10.126の62個

暗算のコツ：「ブロックサイズ」で考える

2進数を毎回書くのは面倒なので、実務では「ブロックサイズ」で暗算します。/25〜/30のように4オクテット目で区切る場合、ブロックサイズは「256 − マスクの4オクテット目」です。/26なら256 − 192 = 64なので、サブネットは0、64、128、192の4つの起点で区切られます。77は64以上128未満なので、ネットワークは.64、ブロードキャストはその次の起点の1つ手前で.127、と一瞬で出せます。/27ならブロック32、/28なら16、/30なら4です。3オクテット目で区切る/17〜/23も同様に、/22なら3オクテット目のブロックサイズが4（256 − 252）で、10.0.0.0、10.0.4.0、10.0.8.0…と刻まれます。

計算に自信がないときや設計書を書くときは、ツールで検算します。macOSやLinuxのipcalcコマンド、あるいはPython標準のipaddressモジュールが手軽です。

# ipcalc（macOS: brew install ipcalc / Ubuntu: apt install ipcalc）
ipcalc 192.168.10.77/26
# Network:   192.168.10.64/26
# Broadcast: 192.168.10.127
# HostMin:   192.168.10.65
# HostMax:   192.168.10.126
# Hosts/Net: 62

import ipaddress

net = ipaddress.ip_network("192.168.10.77/26", strict=False)
print(net.network_address, net.broadcast_address, net.num_addresses)
# 192.168.10.64 192.168.10.127 64

# /16 を /24 に分割して列挙
vpc = ipaddress.ip_network("10.0.0.0/16")
subnets = list(vpc.subnets(new_prefix=24))
print(len(subnets), subnets[0], subnets[255])   # 256 10.0.0.0/24 10.0.255.0/24

# 2つのCIDRが重なっているか
a = ipaddress.ip_network("10.0.0.0/16")
b = ipaddress.ip_network("10.0.5.0/24")
print(a.overlaps(b))   # True

VPC設計でよくある/16と/24の分割例

なぜVPCは/16、サブネットは/24が定番なのか

VPC全体に/16（65,536アドレス）を割り当て、その中を/24（256アドレス）単位でサブネットに切るのは、「余裕が大きく、桁が読みやすい」からです。/16なら3オクテット目をサブネット番号として使えるので、10.0.1.0/24、10.0.2.0/24と人間が見て意味を読み取りやすく、256個のサブネットを作れるため将来の拡張にも困りません。1つの/24に251台（AWS）入れば、中小規模のアプリケーションの1階層には十分です。

典型的な設計は、用途（パブリック/プライベート）とアベイラビリティゾーン（AZ）の組み合わせでサブネットを切る形です。

サブネット	CIDR	用途
public-1a	10.0.0.0/24	ロードバランサー、NATゲートウェイ（AZ-a）
public-1c	10.0.1.0/24	同上（AZ-c）
private-app-1a	10.0.10.0/24	アプリケーションサーバー（AZ-a）
private-app-1c	10.0.11.0/24	同上（AZ-c）
private-db-1a	10.0.20.0/24	データベース（AZ-a）
private-db-1c	10.0.21.0/24	同上（AZ-c）

3オクテット目を「0番台はpublic、10番台はapp、20番台はdb」のように役割ごとに10刻みで空けておくと、後からAZや階層を足しても番号の規則が崩れません。コンテナ（ECS/EKS）を使う場合はタスクやPodが1つずつIPを消費するため、アプリ用サブネットは/24では足りずに/22や/20を切ることもあります。「今の台数」ではなく「IPを消費するものの数」で見積もるのがポイントです。

避けるべき範囲：将来つなぐ相手と重ならない番号を選ぶ

VPCのCIDRを決めるとき、何も考えずに10.0.0.0/16や192.168.0.0/16を選ぶと後で困ることがあります。10.0.0.0/16は多くのチュートリアルやデフォルト設定で使われるため、別のVPCや取引先のネットワークと重なりやすく、192.168.0.0/16はほぼすべての家庭・オフィスのルーターが使っています。VPNでオフィスとつなぐ、他のVPCとピアリングする、買収先のシステムを統合する、といった将来の接続を見越して、10.20.0.0/16や10.130.0.0/16のように「誰も使っていなさそうな」範囲を選ぶのが設計上の定石です。組織内でどの範囲を誰が使っているかを一覧にしたIPアドレス管理表を持っておくと、この判断が確実になります。

重複CIDRによるVPN・ピアリングの失敗

ルーティングは「宛先の範囲」で決まるため、重なると行き先を選べない

ルーターやVPCのルートテーブルは、「この宛先範囲ならこの経路へ」という表です。自分のネットワークが10.0.1.0/24で、VPN先のオフィスも10.0.1.0/24だった場合、10.0.1.50宛てのパケットを「ローカルの隣の端末」に届けるべきか「VPNの向こう」に届けるべきかを決められません。ルートテーブルは通常ローカル経路を優先するため、VPNの向こうへは永遠に届かず、しかも接続自体は成功しているので「つながっているのに通信できない」という分かりにくい症状になります。

VPCピアリングはこの問題を事前に検出し、CIDRが重複するVPC同士のピアリングは作成自体を拒否します。一方、Site-to-Site VPNやWireGuardのような自前VPNは重複を止めてくれないため、設計段階で確認するしかありません。前述のPythonのoverlaps()で機械的にチェックできます。

トラブル事例：VPNは接続できるのにサーバーに届かない

症状

オフィスからAWSのVPCへSite-to-Site VPNを構築した。VPNトンネルのステータスはUPで、AWS側のルートテーブルにもオフィス向けの経路が伝搬されている。しかしオフィスのPCからVPC内のサーバー10.0.1.20へpingもSSHも通らない。

原因

オフィスのLANが192.168.1.0/24、VPCのプライベートサブネットの1つが偶然同じ192.168.1.0/24だった。オフィスのPCは10.0.1.20宛ては問題なく送れるはずだったが、VPC側のサーバーがオフィスのPC（192.168.1.35）へ返答する際、宛先192.168.1.0/24を「自分のローカルサブネット」と判断し、VPNではなくローカルへ送ってしまっていた。行きは届いていたが、戻りが迷子になっていたのが真相だった。

対処

VPC側のサブネットを作り直すのは影響が大きかったため、オフィス側のLANを192.168.1.0/24から172.20.1.0/24へ変更した（小規模オフィスでルーターのDHCP設定を変えるだけで済んだ）。あわせて、社内で使うすべてのCIDRをスプレッドシートに登録し、新しいVPCやVPNを作る前に重複チェックを必須にする運用を追加した。事前にipaddressモジュールで機械的に検査すれば数秒で見つかる問題であり、設計時の確認手順の欠如が本質的な原因だった。

まとめ

CIDRの/nは「先頭nビットがネットワーク部」を意味し、残りのホスト部ビット数から「2のn乗」でアドレス数が決まります。ネットワークアドレスはマスクとのAND、ブロードキャストはホスト部をすべて1にした値で、暗算するならブロックサイズ（256 − マスクの該当オクテット）で区切りを見つけるのが早道です。クラウドでは予約アドレスがある点、コンテナはIPを大量に消費する点を踏まえ、VPCは/16・サブネットは/24を基本に、将来つなぐ相手と重ならない範囲を選んでください。CIDRの重複はVPNやピアリングを静かに壊すため、設計時の機械的なチェックを習慣にすることが最も費用対効果の高い対策です。IPv4の枯渇を背景にした次の一歩として、IPv6入門もあわせてご覧ください。

ネットワーク設計やVPC・VPNの構成の見直しでお困りの際は、Harmonic Societyのシステム開発・インフラ支援にご相談ください。