拠点間・クラウド間接続の方式選定 — VPN・専用線・ピアリングの使い分け

拠点間やクラウド間の接続は、要件を曖昧なまま方式を決めると、後から帯域不足・経路競合・名前解決の干渉が重なって収拾がつかなくなる。IPsec VPN・専用線（閉域網）・クラウドピアリングの三方式は、目的・限界・運用負荷の構造がまったく異なる。本記事では「どの要件が来たらどれを選ぶか」という判断軸と、接続を増やしすぎる前に引くべき設計の境界線を、構築担当者の視点から解説する。

接続をその都度張って経路が把握できなくなる構造

アドホックな接続追加が積み重なるとどうなるか

拠点が3〜5か所の段階では、担当者がその都度VPNトンネルを張って接続を確保する運用が成立しやすい。しかし拠点数やクラウド環境が10を超えてくると、誰がどのトンネルをどの判断で作ったかが追えなくなる。現場では「気づいたら20本以上のトンネルが存在していた」という状況をよく耳にする。問題は経路数だけでなく、設定変更の影響範囲が把握できなくなることにある。あるトンネルのアドレス帯を変更したとき、それが別の経路に意図しない影響を与えても、全体像がなければ気づくのが大幅に遅れる。設計書なきアドホック追加は、後の障害対応コストを積み上げる構造的な落とし穴です。

経路の「全体像」が失われることの実害

経路把握が失われた状態で障害が起きると、切り分け工数が跳ね上がる。経路情報が設計書に残っていなければ、担当者は機器の設定を一枚一枚読み解くところから始めなければならず、中規模の構成でもこの調査に丸1〜2日かかる事例は珍しくない。加えて、フルメッシュ型の接続は拠点数nに対してトンネル数がn(n-1)/2に増えるため、拠点が10か所なら最大45本、20か所なら190本という規模に膨らむ。これを個別管理しようとすると、設定ミスの発生を構造的に避けられなくなる。経路の全体像がなければ、影響調査ではなく「復元調査」から障害対応が始まってしまう。

設計初期に接続トポロジーを決める意味

接続の全体構成を最初に決めておくことが、後々の複雑性を抑える最大の手段になる。Hub-and-Spoke（星型）は中継点で集中管理できる反面、ハブが単一障害点になるリスクを持つ。フルメッシュは各拠点が直接接続できる可用性を持つが、接続数の増加が管理コストに直結する。この選択は「拠点数の将来見通し」と「遅延の許容範囲」で決まることが多く、設計の初期段階で方針を固めておかなければ、後から組み直す際に大きな工数を要する。将来的に5か所以内に収まる見通しなら個別接続でも管理できるが、10か所を超える計画があるならハブを前提にした設計が安定する。

VPNで足りる要件・専用線/ピアリングが要る要件の違い

IPsec VPNが有効な場面

IPsec VPNは、インターネット回線の上に暗号化トンネルを張る方式で、初期費用が低く設備を持たない拠点にも適用しやすい。要件として「帯域が100Mbps前後まで」「遅延が数十msまで許容できる」「通信品質がベストエフォートで構わない」という条件が揃う場面であれば、専用線を引く合理性は薄い。本社から支社へのファイル転送やVDI接続、開発環境へのリモートアクセスなど、リアルタイム性よりも「暗号化された経路の確保」が主な目的となる用途で力を発揮する。ただし暗号化処理のオーバーヘッドにより実効帯域は物理回線の70〜80%程度に落ちることが多い点を、設計値に織り込む必要がある。

専用線・閉域網が必要になる条件

専用線（またはキャリアが提供する閉域網サービス）が必要になるのは、帯域保証・遅延の安定性・インターネット非経由という要件が加わったときです。金融系の取引システムや工場の生産管理システムのように、帯域変動が業務に直接影響する環境では、ベストエフォートのVPNは設計上の選択肢から外れる。コンプライアンス上「インターネット非経由」が求められる場面（医療情報の拠点間連携など）でも、閉域網の採用が前提になる。1Gbpsの帯域保証を要件に挙げる場合、VPNでは物理的な上限と暗号化オーバーヘッドがボトルネックになりやすく、専用線の方が設計の安定性が高い。

クラウドピアリングが選択肢になる条件

オンプレミスからクラウドへの接続においては、クラウドプロバイダーが提供するプライベート接続サービス（Direct Connect・ExpressRoute・Cloud Interconnectなど）が第三の選択肢として機能する。これらは「クラウドへのトラフィックをインターネットから切り離す」ことに特化しており、クラウドへの大量データ転送（1日あたり数TBを超える規模）や、低遅延が求められるクラウド連携処理に向いている。オンプレミス拠点同士の接続には原則使えないため、用途の境界を設計段階で明確にする必要がある。インターネットVPN経由でクラウドに接続している既存構成に後からピアリングを追加する際は、経路の競合が起きないよう優先制御を設計に含めることが重要です。

