概要
Microsoft Entra IDは、すべてのリソースを対象とし、1 つ以上のリソースの除外を含む条件付きアクセス ポリシーの強化された適用モデルをロールアウトしています。 この変更により、ベースライン スコープのみを要求するサインインは、他のリソース アクセスと同じ条件付きアクセス保護を受け取ります。
以前は、 すべてのリソース ポリシーにリソースの除外が存在する場合、ベースライン スコープはポリシーの適用から自動的に除外されていました。 この変更により、これらのスコープはディレクトリ アクセスとして評価され、ポリシーに除外がある場合でも条件付きアクセス ポリシーの対象になります。
技術的背景の詳細については、「 すべてのリソース ポリシーにリソースの除外がある場合の新しい条件付きアクセスの動作」を参照してください。
Important
ベースライン スコープの適用モデルのロールアウトは、2026 年 6 月 15 日に開始されます。
この適用更新プログラムは、Microsoftの Secure Future Initiative と多層防御投資に合わせて更新されます。 Microsoftでは、セキュリティ体制を改善するために、新しい適用モデルを採用することをお勧めします。 詳細については、「 今後の条件付きアクセスの変更: リソースの除外を含むポリシーの適用の強化」を参照してください。
ベースライン スコープとは
ベースライン スコープは、次の一連のスコープの総称です。
-
OpenID Connect (OIDC) スコープ:
email、offline_access、openid、profile -
ベースライン ディレクトリ スコープ:
User.Read、User.Read.All、User.ReadBasic.All、People.Read、People.Read.All、GroupMember.Read.All、Member.Read.Hidden
変更される内容
ロールアウト後、次のシナリオで、以前にアクセスが強制なしで付与された条件付きアクセスチャレンジ (MFA やデバイス コンプライアンスなど) がトリガーされる可能性があります。
- ベースライン スコープのみを要求するパブリック クライアント アプリケーション (デスクトップ アプリなど)。 たとえば、ユーザーは Visual Studio Code デスクトップ クライアントにサインインし、
openidスコープとprofileスコープを要求します。 もう 1 つの例は Azure CLI であり、User.Readのみを要求します。 - すべてのリソース ポリシーから除外され、ベースライン ディレクトリ スコープのみを要求する機密クライアント アプリケーション (Web アプリなど)。 たとえば、
User.ReadとPeople.Readのみを要求するポリシーから除外された Web アプリケーションなどです。
正確な課題は、すべてのリソースを対象とするポリシーで構成されているアクセス制御、またはリソースとしてWindows Azure Active Directory (Azure AD Graph とも呼ばれます) を明示的にターゲットとするアクセス制御によって異なります。
変更されない点
次のシナリオは、適用の変更の影響を受けません。 アプリケーションが既にこれらのシナリオのいずれかに一致している場合、またはこれを行うために更新できる場合、新しい適用によってアプリケーションの動作は変更されません。 これらのシナリオでは、従来の動作を保持することなく、アプリケーションを現在と同じように動作させ続けることができます。
- ベースライン スコープを超えるスコープを要求するアプリケーション。 アプリケーション (パブリックまたは機密) がベースライン スコープ (
Mail.Readなど) を超えるスコープを要求した場合、アプリケーションは既に条件付きアクセスの適用の対象であるため、この動作は変更されません。 パブリック クライアント アプリケーションの場合、ベースライン スコープ と 少なくとも 1 つの他のスコープを要求すると、適用の変更の下でアプリケーションが引き続き同じように動作することを意味します。 - OIDC スコープのみを要求する機密クライアント アプリケーション。 すべてのリソース ポリシーから除外され、OIDC スコープ (
openidやprofileなど) のみを要求する機密クライアント アプリケーションの場合、変更は必要ありません。 機密クライアント アプリケーションが現在、ベースライン ディレクトリ スコープ (User.Readなど) を要求している場合は、アプリケーション開発者と協力して、OIDC スコープを要求できるかどうかを評価します。 OIDC スコープは既にセキュリティで保護されていると見なされているため、この変更を行うと、アプリケーションの動作に影響を与えずにアプリケーションが動作し続けます。
影響を受けるユーザー
この変更は、次のすべての条件に該当する場合にテナントに影響します。
- すべてのリソースを対象とする条件付きアクセス ポリシーが 1 つ以上ある。
- これらのポリシーには、1 つ以上の リソース除外があります。
- テナント内のユーザーは、 ベースライン スコープのみを要求するアプリケーションを使用してサインインします。
ポリシーがリソースの除外なしですべてのリソースを対象としている場合、この変更はユーザーに影響しません。
実行する必要があること
次の表を使用して、アプリケーションに必要なアクションを確認します。
| アプリケーションの種類 | 所有権 | アクションが必要 |
|---|---|---|
| ベースライン スコープのみを要求するパブリック クライアント | テナント所有または ISV 所有 | これらのアプリケーションを条件付きアクセスの適用から除外する必要があるかどうかを確認します。 除外を維持するビジネス上の正当な理由がある場合は、「 カスタマイズ動作を使用して従来の動作を保持する」を参照してください。 |
| すべてのリソース ポリシーから除外された、ベースライン ディレクトリ スコープのみを要求する機密クライアント | テナント所有 | 除外がまだ必要かどうかを確認します。 アプリケーション開発者と協力して、基本的なユーザー情報のopenidなどのディレクトリ スコープではなく、アプリが OIDC スコープ (profile、User.Read など) を要求できるかどうかを評価します。 ロールアウト前に更新を完了できない場合は、「 カスタマイズ動作を使用して従来の動作を保持する」を参照してください。 |
| すべてのリソース ポリシーから除外された、ベースライン ディレクトリ スコープのみを要求する機密クライアント | ISVによって所有されている | 除外がまだ必要かどうかを確認します。 ISV と連携して、アプリケーションがディレクトリ スコープではなく OIDC スコープを要求できるかどうかを評価します。 ほとんどの場合、OIDC スコープは、これらのシナリオに必要な最小特権アクセスを提供します。 ISV が時間内に更新できない場合は、「 カスタマイズ動作を使用して従来の動作を保持する」を参照してください。 |
Important
テナントが所有するパブリック クライアント アプリケーションと機密クライアント アプリケーションの両方で、アプリケーションが条件付きアクセスの課題 (MFA やデバイスコンプライアンスなど) を処理できることを確認します。 そうでない場合は、アプリケーションの更新が必要になることがあります。 アプリケーションを適切に更新する方法については、 条件付きアクセス開発者向けガイダンス を参照してください。
ベースライン スコープを適用する方法を選択する
この強制変更は、ロールアウトの一環としてすべてのテナントに適用されます。 ベースライン スコープの設定を使用して、その効果を制御できます。 テナントでロールアウトが完了するのを待たずにすぐに適用を有効にしたり、ポリシー レベルでカスタマイズして特定のシナリオのレガシ動作を保持したり、準備ができるまで一時的にオプトアウトしたりできます。 ロールアウトは 2026 年 6 月 15 日に開始され、数週間にわたって段階的にロールアウトされます。
Tip
適用設定は、 ベースライン スコープの設定からいつでも更新できます。
強制を有効にする (推奨)
ロールアウトを開始する前に、強化された強制動作を有効にすることができます。 テスト テナントでこのオプションを使用して、アプリケーションとユーザーへの影響を確認します。
すべてのリソース ポリシーでアプリの除外を確認し、「この設定を使用するユーザー」セクションで説明されているシナリオと同様のシナリオを特定していない場合は、適用を有効にする準備ができました。
- Microsoft Entra 管理センターに、少なくとも条件付きアクセス管理者としてサインインします。
- 条件付きアクセスの [ベースライン スコープ] 設定 にアクセスします。 設定を表示するには、この直接リンクが必要です。
- [ 強制を有効にする] を選択します。
- 保存を選びます。
- もう一度 [強制を有効にする] を選択して、変更を確認します。
注
この設定により、すべての リソース ポリシーに対して更新された条件付きアクセスの動作がすぐに有効になり、除外されます。
その結果、以前は条件付きアクセスの適用の対象ではなかった一部のユーザー サインインが、ターゲット リソースとしてWindows Azure Active Directoryを使用して条件付きアクセスで評価および適用される可能性があります。
従来の動作に戻すには、 ベースライン スコープの設定 に戻り、[強制を 無効にする] を選択します。
動作をカスタマイズする
テナント全体ではなく特定のポリシーの適用を無効にする必要がある場合は、[ 動作のカスタマイズ ] オプションを使用します。 この方法では、構成したポリシーに対してのみ従来の動作が保持されますが、適用は他のすべての場所に適用されます。
この変更の影響を受ける可能性がある「 この設定を使用するユーザー 」セクションで説明されているようなビジネス クリティカルなシナリオを特定した場合は、動作をカスタマイズできます。 このオプションを使用すると、特定のポリシーの従来の動作を保持できます。
注
Microsoftでは、新しい適用モデルに合わせることをお勧めします。 [ 動作のカスタマイズ ] オプションは、特定のポリシーのレガシ動作を必要とする特定のシナリオがある場合にのみ使用します。
動作をカスタマイズするには、ベースライン スコープをターゲットにするようにカスタム アプリケーションを構成します。
- アプリケーションの作成: ベースライン スコープのカスタム ターゲット リソースとして機能するようにMicrosoft Entra IDで新しいアプリケーションを登録します。 アプリケーションをシングル テナント アプリケーションとして登録します。 アプリケーションの登録中に追加の構成は必要ありません。
- 関連するポリシーからアプリケーションを除外する: 従来の動作を保持する必要がある条件付きアクセス ポリシーで、ターゲット リソースからカスタム アプリケーションを除外します。
- [ベースライン スコープ設定 UX] でアプリケーションを選択します。 [ベースライン スコープの設定] に移動し、[ 動作のカスタマイズ] を選択し、[ 保存] を選択して、一覧からプレースホルダー アプリケーションを選択します。
これらの手順を完了すると、そのポリシーのカスタム プレースホルダー アプリケーションに対してベースライン スコープが評価されます。 プレースホルダー アプリケーションはポリシーから除外されるため、レガシ動作はそのポリシーに対してのみ保持されます。
カスタマイズ動作設定を使用するユーザー
この設定は、従来の動作を保持する必要がある特定のシナリオがある場合にのみ使用します。 たとえば、次のようなシナリオが考えられます。
- 準拠しているデバイス許可制御が必要なすべてのリソース ポリシー: アンマネージド デバイスからアクセスできる必要がある特定のアプリケーションがあります。
- アプリ保護ポリシー付与制御が必要なリソース ポリシー: Microsoft Intune SDK と統合されておらず、アプリ保護ポリシーを満たさないクライアント アプリケーションがあります。
- ブロック制御を持つすべてのリソース ポリシー: ブロック ポリシーから除外する必要がある特定のアプリケーションがあります。
- 準拠デバイスの要件から除外する必要があるパブリック クライアント: デバイス コンプライアンス許可制御の対象としてはならない特定のパブリック クライアント アプリケーションがあります。
注
以前のすべてのシナリオで、 すべてのリソース ポリシーにリソースの除外があり、クライアント アプリケーションがベースライン スコープのみに依存 している場合は 、サインインが条件付きアクセスの適用の対象とならずにアクセスが許可されていました。 適用の変更後は、サインインが条件付きアクセスの要件を満たした後にのみアクセスが許可されます。
カスタム ターゲット リソースを使用して影響を受けるアプリケーションを特定する
ベースライン スコープ設定を使用して、ロールアウト前に影響を受けるテナント内のアプリケーションを特定できます。 [強制を有効にする] オプションを選択した後、アプリケーションがベースライン スコープを要求するサインイン イベントでは、サインイン ログに条件付きアクセス対象ユーザーとしてカスタム アプリケーションが一覧表示されます。 詳細については、「 条件付きアクセスに関するサインインの問題のトラブルシューティング」を参照してください。
影響を受けるアプリケーションのクエリ
次のMicrosoft Graph クエリを使用して、ベースライン スコープのみを要求するアプリケーションを一覧表示します。
https://graph.microsoft.com/beta/auditLogs/signIns?$filter=createdDateTime ge 2026-05-26T00:00:00Z and createdDateTime lt 2026-05-27T00:00:00Z and conditionalAccessAudiences/any(a:a eq '<your-custom-app-id>')&$select=createdDateTime,appId,appDisplayName,userDisplayName,userPrincipalName,ipAddress,conditionalAccessStatus
<your-custom-app-id>をカスタム アプリケーションのアプリ ID に置き換えます。 必要に応じて、特定の時間範囲のタイムスタンプ値を変更します。
このクエリの結果は、複数の期間にわたって、ベースライン スコープのみを要求するクライアント アプリケーションの一覧を提供します。
強制を無効にする
Warning
[ベースライン スコープ] 設定の [強制を無効にする] オプションは推奨されません。
このオプションを選択すると、テナント内のすべてのポリシーの適用が無効になり、条件付きアクセスカバレッジにギャップが生じる可能性があります。
適用を無効にするか、動作をカスタマイズすることを選択した場合、組織は構成した動作を引き続き使用し、今後のロールアウトでは構成された動作をオーバーライドしません。 [ベースライン スコープ] 設定にアクセスすることで、いつでも構成を手動で更新できます。
ユーザー エクスペリエンス
クライアント アプリケーションが上記のスコープのみを要求するユーザー サインイン フローでは、ユーザーは条件付きアクセスチャレンジ (MFA やデバイス コンプライアンスなど) を受け取る可能性があります。 正確な課題は、すべてのリソース (リソースの除外ありまたは除外なし) を対象とするポリシーまたは AD Graph を明示的にターゲットとするポリシー Azure構成されているアクセス制御によって異なります。
次の例では、テナントに条件付きアクセス ポリシーがあり、次の詳細が含まれています。
- すべてのユーザーとすべてのリソースを対象とする
- 機密クライアント アプリケーションと Exchange Online のリソース除外
- MFA が許可コントロールとして構成されている
シナリオ例
| サンプル シナリオ | ユーザーへの影響 (→後) | 条件付きアクセスの評価 |
|---|---|---|
| ユーザーは Visual Studio Code デスクトップ クライアントにサインインし、openid とプロファイル スコープを要求します。 |
Before: ユーザーにMFAのプロンプトが表示されない After: ユーザーにMFAのプロンプトが表示される |
条件付きアクセスは、適用対象ユーザーとして Windows Azure Active Directory を使用して評価されるようになりました。 |
ユーザーは、 User.Readのみを要求する Azure CLI を使用してサインインします。 |
Before: ユーザーにMFAのプロンプトが表示されない After: ユーザーにMFAのプロンプトが表示される |
条件付きアクセスは、適用対象ユーザーとして Windows Azure Active Directory を使用して評価されるようになりました。 |
ユーザーは、 User.Read と People.Readのみを要求する機密クライアント アプリケーション (ポリシーから除外) を介してサインインします。 |
Before: ユーザーにMFAのプロンプトが表示されない After: ユーザーにMFAのプロンプトが表示される |
条件付きアクセスは、適用対象ユーザーとして Windows Azure Active Directory を使用して評価されるようになりました。 |
次の例に示すように、クライアント アプリケーションが前に示した範囲を超えるスコープを要求した場合の動作に変更はありません。
シナリオ例
| サンプル シナリオ | ユーザーへの影響 | 条件付きアクセスの評価 |
|---|---|---|
ユーザーは、offline_accessとSharePointアクセス (Files.Read) を要求する機密クライアント アプリケーション (ポリシーから除外) にサインインします。 |
動作に変更はありません | 条件付きアクセスは、SharePoint リソースに基づいて引き続き適用されます。 |
ユーザーが OneDrive デスクトップ同期クライアントにサインインします。 OneDriveはオフライン アクセスとExchange Onlineへのアクセスを要求します (Mail.Read)。 |
動作に変更はありません | Exchange Online はポリシーから除外されるため、条件付きアクセスは適用されません。 |
ほとんどのアプリケーションは、前述のスコープを超えてスコープを要求し、アプリケーションがポリシーから明示的に除外されていない限り、既に条件付きアクセスの適用の対象となります。 このような場合、動作に変更はありません。
条件付きアクセスチャレンジを処理できるように、以前に一覧表示されたスコープのみを要求するように意図的に設計され、条件付きアクセスチャレンジを処理するように設計されていないカスタム アプリケーションは、更新が必要になる場合があります。 実装の詳細については、 Microsoft 条件付きアクセス開発者向けガイダンス を参照してください。
FAQ
何もアクションを実行しないとどうなりますか?
適用は、2026 年 6 月 15 日から予定されているロールアウトの一部として自動的に適用されます。 ベースライン スコープの設定に変更を加えていない場合、適用は約数週間にわたって自動的に有効になります。 動作が既定になるため、適用後に ベースライン スコープの設定 に選択内容は表示されません。
以前に [強制の無効化 ] または [動作のカスタマイズ] を選択した場合、テナントは選択した構成を引き続き使用します。 いつでも完全な適用に切り替えることができます。
ロールアウトの前に強制を有効にするにはどうすればよいですか?
https://aka.ms/BaselineScopesSettingsUXに移動し、[強制を有効にする] と [保存] を選択します。 この設定により、すぐに改善された動作が適用されます。 元に戻すには、[ 強制を無効にする] を選択します。
ロールアウト後に従来の動作を保持するにはどうすればよいですか?
カスタマイズ動作を使用して、カスタム テナント所有アプリケーションをベースライン スコープのターゲット リソースとして割り当て、そのアプリケーションをすべてのリソース ポリシーから除外します。 詳細については、「 カスタマイズ動作を使用して従来の動作を保持する」を参照してください。
影響を受けるアプリケーションはどれですか?
ベースライン スコープのみを要求するクライアント アプリケーションにのみ注意が必要です。 ベースライン ( Mail.Read など) を超えるスコープを要求するアプリケーションは、既に条件付きアクセスの適用対象であり、この変更の影響を受けません。 ほとんどの組織では、 すべてのリソース ポリシーから明示的に除外されているアプリケーションを確認することをお勧めします。