CIDRとは？表記の読み方からサブネット設計・AWS VPCでの使い方まで実装者向けに解説

CIDR（Classless Inter-Domain Routing）は、IPアドレスとネットワークの範囲を「192.168.1.0/24」のようにスラッシュ付きで表す方法です。この記事では、プレフィックス長の読み方、サブネットマスクとの相互変換、割り当てられるホスト数の計算、そしてAWS VPCでのCIDRブロック設計や予約アドレスまで、実際にネットワークやクラウド基盤を設計する担当者の視点でまとめました。サブネットの分割と集約、IPv6での考え方の違い、設計で失敗しやすいパターンと見送り基準も扱います。

まとめ：CIDRの要点とインフラ設計での押さえどころ

CIDRは、IPアドレスの後ろに「/プレフィックス長」を付け、先頭何ビットがネットワーク部かを示す表記です。/24なら上位24ビットがネットワーク部、残り8ビットがホスト部で、2の8乗＝256個のアドレスを表します。実際にホストへ割り当てられるのはネットワークアドレスとブロードキャストアドレスを除いた254個です。

設計時に押さえるべき点は3つに集約できます。第一に、プレフィックス長からホスト数を「2の(32−プレフィックス)乗−2」で即算できること。第二に、クラウドや拠点間接続ではCIDR範囲の重複が致命傷になるため、割り当て前に全体のアドレス計画を決めること。第三に、AWS VPCのように各サブネットで5アドレスが予約される環境では、その分を見込んで範囲を切ること。範囲を広く取りすぎても他ネットワークと衝突し、狭く取りすぎても後から拡張できません。以降で計算方法と設計判断を具体的に見ていきます。

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のようにプレフィックス長が小さければ、1つのネットワークに多数の機器を収容できます。この境界がビット単位で動く点が、8ビット刻みしか選べなかったクラスフル方式との決定的な差です。

サブネットマスクとCIDR表記を相互変換する計算手順と対応表

プレフィックス長は、従来のサブネットマスク（255.255.255.0のような表記）と1対1で対応します。/24は先頭24ビットが1、残り8ビットが0のマスクなので、10進数では255.255.255.0になります。変換手順はシンプルで、プレフィックス長のぶんだけ左から1を並べ、8ビットごとに区切って10進数へ直すだけです。マスク側の2進数の仕組みやAND演算でネットワークアドレスを求める手順は、サブネットマスクの詳しい計算で解説しています。代表的な対応を下表に示します。

/32は単一のIPアドレスそのものを指し、ファイアウォールやルーティングで「この1台だけ」を表すときに使います。この相互変換を暗記する必要はありませんが、桁の並びを理解しておくと、設定ミスに気づきやすくなります。

クラスフルアドレッシングからCIDRへ移行した背景とRFC規定

クラスフル方式では、クラスAが約1677万台、クラスBが約6万5千台、クラスCが254台と、収容数が3段階に固定されていました。数百台規模の組織がクラスBを取ると大半のアドレスが遊び、逆にクラスCでは足りない、という無駄が生じます。1990年代前半、IPv4アドレスの枯渇とルーティングテーブルの肥大が現実の問題になりました。

CIDRはこの2つを同時に解きました。プレフィックス長を任意に切ることでアドレスの割り当て精度を上げ、さらに複数の連続したネットワークを1つのプレフィックスにまとめる「経路集約」でルーティングテーブルを圧縮したのです。現在のインターネットのルーティングはCIDRを前提に動いており、AWSやAzureのような主要クラウドのアドレス設計もすべてCIDR表記で行います。

CIDRブロックのアドレス範囲計算とプレフィックス別ホスト数

設計の現場でいちばん問われるのは「このCIDRブロックに何台入るか」です。ここは公式さえ覚えれば暗算できます。範囲計算とサブネット分割・集約、そしてIPv6での違いを順に見ます。

プレフィックス長ごとのホスト数早見表と計算式の具体的な使い方

あるCIDRブロックが持つアドレスの総数は「2の(32−プレフィックス)乗」で求まります。実際に機器へ割り当てられる数は、そこからネットワークアドレスとブロードキャストアドレスの2つを引いた値です。つまり利用可能ホスト数は「2の(32−プレフィックス)乗−2」になります。

