CIDR 設計で最も大切なのは、「他のネットワークと重ならない範囲を選ぶこと」と「後から足せる余白を、境界をそろえて残しておくこと」の2点です。いったん稼働したネットワークのアドレスを変えるのは大がかりな作業になるため、最初の計画で失敗を防ぐのが最も安上がりです。この記事では、VPS・クラウド・社内 LAN・VPN を組み合わせる前提で、範囲の選び方、階層的な割り当て方、重複チェックの方法、文書化までの手順を解説します。
1. 使う範囲を決める：プライベートアドレスの選び方
社内やクラウド内部で使うアドレスは、RFC 1918 で定められたプライベートアドレスから選びます。
- 10.0.0.0/8（約1,677万アドレス）
- 172.16.0.0/12（172.16.0.0〜172.31.255.255）
- 192.168.0.0/16
規模の大きい計画や、拠点・環境が増える見込みがある場合は、10.0.0.0/8 を土台にすると余裕を持って分けられます。
避けたほうがよい範囲
プライベートアドレスであっても、他の仕組みが既定で使う範囲と重なると、VPN 接続時やコンテナ導入時に経路が衝突します。
- 192.168.0.0/24 と 192.168.1.0/24: 家庭用ルーターの既定値に多く、在宅勤務者が VPN で社内につなぐと自宅 LAN と重なりがちです。
- 172.17.0.0/16 付近: Docker の既定ブリッジがこの範囲を使い、Compose で作るネットワークも 172.16.0.0/12 内などから自動で割り当てられることが多いです。既定値は Docker の設定（daemon.json の default-address-pools など）で変えられるため、サーバー側の計画と合わせて決めます。
- 100.64.0.0/10: 通信事業者のキャリアグレード NAT 用の共有アドレス（RFC 6598）です。Tailscale などのメッシュ VPN もこの範囲を使うため、社内の通常セグメントには割り当てないのが無難です。
- 169.254.0.0/16: リンクローカルアドレスで、クラウドのメタデータサービスなどにも使われます。
- 自社が持っていないグローバルアドレス: 「使われていなさそうだから」と内部で使うと、本物の宛先に届かなくなります。
2. 必要な大きさを見積もる
アドレスは足りなくなってから広げるのが難しいため、現在の台数ではなく、数年後の姿で見積もります。
- サブネットごとのホスト数: 現在の台数に、増設やオートスケールの上限を加えます。
- 予約アドレス: IPv4 ではネットワークアドレスとブロードキャストアドレスが使えません。クラウドではさらに事業者がサブネットごとに数個を予約します。AWS と Azure はサブネットごとに5個、Google Cloud はプライマリ範囲で4個が予約されると案内されています（2026年10月現在）。
- Kubernetes: Pod と Service の CIDR は、ノード数×ノードあたりの Pod 数でまとまった範囲を消費します。クラスターを作った後での変更は難しいことが多いため、最初に大きめに確保します。
- クラウドの上限: たとえば AWS の VPC に割り当てられる IPv4 CIDR は /16〜/28 の範囲です。上限を超える計画は複数 VPC への分割を前提にします。
3. 階層的に割り当てる
範囲を決めたら、上から順に「拠点・リージョン」「環境」「用途」のように階層をつけて切り分けます。階層ごとに境界をそろえておくと、経路やファイアウォールのルールを短いプレフィックスでまとめて書けるようになります。
一例として、10.0.0.0/8 を次のように分ける方法があります。
- 10.0.0.0/12：東京リージョン
- 10.0.0.0/16：本番
- 10.1.0.0/16：ステージング
- 10.2.0.0/16：開発
- 10.16.0.0/12：大阪リージョン
- 10.240.0.0/12：VPN クライアント・拠点間接続用
各環境の /16 の中で、さらに用途ごとに切ります。
- 10.0.0.0/20：Web・アプリ層
- 10.0.16.0/20：データベース層
- 10.0.32.0/20：管理・踏み台
- 10.0.48.0/20 以降：予備
この形にしておくと「本番全体は 10.0.0.0/16」「データベース層は 10.0.16.0/20」とルールを1行で書けます。環境をまたいで同じ用途を同じ位置に置く（データベース層はどの環境でも第3オクテット16〜31）ようにすると、アドレスを見ただけで役割が分かり、障害対応時の読み違いが減ります。
予備は「隣」に残す
予備の範囲は、拡張しそうなブロックのすぐ隣に、同じ大きさで残します。10.0.0.0/20 の隣の 10.0.16.0/20 を空けておけば、将来2つを合わせて 10.0.0.0/19 として扱えます。飛び飛びに予備を置くと、拡張したときに1つのプレフィックスでまとめられなくなります。
4. 重複がないかを機械的に確かめる
計画した一覧は、手で眺めるだけでなく、スクリプトで重複を確認します。既存のクラウド VPC、拠点 LAN、VPN、取引先との接続先も一覧に含めるのがポイントです。
import ipaddress
from itertools import combinations
plan = {
"tokyo-prod": "10.0.0.0/16",
"tokyo-stg": "10.1.0.0/16",
"osaka": "10.16.0.0/12",
"vpn-clients": "10.240.0.0/16",
"office-lan": "192.168.50.0/24",
"partner-x": "10.1.128.0/20",
}
nets = {k: ipaddress.ip_network(v) for k, v in plan.items()}
found = False
for (a, na), (b, nb) in combinations(nets.items(), 2):
if na.overlaps(nb):
found = True
print(f"重複: {a} {na} と {b} {nb}")
if not found:
print("重複なし")この例では、ステージングと取引先の範囲が重なっていることが検出されます。取引先や買収先など自社で変えられない範囲は、計画の段階で一覧に入れておかないと、接続の段になって NAT で回避するしかなくなります。
5. IPv6 も同時に計画する
IPv6 を使う、または将来使う可能性があるなら、IPv4 と同じ階層構造で計画しておくと運用がそろいます。IPv6 ではサブネットを /64 で切るのが基本で、SLAAC などの仕組みもこの長さを前提にしています。割り当てを受けたプレフィックス（/48 や /56 など）の中で、拠点・環境・用途の順にビットを割り振ります。クラウドでは IPv6 の範囲を事業者が割り当てる方式が多いため、各社のドキュメントで指定できる範囲を確認してください。
6. 文書化と変更管理
アドレス計画は、作った人の頭の中だけにあると、すぐに崩れます。
- 台帳を1か所に置く: 小規模ならスプレッドシートでも構いません。規模が大きくなれば、NetBox や phpIPAM のような IPAM ツールで、用途・担当・作成日を管理すると重複の申請を防げます。
- 割り当ての手順を決める: 新しいサブネットは台帳に登録してから作る、という順番を決めます。
- Infrastructure as Code と合わせる: Terraform などで管理している場合は、CIDR を変数として台帳と同じ値にそろえ、重複チェックを CI に組み込むと人為的なミスが減ります。
よくある失敗
- 最初の VPC を既定値のまま作り、後から VPN や別アカウントと接続する段で重複に気づく
- 本番・開発をぎりぎりの大きさで作り、オートスケールでアドレスが枯渇する
- 予備を飛び飛びに残したため、拡張後にルールが細切れになる
- 台帳を更新せずに手作業でサブネットを追加し、別チームと同じ範囲を使ってしまう
既存のネットワークを作り直す場合は、設定のバックアップを取り、検証環境で新しい範囲での接続を確かめてから、段階的に移行してください。
まとめ
- 範囲は RFC 1918 から選び、家庭用ルーター・Docker・キャリアグレード NAT・メッシュ VPN が使う範囲との重複を避ける
- 数年後の台数と、クラウドや Kubernetes が消費するアドレスを含めて大きさを見積もる
- 拠点・環境・用途の順に境界をそろえて割り当て、予備は拡張しそうなブロックの隣に残す
- 取引先や既存環境も含めた一覧をスクリプトで重複チェックする
- 台帳と変更手順を決め、IaC と値をそろえて運用する