FortiOS 7.4.8 アップグレードの落とし穴｜IPsec / HA 不具合の対処

はじめに

FortiOS 7.4.8 は、SSL-VPN トンネルモードの段階的廃止や SD-WAN / IPsec 関連の機能拡張など、7.4 系の中でも重要なアップデートを多数含むリリースです。一方、リリース直後のコミュニティ報告と Fortinet のリリースノートからは、IPsec、HA、FortiAnalyzer ログ転送に関連する 3 件の重大な既知問題 が報告されており、本番環境への適用に慎重な判断が求められる状況が続いていました。

特に、Reddit の r/fortinet コミュニティでは、7.0 系からの移行先として 7.4.8 を検討していた管理者から、「リリースノートだけでは判断材料が不足しており、TAC へ問い合わせて初めてトリガー条件が判明する」 という指摘が複数寄せられました。これは公式ドキュメントの記述粒度の問題であり、現場の運用担当者にとっては大きなストレスとなる状況です。

本記事では、Reddit コミュニティに投稿された TAC 経由情報と Fortinet 公式リリースノートを突き合わせ、3 件の既知問題について トリガー条件・本番環境への影響度・暫定対策・恒久対策（7.4.9 以降での解決状況） を実務観点で整理します。FortiOS 7.4 系の継続運用とサポート期間延長の背景については、関連記事『FortiOS 7.4 サポート延長の背景と SSL-VPN 廃止に伴う移行の現実』も参考になります。

FortiOS 7.4.8 で報告されている主要 3 件の不具合

FortiOS 7.4.8 の公式リリースノートに「Known issues（既知問題）」として記載され、Reddit コミュニティでも継続的に議論されてきた 3 件の不具合を取り上げます。これらは Bug ID で 1033083、1140823、1148101 として識別されています。

参考: Known issues（FortiOS 7.4.8 Release Notes）
“The following issues have been identified in version 7.4.8.”
（以下の問題は 7.4.8 で確認されています。）
https://docs.fortinet.com/document/fortigate/7.4.8/fortios-release-notes/236526/known-issues

1033083: HA セッション同期不全と Standby Conserve Mode

HA（FGCP）構成において、Primary 機の TCP セッションが Standby 機へ正しく同期されず、Primary 側にセッションが過剰に蓄積した結果、Standby 機がメモリ枯渇により Conserve Mode に陥る 不具合です。Conserve Mode に入ると、FortiGate は新規セッションの受け入れや一部機能（プロキシ系セキュリティプロファイル等）を制限するため、フェイルオーバー時の動作に深刻な影響が出る可能性があります。

参考: r/fortinet コミュニティ（Reddit ソース投稿）
“1033083 – HA sessions are not properly synchronized, causing a high number of sessions on the primary unit, and the standby unit enters conserve mode.”
（1033083: HA セッションが正しく同期されず、Primary 機のセッション数が増大し、Standby 機が Conserve Mode に入る。）
https://www.reddit.com/r/fortinet/comments/1m18dy1/fortigate_748_anyone_affected_or_not_by_ipsecha/

HA 構成の基本動作については、関連記事『FortiGate HA（FGCP）構成の構築手順』も参考になります。

1140823: np6xLite 機種で IPsec トンネルが ESP パケットをドロップ

NPU として np6xLite を搭載した機種（FortiGate 200F / 201F / 100F / 101F / 80F / 81F / 60F / 61F / 40F / 200E / 201E などのエントリー〜ミッドレンジモデル）で、IPsec トンネル経由の ESP パケットがドロップされ、Spoke 側のトンネルが事実上停止する 不具合です。Hub-and-Spoke の SD-WAN / VPN 構成で発生しやすく、Spoke 側拠点で通信断が発生します。

参考: r/fortinet コミュニティ（Reddit ソース投稿）
“1140823 – IPsec tunnels stuck on spoke np6xlite drops the ESP packet. (would affect our 200Fs)”
（1140823: np6xLite を搭載した Spoke 側で IPsec トンネルが停止し、ESP パケットがドロップされる。投稿者は 200F の運用を想定。）
https://www.reddit.com/r/fortinet/comments/1m18dy1/fortigate_748_anyone_affected_or_not_by_ipsecha/

