CIDR・アドレス空間の設計 — 将来の接続を見据えた割り当て計画

IPアドレスを場当たりで割り当てた結果、VPCピアリングやサイト間VPNを引いた段階でサブネットが衝突し、設計を根本から見直す羽目になる。CIDRの設計は「今動けばよい」という発想で終わらせてはいけない。将来の接続・統合を見越して最初に空間を区切り、誰が何をどの範囲で払い出すかを決める判断こそが、後からの無駄な再設計を防ぐ核心になる。どの粒度で確保し、環境・拠点・用途をどう分けるかを、接続が発生する前に決めておく必要がある。

アドレスを行き当たりで割ってピアリング時に衝突する構造

衝突が「接続フェーズ」で発覚する理由

IPアドレスの割り当てを後回しにしたまま構築を進められるのは、単一VPCや単一拠点で完結している間だけです。環境同士を接続する段階——VPCピアリング、Transit Gateway、サイト間VPN、Direct Connect——に入って初めて、重複が致命的な問題として浮上します。単体では正常に動いていたネットワークが、接続した途端にルートが通らなくなるのは、IPルーティングが「宛先を一意に特定できること」を前提としているからです。重複するCIDRがある場合、ルーターは宛先が曖昧と判断し、一方の経路を隠蔽するか、予測しない方向へパケットを転送します。発覚が遅いほど、修正のために動かし直すリソースの数も増えます。

10.0.0.0/8の中でも衝突は起きる

プライベートアドレスの中で最も広い10.0.0.0/8を使っていれば衝突しない、という誤解が根強く存在します。しかし空間が広くても、誰も管理しなければ同じ範囲を別々の担当者が払い出すことは容易に起きます。現場でよく聞く話として、開発環境と本番環境に同じ10.0.0.0/24を割り当て、統合テスト環境でVPNを繋いだ瞬間にルートが衝突したというケースがあります。この場合、どちらかの環境のアドレスを変更する作業は、EC2インスタンスやロードバランサー、セキュリティグループのルール更新まで波及し、数十時間単位の手戻りになります。10.0.0.0/8という広大な空間も、計画なしには衝突を防げません。

アンチパターン——コピー&ペーストで複製されるアドレス

もっとも頻繁に見られるアンチパターンが、新しい環境を構築する際に既存の設定をそのままコピーするやり方です。TerraformやCloudFormationのコードを複製して環境名だけ書き換えたとき、CIDRの値が書き換わっていないケースが典型例です。3〜5環境程度なら手作業でも気づける可能性がありますが、マイクロサービス化や複数プロジェクトの並行が進んで環境数が20を超えると、どこで何を使っているかの全体像が誰の頭にも入らなくなります。台帳がなければ把握できず、把握できなければ衝突を事前に防ぐ手段がありません。コードのコピーは作業を速く見せますが、アドレス空間の汚染は静かに蓄積していきます。

アドレス空間をどの単位で確保するかの判断

/8・/16・/24のどこを区切りにするかという問い

アドレス空間をどの単位で切るかは、設計の最初に決まる最重要の判断です。基本的な考え方は、「組織全体の割り当て範囲」→「拠点またはアカウント単位」→「環境またはサービス単位」→「用途別サブネット」という階層で委任していく構造です。たとえば、組織全体に10.0.0.0/8を確保し、リージョンや部門ごとに/12または/16を割り当て、その中で各環境が/20〜/24を使う、という階層が現実的な基準の一つになります。どの単位で区切るかは、管理責任の境界と一致させることが重要で、「この/16はクラウド基盤チームが管理する」という宣言をアドレス体系に埋め込む意識で設計することが、後の混乱を防ぎます。

将来の拡張係数をどう見積もるか

現在の規模から将来を見積もる際によく使われる判断基準は、「3〜5年後に環境数が3倍になっても対応できるか」を確認することです。現在10環境を運用している組織が30環境に増えても吸収できる空間があるかどうか。サブネットを切り出す際に、将来のAZ追加やサービス分割を想定して余裕を持てているか。具体的には、現在使用しているサブネット数の4倍程度の空間を確保しておくことが、無駄な再設計を回避できる目安として機能します。ただし、この係数はオンプレミスとクラウドで意味が変わります。クラウドではVPC作成後にCIDRを変更できないため、最初の判断が運用全体を縛る期間が長くなります。

クラウドとオンプレで単位感が変わる理由

オンプレミスでは、サブネット分割がスイッチやルーターの構成変更を伴うため、後から変更するコストが物理的な工事として現れます。一方、AWSのVPCやAzureのVNetでは作成後のCIDR変更が原則できないため、やり直しには付随するリソースの移行が必要になります。違いは「変更コストの性質」で、オンプレは物理工事コスト、クラウドはVPC再作成に伴うリソース移行コストとして現れます。共通するのは「最初の設計変更が高くつく」という点です。クラウドでは開発環境を気軽に作れる分、アドレスの払い出しも気軽になりがちで、それが後の衝突を引き起こす一因になっています。

環境・拠点・用途でどう割り当てを分けるか

