--- title: "CIDRとは？表記の読み方と計算方法・サブネット設計とAWS VPCでの使い方を実装者向けに解説" url: "https://www.issoh.co.jp/tech/details/13322/" published: 2026-07-09 updated: 2026-09-08 categories: ["インフラ・クラウド"] publisher: "株式会社一創" --- # CIDRとは？表記の読み方と計算方法・サブネット設計とAWS VPCでの使い方を実装者向けに解説 CIDR（Classless Inter-Domain Routing）は、IPアドレスとネットワークの範囲を「192.168.1.0/24」のようにスラッシュ付きで表す方法です。プレフィックス長の読み方、サブネットマスクとの相互変換、ホスト数の計算式に加え、Pythonのipaddressとawsコマンドで計算・検証する手順、AWS VPCのCIDR設計と予約アドレス、重複を避ける判断までを実装者の視点で整理しました。分割と集約、IPv6での違い、失敗パターンと見送り基準も扱い、数値はRFCと公式ドキュメントで確認して該当箇所から出典へリンクしています。 ## まとめ：CIDRの要点とインフラ設計での押さえどころ CIDRは、IPアドレスの後ろに「/プレフィックス長」を付け、先頭何ビットがネットワーク部かを示す表記です。/24なら上位24ビットがネットワーク部、残り8ビットがホスト部で、2の8乗＝256個を表します。ホストへ割り当てられるのは、ネットワークアドレスとブロードキャストアドレスを除いた254個。現行仕様は[RFC 4632（BCP 122・2006年8月）](https://www.rfc-editor.org/rfc/rfc4632.html)が規定し、1993年のRFC 1519を廃止した文書です。 設計で押さえる点は4つ。ホスト数を「2の(32−プレフィックス)乗−2」で即算できること。拠点間接続では範囲の重複が致命傷になるため、割り当て前に全体のアドレス計画を決めること。AWS VPCのように各サブネットで5アドレスが予約される環境では、その分を見込んで切ること。そして暗算に頼らず、ipaddressやawsコマンドで検算を自動化すること。広く取りすぎれば衝突し、狭く取りすぎれば後から拡張できません。 ## CIDR表記の仕組みとサブネットマスク・IPアドレスとの対応関係 CIDRは1993年のRFC 1518／1519で標準化され、2006年のRFC 4632が現行仕様を規定します。クラスA・B・Cの固定区分（クラスフルアドレッシング）を置き換え、ネットワークの大きさを1ビット単位で決められるようにした仕組みです。まずは表記の読み方から整理します。 ### プレフィックス長で決まるネットワーク部とホスト部の境界と桁数 CIDR表記は「IPアドレス／プレフィックス長」の形を取ります。192.168.1.0/24であれば、先頭24ビットがネットワーク部、残りの8ビットがホスト部。IPv4は全体で32ビットなので、プレフィックス長は0〜32です。 ネットワーク部は「どのネットワークか」、ホスト部は「その中のどの機器か」を表します。プレフィックス長が大きいほどネットワーク部が長くなり、収容できる機器は減る。/16なら6万台超を収容できます。この境界がビット単位で動く点が、8ビット刻みしか選べなかったクラスフル方式との差です。 ### サブネットマスクとCIDR表記を相互変換する計算手順と対応表 プレフィックス長は、従来のサブネットマスク（255.255.255.0のような表記）と1対1で対応します。/24は先頭24ビットが1、残り8ビットが0のマスクなので、10進数では255.255.255.0。変換はプレフィックス長のぶん左から1を並べ、8ビットごとに10進数へ直すだけです。2進数のマスクやAND演算の手順は、[サブネットマスクの詳しい計算](https://www.issoh.co.jp/tech/details/13334/)で解説しています。 | CIDR | サブネットマスク | ホスト部ビット | | ---- | --------------- | ------- | | /8 | 255.0.0.0 | 24ビット | | /16 | 255.255.0.0 | 16ビット | | /24 | 255.255.255.0 | 8ビット | | /28 | 255.255.255.240 | 4ビット | | /32 | 255.255.255.255 | 0ビット | /32は単一のIPアドレスを指し、ファイアウォールやルーティングで「この1台だけ」を表すときに使います。暗記は不要ですが、桁の並びを理解しておくと設定ミスに気づけます。 ### クラスフルアドレッシングからCIDRへ移行した背景とRFC規定 クラスフル方式では、クラスAが約1677万台、クラスBが約6万5千台、クラスCが254台と収容数が3段階に固定されていました。数百台規模の組織がクラスBを取れば大半が遊び、クラスCでは足りない。RFC 4632の第2章も、1992年のROADグループが「クラスBアドレス空間の枯渇」と「ルーティングテーブルの増大」を課題に挙げた経緯を記録しています。 CIDRはこの2つを同時に解きました。プレフィックス長を任意に切って割り当て精度を上げ、連続したネットワークを1つにまとめる「経路集約」で経路表を圧縮したのです。特殊用途として予約済みのIPv4範囲は[IANAのIPv4 Special-Purpose Address Registry](https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml)が一次情報で、設計で使ってよい範囲はここで確認します。 ## CIDRブロックのアドレス範囲計算とプレフィックス別ホスト数 設計の現場でいちばん問われるのは「このCIDRブロックに何台入るか」です。公式さえ覚えれば暗算できます。範囲計算と分割・集約、IPv6での違いを順に見ます。 ### プレフィックス長ごとのホスト数早見表と計算式の具体的な使い方 総アドレス数は「2の(32−プレフィックス)乗」で求まります。機器へ割り当てられる数は、そこからネットワークアドレスとブロードキャストアドレスの2つを引いた値。つまり利用可能ホスト数は「2の(32−プレフィックス)乗−2」です。 | CIDR | 総アドレス数 | 利用可能ホスト数 | | ---- | ------ | -------- | | /30 | 4 | 2 | | /29 | 8 | 6 | | /28 | 16 | 14 | | /24 | 256 | 254 | | /16 | 65536 | 65534 | /30はホストが2台だけなので、ルーター同士を結ぶ点対点リンクに使われます。/16は大規模なVPCの土台に向いた大きさ。設計では将来の増設ぶんを含めて2倍の余裕を見ると、後述する手戻りを避けられます。 ### サブネット分割と集約（スーパーネッティング）の考え方と実務例 1つのCIDRブロックを長いプレフィックスで小さく割ることをサブネッティング（分割）と呼びます。10.0.0.0/16を10.0.0.0/24、10.0.1.0/24…と256個へ分ければ、部署ごとに分離できます。物理配線を変えずに論理的な分離を増やす場面では、[VLANによるタグ付けとVLAN間ルーティング](https://www.issoh.co.jp/tech/details/13550/)とCIDRの割り当てを一緒に設計すると、L2の分離とL3のアドレス計画が食い違いません。 逆に、連続する複数のネットワークを短いプレフィックスで1つにまとめるのが集約（スーパーネッティング／経路集約）。192.168.0.0/24と192.168.1.0/24を192.168.0.0/23として広告すれば、経路は2つから1つに減ります。集約は経路表を軽くし、経路変更の影響を局所化する。分割で管理単位を細かくし、広告時に集約でまとめるのが実務の型です。 ### IPv6のCIDR表記と/64・/48で分けるサブネット粒度の考え方 IPv6でもCIDR表記の考え方は同じですが、アドレスが128ビットに増えるためプレフィックス長は0〜128を取ります。表記は「2001:db8::/32」のよう。アドレス体系は[RFC 4291（IPv6 Addressing Architecture）](https://www.rfc-editor.org/rfc/rfc4291.html)が規定し、IPv4との違いはブロードキャストがなく2を引かない点です。 1つのサブネットには/64を割り当てるのが運用上の目安。これは[RFC 4862のステートレスアドレス自動設定（SLAAC）](https://www.rfc-editor.org/rfc/rfc4862.html)がインタフェースIDに64ビットを使う前提から来ています。サイト割り当ては注意が必要で、[RFC 6177（BCP 157・2011年3月）](https://www.rfc-editor.org/rfc/rfc6177.html)はRFC 3177の「エンドサイトには一律/48」を撤回し、/56のような割り当ても各RIRの方針として認められたと明記。「/48が標準」の古い解説のまま設計すると、ISPから/56を渡された時点で計画が崩れます。IPv6では1ビットを惜しむより、受け取ったプレフィックスの中で階層を整理する設計に切り替わる。 ## Pythonのipaddressでプレフィックスを計算・検証する実行例 CIDRの計算は手でも書けますが、設計レビューや移行作業では検算を自動化したほうが速く、桁の読み違いも消えます。Python標準ライブラリの`ipaddress`は追加インストールなしで使え、分割・集約・重複判定まで数行。以下は[Python公式ドキュメントのipaddress](https://docs.python.org/3/library/ipaddress.html)にあるAPIだけで組んだ実行例です。 ### ip\_networkでネットマスクと利用可能ホスト数を確かめる手順 起点は`ip_network`です。CIDR文字列を渡すとネットワークオブジェクトになり、ネットマスク、総アドレス数、分割後のブロックが取れます。下のコードはPython 3.14系で実行し、コメントに実際の出力を書きました。 ``` import ipaddress net = ipaddress.ip_network("10.0.0.0/16") print(net.netmask) # 255.255.0.0 print(net.num_addresses) # 65536 print(net.num_addresses - 2) # 65534（IPv4の利用可能ホスト数） subs = list(net.subnets(new_prefix=24)) print(len(subs), subs[0], subs[-1]) # 256 10.0.0.0/24 10.0.255.0/24 agg = ipaddress.collapse_addresses([ ipaddress.ip_network("192.168.0.0/24"), ipaddress.ip_network("192.168.1.0/24"), ]) print(list(agg)) # [IPv4Network('192.168.0.0/23')] ``` `subnets`に`new_prefix`を渡すと、先ほどの分割がそのまま列挙されます。`collapse_addresses`は逆向きで、連続する2つの/24を/23へまとめた結果を返す。この数行を設計資料の付録へ置けば、レビューで「その/22で本当に足りるのか」を即座に検算できます。 ### overlapsで拠点間のCIDR重複を機械判定する検証スクリプト アドレス計画で最も事故が多いのは重複です。拠点やVPCが10を超えると目視では追えないため、計画表を辞書に持ち、総当たりで`overlaps`を回します。CIで回せば、新しい拠点のCIDRを追記した時点で衝突が見つかる。 ``` import ipaddress import itertools plan = { "tokyo-vpc": "10.0.0.0/16", "osaka-vpc": "10.1.0.0/16", "onprem-hq": "10.0.8.0/22", } nets = {k: ipaddress.ip_network(v) for k, v in plan.items()} for (ka, na), (kb, nb) in itertools.combinations(nets.items(), 2): if na.overlaps(nb): print("NG", ka, na, "x", kb, nb) # NG tokyo-vpc 10.0.0.0/16 x onprem-hq 10.0.8.0/22 ``` この例では、東京VPCの10.0.0.0/16がオンプレ本社の10.0.8.0/22を内包しているため接続できません。`overlaps`は包含関係も重複として真を返すので、「片方が広い」ケースを取りこぼしません。 ### is\_privateが100.64.0.0/10でFalseを返す3.13系の仕様 プライベートアドレスの判定を`is_private`に任せるときは、例外を1つ覚えておく必要があります。Python公式ドキュメントは、IANAの特殊用途レジストリを基準としつつ、共有アドレス空間である100.64.0.0/10については例外としてFalseを返すと明記。同ページには「Changed in version 3.13」として偽陽性・偽陰性を修正した旨も載っています。 手元のPython 3.14.6で確認すると、10.1.2.3と192.168.10.5はTrue、100.64.0.1はFalse、172.32.0.1もFalse。100.64.0.0/10はキャリアグレードNATで使う範囲で、インターネットへ直接出ない点はプライベートアドレスと似ています。それでも判定はFalse。「is\_privateがTrueなら社内」という前提で許可判定を組むと、3.12系以前と3.13系以降で挙動が変わる。判定はRFC 1918の3範囲を列挙して照合するほうが安全です。 ## クラウドと業務システム構築で失敗しないCIDR設計の判断基準 ここからは概念ではなく、クラウドや社内ネットワークを構築するときのCIDR設計に踏み込みます。判断を誤ると後戻りが難しい領域です。 ### AWS VPCのCIDRブロック設計と予約される5つのアドレス AWSでVPCを作る際、IPv4のCIDRブロックは/16（65,536アドレス）から/28（16アドレス）で指定します。見落とされがちなのが、[AWS公式ドキュメントのサブネットサイズ設定](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-sizing.html)に記載された「各サブネットの先頭4アドレスと末尾1アドレス、計5つが予約される」という仕様。10.0.0.0/24なら10.0.0.0（ネットワーク）、10.0.0.1（VPCルーター）、10.0.0.2（DNS）、10.0.0.3（将来用）、10.0.0.255（ブロードキャスト）が使えません。/28なら使えるのは11個。IPv6でも同様に5つ予約されます。 | 対象 | IPv4の指定範囲 | IPv6の指定範囲 | | ----- | --------- | --------------- | | VPC | /16〜/28 | /44〜/60（4ビット刻み） | | サブネット | /16〜/28 | /44〜/64（4ビット刻み） | IPv6側の指定幅は[VPCのCIDRブロックのドキュメント](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html)が示すもので、1つのVPCに最大5つのIPv6 CIDRブロックを関連付けられます。既存CIDRのサイズは後から変更できないため、VPC全体は/16など広めに確保し、サブネットは用途ごとに/24前後で切るのが扱いやすい。初期構築の手順は[AWS環境構築の手順](https://www.issoh.co.jp/tech/details/15359/)にまとめました。設計から移行・運用までを外部に相談するなら、[AWSのインフラ構築](https://www.issoh.co.jp/service/system/aws/)で支援を受けられます。 ### 拠点間・オンプレ接続でのアドレス重複を避けるCIDR設計手順 VPCピアリング、VPN、専用線でネットワークをつなぐとき、双方のCIDRが重複していると経路が確定できず接続できません。クラウド移行や企業統合で頻発するトラブルです。[RFC 1918](https://www.rfc-editor.org/rfc/rfc1918.html)が定めるプライベートアドレス（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）は自由に使える反面、各拠点が無計画に192.168.0.0/24を使えば接続段階で衝突します。 対策は、接続しうるネットワーク全体で1つのアドレス計画表を持ち、拠点ごとに重ならないCIDRを事前に割り振ること。前節のoverlaps判定を当てれば、追記の時点で衝突が出ます。多数のVPCと拠点をハブで束ねる構成では、[AWS Transit Gatewayの経路設計](https://www.issoh.co.jp/tech/details/4263/)でルートテーブルの持ち方が変わる。重複が残るなら[NATとNAPT（IPマスカレード）の違い](https://www.issoh.co.jp/tech/details/13552/)で扱う変換で逃がす手もあり、接続方式の選び方は[閉域網とは？VPN・専用線との違い](https://www.issoh.co.jp/column/details/13181/)で整理しました。 ### セキュリティグループとACLでのCIDR許可範囲の絞り込み設計 セキュリティグループやネットワークACL、オンプレのファイアウォールでは、許可・拒否をCIDR単位で指定します。ここでの設計が甘いと、意図せず広い範囲に穴を開けることになる。0.0.0.0/0はすべてのIPアドレスを指すため、管理用ポートに許可すると全世界へ公開したのと同じ状態です。 許可範囲は業務で本当に必要なCIDRまで絞り込むのが原則。社内からのアクセスは自社の固定IPを/32で、拠点間は各拠点のCIDRだけを列挙します。この絞り込みは防御設計の一部であり、[クラウドセキュリティとは](https://www.issoh.co.jp/column/details/13266/)で扱う多層防御とあわせると、許可ルールの妥当性を判断しやすくなります。 ## AWS CLIでVPCとサブネットのCIDRを指定して作る手順 設計したCIDRは、コンソールの画面遷移よりコマンドで残したほうが再現できます。ここではVPCとサブネットを作り、割り当て済みIP数と予約分を突き合わせるまでを示します。指定規則は[AWS CLIのcreate-subnetリファレンス](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-subnet.html)が一次情報です。 ### create-vpcとcreate-subnetでCIDRを指定する実行コマンド VPCに/16を確保し、アベイラビリティゾーンごとに/24を切る最小構成です。VPC IDは`create-vpc`の戻り値から取り、以降のコマンドへ渡します。 ``` aws ec2 create-vpc \ --cidr-block 10.20.0.0/16 \ --query "Vpc.VpcId" --output text # vpc-0a1b2c3d4e5f67890 aws ec2 create-subnet \ --vpc-id vpc-0a1b2c3d4e5f67890 \ --cidr-block 10.20.1.0/24 \ --availability-zone ap-northeast-1a aws ec2 create-subnet \ --vpc-id vpc-0a1b2c3d4e5f67890 \ --cidr-block 10.20.2.0/24 \ --availability-zone ap-northeast-1c ``` VPCの/16をサブネット/24で切れば、同じ形の枠が256個取れる計算。公式ドキュメントは、コマンドラインやAPIでサブネットを作ると指定CIDRが正規形へ自動修正されると記載し、100.68.0.18/18を渡すと100.68.0.0/18になる例を挙げています。ホスト部にビットが立った指定でも通るため、計画表の値は前節のipaddressで正規形に直してから投入したい。 ### describe-subnetsで割当済みIPと予約分を突き合わせるAWS CLI確認 作成後は`describe-subnets`で、実際に使えるアドレス数を確かめます。`AvailableIpAddressCount`は予約5アドレスを引いた値を返すため、設計時の想定と一致するかを検算できる。 ``` aws ec2 describe-subnets \ --filters Name=vpc-id,Values=vpc-0a1b2c3d4e5f67890 \ --query "Subnets[].[SubnetId,CidrBlock,AvailableIpAddressCount]" \ --output table # 10.20.1.0/24 なら 251（256 - 予約5） # 10.20.0.0/28 なら 11（16 - 予約5） ``` /24で251、/28で11という値は、予約仕様から算出できる数と一致します。ずれていれば、想定と違うCIDRで作られたか、既にENIやマネージドサービスがアドレスを消費している。NATゲートウェイやVPCエンドポイント、RDSのようにサブネット内のIPを黙って使うリソースは多いため、実測値と計画値の差分は運用開始前に突き合わせたい項目です。 ## CIDR設計で失敗する典型パターンと広すぎる範囲の見送り基準 最後に、現場で繰り返される失敗と判断基準を言い切ります。CIDR設計はやり直しのコストが高く、初期の判断がそのまま運用の質になります。 ### 広すぎる範囲を避けて適切なプレフィックス長を選ぶための見送り基準 典型的な失敗は2方向。1つは範囲を広く取りすぎるパターンです。「余裕を持たせて」とVPCに10.0.0.0/8を割り当てると、他のVPCや拠点と接続する段になって重複し、経路が組めません。全社のプライベートアドレスは有限の資源で、1つのシステムが/8を占有する設計は見送るべき。/16を超える確保が必要かは、収容予定機器数から逆算して疑ってください。 もう1つは狭く取りすぎるパターン。将来の増設を考えずに/27（AWSでは予約5を引いて27台）で切り、半年後に枯渇して切り直しに追い込まれる例は珍しくありません。サイズ変更は認められていないため、切り直しはサブネットの作り直しとリソース移設を伴う。判断基準はこうです。必要台数の2倍が入るプレフィックスを選び、それでも/16より広い確保が要るなら、システムやサブネットの分割そのものを見直す。迷ったときは、広げるより分割するほうが安全です。 ### RFC 1918を使い切った後に選ぶ追加CIDRと除外される範囲 大規模な統合では、RFC 1918の3範囲を配り切ることがあります。AWSは追加CIDRとして100.64.0.0/10やRFC 1918以外の公開ルーティング可能なCIDRも/16〜/28で関連付けられる一方、169.254.0.0/16（リンクローカル）、198.19.0.0/16、既定VPCが使う172.31.0.0/16は関連付けできないと明記。「空いている範囲だから」と169.254系を計画表へ入れると、投入時点で弾かれます。 実務での順序は、まずRFC 1918の中で拠点・環境ごとに階層を切り、枯渇したら100.64.0.0/10を検討する形。ただしこの範囲はキャリアグレードNATと衝突しうるうえis\_privateもFalseを返すため、SaaS側のIP制限で「社内扱いされない」事故が起きます。追加する前に、既存の割り当てを集約で詰め直せないか確認したい。 ## よくある質問 CIDRの実務でよく検索される疑問に、設計判断へ直結する形で答えます。 ### CIDRとサブネットマスクの違いは何ですか？ 両者は同じ「ネットワーク部の長さ」を別の書き方で表したものです。CIDRはプレフィックス長を「/24」と数字で書き、サブネットマスクは「255.255.255.0」と10進数で書きます。/24と255.255.255.0は完全に同じ意味。CIDR表記のほうが短く経路集約も表しやすいため、現在のルーティングやクラウドではCIDRが標準です。根拠はRFC 4632にあります。 ### /24は何台のIPアドレスが使えますか？ /24は総アドレス数が256個で、そこからネットワークアドレスとブロードキャストアドレスを除いた254個をホストへ割り当てられます。ただしクラウド側が追加でアドレスを予約する環境では利用可能数が減る。AWSは各サブネットの先頭4つと末尾1つ、計5つを予約するため、/24の実効値は251個です。`describe-subnets`の`AvailableIpAddressCount`で実測できます。 ### CIDRの計算はどうやりますか？ 総アドレス数は「2の(32−プレフィックス)乗」、利用可能ホスト数はそこから2を引いた値で求めます。/26なら2の6乗＝64個、利用可能は62個。マスクへ直すときは、プレフィックス長のぶん左から1を並べ、8ビットごとに10進数へ変換します。手計算を避けるなら`ipaddress`で`ip_network`を作り、`num_addresses`や`subnets`を呼べば分割結果まで出ます。IPv6ではブロードキャストがないため2を引きません。 ### プライベートIPアドレスのCIDR範囲はどこですか？ RFC 1918で定められた10.0.0.0/8、172.16.0.0/12、192.168.0.0/16の3つで、インターネットに直接出ない社内ネットワークで自由に使えます。ただし拠点間やクラウドと接続するなら、どの範囲をどの拠点へ割り当てるかを事前に計画する必要がある。なお100.64.0.0/10は共有アドレス空間で、Pythonの`is_private`はFalseを返すため、3範囲と同一に扱うと誤判定になります。 ### IPv4とIPv6でCIDRの考え方は違いますか？ 表記の仕組みは同じですが、アドレス長がIPv4の32ビットに対しIPv6は128ビットで、プレフィックス長は最大128になります。ブロードキャストがないため2を引きません。運用ではサブネットに/64、サイト割り当てには/48または/56を使う。RFC 6177がRFC 3177の「一律/48」を撤回した点は押さえたいところで、AWSのVPCではIPv6サブネットを/44〜/64の4ビット刻みで指定します。 ## 関連記事 - [サブネットマスクとは？仕組みと計算方法・CIDR表記との違い](https://www.issoh.co.jp/tech/details/13334/)：2進数のマスクとAND演算の手順を追えます。 - [NATとは？NAPT（IPマスカレード）との違いとクラウド実装](https://www.issoh.co.jp/tech/details/13552/)：重複したまま接続する場合の逃げ道と限界。 - [AWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループ](https://www.issoh.co.jp/tech/details/15359/)：決めたCIDRを構築手順へ落とす全体像。 - [閉域網とは？VPN・専用線との違い](https://www.issoh.co.jp/column/details/13181/)：拠点間の方式選びとCIDR計画をあわせて検討できます。 - [クラウドセキュリティとは](https://www.issoh.co.jp/column/details/13266/)：許可範囲の絞り込みを多層防御の中で位置づけられます。 --- 出典: [CIDRとは？表記の読み方と計算方法・サブネット設計とAWS VPCでの使い方を実装者向けに解説]()（株式会社一創）