Microsoft Teamsの「Report a Suspicious Call in Microsoft Teams」は、ユーザーが不審・迷惑だと感じたTeams通話を、通話履歴から報告できる機能です。結論から言うと、管理者は Teams管理センターの通話報告設定 と Microsoft Defenderポータルのユーザー報告設定 をセットで確認する必要があります。片方だけ有効でも、報告の可視化やセキュリティ運用に抜けが出る可能性があります。
特に注意したいのは、この機能が単なる「ユーザー向けボタンの追加」ではない点です。報告された通話は、Microsoft Defender for Office 365やDefender XDRでの調査、アラート、SOC運用に関わります。ユーザー周知、報告先メールボックス、プライバシー確認、SIEM/SOAR連携まで含めて展開計画を作るべき更新です。
Microsoft TeamsのReport a Suspicious Call in Microsoft Teamsで何が変わるのか
「Report a Suspicious Call in Microsoft Teams」は、Teams上の不審な通話をユーザー自身が報告できるようにする機能です。公式ロードマップIDは 536573 で、対象製品はMicrosoft TeamsとMicrosoft Defender for Office 365、状態はLaunched、一般提供は2026年3月とされています。公式API上の更新時刻は2026-05-05T23:00:02Zで、日本時間では2026年5月6日の更新に相当します。(Microsoft)
従来、Teamsのセキュリティ報告はメッセージやチャットを中心に考えられがちでした。しかし攻撃者は、外部チャット、なりすまし、偽サポート、採用詐欺、緊急対応を装った通話など、メール以外の経路も悪用します。この更新により、ユーザーは怪しい1対1通話をTeams内から報告し、組織のセキュリティチームが通話ベースのシグナルを把握しやすくなります。
| 確認項目 | 内容 | 管理者が見るべきポイント |
|---|---|---|
| 機能の目的 | Teams通話を不審・迷惑な通話として報告できる | 通話をセキュリティインシデントの入口として扱う |
| 対象サービス | Microsoft Teams、Microsoft Defender for Office 365 | Teams管理者だけでなく、セキュリティ管理者も関与する |
| 状態 | Launched、一般提供は2026年3月 | 既に展開済みの前提でテナント確認を行う |
| 対象クラウド | Worldwide Standard Multi-Tenant | GCCなど特殊クラウドは同じ前提で判断しない |
| 対象プラットフォーム | Desktop、Mac、Web | モバイルや特殊環境は実機確認が必要 |
Microsoft 365ロードマップのリリース日や説明は変更される可能性があるため、展開判断ではロードマップだけでなく、Microsoft Learnの設定手順と自社テナントの実際の表示を確認することが重要です。(Microsoft)
対象になる通話と、対象外として考えるべき範囲
Microsoft Learnでは、Teams通話のユーザー報告について、現時点で「完了した1対1通話」または「不在着信の1対1通話」が対象と説明されています。会議、グループ通話、すべてのPSTN通話、すべてのモバイル環境まで同じように報告できると決めつけない方が安全です。(Microsoft Learn)
| 通話の種類 | 対応の考え方 |
|---|---|
| 完了した1対1のTeams通話 | 報告対象として確認する |
| 不在着信の1対1通話 | 報告対象として確認する |
| 会議通話 | 対象範囲に含まれる前提で運用設計しない |
| グループ通話 | 事前にテストして判断する |
| モバイルクライアント | ロードマップ上の対象プラットフォームに含まれていないため、実機確認する |
| VDI・古いクライアント | 表示差異が起きやすいため、パイロット対象に含める |
実務では、「通話履歴にある怪しい1対1通話を報告できる機能」と説明すると、ユーザーにも管理者にも伝わりやすくなります。
ユーザー側の使い方
ユーザーはTeamsの通話履歴、または通話後の画面から、対象の通話にある「…」メニューを開き、「Report call」を選択します。報告理由ではセキュリティ上の懸念が選ばれ、必要に応じて説明を入力し、内容を確認して送信します。(Microsoft Learn)
| 手順 | ユーザー操作 | 補足 |
|---|---|---|
| 1 | Teamsの通話履歴を開く | 完了した通話・不在着信を確認する |
| 2 | 対象通話の「…」を選ぶ | 誤って折り返し電話しないよう注意 |
| 3 | 「Report call」を選択 | 表示名は環境や言語設定で変わる可能性がある |
| 4 | Security concernを確認 | 迷惑、フィッシング、悪意ある通話として報告する |
| 5 | 必要に応じて説明を入力 | 「Microsoftを名乗った」「認証コードを求められた」など具体的に書く |
| 6 | Reportを押す | 報告後、確認画面を閉じる |
誤って「Scam Suspected」と判定された通話については、ユーザーが「Report as not a security concern」として報告できる操作も用意されています。セキュリティチームは、悪意ある通話の報告だけでなく、誤検知の報告も運用フローに含めるべきです。(Microsoft Learn)
管理者が最初に確認すべき設定
この機能の設定は、大きく分けてTeams管理センター側とMicrosoft Defenderポータル側の2か所があります。Microsoft Learnでは、Teams側の設定は既定でオン、Defenderポータル側は新規テナントでは既定でオン、既存テナントでは有効化が必要と説明されています。Teams側がオフの場合、ユーザーはTeams内で報告できないため、Defender側の設定だけを確認しても不十分です。(Microsoft Learn)
Teams管理センターでReport callを確認する
Teams管理センターでは、通話ポリシーまたはCalling settings内の「Report call」「Report a call」に相当する設定を確認します。Microsoft Learnでは、Teams admin centerにサインインし、Voice > Calling policiesからポリシーを選び、Report callをオンにする手順が示されています。(Microsoft Learn)
別のMicrosoft Learnページでは、Settings & policiesのCalling settingsにある「Report a call」トグルを確認する手順も示されています。管理センターのUIは更新されることがあるため、実際のテナントでは「Report」「call」「security concern」などの表記で検索し、対象ポリシーが全社既定なのか、特定ユーザー向けカスタムポリシーなのかを確認してください。(Microsoft Learn)
Microsoft DefenderポータルでUser reported settingsを確認する
Microsoft Defenderポータルでは、Settings > Email & collaboration > User reported settingsに進み、Microsoft Teamsセクションの「Monitor reported items in Microsoft Teams」を確認します。ここがオフのままだと、Teams側で報告できても、Defender側のユーザー報告として正しく表示・運用できない可能性があります。(Microsoft Learn)
報告先も重要です。ユーザー報告アイテムの送信先は、Microsoftのみ、報告用メールボックスのみ、またはMicrosoftと報告用メールボックスの両方から選べます。古い環境では既定の報告用メールボックスがグローバル管理者のExchange Onlineメールボックスになっている場合があるため、SOCやCSIRTが監視する共有メールボックスに見直す価値があります。(Microsoft Learn)
権限とプライバシーで見落としやすい点
Teams管理センターで設定を確認するには、グローバル管理者またはTeams管理者のロールが必要です。Defenderポータル側の設定変更には、Organization ManagementまたはSecurity Administratorロールグループが必要とされています。日常運用では、グローバル管理者を常用せず、最小権限の原則に沿って担当者へ必要なロールだけを割り当てるべきです。(Microsoft Learn)
また、Microsoftに報告を送信する設定では、提出情報が分析に使われます。Microsoft Learnでは、送信内容がセキュリティ監査済みの米国データセンターに保存され、必要がなくなれば削除されること、Microsoft担当者が提出されたメッセージ、通話、ファイルを読む可能性があることも説明されています。機密性の高い業界では、法務、個人情報保護、監査部門に事前共有しておくと展開後の混乱を避けられます。(Microsoft Learn)
報告後に管理者とSOCが見るべき場所
ユーザーがTeams通話を報告すると、設定に応じてMicrosoft、報告用メールボックス、またはその両方に送信されます。DefenderポータルのSubmissionsページにあるUser reportedタブでは、報告されたTeamsアイテムの情報を確認できます。通話報告では、報告者、発信者、受信者、アイテム詳細などのメタデータが確認対象になります。(Microsoft Learn)
Microsoft Learnでは、ユーザー報告されたTeamsアイテムに対して、次のようなアラートポリシーが既定でアラートを生成すると説明されています。(Microsoft Learn)
| アラート名 | 意味 |
|---|---|
| Teams call reported by user as a security risk | ユーザーがTeams通話をセキュリティリスクとして報告 |
| Teams call reported by user as a not security risk | ユーザーがTeams通話をセキュリティリスクではないと報告 |
| Teams message reported by user as a security risk | Teamsメッセージをセキュリティリスクとして報告 |
| Teams message reported by user as a not security risk | Teamsメッセージをセキュリティリスクではないと報告 |
Defender for Office 365のセキュリティ運用ガイドでは、ユーザーが報告したTeamsメッセージや通話はMicrosoftまたは報告用メールボックスに送信され、関連するアラートがDefender XDRのインシデントに相関されると説明されています。一方で、これらのアラートは現時点で自動調査と対応、いわゆるAIR調査を生成しないため、SOC側でトリアージ手順を用意する必要があります。(Microsoft Learn)
展開時に失敗しやすいポイント
Report a Suspicious Call in Microsoft Teamsは、ボタンを有効にするだけなら難しくありません。しかし、実務で価値を出すには「誰が見て、どこに通知され、どう対応するか」まで決める必要があります。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| Teams側だけ有効にする | 報告はできてもDefender側の可視化が不十分になる | Teams管理センターとDefenderポータルを両方確認する |
| 既存テナントのDefender設定を見落とす | User reportedタブに期待どおり出ない | Monitor reported items in Microsoft Teamsを確認する |
| 報告先メールボックスが管理者個人のまま | SOCが報告に気づかない | 共有メールボックスや監視対象アドレスに変更する |
| ユーザー教育をしない | 怪しい通話に折り返す、認証コードを伝える | 通話履歴から報告する手順を短く周知する |
| プライバシー確認を後回しにする | 法務・監査部門から差し戻される | Microsoftへの送信内容と保存先を事前説明する |
| SIEM/SOARルールを更新しない | Teams通話アラートが埋もれる | アラート名、重要度、担当キューを見直す |
| 会議やグループ通話も対象と誤解する | ユーザー問い合わせが増える | まずは1対1通話の報告として案内する |
特に重要なのは、報告された通話がユーザーの画面から自動的に削除されるわけではない点です。Microsoft Learnでは、報告済みアイテムはユーザーに表示され続け、同じアイテムを複数回報告でき、通話の相手には報告されたことが通知されないと説明されています。(Microsoft Learn)
開発者・連携担当者が確認すべきポイント
Teamsアプリ開発者やセキュリティ連携担当者は、この更新を「新しいユーザー操作」ではなく「新しいセキュリティシグナル」として扱うべきです。既存のSIEM、SOAR、チケット起票、通知フローがTeamsメッセージの報告だけを前提にしている場合、Teams通話の報告が正しく分類されない可能性があります。
確認すべき観点は次の通りです。
| 観点 | 確認内容 |
|---|---|
| アラート分類 | Teams call reported by user as a security riskを専用カテゴリに分類できるか |
| チケット起票 | メッセージ報告と通話報告で同じテンプレートを使ってよいか |
| 重要度 | 役員、経理、情シスを装う通話を高優先度にするか |
| 通知先 | Teams管理者、SOC、ヘルプデスクのどこに流すか |
| 自動化 | AIR調査が自動生成されない前提で、初動確認を手順化する |
| 証跡 | 通話日時、発信者、受信者、報告者、説明文を残せるか |
| 誤検知 | not security riskの報告を改善サイクルに入れるか |
たとえば、既存のチケットシステムで「User reported Teams item」という大分類だけを使っている場合、メッセージと通話が混在します。通話詐欺はユーザーが即座に折り返したり、認証コードを伝えたりするリスクがあるため、メッセージ報告より初動を急ぐべきケースがあります。ワークフロー上は「通話報告」「外部ユーザー」「同一発信者から複数報告」「金銭・認証情報・リモート操作の要求」といった条件で優先度を上げる設計が現実的です。
SOCでの初動対応フロー
報告されたTeams通話は、メールのフィッシング報告と同じ感覚で処理すると遅れが出る場合があります。通話はリアルタイム性が高く、ユーザーが会話中または直後に操作してしまう可能性があるためです。
| 順序 | 対応 | 判断基準 |
|---|---|---|
| 1 | User reportedタブまたはDefender XDRインシデントを確認 | 通話報告アラートの有無を見る |
| 2 | 報告者に状況を確認 | 認証コード、URL、送金、リモート操作の要求があったか |
| 3 | 発信者・外部ドメインを確認 | 同一相手から複数ユーザーへ接触していないか |
| 4 | 影響範囲を確認 | チャット、会議招待、ファイル共有、サインイン異常を確認 |
| 5 | 必要に応じてブロック | ドメイン、URL、ファイル、外部送信者を制御する |
| 6 | ユーザーへ返信 | 報告を受け付けたこと、追加対応の有無を伝える |
| 7 | 再発防止 | 周知文、条件付きアクセス、外部アクセス設定を見直す |
Defender for Office 365のTeams保護では、ユーザー報告だけでなく、Teamsメッセージの検疫、Teamsメッセージエンティティパネル、テナント許可/ブロックリスト、ZAP for Teams、Safe Linksなどの機能と組み合わせて運用できます。通話報告を単独で見るのではなく、Teams全体の攻撃経路を塞ぐ運用に組み込むことが重要です。(Microsoft Learn)
また、SecOpsガイドでは、Teams内の未検出URLをTenant Allow/Block Listでブロックしたり、ドメインをブロックしたりする対応例が示されています。通話でURLや外部チャットへ誘導された場合は、通話報告だけで完了せず、関連するURL、ドメイン、ファイル、アカウント操作まで確認してください。(Microsoft Learn)
ユーザーに周知するときの文面例
展開時は、長い説明よりも「何を見たら、どこから、どう報告するか」を短く伝える方が効果的です。以下は社内ポータルやTeams投稿に使える例です。
Teamsで不審な1対1通話や不在着信を受けた場合は、折り返し電話をせず、通話履歴から対象の通話を選び、「…」メニューの「Report call」から報告してください。
Microsoft、社内IT部門、取引先などを名乗って、認証コード、パスワード、送金、リモート操作、アプリのインストールを求められた場合は、特に注意してください。
報告後も、必要に応じてヘルプデスクまたはセキュリティ窓口へ連絡してください。
この周知では、「怪しいと思ったら報告してよい」と明確に伝えることが大切です。ユーザーが判断に迷って報告を控えるより、SOCが誤報を含めて確認できる状態の方が、攻撃の早期検知につながります。
管理者が展開前に行うチェックリスト
本番展開前に、次の項目を確認してください。
| チェック項目 | 完了の目安 |
|---|---|
| Microsoft 365ロードマップID 536573の内容を確認した | 対象サービス、状態、プラットフォームを把握している |
| Teams管理センターでReport callを確認した | 対象ユーザーのポリシーでオンになっている |
| DefenderポータルでUser reported settingsを確認した | Microsoft Teamsの報告監視がオンになっている |
| 報告先メールボックスを確認した | SOCまたは担当チームが監視できる |
| Defender XDRのアラート確認手順を作った | 通話報告アラートを見逃さない |
| SIEM/SOAR連携を見直した | Teams call reported系アラートを分類できる |
| プライバシー・法務確認を行った | Microsoftへの送信内容について社内合意がある |
| ユーザー向け周知を準備した | 通話履歴から報告する手順を説明できる |
| パイロットユーザーで動作確認した | Desktop、Mac、Webなど主要環境で確認済み |
| 誤検知対応を決めた | not security riskの報告も処理できる |
次に取るべき対応
Microsoft TeamsのReport a Suspicious Call in Microsoft Teamsは、Teams通話をセキュリティ監視の対象として扱うための重要な更新です。まずは、Teams管理センターでReport callが有効か、Microsoft DefenderポータルでTeamsのユーザー報告が監視されているかを確認してください。
そのうえで、報告先メールボックス、Defender XDRのアラート確認、SOCの初動フロー、ユーザー周知を整備します。特に既存テナントでは、Defender側の設定や報告先が古いままになっている可能性があります。機能の有効化だけで終わらせず、「ユーザーが報告する」「SOCが気づく」「必要なブロックや調査を行う」までを一連の運用として設計することが、この更新を実効性のあるTeamsセキュリティ対策にするポイントです。
コメント