LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

サブネットマスクは、IPアドレスのうちどこまでがネットワークを表し、どこからが個々の機器を表すかを示す32ビットの値です。255.255.255.0と書いても/24と書いても同じ区切りを指し、クラウドでサブネットを切る、ファイアウォールの許可範囲を決める、通信できない原因を調べる、といった場面で毎回読み書きします。

本記事では、システム開発やインフラの担当者に向けて、CIDR表記の読み方、ネットワークアドレスとブロードキャストアドレスの計算方法、同じサブネットに属するかの判定を、Pythonの標準ライブラリで確かめながら整理します。クラウドで予約されるアドレスと、つまずきやすい点も扱います。

サブネットマスクとは

IPv4のアドレスは32ビットの数で、人が読むときは8ビットずつ4つに区切って10進数で書きます。サブネットマスクも同じ32ビットの値で、1が立っているビットがネットワーク部、0のビットがホスト部を表します。255.255.255.0なら先頭24ビットが1、残り8ビットが0です。

サブネット化の考え方を定めたRFC 950は、ネットワーク番号とサブネット番号にあたるビットを1にしたマスクを持ち、宛先と自分のアドレスをそれぞれマスクとANDした結果が一致すれば直接送り、一致しなければゲートウェイへ送る処理を示しています。サブネットのビットは隣り合っていなくてもよいとしつつ、連続させて上位に置くことを勧めていました。^*1 CIDRを定めたRFC 4632では、マスクは左詰めで連続していなければならないとされています。^*2

つまり、サブネットマスクは「ここまでが同じネットワーク」と機器に伝えるための物差しで、ルーターの経路やセキュリティグループの許可範囲も同じ物差しで区切りを表します。通信の層の全体像は「通信プロトコルの基礎」で扱っています。

CIDR表記と/24の意味

CIDR（クラスレスドメイン間ルーティング）表記は、アドレスの後ろに「/」とプレフィックス長を付けて区切りを示す書き方です。RFC 4632は、172.16.0.0/16の「/16」を上位16ビットが1で下位16ビットが0のマスクとして説明し、192.168.99.0/24は上位24ビットが1で下位8ビットが0だとしています。/24は255.255.255.0と同じ意味で、プレフィックス長はマスクの1の個数そのものです。

かつてはクラスA・B・Cの3種類の大きさしか選べませんでしたが、CIDRでは2のべき乗の大きさのブロックを自由に定義できます。ホスト部がhビットならアドレスの数は2のh乗で、/24はホスト部が8ビットなので256個です。RFC 4632の表でも、/24は256アドレスで旧来のクラスCにあたると書かれています。^*2

ホストに使える数が2つ少ないのは、ホスト部がすべて0のアドレスをネットワーク自体に、すべて1のアドレスをそのネットワークの全ホストあての宛先（ブロードキャスト）に取っておくためです。RFC 950は、0を「この」、すべて1を「すべて」と読む取り決めをサブネットにも引き継ぐとしています。^*1 表の数は、Pythonのipaddressモジュールで計算し直した値です。

ネットワークアドレスの計算方法

計算は、アドレスとマスクをビットごとにANDするだけです。10.0.1.77/26を例にします。/26のマスクは255.255.255.192で、第4オクテットの192は2進数で11000000です。77は01001101なので、ANDを取ると01000000、つまり64になり、ネットワークアドレスは10.0.1.64です。

ブロードキャストアドレスは、ネットワークアドレスのホスト部をすべて1にした値です。ホスト部は6ビットなので64個のアドレスがあり、10.0.1.64から数えて最後の10.0.1.127がブロードキャストになります。ホストに付けられるのは10.0.1.65〜10.0.1.126の62個です。

手計算は取り違えやすいので、実務ではPythonのipaddressで確かめるのが確実です。次のコードは同じ値を求め、最後にANDの計算も自分で行って結果が一致することを見ています。

import ipaddress

iface = ipaddress.ip_interface("10.0.1.77/26")
net = iface.network
print(net)                     # 10.0.1.64/26
print(net.netmask)             # 255.255.255.192
print(net.broadcast_address)   # 10.0.1.127
print(net.num_addresses)       # 64
print(len(list(net.hosts())))  # 62

# アドレスとマスクのANDでネットワークアドレスを求める
a = int(ipaddress.ip_address("10.0.1.77"))
m = int(net.netmask)
print(ipaddress.ip_address(a & m))  # 10.0.1.64

ip_interface()はホストのアドレスとプレフィックス長をまとめて扱い、networkで所属するネットワークを返します。hosts()は、ネットワークアドレスとブロードキャストアドレスを除いた、使えるアドレスを返す関数です。マスクは/26のほか、255.255.255.192の形でも、ホスト部を1にした0.0.0.63の形でも渡せます。^*3

