Microsoft Teams Phoneの「Brand Impersonation Protection」は、外部からのTeams通話で銀行、ITヘルプデスク、Microsoft Supportなどの信頼できるブランドを装う相手を検知し、ユーザーに警告を出すためのなりすまし通話対策です。結論から言うと、管理者が大規模な移行作業を行う機能ではありません。むしろ重要なのは、警告が出たときのユーザー対応、Report callの有効化、PSTN向けスパムフィルターや着信拒否設定との役割分担を整理することです。2026年6月3日に公開されたMicrosoft Teamsの月次更新では、Teams Phone領域の新機能として、通話中に「Scam suspected」などの警告を出し、ユーザーが拒否・退出・報告できることが紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Teams PhoneのBrand Impersonation Protectionとは
Microsoft Teams PhoneのBrand Impersonation Protectionは、Teams Callingで受ける外部通話に対して、発信者が有名ブランドや信頼されやすい組織を装っていないかを評価する保護機能です。
Microsoft 365 Roadmap ID 543239では、「フィッシング攻撃で狙われやすいブランドを外部ユーザーが装っていないかを、企業ユーザーへの初回接触時のTeams callingで識別する」機能として説明されています。対象プラットフォームはDesktopとMac、クラウドはWorldwide Standard Multi-TenantとGCC、ステータスはRolling out、GA時期はMay CY2026とされています。(Microsoft 365 Message Center Archive)
従来、Teamsのセキュリティ対策はチャット、ファイル、URL、会議参加者の制御に注目されがちでした。しかし、攻撃者はメールだけでなく、Teamsの音声通話やビデオ通話を使って「社内IT」「取引先」「金融機関」「Microsoftサポート」を装うことがあります。Microsoft Security Blogでも、攻撃者がTeamsのチャット、通話、会議、画面共有などを悪用し、ヘルプデスク担当者を装ってリモートアクセスを促す事例が紹介されています。(Microsoft)
つまり、この機能は単なる迷惑電話対策ではなく、音声通話を使ったソーシャルエンジニアリング対策として見るべきです。
何が変わるのか
Brand Impersonation Protectionで変わる点は、ユーザーが「通話に出る前」または「通話中」に、Teams側からリスクの手がかりを受け取れるようになることです。
| 項目 | 変更前 | 変更後 |
|---|---|---|
| 外部からの不審なTeams通話 | 表示名や相手の話し方をユーザーが判断する必要があった | Teamsがブランドなりすましの兆候を評価し、高リスク通話として警告する |
| ユーザーの行動 | 通話に出る、切る、個別に報告するなど対応がばらつきやすい | 警告を見て、拒否、終了、報告などを選びやすくなる |
| 管理者の作業 | 通話経由のなりすましは教育や個別対応に依存しがち | ユーザー教育、Report call、外部通信制御、PSTN対策を組み合わせて運用しやすくなる |
| 既存ポリシーへの影響 | 既存のTeams Callingポリシーで制御 | Message Center情報では、既存のTeams Callingポリシーは変更されないと案内されている |
Message Centerの情報では、この機能は初回接触の外部VoIP発信者からの着信を受けるTeams Calling利用組織が対象で、Teamsは着信を評価し、疑わしい通話には応答前の高リスク警告を表示します。リスク信号が続く場合は通話中にも警告が継続し、ユーザーは通話を受ける、ブロックする、終了するといった操作を選べます。機能は既定で有効化され、管理者による必須アクションはないとされています。(Microsoft 365 Message Center Archive)
ただし、「管理者の作業がない」ことと「運用準備が不要」なことは別です。警告を見たユーザーが正しく行動できなければ、攻撃者にMFAコード、パスワード、リモート操作権限、機密ファイルへのアクセスを渡してしまう可能性があります。
対象者と影響範囲
この変更の影響を受けるのは、Teams Phone管理者だけではありません。外部との通話がある部門、ヘルプデスク、SOC、情シス、取引先対応部門、開発・連携担当者まで確認が必要です。
| 対象者 | 影響 | 確認すべきこと |
|---|---|---|
| 一般ユーザー | 外部通話で警告が表示される可能性がある | 警告が出たら通話を継続せず、社内手順に従う |
| Teams Phone管理者 | 既存のCalling policyや外部通信設定との関係を確認する必要がある | Report call、Spam filtering、着信拒否、外部アクセス制御を確認する |
| ヘルプデスク | 「警告が出たが本物か」という問い合わせが増える可能性がある | 本人確認手順、折り返し手順、ユーザー向け案内文を準備する |
| SOC・セキュリティ担当 | 通話経由のフィッシング報告を調査対象に含める必要がある | Defenderポータルやユーザー報告の確認フローを整える |
| 開発者・連携担当者 | 外部連携アプリ、コンタクトセンター、ボイスボットの表示名が誤解を招く可能性がある | サービス名、発信者名、案内文を見直す |
特に注意したいのは、社外ベンダーや委託先が「IT Support」「Microsoft Support」「Helpdesk」などの汎用的な名前でTeams通話をかけているケースです。正当な運用であっても、ユーザーから見ると攻撃者のなりすましと区別しにくくなります。
Brand Impersonation ProtectionとPSTNスパムフィルターは別物
Brand Impersonation Protectionは、Teams Callingにおけるブランドなりすまし対策です。一方、Microsoft TeamsにはPSTN着信向けのスパムフィルターもあります。
Microsoft Learnでは、TeamsのスパムフィルターはPSTNからの着信を対象に、潜在的なスパム通話を検出し、ユーザーに「Spam Likely」と通知できる機能として説明されています。また、スパムフィルターは着信拒否そのものとは別の機能です。(Microsoft Learn)
整理すると、次のように使い分けます。
| 対策 | 主な対象 | 目的 | 管理者が見る場所 |
|---|---|---|---|
| Brand Impersonation Protection | Teams Callingの外部通話、特に初回接触の外部発信者 | 信頼ブランドを装う通話の警告 | Message Center、Teamsクライアントの挙動、ユーザー教育 |
| Spam filtering | PSTNからの着信 | 迷惑電話らしい着信を「Spam Likely」として通知 | Teams admin centerのCalling policies、PowerShell |
| Block inbound calls | PSTNからの特定番号・番号パターン | 繰り返し問題になる番号をテナント単位で拒否 | Teams PowerShell |
| Report a suspicious call | ユーザーが不審と判断した通話 | ユーザー報告をセキュリティ調査・検知改善につなげる | Teams admin center、Microsoft Defender portal |
すべてをBrand Impersonation Protectionだけに任せるのは危険です。VoIPのなりすまし、PSTNの迷惑電話、既知番号のブロック、ユーザー報告は、それぞれ役割が違います。
管理者が確認すべき設定
Report callが利用できる状態か確認する
Microsoft Learnでは、Microsoft Defender for Office 365 Plan 2またはMicrosoft Defender XDRを利用する組織で、管理者がTeamsの悪意ある通話・疑わしい通話のユーザー報告を許可できると説明されています。ユーザーは通話履歴または通話後の画面から「Report call」を選び、セキュリティ上の懸念として報告できます。(Microsoft Learn)
確認手順は次のとおりです。
| 確認項目 | 操作 |
|---|---|
| Teams admin center側 | Voice > Calling policies を開き、対象ポリシーの Report call を確認 |
| Defender portal側 | ユーザー報告が表示・処理される設定になっているか確認 |
| 既存テナント | 新規テナントと既存テナントで既定値が異なる可能性があるため、必ず実設定を見る |
| ユーザー案内 | 「警告が出たらReport callする」だけでなく、「通話を続けない」「公式番号へ折り返す」まで案内する |
Learnでは、Teams admin center側のReport callは既定でオン、Defender portal側は新規テナントで既定オン、既存テナントでは有効化が必要と説明されています。ユーザー報告を正しく可視化するには、Teams admin centerとDefender portalの両方を確認するのが安全です。(Microsoft Learn)
PSTN向けSpam filteringを確認する
PSTN着信が多い組織では、Brand Impersonation Protectionだけでなく、Spam filteringも確認します。
Teams admin centerでは、Calling policyのSpam Filtering設定を確認します。PowerShellでは、-SpamFilteringEnabledType パラメーターを使って設定できます。Microsoft Learnには、グローバルポリシーでスパム検出を有効化する例として次のコマンドが示されています。(Microsoft Learn)
Set-CsTeamsCallingPolicy -Identity Global -SpamFilteringEnabledType Enabledここで注意したいのは、スパムフィルターを有効にしても、すべての危険な通話が自動で切断されるわけではないことです。ユーザーに通知を出し、判断材料を増やす機能として捉えましょう。
繰り返し問題になるPSTN番号はBlock inbound callsで対応する
特定の番号帯や番号から繰り返し迷惑電話・不正通話が来る場合は、テナント単位の着信拒否も検討します。
Microsoft Learnによると、Teamsのテナント単位の着信拒否はPSTN発信の着信が対象で、Teams admin centerでは管理できず、PowerShellで設定します。また、番号パターンは正規表現で定義し、新しい番号やパターンの追加・削除が有効になるまで最大24時間かかる場合があります。(Microsoft Learn)
例として、設定状況の確認には次のようなコマンドを使います。
Get-CsTenantBlockedCallingNumbers
Get-CsInboundBlockedNumberPattern番号をブロックする場合は、正規表現の誤りに注意してください。広すぎるパターンを設定すると、正当な顧客や取引先からの通話まで止めてしまう可能性があります。設定前に Test-CsInboundBlockedNumberPattern で検証する運用を入れると安全です。
展開前に管理者がやるべき準備
Brand Impersonation Protectionは既定有効の保護機能として案内されていますが、展開前後に管理者が確認すべきことはあります。
| 優先度 | やること | 具体例 |
|---|---|---|
| 高 | ユーザー向け案内を出す | 「Scam suspected」などの警告が出たら通話を続けず、公式窓口に折り返す |
| 高 | ヘルプデスクの応対手順を作る | 「本物の社内IT担当がMFAコードを聞くことはない」と明文化する |
| 高 | Report callの設定を確認する | Teams admin centerとDefender portalの両方を見る |
| 中 | PSTN対策を確認する | Spam filtering、着信拒否番号パターン、Direct Routing側の制御を確認 |
| 中 | 外部通話の棚卸しをする | 取引先、委託先、サポートベンダー、コンタクトセンター連携を洗い出す |
| 中 | 正当な外部発信者名を見直す | 「Support」だけでなく、会社名や契約サービス名を含める |
| 低 | 社内FAQを更新する | 警告画面の意味、報告方法、折り返し確認の流れを掲載する |
特に効果が高いのは、ヘルプデスク向けの短いスクリプトを用意することです。
Teams通話でなりすまし警告が出た場合は、相手が社内担当者や取引先を名乗っていても、パスワード、MFAコード、リモート操作の承認、機密ファイルの共有は行わないでください。通話を終了し、社内ポータルに掲載された公式連絡先へ折り返してください。不審な通話はTeamsのReport callから報告してください。
このように、ユーザーが迷わず行動できる文面にしておくことが重要です。
移行・展開上の注意点
Teams Phoneの導入手順そのものは変わらない
Brand Impersonation Protectionは、Teams Phoneの基本構成やPSTN接続方式を置き換えるものではありません。
Microsoft LearnのTeams Phoneセットアップ手順では、Teams Phoneライセンスの購入・割り当て、PSTN接続方式の選択、電話番号の取得・割り当て、緊急通報、Auto attendant、Call queue、その他のTeams Phone機能、展開管理という流れが示されています。PSTN接続方式によって電話番号管理や緊急通報の手順は異なります。(Microsoft Learn)
そのため、今回の更新を理由にCalling Plan、Operator Connect、Teams Phone Mobile、Direct Routingを急いで変更する必要は通常ありません。確認すべきなのは、既存の通話経路ごとにどの保護が効くのかです。
| 通話経路 | 確認ポイント |
|---|---|
| Teams外部VoIP通話 | Brand Impersonation Protectionの警告、外部アクセス設定、ユーザー教育 |
| PSTN着信 | Spam filtering、Block inbound calls、キャリア側の迷惑電話対策 |
| Direct Routing | SBC側の番号制御、発信者番号・表示名、Teams側ポリシーとの整合性 |
| Operator Connect | オペレーター側の通話制御、番号管理、Teams側の通知・報告設定 |
| Call queue・Auto attendant | 外部からの代表番号着信が多いため、ヘルプデスク対応手順を整備 |
「警告が出る＝必ず詐欺」ではない
Brand Impersonation Protectionは、疑わしいシグナルに基づいて警告を出す保護機能です。警告が出た通話が必ず悪意あるものとは限りません。
たとえば、正当な外部サポート会社が「Microsoft 365 Support」「IT Helpdesk」のような表示名で初回連絡してきた場合、ユーザーから見れば攻撃者との区別がつきません。こうした業務フローがあるなら、事前に次の対策を取るべきです。
| リスク | 対策 |
|---|---|
| 正当な取引先がなりすましに見える | 社内ポータルに正規の連絡元、折り返し先、担当会社名を掲載する |
| ヘルプデスクがMFAコードを聞いてしまう | サポート手順からMFAコード確認を禁止する |
| 外部ベンダーが個人名・汎用名で発信する | 契約上の連絡名やメールドメインを統一する |
| ユーザーが警告を無視する | 年1回の研修ではなく、警告画面の例を使った短い周知を行う |
開発者・連携担当者は表示名と導線を見直す
Teams PhoneやTeams Callingと連携するアプリ、ボイスボット、コンタクトセンター、サポートツールを運用している場合、開発者や連携担当者も確認が必要です。
特に、外部ユーザーへ通話する仕組みや、Teams経由で顧客・社員に折り返す仕組みがある場合は、表示名、通知文、本人確認手順が誤解を招かないか確認してください。
避けたい例は次のようなものです。
| 避けたい設計 | 理由 |
|---|---|
| 発信者名が「Support」「Helpdesk」だけ | 攻撃者も同じ名前を使いやすく、正当性を判断できない |
| 通話中にMFAコードを口頭確認する | なりすまし攻撃と区別がつかず、認証情報窃取につながる |
| Teams通話から外部リモート操作ツールの導入を促す | 実際の攻撃手口と似ており、ユーザー教育と矛盾する |
| 個人アカウントや未確認テナントからサポート通話する | 企業の正規サポートとして信頼しにくい |
望ましい設計は、通話だけで完結させず、社内ポータル、チケット番号、公式メール、契約済みサポート窓口など、別経路で検証できる状態にすることです。
ユーザー向けに伝えるべき行動ルール
管理者が設定を確認しても、最後に通話を受けるのはユーザーです。周知では、機能説明よりも「何をしてはいけないか」「どう確認するか」を短く伝えます。
| 警告・状況 | ユーザーの行動 |
|---|---|
| 「Scam suspected」などの警告が出た | 通話を続けず、終了または拒否する |
| 相手がIT部門やMicrosoftを名乗る | パスワード、MFAコード、リモート操作許可を渡さない |
| 取引先や金融機関を名乗る | その場で指示に従わず、登録済みの公式番号へ折り返す |
| 判断に迷う | TeamsのReport callで報告し、社内ヘルプデスクにチケットを起票する |
| 誤検知と思われる | 勝手に無視せず、正当な連絡元である証跡を残す |
「警告が出たら気を付ける」だけでは不十分です。攻撃者は緊急性を演出します。たとえば「今すぐアカウントを止める」「請求に問題がある」「役員から依頼されている」といった言い方で、ユーザーの判断時間を奪います。社内ルールとして、緊急と言われても一度切って確認することを明文化しておきましょう。
よくある誤解
Brand Impersonation Protectionがあれば通話詐欺は完全に防げる？
完全には防げません。リスクの高い通話を警告し、ユーザーが拒否・終了・報告しやすくする機能です。警告が出ない通話でも、相手がMFAコード、パスワード、リモート操作、送金、機密ファイル共有を求める場合は疑うべきです。
管理者は何もしなくてよい？
Message Centerでは必須の管理者アクションは不要とされていますが、運用上は準備が必要です。特に、ヘルプデスクへの問い合わせ対応、Report callの確認、既存のPSTN対策、ユーザー教育は管理者側で整える必要があります。(Microsoft 365 Message Center Archive)
PSTNの迷惑電話にも同じように効く？
PSTN対策はSpam filteringやBlock inbound callsの領域です。Microsoft Learnでも、スパムフィルターはPSTN着信向けで、着信拒否とは別機能と説明されています。(Microsoft Learn) Brand Impersonation Protectionと混同せず、通話経路ごとに対策を分けて考える必要があります。
既存のTeams Phone移行計画を変更すべき？
通常は不要です。Teams Phoneのセットアップや移行は、ライセンス、PSTN接続方式、電話番号、緊急通報、Auto attendant、Call queue、通話品質管理などを整理して進めるものであり、今回の保護機能はその上に追加されるセキュリティ層として考えるのが自然です。(Microsoft Learn)
まず実施すべき確認チェックリスト
最後に、管理者が次に取るべき行動を絞り込みます。
| チェック | 内容 |
|---|---|
| Message Center確認 | 自社テナントでの展開状況、対象リング、追加案内を確認する |
| Report call確認 | Teams admin centerとDefender portalの設定を確認する |
| ユーザー周知 | 警告が出た場合の終了、折り返し、報告ルールを案内する |
| ヘルプデスク教育 | MFAコード、パスワード、リモート操作許可を求めない手順にする |
| PSTN対策確認 | Spam filteringとBlock inbound callsの運用状況を確認する |
| 外部ベンダー確認 | サポート会社や委託先の発信者名、折り返し先、本人確認手順を整理する |
| インシデント対応 | 通話経由の報告をセキュリティ調査フローに含める |
Microsoft Teams PhoneのBrand Impersonation Protectionは、通話を使ったなりすまし攻撃に対する実用的な防御層です。ただし、警告機能だけでリスクが消えるわけではありません。管理者は、Report call、PSTNスパム対策、着信拒否、外部アクセス制御、ユーザー教育を組み合わせて、通話経由の攻撃に対応できる運用へ更新する必要があります。
まずは自社テナントのMessage Centerを確認し、Report callが使える状態かを見直してください。そのうえで、ユーザーに「警告が出たら通話を続けない」「公式窓口に折り返す」「不審な通話を報告する」という3点を周知することが、最も早く効果の出る対応です。
コメント