Microsoft Teams管理センターでユーザー報告のセキュリティシグナルを確認する方法と対応ポイント

Microsoft Teamsで不審なチャットや誤検知されたメッセージをユーザーが報告しても、管理者がその傾向をつかめなければ、ポリシー改善やインシデント対応にはつながりません。

「Microsoft Teams admin center surfaces user-reported security signals」は、ユーザーが「セキュリティ上の懸念」または「セキュリティ上の懸念ではない」と報告したTeamsメッセージのシグナルを、Teams管理センターのProtection reportsで確認・ダウンロードできるようにする更新です。

これは新しい自動防御機能ではなく、ユーザー報告をTeams管理者が分析しやすくする可視化機能と捉えるのが適切です。まずはTeams管理センターとMicrosoft Defenderの両方でユーザー報告設定を確認し、報告後の調査担当者と対応手順を決める必要があります。

Microsoft 365 Roadmap ID 536571では、一般提供時期が2026年4月、状態が「Launched」、対象がWorldwideの標準マルチテナント環境とされています。ロードマップの更新日時はUTCで2026年7月6日23時、日本時間では2026年7月7日に当たります。(Microsoft)

Microsoft Teams admin center surfaces user-reported security signalsとは

今回の更新では、Teams利用者がメッセージについて報告した次の2種類のシグナルを、Teams管理センター側から確認できるようになります。

• セキュリティ上の懸念がある
• セキュリティ上の懸念ではない

前者は、フィッシング、スパム、悪意のあるコンテンツなどが疑われるメッセージの報告です。後者は、Link Protectionなどによって危険と判定されたものの、利用者が正当なメッセージだと考えた場合の誤検知報告に相当します。(Microsoft Learn)

Teams管理センターでは、これらの報告シグナルをProtection reports内で閲覧し、データとしてダウンロードできます。Microsoftは、報告傾向の把握やポリシー、対応方法の調整に利用できる機能と説明しています。(Microsoft)

項目	今回の変更	変わらない点
管理者の可視性	ユーザー報告のシグナルをTeams管理センターで確認できる	報告内容が自動的に真の脅威と確定するわけではない
レポート	Protection reportsで閲覧・ダウンロードできる	Defenderのインシデント調査やSubmissionsは引き続き必要
ポリシー改善	報告件数や傾向をもとに設定を見直しやすくなる	レポート自体がメッセージをブロックするわけではない
運用分担	Teams管理者もセキュリティ傾向を把握しやすくなる	SecOpsによる判定、封じ込め、再発防止は別工程

保護対象と影響範囲

対象は「ユーザーが報告したTeamsメッセージ」

今回のロードマップ項目が対象としているのは、Teamsの全メッセージではありません。ユーザーが明示的に報告したメッセージから得られるシグナルです。

現在のMicrosoft Defenderの公式情報では、次の場所にあるTeamsメッセージを報告対象にできます。

• 1対1またはグループチャット
• 標準チャネル
• 共有チャネル
• プライベートチャネル
• 会議チャット

報告は、組織内ユーザーからのメッセージと外部ユーザーからのメッセージの両方を対象にできます。対応クライアントにはTeamsデスクトップ、Web、対応バージョンのiOSおよびAndroidアプリが含まれます。(Microsoft Learn)

通話報告は別機能として考える

2026年には、完了済みまたは不在着信となった1対1のTeams通話を、悪意のある通話または誤検知として報告する機能も追加されています。(Microsoft Learn)

ただし、Roadmap ID 536571の説明は「messages users report」としており、今回のTeams管理センターのレポート更新が通話シグナルまで含むとは明記されていません。

そのため、次のように切り分けるのが安全です。

• メッセージ報告は今回のロードマップ項目の対象
• 通話報告は別途設定できる
• 通話データが同じProtection reportに表示されるかは、実際のテナント画面で確認する

共有チャネルでは報告先の組織に注意する

共有チャネルからユーザー報告が行われた場合、報告はその共有チャネルを所有・作成した組織に送られます。自社ユーザーが参加している共有チャネルであっても、自社側だけで報告内容を確認できるとは限りません。(Microsoft Learn)

外部組織との共有チャネルを多用している場合は、インシデント連絡先や相互連絡の手順も決めておく必要があります。

Teams管理センターとMicrosoft Defenderの役割分担

今回の更新によって、Teams管理センターだけでセキュリティ対応が完結するわけではありません。

管理画面	主な役割	実務で行うこと
Teams管理センター	報告シグナルの傾向把握	Protection reportsの確認、データのダウンロード、ポリシー見直し
Microsoft Defenderポータル	個別メッセージの調査と対応	User reported一覧、アラート、インシデント、判定、Microsoftへの再送信
Microsoft Purview	監査・コンプライアンス	監査ログ、保持、eDiscovery、Communication Compliance
SIEM・SOAR	複数サービスの相関分析	ID、端末、メール、Teamsのシグナルを統合して検知・自動化

