Fortinet機器を複数拠点で使う会社の、機種・版・保守先の整理

Fortinet機器を複数拠点で使う会社の、機種・版・保守先の整理。この記事は2026年10月21日に確認できた公式情報を起点に、Fortinet機器を複数拠点で使う会社の、機種・版・保守先の整理という疑問に答えるための確認手順を整理します。自社で対象か分からない項目は推測で埋めず、管理担当や提供元へ確認してください。

機種・バージョンの一覧化

拠点別機種リスト作成

FortiGate を複数拠点で運用している場合、まずは各拠点のネットワーク担当者に現在稼働中の機種とモデル番号をヒアリングします。ヒアリングシートには「拠点名」「機種名」「モデル番号」「設置年月日」などの項目を設け、Excel もしくは Google スプレッドシートで一元管理できるようにします。

取得した情報は、担当者が確認した旨の署名またはメールでの承認を得て、正式な一覧表として保存します。

次に、一覧表を基に機種ごとのハードウェアスペックやサポート期間を照合し、同一機種が複数拠点にまたがっているかを確認します。重複が多い場合は、将来的な統一機種選定の材料となります。最終的に、一覧表は「拠点別機種リスト（PDF）」「更新履歴（CSV）」の二形態で保管し、変更があった際は必ず更新履歴に日付と担当者を記録します。

ファームウェア版管理表

各機種の現在のファームウェア版を把握するため、まずは FortiGate の管理コンソールにログインし、システム情報画面で「Version」項目を取得します。この情報を機種別にまとめた管理表に記入し、同時に公式サイトのサポート情報と照らし合わせて EOL（End‑of‑Life）対象かどうかを判定します。

EOL 機種は、更新が提供されないリスクが高まるため、代替機種への移行計画を別途策定します。

管理表には「機種」「モデル」「現在のファームウェア版」「最新安定版」「EOL 判定」「最終更新日」「担当者」の項目を設け、定期的（例：四半期ごと）にレビューを実施します。レビュー時には、最新の脆弱性情報（例：JPCERT/CC の週報）と照合し、必要なアップデートがある場合は更新依頼へとつなげます。

成果物としては、更新対象機種リスト（PDF）と、未更新機種のリスク評価シート（Excel）を作成し、経営層へ報告します。

ライセンス種別の把握

FortiGate の機能はライセンスで拡張できるため、どの機能が利用可能か、またそれぞれの有効期限を正確に把握しておくことは、運用上重要です。ただし、ライセンス情報は管理画面だけで完結しているとは限らず、過去に変更や更新が行われた履歴が別途保管されている場合があります。

そのため、現在表示されている情報だけで全体像を判断すると、見落としや誤認が生じる可能性があります。

担当者には、まず「現在有効なライセンスの種類と対象機能」について、最新の一覧がどこに保管されているかを確認してください。その上で、過去にライセンスの追加・更新・削除が行われた記録が残っているか、またそれらの記録がどのように管理されているかを尋ねるとよいでしょう。

さらに、ライセンスの有効期限が近づいた際の対応フローや、期限切れが業務に与える影響についても確認しておくと、後々のトラブル防止につながります。これらの情報を整理しておくことで、正確なライセンス管理と適切な運用計画が立てやすくなります。

次に、期限が近いライセンスを抽出し、更新手続きの担当者とスケジュールを割り当てます。期限切れが近い場合は、機能停止リスクを評価し、代替策（例：一時的に別提供元の機能利用）を検討します。最終的に、ライセンス管理表は「機種」「ライセンス種別」「有効期限」「更新担当」「備考」の項目で構成し、定期的にレビュー会議で共有します。

成果物としては、更新予定リスト（PDF）と、ライセンス残存期間のダッシュボード（PowerBI もしくは Google Data Studio）を用意し、関係者全員が可視化できるようにします。

保守契約先の整理

ベンダー別保守一覧

FortiGate の保守は、Fortinet 公式のサポートとサードパーティの保守サービスに分かれることがあります。まずは全拠点の保守契約書を収集し、契約書に記載された提供元名、契約開始日・終了日、対象機種、サポート範囲を一覧表にまとめます。

表は「提供元」「契約番号」「対象機種」「開始日」「終了日」「サポートレベル（24/7、平日対応等）」「担当窓口」の項目で構成し、PDF と Excel の二形式で保存します。

