Alphakt Insightsセキュリティ / SASE導入のアーキテクチャ設計
セキュリティ

SASE導入のアーキテクチャ設計

公開日:2026年4月8日 / 最終更新:2026年7月16日

企業のネットワーク環境は、ここ数年で構造的に変わりました。リモートワークの定着、SaaSの業務利用の拡大、クラウド上のワークロードの増加。従来の「社内ネットワークの境界を守る」アプローチでは、これらの変化に対応しきれなくなっています。

社内ネットワークとインターネットの境界にファイアウォールやプロキシを置き、「内側は安全、外側は危険」という前提で守る。このペリメタ型セキュリティが機能していたのは、ユーザーもアプリケーションも社内にあった時代の話です。今、ユーザーは自宅やカフェから接続し、アプリケーションはSaaSやクラウドに分散し、データは複数の環境を横断して流れています。守るべき「境界」が消失しているのです。

この環境変化に対するアーキテクチャ上の回答が、SASE(Secure Access Service Edge)です。Gartnerが2019年に提唱した概念で、ネットワーク機能(SD-WAN)とセキュリティ機能(SSE)をクラウド上で統合的に提供するアーキテクチャです。

本記事では、SASEの構成要素を整理した上で、導入パターン、段階的な移行設計、ベンダー選定の判断軸を、実務設計者の視点で解説します。「SASEとは何か」の概念解説ではなく、「SASEをどう設計するか」の実務判断に踏み込みます。

SASEは大きくSSE(Security Service Edge)とSD-WAN(Software-Defined Wide Area Network)の2つの柱で構成されます。この2つの役割を正確に理解することが、アーキテクチャ設計の出発点です。

SSEは、ユーザーとアプリケーションの間に介在し、セキュリティ制御を提供する機能群です。主要な構成要素は以下の4つです。

機能役割
SWG(Secure Web Gateway)Web通信の検査・フィルタリング。URLフィルタリング、マルウェアスキャン、DLP(Data Loss Prevention)を提供。従来のプロキシサーバーのクラウド版
CASB(Cloud Access Security Broker)SaaSアプリケーションの利用を可視化・制御する。シャドーITの検出、アクセスポリシーの適用、データの暗号化状況の監視
ZTNA(Zero Trust Network Access)ユーザーのID・デバイス状態・アクセス先を検証し、最小権限でアクセスを許可する。VPNの代替として、ゼロトラストの原則に基づくアクセス制御を実現
FWaaS(Firewall as a Service)クラウド上で提供されるファイアウォール機能。L3/L4のパケットフィルタリングに加え、L7のアプリケーション制御を提供

SD-WANは、拠点間やユーザーとクラウドの間のネットワーク接続を、ソフトウェアで制御・最適化する技術です。従来のMPLS(専用線)に対して、インターネット回線やLTE/5G回線を活用しつつ、アプリケーションの種類に応じたトラフィック制御(ポリシーベースルーティング)を行います。

SD-WANの主要な機能は以下の通りです。

SASEは、SSE(セキュリティ)とSD-WAN(ネットワーク)を統合することで成立するアーキテクチャです。しかし、現時点で両方を単一ベンダーの単一プラットフォームで完全に統合しているケースは多くありません。実態としては、SSEベンダーとSD-WANベンダーが別であるか、一方を先行導入して段階的に統合するパターンが多数です。この「理想と現実のギャップ」を理解した上で設計することが重要です。

SASEの導入アプローチは、大きく3つのパターンに分類できます。企業のネットワーク環境の現状、セキュリティの優先度、予算とスケジュールに応じて選択します。

既存のネットワーク基盤(MPLSやインターネットVPN)はそのまま維持し、セキュリティ機能(SSE)をクラウドに移行するパターンです。

適する状況:「まずリモートワーカーのセキュリティを強化したい」「VPNの代替としてZTNAを導入したい」「SaaS利用の可視化(CASB)を早急に実現したい」など、セキュリティの優先度が高い場合。

メリット:既存ネットワークを変更しないため、導入のリスクとスコープが限定的。セキュリティ効果を短期間で得やすい。

デメリット:ネットワークの最適化(ローカルブレイクアウト等)は実現しない。SD-WANを後から追加する際に、SSEベンダーとの統合性を改めて検証する必要がある。

WAN回線の見直しや拠点統廃合のタイミングで、SD-WANを先行導入するパターンです。

適する状況:「MPLSのコストを削減したい」「拠点の増減に柔軟に対応したい」「SaaS通信のパフォーマンスを改善したい」など、ネットワークの課題が先行している場合。

メリット:WAN回線コストの削減効果が定量化しやすく、投資対効果の説明がしやすい。拠点展開の運用負荷が軽減される。

デメリット:セキュリティの強化は別途対応が必要。SD-WAN導入だけではゼロトラストは実現しない。

SSEとSD-WANを同時に、できれば単一ベンダーのプラットフォームで導入するパターンです。

適する状況:ネットワークとセキュリティの刷新を同時に行う予算とスケジュールがある場合。新規拠点や新会社の立ち上げで、既存環境のしがらみがない場合。

メリット:ネットワークとセキュリティのポリシーを統合管理でき、運用の一貫性が高い。将来的な拡張性も確保しやすい。

