2026年4月30日に更新された Microsoft Defender の公式ドキュメント「Learn Editor: Update behaviors.md」は、Microsoft Defender for Cloud Apps や Microsoft Defender XDR の高度なハンティングで使う「behaviors」を運用している管理者が確認すべき更新です。結論から言うと、最優先で見るべき点は「Defender本体の緊急変更」ではなく、アラートから behaviors への移行、2026年5月予定のVM関連 behavior 廃止、カスタム検出とRBACの見直しです。対象コミットは2026年4月30日付で、GitHub上では「0 file changed」と表示されているため、コミット単体だけで製品仕様が変わったと判断せず、公開済みLearnページの内容と自社運用への影響を確認するのが安全です。(GitHub)
Microsoft Defenderの公式ドキュメント更新「Learn Editor: Update behaviors.md」で何を確認すべきか
今回の更新で確認すべき中心は、Microsoft Defender for Cloud Apps の「behaviors」を、Microsoft Defender XDR の高度なハンティングやカスタム検出でどう扱うかです。
behaviorsは、必ずしも侵害やインシデントを意味するものではありません。生のイベントデータとアラートの中間にある調査用のコンテキスト情報で、MITRE ATT&CKのカテゴリや技術と関連付けられます。つまり、SOCやセキュリティ管理者は「アラートが出たかどうか」だけでなく、「behaviorとして残っている異常な行動をどう調査・通知・記録するか」を設計する必要があります。(Microsoft Learn)
特に確認すべき点は次の3つです。
| 確認ポイント | 運用への影響 | すぐに取るべき対応 |
|---|---|---|
| alertsからbehaviorsへの移行 | 以前はアラートとして扱っていた低忠実度の検出が、既定ではアラート化されない可能性がある | 必要な検出はカスタム検出ルールで再アラート化する |
| VM関連behaviorの廃止予定 | MultipleVmCreationActivities と MultipleDeleteVmActivities が将来のハンティングや相関で使えなくなる | KQL、SIEM、SOAR、レポートで対象ActionTypeを検索する |
| RBACスコープ | behaviorsに含まれるユーザー、アプリ、IP、クラウドリソース情報の閲覧範囲が権限設計に影響する | security adminsとcompliance teamsで閲覧権限を再確認する |
behaviorsとは何か：アラートではなく「調査の材料」
Microsoft Defenderの運用で混同しやすいのが、イベント、behavior、アラートの違いです。
| 種類 | 役割 | 運用上の見方 |
|---|---|---|
| 生イベント | アプリ、ユーザー、IP、ファイル操作などの個別ログ | 量が多く、単体では判断しづらい |
| behavior | 複数のイベントから導かれる異常行動や文脈情報 | 調査の入口。悪性とは限らない |
| アラート | 対応が必要な可能性が高い検出 | インシデント対応、通知、チケット化の対象 |
たとえば「Mass download」は、大量ダウンロードを示すbehaviorです。退職予定者による不審な持ち出しの可能性もあれば、部門移管やバックアップ作業のような正当な業務の可能性もあります。ここで重要なのは、behaviorをそのままインシデント扱いしないことです。
実務では、次のように判断します。
| 判断軸 | 確認例 |
|---|---|
| ユーザーの通常業務と一致するか | 経理担当が月末に大量ファイルを取得しているのか、普段アクセスしない部署のファイルを取得しているのか |
| IPや地域が通常と違うか | 普段は日本からのみアクセスするユーザーが、短時間に海外IPから操作していないか |
| OAuthアプリやPower BIなど高リスク領域か | 外部アプリ連携、レポート共有、認証情報追加が絡んでいないか |
| 既存アラートと関連しているか | Defender XDRのインシデント、Entra IDのサインインリスク、CloudAppEventsと照合できるか |
alertsからbehaviorsへの移行で何が変わるのか
公式ドキュメントでは、Defender for Cloud Apps がアラートの品質を高め、誤検知を減らす目的で、セキュリティコンテンツを alerts から behaviors に移行していると説明されています。移行フェーズとして、behaviorsをアラートと並行送信する段階、behaviorを生成するポリシーが既定で無効化されアラートを送信しない段階は完了済みです。今後は、顧客向けポリシーを削除し、クラウド管理の検出モデルへ移行するフェーズが予定されていますが、最終フェーズの時期は未確定で、変更はMessage Centerで通知されるとされています。(Microsoft Learn)
ここでの実務上のポイントは、「アラートが減った＝安全になった」と判断しないことです。アラート数が減っても、behaviorとして調査材料が残っている場合があります。
特に次のような運用をしている組織は見直しが必要です。
- Defender XDRのアラート件数をKPIとしている
- SIEMやSOARがアラートだけを取り込んでいる
- 内部不正や情報持ち出しをDefender for Cloud Appsの既定アラートに依存している
- 月次の監査レポートで「アラート未検出」を安全性の根拠にしている
- SOCの一次トリアージがAlertInfo中心で、BehaviorInfoやBehaviorEntitiesを見ていない
アラート中心の運用から、behaviorも含めた調査・通知・記録の運用へ移る必要があります。
2026年5月予定のVM関連behavior廃止は必ず確認する
今回の公式ページで特に実務影響が大きいのは、次の2つのbehaviorが2026年5月中に非推奨になる予定とされている点です。
| 廃止予定のbehavior | ActionType |
|---|---|
| Multiple VM creation activities | MultipleVmCreationActivities |
| Multiple delete VM activities | MultipleDeleteVmActivities |
非推奨後、これらのbehaviorsは生成されなくなり、Microsoft Defender XDRでのハンティング、カスタム検出、相関に利用できなくなると説明されています。非推奨前に生成されたレコードは、標準のデータ保持ポリシーに従って保持されます。(Microsoft Learn)
まず、現在のテナントで対象ActionTypeが使われているかを確認します。
BehaviorInfo
| where ActionType in ("MultipleVmCreationActivities", "MultipleDeleteVmActivities")
| summarize LastSeen=max(Timestamp), Count=count() by ActionType
| order by LastSeen desc直近の発生ユーザーや関連エンティティを確認する場合は、BehaviorIdでBehaviorEntitiesと結合します。
BehaviorInfo
| where ActionType in ("MultipleVmCreationActivities", "MultipleDeleteVmActivities")
| project BehaviorId, BehaviorTime=Timestamp, ActionType, Title, Description, AccountUpn
| join kind=leftouter (
BehaviorEntities
| project BehaviorId, EntityType, EntityRole, AccountName, RemoteIP, CloudPlatform, CloudResourceType, CloudResourceId
) on BehaviorId
| order by BehaviorTime desc対象ActionTypeが見つかった場合は、単にKQLを書き換えるだけでは不十分です。次の場所も確認してください。
| 確認場所 | 見るべき内容 |
|---|---|
| Defender XDRのカスタム検出ルール | クエリ本文に対象ActionTypeが含まれていないか |
| Microsoft Sentinelの分析ルール | BehaviorInfo、BehaviorEntities、または取り込み済みXDRデータを使っていないか |
| SOARプレイブック | VM作成・削除関連の自動通知やチケット作成が対象ActionTypeに依存していないか |
| ダッシュボード | 月次レポート、監査証跡、異常操作件数に対象ActionTypeが入っていないか |
| 手順書 | 「Multiple VM creation activitiesを確認する」といった調査手順が残っていないか |
代替検知を作る場合は、自社でどのクラウドサービスを監視しているかに応じて、CloudAppEventsやクラウド監査ログ、Sentinel側のデータソースを使う設計を検討します。CloudAppEventsは、Office 365やその他のクラウドアプリ・サービスに関するアカウントやオブジェクトのイベントを格納する高度なハンティングテーブルです。Defender for Cloud Appsが展開されていない環境では、このテーブルを使うクエリは結果を返さない可能性があります。(Microsoft Learn)
Advanced Huntingで見るべきテーブル
Microsoft Defender XDRの高度なハンティングでは、behaviors関連の主なテーブルとしてBehaviorInfoとBehaviorEntitiesを使います。公式リファレンスでは、どちらもPreviewとして扱われており、GCCでは利用できない旨も記載されています。運用ルールを作る場合は、利用可能なテナント種別と展開済みサービスを必ず確認してください。(Microsoft Learn)
| テーブル | 主な用途 | 確認する列の例 |
|---|---|---|
BehaviorInfo | behavior単位の概要確認 | Timestamp, BehaviorId, Title, Description, ActionType, AttackTechniques, AccountUpn |
BehaviorEntities | behaviorに関係するユーザー、IP、ファイル、デバイス、アプリなどの確認 | EntityType, EntityRole, RemoteIP, AccountName, Application, CloudResourceId |
CloudAppEvents | クラウドアプリ上の詳細イベント確認 | ActionType, Application, IPAddress, ActivityObjects, RawEventData |
調査時は、まずBehaviorInfoで異常行動の種類を把握し、BehaviorEntitiesで関係者やIP、アプリ、クラウドリソースを確認します。
BehaviorInfo
| where Timestamp > ago(7d)
| where ActionType in ("MassDownload", "SuspiciousAdministrativeActivity", "SuspiciousOauthAppFileDownloadActivities")
| project BehaviorId, BehaviorTime=Timestamp, ActionType, Title, Description, AccountUpn, AttackTechniques
| join kind=leftouter (
BehaviorEntities
| project BehaviorId, EntityType, EntityRole, RemoteIP, AccountName, Application
) on BehaviorId
| order by BehaviorTime desc公式ページには、大量ダウンロードを特定ユーザーに対して検出する例も示されています。実際にカスタム検出へ使う場合は、コピー時に全角引用符が混ざっていないか、対象ユーザーが過剰に広くないか、日常業務で大量検知しないかを確認してから有効化しましょう。(Microsoft Learn)
BehaviorEntities
| where Timestamp > ago(1d)
| where ActionType == "MassDownload"
| where EntityType == "User"
| where AccountName in ("username1", "username2")カスタム検出ルールを作るときの注意点
アラートが既定で生成されなくなった検出を引き続きアラート化したい場合は、カスタム検出ルールを使います。Microsoft Defender XDRのカスタム検出ルールは、高度なハンティングクエリをもとに定期実行され、条件に一致した場合にアラートや対応アクションを生成できます。(Microsoft Learn)
ただし、behaviorをそのまま全部アラート化すると、誤検知や通知疲れが起きます。次の基準で絞り込むのが現実的です。
| 設計項目 | 推奨する考え方 |
|---|---|
| 対象ユーザー | 役員、管理者、退職予定者、特権ロール保持者などリスクの高い範囲から始める |
| 対象ActionType | MassDownload、SuspiciousAdministrativeActivity、OAuth関連など、自社リスクに直結するものを優先する |
| 実行頻度 | リアルタイム性が必要なものと、日次確認で十分なものを分ける |
| アラート重大度 | behavior単体では低めにし、外部IP・特権操作・深夜帯など条件が重なった場合に上げる |
| 除外条件 | バックアップ、移行作業、定期レポート作成など既知の正常操作を除外する |
カスタム検出ルールを作る前には、クエリを実行してエラーや結果の傾向を確認する必要があります。また、ルールごとに一度の実行で生成できるアラート数には上限があるため、通常業務を大量に拾うクエリのまま有効化しないことが重要です。(Microsoft Learn)
RBACとコンプライアンスで確認すべきこと
2025年3月以降、Defender for Cloud Appsではbehaviorsに対するRBACスコープを構成できると説明されています。これは、security adminsだけでなく、compliance teamsや監査担当者にも関係します。behaviorには、ユーザー名、IPアドレス、アプリケーション、クラウドリソースなど、調査上重要な情報が含まれるためです。(Microsoft Learn)
次のような権限設計を確認してください。
| 担当者 | 必要な確認 |
|---|---|
| SOCアナリスト | behaviorの閲覧、ハンティング、カスタム検出の作成権限があるか |
| コンプライアンス担当 | 証跡確認に必要な範囲だけを閲覧できるか |
| グローバル管理者 | 日常運用で過剰に使われていないか |
| 外部委託SOC | 委託範囲外のアプリ・部門データまで見えていないか |
| 監査対応担当 | アラートとbehaviorの違いを説明できるレポート形式になっているか |
失敗しやすいのは、アラートだけを監査証跡として扱い、behaviorを見落とすケースです。アラート化されない異常行動でも、調査や内部統制の観点では重要な場合があります。月次レポートでは「アラート件数」だけでなく、「重要ActionTypeのbehavior件数」「カスタム検出化した条件」「除外した正常業務」を分けて記録すると、説明しやすくなります。
移行準備チェックリスト
今回のMicrosoft Defender公式ドキュメント更新を受けて、enterprise ITやセキュリティ運用チームは次の順番で確認すると効率的です。
| 手順 | 作業内容 | 完了の目安 |
|---|---|---|
| 1 | 公式LearnページとGitHubコミットを確認する | 更新日、対象ページ、差分の有無を把握している |
| 2 | BehaviorInfoとBehaviorEntitiesで直近の発生状況を見る | 自社で使われているActionTypeが分かる |
| 3 | VM関連の廃止予定ActionTypeを検索する | MultipleVmCreationActivitiesとMultipleDeleteVmActivitiesの依存有無が分かる |
| 4 | カスタム検出ルールを棚卸しする | 対象ActionTypeや古いポリシー名に依存していない |
| 5 | SIEM、SOAR、チケット連携を確認する | アラートだけでなくbehavior由来の検知設計を把握している |
| 6 | RBACスコープを確認する | 最小権限で必要な担当者が調査できる |
| 7 | レポート指標を更新する | アラート数とbehavior件数を混同していない |
| 8 | Message Centerを監視する | クラウド管理検出モデルへの移行通知を見逃さない |
グローバル運用で注意したいポイント
グローバル企業では、日本語ページだけでなく英語ページも確認することをおすすめします。Microsoft Learnのローカライズページは便利ですが、更新反映や表現に差が出ることがあります。今回のようなDefender for Cloud Apps、Microsoft Defender XDR、高度なハンティング関連の更新では、英語の公式ページ、Message Center、Defenderポータル内の実際の表示を合わせて確認するほうが安全です。
また、海外拠点のSOCと日本側のIT管理者で、次の用語をそろえておくと混乱を避けられます。
| 英語表記 | 日本語運用での表現例 |
|---|---|
| behavior | 動作、異常行動、behaviorデータ |
| alert | アラート |
| custom detection | カスタム検出 |
| advanced hunting | 高度なハンティング |
| ActionType | 検出種別、ActionType |
| correlation | 相関、相関分析 |
特に「behavior」は日本語で「動作」と訳されるため、エンドポイントの動作監視や一般的なユーザー行動ログと混同されがちです。手順書では、可能であれば「Defender XDRのBehaviorInfo/BehaviorEntitiesに記録されるbehavior」のように、テーブル名まで含めて書くと誤解が減ります。
まとめ：まずはActionType依存とカスタム検出を確認する
Microsoft Defenderの公式ドキュメント更新「Learn Editor: Update behaviors.md」で最初に確認すべきなのは、製品画面の見た目ではなく、運用ロジックです。
特に、次の4点を優先してください。
BehaviorInfoとBehaviorEntitiesを使った調査フローがあるか- アラートからbehaviorsへの移行により、必要な検出が見落とされていないか
- 2026年5月予定のVM関連behavior廃止に依存したKQL、SIEM、SOAR、レポートがないか
- behaviorsのRBACスコープが、SOC・監査・コンプライアンスの実務に合っているか
今回の更新は、単なるドキュメント確認で終わらせるよりも、自社のDefender XDR運用を「アラートを見る運用」から「behaviorを含めて調査する運用」へ整えるきっかけにするのが効果的です。
コメント