同じサブネットかの判定

2台の機器が同じサブネットにいるかは、RFC 950の処理のとおり、両方のアドレスをマスクとANDして結果を比べれば分かります。同じなら直接届き、違えばデフォルトゲートウェイを経由します。隣のサーバーに通信が届かないときは、まず両者のマスクと、この計算の結果を見比べるのが近道です。

ipaddressでは、アドレスがネットワークに含まれるかをin演算子で判定できます。次の例は、/24のブロックを/26の4つに分け、所属の判定と、ホスト部が0でない値を渡したときの動きを見ています。

import ipaddress

block = ipaddress.ip_network("10.0.1.0/24")
for sub in block.subnets(new_prefix=26):
    print(sub, sub.broadcast_address)

target = ipaddress.ip_network("10.0.1.64/26")
print(ipaddress.ip_address("10.0.1.100") in target)  # True
print(ipaddress.ip_address("10.0.1.130") in target)  # False

try:
    ipaddress.ip_network("10.0.1.77/26")
except ValueError as e:
    print(e)  # 10.0.1.77/26 has host bits set
print(ipaddress.ip_network("10.0.1.77/26", strict=False))  # 10.0.1.64/26

subnets(new_prefix=26)は、/24を/26に分けた4つのネットワークを順に返します。10.0.1.130は3つ目の10.0.1.128/26に属するため、10.0.1.64/26の判定はFalseです。ip_network()は既定でstrict=Trueになっていて、ホスト部のビットが立った値を渡すとValueErrorを出し、strict=Falseならホスト部を0にしたネットワークとして受け取ります。^*3 設定ファイルの値を読み込むときは、どちらの動きにしたいかを先に決めておきます。

クラウドのサブネット設計での使いどころ

サブネットマスクの計算がいちばん効いてくるのは、クラウドでVPCや仮想ネットワークのアドレスを割り当てる場面です。社内で使うアドレスには、RFC 1918が私的なネットワーク用に定めた10.0.0.0/8、172.16.0.0/12、192.168.0.0/16の3つのブロックがよく使われます。^*4

AWSのVPCでは、IPv4のサブネットは/28から/16までの大きさで作れます。各サブネットの最初の4つと最後の1つのアドレスは予約されていて、EC2インスタンスなどには割り当てられません。10.0.0.0/24なら、.0がネットワークアドレス、.1がVPCルーター、.2がDNSサーバー用、.3が将来のための予約、.255がブロードキャスト用です。VPCはブロードキャストをサポートしていないため、このアドレスを予約しているとAWSは説明しています。^*5

Azureの仮想ネットワークも、各サブネットの最初の4つと最後の1つ、合わせて5つのアドレスを予約します。192.168.1.0/24なら、.1が既定のゲートウェイ、.2と.3がAzure DNSへの対応付けに使われ、IPv4のサブネットは/29から/2までの大きさで作れ、サブネットのアドレス空間は互いに重ねられません。^*6

小さいサブネットほど予約の5つの比重が大きく、/28では16個のうち11個しか使えません。ロードバランサーなどのサービスもアドレスを使うため、台数の見込みに余裕を持たせて大きさを決めます。

複数のVPCや拠点をつなぐ構成では、アドレスの範囲が重ならないことが前提です。設計の段階で、割り当て案の重なりを機械的に調べておきます。

import ipaddress
import itertools

plan = {"app": "10.0.1.0/26", "db": "10.0.1.64/27", "batch": "10.0.1.80/28"}
nets = {name: ipaddress.ip_network(cidr) for name, cidr in plan.items()}

for (a, x), (b, y) in itertools.combinations(nets.items(), 2):
    if x.overlaps(y):
        print("重複:", a, x, "と", b, y)

overlaps()は、一方のネットワークがもう一方に一部でも含まれればTrueを返します。^*3 この例では、dbの10.0.1.64/27（.64〜.95）の中にbatchの10.0.1.80/28が入っているため、重なりとして検出されます。VPCどうしをつなぐ経路と費用の考え方は「AWS Transit Gateway/VPCのデータ処理コストを外注で最適化する進め方」で扱っています。

つまずきやすい点

1つ目は、機器どうしを1対1でつなぐリンクのプレフィックス長です。/30では4アドレスのうち2つしか両端に使えませんが、1対1のリンクにブロードキャストは要りません。RFC 3021は、/31の2つのアドレスをどちらもホストのアドレスとして解釈しなければならないと定め、500本のリンクがあれば1000アドレスを節約できると試算しています。^*7 Pythonのhosts()も/31では2つとも返しますが、機器やツールによって扱いが違うことがあるので、使う前に対応を確かめます。

