社内ネットワーク設計のポイント
- ネットワーク環境の最適化
社内ネットワーク設計の基本から、IPoE・LBOを前提とした最新構成、Wi‑Fi設計、回線・機器選定、移行手順までを体系的に解説。回線を増速しても遅い原因と改善ポイントが分かる実践ガイドです。
多くの企業で「回線を増速したのにネットワークが遅い」「SaaSやWeb会議の品質が安定しない」といった課題が顕在化しています。これらの問題は回線そのものではなく、現状把握が不十分なまま設計・構築が進められていることが原因であるケースが少なくありません。まずは現状の問題点・課題を整理し、その上で最適なネットワーク設計を行うことが重要です。
1. 社内ネットワーク構築の全体像（企業ネットワークの基本概念）
LAN と WAN：
LAN は拠点内（オフィスや工場）をつなぐ網（社内ネットワーク）、有線LAN・無線LAN（Wi‑Fi）を含みます。WAN は本社–拠点など離れた場所をつなぐ網（社内ネットワーク）です。まずは「拠点内のLAN」と「拠点間を結ぶWAN」を分けて考えると、構成の整理がしやすくなります。
1-1 レイヤ別の役割
社内ネットワークは「端末がつながる部分」「まとめる部分」「背骨となる部分」の3つのレイヤに分けて考えると、トラブル時の切り分けがしやすくなります。
1-2-1 拠点–本社 接続モデル（ハブ＆スポーク／メッシュ）
拠点と本社間の接続では、運用性を重視したハブ＆スポーク型か、可用性を重視したメッシュ型を選択します。
1-2-2 クラウド接続モデル（本社経由／LBO）
クラウドやSaaSへの通信は、本社経由とするか、LBOで直接インターネットへ抜けるかを用途別に設計します。
図1-1：拠点–本社–クラウド 接続モデル（比較）
ハブ＆スポーク：
本社（ハブ）に集約。運用は簡素、ただし本社に負荷集中します。また、本社で障害が発生すると、全社的に影響が出てしまいます。
メッシュ：
本社-拠点間または拠点間同士を直接接続。高可用だが構成と運用が複雑です。
図1-2：LBO（Local Breakout）
LBO（Local Breakout）：
クラウドやM365(Microsoft 365)等は拠点から直接インターネットへ抜けさせ、遅延と本社の出口混雑を大幅に低減。SD‑WANやPACファイル（Proxy Auto-Configuration）で対象トラフィックだけを直接化するのが一般的です。
ただし、インターネット出口が分散するため、セキュリティ制御やログの一元管理は別途設計（SSE/SWG等）が必要になります。
以下のような課題がある場合は、設計の見直しで改善できる可能性があります。
- 回線を増速しても遅い
- 拠点ごとに品質がばらつく
- M365やWeb会議が不安定
→ AtinaVPN では構成設計から支援可能です。
1-3 回線×ネットワークの関係（回線種別・帯域・冗長）
図2：PPPoE と IPoE（IPv6）の違い（混雑ポイントのイメージ）
ボトルネックは「WANの出口」で起きがちです。PPPoEは網終端装置の混雑で夜間低速化しやすく、IPoE/IPv4 over IPv6（v6コネクト/DS‑Lite等）は、PPPoEで問題になりがちな網終端装置の輻輳を避けやすく、結果として混雑リスクを低減しやすくなります。冗長化は回線二重化＋経路多様化 （キャリア/物理経路の分散）が基本です。
2. 要件定義のコツ（アプリ要件・拠点・将来拡張）
2-1 業務アプリの通信特性を棚卸し（SaaS／IaaS／オンプレ）
例：M365の“最適化カテゴリ”についてはバイパスが推奨。VDI/リモートデスクトップはRTTとジッタに敏感。IaaS直結（Site‑to‑Site）有無も明確化を。
2-2 ユーザー密度とWi‑Fi設計（AP台数／チャネル／5GHz中心）
高密度環境では5GHz中心（可能なら6GHzも）、チャネル幅はまず20/40MHzから、チャネル再利用と送信電力の均しが基本。会議室はピーク同時接続を前提にAP追加とチャネル設計を行います。
通常時だけでなく、月末・期末・キャンペーンなど業務が集中する期間のトラフィック増加も考慮して要件を定義します。ピーク時を想定した設計が、実運用での安定性につながります。
2-3 セキュリティ要件との両立（ゼロトラスト前提）
「境界で守る」から、認証・端末状態の継続検証へ。NIST SP800‑207の原則（最小権限／通信は常に保護／セッション単位の許可／動的ポリシー…）を、IdP（条件付きアクセス）, ZTNA, EDR/SIEMで段階導入。
- 設計時には性能や可用性だけでなく、情報セキュリティの三要素（機密性・完全性・可用性）をバランスよく満たすことも重要です。ネットワーク設計はセキュリティ設計と切り離せない点を意識する必要があります。
3. 設計の型（標準アーキ：有線LAN／無線LAN／WAN／インターネット）
3-1 IPoE/IPv4 over IPv6 と LBOを起点にした“クラウド前提”設計
図3：LBO 分離設計（社内は本社経由／SaaSは直出し）
前提
拠点のWANはIPoE/IPv4 over IPv6化（MAP‑E/DS‑Lite等）。PPPoEの渋滞点（網終端装置）を避け、クラウド直行（LBO）の土台を作る。
運用
M365等の最適化カテゴリはプロキシ/検査をバイパスし、PACファイルやSD‑WANのアプリ識別でDIRECT（プロキシを経由しない直接通信）へ。ファイアウォールは同一エンドポイントのACLを許可。
プロキシ環境下でLBOを行う場合、PAC設定・認証方式・証明書展開の整合性に注意が必要です。特にSaaSのエンドポイント変更に追従できないと通信失敗の原因となるため、FQDNベース制御やベンダー公開情報の定期更新が重要です。
ハブ＆スポークとLBOを併用する場合、拠点ごとの設計・展開・運用が課題になりがちです。設計から運用支援まで含めた検討は AtinaVPN の活用も可能です。
3-2 DNS / プロキシ / PACファイルの整合（DIRECT例外と追従）
原則
M365は最適化・許可カテゴリをDIRECTへ。PACファイルで対象FQDNを例外（DIRECT）にし、FW側も同FQDN/IPを許可・バイパス。Microsoftのエンドポイント更新に追従できる仕組み（APIやスクリプト）を採用。
実務Tip
ベンダーの「M365バイパス機能」だけに依存せず、漏れたホストを手当できる運用を。
4. 機器・回線の選定ポイント
4-1 回線（帯域・SLA・冗長／キャリア多重）
- 帯域は「同時ビデオ会議×人数×コーデック目安＋余裕」で算定。
- 冗長化はキャリア/物理ルートの多重まで踏み込み、SD‑WANやBGPでアクティブ/アクティブに。
- IPoE/IPv4 over IPv6の可否と方式（MAP‑E/DS‑Lite）も契約前に確認。
4-2 ルータ・FW・SW・AP（スループット／同時接続／ライセンス）
- ルータ/FW：スループットは実効値で比較（L7機能ON時）。ライセンス体系（機能・端末数・クラウド管理）もTCOに直結。
- スイッチ：PoEは将来のAP増設を見越し余剰30%。
- AP：5GHz中心、適切なチャネル幅（20/40MHz）、適正出力が安定の鍵。
4-3 監視・ログ収集（将来の可観測性）
- ネットワーク・無線LAN・セキュリティ・SaaSの横断メトリクスを一元化。ユーザー体感（遅延/損失/ジッタ）を可視化できる仕組みが運用コストを下げます。
5. プロジェクト計画と移行手順（段階導入）
5-1 PoC→パイロット→段階展開
本社の一角/小規模拠点でPoC、次に部署単位のパイロット、検証済みテンプレを横展開。Wi‑Fiはサイトサーベイ→AP最適配置→本番の順。
5-2 同時稼働・ロールバック計画
重要システムは旧環境と並走。WAN切替は時間帯分散し、プレチェックリストで戻し条件を明記。
5-3 運用設計（内製／アウトソース／ハイブリッド）
アラート閾値と一次対応Runbook、変更管理フローを文書化。可用性/SLAの責任分界も契約前に明確化。
6. “回線だけ増速”で体感が上がらない理由
出口の設計（PPPoE渋滞／プロキシ集中／DNS遅延／Wi‑Fi干渉）がボトルネックのままでは、帯域増強の効果は限定的。IPoE化＋LBO＋Wi‑Fi設計＋プロキシ例外のセットで改善します。
7. 保存版：設計前チェックリスト（10項目）
8. よくある質問（FAQ）
Q. LBOは「すべて直出し」にすべき？
A. いいえ。社内システムは本社／DC経由、SaaSやWeb会議など効果の大きい通信だけを直出しする「分離設計」が基本です。
Q. PACファイルは必須？
A. プロキシを使う環境では有効です。M365など一部宛先をDIRECTにし、FW側の許可とセットで運用します。
Q. 回線増速より先にやるべきことは？
A. まずボトルネックを計測で特定（RTT/ロス/ジッタ、IF使用率、無線再送など）。出口設計（IPoE化やLBO、プロキシ例外）の見直しが先になるケースが多いです。
9. ご相談導線（AtinaVPN）
多拠点のハブ＆スポーク＋LBOを段階導入したい、運用負荷も含めて見直したい場合は、インターネットVPN「AtinaVPN」へご相談ください。
- 掲載されている会社名、サービス名、ロゴ等は各社の商標または登録商標です。