7.4.9 のリリースノートでは、本不具合は 「複数回の鍵更新（rekey）における vifid 形成不全に起因する ESP パケットドロップ」 として、より詳細な技術的説明とともに解決済みリストに掲載されています。なお、後述するように NPU オフロードを無効化する暫定対策 で回避可能です。IPsec VPN の基本構築と SD-WAN 連携については、関連記事『FortiGate IPsec VPN の構築手順｜IKEv2 と NAT 越えの設定例』も参考になります。

1148101: FortiAnalyzer へのログ転送停止

FortiGate から FortiAnalyzer（FAZ）へのログ転送が、ある条件下で 完全に停止する 不具合です。FortiView ダッシュボードのソースも表示されなくなるため、運用監視・ログ集約の観点で大きな影響があります。

参考: r/fortinet コミュニティ（Reddit ソース投稿）
“1148101 – Logs are not uploaded to FortiAnalyzer.”
（1148101: FortiAnalyzer へログがアップロードされない。）
https://www.reddit.com/r/fortinet/comments/1m18dy1/fortigate_748_anyone_affected_or_not_by_ipsecha/

リリースノートには明確なトリガー条件が記載されておらず、ローカルディスクを持たない（FortiAnalyzer ストリーミング前提の）構成の FortiGate で特に影響が大きい 不具合です。一方、コミュニティの報告では「7.4.8 へアップグレードしても FAZ ログ転送に問題が発生しない」というケースもあり、影響を受けるか否かが構成によって分かれる挙動を示しています。

3 件の不具合の位置づけ

3 件は性質が大きく異なり、本番環境での影響度と回避難易度に差があります。

各不具合のトリガー条件と本番影響の評価

公式リリースノートには各 Bug ID について短い説明文しか記載されていません。一方、Reddit r/fortinet のスレッドでは、投稿者が Fortinet TAC（テクニカルサポート）に直接問い合わせて得たトリガー条件の詳細情報が共有されました。本セクションでは、その TAC 確認情報と公式リリースノートを突き合わせ、各不具合が どのような構成・運用条件で発生するか、そして 本番環境への影響度 を整理します。

1033083: HA セッション同期不全のトリガー条件と影響評価

本不具合の発生条件について、TAC は 「FortiGate がエフェメラルセッション（ephemeral sessions）の上限に達した時にトリガーされる」 と回答しています。エフェメラルセッションとは、機種ごとにハードウェアリソースに応じて確保される短命の TCP / UDP セッション領域のことで、通常運用では使い切ることが稀な領域です。

参考: TAC 確認情報（Reddit r/fortinet スレッド）
“This bug is triggered when FortiGate reaches its limit for ephemereal sessions. It was discovered in stress testing and is, in my opinion, unlikely to occur in production environments. Workaround is to disable session pickup (config sys ha > set session-pickup disable).”
（本不具合は FortiGate がエフェメラルセッションの上限に達した時にトリガーされる。ストレステストで発見されたものであり、本番環境で発生する可能性は低いと考えられる。回避策は session-pickup の無効化。）
https://www.reddit.com/r/fortinet/comments/1m18dy1/fortigate_748_anyone_affected_or_not_by_ipsecha/

本番影響度: 低 〜 中

ストレステスト環境下で発見された不具合であり、TAC 自身も「本番環境での発生可能性は低い」という評価です。ただし、以下のような環境では注意が必要です。

エフェメラルセッション数が想定以上に増える可能性のある環境

大量の短時間セッション（CDN 経由のアクセス、大規模 IoT デバイス群、DDoS 攻撃を受けた場合等）

エントリーモデルを HA 構成で運用している環境

ハードウェアリソースが限られるため、上限到達のリスクが相対的に高い。

実機が影響を受けるかどうかは、エフェメラルセッションの最大値と現在値を比較することで判定できます。具体的な確認方法は後述します。

なお、Reddit スレッドでは複数の管理者が「200F や 400F の HA 構成を 7.4.8 で運用しているが 1033083 に遭遇していない」と報告しており、現場での発生確率は低い実態がうかがえます。

1140823: np6xLite 機種で IPsec トンネルが ESP パケットをドロップ — トリガー条件と影響評価

本不具合のトリガー条件について、TAC は 「vpn-id-ipip カプセル化を使用しており、かつ NPU オフロードが有効になっている IPsec トンネル」 と回答しています。