Teams管理センターは、Teams運用担当者が全体傾向を確認するための入口として有効です。一方、個別の脅威判定やインシデント対応は、引き続きMicrosoft Defenderを中心に行います。

Microsoftは、Teams関連のセキュリティ運用について、DefenderのインシデントキューまたはSIEM・SOAR連携からトリアージを開始することを推奨しています。(Microsoft Learn)

管理者が確認すべき設定

ユーザー報告機能には、Teams管理センター側とMicrosoft Defender側の2段階の設定があります。どちらか一方だけを有効にしても、期待した動作にならない可能性があります。

「セキュリティ上の懸念を報告」を確認する

Teams管理センターでは、ユーザーがメッセージを不審なものとして報告できるかを制御します。

1. Teams管理センターを開く
2. 「Settings & policies」を開く
3. 全体設定またはカスタムポリシーを選択する
4. 「Messaging」を開く
5. 「Report a security concern」をオンにする
6. 設定を保存する

この設定はTeams側の報告ボタンを制御します。オフの場合、Microsoft Defender側の監視設定が有効でも、ユーザーはTeamsからメッセージを報告できません。(Microsoft Learn)

組織全体で一括有効化する前に、情報システム部門やセキュリティ部門を対象にしたカスタムポリシーで試行する方法もあります。

「誤ったセキュリティ検出を報告」を確認する

正当なメッセージが危険と判定された場合に、ユーザーが誤検知を報告できるようにします。

1. Teams管理センターで「Messaging settings」を開く
2. 「Messaging safety」を確認する
3. 「Report incorrect security detections」をオンにする
4. 設定を保存する

この設定を有効にすると、Link Protectionなどで警告されたメッセージに対し、ユーザーが「セキュリティ上の懸念ではない」と報告できます。(Microsoft Learn)

誤検知報告は、安全性を下げるための機能ではありません。業務で利用している正当なURLやサービスが繰り返し警告される場合に、検知精度やポリシーを改善するための材料です。

Microsoft Defender側の監視設定を確認する

Microsoft Defenderポータルでは、次の場所を確認します。

1. 「Settings」を開く
2. 「Email & collaboration」を選択する
3. 「User reported settings」を開く
4. Microsoft Teamsセクションを確認する
5. 「Monitor reported items in Microsoft Teams」をオンにする

この設定は新しいテナントでは既定でオンですが、既存テナントでは管理者による有効化が必要な場合があります。Teams管理センターで報告を許可していても、この設定が無効だと、DefenderのSubmissionsに正しく表示されない可能性があります。(Microsoft Learn)

報告データの送信先を決める

Microsoft Defenderでは、ユーザー報告の送信先を次のいずれかから選択できます。

設定	動作	向いている組織
Microsoftと報告用メールボックス	Microsoftの分析と社内確認の両方を行う	標準的な構成
Microsoftのみ	Microsoftの分析を優先する	専用メールボックスを運用しない組織
報告用メールボックスのみ	社内だけで一次確認する	データ送信方針に制約がある組織

「報告用メールボックスのみ」を選択した場合、管理者がDefenderのUser reported画面から手動送信しない限り、Microsoftによる分析は行われません。Microsoftは、Microsoftと報告用メールボックスの両方に送る設定を既定として推奨しています。(Microsoft Learn)

権限は最小限にする

Teams管理センターのユーザー報告設定を変更するには、Global AdministratorまたはTeams Administratorなどの権限が必要です。Microsoft Defender側の設定には、Security AdministratorやOrganization Managementなどの権限が必要になります。(Microsoft Learn)

通常運用でGlobal Administratorを常用する必要はありません。Teams側はTeams Administrator、Defender側はSecurity Administratorなど、担当業務に必要な権限だけを付与します。

ライセンス要件はテナントで確認する

2026年7月時点では、Microsoftの公式文書間でライセンスに関する記載が完全には一致していません。

Microsoft Defender側の新しい文書では、Microsoft Defender for Office 365 Plan 1、Plan 2、またはMicrosoft Defender XDRを対象として説明しています。一方、Teams側の一部文書では、Plan 2またはMicrosoft Defender XDRと記載されています。(Microsoft Learn)

また、Roadmap ID 536571自体には具体的なライセンス名が記載されていません。(Microsoft)

そのため、ライセンスの判断は次の順で行うのが確実です。

1. Teams管理センターにProtection reportsが表示されるか確認する
2. 対象のユーザー報告レポートを実行できるか確認する
3. Microsoft DefenderのUser reported画面にTeams報告が表示されるか確認する
4. Microsoft 365管理センターのメッセージセンターを確認する
5. 契約しているライセンス条件を販売元またはMicrosoftに確認する

