FortiGate SD-WAN設定ガイド｜ゾーン・SLA・ルールと機種選定【FortiOS 7.6/8.0】

FortiGateのSD-WAN機能（Fortinetの製品名ではFortinet Secure SD-WAN、日本語では「セキュアSD-WAN」）は、複数のWAN回線を1つの論理インターフェースにまとめ、遅延・ジッター・パケットロスの実測値に応じて通信ごとに経路を選ぶ機能です。設定はGUIでも完結しますが、つまずくのは画面の操作ではなく「回線をSD-WANに入れる前に何を消しておくか」「ヘルスチェックの既定値をそのまま使ってよいか」の2点です。この記事では、ゾーン・メンバー・パフォーマンスSLA・ルールという4階層の構成を軸に、設定手順、ローカルブレイクアウト、回線冗長の確認方法、機種とライセンスの選び方までを扱います。あわせて、日本語の設定情報がFortiOS 6.2〜7.4世代で止まっている間に変わった仕様（7.6.3でのSSL-VPNトンネルモード廃止、FortiOS 8.0のSD-WANバンドル統合）も整理します。

まとめ

• FortiGateのSD-WANはゾーン → メンバー（WAN回線） → パフォーマンスSLA（ヘルスチェック） → SD-WANルールの4階層で構成する。CLIでは config system sdwan 配下にすべて収まる。
• 回線をメンバーに追加する前に、その物理インターフェースを参照しているスタティックルートとファイアウォールポリシーを外す。参照が残っているとメンバー登録が拒否される。
• パフォーマンスSLAの既定しきい値はレイテンシ5ms・ジッター5ms・パケットロス0%（FortiOS 7.6管理ガイド）。国内の一般的なインターネット回線でも5msは容易に超えるため、既定のままにせず実測値をもとに決める。
• SD-WANルールのストラテジーはManual／Best Quality／Lowest Cost (SLA)／Maximize Bandwidth (SLA)の4種類。Microsoft 365などのローカルブレイクアウトはInternet Service（ISDB）を宛先にしたルールで実現する。
• FortiOS 7.6.3以降、SSL-VPNトンネルモードは廃止されIPsec VPNに置き換わった。拠点でSSL-VPNを使っている環境は、アップグレード前に移行しないとリモート接続が切れる。
• SD-WAN専用機は不要で、既存のFortiGateがそのままSD-WAN機器になる。ただしISDBやIPSはFortiGuardのサブスクリプション次第で、FortiOS 8.0（2026年3月10日発表）でバンドル体系が統合された。

FortiGate SD-WANを構成する4階層｜ゾーン・メンバー・SLA・ルール

FortiGateのSD-WANは下から積み上がる4階層です。この対応関係を先に押さえると、GUIのどの画面が何を設定しているのかが一度で分かります。

ファイアウォールポリシーは、この4階層の上に乗ります。SD-WAN化したあとは個々のWANインターフェースではなくSD-WANゾーンを宛先インターフェースに指定するのが原則で、これによりポリシーを回線本数分だけ複製する必要がなくなります。ルーティングとポリシーがどの層で効いているのか曖昧なまま設定すると切り分けが難しくなるため、レイヤの整理が怪しい場合はOSI参照モデルの7階層と各層プロトコルの整理に一度戻ると早いです。

SD-WANの設定手順（FortiOS 7.6系）

メンバー登録前に外す既存参照（スタティックルート・ポリシー）

GUI：ネットワーク > SD-WAN > SD-WANゾーン。最初の関門はここです。インターフェースをSD-WANメンバーに追加しようとして「使用中です」と拒否される場合、そのインターフェースがスタティックルートかファイアウォールポリシーから参照されているのが原因です。wan1に既定ルート（0.0.0.0/0）が向いている状態のままメンバー化はできません。既存の設定を削除してからメンバーに追加し、そのあとでSD-WAN宛の既定ルートを引き直します。

本番機で作業する場合、この削除の瞬間に通信が切れます。リモートから作業するなら、切り戻し用のコンフィグをあらかじめ用意し、execute reboot で復帰できるよう保存前に検証するか、コンソール経路を確保しておきます。

config system sdwan
    set status enable
    config zone
        edit "virtual-wan-link"
        next
    end
    config members
        edit 1
            set interface "wan1"
            set zone "virtual-wan-link"
            set gateway 192.168.1.1
        next
        edit 2
            set interface "wan2"
            set zone "virtual-wan-link"
            set gateway 192.168.2.1
        next
    end