参考: TAC 確認情報（Reddit r/fortinet スレッド）
“Triggered when using vpn-id-ipip encapsulation in IPsec tunnels and have NPU offload enabled. Does not affect 90G platform running 7.4.8.”
（vpn-id-ipip カプセル化を使用し、NPU オフロードが有効な IPsec トンネルでトリガーされる。7.4.8 上の 90G プラットフォームには影響しない。）
https://www.reddit.com/r/fortinet/comments/1m18dy1/fortigate_748_anyone_affected_or_not_by_ipsecha/

vpn-id-ipip は何のためのオプションか

vpn-id-ipip は SD-WAN セグメンテーション（複数 VRF を単一オーバーレイに収容する機能） で使用される IPsec フェーズ 1 のカプセル化オプションです。Hub-and-Spoke 構成において、Spoke 拠点が複数の企業・部門のサブネットを収容し、それぞれを別 VRF で分離して通信させる際に必要となります。

参考: SD-WAN segmentation over a single overlay（FortiOS 7.4.7 Administration Guide）
“Segmentation requires that VRF info is encapsulated within the IPsec VPN tunnel. This setting enables multi-VRF IPSEC tunnels.”
（セグメンテーションを実現するには、IPsec VPN トンネル内に VRF 情報をカプセル化する必要があります。この設定により multi-VRF IPsec トンネルが有効化されます。）
https://docs.fortinet.com/document/fortigate/7.4.7/administration-guide/810981

該当する CLI 設定は以下の形です。

config vpn ipsec phase1-interface
    edit <name>
        set encapsulation vpn-id-ipip
    next
end

つまり、set encapsulation vpn-id-ipip を含む IPsec フェーズ 1 設定を持たない環境では、1140823 の影響を受けない ことになります。一般的な拠点間 IPsec VPN や、シンプルな Hub-and-Spoke 構成（単一 VRF）では本不具合は発生しません。

影響を受ける機種

本不具合は NPU として np6xLite を搭載する機種で発生します。

本番影響度: 中 〜 高

vpn-id-ipip カプセル化を使用している環境では、Spoke 拠点での通信断という深刻な事象 が発生する可能性があります。特に、複数の VRF を SD-WAN オーバーレイで収容している大企業や、SaaS / IaaS 系のホスティング事業者では影響が大きくなります。

1148101: FortiAnalyzer ログ転送停止 — トリガー条件と影響評価

本不具合は TAC からも明確なトリガー条件が示されておらず、最も評価が難しい既知問題です。

参考: TAC 確認情報（Reddit r/fortinet スレッド）
“No specific trigger condition listed so I suspect just logging to FortiAnalyzer is enough. Workaround is to restart the miglogd/fgtlogd processes.”
（特定のトリガー条件は示されていないため、FortiAnalyzer へのロギングを設定しているだけで発生する可能性があると推測される。回避策は miglogd / fgtlogd プロセスの再起動。）
https://www.reddit.com/r/fortinet/comments/1m18dy1/fortigate_748_anyone_affected_or_not_by_ipsecha/

Reddit コミュニティでは、「全てのログが届かないわけではなく、特定のコネクション分だけ届かない」「7.4.8 にアップグレードしたが FAZ ログ転送に問題は起きていない」など相反する報告が寄せられています。これらを総合すると、本不具合は 特定の条件下のセッションログだけが欠落する部分的な不具合 の可能性が高く、一度発生すると miglogd / fgtlogd プロセスを再起動するまで自己回復しない特性があります。

7.4.9 のリリースノートに基づく公式の症状説明は以下の通りです。

参考: Known issues（FortiOS 7.4.7 Release Notes — 1148101 の記述）
“Logs fail to appear in FortiAnalyzer, and FortiView sources are missing from the Dashboard.”
（ログが FortiAnalyzer に表示されず、FortiView のソースがダッシュボードから欠落する。）
https://docs.fortinet.com/document/fortigate/7.4.7/fortios-release-notes/

本番影響度: 中

ファイアウォール本体の通信機能には影響しないため緊急度は低めですが、セキュリティ運用・コンプライアンス監査・インシデント調査の観点では深刻 です。特に ローカルディスクを持たないモデル では、FAZ ストリーミングが唯一のログ保存手段となっているケースが多く、影響が大きくなります。

