サブネット計算ツール
IPv4/IPv6 のネットワークアドレス、ブロードキャスト、マスク、ホスト範囲、CIDR をブラウザだけで計算します。
サブネット計算ツールとは
サブネット計算ツールは、IP アドレスと CIDR プレフィックスまたはサブネットマスクを入力すると、そのネットワークの構造的な属性、すなわちネットワークアドレス、ブロードキャストアドレス、利用可能なホスト範囲、総ホスト数、そしてネットワークビットとホストビットの境界をバイナリで導き出すツールです。ネットワークエンジニア、システム管理者、開発者は、VLSM の割り当て計画、ファイアウォールルールの作成、「なぜこのホスト同士が通信できないのか」のトラブルシューティング、ルーティングテーブルの設定など、あらゆる場面でこのツールを使います。計算自体はマスクとのビット単位 AND/OR にすぎず、原理は単純ですが実務では誤りが起こりやすく、特に IPv4 と IPv6 のアドレスはそれぞれ 32 ビットと 128 ビットで長さが異なるため間違いやすくなります。本ツールはブラウザ内で BigInt 演算を用いて完結するため、IPv6 全域(/0 から /128 まで)を精度を損なうことなく扱え、入力したアドレスがサーバーに送信されることもありません。
使い方
操作手順
- 上部のトグルで IPv4 か IPv6 を選択します。
- 入力欄に IP アドレスを入力します。例:10.0.0.42 や 2001:db8::1。
- 数値入力またはスライダーでプレフィックス長を調整すると、結果が即座に更新されます。
- 結果タイルをクリックすると、その値をクリップボードにコピーできます。
- IPv4 の場合は、より長いターゲットプレフィックスを指定してネットワークを小さなサブネットに分割することもできます。
よくある誤解
- /31 ネットワークは壊れているわけではありません。RFC 3021 によりポイントツーポイントリンクでの利用が明示的に認められており、両方のアドレスが利用可能です。
- /32 は単一ホスト(ホストルート)を表し、空のネットワークではありません。IPv6 の /128 も同様です。
- 「ブロードキャストアドレス」という概念は IPv6 には存在しません。代わりにプレフィックス末尾のアドレスが表示され、範囲チェックでは同じ役割を果たします。
- ワイルドカードマスク(Cisco の ACL で使用)は、サブネットマスクのビット単位 NOT に過ぎません。255.255.255.0 のワイルドカードは 0.0.0.255 です。
活用シーン
技術原理
IPv4 アドレスは 32 ビット、IPv6 は 128 ビットです。CIDR 表記(RFC 4632、2006 年 8 月)はアドレスにプレフィックス長 /n を付加し、左から n ビットをネットワーク識別子、残りをホスト識別子と宣言します。サブネットマスクは n 個の 1 ビットに続いて 32−n(または 128−n)個の 0 ビットが並ぶビットパターンであり、/24 であれば 11111111.11111111.11111111.00000000、ドット 10 進では 255.255.255.0 となります。CIDR は RFC 791 のクラスフルアドレッシング(0.0.0.0–127.255.255.255 が暗黙の /8 のクラス A(0.0.0.0/8 は「このネットワーク」として、127.0.0.0/8 はループバック用に予約)、128.0.0.0–191.255.255.255 が /16 のクラス B、192.0.0.0–223.255.255.255 が /24 のクラス C など)を置き換えました。クラスフル方式はアドレスを破滅的に浪費し、たとえば 1,000 席の企業がクラス B の割り当てを受けると 1,000 必要なところに 65,534 ホストを得てしまい、IPv4 空間を断片化させていました。CIDR は任意のプレフィックス長を許容し、VLSM(可変長サブネットマスク、最初に RFC 950(1985 年)で定義された)と経路集約(「スーパーネッティング」)を可能にしました。 中核となる演算はビット単位です。ネットワーク = アドレス AND マスク、ブロードキャスト = ネットワーク OR (NOT マスク) = ネットワーク OR ワイルドカードとなります。192.168.1.100/24 の場合、アドレス 0xC0A80164 と 0xFFFFFF00 の AND は 0xC0A80100(192.168.1.0)、0x000000FF との OR は 0xC0A801FF(192.168.1.255)になります。利用可能なホストは IPv4 では 2^(32−n) − 2 個(ネットワークとブロードキャストを差し引く)です。この −2 は /31 では消え(RFC 3021 がポイントツーポイントリンク用に取り戻し、両端が利用可能)、/32 では単一ホストルートとなります。IPv6 にはブロードキャストアドレスがなく、マルチキャストとエニーキャストがその役割を引き継いだため、「最後のアドレス」は単にプレフィックス範囲の上限にすぎません。JavaScript のネイティブビット演算子は 32 ビット符号付きであり、IPv4 の 0xFFFFFFFF はオーバーフローして −1 になり、IPv6 はそもそも表現できません。本ツールは両方を BigInt で扱い、バージョンに依存しない正確さを保証します。 プライベートアドレス空間は、IPv4 では RFC 1918 で 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 が定義されています。IPv6 は fc00::/7 のユニークローカルアドレス(RFC 4193)に加え、SLAAC とリンク内通信のための fe80::/10 リンクローカルを使用します。本ツールはこれらに印を付けるため、プライベート範囲を誤ってパブリック BGP に公開してしまうことを防げます。本ツールが防止する典型的な誤りには次のようなものがあります。(1) 192.168.1.100/255.255.255.0 と /24 のどちらで入力するか迷うケース:本ツールはプレフィックス形式を受け取りつつドットマスクも表示します。(2) /30 と /29 のホスト容量を取り違えるケース(2 台と 6 台)。(3) /24 を 8 つの /27 に分割した際、4 つ目のサブネットの開始位置を誤るケース(正しくは 192.168.1.96 であって 192.168.1.97 ではありません)。(4) Cisco の ACL 構文でワイルドカード 0.0.0.255 とマスク 255.255.255.0 を混同するケース。ネットワークビットを強調表示したバイナリビジュアライゼーションは、これらのすべての誤りを根本から消し去る境界を体得する最速の方法です。
- RFC 4632(2006 年 8 月)は CIDR — Classless Inter-Domain Routing — を定義し、RFC 791 のクラスフル A/B/C 方式を置き換えました。/n 表記はネットワークプレフィックス長を宣言し、残りのビットがホスト部となります。CIDR は VLSM(最初に RFC 950(1985 年)で定義された)と経路集約を可能にし、IPv4 のアドレス節約と現代の BGP テーブルの双方に不可欠です。
- ネットワークアドレス = IP AND マスク、ブロードキャスト = ネットワーク OR ワイルドカード(ワイルドカード = NOT マスク)。/24 ならマスクは 0xFFFFFF00、ワイルドカードは 0x000000FF。利用可能ホスト数 = 2^(32−n) − 2、ただし /31(RFC 3021、ポイントツーポイントリンクで両アドレス利用可)と /32(単一ホストルート)は例外です。
- IPv6(128 ビット)にはブロードキャストはなく、マルチキャスト(ff00::/8)とエニーキャストがその役割を担います。慣例上の最小プレフィックスは /64(SLAAC のため、サブネットあたり 1,800 京アドレス)、サイトあたり /56 または /48、ISP あたり /32 です。IPv6 のアドレス空間は節約よりも経路集約を優先します。
- RFC 1918 を超える予約範囲:127.0.0.0/8 はループバック、169.254.0.0/16 は IPv4 リンクローカル(auto-IP / APIPA)、224.0.0.0/4 はマルチキャスト、240.0.0.0/4 は実験用に予約されています。IPv6 でも fe80::/10 がリンクローカル SLAAC 用に、ff00::/8 がマルチキャスト用に、::1/128 がループバック用に予約されています。本ツールはプライベート範囲とパブリック範囲を区別するため、入力したアドレスがパブリックインターネット上でルーティング可能かどうかを一目で判断できます。
- JavaScript のビット演算子は 32 ビット符号付きで、(0xFFFFFFFF & 0xFFFFFF00) は 0xFFFFFF00 ではなく −256 を返します。本ツールは全体を通して BigInt を使用し、IPv4 の全範囲と 128 ビットの IPv6 を精度を落とさずに処理します。同じコードパスで両バージョンを計算し、マスク幅だけが異なります。
- Cisco/Juniper でよくある落とし穴:ACL 構文はサブネットマスク(255.255.255.0)ではなくワイルドカードマスク(0.0.0.255)を取ります。EIGRP や OSPF の network 文もワイルドカードを使います。反転したマスクは意図したネットワークの補集合にマッチし、ルーティングプロトコルではサイレントに(隣接関係が確立されない形で)、ACL では悪用可能な形で(誤ったトラフィックが許可される形で)影響を及ぼします。
- VLSM の例:/24 を 4 つの均等なサブネットに分割すると、4 × /26(各 64 アドレス)となり、サブネットあたりの利用可能ホスト数は 62 です。隣り合う /26 はオフセット 0、64、128、192 から始まり、0、63、127、191 ではありません。本ツールの分割機能はこれらの境界を自動生成するため、頭の中で換算する必要がありません。
実例
標準的な /24(最も一般的な LAN)
入力: 192.168.1.100/24
ネットワーク: 192.168.1.0
ブロードキャスト:192.168.1.255
マスク: 255.255.255.0
ワイルドカード: 0.0.0.255
ホスト: 192.168.1.1 - 192.168.1.254 (254 台利用可)
クラス: C、プライベート(RFC 1918)
バイナリ: 11000000.10101000.00000001.01100100
(ネットワークビット = 左 24、ホストビット = 右 8)ポイントツーポイント /31(RFC 3021)
入力: 10.0.0.1/31
ネットワーク: 10.0.0.0
ブロードキャスト:10.0.0.1
マスク: 255.255.255.254
ホスト: 10.0.0.0 - 10.0.0.1 (2 台利用可、リンクの両端)
RFC 3021 以前、/31 は 2 - 2 = 0 のため「使用不可」とされていました。
現代のルーターはポイントツーポイントリンクで両アドレスを許可し、
トランジット区間でアドレス空間を半分節約できます。VLSM 分割:/24 を 4 つの /26 へ
入力: 192.168.1.0/24、/26 へ分割
サブネット 1: 192.168.1.0/26 ホスト .1 - .62
サブネット 2: 192.168.1.64/26 ホスト .65 - .126
サブネット 3: 192.168.1.128/26 ホスト .129 - .190
サブネット 4: 192.168.1.192/26 ホスト .193 - .254
境界に注目してください:0、64、128、192。各 /26 は 64 アドレスを
保持します(うち 62 台が利用可能)。よくある間違いは、サブネット 2 を
.63(サブネット 1 のブロードキャストの +1)から始めることですが、
.63 はブロードキャストそのものであり、次のサブネットは .64 から始まります。IPv6 /64(標準的なリーフネットワーク)
入力: 2001:db8:1234:5678::1/64
ネットワーク: 2001:db8:1234:5678::
最終: 2001:db8:1234:5678:ffff:ffff:ffff:ffff
マスク: ffff:ffff:ffff:ffff::
ホスト: 18,446,744,073,709,551,616 (2^64)
単一の /64 は IPv4 全体を 2 乗した数より多くのアドレスを保持します。
SLAAC は下位 64 ビットがインターフェース識別子(EUI-64 または
RFC 7217 によるランダム値)をエンコードするため /64 を必要とします。よくある質問
なぜ /24 の利用可能ホストは 256 ではなく 254 なのですか?
/24 サブネットには 2^8 = 256 個のアドレスがありますが、そのうち 2 つは予約されています。ネットワークアドレス(192.168.1.0)はルーティングテーブル上でサブネット自身を識別するためのもので、ブロードキャストアドレス(192.168.1.255)はサブネット上のすべてのホスト宛てのメッセージに使われます。どちらもホスト IP として使用できないため、割り当て可能なアドレスは 254 個になります。この −2 ルールは /1 から /30 までのすべての IPv4 プレフィックスに当てはまります。例外は /31(RFC 3021、ポイントツーポイントで 2 台利用可)と /32(単一ホストルートで 1 台)です。
サブネットマスクとワイルドカードマスクの違いは何ですか?
サブネットマスクはネットワーク部が 1、ホスト部が 0 のマスクで、/24 なら 255.255.255.0 です。ワイルドカードマスクはそのビット単位 NOT で、/24 なら 0.0.0.255 となります。Cisco IOS の access-list、EIGRP、OSPF はワイルドカードを使用しますが、これは元来の ACL 実装が「don't care」モデル(ワイルドカードの 1 ビットは「このビットは一致しなくてよい」を意味する)を採用していたためです。他社製品や現代の Cisco 構文の多くはサブネットマスク形式も受け付けますが、引き継ぐ既存の設定ではワイルドカードが使われていることが多いでしょう。
IPv6 にはブロードキャストアドレスがありますか?
ありません。IPv6 では意図的にブロードキャストが廃止され、マルチキャスト(ff00::/8)とエニーキャストに置き換えられました。「全ノード」スコープは ff02::1 で、IPv4 のリンクローカルブロードキャストと似た振る舞いをしますが、マルチキャストグループに参加したノードにしか届きません。そのため本ツールでは IPv6 のこの値を「ブロードキャスト」ではなく「最終アドレス」として表示します。IPv4 の 255.255.255.255 のようにそこへパケットを送ることはできません。すべてのホストへ配送するプロトコルレベルの仕組みは存在しないからです。
古い式では「利用可能ホスト数 0」となる /31 がなぜ役に立つのですか?
2000 年以前の教科書では、/31 は 2^1 − 2 = 0 で利用可能ホスト数 0 のため無効とされていました。RFC 3021(2000 年 12 月)はポイントツーポイントリンク向けに /31 を再定義しました。エンドポイントが 2 つしかなく、別個のブロードキャストが不要だからです(リンク自体がブロードキャストスコープを定義します)。現代のルーター(IOS 12.2 以降、Junos、FRR、Linux)はすべて /31 をサポートします。トランジットリンクで /30 の代わりに /31 を使えば、コアネットワークインフラが消費するアドレス空間が半分になります。大規模ネットワークで数千のリンクに適用すれば、その差は無視できません。
なぜ私の IPv6 サブネットはどれも /64 になるのですか?
慣例として、リーフネットワークに割り当てる IPv6 の最小単位は /64 です。下位 64 ビットはインターフェース識別子のために予約されており、SLAAC(RFC 4862)は MAC アドレス(EUI-64)、ネットワークプレフィックスとホスト固有秘密に基づく安定ハッシュ (RFC 7217)、または短命なランダム値(RFC 4941 プライバシー拡張)からこれを生成します。ポイントツーポイントリンクで /126 や /127 を使うのは静的設定としては成立しますが、SLAAC や多くの自動化機能が動かなくなります。エンドステーションが存在するすべてのサブネットには /64 が推奨され、/127 は完全に管理下にあるルーター間リンクでのみ使用されます。
このツールは私の IP アドレスをサーバーに送信しますか?
送信しません。すべての計算はブラウザ内で JavaScript の BigInt 演算によりクライアントサイドで実行されます。アドレス、プレフィックス、計算結果のいずれもバックエンドに送信されることはありません。ブラウザの DevTools のネットワークタブを開けば、計算中に外向きのリクエストがないことを確認できます。これは ToolAct のすべてのブラウザベースユーティリティに共通するプライバシー方針です。
/24 と 255.255.255.0 の違いは何ですか?
機能的には何も違いません。同じマスクを表す 2 つの記法にすぎません。/24(CIDR 表記、RFC 4632)は先頭の 1 ビットの数を数え、255.255.255.0(ドット 10 進マスク)はそれらのビットを 4 オクテットの数値として書き出します。現代の OS やルーターの設定はどちらの形式も受け付けます。本ツールは入力したプレフィックスについて両方を表示するため、対象システムが要求する方をそのままコピー&ペーストできます。
なぜこの計算ツールは 010.0.0.1 のような入力を拒否するのですか?
先頭ゼロ(010、04、0001)は、IP パーサーごとに同じ文字列でも解釈が異なるため拒否しています。glibc の inet_aton は歴史的に先頭ゼロのオクテットを 8 進数として解釈してきました(010 = 8)が、現代の Python(3.9.5 以降)や JavaScript ランタイムはこれを 10 進数として扱います(010 = 10)。このスタック間の解釈の不一致は、実際に SSRF バイパスの脆弱性(CVE-2021-29921 とその系列)を引き起こしてきました。あるサービスがアロー・リスト判定で 010.0.0.1 を 8.0.0.1 として扱う一方、下流のライブラリが 10.0.0.1 へ接続してしまう、というケースです。特定の解釈を暗黙に採用することを避けるため、本ツールは先頭ゼロを含むオクテットをすべて拒否しています。貼り付ける前にゼロを取り除いてください(010 → 10)。