政府機関向けクラウドについても、Roadmap ID 536571ではWorldwideの標準マルチテナント環境のみが記載されています。GCC、GCC High、DoDなどで同時に利用できるとは限りません。(Microsoft)

監査・検知・インシデント対応への影響

ユーザー報告は「判定」ではなく「シグナル」

ユーザーが「セキュリティ上の懸念」として報告したからといって、そのメッセージがフィッシングと確定したわけではありません。

反対に、「セキュリティ上の懸念ではない」と報告されたメッセージが必ず安全であるとも限りません。ユーザーが攻撃を正当な連絡と誤認している可能性もあります。

実務では、次の情報と突き合わせて判定します。

• 送信元のユーザーまたは外部ドメイン
• メッセージに含まれるURL
• 添付ファイルのハッシュ値
• 同じメッセージを受信したユーザー数
• URLのクリック履歴
• Microsoft Entra IDのサインイン履歴
• 端末側のアラート
• 同じ送信者からのメールやTeams招待

Defenderでアラートとインシデントが生成される

Teamsメッセージがユーザーから報告されると、既定のアラートポリシーによって次のようなアラートが生成されます。

• Teams message reported by user as a security risk
• Teams message reported by user as a not security risk

これらのアラートはMicrosoft Defenderのインシデントに関連付けられます。報告内容の詳細画面から、対応するアラートを開くこともできます。(Microsoft Learn)

ただし、ユーザー報告から生成されたTeamsアラートは、現時点では自動調査と対応であるAIRを自動的には開始しません。SecOps担当者によるトリアージや、SIEM・SOAR側での処理が必要です。(Microsoft Learn)

DefenderのUser reported画面で行えること

Microsoft Defenderポータルの「Actions & submissions」から「Submissions」を開き、「User reported」タブを確認すると、管理者は次の操作を行えます。

• 報告内容の確認
• Microsoftへの送信または再送信
• 管理者判定の付与
• 報告者への結果通知
• 関連アラートの確認
• 管理者送信への変換

Teamsメッセージは、管理者が任意のメッセージを直接選んでMicrosoftへ送信する方式ではありません。原則として、ユーザーから報告されたTeamsメッセージをUser reported画面から管理者送信に変換します。(Microsoft Learn)

今回の更新は監査ログの代替ではない

Protection reportsからデータを確認・ダウンロードできるようになっても、Microsoft Purview Audit、eDiscovery、保持ポリシーの代替にはなりません。

役割を次のように分けます。

• Protection reports：ユーザー報告の傾向分析
• Defender：脅威の調査、判定、対応
• Purview Audit：操作や変更の証跡確認
• eDiscovery：法務・調査目的の検索、保全、エクスポート

インシデント調査で証跡を残す場合は、Teams管理センターからダウンロードしたレポートだけでなく、Defenderのインシデント番号、調査結果、実施したブロックやポリシー変更も記録します。

レポートを読む際の注意点

報告件数とインシデント件数は一致しない

Teamsでは、報告後も対象メッセージがユーザーに表示され続けます。同じメッセージを複数回報告することもでき、送信者には報告されたことが通知されません。(Microsoft Learn)

そのため、単純な報告件数だけで攻撃規模を判断すると誤ります。

例えば、同じフィッシングメッセージを50人が報告した場合は、次のいずれにも解釈できます。

• 50件の別々の攻撃
• 1件の攻撃が50人に拡散
• 1件のメッセージが重複報告された
• セキュリティ訓練メールが一斉に報告された

可能であれば、送信者、URL、メッセージID、報告時刻などで重複を整理してから傾向を分析します。

誤検知報告が多くても即座に許可しない

同じ業務サービスのURLについて「セキュリティ上の懸念ではない」という報告が増えても、すぐにドメイン全体を許可するのは危険です。

正規のクラウドサービスでは、同じドメイン配下にユーザー投稿コンテンツやリダイレクトURLが置かれる場合があります。ドメイン全体を許可すると、そのサービスを悪用した攻撃まで通過させる可能性があります。

許可を検討するときは、次の順で確認します。

1. 対象URLの完全なパスを確認する
2. リダイレクト先を確認する
3. Microsoft Defenderの判定理由を確認する
4. 同じURLに関する他の報告を確認する
5. 期限付きの例外で検証する
6. 恒久的な許可が必要か再評価する

Microsoftへの送信内容を理解しておく

ユーザーがTeamsアイテムをMicrosoftへ報告する設定の場合、メッセージ本文、ヘッダー、添付ファイル、ルーティング情報などが分析対象になります。報告したメッセージの前後最大15件の文脈メッセージが共有される場合もあります。(Microsoft Learn)