end

メンバーに gateway（回線側の次ホップ）を必ず入れます。ここが空だとヘルスチェックのプローブが出て行かず、後段のSLA判定がすべて失敗します。

パフォーマンスSLAの既定値の落とし穴と実測ベースのしきい値設計

GUI：ネットワーク > SD-WAN > パフォーマンスSLA。パフォーマンスSLAは、各メンバー経由でプローブを送って回線品質を測る仕組みです。プロトコルはPing、HTTP、TCP/UDPエコー、TWAMP、DNSなどから選べます。プローブ先には、経路が確実に分かれるサーバ（各ISPのDNSやパブリックDNS）を指定します。

config system sdwan
    config health-check
        edit "HC-Internet"
            set server "1.1.1.1" "8.8.8.8"
            set protocol ping
            set interval 500
            set failtime 5
            set recoverytime 5
            set members 1 2
            config sla
                edit 1
                    set latency-threshold 100
                    set jitter-threshold 30
                    set packetloss-threshold 2
                next
            end
        next
    end
end

注意すべきは既定値です。FortiOS 7.6の管理ガイドでは、SLAのしきい値はレイテンシ5ms（0〜10000000、既定=5）、ジッター5ms（同）、パケットロス0%（0〜100、既定=0）と定義されています。5msというのは同一都市内の専用線でようやく届く水準で、一般的な国内ブロードバンド回線ではまず超えます。既定のまま有効にすると全メンバーがSLA違反と判定され、ルールが期待どおりに動きません。上の例のように、実測したRTTに余裕を持たせた値（例：レイテンシ100ms、ジッター30ms、ロス2%）を先に決めてから設定します。

プローブ間隔 interval の既定は500ミリ秒、障害と判定するまでの連続失敗回数 failtime と復旧判定の recoverytime は既定5です。500ms × 5回で約2.5秒での切り替わりになります。音声やリアルタイム通信を守りたい拠点はこのままでよく、回線がもともと不安定で経路がフラッピングするなら failtime を10（＝約5秒）まで伸ばして揺れを吸収します。

SD-WANルールの評価順とストラテジー4種の使い分け

GUI：ネットワーク > SD-WAN > SD-WANルール。SD-WANルールは上から順に評価され、最初に一致したルールの経路選択が使われます。どのルールにも一致しない通信は、implicitルール（既定のロードバランス方式は source-ip-based）に落ちます。ストラテジーは4種類あり、選び方は通信の性質で決まります。

回線コストを下げる目的でSD-WANを入れるなら、第一候補はLowest Cost (SLA)です。「品質が保たれている限り安いブロードバンド回線を使い、SLAを割ったら専用線に逃がす」という設計がそのまま1つのルールで表現できます。対してBest Qualityはlink-cost-factorが最良の回線を常に選ぶため、品質が僅差で揺れると経路が入れ替わり、その都度セッションが張り直しになります。常時ベストを追うより、SLAを満たす範囲で経路を固定するほうが、経路切替時のセッション再確立を避けられる。音声・映像のように品質差が体感に直結する通信だけBest Qualityに寄せる、という切り分けが現実的です。Maximize Bandwidth (SLA)は、SLAを満たすメンバー全体に load-balance-mode の方式（既定は source-ip-based）で分散します。

SD-WANゾーン宛のスタティックルートとポリシーの書き換え

メンバー登録が終わったら、SD-WAN宛の既定ルートを入れます。ゲートウェイはメンバー側で定義済みなので、ルートはSD-WANインターフェースを指すだけです。

config router static
    edit 1
        set dst 0.0.0.0 0.0.0.0
        set distance 1
        set sdwan-zone "virtual-wan-link"
    next
end

ファイアウォールポリシーは、送信元をinternal、宛先インターフェースをSD-WANゾーンにします。ここを個別のwan1／wan2のままにしておくと、SD-WANルールで選ばれた経路とポリシーが噛み合わず、通信が落ちます。

設定直後の動作確認に使うCLI診断コマンド3種

GUIの緑色表示だけで判断せず、CLIで実測値とルールの適用結果を見ます。設定直後に確認すべきは次の3つです。

# 各メンバーの遅延・ジッター・ロスとSLA充足状況
diagnose sys sdwan health-check

# SD-WANルールがどのメンバーを選んだか
diagnose sys sdwan service

