FortiGate アップグレードパスの確認方法｜更新前の判断と注意点

はじめに

FortiGate（FortiOS）のファームウェアを更新する際は、現在のバージョンから目標のバージョンへ直接更新できるのか、途中のバージョンを経由する必要があるのかを事前に確認します。この更新順は機種とバージョンの組み合わせごとに異なり、ほかの機器で同じ更新を実施した経験があっても、そのまま当てはまるとは限りません。

さらに実務では、経路が分かった後に「その更新先を自環境で採用してよいか」「各段階で何を確認すれば次へ進めるか」「HA 構成ではどの順に切り替わるか」「問題が出た場合にどこまで戻せるか」を判断する必要があります。本記事では、公式の Upgrade Path Tool の使い方を起点に、Fortinet の公式資料を横断してこれらの判断材料を整理します。

結論として、アップグレードパスは、モデル・現在のバージョン（ビルド）・目標バージョンを公式の Upgrade Path Tool に入力して確認します。表示されるのは Fortinet が検証済みとする更新順で、直接更新できる組み合わせもあれば、中継版を経由する組み合わせもあります。ただし、経路が表示されることと、その更新先を自環境で採用できることは別の判断であり、Release Notes、既知の問題、サポート期間、製品間の互換性を確認したうえで、1 段階ずつ更新と確認を繰り返すことをおすすめします。

FortiGate アップグレードパスの確認方法

アップグレードパスは、開始版から目標版までの間に適用する、サポートされたファームウェアの順番です。Fortinet の Technical Tip では、アップグレードパスを機種ごとに定められた順番と位置づけ、工場出荷状態の機器であってもサポートされた経路に従うよう求めています。経路に従わなかった場合の影響としては、設定の消失、通信断、リモート管理の喪失、HA の同期異常、起動不良などが挙げられています（Technical Tip: FortiGate/FortiOS Upgrade Path）

確認に必要な情報と調べ方

Upgrade Path Tool には、モデル、現在のバージョン、目標バージョンの 3 つを入力します。現在のバージョンは、ビルド番号まで含めて記録しておくと、ツールの結果や Release Notes と照合しやすくなります。

get system status

上記の確認方法は、FortiGate 7.0.0 Firmware Upgrade Guide に記載された手順に基づきます。

Upgrade Path Tool で経路を確認する手順

Web 版の Upgrade Path Tool はログインなしで利用できます。サポートポータル（FortiCloud アカウントでログイン）の Support > Firmware Download > UPGRADE PATHS からも経路を確認できます。以下の画面項目名は、2026 年 9 月 24 日時点のツールページの表記に基づきます。

結果の読み方と更新回数の数え方

経路表に並ぶ版を上から順に 1 つずつ適用し、開始版から目標版までに経由する hop の数が更新回数になります。Technical Tip でも、各段階は個別のファームウェア更新として扱われ、更新ごとに機器が再起動すると説明されています。

2 つ目の例はモデルを指定しない説明用の記載で、現在の経路を示すものではありません。実際の経路は、自機のモデルでツールを使って確認することをおすすめします。

ツールは、Fortinet が検証した更新の組み合わせから、更新回数が最も少ない経路を返します。直接更新が表示された場合は中継版は不要で、中継版が表示された場合はその順番に従います。「1〜2 バージョン差なら直接更新できる」といった目安では判断できないため、組み合わせごとにツールで確認します。

参考: Fortinet Upgrade Path Tool
“Other paths may work, but only the shortest validated path is shown.”
（ほかの経路が機能する場合もありますが、表示されるのは検証済みの最短経路のみです）
https://docs.fortinet.com/upgrade-tool/fortigate

サポートポータルと Web 版ツールで経路が異なる場合について、Technical Tip ではどちらの経路に従ってもよいと説明されています。どちらを採用したかを手順書に残しておくと、作業当日の再確認や引き継ぎで迷いにくくなります。

作業直前の再確認