/30はホストが2台だけなので、ルーター同士を結ぶ点対点リンクによく使われます。逆に/16は6万台超を収容できるため、大規模なVPCの土台に向いた大きさです。設計では「将来の増設ぶんを含めて2倍の余裕を見る」と、後述する再設計の手戻りを避けられます。

サブネット分割と集約（スーパーネッティング）の考え方と実務例

1つのCIDRブロックを、より長いプレフィックスで小さく割ることをサブネッティング（分割）と呼びます。たとえば10.0.0.0/16を、10.0.0.0/24、10.0.1.0/24…と256個の/24へ分ければ、部署やシステムごとにネットワークを分離できます。分割はセキュリティ境界を引くための基本操作です。

逆に、連続する複数のネットワークを短いプレフィックスで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」のように書きます。IPv4と大きく違うのは、ブロードキャストの概念がないため利用可能数から2を引かない点です。

運用上の目安として、1つのサブネットには/64を割り当てるのが一般的で、ここはステートレスアドレス自動設定（SLAAC）の前提になっています。組織へのサイト割り当てには/48や/56がよく使われ、/48なら内部で65536個の/64サブネットを切れる規模です。IPv6ではアドレス空間が桁違いに広いため、IPv4のように1ビットを惜しむ発想ではなく、階層を整理して割り当てる設計に切り替わります。

クラウドと業務システム構築で失敗しないCIDR設計の判断基準

ここからは概念ではなく、実際にクラウドや社内ネットワークを構築するときのCIDR設計に踏み込みます。判断を誤ると後戻りが難しい領域です。

AWS VPCのCIDRブロック設計と予約される5つのアドレス

AWSでVPCを作る際、CIDRブロックは/16から/28の範囲で指定します。ここで見落とされがちなのが、AWS公式ドキュメントに記載された「各サブネットの先頭4アドレスと末尾1アドレス、計5つがAWSにより予約される」という仕様です。/28（16アドレス）でサブネットを切ると、利用できるのは11アドレスにとどまります。

そのため、小さなサブネットを多数切る設計では予約ぶんの目減りが効いてきます。VPC全体は将来のサブネット追加を見込んで/16など広めに確保し、サブネットは用途ごとに/24前後で切るのが扱いやすい構成です。AWS上でこうしたネットワーク設計から移行・運用までを外部に相談したい場合は、AWSのインフラ構築で設計段階からの支援を受けられます。オンプレミスやマルチアカウント構成を含む要件では、初期のアドレス計画の巧拙が運用コストを左右します。

拠点間・オンプレ接続でのアドレス重複を避けるCIDR設計手順

VPCピアリング、VPN、専用線で複数のネットワークをつなぐとき、双方のCIDRが重複していると通信経路が確定できず接続できません。これはクラウド移行やM&A後のネットワーク統合で頻発するトラブルです。プライベートアドレス（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）は自由に使える反面、各拠点が無計画に192.168.0.0/24を使っていると、いざ接続する段階で衝突します。

対策は、接続する可能性のあるネットワーク全体で1つのアドレス計画表を持ち、拠点ごとに重ならないCIDRを事前に割り振ることです。拠点間をVPNや専用線で結ぶ構成の選び方は、閉域網とは？VPN・専用線との違いで整理しています。アドレス計画とあわせて接続方式を決めると、後の統合で詰まりにくくなります。

セキュリティグループとACLでのCIDR許可範囲の絞り込み設計

クラウドのセキュリティグループやネットワークACL、オンプレのファイアウォールでは、通信の許可・拒否をCIDR単位で指定します。ここでの設計が甘いと、意図せず広い範囲に穴を開けることになります。0.0.0.0/0はすべてのIPアドレスを意味するため、管理用ポートにこれを許可すると全世界に公開したのと同じ状態です。

許可範囲は、業務で本当に必要なCIDRまで絞り込むのが原則です。社内からのアクセスは自社の固定IPを/32で、拠点間は各拠点のCIDRだけを列挙します。CIDRの絞り込みはクラウド全体の防御設計の一部であり、クラウドセキュリティとはで扱う多層防御の考え方とあわせて設計すると、許可ルールの妥当性を判断しやすくなります。