# メンバーの状態（up/down、優先度）
diagnose sys sdwan member

health-check の出力でパケットロスが100%になっている場合は、プローブ先までの疎通ではなくメンバーのgateway設定漏れを先に疑います。SLAは満たしているのに想定と違う回線に流れる場合は、service の出力でどのルールIDに一致したかを確認します。ルールは上から順に評価されるため、上位ルールの条件が広いと、下位のルールにはそもそも到達しません。

ローカルブレイクアウトの設定｜Microsoft 365を拠点から直接出す

ローカルブレイクアウト（DIA：Direct Internet Access）は、クラウドサービス宛の通信をデータセンター経由のバックホールに載せず、拠点のFortiGateから直接インターネットへ出す設計です。Microsoft 365のようにセッション数が多く遅延に敏感なサービスで効きます。

FortiGateでは、宛先IPを列挙する代わりにInternet Service（ISDB：インターネットサービスデータベース）をSD-WANルールの宛先に指定します。ISDBはアプリケーション識別ではなく、サービスごとの宛先IPレンジとポートの集合です。Microsoft 365の接続先IPは頻繁に変わりますが、ISDBはFortiGuard経由で更新されるため、IPリストの追随運用が要らなくなります。

config system sdwan
    config service
        edit 1
            set name "M365-Breakout"
            set mode sla
            set internet-service enable
            set internet-service-name "Microsoft-Office365"
            config sla
                edit "HC-Internet"
                    set id 1
                next
            end
            set priority-members 1
        next
    end
end

ISDBのMicrosoft 365は Microsoft-Office365 配下がサブグループ（Optimize／Allow／Default など）に分かれており、どれを指定するかで対象になるIPレンジが変わります。全部を一括でブレイクアウトさせるのか、遅延に敏感なOptimize系だけを直接出すのかは、指定するサブグループで決まります。

ここで見落とされがちなのが、SD-WANルールはあくまで経路選択しかしない点です。拠点から直接インターネットに出すということは、その通信がデータセンターの検査装置を通らなくなるということでもあります。ブレイクアウトさせる通信にもFortiGate側でIPS・アプリケーション制御・SSLインスペクションを効かせるポリシーを必ず併せて設計します。ここを省くと、ブレイクアウトは単なる検査の抜け穴になります。

回線冗長とフェイルオーバー｜切り替わらないときに見る場所

「回線が落ちたのに切り替わらない」現象の多くは、物理リンクが落ちていないことに起因します。ONU配下でL2リンクは上がったままISP側で通信だけが死んでいる状態では、インターフェースのリンクダウンは発生せず、ルートも生きたままです。SD-WANのパフォーマンスSLAが必要なのはまさにこの状況で、リンクの上下ではなくプローブの到達性で回線の生死を判定するのが本質です。

切り替わらないときの確認順序は次のとおりです。

• ヘルスチェックにメンバーが登録されているか（set members の指定漏れ）。登録されていないメンバーは監視対象外のまま生き続けます。
• SD-WANルールが参照しているSLA IDと、health-check側のSLA IDが一致しているか。IDがずれていると、SLA違反時のフェイルオーバーが発火しません。
• プローブ先が両回線から到達可能か。両メンバーのプローブ先を同一サーバにしていると、そのサーバ側の障害で両方同時にダウン判定になります。
• ルールがManualストラテジーになっていないか。ManualはSLAを見ないため、回線が劣化しても経路は固定されたままです。

拠点間VPNを冗長化する場合は、複数のIPsecトンネルをSD-WANメンバーとして登録し、トンネル単位でSLAを測ります。多拠点をハブ&スポークで組むならADVPNを併用します。全拠点間にトンネルを常設せず、スポーク同士の通信が発生したときだけ動的にショートカットトンネルを張る仕組みで、拠点数が増えてもトンネル数の組み合わせ爆発を避けられます。FortiOS 8.0で追加されたマルチパスIPsecトンネルは、この上で単一トンネルに複数経路を束ねて冗長性を高めるものです。VPNの構成そのものを見直す段階にあるなら、機器に依存しないオーバーレイ型の選択肢としてTailscaleの暗号化の仕組みと安全性と比較しておくと、拠点VPNをFortiGateで持つべきかの判断がしやすくなります。

SD-WAN機器としてのFortiGate選定｜機種とライセンス

SD-WAN専用機が不要な理由と既存FortiGateの流用条件