サポートされる経路は、新しい問題が判明した場合などに更新されることがあります。Technical Tip でも、似た更新を別の機器で問題なく実施済みであっても、作業前に最新の経路を確認するよう推奨しています。設計時に保存した結果と作業当日の結果を比較し、差がある場合は当日の経路と、各段階の Release Notes を確認し直します。あわせて、中継版を含むすべての段階のファームウェアイメージを、対象モデル向けに事前に入手しておきます。

目標版が選べない・経路が表示されない場合

「経路が出ない」という状況は、Web 版ツールで目標版を選べない場合と、FortiGate 本体の GUI でエラーが表示される場合で原因が異なります。

No valid upgrade path の問題は、過去のファームウェアが多い FortiGate-VM で起きやすいものの、物理アプライアンスでも発生すると説明されています。

参考: Troubleshooting Tip: No valid upgrade path error when upgrading the FortiGate firmware
“resolved in FortiOS versions 7.4.10 and 7.6.5”
（FortiOS 7.4.10 および 7.6.5 で解決済み）
https://community.fortinet.com/fortigate-3/troubleshooting-tip-no-valid-upgrade-path-error-when-upgrading-the-fortigate-firmware-219824

経路が確認できない状態で、大きくバージョンを飛ばして適用する進め方はおすすめしません。コンソール接続の用意は異常時の復旧手段であり、経路未確認のまま進める理由にはなりません。判断に迷う場合は、Fortinet TAC への確認を検討することをおすすめします。Technical Tip では、サポートケースの中で TAC が経路を指定する場合もあると説明されています。

更新先と作業条件を判断する

Upgrade Path Tool が示すのは「どの順番で更新できるか」であり、「その版を自環境で使ってよいか」は示しません。Firmware Upgrade Guide でも、更新に伴う停止や動作変更の可能性に触れたうえで、Release Notes の確認、経路の確認、バックアップ、検証環境でのテストを求めています。

参考: FortiGate 7.0.0 Firmware Upgrade Guide
“Firmware upgrades may cause temporary outages, configuration deprecations, or changes in feature behavior.”
（ファームウェアの更新は、一時的な停止、設定の廃止、機能動作の変更を引き起こす場合があります）
https://docs.fortinet.com/document/fortigate/7.0.0/firmware-upgrade-guide

目標版と中継版に共通する確認表

次の表は、目標版だけでなく経路上の中継版にも当てはめて確認します。中継版の稼働は一時的でも、各段階は通常の更新として実行されるため、その版の設定変換や動作変更の影響を受けます。

FortiManager や FortiAnalyzer を併用している環境では、FortiGate より先に管理製品側を更新する必要があると Technical Tip で説明されています。Security Fabric を構成している場合は、Release Notes の Fortinet Security Fabric upgrade に記載された更新順もあわせて確認します。

Feature／Mature と推奨リリースの扱い

FortiOS のビルドには Feature と Mature のタグがあります。Firmware Upgrade Guide では、Feature は新機能やバグ修正を含む版、Mature は大きな新機能を含まず、バグ修正とセキュリティ修正を優先する版と説明されています。タグは、GUI の Firmware 欄のほか、7.4 以降の System > Firmware & Registration（7.0／7.2 では System > Fabric Management）でも確認できます（Administration Guide: Firmware & Registration）

ただし、Mature タグや Fortinet の Technical Tip: Recommended Release for FortiOS は選定の参考情報であり、自環境で問題が起きないことを保証するものではありません。「1 つ前のパッチなら安定している」といった一般化も、判断の根拠にはなりません。どのタグの候補であっても、前節の確認表で判断することをおすすめします。

なお、FortiOS 8.0 は 2026 年 4 月 21 日に 8.0.0、9 月 15 日に 8.0.1 の Release Notes が公開されています。8.0 系を目標にする場合も、確認の観点は変わりません。

中継版・目標版で影響が出やすい変更例

経路上や目標版に次の版以降が含まれる場合は、目標版だけでなく該当する段階の Release Notes も確認します。