次に、公式保守とサードパーティ保守を色分けして可視化し、重複や抜け漏れがないかをチェックします。重複がある場合は、コスト削減の観点からどちらか一方に統合する提案を作成します。また、保守窓口が複数ある場合は、緊急時の一次連絡先を明確にし、社内マニュアルに記載しておくことが重要です。

成果物としては、提供元別保守一覧（PDF）と、緊急連絡フローチャート（PNG）を作成し、全担当者に配布します。

保守対象外例外項目

保守契約には対象外となるハードウェアや旧版ファームウェアが含まれることがあります。まずは契約書の「除外項目」セクションを確認し、対象外機種やバージョンを抽出します。抽出した情報は「機種」「除外理由」「除外開始日」「代替対応策」の表にまとめ、担当者が容易に参照できるようにします。

例外対象が判明した場合は、代替策として社内での障害対応フローや、サードパーティ提供元への委託手順を策定します。フローは「障害検知 → 例外判定 → 代替対応実施 → 報告」の4ステップで構成し、各ステップに担当者と期限を明記します。成果物は、例外項目一覧（Excel）と代替対応フローチャート（PDF）で、定期的にレビューしながら更新します。

契約更新スケジュール管理

拠点ごとの保守契約を整理するときは、機器が現在使われているか、契約に何の作業が含まれるか、更新の相談を誰が行うかを確認します。契約の終了日だけを並べても、機器の更新を依頼できる状態かは分かりません。

確認を始める時期は、契約の手続きと業務への影響に合わせて決めます。保守会社から案内が来る前提にせず、自社でも窓口と期限を把握してください。契約の更新と、今回の脆弱性への対応は別に追跡し、契約手続き中だから技術対応も完了したと扱わないようにします。

更新担当者は、抽出された機種ごとに更新手続きの進捗をチェックリストで管理します。チェックリストには「見積取得」「社内承認」「契約書署名」「保守開始確認」の項目があり、完了したら担当者が署名またはチェックマークを付けます。

更新が失敗した場合は、代替手段として別提供元の保守へ切り替えるフローを事前に用意し、緊急時に迅速に実行できるようにします。最終的に、更新スケジュール管理表（PDF）と進捗報告書（Word）を作成し、経営層へ定期的に報告します。

拠点間設定の統一指針

共通ポリシーの策定

全拠点で適用すべきファイアウォールポリシーは、まず基本的なトラフィック許可・拒否ルールを一覧化し、業務フローに合わせた例外条件を明文化します。担当者は、各拠点のネットワーク構成図と照らし合わせて、ポリシー項目が過不足なく反映されているかをチェックリストで確認します。

例外拠点は、支店ごとの業務要件や法令遵守の差異を根拠に判定し、例外理由と期間を文書化して承認フローに回します。

次に、ポリシー変更時の影響範囲をシミュレーションし、テスト環境での検証結果をレポートにまとめます。検証結果は、変更前後のトラフィックログと比較し、許可すべき通信が遮断されていないか、逆に不正トラフィックが通過していないかを確認します。最終的に、全拠点の担当者が承認サインを行い、ポリシーを本番に反映させる手順を文書化して保存します。

VPNトンネル設定比較

VPNトンネルの設定を統一基準と照らし合わせて比較する際は、まず現在の設定内容がどこに記録されているかを確認してください。その上で、実際に比較対象となる項目（暗号化方式や認証方式など）について、各拠点の担当者に「設定の根拠となる資料はありますか」「最新の設定変更履歴はどこで管理されていますか」と尋ねることが重要です。

これにより、設定の実態と文書化された情報が一致しているかを把握できます。

相違点が見つかった場合は、差分を示すだけでなく、なぜその差が生じたのかを担当者に説明してもらうよう依頼してください。具体的には「この設定が他拠点と異なる理由は何ですか」「変更の背景や目的はどのように決められましたか」といった質問を投げかけると、単なる修正指示に留まらない根拠の確認ができます。

こうした確認を踏まえて、修正の必要性や優先度を判断し、次の対応策を検討してください。

修正作業は、まずテスト拠点で設定変更を実施し、トンネルの確立とデータ転送の安定性を確認します。問題がなければ本番拠点へ順次適用し、適用後はトンネルステータスとログを取得して、期待通りの暗号化が行われているかを検証します。検証結果は、変更前後の設定差分と併せて成果物として保管し、次回の監査時に提示できるようにします。