「SD-WAN機器」を探すと専用アプライアンスを買う前提で考えてしまいがちですが、Fortinet Secure SD-WANはFortiOSの機能として実装されており、すでに設置しているFortiGateの設定を変えるだけでSD-WAN機器になります。SD-WAN専用製品との違いはここで、UTM／次世代ファイアウォールとSD-WANが1台に同居するため、拠点に追加の筐体・電源・保守契約が増えません。

機種選定で見るべきはカタログのファイアウォールスループットではなく、IPSやSSLインスペクションを有効にした状態（Threat Protectionスループット）の数値です。ファイアウォールスループットは検査なしの上限値で、SD-WANでブレイクアウトさせる通信に検査をかける以上、実効性能はThreat Protection側で決まります。ここを取り違えると、カタログ値の数分の1しか出ないという結果になります。

エントリー帯はGシリーズに更新されており、FortiOS 8.0.0のサポート対象にも50G／51G／70G／71G／90G／91Gが含まれます。拠点規模との対応はおおよそ次のとおりですが、実効値は有効にする検査機能で変わるため、必ず最新のデータシートで確認してください。

ライセンスとサブスクリプションの考え方

経路制御そのもの（ゾーン、SLA、ルール）はFortiOSの設定で完結します。一方で、実運用に必要な次の要素はFortiGuardのサブスクリプションに依存します。

• Internet Service（ISDB）の更新：Microsoft 365などをサービス単位でブレイクアウトさせるなら必須。
• IPS・アンチウイルス・Webフィルタ：ブレイクアウト通信を検査するために必要。
• FortiManager：多拠点にSD-WANテンプレートを一括展開し、SLA違反や経路切替を横断で監視する場合。拠点ごとにGUIで設定する運用は、拠点が増えるほど設定差異の温床になります。

なお、FortiOS 8.0で調達単位そのものが変わっています（次章）。旧来のUTP／エンタープライズバンドル前提で見積を組むと構成が噛み合わないことがあるため、新規調達時は最新のバンドル体系で確認してください。

FortiOS 7.6.3以降で変わった設計前提｜SSL-VPN廃止とバンドル統合

日本語で流通しているFortiGate SD-WANの設定情報は、Fortinet公式の設定ガイドPDFを含めてFortiOS 6.2〜7.4世代のものが中心です。4階層の考え方は変わっていないので手順自体は今も使えますが、その間に、拠点設計に直接影響する仕様変更が起きています。ここを知らずにアップグレードすると事故になります。

最大の変更はSSL-VPNトンネルモードの廃止です。FortiOS 7.6.3以降、SSL-VPNトンネルモードはIPsec VPNに置き換えられ、GUIからもCLIからも消えました。IPsec VPN側がTCP 443をトランスポートとして使えるようになったため（UDP 500／4500がISPやCGNATで塞がれる環境でも通せる）、機能としては代替されていますが、移行は自動ではありません。アップグレード前に手動でIPsec VPNへ移行するか、FortiConverterで変換しておかないと、拠点のリモート接続が切れた状態でSD-WAN移行を迎えることになります。SD-WAN導入とOSアップグレードを同時に計画している環境では、ここが最優先の確認事項です。FortiOS 8.0.0では、エントリー機を中心にSSL-VPNのWebモード（エージェントレス接続）も利用できなくなっており、SSL-VPNに依存した運用は前提から見直しが必要です。

もう一つがFortiOS 8.0（2026年3月10日発表）です。SD-WAN関連では、オーバーレイとアンダーレイの接続性・集中管理・レポートを1つにまとめた統合SD-WANバンドル、複数経路を1本に束ねるマルチパスIPsecトンネル、SD-WAN環境の設定・切り分けを対話的に支援するAIエージェントが追加されました。新機能の全体像とアップグレード可否の判断材料はFortiOS 8.0の3つの革新領域を解説した記事にまとめています。

外部評価としては、SD-WAN分野のGartner Magic Quadrantで5年連続リーダー・実行能力の軸で最高位（2024年版が最新のSD-WAN単独MQ）、2025年はSASEプラットフォームのMagic Quadrantでリーダーに選出されています。ただし評価は稟議の裏付けにはなっても、自社の回線構成やアプリ要件との適合を保証するものではありません。

FortiGateを選ぶ基準と、選ぶべきでない場面