FortiOS 7.4 と 7.6 の EOES／EOS は、2026 年 3 月の Customer Support Bulletin（CSB-260330-1）で 1 年延長され、EOES は 7.4 が 2027 年 5 月 11 日、7.6 が 2028 年 7 月 25 日になっています（Technical Tip: FortiOS End of Support change for FortiOS v7.4 and v7.6）。延長の背景と SSL VPN からの移行事情は関連記事『FortiOS 7.4 EOES 延長と SSL-VPN から IPsec への移行実情』、強制アップグレードの条件と延期の方法は『FortiGate 強制自動アップグレードの仕様と無効化手順』で解説しています。

各更新段階で次へ進めるか確認する

複数段階の更新では、目標版に到達してからまとめて確認するのではなく、段階ごとに確認してから次へ進みます。物理アプライアンスの予備パーティションから戻せるのは最大 1 段階分であり、Technical Tip でも目標版だけでなく各段階でのテストが強く推奨されています。

1 段階分の作業の流れ

更新前後に確認するコマンドと判断

各コマンドの出力は更新前と更新後で比較します。表の「次へ進める目安」は本記事で整理した判断の観点であり、利用機能に応じて項目を追加します。

execute ping は FortiGate 自身が生成する通信で、ファイアウォールポリシー、NAT、ポリシールートは適用されません（Technical Tip: Pinging Out to Internet from Local Interface）端末やサーバーから FortiGate を通過する業務通信は、手順 1 で決めた確認項目に沿って、実際の端末・サーバーから本来の経路で疎通とアプリケーションの動作を別途確認します。

diagnose debug config-error-log read は Firmware Upgrade Guide の Upgrade validation で案内されている確認です。get system performance status は CPU、メモリ、セッション、稼働時間などの状態を示すもので、VDOM 数やポリシー数といった設定の概要を示すものではありません。

続行せず調査・復旧判断へ進む基準

• 経路表とは異なるバージョンやビルドで起動している
• 設定変換エラーが、利用中の機能（ポリシー、VPN、ルーティングなど）に関係している
• HA のメンバー間でバージョンがそろわない、または設定の同期が完了しない
• 拠点間 VPN、主要サービスへの通信、ログ送信など、重要な業務通信の異常が残る
• CPU やメモリの高負荷が続き、原因を判断できない

これらが 1 つでも残る場合は次の段階へ進まず、原因の調査と、切り戻すかどうかの判断へ移ることをおすすめします。次の版で解消する見込みがあっても、問題を抱えたまま進むと原因の切り分けが難しくなり、戻し先の選択肢も狭まります。

HA 構成（FGCP）でのアップグレードの動作

ここでは、2 台の FortiGate で構成した FGCP のアクティブ・パッシブ（A-P）クラスターを対象に、既定の uninterruptible 方式での動作を整理します。FGSP、FortiGate 6000／7000 シリーズ、Hyperscale の構成は、更新方式や既定値が異なるため、それぞれの製品資料を参照することをおすすめします。

更新方式の設定と FortiOS バージョンによる違い

HA クラスターの更新方式を決める設定名は、FortiOS 7.4.1 で変わっています（Technical Tip: FortiGate HA upgrade procedure and the status during the upgrade）

現在の設定は show full-configuration system ha で確認できます。local-only と secondary-only は、7.4.1 で追加された FGCP multi-version cluster upgrade に関わる方式で、特定のメンバーだけを更新する用途です。前提と手順が通常の更新と異なるため本記事の対象外とし、利用する場合は公式の説明に沿って検討することをおすすめします。

uninterruptible 方式での更新順序

この順序は Administration Guide: Upgrading FortiGates in an HA cluster の説明に基づきます。同ガイドでは、Secondary がすべて応答しなくなった場合、Primary は通常どおり動作を続け、Secondary が再参加するまで更新されないと説明されています。この順序で進めるには、開始前にクラスターの設定が同期しており、Secondary がクラスターに参加していることが前提です。Release Notes に HA の更新に関する注意がある版では、その記載を優先します。

Primary の選出と override