環境（dev/stg/prd）の分け方

環境ごとにアドレスレンジを明確に分けることで、誤接続と経路の混在を防ぎます。典型的な分け方は、開発・ステージング・本番それぞれに独立した/16を割り当て、その中でサブネットを切る構成です。重要なのは、環境間の経路を引くときに常に重複なく識別できる状態を維持することです。開発からステージングへのアクセスが必要であれば、重複しないアドレス空間の上でピアリングやルーティングを設計します。環境をまたぐ通信が発生するたびに「この経路が本番に抜けていないか」を確認できるのも、環境ごとに空間を分けているからこそです。環境の境界はセキュリティの境界でもあるため、アドレスレンジの分離はアクセス制御の設計に直結します。

拠点・リージョン軸の考え方

複数拠点や複数リージョンにまたがる構成では、拠点単位でアドレスレンジを分けることが接続設計を単純にします。たとえば、東京リージョンに10.1.0.0/16、大阪リージョンに10.2.0.0/16、オフィス拠点に10.3.0.0/16を割り当てると、どのIPを見ても「どこのリージョン・拠点か」が一目で判断できます。この可読性は、障害調査やアクセスログの解析時に大きな差になります。ログに10.1.x.xが出れば東京リージョンのリソース、10.3.x.xが出ればオフィス拠点という読み方ができれば、調査の起点を絞る時間が短縮されます。拠点軸の割り当ては、ネットワーク担当者だけでなく、セキュリティチームやオペレーションチームにとっても追跡コストを下げる設計判断です。

用途（管理系・アプリ系・DBティア）の分離

同じ環境の中でも、管理用サブネット・アプリケーション用サブネット・データベース用サブネットを分けることで、セキュリティグループやネットワークACLのルールをシンプルに保てます。用途ごとにサブネットが分かれていると、「データベース層からインターネットへの直接通信を禁止する」というルールをサブネット単位で一括適用でき、個別リソースへの設定ミスが入り込む余地を減らします。用途軸で分けるサブネットは/24や/26単位で細かく切ることが多く、後述する「細かすぎる」問題と向き合う場所でもあります。管理系のサブネットは踏み台やモニタリングエージェントが乗る領域であり、アプリ系・DB系とは明確に分離することで、インシデント時の通信遮断も一元的に行いやすくなります。

比較表：大きく確保・都度払い出し・分割委任の向き不向き

3つのアプローチの概要

アドレス空間の管理戦略は大きく3つに整理できます。最初から大きなブロックを確保して階層で委任する「大ブロック確保型」、必要になった都度CIDRを払い出す「都度払い出し型」、組織またはチーム単位でレンジを委任して自律管理させる「分割委任型」です。それぞれ適した組織規模・拡張性・管理コストが異なるため、現在の組織の状態と将来の接続予定を照らし合わせて選ぶことが重要です。以下の比較表を設計判断の入口として活用してください。

観点	大ブロック確保型	都度払い出し型	分割委任型
初期設計コスト	高い（全体計画が必要）	低い（その都度決める）	中程度（委任ルールの整備が必要）
将来のピアリング可否	衝突しにくい	衝突リスクが高い	委任ルール次第
拡張性	計画内で高い	無計画に広がる	チーム内では高い
管理主体	中央集権型	各担当者任せ	チームに委任
向いている規模	中〜大規模（20環境以上）	小規模・単発プロジェクト	部門間で自律が必要な組織
主なリスク	確保しすぎて無駄になる	接続時の衝突	委任レンジの重複

向き不向きの判断軸

どのアプローチが合うかは、組織の成長スピードと接続予定の有無で決まります。将来的に他社システムや別チームのVPCと接続する可能性が少しでもあるなら、都度払い出し型は後になって高い確率で問題を引き起こします。一方、完全に独立して動かし続ける単体プロジェクトであれば、大ブロック確保型のオーバーヘッドは過剰です。判断の起点は「このネットワークは将来、他のネットワークと繋がるか」という問いにあります。接続予定があるなら、管理コストをかけても計画的に確保する方を選ぶべきです。

将来の接続・統合で重複させないための設計

M&A・買収先との統合シナリオ

企業間の統合やシステム統合が発生したとき、ネットワークの接続を迫られるケースは珍しくありません。構築を任されたある担当者は、買収先企業のネットワークと接続しようとした際に、双方が10.0.0.0/16を使っていたため、NAT二重変換という複雑な回避策を取らざるを得なかったと振り返っています。この種の統合作業は、アドレス変更だけで数か月・数十人月の工数がかかることもあります。M&Aを想定していない組織でも、グループ会社間の接続やベンダーとのプライベート接続は起こり得るため、「他社と被りにくいアドレスを選ぶ」意識は最初から持つべきです。172.16.0.0/12や192.168.0.0/16は小規模環境で多用されるため、大規模なクラウド構成では10.0.0.0/8から独自のサブレンジを選ぶのが一般的な判断です。

マルチクラウド・ハイブリッド接続の事前合意