Microsoftは、送信された情報をセキュリティアルゴリズムの改善や判定に利用し、必要に応じて担当者が内容を確認する可能性があると説明しています。(Microsoft Learn)

個人情報、機密情報、要配慮情報を扱う組織では、次の対応が必要です。

• ユーザー報告機能の動作を社内規程に反映する
• 報告時に前後の文脈が含まれる可能性を説明する
• 報告データの送信先を法務・情報セキュリティ部門と確認する
• 報告用メールボックスのアクセス権と保存期間を決める

優先して行うべき対応

優先度	対応	確認内容
高	Teams側の報告設定を確認	Report a security concernが有効か
高	Defender側の監視設定を確認	Monitor reported items in Microsoft Teamsが有効か
高	調査担当を決める	Teams管理者、SecOps、ヘルプデスクの役割分担
高	報告後のSLAを決める	高リスク報告を何分・何時間以内に確認するか
中	Protection reportsを定期確認	件数、送信者、外部ドメイン、誤検知傾向
中	報告データを基準化	通常時の報告件数を把握し、急増を検知
中	ユーザー教育を行う	何を報告し、何を報告しないか
中	プライバシー確認	Microsoftへの送信範囲と社内規程

最初の1か月は、週単位でレポートをダウンロードし、通常時の報告量を把握するのが現実的です。

具体的には、次の指標を記録します。

• セキュリティ上の懸念として報告された件数
• 誤検知として報告された件数
• 同じ外部ドメインに関する報告数
• 同じURLに関する報告数
• Microsoftの判定とユーザー報告が一致した割合
• 調査開始までの時間
• 調査完了までの時間

実務で役立つ活用例

特定の外部ドメインからの報告が急増した場合

普段は報告がない外部ドメインから、短期間に複数の「セキュリティ上の懸念」が報告された場合は、標的型攻撃や外部アカウント侵害の可能性があります。

次の順で対応します。

1. Defenderで対象メッセージとURLを確認する
2. 同じ送信者と通信したユーザーを特定する
3. URLクリックの有無を調査する
4. 必要に応じて外部ドメインまたは送信者をブロックする
5. 既存メッセージの削除や隔離を検討する
6. 影響を受けたユーザーの認証情報を確認する

正規サービスの誤検知報告が増えた場合

勤怠管理、経費精算、ファイル共有など、業務上必要なサービスのURLに誤検知報告が集中する場合は、ポリシーやMicrosoftの判定を確認します。

ただし、報告数だけで許可設定を追加せず、正規の送信元、URL構造、リダイレクト先まで確認します。

特定部署からの報告だけが多い場合

一つの部署だけ報告数が多い場合、攻撃を受けているとは限りません。

次の可能性があります。

• 外部取引先とのやり取りが多い
• セキュリティ教育直後で報告意識が高い
• 業務システムが誤検知されている
• 特定担当者が同じメッセージを繰り返し報告している

報告数を部署の利用者数や外部通信量で補正すると、より正確に比較できます。

対応要否を判断する基準

現在の状態	対応要否	推奨対応
ユーザー報告とDefender監視が有効	対応あり	Protection reportsの確認手順を追加する
Teams側だけ有効	優先対応	Defenderの監視設定と送信先を確認する
Defender側だけ有効	優先対応	Teams側の報告ポリシーを有効にする
報告後の担当者が不明	最優先	調査担当、連絡経路、SLAを決める
独自の報告窓口がある	要検討	Teams標準報告との統合または使い分けを決める
政府機関向けクラウド	個別確認	テナント展開状況とメッセージセンターを確認する
Protection reportsが表示されない	個別確認	ライセンス、権限、ロールアウト状況を確認する

今回の更新だけを理由に、緊急でTeamsポリシーを全面変更する必要はありません。ただし、ユーザー報告をすでに許可しているにもかかわらず、誰も報告内容を確認していない組織は早急な見直しが必要です。

まとめ

Microsoft Teams admin center surfaces user-reported security signalsは、ユーザーが報告したTeamsメッセージのセキュリティシグナルを、Teams管理センターのProtection reportsで確認・ダウンロードできるようにする更新です。

重要なのは、レポートを表示できることではなく、ユーザー報告を実際の対応につなげることです。

まず、Teams管理センターの「Report a security concern」と「Report incorrect security detections」を確認します。続いて、Microsoft Defenderの「Monitor reported items in Microsoft Teams」と報告データの送信先を確認してください。

そのうえで、Teams管理者とSecOpsの役割分担、確認頻度、調査期限、ユーザーへの結果通知方法を決めます。Teams管理センターは傾向把握、Microsoft Defenderは個別調査と対応という役割を明確にすると、ユーザー報告を放置せず、ポリシー改善と早期検知の両方に活用できます。