Microsoft Defenderで隔離されたメールやファイルを管理する場合、今回まず押さえるべき結論は「削除は復旧前提で扱わない」「リリースは元の場所への復元ではなく再配信として扱う」「プレビューやダウンロードには内容閲覧用の権限を確認する」の3点です。特にMicrosoft Defender for Office 365を利用している組織では、Exchange Onlineのメールだけでなく、SharePoint、OneDrive、Microsoft Teams上の隔離ファイルも管理対象になります。(Microsoft Learn)
Microsoft Learnの対象ページはメタデータ上 ms.date: 05/19/2026、ページ下部でも「Last updated on 2026-05-19」と表示されています。本記事では、日本時間2026年5月20日時点で管理者が確認すべき影響範囲、設定、移行・展開時の注意点を整理します。(GitHub)
Microsoft Defenderのセキュリティ更新、管理者が確認すべき影響範囲と対応ポイント
Microsoft Defenderの隔離管理は、迷惑メールを一覧から戻すだけの機能ではありません。誤検知対応、危険な添付ファイルの調査、ユーザーからのリリース申請、監査ログ確認、PowerShellによる運用自動化まで関係します。
今回の確認ポイントは、機能追加よりも運用ルールの見直しが必要な明確化と捉えると分かりやすいです。特に削除・リリース・権限の扱いは、ヘルプデスクの手順書やSOCのエスカレーション基準にそのまま影響します。
| 確認項目 | 管理者への影響 | すぐ確認すべきこと |
|---|---|---|
| 隔離メールの削除 | 削除後の復旧を前提にした運用は危険 | 削除前レビュー、承認フロー、監査ログ確認手順 |
| メールのリリース | Outlook上では再配信時刻で表示される場合がある | ユーザー案内文と問い合わせ対応テンプレート |
| プレビュー・ダウンロード権限 | メタデータ閲覧と本文・内容閲覧を分けて考える必要がある | Unified RBAC、Quarantine Administrator、Security Administratorなどの権限 |
| SharePoint・OneDrive・Teamsの隔離ファイル | メール以外のファイルも隔離管理の対象になる | Defender for Office 365 Plan 1/2、Safe Attachments設定 |
| PowerShell運用 | 一括確認や自動化の対象になる | Get、Release、Delete、Export系コマンドレットの利用範囲 |
変更点の要点：削除・復旧・リリース時刻・内容閲覧権限を見直す
GitHub上のMicrosoftDocs履歴では、2026年5月19日に「Only one delete option available」と「Can’t recover deleted quarantine items」という変更が記録されています。前者では削除フローが「Permanently delete the message from quarantine」を選んで削除する説明に整理され、後者では削除済み隔離アイテムの復旧がサポートされない旨が明確化されています。(GitHub)
また、2026年4月の更新では、隔離メールをリリースした場合に「元の場所へ復元」されるのではなく、受信者のメールボックスへ再配信されるため、Outlook上の表示時刻が再配信時刻になるという注記が追加されています。元の送信日時はメッセージヘッダーに保持されます。(Microsoft Learn)
さらに、隔離メールのプレビューやダウンロードには、Defender XDR Unified RBACで「Email and Collaboration content: Quarantine Emails (read)」に相当する内容閲覧権限が示されています。単に隔離一覧を読めるだけでは、本文確認やダウンロードまでできない可能性がある点に注意が必要です。(Microsoft Learn)
管理者が誤解しやすいポイント
「隔離から削除」は、通常のメールボックス内の削除とは意味が違います。ユーザーの削除済みアイテムやExchangeの保持機能から簡単に戻せる前提で扱うと、調査証跡や誤検知対応で問題になります。
同様に、「リリース」は元の受信時刻でメールが復活する操作ではありません。ユーザーから「メールが今日届いたように見える」「本来の受信順と違う」と問い合わせが来る可能性があります。ヘルプデスク向けには、次のように説明を用意しておくと実務で混乱を減らせます。
| 問い合わせ例 | 回答のポイント |
|---|---|
| 隔離メールを戻したのに、受信日時が今日になっている | リリースは再配信として処理されるため、Outlook上の表示時刻が変わることがある |
| 元の送信日時を確認したい | メッセージヘッダーに元の送信日時が保持される |
| 削除した隔離メールを戻したい | 削除済み隔離アイテムの復旧はサポートされないため、削除前確認が重要 |
| 本文を確認できない | 一覧閲覧権限とは別に、隔離メール内容の読み取り権限が必要な場合がある |
対象範囲：クラウドメールボックス全体とDefender for Office 365のファイル保護
Microsoft 365のクラウドメールボックスを持つ組織では、危険または不要と判定されたメッセージが隔離に保持されます。管理者は、ユーザー全体の隔離メッセージを表示、リリース、削除できます。Defender for Office 365を利用している組織では、Safe Attachmentsによって隔離されたSharePoint、OneDrive、Microsoft Teamsのファイルや、TeamsメッセージのZAPによる隔離も管理対象に含まれます。(Microsoft Learn)
| 領域 | 対象 | 主な管理操作 |
|---|---|---|
| Exchange Onlineのメール | スパム、フィッシング、マルウェア、トランスポートルールなどで隔離されたメール | 表示、プレビュー、リリース、削除、Microsoftへの送信、ダウンロード |
| SharePoint / OneDriveのファイル | Safe Attachmentsで悪意ありと判定されたファイル | 表示、リリース、削除、ダウンロード |
| Microsoft Teams | Safe AttachmentsやZAPの対象となるメッセージ・ファイル | Defender for Office 365の構成に応じて管理 |
| 監査ログ | 管理者またはユーザーが行った隔離操作 | 削除者の確認、運用証跡の確認 |
| PowerShell | 隔離メッセージやファイルの管理 | Get、Release、Delete、Exportなどのコマンドレット |
ここで重要なのは、メールの隔離とファイルの隔離では保持後の状態が同じではないことです。SharePointやOneDriveで隔離されたファイルは30日後に隔離から削除されますが、ブロックされたファイル自体はSharePointまたはOneDrive上でブロック状態のまま残ると説明されています。(Microsoft Learn)
権限設計：Global Administratorに頼らず最小権限で運用する
隔離管理では、誰が「見るだけ」なのか、誰が「リリースできる」のか、誰が「本文をプレビュー・ダウンロードできる」のかを分けて設計する必要があります。Microsoftは最小権限の原則を推奨しており、Global Administratorは非常に強い権限であるため、緊急時や代替ロールが使えない場合に限定すべきとしています。(Microsoft Learn)
特に確認すべきロールは次の通りです。
| 目的 | 確認する権限・ロールの例 | 注意点 |
|---|---|---|
| 全ユーザーの隔離メッセージに対処する | Quarantine Administrator、Security Administrator、Organization Management、またはUnified RBACの隔離管理権限 | 運用担当者にGlobal Administratorを付与しない |
| 読み取り専用で確認する | Security Reader、Global Reader、Unified RBACの読み取り権限 | リリースや削除はできない前提で分担する |
| 隔離メールの本文プレビューやダウンロード | Unified RBACのQuarantine Emails read相当 | 一覧閲覧とは分けて権限棚卸しを行う |
| Microsoftへ誤検知として送信する | Security Administratorなど | 誤検知報告と許可リスト追加の扱いを明確にする |
| SharePoint / OneDrive / TeamsのSafe Attachments設定 | Security Administrator、Organization Management、必要に応じてSharePoint Administrator | メール管理者だけではファイル側の設定確認が不足する |
注意点として、現在の公式手順では、Azure Privileged Identity Managementで割り当てられたロールは隔離でサポートされない旨が示されています。また、Exchange Online権限による隔離メッセージ管理は2023年2月に終了しており、他組織のゲスト管理者は受信者と同じ組織内の管理者でない限り隔離メッセージを管理できません。(Microsoft Learn)
移行・展開時のチェックポイント
既存の運用が古いExchange Online権限や過剰なGlobal Administrator付与に依存している場合、今回の更新内容とは別に、運用そのものを見直す価値があります。
展開前には、次の順で確認すると抜け漏れを防ぎやすくなります。
| 順番 | 確認内容 | 実務上の判断基準 |
|---|---|---|
| 1 | 誰が隔離一覧を見るか | SOC、ヘルプデスク、メール管理者を分ける |
| 2 | 誰がリリースできるか | 誤配送リスクがあるため、一次対応者と承認者を分ける |
| 3 | 誰が本文をプレビュー・ダウンロードできるか | 個人情報や機密情報を扱うため、最小限にする |
| 4 | 誰が削除できるか | 復旧不可を前提に、削除権限は絞る |
| 5 | 誰がMicrosoftへ送信できるか | 誤検知改善と許可リスト追加の判断者を決める |
| 6 | 監査ログを誰が確認するか | インシデント後に「誰が何をしたか」を追える体制にする |
隔離ポリシー：ユーザーに何を許可するかを決める
隔離ポリシーは、ユーザーが自分宛ての隔離メッセージに対して何をできるか、通知を受け取るかを定義する設定です。管理者は、受信者への通知有無や、ユーザーがリリース申請・削除・プレビューなどを行えるかを制御できます。(Microsoft Learn)
ここでの判断基準は、「ユーザーの利便性」と「誤って危険なメールを戻すリスク」のバランスです。
| 運用方針 | 向いている組織 | 注意点 |
|---|---|---|
| 管理者のみがリリースする | 金融、医療、法務、機密情報を扱う部門 | ヘルプデスク負荷が上がる |
| ユーザーはリリース申請のみ可能 | 一般的な企業利用 | 承認待ちのSLAを決める必要がある |
| 一部の低リスクメールはユーザーがリリース可能 | 情報システム部門が小さく、業務停止影響が大きい組織 | 高信頼度フィッシングやマルウェアは慎重に扱う |
| 通知を有効化する | 隔離に気づかず業務が止まりやすい組織 | 通知が多すぎるとユーザーが無視しやすい |
なお、隔離ポリシーの割り当てを変更しても、変更前に隔離されたメッセージには新しい割り当てが適用されないと説明されています。ポリシー展開時は「変更後に隔離されたメールから適用される」と周知しておくと、検証時の誤解を避けられます。(Microsoft Learn)
保持期間：30日と思い込まず理由別に確認する
隔離されたメッセージやファイルの保持期間は、隔離理由によって異なります。たとえば、スパムやフィッシングなどはポリシーによって15日または30日の扱いがあり、マルウェア、Safe Attachments、メールフロールール、TeamsのZAP、SharePoint・OneDrive・Teamsのファイル隔離は30日と説明されています。期限を過ぎたメッセージは完全に削除され、復旧できません。(Microsoft Learn)
| 隔離理由・対象 | 既定の考え方 | 管理上の注意 |
|---|---|---|
| スパム、バルク、フィッシング、高信頼度フィッシング | ポリシーにより15日または30日 | 既定ポリシーとプリセットセキュリティポリシーで差が出る |
| マルウェアメール | 30日 | ユーザーにリリースさせる運用は避ける |
| Safe Attachmentsのメール | 30日 | リリース前に本文、URL、添付ファイルを確認する |
| メールフロールールで隔離 | 30日 | ルール設計ミスで業務メールを止めないよう監視する |
| SharePoint / OneDrive / Teamsの悪意あるファイル | 30日 | 隔離から消えてもファイルはブロック状態で残る場合がある |
| Teamsチャット・チャネルのZAP隔離 | 30日 | Teams運用部門にも影響を共有する |
実務では、保持期間ぎりぎりのメールをまとめて確認する運用は危険です。優先度の高いアカウント、経理・人事・役員などの重要部門、外部取引先からのメールは、毎営業日または定期的にフィルターで確認する運用を推奨します。
メール隔離の実務手順：探す、判断する、実行する
管理者はMicrosoft Defenderポータルの「Email & collaboration」から「Review」>「Quarantine」>「Email」タブへ進み、隔離メールを確認します。一覧では、受信時刻、件名、送信者、隔離理由、リリース状態、ポリシー種類、期限などを確認できます。検索ボックスは現在表示中のビューを検索するものであり、すべての隔離アイテムを対象に探す場合はフィルターを使う必要があります。(Microsoft Learn)
メッセージを探すときの実務テクニック
問い合わせ対応では、ユーザーから「メールが届かない」とだけ連絡されることがよくあります。その場合は、次の順で絞り込むと調査時間を短縮できます。
| 状況 | 使う条件 | ポイント |
|---|---|---|
| 送信者が分かっている | Sender address | 取引先ドメイン単位ではなく、可能ならメールアドレス単位で確認 |
| 受信者が分かっている | Recipient address | 代理アドレス宛てでも主メールアドレスに解決される点に注意 |
| 件名が分かっている | Subject | 表記ゆれがある場合はMessage traceも併用 |
| Message IDが分かっている | Message ID | 山括弧を含む完全な値で検索 |
| 緊急度が高い | Time received、Expires | 期限切れ前に処理する |
| 重要ユーザー | Recipient tag | Priority accountなどのタグを活用 |
Message traceで「配信ではなく隔離された」と分かった場合は、Message IDを使って隔離画面で確認すると、同名件名のメールと取り違えにくくなります。
リリース前に確認すべき判断基準
隔離メールをリリースする前に、少なくとも次の項目を確認します。
| 確認項目 | リリースしてよい可能性が高い例 | 止めるべき例 |
|---|---|---|
| 送信者 | 既知の取引先で、過去のやり取りと整合する | 表示名だけ既知で、実メールアドレスが不自然 |
| 件名 | 業務文脈と一致している | 緊急・支払い・パスワード更新を強く促す |
| URL | 公式ドメインや既知の業務システム | 短縮URL、不審なリダイレクト、類似ドメイン |
| 添付ファイル | 事前に共有予定が分かっている | 実行形式、マクロ、暗号化ZIP、内容不明のファイル |
| 認証結果 | SPF、DKIM、DMARCなどが整合 | なりすましや中継不審がある |
| 隔離理由 | バルクやスパムなど低リスク寄り | マルウェア、高信頼度フィッシング、Safe Attachments検出 |
リリース時に「Submit the message to Microsoft to improve detection」を選ぶと、誤検知としてMicrosoftに報告できます。また、「Allow this message」を選んだ場合はTenant Allow/Block Listに送信者、URL、添付ファイルなどの許可エントリが追加され、既定では最終使用から45日後に削除される設定が示されています。(Microsoft Learn)
削除運用：復旧できない前提で承認フローを作る
今回もっとも運用に影響しやすいのは、隔離メール削除の扱いです。公式手順では、隔離メールを削除すると元の受信者には送られず、削除画面で「Permanently delete the message from quarantine」を選択して削除したメッセージは復旧できないと説明されています。(Microsoft Learn)
削除は次のような基準で扱うと安全です。
| 判断 | 対応 |
|---|---|
| 明らかなマルウェア、認証情報窃取、業務と無関係なフィッシング | 削除候補。ただし監査ログ確認のため記録を残す |
| ユーザーが業務メールだと主張している | 削除せず、プレビュー・ヘッダー・送信者確認を行う |
| 取引先からの請求書や契約書 | 誤検知の可能性があるため、セキュリティ担当が確認 |
| 複数ユーザーに届いた同一メール | 一括削除前に代表サンプルを分析 |
| 法務・監査上の保持が必要な可能性がある | 削除権限者に確認し、必要なら別途証跡を確保 |
削除した人物を確認したい場合、管理者はDefenderポータルまたはMicrosoft Purviewポータルの監査検索で「Deleted Quarantine message」を検索できます。隔離操作は監査対象であるため、削除権限を付与する場合は監査ログの確認手順までセットで整備するべきです。(Microsoft Learn)
SharePoint・OneDrive・Teamsの隔離ファイル管理
Defender for Office 365 Plan 1またはPlan 2を利用している組織では、SharePoint、OneDrive、Microsoft TeamsでSafe Attachmentsにより隔離されたファイルをDefenderポータルから管理できます。ファイル隔離の画面では、ユーザー、場所、ファイル名、ファイルURL、ファイルサイズ、リリース状態、期限、検出元などを確認できます。(Microsoft Learn)
Safe Attachmentsを有効化する
SharePoint、OneDrive、Teams向けのSafe Attachmentsは、Microsoft DefenderポータルまたはExchange Online PowerShellで有効化できます。設定反映には最大30分かかる可能性があり、PowerShellでは Set-AtpPolicyForO365 -EnableATPForSPOTeamsODB $true が示されています。(Microsoft Learn)
また、Safe Attachmentsで検出された悪意あるファイルについて、既定ではユーザーが開く、移動する、コピーする、共有する操作はできない一方、削除やダウンロードは可能と説明されています。ダウンロードを防ぎたい場合は、SharePoint Online PowerShellで Set-SPOTenant -DisallowInfectedFileDownload $true を設定します。この設定はユーザーと管理者の両方に影響します。(Microsoft Learn)
| 設定 | 目的 | 注意点 |
|---|---|---|
| Safe Attachments for SharePoint, OneDrive, and Teamsを有効化 | 共同作業領域の悪意あるファイル共有を防ぐ | Defender for Office 365のライセンスが必要 |
| DisallowInfectedFileDownloadを有効化 | 悪意あるファイルのダウンロードを防ぐ | 管理者にも影響するため、調査用手順を別途用意する |
| 検出ファイルのアラートポリシーを作成 | 管理者が悪意あるファイル検出に気づけるようにする | 通知先と重大度を運用に合わせて決める |
| Threat protection status reportを確認 | SharePoint、OneDrive、Teamsの検出状況を見る | 定期レビューに組み込む |
PowerShellと自動化：開発者・運用担当が確認すべきこと
公式手順では、隔離メッセージやファイルの管理にExchange Online PowerShellのコマンドレットが示されています。対象には Get-QuarantineMessage、Release-QuarantineMessage、Delete-QuarantineMessage、Export-QuarantineMessage などが含まれます。ただし、Preview-QuarantineMessage はメッセージ専用で、隔離ファイルには使えないと説明されています。(Microsoft Learn)
開発者や運用自動化担当者は、次の点を確認してください。
| 観点 | 確認内容 |
|---|---|
| 権限 | スクリプト実行アカウントが最小権限で必要操作を実行できるか |
| 対象 | メールとファイルを同じ処理として扱っていないか |
| 削除 | 自動削除処理に承認・ログ・対象条件の制限があるか |
| リリース | 誤リリース時の影響範囲を記録しているか |
| 監査 | 操作ログをMicrosoft 365側の監査ログと突合できるか |
| 例外処理 | 保持期限切れ、権限不足、既にリリース済みの状態を処理できるか |
自動化する場合、最初から削除やリリースを実行するスクリプトを展開するのは避けるべきです。まずは読み取り専用で隔離件数、期限切れ間近の件数、隔離理由、対象ユーザーを可視化し、運用者が判断できるダッシュボードやレポートから始めると安全です。
管理者向けの実践チェックリスト
本番環境での確認は、次の順番で進めると効率的です。
| チェック | 内容 | 完了基準 |
|---|---|---|
| 権限棚卸し | 隔離閲覧、内容閲覧、リリース、削除、Microsoft送信の権限を確認 | Global Administrator依存を減らせている |
| ポリシー確認 | 隔離ポリシー、通知、ユーザー操作権限を確認 | 部門ごとの運用方針と一致している |
| 削除手順 | 削除前確認と承認フローを整備 | 復旧不可を前提に手順書化されている |
| リリース案内 | 再配信時刻の説明をヘルプデスク文書に追加 | ユーザー問い合わせ時に説明できる |
| Safe Attachments | SharePoint、OneDrive、Teamsの保護を確認 | 有効化、ダウンロード制御、アラートが確認済み |
| 監査 | 削除者や操作履歴の検索手順を確認 | インシデント時に追跡できる |
| PowerShell | 自動化スクリプトの対象と権限を確認 | メールとファイルの違いを考慮している |
| 教育 | ヘルプデスクとSOCに変更点を共有 | 誤削除・誤リリースを防ぐ運用になっている |
よくある失敗と対策
隔離メールをまとめて削除してしまう
複数選択による一括操作は便利ですが、誤検知メールをまとめて消すリスクがあります。特に取引先ドメイン、請求書、採用応募、問い合わせフォーム経由のメールは、スパム判定されても業務上重要な可能性があります。
対策として、削除前に「隔離理由」「送信者」「受信者」「件名」「検出ポリシー」「期限」を確認するチェックを必須にします。高リスクな隔離理由でない場合は、削除ではなく一時保留にする判断も有効です。
リリース後にユーザーがメールを見つけられない
リリースされたメールは再配信として扱われるため、ユーザーは元の受信日時付近ではなく、リリース時刻付近でメールを探す必要があります。Inboxルールによって別フォルダーに移動または削除される可能性もあるため、必要に応じてMessage traceを併用します。(Microsoft Learn)
Allow senderやBlock senderの意味を誤解する
Allow senderやBlock senderは、管理者が組織全体の許可・拒否を設定する操作とは限りません。公式手順では、これらの操作は「Recipient > Only me」でフィルターした場合に表示され、サインイン中のメールボックスのSafe SendersまたはBlocked Sendersに追加される説明があります。組織全体でブロックしたい場合は、メールフロールールなど別の手段を検討します。(Microsoft Learn)
ファイル隔離をメール隔離と同じように扱う
SharePointやOneDriveのファイルは、隔離から削除されてもファイル自体がブロック状態で残る場合があります。また、ファイルのリリース時にMicrosoftへ報告できない旨も示されています。メールの誤検知対応と同じワークフローをそのまま流用せず、ファイル所有者、サイト管理者、SharePoint管理者を含めた対応ルートを作るべきです。(Microsoft Learn)
まず実施すべき対応
今回のMicrosoft Defender for Office 365の隔離管理に関する更新は、大規模な移行作業を強制するものではありません。しかし、日々の運用に直結する「削除」「復旧不可」「リリース時刻」「内容閲覧権限」が明確化されているため、手順書を放置すると問い合わせ対応やインシデント対応で混乱が起きます。
まずは、次の3つを優先してください。
1つ目は、削除権限を持つ担当者と承認フローの確認です。削除済み隔離アイテムは復旧前提で扱えないため、削除前の判断基準を明文化します。
2つ目は、リリース後のユーザー案内です。Outlook上では再配信時刻で表示される可能性があるため、ヘルプデスクの回答テンプレートに追記します。
3つ目は、権限とSafe Attachments設定の棚卸しです。メールだけでなくSharePoint、OneDrive、Teamsのファイル隔離まで含めて、Microsoft Defenderの隔離管理をひとつのセキュリティ運用として見直しましょう。
コメント