デメリット:導入スコープが大きく、プロジェクトの複雑性とリスクが高い。単一ベンダーへのロックインリスクがある。全機能を同時に立ち上げるため、移行期間中の運用負荷が大きい。

実務上の推奨:多くの企業にとって現実的なのはパターン1(SSE先行)またはパターン2(SD-WAN先行)で段階的に導入し、最終的にパターン3(統合)に収束させるアプローチです。フルSASEを一度に導入する「ビッグバン」方式は、リスクが高く、成功事例も限られています。

SASE導入の実務で最も難しいのは、「既存のネットワーク・セキュリティ環境からどう移行するか」の設計です。既存環境を一夜にして停止することはできないため、新旧環境の共存期間をどう管理するかが成否を分けます。

Step 1:現状のトラフィックフローを可視化する。移行を設計する前に、現在のネットワークトラフィックがどこからどこへ、どの経路で、どの程度の量流れているかを可視化します。特に、ローカルブレイクアウトの対象になるSaaSトラフィック、拠点間通信、リモートアクセスVPNのトラフィック量を把握しておくことが、移行後のキャパシティ設計に不可欠です。

Step 2:移行対象を優先順位づけする。すべてのユーザーと拠点を一度に移行するのではなく、影響範囲が小さく効果が見えやすい対象から段階的に移行します。たとえば「まずリモートワーカーのVPNをZTNAに移行する」「次に本社のSaaS通信をSSE経由に切り替える」「最後に拠点間WANをSD-WANに移行する」という順序が一般的です。

Step 3:共存期間のポリシー設計。移行期間中は、新環境(SASE)と旧環境(既存FW/VPN/プロキシ)が並行稼働します。この期間のセキュリティポリシーの整合性をどう担保するかが重要です。「新環境のユーザーにはZTNAポリシーを適用し、旧環境のユーザーには既存VPNポリシーを維持する」といったハイブリッド運用の設計が必要です。

Step 4:旧環境の廃止基準を事前に定義する。「いつ旧環境を停止するか」の基準を移行開始前に定義しておきます。「新環境への移行率が90%に達した時点」「旧環境のセキュリティパッチサポートが終了する時点」など、定量的な基準を設けることで、旧環境がいつまでも残り続ける状態を防ぎます。

SASEのベンダー選定は、機能比較だけでは不十分です。機能面では主要ベンダーの差は縮まりつつあり、むしろ「自社の環境との適合性」と「運用のしやすさ」が選定の決め手になるケースが増えています。

判断軸確認すべきポイント
既存環境との統合性現在使用しているIdP(Azure AD/Okta等)との連携、既存FW/プロキシからの移行パス、エンドポイントエージェントの共存可否
PoP(接続拠点)の配置自社の拠点やユーザーの所在地に近いPoPがあるか。日本国内のPoPの数と場所。レイテンシーの実測値
管理コンソールの統合度SSEとSD-WANが単一の管理画面で運用できるか。ポリシーの統合管理、ログの統合分析が可能か
スケーラビリティユーザー数の増減、拠点の追加、M&A等に対する柔軟な拡張性。ライセンス体系の柔軟性
サポート体制日本語サポートの有無、障害時の対応SLA、導入支援の体制。SASEは運用が始まってからのサポート品質が重要

SASEのベンダー選定で最も大きな判断は、SSEとSD-WANを同一ベンダーで揃える(シングルベンダーSASE)か、それぞれ最適なベンダーを選ぶ(ベストオブブリード)かです。

シングルベンダーのメリット:管理の統合、ポリシーの一貫性、ベンダー間の責任分界の明確さ。運用の簡素化が最大の強み。

シングルベンダーのデメリット:特定ベンダーへのロックイン。各機能の深さがベストオブブリードに劣る場合がある。

ベストオブブリードのメリット:各領域で最も優れた製品を選択できる。既存環境との統合性が高い製品を個別に選べる。

ベストオブブリードのデメリット:ベンダー間の統合・連携の設計と運用が自社の負担になる。障害時の切り分けが複雑になる。

実務上の判断基準:社内にネットワーク・セキュリティの専門チームがあり、マルチベンダー環境の運用に耐えうる体制があればベストオブブリード。運用チームが少数で管理の簡素化を重視する場合はシングルベンダー。組織の運用体制が選定の最大の判断軸です。

本記事では、SASEの構成要素、導入パターン、段階的移行の設計、ベンダー選定の判断軸を整理しました。

SASEの導入は、「SASEを入れること」が目的ではありません。目的は、変化したネットワーク環境において、ユーザーの利便性とセキュリティを両立させることです。SASEはその目的を達成するための手段であり、自社の環境・体制・優先度に合った設計を行うことが、導入の成否を左右します。

ゼロトラストの設計原則を理解した上で、その具体的な実装パターンとしてSASEを設計できる力。これは、クラウド移行とリモートワークが常態化した現在のエンタープライズ環境において、セキュリティアーキテクトの中核スキルの一つです。

関連サービス

Alphaktは、AI×BPRを起点に戦略から実装・運用まで一気通貫で伴走します。(※プロトタイプのため導線はダミーです)

JOIN ALPHAKT

Alphaktで働くことに興味はありますか?

「提言して終わり」ではなく実装まで走り切る。基幹産業の変革に挑むメンバーを募集しています。

採用情報を見る →