2つ目は、ホスト部が0でない値をネットワークとして書いてしまうことです。AWSは、コマンドラインツールやAPIでサブネットを作るときに100.68.0.18/18を指定すると、100.68.0.0/18として作成すると説明しています。^*5 意図しない範囲で作られても気づきにくいため、IaCのコードでは前述のstrict=Trueのような検査をかけ、作成前に誤りに気づけるようにします。

3つ目は、IPv6に同じ感覚を持ち込むことです。IPv6ではアドレスの後ろにプレフィックス長を付けて表し、RFC 4291はプレフィックス長を、アドレスの左から連続する何ビットがプレフィックスかを示す10進数と定めています。先頭が2進数の000で始まるものを除くユニキャストアドレスでは、インターフェースIDを64ビットにするよう求めているため、LANのサブネットは/64が基本です。^*8 AzureでもIPv6のサブネットはちょうど/64と決まっています。^*6移行の進め方は「IPv6移行とは」で扱っています。

外部に委託するときに確認しておきたい点

サブネットの設計やネットワークの構築を外部に委託するときは、アドレスの割り当て表を誰が持ち、どう更新するかを最初に決めておきます。表計算の台帳が複数に分かれていると、重なりや使い残しに気づけません。IPアドレス管理を含む構成管理の仕組みは「NetBoxでネットワーク構成管理を外注構築」で扱っています。

そのうえで、既存の拠点や他のVPC、接続先と重ならない範囲を選んでいるか、サービスが使うアドレスまで見込んで台数の上限を示しているか、重なりの検査を変更のたびに自動で走らせる仕組みがあるかを確かめます。提案の段階で文書にしてもらうと、引き継ぎのときにも判断の根拠が残ります。

まとめ：サブネットマスクで確かめておきたい3つの点

サブネットマスクで確かめておきたい点は3つです。第一に、/24のプレフィックス長はマスクの1の個数で、ホスト部のビット数からアドレスの数が決まること。第二に、ネットワークアドレスはアドレスとマスクのANDで求まり、同じサブネットかどうかも同じ計算で判定できること。第三に、クラウドでは各サブネットで5つのアドレスが予約されるため、使える数を差し引いて大きさを決め、範囲の重なりを事前に調べることです。

よくある質問

出典

1. *1　参考：IETF「RFC 950 Internet Standard Subnetting Procedure」（https://www.rfc-editor.org/rfc/rfc950）。出典：アドレスマスク（my_ip_mask）とANDによる送り先の判定、サブネットのビットを連続させて上位に置く推奨、0とすべて1のアドレスの扱いの記述を参照（2026年10月確認）
2. *2　参考：IETF「RFC 4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan」（https://www.rfc-editor.org/rfc/rfc4632）。出典：3.1節のプレフィックス表記（/16・/24の意味、2のべき乗のブロック）、3.1節の表（/24が256アドレス・旧クラスC、/32がhost route）、マスクが左詰めで連続する必要の記述を参照（2026年10月確認）
3. *3　参考：Python Software Foundation「ipaddress — IPv4/IPv6 manipulation library」（https://docs.python.org/3/library/ipaddress.html）。出典：IPv4Networkのマスクの指定形式、strictの動き、hosts()・subnets()・overlaps()、in演算子による所属の判定、netmask・broadcast_address・num_addressesを参照（2026年10月確認）
4. *4　参考：IETF「RFC 1918 Address Allocation for Private Internets」（https://www.rfc-editor.org/rfc/rfc1918）。出典：3節の私的なネットワーク用の3つのアドレスブロックを参照（2026年10月確認）
5. *5　参考：Amazon Web Services「Subnet CIDR blocks — Amazon Virtual Private Cloud」（https://docs.aws.amazon.com/vpc/latest/userguide/subnet-sizing.html）。出典：IPv4のサブネットの大きさ（/28〜/16）、予約される5つのアドレスと用途、CIDRブロックを正規の形に直す例を参照（2026年10月確認）
6. *6　参考：Microsoft「Azure Virtual Network FAQ」（https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq）。出典：各サブネットで予約される5つのアドレスと用途、サブネットの大きさ（/29〜/2）、IPv6サブネットは/64、サブネットのアドレス空間を重ねられないことの記述を参照（2026年10月確認）
7. *7　参考：IETF「RFC 3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links」（https://www.rfc-editor.org/rfc/rfc3021）。出典：1節の/30と1対1リンクの問題、500本のリンクで1000アドレスの節約、2.1節の/31の2アドレスをホストとして解釈する規定を参照（2026年10月確認）
8. *8　参考：IETF「RFC 4291 IP Version 6 Addressing Architecture」（https://www.rfc-editor.org/rfc/rfc4291）。出典：2.3節のプレフィックス長の定義、2.5.1節のインターフェースIDを64ビットとする規定を参照（2026年10月確認）

Tweet