2026年10月16日
2026年10月16日
サブネットマスク設計のベストプラクティス|セグメントごとのサイズの決め方と設定ミスを防ぐ運用
サブネットマスクは「いま必要な台数」ではなく「数年後の台数+予約アドレス+余裕」から逆算し、役割ごとに決めたサイズを揃えて使うのが基本です。この記事では、セグメントごとにマスク長(/24、/26 など)を選ぶ手順、クラウドで差し引かれるアドレス、機器間リンクの扱い、マスクの設定ミスが起きたときの症状と確認方法までを扱います。アドレス空間全体の割り振り(どのプライベート範囲を使うか、拠点やVPCをどう分けるか)は CIDR 設計の話になるため、ここではその内側で「1つ1つのサブネットをどの大きさにするか」に絞ります。
サブネットマスクで決まること
サブネットマスクは IPv4 アドレス 32 ビットのうち、先頭から何ビットをネットワーク部とするかを示します。255.255.255.0 は /24 と同じ意味で、残り 8 ビットがホスト部です。ホスト部のビット数を h とすると、そのサブネットに含まれるアドレスは 2 の h 乗個で、そこからネットワークアドレスとブロードキャストアドレスの 2 個を引いた数が、通常の LAN でホストに割り当てられる上限になります。
| マスク長 | サブネットマスク | アドレス数 | 一般的なホスト上限 |
|---|---|---|---|
| /24 | 255.255.255.0 | 256 | 254 |
| /25 | 255.255.255.128 | 128 | 126 |
| /26 | 255.255.255.192 | 64 | 62 |
| /27 | 255.255.255.224 | 32 | 30 |
| /28 | 255.255.255.240 | 16 | 14 |
| /29 | 255.255.255.248 | 8 | 6 |
マスクを 1 ビット長くするとサブネットは半分になり、短くすると倍になります。後から大きくするには隣接する範囲が空いている必要があるため、最初のサイズ選びが運用のしやすさを左右します。
ベストプラクティス1:必要数は「現在×成長+予約分」で見積もる
マスク長を決めるときは、次の順に数えます。
- いま接続している機器の数(サーバー、PC、プリンター、IP電話、無線APなど)
- 数年以内に増える見込み。拠点の増員計画、仮想マシンやコンテナの増加、IoT 機器の追加を含めます
- 固定で使うアドレス。デフォルトゲートウェイ、冗長構成の仮想IP(VRRP など)、DNS・監視・管理用のアドレス
- DHCP の払い出し範囲とリース期間中の重複分。来客用 Wi-Fi のように端末の入れ替わりが激しい場所では、同時接続数より多めに見ます
- クラウドの場合は、事業者が予約するアドレス
合計がちょうど収まるマスクではなく、1 段大きいマスクを選ぶと、増設のたびに再設計する事態を避けやすくなります。たとえば合計 50 台なら /26(上限 62)では余裕が少ないため、/25 を検討します。逆に、数台しか置かないセグメントに /24 を割り当て続けると、アドレス空間全体が早く埋まるので、役割に応じて小さくすることも設計のうちです。
ベストプラクティス2:クラウドの予約アドレスを差し引く
クラウドの VPC やサブネットでは、事業者が一部のアドレスを自分の用途に予約します(2026年10月現在)。
- AWS(Amazon VPC): 各サブネットの先頭 4 個と最後の 1 個、計 5 個が予約され、インスタンスには割り当てられません。サブネットに指定できるサイズは /16〜/28 です
- Microsoft Azure: 各サブネットで 5 個が予約されます
- Google Cloud: 各サブネットで 4 個が予約されます
つまり AWS で /28 を作ると、使えるのは 16 − 5 = 11 個です。ロードバランサー、NAT ゲートウェイ、マネージドデータベース、Kubernetes の Pod などはサービス側が自動でアドレスを消費するため、想定より早く枯渇しがちです。特に EKS などで Pod に VPC のアドレスを直接割り当てる構成では、ノード数より Pod 数で見積もる必要があります。予約の数や最小・最大サイズは仕様変更の可能性があるので、設計時に各社の公式ドキュメントで確かめてください。
ベストプラクティス3:役割ごとにサイズを揃える
拠点ごと・用途ごとにマスク長がばらばらだと、ACL やファイアウォールのルール、監視の設定、障害時の切り分けがそのたびに計算作業になります。次のように「この役割はこのサイズ」と決めておくと、設定を見ただけで範囲が読めるようになります。
- 一般端末セグメント: /24 または /23
- サーバーセグメント: /24〜/26(台数と増設計画による)
- 管理用(機器の管理インターフェース、IPMI など): /26〜/27
- 機器間の接続リンク: /30 または /31
- ループバック(ルーターの識別用): /32
あわせて、各サブネットの中でのアドレスの使い方も揃えます。「ゲートウェイは先頭の使用可能アドレス」「固定割り当ては下位、DHCP は上位」のように規則を決めると、新しい担当者でも迷いにくくなります。
ベストプラクティス4:機器間リンクは /30 か /31
ルーター同士を 1 対 1 でつなぐリンクには、端点 2 つ分のアドレスがあれば足ります。従来は /30(使えるアドレス 2 個)が一般的でしたが、RFC 3021 で定められた /31 を使うとネットワークアドレスとブロードキャストアドレスを持たない形で 2 個とも使え、アドレスを半分に節約できます。ただし、古い機器や一部の OS・ファイアウォールでは /31 を扱えない場合があるため、採用前に両端の機器が対応しているか確認してください。拠点間をつなぐ専用線や VPN のトンネルインターフェースでも同じ考え方が使えます。
ベストプラクティス5:マスクは連続したビットのみ、表記は統一する
サブネットマスクは先頭から 1 が連続し、途中から 0 が続く形だけを使います。255.255.0.255 のような不連続マスクは現在の機器や OS では一般的に扱われず、設定できても動作の予測が難しくなります。また、設定ファイルによって /24 形式とドット区切り形式が混在すると読み違いの原因になるため、設計書と構成管理(Ansible や Terraform などのコード)ではどちらかに揃え、変換が必要な箇所だけ注記しておくと安全です。
マスクの設定ミスで起きる症状と確認方法
同じセグメントの機器同士でサブネットマスクが食い違うと、「一部の相手とだけ通信できない」という分かりにくい症状になります。
- マスクが本来より長い(例: /24 のはずが /25): 自分の範囲外と判断した同一セグメントの相手宛てのパケットをゲートウェイに送ってしまい、到達しないか、遠回りになります
- マスクが本来より短い(例: /24 のはずが /23): 本来はルーター越しの相手を同一セグメントと判断して ARP で直接探しに行くため、応答が返らず通信できません
確認は、まず各機器の実際の設定値を見るところから始めます。
# Linux: インターフェースのアドレスとプレフィックス長
ip -4 addr show
# その宛先へどの経路・どのインターフェースで送るか
ip route get 192.168.1.130
Windows では ipconfig /all でサブネットマスクを、route print で経路表を確認できます。DHCP で配っている場合は、DHCP サーバー側のスコープ設定(サブネットマスクのオプション)も見ます。手作業の計算に不安があるときは、Python の標準ライブラリで範囲を確かめると確実性が上がります。
import ipaddress
net = ipaddress.ip_network("192.168.1.0/26")
print(net.netmask, net.num_addresses, net.network_address, net.broadcast_address)
print(ipaddress.ip_address("192.168.1.70") in net) # False: 範囲外
変更するときの進め方
運用中のサブネットのマスクを変えると、そのセグメントの全機器、DHCP スコープ、ルーターの経路、ファイアウォールのルールに影響します。作業前に現在の設定を控え、機器の設定バックアップを取り、変更する順番(DHCP スコープ → ゲートウェイ → 各機器、など)と切り戻し手順を書き出しておきます。拡張したい場合は、隣接する範囲が空いているかを先に確認してください。空いていなければ、マスクを広げるより新しいサブネットを追加して移行するほうが安全なことが多いです。
まとめ
- マスク長は「現在の台数+成長+固定アドレス+予約分」から決め、ぎりぎりではなく 1 段余裕を持たせる
- クラウドでは各社が予約するアドレス(AWS・Azure は 5 個、Google Cloud は 4 個)を差し引き、マネージドサービスの消費も見込む
- 役割ごとにマスク長とサブネット内のアドレス配置を揃えると、設定と切り分けが楽になる
- 機器間リンクは /30、対応機器なら /31 で節約できる
- マスクの食い違いは「一部とだけ通信できない」症状になるため、
ip addrやipconfig /allで実際の値を確認する