3 件の影響度サマリー

リモートアクセス IPsec VPN（FortiClient ダイアルアップ）環境での影響

3 件の不具合は性質が大きく異なるため、FortiClient を使ったリモートアクセス IPsec VPN 環境 での影響範囲も整理しておきます。

特に 1140823 は、リモートアクセス IPsec VPN 環境では発生しません。先述の通り、トリガー条件である set encapsulation vpn-id-ipip は SD-WAN セグメンテーション（multi-VRF を単一オーバーレイに収容する機能）専用のオプションであり、FortiClient ダイアルアップ VPN の標準的な設定には含まれないためです。Fortinet 公式ドキュメントが示すリモートアクセス IPsec VPN のフェーズ 1 設定例にも vpn-id-ipip の指定はなく、Mode Config（set mode-cfg enable）と EAP / XAuth 認証を組み合わせる構成が標準となっています。

参考: FortiClient as dialup client（FortiOS 7.6.6 Administration Guide）
https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/785501/forticlient-as-dialup-client

つまり、Reddit スレッドで議論されていた「Spoke 拠点（200F 等）で IPsec トンネルが停止する」というシナリオは、大規模 SD-WAN マルチ VRF 展開環境に特有の問題 であり、一般的なリモートアクセス VPN 環境では考慮不要です。リモートアクセス VPN 環境で主に注意すべきは、1148101（FAZ ログ転送停止） となります。

暫定対策（Workaround）の CLI 設定

7.4.9 以降への恒久対策が取れない環境向けに、各不具合の暫定対策を CLI コマンドベースで整理します。いずれの対策も副作用を伴うため、適用前にトレードオフを理解しておくことが重要です。

1033083: HA セッション同期の無効化

TAC から提示された暫定対策は、session-pickup を無効化する ことです。

config system ha
    set session-pickup disable
end

参考: Session pickup（FortiOS 7.6.6 Administration Guide）
“If you leave session pickup disabled, the cluster doesn’t track sessions, and active sessions must be restarted or resumed after a failover.”
（session-pickup を無効化したままの場合、クラスタはセッションを追跡せず、フェイルオーバー後にアクティブなセッションは再開または再接続が必要となります。）
https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/955521/session-pickup

session-pickup を無効化すると、HA フェイルオーバー発生時に既存の TCP セッションが切断され、再接続が必要 となります。多くの一般的なプロトコル（HTTP / HTTPS、SSH、SMB など）はクライアント側で自動的に再接続するため、運用上の影響は数秒程度のセッション断に留まります。ただし、以下のユースケースでは影響が大きくなります。

• 長時間継続する FTP の大容量ダウンロード: ダウンロードが最初からやり直しになる可能性あり
• WebSocket・gRPC ストリーミングなどの常時接続型通信: アプリケーション側で再接続ロジックが必要
• データベース接続プール経由のセッション: プール側の再接続処理に依存

HA フェイルオーバーが頻発しない一般的な運用環境では、session-pickup 無効化のデメリットは限定的です。

1140823: NPU オフロード無効化（vpn-id-ipip 利用環境向け）

TAC およびコミュニティが推奨する暫定対策は、該当する IPsec フェーズ 1 インターフェースで NPU オフロードを無効化する ことです。

config vpn ipsec phase1-interface
    edit <tunnel-name>
        set npu-offload disable
    next
end

Reddit コミュニティの報告では、CPU 使用率への影響は 1〜2% 程度の軽微な上昇に留まる ケースが多いとされています。

参考: TAC 確認情報（Reddit r/fortinet スレッド）
“Easy work around with npu-offload disable on your phase1 interfaces. Fortigates have plenty of CPU to handle it and you’ll only see a 1-2 % CPU spike typically.”
（フェーズ 1 インターフェースで npu-offload を無効化するだけで容易に回避できる。FortiGate は処理能力に余裕があり、通常 CPU 使用率の上昇は 1〜2% 程度に留まる。）
https://www.reddit.com/r/fortinet/comments/1m18dy1/fortigate_748_anyone_affected_or_not_by_ipsecha/

ただし、既存の CPU 使用率が常時 60% を超えている環境、大量の IPsec トンネルを集約する Hub 装置、高速回線（10Gbps 以上）での IPsec 終端 では、CPU 負荷影響をより慎重に評価することが推奨されます。