AWSとAzureを併用したり、オンプレミスとクラウドを接続したりするハイブリッド構成では、接続を引く前にアドレス空間の調整が必要です。後から「AzureのVNetがAWSのVPCと重なっている」と気づいても、どちらかのVNetを作り直すことになり、付随するリソース移行を含めると大きな工数が発生します。事前合意の場として機能するのが、IP管理台帳（IPAMツールまたはスプレッドシート）を使った定期レビューです。環境を追加する前に台帳を参照し、重複がないことを確認するプロセスを設けることで、後から気づく衝突を防げます。接続が発生するタイミングは予測しにくいため、「繋がる前提」で台帳を整備しておくことが実用的な対策です。

割り当て台帳とレビュープロセスの設計

アドレス空間の管理は「誰でも同じ結論に辿り着ける仕組み」にすることが重要です。台帳に記録すべき最低限の項目は、割り当てCIDR・用途・環境・担当者・割り当て日・接続予定の有無の6項目です。これをGitで管理し、新規環境の追加時にプルリクエストを出してレビューを受けるフローにすると、変更履歴と承認記録が残ります。IPAMツール（AWS VPC IPAMやNetBoxなど）を導入している場合は、払い出しをツール経由に統一することで手作業による重複を防ぐ効果があります。台帳の整備は「作業が増える」ではなく、「後の接続設計を楽にする投資」として位置づけることが、組織への定着の鍵です。

細かく切りすぎて枯渇・大きく取りすぎて無駄の境界

/27以下のサブネットが引き起こす問題

サブネットを細かく切りすぎると、クラウドプロバイダの予約アドレスによって使用可能なIPが想定より少なくなります。AWSではサブネット内の先頭4アドレスと末尾1アドレスが予約されるため、/28（総数16）では使用可能なIPは11個しかありません。ここにALBを配置しようとすると、ALBは複数のIPアドレスを消費するため、数台のEC2を稼働させるだけでIPが枯渇します。サブネットのCIDRを後から変更するには付随するリソースの移行が必要になり、その工数は環境の規模によって10〜40時間以上に及ぶこともあります。「最初は小さくていい」という考えが、後の大きな手戻りを引き起こす典型例です。手を動かす段階の判断については実装手順に委ねるとして、設計として押さえるべきは「予約分を引いた実効アドレス数で最大リソース数を吸収できるか」という問いです。

/16を1環境に丸ごと渡す場合のトレードオフ

逆に、1つの環境に/16（65,536アドレス）を割り当てることは、アドレスの無駄遣いになる可能性があります。特に、組織全体で使えるアドレス空間が限られているとき、1環境が過大なレンジを占有すると他の環境への割り当てが圧迫されます。10.0.0.0/8では/16が最大256個しか取れないため、256を超える環境やテナントが必要な場合には/16単位では足りなくなります。SaaSやマルチテナント型のシステムを構築する場合は、テナントごとのサブネットを/24や/20に絞り、テナント数が増えても空間が枯渇しない設計にする必要があります。スケールの見通しを持たずに「とりあえず大きく取る」という判断は、後の割り当て困難を招くことがあります。

適切な粒度の目安と判断基準

適切な粒度を決める判断軸は3つです。1つ目は「このサブネットに乗せるリソースの最大数」。EC2インスタンスが最大50台なら/26（使用可能62アドレス）ではギリギリであり、/25（使用可能126アドレス）以上が安全な選択です。2つ目は「AZをまたぐ分割が必要か」。マルチAZ構成では1AZあたりのサブネットに分割するため、消費するアドレス数がAZ数に比例します。3つ目は「将来のスケールアウト余地」。現在の最大見込みの2倍程度を吸収できる余裕を持たせることが、再設計を回避する実用的な目安です。この3つの軸で評価すると、「細かすぎる」と「大きすぎる」の境界が具体的に見えてきます。

アドレス設計チェックリスト

新規ネットワークの設計時と、既存環境への接続追加時のいずれにも使えるチェックリストです。接続フェーズでの衝突や後の再設計リスクを下げるために、設計着手前にこれを通過させてください。

1. 組織全体のアドレス割り当てポリシー（使用レンジ・委任ルール）が文書化されているか
2. 新規CIDRが、既存の全環境・全拠点・外部接続先と重複していないことを確認したか
3. 今後3〜5年の環境数・サービス数の増加を見込んだ空間を確保しているか
4. 環境（dev/stg/prd）・拠点・用途の3軸でサブネットが分離されているか
5. クラウドプロバイダの予約アドレス数を考慮した上で、リソース最大数の2倍以上のアドレスを確保しているか
6. マルチAZ構成の場合、各AZのサブネットに十分なアドレスが確保されているか
7. 将来のピアリング・VPN・Transit Gateway接続を想定したルーティング設計が済んでいるか
8. 割り当て台帳（IPAMまたはスプレッドシート）に記録し、変更時のレビュープロセスが定義されているか
9. M&Aや外部接続で他社ネットワークと繋がる可能性を考慮し、172.16.0.0/12や192.168.0.0/16の多用を避けているか
10. サブネットの変更・拡張が必要になった場合の手順と責任者が明確になっているか