メールフィルタ設定統合

メールセキュリティ機能の有効化状況を拠点ごとに把握し、統一したポリシーにまとめることは重要です。ただし、機能の有無や導入手順が全拠点で同一であると決めつけるのは根拠がありません。実際の設定は拠点ごとの運用要件や既存システムとの連携状況によって異なる可能性があります。

そのため、まずは現在の設定を正確に把握し、未適用の機能が本当に必要かを検討する必要があります。

担当者に確認すべき具体的な質問は次のとおりです。

• 各拠点で現在有効になっているスパム検知、ウイルススキャン、フィッシング対策の項目は何か。
• それらの機能が未適用の場合、導入の目的や期待効果はどのように考えているか。
• 新たに有効化する際に、テストメールでの検証計画や、誤検知・正当メールのブロックを防ぐための運用ルールはどのように設定する予定か。

これらの回答をもとに、実際に必要な設定変更やマニュアル作成の範囲を判断できます。

導入後は、フィルタリングログを定期的に抽出し、検出率と誤検知率をレポート化します。万が一、誤検知が増加した場合は、フィルタの例外リストを調整し、ロールバック手順を実行します。最終的に、設定統合完了報告書に、適用範囲、テスト結果、保守担当者のサインを添付し、成果物として保管します。

更新作業と検収フロー

更新依頼手順書作成

更新依頼は、標準フォーマットに従い「対象機種」「現在版」「対象版」「実施日時」「担当者」「影響範囲」の項目を必ず記入します。担当者は、事前に機種・バージョン一覧表と保守契約情報を照合し、対象版が保守対象かつサポート期間内であることを確認します。チェックリストには、バックアップ取得、メンテナンスウィンドウ確保、障害時連絡先の記載を必須項目として設定します。

依頼書は、承認フローを経てIT部門の変更管理システムに登録し、実施担当者へ自動通知します。登録時に添付する資料として、現在の設定バックアップとリリースノートの抜粋を添付し、後続の検証作業で参照できるようにします。依頼書は、更新完了後に実績報告として更新履歴に追記し、監査証跡として保持します。

更新失敗時の対策

更新が失敗した場合は、まずエラーログを取得し、失敗原因を分類します。代表的なシナリオとして「ファームウェア不整合」「ライセンス不一致」「ネットワーク遮断」の三つが想定され、各シナリオごとにロールバック手順を事前に用意しておきます。担当者は、失敗報告書にエラーメッセージと影響範囲を記載し、即時に保守提供元へ責任者への連絡します。

ロールバックは、事前に取得した設定バックアップと前バージョンのイメージを使用し、元の状態に復元します。復元後は、サービス稼働確認とログ解析を行い、問題が解消されたことを確認したうえで、再度更新計画を立案します。失敗報告書は、原因分析と再発防止策を含めて管理台帳に保存し、次回以降の更新作業に活用します。

最終検収項目一覧

更新後の検収では、機能が正しく動作しているかと、システムの処理速度が以前と比べて大きく変わっていないかを確認することが重要です。機能面では、VPN が確立できるか、メールのフィルタリングが有効か、ファイアウォールのルールが期待通りに適用されているか、ライセンス情報が正しく表示されているかを、実際に操作しながらチェックしてください。

処理速度については、更新前に取得したベンチマーク結果と比較できるよう、測定手順や使用したツールを記録した資料を用意してもらうと、変化の有無を客観的に判断しやすくなります。

担当者に確認すべきポイントは次のとおりです。
1. 機能確認項目のチェックリストはどのように作成し、誰が実施したか。
2. ベンチマーク測定に使用した手順書やツールの名称、測定結果の保存場所。
3. 更新前後の測定結果を比較した際に、許容範囲を超える差異があった場合の対応策は何か。

これらの情報を把握しておくことで、検収結果が主観的な判断に偏らず、具体的な根拠に基づいた評価が可能になります。

全項目が合格基準を満たしたら、検収合格証を発行し、成果物として設定バックアップ、検証レポート、承認サインを添付したフォルダを納品します。納品物は、保守提供元と社内のIT資産管理システムに登録し、次回の更新サイクルで参照できるように保管します。合格しなかった項目は、再度修正作業を実施し、再検収を行うフローを明確にしておくことが重要です。