Microsoft Defender for Office 365でOutlookのフィッシング報告を管理している組織は、従来の「Report Message」「Report Phishing」アドイン前提の運用から、Outlook標準の組み込みReportボタンを中心にした運用へ移行する準備が必要です。特に重要なのは、対応Outlookバージョンの確認、User reported settingsの送信先設定、報告メールボックスの扱い、共有メールボックスや代理送信時の権限確認です。
Microsoft Learnの「Report phishing and suspicious emails in Outlook for admins」は、Exchange Onlineメールボックスを持つMicrosoft 365組織で、ユーザーがOutlookから迷惑メール、フィッシング、誤検知メールを報告する仕組みを管理者向けに整理した公式情報です。この記事では、2026年6月時点の公式情報をもとに、影響範囲、設定変更、移行期限、管理者が確認すべきポイントを実務目線で解説します。なお、Microsoft Learn上の当該ページは表示上「Last updated on 2026-06-15」となっています。(Microsoft Learn)
Microsoft DefenderのOutlook報告機能で何が変わるのか
今回のポイントは、Outlookで不審メールを報告する操作が、個別に追加するアドインではなく、Outlookに組み込まれたReportボタンへ寄っていくことです。
Microsoft Defender for Office 365では、ユーザーがOutlook上で「Report phishing」「Report junk」「Not junk」を選ぶことで、不審メールや誤検知メールを管理者、Microsoft、またはその両方へ送信できます。報告されたメッセージは、Microsoft DefenderポータルのSubmissionsページにある「User reported」タブで確認できます。(Microsoft Learn)
管理者にとっての実務上の意味は、単に「ボタンが変わる」ことではありません。報告先、通知文面、分析フロー、アドイン廃止への備え、ユーザー教育をまとめて見直すタイミングだと考えるべきです。
影響を受ける組織と対象サービス
この機能は、Exchange Onlineメールボックスを持つMicrosoft 365組織で利用されます。公式ドキュメント上の適用範囲は、クラウドメールボックスの組み込みセキュリティ機能、Microsoft Defender for Office 365 Plan 1 / Plan 2、Microsoft Defender XDRです。(Microsoft Learn)
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| 対象メール環境 | Exchange Onlineメールボックスを利用しているか |
| 対象ユーザー | Outlookから不審メールを報告する全ユーザー |
| 管理画面 | Microsoft DefenderポータルのUser reported settingsとSubmissions |
| 関連ライセンス | Defender for Office 365 Plan 1 / Plan 2、Microsoft Defender XDRなど |
| 主な影響 | 報告ボタン、報告先、アドイン運用、ユーザー教育、SOC運用 |
特にグローバル企業では、国や地域ごとにOutlookの更新チャネル、利用クライアント、SOCの運用体制が異なることがあります。そのため、全社一律で「ボタンが出るはず」と判断せず、地域別・部門別・端末別に確認することが重要です。
組み込みReportボタンの対応Outlookバージョン
Outlookの組み込みReportボタンは、多くのOutlookクライアントで利用できます。ただし、デスクトップ版Outlook for Microsoft 365では更新チャネルごとに必要バージョンが異なります。
| Outlookクライアント | 必要バージョン・条件 |
|---|---|
| Outlook for Microsoft 365 Current Channel | Version 16.0.17827.15010以降 |
| Outlook for Microsoft 365 Monthly Enterprise Channel | Version 16.0.18025.20000以降 |
| Semi-Annual Channel Preview | Release 2502、build 16.0.18526.20024以降 |
| Semi-Annual Channel | Release 2502、build 16.0.18526.20024以降 |
| Outlook for Mac | Version 16.89（24090815）以降 |
| Outlook for iOS | Version 4.2511以降 |
| Outlook for Android | Version 4.2446以降 |
| 新しいOutlook for Windows | 対応 |
| Outlook on the web | 対応 |
公式情報では、Monthly Enterprise Channelは「16.0.18025.20000以降」とされています。社内資料や展開計画で「16.0.18025.2」のように表記している場合は、桁落ちや転記ミスがないか確認してください。(Microsoft Learn)
Reportボタンが表示されないときの確認ポイント
Reportボタンは、対応バージョンのOutlookであれば常に表示されるわけではありません。公式情報では、次の2つの条件が必要です。
| 条件 | 確認場所 |
|---|---|
| User reportingが有効になっている | Microsoft Defenderポータル |
| 組み込みReportボタンを使う設定になっている | User reported settings |
User reportingが無効で、さらに非Microsoftアドインボタンを使う設定になっている場合、対応Outlookでも組み込みReportボタンは利用できません。(Microsoft Learn)
実務では、「Outlookのバージョンは満たしているのにボタンがない」という問い合わせが起きやすいです。この場合は、クライアントの更新状況だけでなく、Defenderポータル側のUser reported settingsを必ず確認してください。
ユーザー報告時の動作を整理する
ユーザーがReportボタンを使ったとき、報告種別によってメールボックス内での動作が異なります。
| ユーザーの操作 | 操作できる場所 | メールボックス内の動作 |
|---|---|---|
| Report junk | InboxまたはJunk Email以外のメールフォルダー | メッセージがJunk Emailへ移動し、送信者がブロック済み送信者に追加される |
| Report phishing | 任意のメールフォルダー | メッセージが削除される |
| Not junk | Junk Emailフォルダー | メッセージがInboxへ移動する |
報告されたメッセージは、組織のUser reported settingsに応じて、報告メールボックス、Microsoft、またはその両方へ送信されます。(Microsoft Learn)
ここで注意したいのは、ユーザーにとって「報告」は単なる通知ではなく、メールの移動や削除を伴う操作だという点です。特に「Report phishing」を押すとメッセージが削除されるため、調査証跡の取り扱いをユーザー教育に含める必要があります。
管理者が変更・確認すべきUser reported settings
管理者が最初に確認すべきなのは、Microsoft DefenderポータルのUser reported settingsです。ここで、Outlookの報告機能を有効化し、報告先をどこにするかを決めます。
主な選択肢は次の3つです。
| 送信先設定 | 向いている組織 | 注意点 |
|---|---|---|
| Microsoft only | Microsoftの分析を優先し、SOCで全件確認しない組織 | 社内の報告メールボックスには蓄積されない |
| My reporting mailbox only | SOCやメール管理者が先に確認したい組織 | Microsoftに自動送信されないため、必要に応じて手動送信が必要 |
| Microsoft and my reporting mailbox | Microsoftの分析と社内確認を両立したい組織 | 報告メールボックスの運用ルールが必要 |
Microsoftの公式情報では、Microsoft reporting toolsを使う場合、ユーザー報告メッセージを報告メールボックスのみ、Microsoftのみ、または両方へ送信するように構成できます。報告メールボックスに送る場合は、管理者がSubmissionsページのUser reportedタブから手動でMicrosoftへ提出する運用も可能です。(Microsoft Learn)
報告メールボックスはSecOpsメールボックスとして扱う
報告メールボックスを使う場合は、そのメールボックスをSecOps mailboxとして構成することが重要です。公式情報では、報告メールボックスがフィルター処理されずにユーザー報告メッセージを受け取れるようにするため、SecOps mailboxとして識別することや、DLPを利用している場合はDLPから除外することが案内されています。(Microsoft Learn)
これは実務上かなり重要です。報告メールボックス自体に保護機能やDLPが強く効きすぎると、ユーザーが報告した不審メールが正しく集約されず、SOCが見落とす原因になります。
共有メールボックス・代理操作での注意点
組み込みReportボタンは、対応している一部のOutlookクライアントで、共有メールボックスや代理アクセスしている他のメールボックスからの報告にも対応します。ただし、共有メールボックスから報告するには、代理ユーザーにSend As権限が必要です。
Send As権限がない場合、メッセージは報告メールボックスへ送信されず、フォルダーから削除されるだけになります。(Microsoft Learn)
この仕様は、現場でトラブルになりやすいポイントです。たとえば、カスタマーサポート部門や経理部門で共有メールボックスを使っている場合、担当者が「報告した」と思っていても、実際にはSOC側に届いていない可能性があります。
管理者は、共有メールボックスを使う部門について、次の3点を確認してください。
- 共有メールボックスで不審メール報告を行う運用があるか
- 報告する担当者にSend As権限があるか
- 報告テストを実施し、User reportedタブや報告メールボックスに届くか
Report Message / Report Phishingアドインからの移行方針
Microsoftは、Report MessageアドインとReport Phishingアドインをメンテナンスモードとしており、将来的に廃止される予定と説明しています。公式情報では、組み込みReportボタンへの移行が推奨されています。(Microsoft Learn)
重要なのは、現時点で「何年何月何日に完全廃止」といった明確な移行期限が公式ページ内で日付指定されているわけではない点です。Microsoftは、廃止に向けて追加の連絡を行うと説明しています。したがって、管理者は「まだ期限がないから後回し」ではなく、「廃止日が出てから慌てないために先に移行計画を作る」と考えるべきです。(Microsoft Learn)
アドイン移行で取るべき現実的な進め方
いきなり全社からアドインを削除すると、問い合わせが増える可能性があります。実務では、次の順序で進めると安全です。
| フェーズ | 作業内容 | 判断基準 |
|---|---|---|
| 現状把握 | Report Message / Report Phishingアドインの展開状況を確認 | どのユーザー・部門に配布されているか |
| クライアント確認 | Outlookの対応バージョンを確認 | 組み込みReportボタンが利用可能か |
| 設定確認 | User reported settingsで組み込みReportボタンを有効化 | 報告先が意図通りか |
| パイロット | 一部部門で報告テスト | User reportedタブ、報告メールボックス、通知が正しく動くか |
| 段階移行 | アドインの対象を縮小または削除 | 利用者からの問い合わせが許容範囲か |
| 教育更新 | 社内手順書・訓練資料を更新 | 旧アドイン名が残っていないか |
アドインを削除する場合、Microsoft 365管理センターのIntegrated appsから対象アドインを選び、Remove appを実行します。公式情報では、削除後にアドインが組織から消えるまで最大24時間かかる可能性があるとされています。(Microsoft Learn)
非Microsoftの報告アドインを使う場合の注意点
KnowBe4、Cofense、Hoxhuntなどの非Microsoft報告ツールを使っている組織では、組み込みReportボタンとの二重運用に注意が必要です。
Microsoftの公式情報では、非Microsoft報告ツールをDefender for Office 365の報告エクスペリエンスと統合すると、Defenderのインシデント管理、Microsoft分析、製品内のフィッシングトリアージ、自動応答機能を利用できると説明されています。(Microsoft Learn)
ただし、非Microsoftツールから報告メールボックスへ送るメッセージには形式要件があります。元メールを変更せず、非圧縮の.emlまたは.msg添付として含め、必要なヘッダーを保持する必要があります。複数の添付メッセージを含む場合は破棄される点にも注意が必要です。(Microsoft Learn)
さらに、Phishing Triage Agentを利用する場合、Microsoftは「Microsoftと非Microsoftの報告ボタンを同時に走らせない」ことを共通の設定ミスとして挙げています。重複送信はノイズを増やし、SOCのトリアージ効率を下げるためです。(Microsoft Learn)
Submissionsページで管理者が確認すべきこと
ユーザーが報告したメッセージは、Microsoft DefenderポータルのSubmissionsページで確認できます。管理者は、User reportedタブから報告内容を確認し、必要に応じてMicrosoftへ送信または再送信し、判定を付けてユーザーへ通知できます。(Microsoft Learn)
運用で確認すべき項目は次のとおりです。
| 確認項目 | 目的 |
|---|---|
| User reportedタブに報告が届くか | ボタン・送信先設定の確認 |
| Microsoftへ自動送信されているか | Microsoft only / Microsoft and my reporting mailbox設定の確認 |
| Not Submitted to Microsoftが残っていないか | 報告メールボックスのみ運用での提出漏れ確認 |
| 管理者がMark as and notifyを使えるか | ユーザーへのフィードバック運用確認 |
| 同一メールの重複報告が多すぎないか | アドイン二重運用や訓練設計の見直し |
Microsoftは、ユーザー報告メッセージをMicrosoftへ送る設定の場合、管理者がSubmissionsページからMicrosoftへ提出する場合と同様のチェックを行うと説明しています。そのため、再送信が有用なのは、まだMicrosoftへ送られていないメッセージや、元の判定に同意できない場合です。(Microsoft Learn)
ユーザー通知と教育で失敗しないためのポイント
Reportボタン移行で見落とされやすいのが、ユーザー向けの案内です。ボタン名や場所が変わると、ユーザーは「どれを押せばよいのか」と迷います。特に旧アドインの「Report Phishing」だけに慣れている場合、組み込みReportボタンのドロップダウンに「Report phishing」「Report junk」「Not junk」があることを説明する必要があります。
Microsoftの移行FAQでは、組み込みReportボタンは分割ボタンであり、ドロップダウンを使ってjunkやnot junkを報告できると説明されています。(Microsoft Learn)
社内教育では、次のように簡潔に案内すると効果的です。
| ユーザーに伝える内容 | 例 |
|---|---|
| 不審なメール | Report → Report phishing |
| 迷惑メール | Report → Report junk |
| 迷惑メールフォルダーに入った正常メール | Report → Not junk |
| 迷った場合 | メール内のリンクや添付を開かず、Report phishingを選ぶ |
| 共有メールボックス | 担当者によっては報告できない場合があるためIT部門へ連絡 |
Defender for Office 365 Plan 2では、AIRの結果に基づく自動通知も利用できます。フィッシング、マルウェア、スパム、脅威なしといった調査結果に応じて、報告ユーザーへ通知する運用を組めます。(Microsoft Learn)
管理者向けチェックリスト
移行計画を作る際は、次のチェックリストを使うと抜け漏れを減らせます。
| 項目 | 確認内容 |
|---|---|
| Outlookバージョン | Current Channel、Monthly Enterprise Channel、Mac、iOS、Androidの対応バージョンを満たしているか |
| User reporting | Microsoft Defenderポータルで有効になっているか |
| Reportボタン設定 | 組み込みReportボタンを使う設定か、非Microsoftアドインを使う設定か |
| 報告先 | Microsoftのみ、報告メールボックスのみ、両方のどれか |
| 報告メールボックス | SecOps mailbox設定、DLP除外、受信確認が済んでいるか |
| 共有メールボックス | Send As権限と報告テストを確認したか |
| アドイン | Report Message / Report Phishingアドインの展開範囲を把握したか |
| 移行期限 | 明確な廃止日は未指定だが、メンテナンスモードを前提に移行計画を作ったか |
| ユーザー教育 | 旧手順書、訓練資料、社内FAQを更新したか |
| SOC運用 | User reportedタブの確認担当、対応SLA、通知テンプレートを決めたか |
まとめ：今すぐやるべきこと
Microsoft Defender for Office 365のOutlook報告機能は、組み込みReportボタンを中心にした運用へ移りつつあります。管理者が最初にやるべきことは、Outlookの対応バージョン確認、User reported settingsの確認、報告先の整理、旧アドインの展開状況確認です。
特に、Report Message / Report Phishingアドインはメンテナンスモードで、将来的に廃止予定とされています。明確な廃止日が出てから対応するのではなく、パイロット部門で組み込みReportボタンを検証し、報告メールボックス、Submissionsページ、ユーザー通知まで一連の流れを確認しておくべきです。
不審メール報告は、セキュリティ製品の設定だけで完結しません。ユーザーが迷わず報告でき、管理者が正しく確認し、必要に応じてMicrosoftの分析へつなげられる状態を作ることが、今回の更新ポイントで最も重要です。
コメント