比較表：IPsec VPN・専用線・クラウドピアリングの特性整理

項目	IPsec VPN	専用線・閉域網	クラウドピアリング
経路	インターネット（暗号化）	キャリアの閉域網	キャリアバックボーン経由でクラウドへ直結
帯域保証	なし（ベストエフォート）	あり（契約帯域を保証）	ポート帯域の範囲内で安定
遅延の安定性	低い（インターネット依存）	高い（数ms以内に抑制可）	中〜高（インターネット経由より安定）
実効帯域の目安	物理回線の70〜80%程度	契約帯域をほぼそのまま利用可	ポート帯域（1Gbps・10Gbps等）の範囲内
インターネット非経由	非対応（暗号化のみ）	対応	対応（プロバイダー網を経由）
冗長化の難易度	低〜中（トンネル複数化）	中〜高（回線・終端装置の二重化）	中（物理ポートの冗長化オプション）
主な適用用途	拠点間・開発環境・支社接続	基幹系・金融・工場・医療	大量クラウド転送・低遅延クラウド連携
オンプレ拠点間接続	対応	対応	原則非対応

帯域・遅延・冗長性から見た方式選定

帯域の設計と上限の見積もり方

帯域の設計で最初に決めるべきは「最大同時接続時のトラフィック量」ではなく「業務が止まる帯域の下限値」です。上限ではなく下限を先に定義することで、要件を下回ったときに何が起きるかを設計段階で意識できる。VPNは暗号化オーバーヘッドにより実効帯域が物理回線の70〜80%程度になるため、100Mbpsの回線でVPNを張った場合、実効的に使えるのは60〜80Mbps程度と見積もっておくのが現実的です。専用線であれば契約帯域をほぼそのまま使える設計が可能で、バースト時の挙動も予測しやすい。クラウドピアリングは物理ポートの帯域（1Gbps・10Gbpsなど）の範囲内で安定した通信が得られるため、大量転送を伴う連携に向いている。

遅延要件の違いが方式を変える

遅延の要件は「何msを超えると業務に支障が出るか」を先に定義しておく必要があります。VoIPや遠隔制御・リアルタイムデータ連携のような用途では、往復遅延が150msを超えると品質劣化が体感できるようになる。インターネット経由のVPNでは、経路によって遅延が50〜100ms変動することがあり、安定した品質を保証できない。専用線や閉域網であれば、遅延の変動幅を数ms以内に抑えられる構成が選べる。クラウドピアリングもキャリアのバックボーンを経由するため、インターネットよりも遅延が安定しやすく、クラウド上のデータベースやAPIに低遅延でアクセスする用途に適している。遅延の要件定義を怠ると、構築後に「想定より応答が遅い」という問題が噴出しやすい。

冗長化の設計コストを方式ごとに考える

冗長化の設計は、方式によって複雑さが大きく異なります。VPNは複数のトンネルを並列で張ることで冗長化できますが、フェールオーバーの挙動をルーティング設定と組み合わせて事前に検証しておかなければ、障害時に切り替わらないケースがある。専用線は回線自体の冗長化に加えて終端機器の冗長化も必要になり、費用が積み上がりやすい。クラウドピアリングは物理ポートの冗長化オプションを提供しているが、有効化するかどうかは要件次第です。冗長化の判断は「何分の停止が業務損失に直結するか」から逆算して設計するのが基本で、SLA目標値を先に定義してから方式と冗長構成を選ぶ順序が推奨されます。

経路と名前解決をどう分けて設計するか

経路設計の分離原則

複数の接続方式を組み合わせる構成では、「どのトラフィックがどの経路を通るか」を明示的に設計する必要があります。静的ルーティングだけで管理しようとすると、接続が増えるたびに設定の整合性を人手で維持しなければならず、変更ミスが起きやすくなる。拠点数が10か所規模を超えてきたあたりから、BGPなどの動的ルーティングプロトコルを取り入れて経路情報を自動管理する設計が検討に値してきます。ただし動的ルーティングは設定が複雑になる分、フィルタリングポリシーの設計が重要で、意図しない経路が広告されないよう境界を明確にする必要があります。手を動かすフェーズの詳細は専門書やセミナーで確認するとして、ここでは「静的と動的をいつ切り替えるか」という判断点を押さえておくことが重要です。

名前解決の設計が経路設計に干渉する場面

