Microsoft Entra テナント制限 v2の2026年4月更新で、管理者が最初に押さえるべきポイントは「サービス プリンシパルのサインインがブロックされたとき、ログがどのテナントに残るか」です。2026年4月24日のMicrosoftDocs更新では、Tenant Restrictions v2でサービス プリンシパルのサインインがブロックされた場合、サインインログは要求を受けたテナント側にのみ表示され、ポリシーを構成したテナント側には生成されない、という注意点が追加されました。これは新機能の追加というより、調査・監査・SIEM連携の運用に影響する重要な明確化です。(GitHub)
この記事では、Microsoft Entra ID / Microsoft Entra External IDの「Configure Tenant Restrictions」、つまりテナント制限 v2について、2026年4月更新の意味、v1との違い、設定時の判断基準、監査ログで見落としやすいポイントまで実務向けに整理します。対象は、security admins、identity teams、compliance teamsです。
Microsoft Entra テナント制限 v2とは何か
Microsoft Entra テナント制限 v2は、組織のネットワークや管理対象デバイスから、ユーザーが外部アカウントを使って外部アプリへサインインする行為を制御するための機能です。たとえば、社員が個人で作成した別テナントのアカウントや、取引先から付与された外部アカウントを使って、会社の端末・会社のネットワークから外部テナントのアプリにアクセスするケースを制限できます。(Microsoft Learn)
重要なのは、テナント制限が「自社アカウントで外部アプリへ行く」制御だけではない点です。Microsoftの整理では、インバウンド設定は外部アカウントによる内部アプリへのアクセス、アウトバウンド設定は内部アカウントによる外部アプリへのアクセスを制御します。一方、テナント制限は外部アカウントによる外部アプリへのアクセスを制御します。(Microsoft Learn)
実務では、次のようなシナリオで有効です。
| シナリオ | テナント制限 v2で防ぎたいこと |
|---|---|
| 退職予定者や内部不正リスクのあるユーザー | 個人テナントや不明な外部テナントへサインインし、データを持ち出す |
| 会社端末での個人Microsoftアカウント利用 | 管理外のOneDrive、Teams、Microsoft 365環境へのアクセス |
| 取引先テナントへのアクセス | 許可済みパートナーの特定アプリだけを許可し、それ以外をブロック |
| 監査・規制対応 | 外部テナント利用を「暗黙の許可」ではなく、ポリシーで明示的に管理 |
2026年4月24日更新のポイントは「サービス プリンシパルのログ」
2026年4月24日の更新で追加された実務上のポイントは、サービス プリンシパルのサインインログに関する記述です。GitHub上のMicrosoftDocs履歴では、該当コミットが「Add note on service principal sign-in log behavior」としてマージされ、Tenant Restrictions v2でサービス プリンシパルのサインインがブロックされた場合のログ表示先が追記されています。(GitHub)
追加された内容を運用目線で言い換えると、次のようになります。
| 確認ポイント | 管理者が取るべき対応 |
|---|---|
| サービス プリンシパルのサインインがTRv2でブロックされる場合がある | 人間のユーザーだけでなく、アプリ認証・自動化処理もテスト対象に入れる |
| ログはサインイン要求を受けたテナント側にのみ出る | ポリシー設定テナント側だけを見て「ログがない」と判断しない |
| TRv2ポリシー構成テナント側にはログが生成されない | SOC、監査、障害対応手順書にログ確認先を明記する |
| Microsoft GraphやPowerShell連携に影響する可能性がある | サービス プリンシパルを使う運用ジョブを棚卸しする |
特に注意したいのは、SIEMやログ分析基盤で「自社テナントのサインインログだけ」を監視している場合です。TRv2によるブロックが発生しても、期待した場所にログが出ない可能性があります。障害調査では、対象アプリのテナント、リソーステナント、外部テナントのどこにサインイン要求が送られたかを確認する必要があります。
テナント制限 v2の保護範囲は「認証プレーン」と「データプレーン」で考える
Tenant Restrictions v2を理解するうえで、認証プレーンとデータプレーンの違いは避けて通れません。
認証プレーン保護は、外部IDを使ったサインインそのものをブロックする仕組みです。Microsoft Learnでは、Tenant Restrictions v2の認証プレーン保護は一般提供と説明されています。(Microsoft Learn)
データプレーン保護は、認証をすり抜けるようなアクセスを防ぐための仕組みです。たとえば、匿名のTeams会議参加、SharePointファイルへの匿名アクセス、外部テナントで取得したトークンの持ち込みといったケースを想定します。Microsoft Learnでは、データプレーン保護により、リソースアクセス時に認証を強制し、認証に失敗した場合はアクセスをブロックすると説明されています。(Microsoft Learn)
| 保護の種類 | 主な対象 | 実務上の意味 |
|---|---|---|
| 認証プレーン保護 | 外部アカウントによるサインイン | 未承認テナントへのサインインを入口で止める |
| データプレーン保護 | SharePoint、OneDrive、Teams、Microsoft Graphなどのリソースアクセス | 匿名リンク、会議参加、持ち込みトークンなどの回避策を抑える |
| サービス プリンシパルの制御 | アプリ認証、Graph連携、自動化ジョブ | ユーザー操作以外のアクセス経路も監査対象にする |
SharePoint Onlineは認証プレーンとデータプレーンの両方でTenant Restrictions v2をサポートし、外部発行IDを使った匿名ファイルアクセスはブロックされます。OneDriveも同様に認証プレーンとデータプレーンの両方をサポートしますが、コンシューマー向けOneDrive、つまり onedrive.live.com 経由のOneDrive for ConsumerはTRv2の対象外で、必要に応じてプロキシ側でのブロックが回避策として示されています。(Microsoft Learn)
v1からv2で何が変わったのか
Tenant Restrictions v1は、主に企業プロキシで許可テナントの一覧をHTTPヘッダーに挿入し、Microsoft Entra ID側で認証時に制御する方式でした。v2では、構成の中心がMicrosoft Entraのクロステナントアクセス設定に移り、クラウド側のポリシーとして管理できるようになっています。(Microsoft Learn)
| 比較項目 | Tenant Restrictions v1 | Tenant Restrictions v2 |
|---|---|---|
| 管理方式 | 企業プロキシのヘッダー設定が中心 | クロステナントアクセス設定のクラウドポリシーが中心 |
| 管理画面 | Microsoft Entra管理センターでのポリシーUIなし | Microsoft Entra管理センターから設定可能 |
| 粒度 | テナント単位、Microsoftアカウント単位が中心 | テナント、ユーザー、グループ、アプリ単位で制御可能 |
| 匿名アクセス対策 | Teams会議やファイル共有の匿名アクセスは許可される | Teams会議、匿名共有リソース、Formsなどをブロック可能 |
| プロキシ依存 | 強い | Global Secure Access、企業プロキシ、Windowsデバイス管理から選択 |
| データプレーン保護 | 限定的 | 構成方式により対応可能 |
v1からv2へ移行する場合、v1の Restrict-Access-To-Tenants ヘッダーで管理していた許可リストを、v2ではパートナーテナントごとのポリシーとして作成します。Microsoftは、v2では構成がサーバー側のクラウドポリシーに移るため、v1ヘッダーは不要になると説明しています。(Microsoft Learn)
適用方式は3つある：GSA、企業プロキシ、Windows管理デバイス
Tenant Restrictions v2は、ポリシーを作成しただけでは十分ではありません。要求にTRv2のシグナルを載せ、Microsoft Entra ID側に「この組織のテナント制限ポリシーを適用する」と伝える必要があります。Microsoft Learnでは、クライアント側での適用方式として、Global Secure Accessのユニバーサルテナント制限、企業プロキシ、Windows管理デバイスの3つが示されています。(Microsoft Learn)
| 適用方式 | 向いている環境 | 強み | 注意点 |
|---|---|---|---|
| Global Secure Accessによるユニバーサルテナント制限 | 多拠点、リモートワーク、複数OS、複数ブラウザー | OS、ブラウザー、デバイス形態にかかわらずトラフィックへタグ付けできる | Global Secure Accessのライセンス、クライアント、リモートネットワーク設定が必要 |
| 企業プロキシ | 既存のプロキシ基盤があり、社内ネットワーク中心 | 認証プレーンの制御を既存ネットワークで実装しやすい | データプレーン保護は提供されない。TLS検査とヘッダー挿入が必要 |
| Windows管理デバイス | 会社所有Windows端末を中心に管理している環境 | 企業プロキシなしで認証プレーンと一部データプレーンを保護可能 | プレビュー要素があり、Chrome、Firefox、.NETスタックなどは直接保護されない |
Global Secure Accessのユニバーサルテナント制限は、OSやブラウザー、デバイス形態に関係なくトラフィックにタグ付けし、クライアント接続とリモートネットワーク接続の両方をサポートします。Microsoft Learnでは、Microsoft Entra IDとMicrosoft GraphのネットワークトラフィックにTRv2のポリシー情報を追加し、承認された外部テナントのみを利用させる仕組みとして説明されています。(Microsoft Learn)
企業プロキシ方式では、sec-Restrict-Tenant-Access-Policy ヘッダーに <TenantId>:<policyGuid> を設定し、Microsoftのサインインドメインへ送信します。対象として、login.live.com、login.microsoft.com、login.microsoftonline.com、login.windows.net が挙げられています。(Microsoft Learn)
設定前に決めるべきポリシー設計
Tenant Restrictions v2で失敗しやすいのは、いきなり「全部ブロック」から始めることです。セキュリティ上は強く見えても、取引先テナント、学習サービス、サポートポータル、自動化ジョブなどが止まり、業務影響の切り分けが難しくなります。
まずは、次の順序で設計すると実装しやすくなります。
| 設計項目 | 推奨する考え方 |
|---|---|
| 既定ポリシー | 原則ブロックを基本にしつつ、検証期間は対象ユーザーを絞る |
| パートナーテナント | 取引先ドメインではなく、テナントIDで確認する |
| 許可アプリ | 「外部テナント全体」ではなく、必要なアプリだけを許可する |
| Microsoftアカウント | 個人MSAを全面許可せず、Microsoft Learnなど必要なアプリ単位で検討する |
| 監査 | ユーザー、サービス プリンシパル、匿名アクセスを別々にテストする |
| 例外管理 | 例外を申請制にし、期限・理由・承認者を残す |
Microsoft Learnでは、既定のテナント制限を設定したうえで、必要に応じてパートナー組織を追加し、既定値と異なる設定をカスタマイズできると説明されています。また、外部アプリケーションはすべてを対象にするか、選択したアプリケーションだけを対象にするかを選べます。(Microsoft Learn)
Microsoftアカウントを扱う場合は特に注意が必要です。Microsoftアカウントではユーザー単位の細かな割り当てはサポートされないため、アプリケーション単位の粒度で必要最小限に絞る設計が現実的です。(Microsoft Learn)
実装手順：本番導入前にやるべきこと
現状の外部テナント利用を棚卸しする
最初に、現在どの外部テナントへアクセスしているかを把握します。対象は人間のユーザーだけではありません。PowerShell、Microsoft Graph、CI/CD、監視ツール、バックアップ製品など、サービス プリンシパルを使う処理も確認します。
チェックすべき項目は次の通りです。
| 棚卸し対象 | 確認内容 |
|---|---|
| ユーザーサインイン | どの外部テナントへ、どのアカウントでサインインしているか |
| B2Bコラボレーション | 正規のゲスト招待で代替できるアクセスか |
| Microsoftアカウント | 個人MSA利用が業務上必要か |
| Teams会議 | 外部開催会議への参加要件があるか |
| SharePoint / OneDrive | 匿名リンクや外部発行IDでのアクセスがあるか |
| サービス プリンシパル | 外部テナントへ向かうGraph/API連携があるか |
既定ポリシーを作成する
Microsoft Entra管理センターで、Entra ID > External Identities > Cross-tenant access settings に移動し、既定の設定からTenant restrictionsを編集します。既定ポリシーが存在しない場合は、ポリシーを作成し、Tenant IDとPolicy IDを控えます。これらはWindowsクライアントやプロキシ設定で必要になります。(Microsoft Learn)
初期設定では、次のような方針が扱いやすいです。
| 環境 | 推奨初期方針 |
|---|---|
| 高規制業種、金融、医療、公共 | 既定でブロックし、必要なパートナーとアプリだけ許可 |
| 一般企業で外部コラボレーションが多い | 監査対象グループから段階導入し、業務影響を確認 |
| グローバル企業 | 地域別・部門別の例外ではなく、テナントIDとアプリIDで標準化 |
| 開発部門が多い組織 | サービス プリンシパル、検証テナント、GitHub Actionsなどの自動化経路を先に棚卸し |
パートナーテナントごとの例外を作る
既定で外部アクセスをブロックする場合、業務上必要な取引先や教育サービスなどはパートナーテナントとして追加します。このとき、ドメイン名だけで判断せず、テナントIDを確認することが重要です。大企業やグループ会社では、同じブランド名でも複数テナントを運用していることがあります。
例外は「パートナー全体を許可」ではなく、できるだけ「特定ユーザーまたはグループが、特定アプリだけ利用できる」形にします。Microsoft Learnでも、特定ユーザーに特定アプリケーションだけを許可する設計は、必要なユーザーにアクセスを限定することでセキュリティ体制を高めると説明されています。(Microsoft Learn)
適用方式を選び、シグナルを有効化する
Global Secure Accessを利用する場合は、Universal Tenant RestrictionsタブでMicrosoft Entra IDとMicrosoft Graph向けのTenant Restrictionsを有効化します。Microsoft Learnでは、Global Secure Access AdministratorとSecurity Administratorのロールが必要な手順として説明されています。(Microsoft Learn)
企業プロキシを使う場合は、TRv2ヘッダーをMicrosoftサインインドメインへ送信します。以前にv1やMSA制限を設定していた環境では、restrict-msa を送信し続けると新しい設定と競合する可能性があるため、既存ヘッダーの整理が必要です。(Microsoft Learn)
Windows管理デバイスで適用する場合は、グループポリシーでTenant IDとPolicy IDを設定します。ただし、WindowsのTRv2は一部シナリオの認証プレーンとデータプレーンを保護する部分的なソリューションであり、Chrome、Firefox、.NETスタックは保護しないとされています。これらを制御するには、App Control for BusinessやWindows Firewallの併用を検討します。(Microsoft Learn)
監査・ログ確認で失敗しやすいポイント
Tenant Restrictions v2は、設定そのものよりも「ブロックされた理由を説明できるか」が運用上の成否を分けます。特に2026年4月更新で明確化されたサービス プリンシパルのログ挙動は、障害対応の盲点になりやすい部分です。
| 症状 | よくある原因 | 確認すべき場所 |
|---|---|---|
| ユーザーはブロックされたが、自社テナントにログがない | 外部テナント側でサインイン要求が処理されている | リソーステナント、外部テナントのサインインログ |
| サービス プリンシパルの失敗ログが見つからない | TRv2ポリシー構成テナントにはログが出ないケース | サインイン要求を受けたテナント |
| Teams会議の挙動が想定と違う | Teamsフェデレーション制御とTRv2の役割を混同 | Teams管理センター、クロステナントアクセス設定 |
| SharePoint匿名リンクが一部通る | ホームテナントのリソースと外部テナントのリソースを混同 | リンク生成元テナント、利用ID |
| ChromeやFirefoxで抜け道がある | Windows GPO方式だけでは未対応アプリを保護できない | App Control for Business、Windows Firewall設定 |
| OneDrive個人向けが制御されない | onedrive.live.com はTRv2対象外 | プロキシまたはSWG側のURL制御 |
Microsoft Learnでは、サインインログでTRv2ポリシー適用時のサインイン詳細を確認でき、失敗時にはアクティビティ詳細に理由が表示されると説明されています。一方、サービス プリンシパルがTRv2でブロックされた場合、ログは要求を受けたテナントにのみ表示され、ポリシーを構成したテナントには生成されないとされています。(Microsoft Learn)
コンプライアンスチームが確認すべき観点
コンプライアンスチームにとって、Tenant Restrictions v2は「外部テナントへのアクセスを止める機能」だけではありません。外部ID、個人アカウント、匿名アクセス、自動化アプリの利用実態を説明可能にするための統制ポイントです。
監査証跡として残すべきものは、少なくとも次の5つです。
| 証跡 | 残す理由 |
|---|---|
| 既定ポリシーの設定値 | 原則ブロックか、許可ベースかを説明するため |
| パートナーテナントの許可理由 | 例外が業務上必要であることを示すため |
| 許可アプリの一覧 | 外部テナント全体を広く許可していないことを示すため |
| サービス プリンシパルの棚卸し結果 | 人以外のアクセス経路を管理していることを示すため |
| ログ確認手順 | ブロック時にどのテナントで証跡を確認するかを明確にするため |
特にグローバル企業では、地域拠点ごとに異なる例外を作り始めると、数か月後にポリシーが複雑化します。例外は「国・部門」ではなく、「外部テナントID」「対象ユーザーまたはグループ」「対象アプリ」「期限」で管理する方が、監査でも説明しやすくなります。
導入時のチェックリスト
本番導入前には、次の順序で確認すると手戻りを減らせます。
| フェーズ | チェック項目 |
|---|---|
| 設計 | 既定でブロックするか、段階導入するかを決めた |
| 棚卸し | 外部テナント、Microsoftアカウント、サービス プリンシパルを洗い出した |
| 例外設定 | 許可テナントと許可アプリを必要最小限にした |
| 適用方式 | Global Secure Access、企業プロキシ、Windows GPOのどれで適用するか決めた |
| 技術検証 | My Apps、Teams、SharePoint、OneDrive、Graph、PowerShellをテストした |
| ログ確認 | ユーザーとサービス プリンシパルのログ確認先を手順化した |
| 運用 | 例外申請、期限、承認者、棚卸しサイクルを決めた |
| 周知 | ヘルプデスク向けに想定エラーと案内文を用意した |
導入後は、いきなり全社展開せず、セキュリティ部門、IT部門、パイロットユーザー、開発・自動化ジョブを含む小さな範囲で検証します。特にサービス プリンシパルは、ユーザーから問い合わせが来ないまま夜間ジョブや監査連携が失敗することがあります。
まとめ：2026年4月更新後に管理者がやるべきこと
Microsoft Entra テナント制限 v2の2026年4月更新で最も重要なのは、サービス プリンシパルのサインインがTRv2でブロックされた場合のログ確認先が明確化されたことです。これは設定画面の大きな変更ではありませんが、インシデント調査、監査、SIEM設計に直接影響します。
security adminsとidentity teamsは、まず外部テナント利用とサービス プリンシパルを棚卸しし、既定ポリシーと例外ポリシーを分けて設計してください。compliance teamsは、許可理由、対象アプリ、ログ確認先、例外期限を証跡として残す運用を整えるべきです。
次に取るべき行動は明確です。自社のTRv2設定有無を確認し、サービス プリンシパルを含むテストケースを作成し、ログ確認手順を更新してください。Tenant Restrictions v2は、単なるブロック機能ではなく、外部ID利用を説明可能な統制に変えるための仕組みです。
コメント