設定変更後は、対象トンネルの IKE / IPsec SA をクリアして設定変更を反映させることが必要です。

diagnose vpn ike gateway clear name <tunnel-name>

1148101: miglogd / fgtlogd プロセスの再起動

TAC から提示された暫定対策は、ログ転送を担当するプロセス（miglogd / fgtlogd）の再起動 です。

diagnose test application miglogd 99
diagnose test application fgtlogd 99

末尾の 99 は対象プロセスの再起動を指示するアクションコードです。実行後、数秒でプロセスが自動的に再起動され、ログ転送が復旧します。ただし本対策は対症療法であり、一定期間経過後に再度同じ問題が発生する可能性があります。根本対策となる 7.4.9 以降へのアップグレードが推奨 されます。

暫定対策の選択フロー

エフェメラルセッション上限の確認方法

1033083 の影響を受ける可能性があるかを判断するには、運用中の FortiGate がエフェメラルセッションの上限にどの程度近づいているか を確認する必要があります。

diagnose sys session full-stat コマンドの実行

エフェメラルセッションの現在使用数と最大値は、以下のコマンドで確認できます。

diagnose sys session full-stat

出力例の一部抜粋

session table: table_size=1048576 max_depth=3 used=14780
misc info: session_count=6410 setup_rate=28 exp_count=47 clash=361
           memory_tension_drop=0 ephemeral=0/501248 removeable=0
           npu_session_count=609 nturbo_session_count=471

参考: diagnose sys session full-stat（Fortinet Community）
https://community.fortinet.com/t5/Support-Forum/Looking-for-information-on-quot-diagnose-Sys-session-full-stat/td-p/53070

出力中の ephemeral=現在値/最大値 の部分が、エフェメラルセッションの使用状況を示しています。上記の例では「現在 0 セッション、最大 501,248 セッション」となります。

機種別の最大値の参考値

Reddit スレッドで共有された複数機種の実測値を整理すると、機種ごとに以下のような上限値が観測されています。

参考: TAC 確認情報（Reddit r/fortinet スレッド、pbrutsche 氏のコメント）
“Our 400F HA pair maxes out at 1,146,880 ephemeral sessions. A 200F HA pair maxes out at 589,824.”
（当社の 400F HA Pair は 1,146,880 エフェメラルセッションが上限。200F HA Pair は 589,824 が上限。）
https://www.reddit.com/r/fortinet/comments/1m18dy1/fortigate_748_anyone_affected_or_not_by_ipsecha/

上記の値はあくまで参考値であり、実機の正確な上限値は diagnose sys session full-stat で確認することが推奨 されます。

影響評価の目安

ephemeral=現在値/最大値 の比率を継続的に監視することで、1033083 の影響を受けるかを判定できます。

• 使用率 50% 未満で安定している環境: 1033083 の発生可能性は非常に低い
• 使用率 70% を超えることがある環境: 1033083 のリスクあり、暫定対策の適用を検討
• 使用率 90% に近づく環境: 1033083 のリスクが高い、暫定対策または恒久対策の早期実施を推奨

エフェメラルセッション使用率はデフォルトの監視項目に含まれていないため、SNMP / API / SSH スクリプト経由での定期取得を組み込むことが推奨 されます。

恒久対策: 7.4.9 以降アップグレードの判断軸

3 件の不具合はすべて FortiOS 7.4.9 で解決済み として公式リリースノートに記載されています。一方、7.4.9 以降には 新たな互換性問題（SAML 署名検証の仕様変更） が導入されているため、単純に最新版へ更新すれば良いという判断にはなりません。本セクションでは、現時点（2026 年 5 月）における推奨コードと、アップグレード判断のポイントを整理します。

7.4.9 / 7.4.10 / 7.4.11 における 3 件の解決状況

3 件の Bug ID は、いずれも 7.4.9 のリリースノートにおいて「Resolved issues（解決済み）」リストに記載されています。

参考: Resolved issues（FortiOS 7.4.9 Release Notes）
“1140823 — IPsec tunnels become stuck on spoke np6xlite, causing ESP packet drops after extended operation due to improper vifid formation during multiple rekey operations.”
（1140823: 複数回の rekey 操作における不適切な vifid 形成に起因し、長時間運用後に np6xLite 搭載 Spoke 機で IPsec トンネルが停止し ESP パケットがドロップされる。）
https://docs.fortinet.com/document/fortigate/7.4.9/fortios-release-notes

