Microsoft Teamsの匿名参加者アクセス管理は、組織全体のスイッチで一律に制御する方式から、会議開催者ごとのポリシーで制御する方式へ移行準備が必要です。
2026年7月10日に更新されたMicrosoft Learnでは、組織全体のAnonymous users can join a meeting設定が将来的に廃止されると明記されました。当面はこの設定をオンのまま維持し、Anonymous users can join a meeting unverifiedという開催者単位の会議ポリシーで、匿名参加を許可するユーザーやグループを管理することが推奨されています。
ただし、組織全体設定の廃止日や段階的な展開スケジュールは、現時点では示されていません。管理者は設定をすぐに一律変更するのではなく、現在の会議ポリシー、ロビー、メールコード確認、外部アクセス、イベントポリシーを棚卸ししてから段階的に移行する必要があります。(Microsoft Learn)
Microsoft Teamsの匿名参加者アクセス管理で何が変わるのか
今回の重要なポイントは、匿名参加機能そのものが突然追加・廃止されることではありません。匿名参加を管理する中心が、テナント全体の設定から開催者単位のポリシーへ移ることです。
| 項目 | 現在の構成 | 今後の推奨構成 |
|---|---|---|
| 主な管理単位 | 組織全体 | 会議開催者またはグループ単位 |
| Teams管理センター | 会議設定の組織全体スイッチ | 会議ポリシーの開催者単位設定 |
| 組織全体設定 | 匿名参加全体の上位ゲートとして機能 | 当面はオンのまま維持 |
| 匿名参加の許可・拒否 | 全員に一律適用しやすい | 業務や役割に応じて個別制御 |
| PowerShell | DisableAnonymousJoin | AllowAnonymousUsersToJoinMeeting |
| 管理の柔軟性 | 低い | 外部向け会議の開催者だけ許可できる |
PowerShellでは、従来のテナント全体設定が-DisableAnonymousJoin、開催者単位の設定が-AllowAnonymousUsersToJoinMeetingに対応します。Microsoftは、前者をFalse、つまり匿名参加を組織全体ではブロックしない状態に保ち、後者でユーザーやグループごとに制御することを推奨しています。(Microsoft Learn)
組織全体設定は今すぐオフにするものではない
「組織全体設定が廃止予定」と聞くと、設定を今すぐ無効化すべきだと考えがちです。しかし、公式の推奨は逆です。
現在は、Teams管理センターの次の設定をオンのまま維持します。
会議 → 会議の設定 → 参加者 → 匿名ユーザーが会議に参加できる
そのうえで、次の開催者単位ポリシーを使って許可範囲を絞ります。
会議 → 会議ポリシー → 会議参加とロビー → Anonymous users can join a meeting unverified
この構造にしておけば、組織全体設定が将来削除されても、開催者単位のポリシーを中心とした運用へ移行しやすくなります。(Microsoft Learn)
対象サービスとプラットフォーム
今回の情報は、特定のWindows版やMac版Teamsアプリだけを対象にしたクライアント更新ではありません。Microsoft Teamsサービス側の会議・イベントポリシーに関する管理情報です。
| 対象 | 影響 |
|---|---|
| Teams会議 | 匿名参加の許可、メール確認、ロビー待機を制御 |
| Teamsイベント | ウェビナーやタウンホールへの匿名登録・参加を制御 |
| Teams管理センター | GUIによる設定とポリシー割り当て |
| Teams PowerShell | 設定の一括確認、変更、自動化 |
| Teams Premium | 匿名参加者のメールコード確認に必要 |
| Azure Communication Services | カスタムクライアントからの匿名参加も制御対象 |
公式ページには、Windows、Mac、Web、iOS、Androidごとの展開日は記載されていません。記載内容から判断すると、クライアント別の機能配信ではなく、テナントと開催者に割り当てられるサービス側ポリシーとして扱うべき更新です。
匿名参加者は通常のTeamsクライアントだけでなく、Azure Communication Servicesを利用して作られたカスタムクライアントから参加する場合もあります。必要であれば、PowerShellの-BlockedAnonymousJoinClientTypesを使用し、TeamsクライアントまたはAzure Communication Servicesクライアントの一方をブロックできます。(Microsoft Learn)
Teamsにおける「匿名参加者」とは
Teamsの匿名参加者は、単に名前を入力せず参加した人だけではありません。MicrosoftによってIDが確認できない参加者が匿名として扱われます。
| 参加者の状態 | Teams上の扱い |
|---|---|
| 組織の職場または学校アカウントでサインイン | 組織内ユーザー |
| Microsoft Entra B2Bのゲストアカウントで参加 | ゲスト |
| 信頼関係が成立した外部組織のアカウントで参加 | 外部ユーザー |
| サインインせずに参加 | 未確認の匿名参加者 |
| 信頼されていない組織から参加 | 匿名として扱われる場合がある |
| 一方向だけの外部アクセス許可になっている | 匿名として扱われる場合がある |
| メールコードで確認して参加 | メール確認済みの匿名参加者 |
未確認の匿名参加者には、会議中にUnverified相当の表示が付きます。メールに送られたワンタイムパスコードで確認した参加者にはEmail Verified、Microsoftアカウントでサインインした外部参加者にはExternalと表示されます。(Microsoft Learn)
外部アクセス設定の不備でも匿名扱いになる
管理者が特に注意すべきなのは、取引先のユーザーがMicrosoft 365アカウントでサインインしていても、必ず外部ユーザーとして認識されるとは限らない点です。
外部組織との信頼関係は、双方の組織が互いのドメインを許可し、開催者と参加者の両方に外部アクセスを許可するポリシーが適用されている必要があります。片方の組織だけが許可している場合や、開催者の外部アクセスポリシーが無効な場合、相手が匿名参加者として扱われる可能性があります。(Microsoft Learn)
そのため、「匿名参加を禁止したら特定の取引先だけ会議に入れなくなった」という場合は、会議ポリシーだけでなく外部アクセス設定も確認する必要があります。
匿名参加を制御する設定は複数ある
匿名参加の管理では、一つのスイッチだけを確認しても不十分です。少なくとも次のレイヤーを分けて考える必要があります。
| 管理レイヤー | 主な設定 | 役割 |
|---|---|---|
| 組織全体 | Anonymous users can join a meeting | 現行の組織全体ゲート |
| 開催者単位 | Anonymous users can join a meeting unverified | 未確認の匿名参加を許可・拒否 |
| メール確認 | Anonymous users can join a meeting after verifying | メールコードによる確認方法を提供 |
| 会議単位 | Require unverified participants to verify their info before joining | 開催者が特定の会議で確認を要求 |
| ロビー | Who can bypass the lobby | 匿名参加者を直接入室させるか決定 |
| 会議開始 | Anonymous users and dial-in callers can start a meeting | 確認済みユーザー不在で開始できるか決定 |
| アプリ | Anonymous users can interact with apps in meetings | 会議アプリを利用できるか決定 |
| イベント | Who can attend webinarsなど | イベントへの登録・参加を制御 |
未確認参加とメールコード確認は別の設定
次の二つは名前が似ていますが、役割が異なります。
Anonymous users can join a meeting unverified
未確認のまま匿名参加できるかを決めます。
Anonymous users can join a meeting after verifying
メールに送られたワンタイムパスコードを使う確認経路を提供するかを決めます。
PowerShellでは、それぞれ次のパラメーターに対応します。
- 未確認参加:
AllowAnonymousUsersToJoinMeeting - メール確認:
AnonymousUserAuthenticationMethod
AnonymousUserAuthenticationMethodの値は、メールコードを利用するOneTimePasscodeと、認証方法を無効にするNoneです。ただし、Noneに変更するだけでは、未確認の匿名参加まで自動的に禁止されるわけではありません。匿名参加を全面的に止める場合は、未確認参加の許可設定も併せて確認する必要があります。(Microsoft Learn)
メールコード確認にはTeams Premiumが必要
メールコードによる匿名参加者の確認機能を利用できるのは、Teams Premiumライセンスを持つ会議開催者です。
管理者が開催者単位の会議ポリシーでBy email codeを許可すると、対象のTeams Premiumユーザーには、会議オプションとして次の設定が表示されます。
Require unverified participants to verify their info before joining
開催者がこの設定をオンにすると、未確認の匿名参加者はメールアドレスを入力し、送信されたワンタイムパスコードで確認してから会議へ参加します。
注意すべき点は、この管理者設定だけで、すべての会議にメール確認が強制されるわけではないことです。公式ページでは、開催者側の会議オプションは既定でオフとされています。管理者が機能を許可した後、開催者が対象会議で有効にする必要があります。(Microsoft Learn)
また、メールコード確認はTeamsイベントではサポートされません。ウェビナーやタウンホールでは、イベントポリシー、登録、ロビーなど別の方法で参加者を管理する必要があります。(Microsoft Learn)
ロビー設定は匿名参加の許可とは別に確認する
匿名参加を許可していても、参加者をすぐ会議へ入室させる必要はありません。
Who can bypass the lobbyをEveryone以外に設定すると、匿名参加者をロビーで待機させられます。例えば、組織内ユーザーや信頼された組織だけを直接入室させ、匿名参加者は開催者が確認してから許可する運用が可能です。
一方、Who can bypass the lobbyがEveryoneの場合、匿名参加者も原則としてロビーを通過します。機密情報を扱う会議では、匿名参加を許可するかどうかだけでなく、ロビーを通過できるユーザーの範囲も確認してください。(Microsoft Learn)
Anonymous users and dial-in callers can start a meetingは、原則としてオフを維持するのが安全です。この設定をオンにすると、確認済みの参加者や開催者がいない状態でも、匿名参加者が会議リンクを使って会議を開始できる場合があります。Microsoftもオフを推奨しています。(Microsoft Learn)
匿名参加者の会議アプリ利用も確認する
匿名参加を許可する組織では、会議アプリの利用可否も確認が必要です。
既定では、匿名参加者による会議アプリの操作は有効です。匿名参加者は、グローバルのTeamsアプリ許可ポリシーを継承し、会議内にすでに追加されているアプリを操作できます。ただし、自分でアプリを追加したり管理したりすることはできません。
会議アプリでアンケート、入力フォーム、外部サービス連携などを利用している場合は、匿名参加者にどこまで操作を許可するかを確認してください。設定場所は次のとおりです。
会議 → 会議の設定 → 参加者 → Anonymous users can interact with apps in meetings
PowerShellではDisableAppInteractionForAnonymousUsersで制御できます。パラメーター名が否定形のため、Trueがアプリ操作の禁止、Falseが許可となる点に注意が必要です。(Microsoft Learn)
Teamsイベントの匿名参加は別のポリシーで管理する
Teams会議とTeamsイベントでは、匿名参加を管理するポリシーが異なります。
| イベントの種類 | 主な管理設定 | 匿名参加を許可する値 |
|---|---|---|
| 最大1,000人規模のイベント | Who can attend webinars | Everyone |
| 大規模な対象者向けに最適化したイベント | Who can attend town halls | Everyone |
| PowerShellで最大1,000人規模を管理 | EventAccessType | Everyone |
| PowerShellで大規模イベントを管理 | TownhallEventAttendeeAccess | Everyone |
Optimize for large audienceが有効なイベントには、タウンホール向けの参加ポリシーが適用されます。それ以外では、ウェビナー向けの参加ポリシーが適用されます。
匿名参加者の登録や参加を認めるには、対象ポリシーをEveryoneに設定します。組織内ユーザーだけに制限する値へ変更すると、匿名参加者はイベントへの登録や参加ができません。イベントポリシーの変更も、反映まで最大24時間かかる場合があります。(Microsoft Learn)
展開時期はいつか
Microsoft Learn日本語版の最終更新日は、2026年7月10日です。ただし、この日付は公式ドキュメントの更新日であり、組織全体設定が同日に削除されたことを意味しません。
2026年7月10日時点の公式ページには、次の情報は記載されていません。
- 組織全体設定が削除される具体的な日付
- Targeted Releaseの開始時期
- 一般提供環境への展開時期
- Windows、Mac、Web、モバイルごとの展開順
- 商用環境や政府機関向け環境ごとの展開差
一方で、現在の組織全体設定をオンのまま維持し、開催者単位の会議ポリシーへ管理を移すよう明確に推奨されています。
したがって、この更新は「即日で動作が変わる機能展開」というより、将来の設定廃止に備えるための運用移行通知として捉えるのが適切です。なお、会議ポリシーやイベントポリシーの変更自体は、反映まで最大24時間かかる場合があります。(Microsoft Learn)
対応が必要な組織を判断する
| 現在の運用 | 対応優先度 | 確認すべきこと |
|---|---|---|
| 組織全体の匿名参加をオフにしている | 高 | 開催者単位ポリシーを先に設計する |
| 組織全体をオンにし、全員に匿名参加を許可している | 高 | 内部会議用の制限ポリシーが必要か確認 |
| 外部向け会議を一部の部署だけが開催する | 高 | 対象グループ専用の許可ポリシーを作成 |
| Teams Premiumを利用している | 高 | メールコード確認と開催者向け手順を確認 |
| 公開ウェビナーやタウンホールを開催する | 高 | イベントポリシーを別途確認 |
| 特定の取引先が匿名扱いになる | 高 | 双方向の外部アクセス設定を確認 |
| 匿名参加を現在利用していない | 中 | 将来の廃止前に制限ポリシーを準備 |
| Azure Communication Servicesを利用している | 中 | 匿名参加クライアントの許可範囲を確認 |
特に、現在組織全体の匿名参加をオフにしているテナントは注意が必要です。開催者単位のポリシーが初期状態のまま組織全体設定をオンにすると、想定より広い範囲の開催者が匿名参加可能な会議を作成できる可能性があります。
管理者が行う設定確認手順
現在の設定を棚卸しする
最初に、Teams管理センターで次の項目を確認します。
会議→会議の設定で、組織全体の匿名参加設定を確認する会議→会議ポリシーで、グローバルポリシーとカスタムポリシーを確認する- 各ポリシーの未確認参加とメールコード確認を確認する
- ロビー通過、会議開始、アプリ操作の設定を確認する
- 各ポリシーが割り当てられているユーザーやグループを確認する
会議→イベントポリシーで、公開イベントの参加範囲を確認する
PowerShellを利用している場合は、次のような読み取り処理で設定を一覧化できます。
Import-Module MicrosoftTeams
Connect-MicrosoftTeams
Get-CsTeamsMeetingConfiguration |
Select-Object Identity,
DisableAnonymousJoin,
DisableAppInteractionForAnonymousUsers
Get-CsTeamsMeetingPolicy |
Select-Object Identity,
AllowAnonymousUsersToJoinMeeting,
AnonymousUserAuthenticationMethod,
AutoAdmittedUsers,
BlockedAnonymousJoinClientTypes |
Sort-Object Identity
Get-CsTeamsEventsPolicy |
Select-Object Identity,
EventAccessType,
TownhallEventAttendeeAccess |
Sort-Object Identity
CSVとして証跡を保存する場合は、次のように出力します。
Get-CsTeamsMeetingPolicy |
Select-Object Identity,
AllowAnonymousUsersToJoinMeeting,
AnonymousUserAuthenticationMethod,
AutoAdmittedUsers,
BlockedAnonymousJoinClientTypes |
Export-Csv ".\TeamsMeetingPolicies.csv" `
-NoTypeInformation `
-Encoding utf8
Teams PowerShellでは、DisableAnonymousJoinが否定形である一方、AllowAnonymousUsersToJoinMeetingは肯定形です。値の意味を取り違えないようにしてください。(Microsoft Learn)
会議の用途別にポリシーを設計する
全ユーザーに同じポリシーを割り当てるより、開催する会議の用途で分けたほうが管理しやすくなります。
| 会議の用途 | 匿名参加 | メール確認 | ロビー |
|---|---|---|---|
| 社内会議 | 原則禁止 | 無効 | 組織外ユーザーは待機 |
| 通常の取引先会議 | 必要に応じて許可 | 任意 | 匿名参加者は待機 |
| 採用面接や相談会 | 許可 | Teams Premium利用時に検討 | 開催者が確認して入室 |
| 機密性の高い外部会議 | 原則禁止またはメール確認 | 推奨 | 開催者・共同開催者のみ通過 |
| 一般向け説明会 | 許可 | 必要性を判断 | ロビーと発表者権限を制限 |
| 公開イベント | イベントポリシーで許可 | 利用不可 | 登録・ロビー・役割で管理 |
取引先との定例会議では匿名参加を許可しつつ、経営会議や人事会議では禁止するなど、開催者の役割に応じてポリシーを割り当てるのが実務的です。
組織全体設定がオフの場合は順序を守る
現在、組織全体の匿名参加設定をオフにしている場合、いきなりオンへ変更してはいけません。安全な移行順序は次のとおりです。
- グローバル会議ポリシーの現在値を保存する
- 原則禁止とする開催者用ポリシーを作成する
- 外部向け会議を開催するユーザーやグループだけに許可ポリシーを作成する
- Teams Premium利用者についてメールコード確認の方針を決める
- ポリシーを対象ユーザーやグループへ割り当てる
- 最大24時間の反映時間を見込む
- テストユーザーで参加動作を確認する
- 問題がないことを確認してから組織全体設定をオンにする
この順序なら、組織全体設定をオンにした瞬間に、全開催者の会議で匿名参加が広く許可されるリスクを抑えられます。
移行前に実施すべきテスト
設定変更後は、開催者のTeams画面だけでなく、参加者側の動作も確認します。
| テスト参加者 | 確認内容 |
|---|---|
| サインアウトしたブラウザー | 未確認として参加できるか、ロビーに入るか |
| 個人用Microsoftアカウント | 外部ユーザーとして認識されるか |
| 信頼済みの取引先テナント | 匿名ではなく外部ユーザーになるか |
| 信頼されていないテナント | 匿名扱いになった場合の動作 |
| メールコードを利用する参加者 | コード受信、入力、表示名を確認 |
| Teams Premiumを持たない開催者 | メール確認オプションの表示を確認 |
| 公開イベントの参加者 | 登録と参加が可能か |
| Azure Communication Servicesクライアント | 許可またはブロックが意図どおりか |
テストでは、予定された会議だけでなく、新しく作成した会議でも確認してください。既存会議の会議オプションが、現在の管理者ポリシーと異なる状態になっている可能性があるためです。
失敗しやすいポイント
組織全体設定だけを変更する
今後の中心は開催者単位のポリシーです。組織全体設定だけで匿名参加を管理し続けると、設定廃止時に影響範囲を把握できなくなる可能性があります。
匿名参加とロビー通過を同じものとして扱う
匿名参加を許可しても、ロビーで待機させることは可能です。参加許可と自動入室は別々に設計してください。
メールコード設定をオンにすれば自動的に強制されると考える
Teams Premiumのメールコード確認は、開催者が会議オプションをオンにして利用する仕組みです。管理者ポリシーだけで、すべての会議に自動適用されるとは限りません。
Noneを匿名参加禁止の設定だと考える
AnonymousUserAuthenticationMethod Noneは、メールコードによる認証経路を無効にする値です。未確認の匿名参加を禁止する設定とは別です。
Teams会議とイベントを同じ設定で管理する
ウェビナーやタウンホールはイベントポリシーで管理されます。会議ポリシーだけ変更しても、公開イベントの匿名登録や参加範囲は変わらない場合があります。
外部アクセスの信頼関係を確認しない
相手がMicrosoft 365ユーザーでも、双方の外部アクセス設定が整っていなければ匿名扱いになる可能性があります。匿名参加を厳しく制限するほど、取引先の外部アクセス設定が重要になります。
管理者が最初に行うべきこと
最初に実施すべきなのは、組織全体設定を変更することではありません。現在の会議ポリシーと割り当て状況を一覧化し、どの開催者に匿名参加を認めるかを決めることです。
特に組織全体設定をオフにしているテナントでは、先に開催者単位の制限ポリシーを整備してください。その後、外部向け会議を担当する部署だけに許可ポリシーを割り当て、テスト環境で動作を確認してから、組織全体設定をオンへ移行します。
2026年7月10日時点では、組織全体設定の具体的な廃止日は示されていません。しかし、Microsoftが開催者単位の管理へ移行する方針を明示した以上、廃止日が発表されてから対応を始めるのではなく、現在のうちにポリシー構成を整理しておくことが安全です。(Microsoft Learn)

コメント