CIDR設計で失敗する典型パターンと広すぎる範囲の見送り基準

最後に、独自の視点として、現場で繰り返される失敗と、そこから導ける判断基準を言い切っておきます。CIDR設計はやり直しのコストが高いため、初期の判断がそのまま運用の質になります。

広すぎる範囲を避けて適切なプレフィックス長を選ぶための見送り基準

典型的な失敗は2方向にあります。1つは範囲を広く取りすぎるパターンです。「余裕を持たせて」とVPCに10.0.0.0/8を割り当てると、他のVPCや拠点と接続する段になって重複し、経路が組めません。全社で使うプライベートアドレスは有限の資源であり、1つのシステムが/8を占有する設計は見送るべきです。目安として、単一システムのVPCで/16を超える確保が必要かは、収容予定機器数から逆算して疑ってください。

もう1つは狭く取りすぎるパターンです。将来の増設を考えずに/27（29台）でサブネットを切り、半年後に機器が増えて枯渇し、サブネットの切り直しに追い込まれる例は珍しくありません。判断基準はこうです。現時点の必要台数の2倍が入るプレフィックスを選び、それでも/16より広い確保が必要になるなら、システムやサブネットの分割そのものを見直す。この「2倍まで、ただし/8のような過大確保はしない」という幅の中で設計すれば、拡張性と重複回避を両立できます。迷ったときは、広げるより分割するほうが安全です。

よくある質問

CIDRの実務でよく検索される疑問を、設計判断に直結する形で回答します。

CIDRとサブネットマスクの違いは何ですか？

両者は同じ「ネットワーク部の長さ」を別の書き方で表したものです。CIDRはプレフィックス長を「/24」と数字で書き、サブネットマスクは「255.255.255.0」と10進数で書きます。/24と255.255.255.0は完全に同じ意味です。CIDR表記のほうが短く、経路集約も表しやすいため、現在のルーティングやクラウドではCIDRが標準になっています。

/24は何台のIPアドレスが使えますか？

/24は総アドレス数が256個で、そこからネットワークアドレスとブロードキャストアドレスを除いた254個をホストへ割り当てられます。ただしAWSのVPCなど、クラウド側が追加でアドレスを予約する環境では、その予約ぶん（AWSでは各サブネット5個）だけ利用可能数が減ります。

CIDRの計算はどうやりますか？

総アドレス数は「2の(32−プレフィックス)乗」、利用可能ホスト数はそこから2を引いた値で求めます。/26なら2の6乗＝64個、利用可能は62個です。サブネットマスクへ直すときは、プレフィックス長のぶん左から1を並べ、8ビットごとに10進数へ変換します。IPv6ではブロードキャストがないため2を引きません。

プライベートIPアドレスのCIDR範囲はどこですか？

RFC 1918で定められた10.0.0.0/8、172.16.0.0/12、192.168.0.0/16の3つです。これらはインターネットに直接出ない社内ネットワークで自由に使えます。ただし拠点間やクラウドと接続する場合は、どの範囲をどの拠点に割り当てるかを事前に計画し、重複を避ける必要があります。

IPv4とIPv6でCIDRの考え方は違いますか？

表記の仕組みは同じですが、アドレス長がIPv4の32ビットに対しIPv6は128ビットで、プレフィックス長は最大128になります。IPv6にはブロードキャストがないため利用可能数から2を引きません。運用ではサブネットに/64、サイト割り当てに/48や/56を使うなど、ビットを節約するより階層を整理する設計に変わります。

関連記事

• 閉域網とは？VPN・専用線との違い：拠点間接続でCIDRの重複を避けるとき、接続方式の選び方とあわせて読むと設計しやすくなります。
• クラウドセキュリティとは：セキュリティグループやACLでのCIDR許可範囲を、多層防御の設計の中で位置づけて考えられます。
• AWSのインフラ構築：AWS VPCのCIDR設計から移行・運用まで、要件に合わせた支援を相談できます。