SASE（Secure Access Service Edge、サッシー）は、SD-WANによるネットワーク接続と、SWG・CASB・ZTNA・FWaaSといったセキュリティ機能を、クラウド上のエッジで一体提供する枠組みです。Gartnerが2019年に提唱し、社内データセンターへ通信を集約する従来型のVPN構成が、SaaSとリモートワークの広がりで行き詰まったことを背景にしています。この記事では、SASEを構成する5要素の役割分担、ゼロトラストとの関係、SD-WANの有無で分かれるSSEとの違い、スモールスタートでの導入ステップ、そして製品選定と受託開発での線引きまでを、実装者の視点で整理する構成です。概念だけで終わらせないよう、Microsoft 365の例外リストをAPIで取り出す手順と、ZTNAの最小構成になる設定ファイルも実物で示しました。読み終えた段階で、自社がSASE全体を採るかSSEに絞るか、どこから着手するかを判断できる状態を目指します。
まとめ｜SASE導入で先に押さえる構成と判断の勘所
SASEの核心は、ネットワーク（SD-WAN）とセキュリティ（SWG・CASB・ZTNA・FWaaS）を別々の機器で積み上げるのをやめ、クラウド上の接続点（PoP）で一括して検査・制御する点にあります。拠点ごとにファイアウォールやプロキシを置く発想から、ユーザーとアプリの間にクラウドの検査層を挟む発想への転換です。
導入判断の分岐は明快です。既存のWANやSD-WANを刷新する余地があるならSASE全体、ネットワーク回線は温存してセキュリティだけ先にクラウド化したいならSSEを選びます。多くの企業にとって現実的な入口は、VPNの逼迫や情報漏えいリスクが顕在化している領域にZTNAとSWGを先行導入し、成果を確かめてから範囲を広げるスモールスタートです。
一度に全機能を単一ベンダーへ寄せる構成は運用が軽くなる一方、既存資産を活かしにくい局面もあります。もう一つ見落としやすいのが認証基盤で、ZTNAの判定はIdPから受け取る本人情報と端末情報に依存します。自社にネットワーク・セキュリティの設計運用体制がない場合は、製品選定と初期設計を外部の開発・インフラ支援に委ね、運用を内製へ移す進め方が破綻を避けやすい選択肢の一つです。
SASEの定義と登場背景｜境界型防御の限界とクラウド利用の広がり
SASEは2019年8月、Gartnerのレポート「The Future of Network Security Is in the Cloud」で提唱された概念です。ネットワークとセキュリティを別領域として扱う従来設計を統合し、クラウドから配信するサービスとして再構成する考え方を指します。単一の製品名ではなく、複数の機能をまとめた設計モデルである点を最初に押さえておきます。
調査会社の用語にとどまらず、標準化団体も定義を置いています。通信事業者の業界団体MEF（現在の名称はMplify Alliance）は、SASEのサービス属性をMEF 117として標準化し、SD-WANとセキュリティ機能、ネットワークエッジを組み合わせたクラウドサービスとして定めました。通信事業者が提供するSASEサービスの仕様書を読むとき、この標準の用語に沿って書かれていることがあります。
SASEが統合するネットワーク機能とセキュリティのクラウド配信
SASEが束ねる機能は、大きく2系統に分かれます。ひとつはSD-WANを中心とするネットワーク接続、もうひとつはSWG・CASB・ZTNA・FWaaSによるセキュリティ検査です。これらを世界各地に分散したPoP（Point of Presence）で提供し、ユーザーがどこにいても近くのエッジで通信を処理します。
従来はデータセンターに集約していた検査機能を、クラウド側へ持ち出したと捉えると理解しやすいです。拠点や在宅の端末は、いったん本社を経由せず、最寄りのPoPで認証・フィルタリングを受けてからSaaSやインターネットへ抜けます。通信経路が短くなり、拠点機器の管理負担も下がります。
境界型防御が限界を迎えた背景｜クラウドとリモートワークの普及
境界型防御は「社内は安全、社外は危険」という前提に立ち、社内ネットワークの出入口を固めるモデルでした。この前提は、業務データがSaaSやIaaSへ移り、社員が自宅や外出先から直接クラウドへアクセスする働き方の広がりで崩れました。守るべき資産が境界の外側に出てしまったからです。
VPNで全通信を本社へ引き戻す構成は、クラウド利用が主になると遠回りが常態化し、回線とVPN装置がボトルネックになります。コロナ禍以降にVPNの同時接続数が跳ね上がり、増強に追われた企業は少なくありません。SaaS提供側もこの遠回りを問題視しており、MicrosoftはMicrosoft 365のネットワーク接続の原則で、利用者に近い出口から直接接続させるローカルエグレス構成を推奨しています。SASEは、この「経路の非効率」と「境界前提の崩壊」の両方に同時に手を当てる設計として広がりました。
SASEを構成する5要素｜SD-WANとセキュリティ機能の分担
SASEはSD-WANとセキュリティ機能群からなります。それぞれが守備範囲を分担し、単体では埋められない穴を補い合う構造です。ここでは5要素の役割を、実務で判断に効く粒度で整理します。
SD-WANが担う拠点間とクラウドへの動的な経路制御と可視化
SD-WAN（Software-Defined WAN）は、複数回線をソフトウェアで束ね、通信の種類に応じて経路を振り分けるネットワーク層の要素です。Microsoft 365のような信頼できるSaaSはローカルブレイクアウトで直接インターネットへ流し、基幹システム向けは専用線へ寄せる、といった制御を動的に行います。
回線障害時の切り替えや、拠点ごとの通信状況の可視化もSD-WANの役割です。SASEの文脈では、このネットワーク制御とクラウド側のセキュリティ検査が同じ管理面でつながる点に価値があります。経路を決める層と検査する層が分断されていると、設定の齟齬が事故の温床になりがちでした。拠点側の装置でSLA監視やルールをどう組むかは、FortiGateのSD-WAN設定でゾーン・SLA・ルールを組む手順が具体例になります。
SWGとCASB・ZTNA・FWaaSが分担するクラウド側の防御機能
セキュリティ側は4つの機能が守備範囲を分けます。SWG（Secure Web Gateway）はWeb通信を検査し、危険なサイトへの接続やマルウェアのダウンロードを止めるゲートウェイです。プロキシとして通信を仲介し、URLフィルタリングやSSLインスペクションを担います。
CASB（Cloud Access Security Broker）は、SaaS利用の可視化と制御が持ち場です。誰がどのクラウドサービスに何をアップロードしたかを把握し、許可していないサービスの検知や、機密ファイルの持ち出し制御を行います。CASBが見つけにいく無許可利用の実態と公的資料での扱いは、シャドーITの該当例とBYODとの違いを整理した記事で詳しく確認できる内容です。FWaaS（Firewall as a Service）は、拠点ごとの物理ファイアウォールをクラウドの機能として置き換え、ポリシーを一元管理します。
| 要素 | 層 | 主な役割 |
|---|---|---|
| SD-WAN | ネットワーク | 回線束ねと経路制御 |
| SWG | セキュリティ | Web通信の検査 |
| CASB | セキュリティ | SaaS利用の可視化 |
| ZTNA | セキュリティ | アプリ単位の接続 |
| FWaaS | セキュリティ | FWのクラウド提供 |
ZTNA（Zero Trust Network Access）は次章で詳しく扱います。5要素は等価ではなく、リモートアクセスの課題が先ならZTNA、SaaSのガバナンスが先ならCASBというように、自社の痛みに応じて着手順に濃淡をつけて構いません。
ゼロトラストとSASEの関係｜考え方と製品実装レイヤーの対応
SASEとゼロトラストは混同されがちですが、抽象度が異なります。ゼロトラストは「何も信頼せず、都度検証する」という設計原則であり、SASEはその原則をネットワーク全域で実装するための具体的な枠組みです。原則と実装形態の関係にあると捉えると整理できます。ゼロトラストの全体像はゼロトラストとは何かを解説した記事で確認できます。
原則側の一次情報は米国の公的文書です。NISTが2020年8月に公表したSP 800-207 Zero Trust Architectureは、ポリシー決定点（PDP）と実施点（PEP）を分けて考える参照モデルを示しました。SASEのPoPは、この実施点をクラウドに置いたものと読むと対応が取れます。移行の段階を測る物差しとしては、CISAのZero Trust Maturity Model（Version 2.0）が、ID・デバイス・ネットワーク・アプリ・データの5本柱で成熟度を定義しています。
ゼロトラストの原則をネットワーク全域へ広げるSASEの実装形態
ゼロトラストが求めるのは、社内外を問わずアクセスのたびに本人性と端末状態を検証し、必要最小限の権限だけを与えることです。この原則を「Web通信ならSWG」「SaaSならCASB」「社内アプリならZTNA」と機能に割り付け、クラウドエッジで一貫して適用する実装がSASEにあたります。
言い換えると、ゼロトラストは設計思想、SASEは製品として買える形にした配信モデルです。設計原則をどう構成要素へ落とすかは、ゼロトラストアーキテクチャの構成要素を扱った記事と合わせて読むと、SASEの各機能がどの原則に対応するかが見えてきます。
ZTNAがVPNを置き換える仕組みと最小権限アクセスの適用範囲
ZTNAは、SASEのなかでゼロトラストを最も直接的に体現する機能です。VPNが「ネットワークに入れれば内部全体へ到達できる」構造だったのに対し、ZTNAは検証を通ったアプリケーション単位でのみ接続を許し、他のリソースは見えない状態に保ちます。攻撃者が1台を乗っ取っても横展開しにくくなります。
接続時にはユーザー認証に加え、端末のOSバージョンやセキュリティ対策の状態を条件に加えられます。このときの本人確認はSASE製品が自前で持つのではなく、Entra IDやOktaなどのIdPにSAMLやOIDCで委ねるのが一般的です。IdP連携の方式と選び方はIDaaSとSAML・OIDC・SCIM連携を実装視点で解説した記事で補えます。VPNの同時接続数に悩む組織が最初にSASEへ踏み出す入口として、ZTNAは選ばれやすい要素です。仕組みの詳細はゼロトラストネットワーク（ZTNA）とVPNの違いを解説した記事で補えます。
SASEとSSEの違い｜SD-WANの有無で分かれる二つの選択肢
SASEを検討すると必ず出てくるのがSSE（Security Service Edge）です。両者は別物ではなく、包含関係にあります。この関係を理解すると、自社がどちらを選ぶべきかが自然に決まります。
SSEはSASEからSD-WANを除いたクラウドセキュリティの集合
SSEは、Gartnerが2021年前後に定義した概念で、SASEからネットワーク機能であるSD-WANを取り除いた、セキュリティ側の集合を指します。構成はSWG・CASB・ZTNA・FWaaSの4機能です。「SASE ＝ SSE ＋ SD-WAN」という等式で覚えると関係を取り違えません。
Gartnerは2022年以降、SASEとSSEで別々のMagic Quadrantを公開しています。SSE部門ではZscaler・Netskope・Palo Alto Networksなどが上位に名を連ね、市場でもネットワークとセキュリティを切り分けて評価する見方が定着してきました。評価の順位は年ごとに入れ替わるため、選定時は最新の公表版を確認してください。
既存SD-WANの刷新要否で分かれるSASEとSSEの選び方
選択の分かれ目は、ネットワーク側に手を入れる必要があるかどうかです。拠点WANの更改時期が近い、回線構成を見直したい、といった事情があるならSD-WANを含むSASE全体が候補になります。逆に、既存の回線やSD-WANに不満がなく、セキュリティだけを先にクラウド化したいならSSEが合理的です。
実務では、まずSSE（とりわけZTNAとSWG）から着手し、WAN更改のタイミングでSD-WANを組み込んでSASEへ広げる段階移行がよく採られます。ネットワークとセキュリティの導入時期は必ずしも一致しないため、無理に同時刷新を狙わず、要否を分けて考える方が失敗を減らせます。
SASEの動きを手元で確かめる｜M365の例外抽出とZTNA設定の実例
SASEの設計で最初に手が止まるのは「どの通信をPoP経由にし、どれを直接抜くか」と「社内アプリをどう公開するか」の2点です。どちらも製品を買う前に手元で確かめられます。ここでは公式に公開されているAPIと設定ファイルの書式を使い、検証の第一歩を再現できる形で示します。
Microsoft 365のエンドポイントAPIで直接抜く通信の一覧を取り出す
Microsoftは、Microsoft 365が使うURLとIPアドレスをIP Address and URL web serviceとしてJSONで公開しています。各エンドポイントには接続カテゴリが付き、値はOptimize・Allow・Defaultの3種類です。遅延に最も敏感なOptimizeは、SWGのSSLインスペクションやPoP経由から外し、ローカルブレイクアウトの対象にする候補になります。
# clientrequestid は任意のGUID。ServiceAreas を絞り、IPv6を除外して取得する
curl -s "https://endpoints.office.com/endpoints/worldwide?clientrequestid=$(uuidgen)&ServiceAreas=Exchange,SharePoint&NoIPv6=true" \
| python3 -c '
import json, sys
for e in json.load(sys.stdin):
if e.get("category") == "Optimize":
print(e["serviceArea"], ",".join(e.get("urls", [])), "IP範囲:", len(e.get("ips", [])))
'
# 出力例（2026年10月2日に実行）
# Exchange outlook.cloud.microsoft,outlook.office.com,outlook.office365.com IP範囲: 11
# SharePoint *.sharepoint.com IP範囲: 52026年10月2日時点で取得したデータの版は2026081400でした。この一覧は随時更新されるため、Microsoftは別のversionメソッドで版を確かめ、問い合わせは1時間に1回までにするよう案内しています。SASE製品の例外リストへ手で写すと更新に追従できないので、版の変化を検知して取り込み直す仕組みまで含めて設計しておくと運用が崩れません。
cloudflaredの設定ファイルで社内アプリを1つだけZTNA公開する
ZTNAの動きを最小構成で確かめるなら、Cloudflare Tunnelが手軽です。社内サーバーに置いたコネクタ（cloudflared）が外向きにだけ接続を張るため、受信ポートを開けずにアプリ単位で公開できます。書式はCloudflare One docsのConfiguration fileに従い、下は勤怠システム1つだけを公開する例です。
# /etc/cloudflared/config.yml（UUIDは cloudflared tunnel create で発行された値に置き換える）
tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
ingress:
- hostname: kintai.example.co.jp
service: http://localhost:8080
# 最後は必ず全件一致のルールで締める（どのルールにも当たらない通信は404）
- service: http_status:404# ingressルールの書式を検証する
cloudflared tunnel ingress validate
# 指定URLがどのルールに一致するかを確かめる
cloudflared tunnel ingress rule https://kintai.example.co.jpこの設定だけでは「つながる」状態であり、ゼロトラストにはなっていません。公開したホスト名に対してIdP認証や端末条件を課すアクセスポリシーを管理画面側で設定して、初めてZTNAとして機能します。PoVではこの例のように対象を1アプリに絞り、認証の通り方とログの出方を確かめてから範囲を広げると判断材料がそろいます。
SASE導入の進め方｜スモールスタートで失敗を避ける実装ステップ
SASEは範囲が広く、全機能を一度に切り替えようとすると設計も移行も破綻しやすい対象です。成果を確かめながら範囲を広げる進め方が、事故と手戻りを抑えます。
PoV検証から始めるSASE導入のスモールスタート実装ステップ
着手の順序は、痛みの大きい領域を起点に置くと決めやすくなります。多くの組織では、VPNの逼迫やSaaSの野放図な利用が最初の課題になります。以下は、限定範囲で価値を検証（PoV）してから広げる典型的な流れです。
- 現状の通信経路と、守るべきアプリ・データを棚卸しする
- 最も困っている領域（VPN代替やSaaS制御）に絞ってZTNAかSWGを試験導入する
- 一部の部署・拠点で運用し、通信品質とポリシーの妥当性を測る
- 問題がなければ対象アプリと利用者を段階的に広げる
- WAN更改のタイミングでSD-WANを組み込みSASE全体へ拡張する
最初から全社・全機能を対象にせず、効果を数値で確かめてから投資を厚くする流れが要です。PoVの段階で、既存プロキシやVPNとの併存期間をどう設計するかまで決めておくと、切り替え時の混乱を避けられます。測る項目は、SaaSの応答時間、認証失敗の件数と理由、ヘルプデスクへの問い合わせ数の3つに絞ると比較しやすくなります。
SASE導入でつまずく典型的な失敗パターンと回避策の順序設計
つまずきの多くは、技術ではなく順序と設計に起因します。ありがちな失敗は、機能ごとにバラバラの製品を場当たりで導入し、ポリシーが二重化・矛盾するケースです。SWGとFWaaSで別々のルールを持つと、どちらが効いているか追えなくなります。
もう一つは、全通信をいきなりPoP経由へ切り替え、遅延やSaaSの動作不良で業務が止まるパターンです。信頼できるSaaSはローカルブレイクアウトで直接抜くなど、例外設計を先に決めておくと防げます。前章のAPIで取り出したOptimizeの一覧が、その例外設計の出発点として参照する一覧です。順序としては「棚卸し→例外設計→限定導入→拡張」を守り、ポリシーの一元管理を最初から設計に含めることが回避策になります。
SASE製品の選定観点｜単一ベンダー統合と二社構成の判断基準
SASE製品は、すべてを1社で揃える統合型と、ネットワークとセキュリティを別ベンダーで組む構成に大きく分かれます。ここは玉虫色にせず、条件ごとに推奨を言い切ります。
単一ベンダー統合か二社構成かで変わるSASE製品の選定軸と評価観点
単一ベンダー統合は、管理面が一つにまとまり、ポリシーの整合が取りやすい構成です。運用体制が薄い組織や、ネットワークとセキュリティを同時に刷新できる組織には、まず統合型を推します。設定箇所が分散しないため、運用ミス由来の事故を減らせます。
一方、既存のSD-WANやセキュリティ製品に強い資産があり、それを捨てる合理性がない場合は、二社構成で連携させる選択が現実的です。評価では、PoPの国内配置と実効遅延、SSLインスペクションの処理性能、既存IDaaSやSIEMとの連携可否を、カタログ値ではなく自社トラフィックでの実測で確かめます。SASEが出すアクセスログをSIEMへ送って相関分析に回すなら、取り込み形式と保存期間の設計を先に済ませておくことが必要です。その前提はSIEMの仕組みとEDR・SOCとの違いを解説した記事で整理しています。無停止に近い移行が可能かも、選定軸に含めます。
| 条件 | 推奨構成 |
|---|---|
| 運用担当が少ない | 単一ベンダー統合 |
| WAN更改が近い | SASE全体 |
| 既存SD-WANに満足 | SSEのみ追加 |
| 既存FWに投資済み | 二社構成で連携 |
受託開発でSASEを扱う場面と内製・外部委託を分ける判断条件
SASEの設計運用には、ネットワーク・認証基盤・クラウドの横断知識が要ります。社内にこの体制がある組織は、製品選定から運用まで内製で回して構いません。逆に、専任のネットワーク・セキュリティ担当がいない、あるいはクラウド移行と並行してSASEを進める組織では、初期設計を外部へ委ねる方が安全です。
とくに詰まりやすいのが、ZTNAの判定に使う本人情報と業務システム側の権限の整合です。IdPのグループ設計が粗いと、アプリ単位の最小権限を組もうとしても条件が書けません。SSOやID管理の土台から整えたい場合は、認証基盤・ID管理システム開発のように、IdP連携と業務アプリの認可設計をまとめて扱える相手を選ぶと、SASEとシステム側の整合が取りやすくなります。内製すべきは日々の運用、外部へ出すべきは初期設計と移行、という線引きが現実的な判断条件です。
SASEの導入・選定でよくある質問｜ゼロトラストとの違いも整理
SASEの検討時に相談の多い5つの疑問を、実務判断に必要な範囲で簡潔に答えます。
SASEとは何の略で、どう読みますか？
SASEはSecure Access Service Edgeの略で、「サッシー」と読みます。Gartnerが2019年に提唱した概念で、SD-WANによるネットワーク接続と、SWG・CASB・ZTNA・FWaaSといったセキュリティ機能を、クラウドのエッジで統合して提供する設計モデルを指します。単一製品ではなく、複数機能をまとめた枠組みである点が要点です。
SASEとゼロトラストの違いは何ですか？
ゼロトラストは「何も信頼せず都度検証する」という設計原則で、SASEはその原則をネットワーク全域に実装するための具体的な枠組みです。抽象度が異なり、対立する概念ではありません。NIST SP 800-207が示す原則を、SWGやZTNAなどの構成要素へ落とし込み、クラウドから配信する形にしたものがSASEにあたります。
SASEとSSEはどちらを選ぶべきですか？
SD-WANを含めて刷新するならSASE、既存のネットワークを温存してセキュリティだけクラウド化するならSSEです。SSEはSASEからSD-WANを除いた集合（SWG・CASB・ZTNA・FWaaS）で、「SASE＝SSE＋SD-WAN」の関係にあります。多くの企業はSSEから着手し、WAN更改の時期にSD-WANを加えてSASEへ広げます。
SASEの導入に必要な期間や費用の目安は？
範囲によって大きく変わります。ZTNAやSWGを一部門で試すPoVなら数週間から始められますが、全社のネットワークとセキュリティを統合するSASE全体では、要件定義から移行まで数か月から年単位になることもあります。費用は利用者数と機能範囲に連動するサブスクリプションが主流で、まず限定範囲で効果を測り、投資を段階的に厚くする進め方が無駄を防ぐ現実解です。
VPNはSASEに置き換えるべきですか？
VPNの同時接続数に悩んでいる、あるいは内部への横展開リスクを下げたい場合は、ZTNAへの置き換えが有力です。ただし一斉切り替えは業務停止のリスクを伴うため、対象アプリを絞って併存期間を設け、段階的に移すのが安全です。すべてのVPN用途が即座に不要になるとは限らず、置き換え範囲を見極めてから進めます。
関連記事
- ゼロトラストとは？境界型防御との違い・NIST7原則と導入判断を解説：SASEが実装するゼロトラストの設計原則を体系的に押さえたい方へ。
- ゼロトラストアーキテクチャとは？NISTの構成要素と設計ステップを解説：SASEの各機能が対応する構成要素を、設計の観点から確認できます。
- ゼロトラストネットワーク（ZTNA）とは？VPNとの違いと製品選定・導入判断を解説：SASEの入口になりやすいZTNAの仕組みを深掘りしたい方へ。
- IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携を実装視点で解説：ZTNAの判定に使う本人情報を、どのIdPからどう渡すかを確認できます。
- FortiGate SD-WAN設定ガイド｜ゾーン・SLA・ルールと機種選定【FortiOS 7.6/8.0】：SASEのネットワーク側を担うSD-WANの設定を具体的に知りたい方へ。