更新の完了後に元の Primary へ役割が戻るかどうかは、HA priority だけでは決まりません。Technical Tip では、クラスターの稼働時間の差、HA priority、override の有効・無効などの状態によって、元の Primary が戻る場合と戻らない場合があると説明しています。掲載されている例では、稼働時間の差が 5 分未満で、priority が大きいことを理由に、元の Primary が再選出されています。

参考: Technical Tip: FortiGate HA upgrade procedure and the status during the upgrade
“the original Primary may or may not resume as the HA Primary”
（元の Primary が HA Primary に戻る場合も、戻らない場合もあります）
https://community.fortinet.com/fortigate-3/technical-tip-fortigate-ha-upgrade-procedure-and-the-status-during-the-upgrade-129903

手順書では、override と priority の設定から更新後の Primary を事前に想定し、想定と異なる場合の扱い（そのまま運用するか、計画的に切り替えるか）を決めておくことをおすすめします。選出の優先順位は Technical Tip: FortiGate HA Primary unit selection process when override is disabled vs enabled で確認できます。

セッション引き継ぎと通信影響の限界

uninterruptible 方式でも、更新の途中で Primary の切り替えが発生します。切り替え時に既存のセッションを引き継ぐには session pickup の設定が必要で、既定では無効です。Firmware Upgrade Guide では、TCP の継続性のために session-pickup、UDP や ICMP のために session-pickup-connectionless を有効にするよう案内しています。

参考: Administration Guide: Pass-through sessions
“Not Supported; sessions have to be restarted.”
（プロキシベースのセキュリティプロファイルのセッションは非対応で、再開が必要です）
https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/126801/pass-through-sessions

このため、HA 構成であっても、更新中の通信影響がなくなるとは限りません。影響の程度は、利用機能、session pickup の設定、周辺のスイッチやルーターの切り替え動作によって変わります。保守作業枠は通信影響がある前提で設定し、許容できる範囲を業務側と合意しておくことをおすすめします。

各段階での HA の確認

チェックサムの一致は、同期対象の設定がメンバー間でそろっていることの確認です。ホスト名や HA priority のように同期されない設定の妥当性や、業務通信の正常性までは示さないため、前章の確認とあわせて判断します。

作業時間の見積もりと切り戻しの準備

所要時間の見積もり方

更新 1 回あたりの所要時間は、モデル、設定の規模、HA の有無、イメージの転送方法などで変わります。本記事で確認した公式資料の範囲では、一般的な FortiGate に共通する所要時間の目安は示されていませんでした。そのため固定値ではなく、次の 3 つを分けて見積もることをおすすめします。

処理時間

イメージの転送、書き込み、再起動、起動後にサービスが安定するまでの時間です。HA 構成では、Secondary と旧 Primary の更新がそれぞれ加わります。Upgrade Path Tool のページでも、各段階の間でサービスの安定を待つよう案内されています。

業務通信が使えない時間

単体構成では再起動中の転送停止、HA 構成では Primary 切り替え時の影響と、引き継がれないセッションの再確立が該当します。処理時間とは一致しません。

保守作業枠

処理時間に加えて、事前の状態記録、バックアップ、各段階の確認、切り戻しに必要な時間を含めた枠です。

保守作業枠は「事前作業 + 更新回数 ×（処理時間 + 安定待ち + 段階ごとの確認）+ 切り戻しに必要な時間」として積み上げます。処理時間には、検証環境や同型機での過去の作業記録など、自環境に近い条件で測った値を使うことをおすすめします。切り戻しに必要な時間は、次節で選ぶ方法（予備パーティションからの起動か、イメージの再導入と設定の復元か）によって大きく変わります。

切り戻し方法の選び方

Fortinet の公式資料では、ファームウェアのダウングレードはサポートされないとされています。一方で、直前の状態へ戻す方法や、旧版を再導入する方法は条件付きで案内されており、方法ごとに戻せる範囲と制約が異なります。

参考: Technical Tip: FortiGate/FortiOS Upgrade Path
“There are no supported downgrade paths for any firmware.”
（どのファームウェアにも、サポートされたダウングレードパスはありません）
https://community.fortinet.com/fortigate-3/technical-tip-fortigate-fortios-upgrade-path-185559

