SAPシステムをMicrosoft Defender側で監視したい管理者がまず押さえるべき結論は、Microsoft Sentinel solution for SAP applications overviewは「SAP向けのSIEM/SOAR監視を、Microsoft Sentinelの機能としてMicrosoft Defenderポータルでも扱えるようにする」位置づけだという点です。単体の「Defender for SAP」という別製品ではなく、Microsoft SentinelのSAP向けソリューションを、Defenderポータルの統合運用に組み込んで使います。
2026年5月14日に更新された公式概要では、このSAP向けソリューションがMicrosoft Sentinel in the Microsoft Defender portalとAzure portalの両方に適用されること、SAP環境の脅威検知・調査・対応を支援することが示されています。特に管理者は、コンテナ型SAPデータコネクタエージェントの廃止予定、エージェントレス接続への移行、SAP別の課金・ログ取り込み量、Defenderポータル移行時のインシデント運用変更を優先して確認すべきです。(Microsoft Learn)
Microsoft Defenderでの位置づけを正しく理解する
Microsoft Sentinel solution for SAP applicationsは、SAPのログやアクティビティをMicrosoft Sentinelに取り込み、SAP固有の不審操作を検知するためのソリューションです。公式概要では、SAPシステムが機密情報を扱い、攻撃者の標的になりやすい一方で、従来はSOCからの可視性が不足しがちだと説明されています。そのギャップを埋めるために、Microsoft SentinelがSAP環境向けの検知、分析、調査、対応を提供します。(Microsoft Learn)
Microsoft Defenderとの関係で重要なのは、Microsoft SentinelがMicrosoft Defenderポータル上でも一般提供されていることです。Defenderポータルでは、SIEMであるSentinelとXDRの調査体験を統合し、インシデント、アラート、エンティティ、ハンティングを一つの運用画面で扱えます。Microsoft Defender XDRを使っていない組織でも、Microsoft SentinelをDefenderポータルで利用できるとされています。(Microsoft Learn)
つまり、この記事で扱う変更は「SAP監視をDefenderが直接代替する」という話ではありません。実務上は、SAPログはSentinelのSAP向けコネクタで取り込み、インシデント調査や相関分析をDefenderポータル側の統合SOC運用に寄せていくと理解すると分かりやすくなります。
2026年5月14日更新で押さえるべき変更点
今回の公式情報で管理者が見るべきポイントは、機能追加の有無だけではありません。むしろ、既存環境の運用方式が今後も安全に継続できるかを確認する材料として読むべきです。
| 確認項目 | 公式情報で示されている内容 | 実務上の影響 |
|---|---|---|
| 適用先 | Microsoft Sentinel in the Microsoft Defender portalとAzure portalに適用 | Defenderポータル前提のSOC運用を計画する必要がある |
| 監視対象 | SAPのビジネスロジック、アプリケーション、データベース、OS層の脅威監視を支援 | SAP単体ではなく、他の組織内シグナルとの相関を前提に設計する |
| コネクタ方式 | エージェントレスデータコネクタとコンテナ型データコネクタエージェントをサポート | 新規展開はエージェントレスを優先し、既存コンテナ型は移行計画が必要 |
| コンテナ型エージェント | SAPデータコネクタエージェントは非推奨で、2026年9月14日に恒久的に無効化予定 | 既存利用中の環境は、期限前にエージェントレスへ移行する |
| 対応SAP環境 | SAP ECC、Business Suite、NetWeaverベース製品、S/4HANA Cloud Private Edition、ハイブリッド展開などを対象 | RISE、オンプレミス、クラウド混在環境の棚卸しが必要 |
| 料金 | ソリューションのインストールは無料だが、本番の接続済みアクティブシステムには追加の時間課金が発生 | 本番・非本番の判定、ログ量、権限不備による「不明」状態を確認する |
| SAP BTP | SAP BTP向けには別のMicrosoft Sentinel solution for SAP BTPが用意されている | SAPアプリケーション本体とBTPを同じ範囲だと誤解しない |
公式ドキュメントでは、SAP向けソリューションのインストール自体は無料でも、接続済みのアクティブな本番システムには追加の時間課金が発生し、システム状態が権限問題などで不明な場合は本番システムとして数えられると説明されています。ログ取り込み量によるMicrosoft Sentinel側のコストも別途考慮が必要です。(Microsoft Learn)
影響を受ける対象者
この更新は、SOC担当者だけで完結する内容ではありません。SAP BASIS、Azure管理者、Microsoft Entra ID管理者、アプリケーション運用担当、開発者がそれぞれ確認すべきポイントを持ちます。
| 対象者 | 確認すべきこと | 放置した場合のリスク |
|---|---|---|
| SOC・セキュリティ管理者 | 分析ルール、ウォッチリスト、インシデント運用、Defenderポータル移行 | 誤検知の増加、重要アラートの見落とし、運用手順の不一致 |
| SAP BASIS管理者 | SAP監査ログ、権限、SID、クライアント、SAP Cloud Connector、SAP Integration Suite | ログ未収集、権限不足、コネクタ接続失敗 |
| Azure・Sentinel管理者 | Log Analyticsワークスペース、DCR/DCE、Key Vault、Content Hub、ロール | デプロイ失敗、シークレット管理不備、課金の見落とし |
| Entra ID管理者 | アプリ登録、Application Developer権限、サービスプリンシパル、ロール割り当て | エージェントレス接続の自動デプロイ失敗 |
| 開発者・自動化担当 | KQL、Logic Appsプレイブック、チケット連携、カスタム検知 | Defender移行後に自動化や通知が期待通り動かない |
特にエージェントレス接続では、SAP側だけでなく、SAP BTP、SAP Cloud Connector、Microsoft Entra ID、Azureリソース権限が関係します。公式の前提条件では、SAP NetWeaver 7.5以上、SAP Integration Suite、Process Integration Runtime、Cloud Foundry Runtime、SAP Cloud Connectorなどが挙げられています。(Microsoft Learn)
何が検知できるのか
Microsoft Sentinel solution for SAP applicationsは、SAPの操作ログを単純に保管するだけの仕組みではありません。SAPに特化した検知ルール、ワークブック、ウォッチリスト、プレイブックを組み合わせ、SOCがSAPの不審な操作を調査しやすい形にします。
代表的な検知対象は次の通りです。
| 検知カテゴリ | 例 | 現場での意味 |
|---|---|---|
| 特権操作 | 特権ユーザー作成、緊急ユーザーの使用、権限変更 | 内部不正や侵害後の権限昇格を早期に見つける |
| SAPセキュリティ機構の回避 | 監査ログ無効化、機密性の高いFunction Module実行 | 攻撃者が証跡を消そうとする動きを検知する |
| 永続化 | ICFサービス作成、リモート関数呼び出しによる機密テーブルアクセス | バックドア作成や長期潜伏の兆候を捉える |
| データ持ち出し | 複数ファイルのダウンロード、スプール乗っ取り、機密テーブル参照 | 顧客情報・財務情報などの流出リスクを監視する |
| 初期アクセス | ブルートフォース、同一IPからの複数ログオン | SAPログオンの異常を早期に検知する |
公式のセキュリティコンテンツリファレンスでは、SAP監査ログ、Change Documents Log、ユーザー権限情報などをもとに、多数の分析ルールやワークブックが提供されることが説明されています。一部の要素はPreviewとして扱われるため、本番適用前に利用条件と動作を確認してください。(Microsoft Learn)
新規展開ではエージェントレス接続を前提に考える
展開設計で最も重要なのは、データコネクタ方式の選択です。公式ドキュメントでは、SAP向けソリューションがエージェントレスデータコネクタとコンテナ型データコネクタエージェントの両方をサポートすると説明されています。一方で、コンテナ型のSAPデータコネクタエージェントは非推奨で、2026年9月14日に恒久的に無効化される予定です。(Microsoft Learn)
コネクタ方式別の判断基準
| 現在の状態 | 推奨アクション | 注意点 |
|---|---|---|
| これから新規導入する | エージェントレスデータコネクタを前提に設計 | SAP Cloud Connector、SAP Integration Suite、BTP権限を先に確認する |
| 既にコンテナ型エージェントを使っている | 期限前にエージェントレスへ移行 | 既存ルールやワークブックの動作確認を並行稼働期間に行う |
| 複数SID・複数環境を監視する | 本番・非本番、ログ種別、ワークスペース設計を整理 | 課金、検知感度、アクセス制御を環境ごとに分けて考える |
| RISE/ECSでインフラ層も見たい | SAP LogServとの併用を検討 | 標準のSAPアプリケーションコネクタだけでOS・インフラログまで網羅すると誤解しない |
エージェントレス接続は、SAP Cloud ConnectorとSAP Integration Suiteを使ってSAPシステムに接続し、Security Audit Log、Change Docs logs、ユーザーマスターデータ、ロール、承認情報などの重要なセキュリティログを取り込みます。公式ドキュメントでは、SAP Cloud Connectorの既存構成を活用でき、ネットワーク課題を改めて解決し直さずに済む利点が説明されています。(Microsoft Learn)
既存のコンテナ型エージェント利用環境は移行計画が必須
既にコンテナ型SAPエージェントを使っている環境では、「動いているから様子を見る」は危険です。無効化予定日が明示されているため、2026年9月14日より前に移行作業を完了し、ログ収集・検知・通知・運用手順まで確認する必要があります。
公式の移行ガイドでは、移行の流れとして、既存構成の評価、エージェントレスコネクタのデプロイ、ログ取得の検証、一定期間の並行稼働、コンテナ型エージェントの廃止が示されています。また、既存の分析ルール、ワークブック、プレイブックはエージェントレス接続でも機能し続けると説明されています。(Microsoft Learn)
移行時に確認したいKQL例
ログが取り込まれているかを確認するには、まず直近1時間のABAP監査ログの取り込み状況を見るのが実用的です。
let startTime = ago(1h);
let endTime = now();
ABAPAuditLog
| where TimeGenerated between (startTime .. endTime)
| summarize Count = count() by SourceSystem, bin(TimeGenerated, 5m)
| order by TimeGenerated descこのような確認は、単に「コネクタが接続済み」と表示されるかを見るだけでは不十分です。SIDごと、ログ種別ごと、時間帯ごとにデータが期待通り入っているかを確認し、既存の検知ルールが同じ条件で発火するかまでテストしてください。移行ガイドでも、エージェントレス接続のログ取得を検証し、一定期間並行稼働してから旧エージェントを廃止する流れが示されています。(Microsoft Learn)
展開前に確認すべき前提条件
Microsoft Sentinel solution for SAP applicationsは、Content Hubからインストールするだけでは完成しません。SAP側、Azure側、Entra ID側、ネットワーク側の前提条件が揃って初めて、ログ収集と検知が成立します。
| 確認項目 | 具体的に見る内容 | 失敗しやすいポイント |
|---|---|---|
| Microsoft Sentinelワークスペース | Log AnalyticsワークスペースでSentinelが有効化されているか | ワークスペースはあるがSentinelが有効でない |
| Azure権限 | ソリューション展開、DCR/DCE作成、ロール割り当てができるか | Owner権限不足でリソース作成に失敗する |
| Entra ID権限 | アプリ登録に必要なApplication Developer以上の権限があるか | エージェントレス接続のAzureリソース自動展開でエラーになる |
| SAPシステム情報 | SID、システム番号、クライアントID、ホスト名、接続方式 | BASISチームからの情報不足で接続設定が止まる |
| SAP権限 | NetWeaver管理権限、BTPサブアカウント権限、Integration Suite関連ロール | 必要ログは見えるが一部の権限情報が取れない |
| SAP Cloud Connector | 対象SAPシステムへの接続、宛先、証明書、ネットワーク経路 | ネットワーク到達性だけ確認して認可設定を見落とす |
| ログ種別と量 | Audit Log、Change Docs、ユーザー情報、スプールなど | 取り込み量が増え、コストやノイズが想定を超える |
| シークレット管理 | Key Vault、BTPクライアントシークレット、ローテーション | 平文設定や期限切れで接続障害が起きる |
公式の前提条件では、Azure側のリソース作成権限、Key Vault利用、SAP NetWeaver 7.5以上、BTPサービス、SAP Cloud Connector、SAP側ロールなどが整理されています。ログ取り込み量はシステム利用状況、利用モジュール、ユーザー数、ログ種別などに影響されるため、事前テストで概算するのが安全です。(Microsoft Learn)
Content Hubでのインストールと展開の流れ
Microsoft Sentinel solution for SAP applicationsは、Microsoft SentinelのContent Hubから導入します。インストールすると、SAPデータコネクタ、エージェントレスデータコネクタ、ワークブック、SAP関連の分析ルールなどが利用可能になります。データコネクタは、ソリューションを入れただけでは接続済みにならず、コネクタ設定まで完了して初めて利用できます。(Microsoft Learn)
実務で使いやすい展開手順
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 事前準備 | Sentinelワークスペース、権限、SAP情報、BTP情報を整理 | セキュリティチームとSAP BASISチームの担当範囲を明確にする |
| ソリューション導入 | Content Hubで「SAP」を検索し、SAP applications solutionを作成 | 同一ワークスペースか複数ワークスペース構成かを決める |
| SAP側準備 | SAP監査ログ、権限、必要なロール、Cloud Connectorを設定 | 本番と非本番で同じ設定にしない |
| コネクタ接続 | エージェントレスデータコネクタでSAPクライアントを追加 | Entra ID、DCR、DCE、BTPクライアント情報を確認する |
| ログ確認 | ABAPAuditLogなどのテーブルで取り込みを確認 | SIDごとにデータ鮮度と件数を確認する |
| 検知有効化 | 分析ルールテンプレートから段階的にルールを作成 | 最初から全ルールを有効化せず、誤検知を調整する |
| 運用化 | インシデント対応、プレイブック、チケット連携を確認 | Defenderポータル移行後の挙動も含めてテストする |
公式の展開概要でも、前提条件の確認、Content Hubからのソリューション展開、SAPシステム設定、SAPシステム接続、検知と脅威保護の有効化という流れが示されています。SAP BASISチームとセキュリティチームが分担して作業する前提で計画することが推奨されています。(Microsoft Learn)
分析ルールは段階的に有効化する
SAP向けソリューションの分析ルールは、最初からすべて有効化すればよいわけではありません。公式ドキュメントでは、すべての分析ルールがテンプレートとして提供され、少数のルールを段階的に作成しながらチューニングする方法が推奨されています。(Microsoft Learn)
最初に有効化しやすいルールとしては、特権ユーザー変更、特権ユーザーのログイン、特権ユーザーによる他ユーザー変更、機密ユーザーのパスワード変更とログイン、クライアント構成変更、Function Moduleテストなどが挙げられています。これらはSOCとSAP BASISが共同で動作確認しやすく、初期チューニングにも向いています。(Microsoft Learn)
ウォッチリストの初期設定が検知品質を左右する
SAP向け検知では、ウォッチリストが非常に重要です。たとえば「どのユーザーが特権ユーザーか」「どのテーブルが機密か」「どのネットワークが通常の接続元か」が正しく定義されていないと、アラートが多すぎたり、逆に重要な操作を見逃したりします。
| ウォッチリスト | 役割 | 設定のコツ |
|---|---|---|
| SAP – Systems | 監視対象SAPシステム、SID、本番・非本番の整理 | 監視範囲と課金対象の整理に使うが、課金判定そのものとは分けて考える |
| SAP – Networks | 既知ネットワークや拠点を定義 | 広すぎるCIDRだけでなく、地域・拠点単位で分けると異常検知に効く |
| SAP – Sensitive Tables | 機密テーブルを定義 | 個人情報、財務、販売、購買、権限関連テーブルをBASISと確認する |
| SAP – Sensitive Transactions | 機密トランザクションコードを定義 | SU01、PFCG、SE16系など、環境固有の重要操作を反映する |
| SAP – Privileged Users | 特権ユーザーを定義 | SAP*、DDIC、緊急ユーザー、インターフェースユーザーを棚卸しする |
| SAP – Sensitive Roles / Profiles | 機密ロール・プロファイルを定義 | 業務部門が持つ高権限ロールも含めて確認する |
| SAP – Critical Authorizations | 重要な認可オブジェクトを定義 | 「誰が何を実行できると危険か」を基準に整理する |
公式ドキュメントでも、ウォッチリストにはサンプルや事前構成が含まれるものの、自社環境で機密とみなす操作、トランザクション、承認、テーブルをSAP BASISチームと相談して更新することが推奨されています。(Microsoft Learn)
Defenderポータル移行で見落としやすい運用変更
Microsoft Defenderに関する観点で最も重要なのは、Defenderポータルへの移行です。Microsoft SentinelはDefenderポータルで一般提供されており、2027年3月31日以降はAzure portalでサポートされず、Defenderポータルのみで利用されると公式ドキュメントに記載されています。Azure portal中心でSAP監視を運用している組織は、SAPコネクタ移行と並行して、SOC運用画面の移行も計画すべきです。(Microsoft Learn)
Defenderポータル移行時の主な注意点
| 領域 | 注意点 | 管理者が行うこと |
|---|---|---|
| インシデント相関 | DefenderポータルではDefender XDRエンジンがアラート相関やインシデント統合を制御 | SAPアラートが既存ルール名どおりに単独インシデント化される前提を見直す |
| Fusion | Azure portal側のFusion分析ルールは、Defenderポータル移行時に無効化される | 相関検知の運用手順をDefender XDR側の挙動に合わせる |
| アラートのみのルール | インシデント作成を無効にしたSentinel分析ルールのアラートはDefenderポータルで表示されない | SAP関連ルールのインシデント作成設定を確認する |
| 自動化ルール | インシデント条件や一部フィールドの扱いが変わる | Logic Apps、ServiceNowなどのチケット連携を再テストする |
| 手動・API作成インシデント | Azure portalやAPI、Logic Appで手動作成されたSentinelインシデントはDefenderポータルに同期されない | 手動起票や外部連携の運用をDefenderポータル基準に見直す |
| Advanced hunting | 既存のログテーブル、KQL、関数をAdvanced huntingで利用できる | SAP調査用KQLをDefenderポータルで実行し、表示差分を確認する |
公式の移行ドキュメントでは、Defenderポータル移行後にインシデントプロバイダー名がMicrosoft XDRになること、Fusionが無効化されること、アラート相関がDefender XDRエンジンで処理されること、Advanced huntingで既存のログテーブルやKQLを利用できることなどが説明されています。(Microsoft Learn)
RISE/ECSではアプリケーション層とインフラ層を分けて考える
SAP RISE/ECS環境では、標準のSAPアプリケーションコネクタだけで全レイヤーのログを取れると考えると設計ミスにつながります。公式のSAP LogServ連携ドキュメントでは、Microsoft Sentinel Solution for SAP applicationsはSAPアプリケーション層の監視を提供する一方、RISE/ECS環境ではインフラやOSログがSAPによって管理され、標準のSAPアプリケーションコネクタからはアクセスできないと説明されています。(Microsoft Learn)
RISE/ECSでHANAデータベース、OS、ネットワーク、SAP Web Dispatcher、SAP Cloud Connectorなどのログも含めて見たい場合は、SAP LogServ連携を併用する設計を検討します。公式情報では、SAP LogServがインフラ、データベース、OS層のログをMicrosoft Sentinelに取り込む補完的な役割を持つと説明されています。(Microsoft Learn)
開発者・自動化担当が確認すべきポイント
SAP向けSentinelソリューションを導入済みの環境では、KQL、プレイブック、外部連携、チケット起票の影響確認が必要です。特にDefenderポータル移行後は、画面が変わるだけでなく、インシデントの生成・相関・同期の挙動が変わる箇所があります。
KQLとカスタム検知
エージェントレス移行ガイドでは、既存のSAP向け分析ルール、ワークブック、プレイブックはエージェントレスデータコネクタでも機能し続けると説明されています。ただし、独自のKQLで特定の取り込み方式や古いテーブル名、特定列の有無に依存している場合は、移行後のデータで必ず検証してください。(Microsoft Learn)
確認する観点は次の通りです。
ABAPAuditLogなどの対象テーブルにデータが入っているか- SID、SourceSystem、Client、Userなどの条件が既存クエリと一致するか
- 本番・非本番を判定する条件がウォッチリストと整合しているか
- 旧エージェントとエージェントレスの並行稼働中に重複検知が起きないか
- DefenderポータルのAdvanced huntingで使うクエリと、Log Analytics側のクエリを混同していないか
プレイブックとチケット連携
Logic AppsプレイブックでServiceNowなどの外部チケットを作成している場合、Defenderポータル移行後のインシデントフィールド差分を確認してください。公式ドキュメントでは、Defenderポータル移行後にSecurityIncidentテーブルのDescriptionフィールドが含まれなくなることや、手動・API作成のSentinelインシデントがDefenderポータルへ同期されないことが説明されています。(Microsoft Learn)
開発者は、少なくとも次のテストを行うべきです。
| テスト項目 | 確認内容 |
|---|---|
| SAPアラート発火時のチケット起票 | ルール名、重大度、SID、ユーザー、トランザクションコードが正しく渡るか |
| インシデントURL | Azure portal向けURLではなく、DefenderポータルでSOCが開けるURLになっているか |
| 自動クローズ・抑制 | チューニング対象のサービスアカウントやRFCユーザーが過剰に除外されていないか |
| 手動実行 | Defenderポータルで手動プレイブック実行が必要な運用になっていないか |
| 並行稼働 | 旧コネクタと新コネクタの重複で同じチケットが二重起票されないか |
よくある失敗と回避策
SAP向けSentinelソリューションは、導入自体よりも運用設計で失敗しやすいサービスです。特に大規模SAP環境では、ログが入っていることと、実際に使える検知になっていることは別問題です。
| 失敗パターン | 起きる問題 | 回避策 |
|---|---|---|
| Content Hubで入れただけで満足する | コネクタ未設定のためログが入らない | インストール後にデータコネクタ接続とKQLでのログ確認まで行う |
| ウォッチリストを初期値のまま使う | 誤検知が多い、または重要操作を見逃す | 特権ユーザー、機密テーブル、ネットワークをBASISと共同で更新する |
| すべての分析ルールを一括有効化する | SOCに大量のアラートが流れ、運用が破綻する | 重要度が高く検証しやすいルールから段階的に有効化する |
| 本番・非本番の扱いを曖昧にする | 課金、重大度、検知条件が実態とずれる | SAP設定、ウォッチリスト、運用台帳の3点を突き合わせる |
| コンテナ型エージェントを使い続ける | 2026年9月14日以降に収集継続できなくなる可能性がある | エージェントレス接続を並行稼働し、期限前に切り替える |
| Defenderポータル移行を後回しにする | インシデント相関、自動化、チケット連携で想定外の差分が出る | SAP監視の移行計画にDefenderポータル運用テストを含める |
| RISE/ECSのインフラログも標準コネクタで取れると思い込む | OS・ネットワーク・HANAログの可視性が不足する | 必要に応じてSAP LogServ連携を検討する |
特に注意したいのは、SAP – Systemsウォッチリストで本番・非本番を定義しても、それ自体が課金判定を直接変えるわけではない点です。公式ドキュメントでは、本番システムの識別はSAPシステム側の構成を見て行われると説明されています。運用上の分類と課金上の分類を混同しないようにしてください。(Microsoft Learn)
管理者が今すぐ行うべき確認
Microsoft Sentinel solution for SAP applications overviewの更新を受けて、まず行うべきことは「新機能の確認」ではなく、現行環境の棚卸しです。
| 優先度 | 確認内容 | 完了の目安 |
|---|---|---|
| 高 | コンテナ型SAPエージェントを使っているか | 使用中ならエージェントレス移行計画を作成済み |
| 高 | DefenderポータルでSentinel運用を確認したか | SAPインシデントの表示、相関、自動化をテスト済み |
| 高 | SAP本番・非本番、SID、ログ種別を棚卸ししたか | 監視対象と課金対象の台帳がある |
| 中 | ウォッチリストを自社環境向けに更新したか | 特権ユーザー、機密テーブル、ネットワークが反映済み |
| 中 | 分析ルールを段階的に有効化しているか | ルールごとの誤検知チューニング方針がある |
| 中 | BTPシークレットやKey Vault運用を決めたか | ローテーション手順と所有者が決まっている |
| 中 | RISE/ECSのインフラログ要件を確認したか | SAP LogServの要否を判断済み |
今回の更新で最も重要なのは、SAP監視がMicrosoft Defenderポータルの統合SOC運用に近づいていること、そしてコンテナ型エージェントからエージェントレス接続への移行が避けられないことです。既存環境では、コネクタ方式、ログ取り込み、分析ルール、ウォッチリスト、プレイブック、Defenderポータルでのインシデント運用を順番に確認してください。
新規導入なら、エージェントレス接続、Content Hub展開、段階的な分析ルール有効化、BASISとのウォッチリスト整備を最初の設計に含めるのが安全です。既存導入済みなら、2026年9月14日のコンテナ型エージェント無効化予定と、2027年3月31日以降のDefenderポータル中心の運用を前提に、移行スケジュールを今のうちに具体化しましょう。
コメント