7.4.9 以降で発生した SAML 署名検証問題

7.4.9 以降では、デフォルト動作の変更により SAML レスポンスメッセージの署名検証が必須化 されました。SAML IdP（Identity Provider）側でレスポンスとアサーションを署名する設定が必要となります。

参考: Recommendation for Fortinet Devices（NetworksGroup ブログ）
“This change in default behavior verifies the signature for SAML response messages. This means that configurations must be made to the SAML IdP to sign SAML responses and assertions. While providers such as Azure can be reconfigured to work properly, the only workaround for other IdPs (such as Google) is to downgrade to FortiOS 7.4.8.”
（このデフォルト動作の変更により、SAML レスポンスメッセージの署名が検証されます。SAML IdP 側でレスポンスとアサーションへの署名設定が必要となります。Azure などのプロバイダは再設定で対応可能ですが、Google などその他の IdP では 7.4.8 へのダウングレード以外の回避策がありません。）
https://www.networksgroup.com/blog/recommendation-for-fortinet-devices

SAML SSO 認証を運用している環境では、IdP 側の対応可否を事前に確認することが推奨 されます。特に Google Workspace など、レスポンス署名のオプション設定が限定的な IdP を利用している環境では注意が必要です。ローカル認証、LDAP、RADIUS のみで認証している環境や、Azure AD（現 Microsoft Entra ID）利用環境では本問題の影響を受けません。

推奨アップグレードパスの判断軸

7.0.x からの直接アップグレードを行う場合は、複数バージョンを経由する必要があります。FortiGate の公式アップグレードパスの確認手順については、関連記事『FortiGate のアップグレードパス確認手順』を参照してください。

アップグレード前の確認チェックリスト

• 運用中の SAML IdP がレスポンス署名に対応できるか、IdP 管理者と調整済みか
• 2GB RAM 機種を含む場合、プロキシ関連機能の制約と Security Rating 非対応の影響範囲を把握しているか
• HA 構成の場合、uninterruptible-upgrade が有効化されているか
• FortiClient / FortiManager / FortiAnalyzer のバージョン互換性が要件を満たしているか
• 公式アップグレードパス（Fortinet Customer Service & Support サイト）で経由バージョンを確認したか
• 設定バックアップ、切り戻し手順、検証環境での事前確認が完了しているか

なお、FortiOS 7.4.8 以降では、ライセンス無効や EOES 到達を条件として、同一マイナーバージョン内の最新パッチへ自動でアップグレードがスケジュールされる仕様が追加 されています。意図しないアップグレードを防ぐ手順については、関連記事『FortiGate 強制アップグレード（自動アップグレード）の仕様と回避対策』もあわせて参照してください。

まとめ

本記事では、FortiOS 7.4.8 で報告されている IPsec / HA / FortiAnalyzer ログ転送の主要 3 件の不具合について、トリガー条件・本番影響・暫定対策・恒久対策を整理しました。

• 3 件の不具合（1033083 / 1140823 / 1148101）はいずれも公式リリースノートに既知問題として記載されているが、トリガー条件の詳細は TAC 経由で初めて判明する粒度となっている
• 1033083 はエフェメラルセッション上限到達時に発生し、diagnose sys session full-stat で自機の使用率を確認することで影響評価が可能
• 1140823 は vpn-id-ipip カプセル化（SD-WAN セグメンテーション）と NPU オフロードの組み合わせで発生し、np6xLite 搭載機種が対象
• FortiClient を使ったリモートアクセス IPsec VPN 環境では 1140823 は発生せず、主な注意点は 1148101（FAZ ログ転送停止）となる。
• 1148101 は FAZ ログ転送が部分的に停止する問題で、明確なトリガー条件は不明、対症療法としてのプロセス再起動以外の暫定策に乏しい。
• 3 件は FortiOS 7.4.9 で解決済みだが、7.4.9 以降では SAML 署名検証の仕様変更により別の互換性問題が発生
• 2026 年 5 月時点では、7.4 系の推奨コードは 7.4.11（ビルド 2878）、SAML 利用環境では IdP 側の対応可否を事前に確認することが推奨される。

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