予備パーティションからの起動は Technical Tip: Selecting an alternate firmware for the next reboot で、execute set-next-reboot {primary | secondary} を使う方法として説明されています。ここでの primary と secondary はパーティション番号を指し、HA の Primary／Secondary とは関係ありません。

逆順の経路について、Technical Tip: FortiGate Firmware Downgrade for Minor Releases は、現地作業ができず戻し先の版の設定バックアップもない遠隔地の機器など、段階的なダウングレードしか選択肢がない場合に限り、Upgrade Path Tool の開始版と目標版を入れ替えて得た経路を逆にたどる方法を示しています。同じ記事では、HA クラスターをダウングレードすると全メンバーが同時にダウングレードされるため、短時間の通信断を見込むよう説明しています。

参考: Technical Tip: FortiGate Firmware Downgrade for Minor Releases
“only be utilized if a step-by-step firmware downgrade is the only option available”
（段階的なダウングレードが唯一の選択肢である場合にのみ使用すること）
https://community.fortinet.com/fortigate-3/technical-tip-fortigate-firmware-downgrade-for-minor-releases-148979

このため、逆順の更新は通常の切り戻し手順ではなく、ほかの方法を使えない場合の限定的な手段として扱うことをおすすめします。

あわせて、次の制約も確認します。Release Notes の Downgrading to previous firmware versions では、ダウングレード後に保持される設定は運用モード、インターフェース／管理 IP、静的ルート、DNS、管理者アカウント、セッションヘルパー、アクセスプロファイルに限られるとされています。新しい機種では起動時に BIOS レベルの署名と整合性のチェックが行われ、一定より古い版へ戻すと起動できない場合があり、このチェックは戻し方によらず適用されます。また、7.2.11、7.4.8、7.6.1 以降では管理者パスワードのハッシュ方式が PBKDF2 に変わっており、それより前の版へ戻す場合の管理者ログインに関する注意が Release Notes に記載されています（FortiOS 7.2.12 Release Notes）

「各段階のバックアップがあれば任意の段階へ戻せる」とは限りません。バックアップは取得した版に対応しており、戻すにはその版を再導入したうえで復元する必要があります。取得後に加えた設定変更は含まれない点にも注意が必要です。

事前に準備しておくもの

• 経路上のすべての版と、現在の版のファームウェアイメージ（対象モデル向け）
• 各段階の開始前に取得した設定バックアップ（ファイル名に版とビルドを含める）
• コンソール接続と、必要に応じて TFTP サーバー
• VM の場合は、ハイパーバイザー側のスナップショット
• 切り戻しの判断者、判断の期限、戻し先の版と方法を記載した手順書
• Fortinet サポートへの連絡手段（契約情報、シリアル番号）

Fortinet TAC はファームウェア更新作業の待機サポートを提供しておらず、問題が発生した時点で連絡するよう案内されています。作業時間帯と連絡手順は、社内の体制とあわせて事前に決めておくことをおすすめします。

まとめ

FortiGate のアップグレードパスは、公式の Upgrade Path Tool にモデル、現在のバージョン、目標バージョンを入力して確認します。ただし経路は更新の順番を示すものであり、更新先の採用可否、各段階の確認、HA の動作、切り戻しの準備は別に判断する必要があります。

• 経路はモデルと現在の版、目標版を公式ツールへ入力して確認する。
• 直接更新か中継版の経由かは、ツールが示す検証済みの経路に従う。
• 経路が表示されても、更新先の採用可否は Release Notes などで判断する。
• 中継版の動作変更や既知の問題も、目標版と同じ観点で確認する。
• 各段階で設定変換エラー、HA の同期、業務通信を確認して次へ進む。
• HA の uninterruptible 方式でも、切り替え時の通信影響は残り得る。
• 作業時間は固定値ではなく、更新回数と確認、切り戻しの時間から見積もる。

以上、最後までお読みいただきありがとうございました。