FortiGateのSD-WANが有利なのは、拠点にUTMを置く前提があり、セキュリティ検査とWAN最適化を1台に統合したい場合です。既存機器を活かせるため初期費用が抑えられ、セキュリティポリシーとSD-WANルールを同じ画面で管理できます。拠点数が数十規模でも、FortiManagerでテンプレート展開すれば運用は回ります。

一方で、次の条件に当てはまるなら、FortiGate SD-WANは最適解ではありません。

• WAN回線・SD-WAN・運用をまとめて外部に委ねたい：回線とSD-WANをセットで提供するキャリア型マネージドSD-WANのほうが、自社に運用要員を置かずに済みます。FortiGateは自社（または保守ベンダー）でSLA設計とルール設計を持つ前提の製品です。
• 拠点にハードウェアを置きたくない：クラウド側で完結させたいなら、FortiSASEのようなSASE型に寄せる判断のほうが素直です。
• マルチベンダーのWANをそのまま統合したい：SD-WANの効果はFortiGateで両端を揃えたときに最大化します。片端が他社機のままでは、SLAベースの経路制御が機能しません。

また、FortiGateはインターネットに面する機器である以上、脆弱性対応の運用が前提になります。過去には認証バイパスの深刻な脆弱性（CVE-2024-55591）も公表されており、SD-WANで拠点をインターネットに直接出す設計にするなら、パッチ適用の体制とセットで考える必要があります。詳細はFortiOSの脆弱性対策と概要（CVE-2024-55591）、および直近の事例としてCVE-2026-31431「Copy Fail」の影響範囲とパッチ・緩和策を参照してください。

よくある質問

FortiGateのSD-WANに追加のライセンスは必要ですか。

ゾーン・パフォーマンスSLA・SD-WANルールによる経路制御はFortiOSの設定で構成できます。ただし、Microsoft 365などをサービス単位（宛先IPレンジ）で識別してブレイクアウトさせるInternet Service（ISDB）の更新や、ブレイクアウト通信を検査するIPS・アンチウイルスはFortiGuardのサブスクリプションに依存します。FortiOS 8.0で統合SD-WANバンドルが導入され調達体系が変わったため、必要なライセンスは最新の見積で確認してください。

SD-WANのインターフェースメンバーに追加できないのはなぜですか。

そのインターフェースがスタティックルートかファイアウォールポリシーから参照されているためです。wan1に向いた既定ルートやwan1を宛先にしたポリシーを削除してから、メンバーに追加してください。削除の瞬間に通信が切れるため、リモート作業ではコンソール経路を確保しておきます。

回線が劣化してもフェイルオーバーしません。どこを見ればよいですか。

diagnose sys sdwan health-check で対象メンバーが監視対象に入っているか、diagnose sys sdwan service でルールが参照するSLA IDとhealth-check側のIDが一致しているかを確認します。ルールのストラテジーがManualの場合はSLAを見ないため、劣化しても経路は切り替わりません。

パフォーマンスSLAのしきい値は何を基準に決めますか。

既定値はレイテンシ5ms・ジッター5ms・パケットロス0%ですが、国内の一般的なインターネット回線ではレイテンシ5msはまず超えます。まず各回線の平常時RTTとジッターを実測し、そこに業務上許容できる劣化幅を足した値を設定します。音声を通すならITU-Tの一般的な目安である片方向150ms以内を上限の目安に、余裕を持たせて決めるのが実務的です。

FortiOS 7.6以降にアップグレードするとき、SD-WAN以外に注意すべき変更はありますか。

FortiOS 7.6.3でSSL-VPNトンネルモードが廃止され、IPsec VPNに置き換えられました。GUI・CLIから設定項目が消えるため、SSL-VPNでリモートアクセスしている環境はアップグレード前にIPsec VPNへ移行する必要があります。IPsec側はTCP 443も使えるため、UDPが塞がれた環境でも代替できます。

関連記事

• FortiOS 8.0が登場した背景とネットワーク管理者が押さえるべき3つの革新領域
• Fortinet製FortiOSの脆弱性対策と概要（CVE-2024-55591）
• CVE-2026-31431「Copy Fail」とは？影響範囲と今すぐ行うべきパッチ・緩和策をわかりやすく解説
• OSI参照モデルとは？7階層の役割・各層プロトコル・TCP/IPとの違いを解説
• Tailscaleの安全性は大丈夫？暗号化の仕組み・脆弱性リスク・料金・使い方を解説【2026年最新】