DNSの名前解決が経路設計と整合していない場合、意図しない経路でトラフィックが流れるという問題が発生します。典型的なのは「クラウド上のリソースにプライベートIPで到達したいが、DNSがパブリックIPを返してしまう」というケースです。クラウドピアリングを使ってオンプレミスからVPC内のエンドポイントに到達しようとしても、名前解決がパブリック側に引かれていれば通信はインターネットを経由してしまう。これは設計上の抜け漏れとして現場でも頻繁に起きる問題で、経路とDNSを別々に設計した後で整合性を確認するステップを必ず入れる必要があります。接続方式の選定フェーズでDNS設計を同時に議題に上げておかないと、後工程で手戻りが発生します。

分割DNSとプライベートゾーンで整合を保つ

名前解決と経路の整合性を保つ設計手法として、分割DNS（Split DNS）とプライベートゾーンの組み合わせがあります。拠点からのDNSクエリをオンプレミスのリゾルバが受け持ち、クラウド向けの特定ゾーンだけをクラウドプロバイダーのプライベートゾーンへ転送するという構成です。これにより「内側からはプライベートIPを返し、外側からはパブリックIPを返す」という分離が実現します。転送ルールが増えると管理が煩雑になるため、ゾーン設計の記録と変更管理を接続設計と同一ドキュメントで維持する運用が推奨されます。設計段階でこの構成を想定していないと、ピアリング導入後に名前解決だけがうまく動かないという状態に陥りやすい。

接続を増やしすぎて経路が破綻する境界

管理可能な接続数の目安と複雑性の閾値

接続が管理限界を超えるタイミングは、単純な接続数だけでは測れません。接続数・方式の種類・担当者の人数・設計書の整備状況が組み合わさって、ある閾値で一気に把握困難になります。現場の体感として「手動で管理できるVPNトンネルは15〜20本程度が限界」という話をよく耳にします。これを超えてくると、変更時の影響調査に毎回2〜3時間が取られるようになり、変更を避けて塩漬けにされた設定が増えていく。そのまま放置すると、誰も構成を把握していない接続が本番環境に残り続けるリスクが高まります。構築を任されたある担当者が異動した後、後任が接続の全体像を把握するのに1か月かかったという話は珍しくありません。

破綻に至る前に引くべき設計の境界線

経路が破綻する前に設計を見直すシグナルとして、「変更申請があっても影響調査が完了できない」「設定変更後に予期しない疎通断が起きる」「担当者が異動したときの引き継ぎに2週間以上かかる」などが挙げられます。これらのシグナルが現れた時点では、すでに設計の複雑性が運用限界に達しています。抜本的な見直しを先延ばしにすることで、障害発生時の対応コストが乗数的に増加します。接続数が一定規模を超えた段階でHub-and-Spoke構成への集約や、オーバーレイ型の経路管理基盤の導入を設計の選択肢に加えることが、長期的な安定運用への布石になります。設計変更のタイミングは「破綻してから」ではなく「シグナルが出た時点」で判断することが重要です。

拠点間接続 選定チェックリスト

方式選定の前に以下の各項目を確認することで、要件の抜け漏れと設計の分岐点を明確にできます。回答がそろった段階で、適切な方式と構成の輪郭が見えてきます。

1. 帯域の下限を定義しているか。「最大トラフィック」ではなく「業務が止まる帯域の下限値」を数値で定めているか。
2. 遅延の許容範囲を用途別に定義しているか。往復遅延が何msを超えると業務影響が出るかを、用途ごとに明記しているか。
3. インターネット非経由の要件があるか。コンプライアンス・規制・セキュリティポリシーにより、閉域網が必要かどうかを確認しているか。
4. 接続先がオンプレミス拠点かクラウドかを整理しているか。クラウドピアリングはオンプレミス拠点間には使えないため、接続先の区別を設計段階で明確にしているか。
5. 将来の拠点数増加を見込んでいるか。5か所以内に収まる見通しか、10か所以上に増える計画があるかで、接続トポロジーの設計が変わる。
6. 冗長化の要件（RTOとRPO）を定義しているか。何分の停止を許容するかを定め、方式ごとの冗長化設計と対応させているか。
7. 経路設計とDNS設計を同一フェーズで進めているか。クラウドへのプライベート接続を使う場合、名前解決の設計と経路設計が整合しているかを確認しているか。
8. Hub-and-SpokeかフルメッシュかをVPN設計前に決めているか。接続トポロジーを先に決め、その上で方式と機器を選定する順序になっているか。
9. 変更管理と経路情報の記録先を決めているか。接続が増えても追跡できる形で設計情報を管理する仕組みを用意しているか。
10. 管理限界を超えた場合の移行計画があるか。接続数が増加した際に、構成集約やオーバーレイ管理基盤への移行を計画に含めているか。