<p>本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">Azure AD条件付きアクセス ポリシー：クラウドセキュリティの要</h1> <p>クラウド環境への移行が進む現代において、IDは新たなセキュリティ境界の中心となりつつあります。Microsoft Entra ID（旧 Azure AD）の<strong>条件付きアクセス ポリシー</strong>は、このIDベースのセキュリティを強化するための重要なツールです。これは、ユーザーがクラウドアプリケーションにアクセスしようとする際に、定義された条件に基づいてアクセスを許可、制限、またはブロックする「if-then」ステートメントとして機能します。 、クラウドアーキテクトの視点から、条件付きアクセス ポリシーのアーキテクチャ、具体的な設定手順、運用監視、セキュリティへの貢献、コスト、そしてよくある落とし穴について深く掘り下げて解説します。</p> <h2 class="wp-block-heading">アーキテクチャ</h2> <p>条件付きアクセス ポリシーは、アクセス要求の際に複数のシグナルを統合し、リアルタイムで意思決定を行います。その核となるアーキテクチャは以下の要素で構成されます[1]。</p> <ol class="wp-block-list"> <li><p><strong>割り当て (Assignments)</strong>:</p> <ul> <li><p><strong>ユーザーとグループ</strong>: ポリシーを適用する対象のユーザーまたはグループ。特定の管理者や緊急アクセスアカウントは除外することが推奨されます。</p></li> <li><p><strong>クラウドアプリまたはアクション</strong>: ポリシーを適用する特定のアプリケーション (例: SharePoint Online, Salesforce) やユーザーアクション (例: ユーザー登録、セキュリティ情報の登録)。</p></li> </ul></li> <li><p><strong>条件 (Conditions)</strong>:</p> <ul> <li><p><strong>デバイスプラットフォーム</strong>: iOS, Android, Windows, macOS などのOS。</p></li> <li><p><strong>場所</strong>: 特定のIPアドレス範囲 (信頼できる場所) からのアクセス、または特定の国からのアクセス。</p></li> <li><p><strong>クライアントアプリ</strong>: ブラウザ、モバイルアプリ、レガシー認証クライアントなど。</p></li> <li><p><strong>デバイスの状態</strong>: Entra ID 参加済み、ハイブリッド Entra ID 参加済み、準拠済みデバイスなど。</p></li> <li><p><strong>サインインリスク</strong>: Entra ID Identity Protection によって検出されたサインインの危険度 (P2ライセンスが必要)。</p></li> <li><p><strong>ユーザーリスク</strong>: Entra ID Identity Protection によって検出されたユーザーアカウントの危険度 (P2ライセンスが必要)。</p></li> <li><p><strong>デバイスのフィルター</strong>: 特定のデバイス属性に基づいてポリシーを適用 (P2ライセンスが必要)。</p></li> </ul></li> <li><p><strong>アクセス制御 (Access Controls)</strong>:</p> <ul> <li><p><strong>許可 (Grant)</strong>: アクセスを許可する際に、追加の要件を課します。</p> <ul> <li><p>多要素認証 (MFA) の要求</p></li> <li><p>デバイスを準拠としてマークする</p></li> <li><p>ハイブリッド Entra ID 参加済みデバイスの要求</p></li> <li><p>承認されたクライアントアプリの要求</p></li> <li><p>アプリ保護ポリシーの要求</p></li> </ul></li> <li><p><strong>セッション (Session)</strong>: クラウドアプリへのセッション中に特定の制御を適用します。</p> <ul> <li><p>条件付きアクセス アプリ制御 (Defender for Cloud Appsとの連携、P2ライセンスが必要)</p></li> <li><p>サインイン頻度</p></li> <li><p>永続的なブラウザセッション</p></li> <li><p>カスタム統一インターフェイスの要求</p></li> </ul></li> </ul></li> </ol> <h3 class="wp-block-heading">ポリシー評価フロー</h3> <p>条件付きアクセス ポリシーの評価は、ユーザーがアプリケーションにアクセスしようとしたときに開始され、Entra IDによって複数の条件が確認された後、最終的なアクセス決定が行われます。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> flowchart TD A["ユーザー"] --> |アクセス要求| B("クラウドアプリケーション") B --> |認証要求| C("Microsoft Entra ID") C --> |ポリシー評価要求| D{"条件付きアクセス ポリシーエンジン"} D --> |対象ユーザー/グループ| D1["割り当て: 誰が"] D --> |対象クラウドアプリ| D2["割り当て: 何に"] D --> |サインインの状況| D3["条件: どこから/どのようなデバイスで/リスクレベルは"] D1 & D2 & D3 --|すべての条件が一致| E{"アクセス制御の適用"} E --> F1["許可: MFAを要求"] E --> F2["許可: 準拠デバイスを要求"] E --> F3["セッション制御: クラウドアプリセキュリティ"] E --> G["ブロック: アクセス拒否"] F1 & F2 & F3 --> H["アクセス許可"] G --> I["アクセス拒否"] D --|条件不一致またはポリシー対象外| J["通常のアクセス"] H --> B I --> A J --> B </pre></div> <p>[1]</p> <h2 class="wp-block-heading">設定手順</h2> <p>ここでは、特定のセキュリティグループに属するユーザーがSharePoint Onlineにアクセスする際に、多要素認証 (MFA) を要求するポリシーをPowerShell (Microsoft Graph API) で設定する例を示します。この例は、2024年7月29日時点のMicrosoft Graph APIに基づいています。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># Microsoft Graph PowerShellモジュールのインストール (初回のみ) # Install-Module -Name Microsoft.Graph -Scope CurrentUser # 必要なスコープでMicrosoft Graphに接続 # Policy.ReadWrite.ConditionalAccess スコープは条件付きアクセスポリシーの読み書きに必要 # Group.Read.All と Application.Read.All はグループとアプリケーション情報の取得に必要 # Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess", "Group.Read.All", "Application.Read.All" # --- 変数定義 --- # ポリシーを適用するセキュリティグループの表示名 (例: 'SalesTeam') $groupDisplayName = "営業部ユーザー" # ポリシーを適用するクラウドアプリケーションの表示名 (例: 'Office 365 SharePoint Online') $targetAppDisplayName = "Office 365 SharePoint Online" # 作成するポリシーの名前 $policyName = "SharePointOnline_MFA_for_SalesTeam_ReportOnly" # ポリシーの初期状態: 'reportOnly' (監視のみ), 'enabled' (有効), 'disabled' (無効) # 最初は必ず 'reportOnly' で作成し、影響を確認することを強く推奨 $policyState = "reportOnly" # --- グループのObjectIDを取得 --- # 前提: 指定した表示名のグループがEntra IDに存在すること Write-Host "グループ '$groupDisplayName' のObjectIDを取得中..." $groupId = (Get-MgGroup -Filter "DisplayName eq '$groupDisplayName'").Id if (-not $groupId) { Write-Error "エラー: グループ '$groupDisplayName' が見つかりません。正確な表示名を確認してください。" exit } Write-Host "グループ '$groupDisplayName' のObjectID: $groupId" # --- アプリケーションのObjectIDを取得 (サービスプリンシパルとして) --- # 前提: 指定した表示名のアプリケーションがEntra IDに存在すること Write-Host "アプリケーション '$targetAppDisplayName' のObjectIDを取得中..." # Get-MgServicePrincipal を使用してアプリケーションのサービスプリンシパルIDを取得 $appId = (Get-MgServicePrincipal -Filter "DisplayName eq '$targetAppDisplayName'").Id if (-not $appId) { Write-Error "エラー: アプリケーション '$targetAppDisplayName' が見つかりません。正確な表示名を確認してください。" exit } Write-Host "アプリケーション '$targetAppDisplayName' のObjectID: $appId" # --- 条件付きアクセス ポリシーの定義 --- # ポリシーの条件部分 $conditions = @{ users = @{ includeGroups = @($groupId) # 特定のグループを対象に含める excludeGroups = @() # 例: 緊急アクセスアカウントのグループObjectIDを除外することも可能 } applications = @{ # 特定のサービスプリンシパルを対象に含める includeServicePrincipals = @($appId) } # すべてのクライアントアプリケーション (ブラウザ、モバイルアプリなど) を対象 clientApplications = @{ includeClientApplications = @("all") } # 場所やデバイスの状態など、他の条件を追加することも可能 # locations = @{ includeLocations = @("All") } # 例: 全ての場所からのアクセスを対象 } # ポリシーの許可コントロール部分 # "mfa" は多要素認証を意味する組み込みコントロール $grantControls = @{ operator = "OR" # 複数のコントロールがある場合、ANDまたはORで結合 builtInControls = @("mfa") # 多要素認証を必須とする } # --- ポリシーの作成 --- Write-Host "条件付きアクセス ポリシー '$policyName' を作成中 (状態: $policyState)..." try { New-MgIdentityConditionalAccessPolicy ` -DisplayName $policyName ` -State $policyState ` -Conditions $conditions ` -GrantControls $grantControls Write-Host "条件付きアクセス ポリシー '$policyName' を正常に作成しました。" Write-Host "現在の状態は '$policyState' (レポート専用モード) です。Azure Portalのサインインログで影響を確認してください。" Write-Host "問題がないことを確認した後、'state' を 'enabled' に変更してポリシーを有効化できます。" } catch { Write-Error "ポリシーの作成中にエラーが発生しました: $($_.Exception.Message)" } # --- ポリシーの有効化 (テスト後) --- # テストが完了し、ポリシーを有効化する場合は、以下の手順を実行 # $policyToEnable = Get-MgIdentityConditionalAccessPolicy -Filter "DisplayName eq '$policyName'" # Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyToEnable.Id -State "enabled" </pre> </div> <p>このスクリプトは、ポリシーを最初に「レポート専用モード (reportOnly)」で作成します。これは、ポリシーが適用された場合にどのような影響があるかを、実際のアクセスをブロックせずにサインインログで確認できるため、非常に重要なベストプラクティスです[6]。</p> <h2 class="wp-block-heading">運用監視</h2> <p>条件付きアクセス ポリシーの適切な運用には、継続的な監視と評価が不可欠です。</p> <ul class="wp-block-list"> <li><p><strong>サインインログ</strong>: Microsoft Entra ID のサインインログは、各認証要求に対してどの条件付きアクセス ポリシーが適用されたか、そしてその結果（アクセス許可、アクセス拒否）を詳細に記録します。ログの詳細の「条件付きアクセス」タブでポリシー評価結果を確認できます[5]。</p></li> <li><p><strong>条件付きアクセスに関する分析情報とレポート</strong>: Azure Portalからアクセスできるこのワークブックは、過去のサインインデータに基づいて条件付きアクセス ポリシーの影響を可視化します。これにより、有効化前の「レポート専用モード」での影響評価や、既存ポリシーの効果測定が容易になります[5]。</p></li> <li><p><strong>Azure Monitor と Log Analytics</strong>: サインインログをLog Analyticsワークスペースにルーティングすることで、カスタムクエリやダッシュボードの作成、特定のアラート条件（例: 多数のアクセス拒否イベント）に基づいた通知設定が可能になります。これにより、異常なアクティビティやポリシーの意図しない影響を迅速に検知できます。</p></li> <li><p><strong>「What If」ツール</strong>: ポリシーを有効化する前に、特定のユーザー、アプリケーション、条件でポリシーをシミュレートし、その結果を予測できるツールです。これにより、意図しないロックアウトを防ぎ、ポリシーの動作を正確に理解するのに役立ちます。</p></li> </ul> <h2 class="wp-block-heading">セキュリティ</h2> <p>条件付きアクセス ポリシーは、アイデンティティとアクセス管理のセキュリティにおいて中心的な役割を果たします。</p> <ul class="wp-block-list"> <li><p><strong>アイデンティティと権限境界</strong>: Microsoft Entra ID は、組織のIDを一元管理するクラウドベースのディレクトリサービスであり、条件付きアクセスはそのIDのアクセス制御層として機能します。ユーザー、グループ、アプリケーションといったアイデンティティに対して、アクセスを許可するかどうか、またどのような条件で許可するかを決定することで、権限の境界を細かく定義します。</p></li> <li><p><strong>多要素認証 (MFA) の強制</strong>: 最も一般的な用途の一つは、MFAを強制することです。MFAは、認証の最も効果的な手段の一つであり、条件付きアクセスにより、特定の状況（例: 信頼できない場所からのアクセス、管理者アカウントのサインイン）でのみMFAを要求するといった柔軟なポリシー設計が可能です。</p></li> <li><p><strong>Entra ID Identity Protectionとの統合</strong>: Microsoft Entra ID P2ライセンスが必要ですが、Identity Protectionが検出するユーザーリスク（例: 流出した認証情報）やサインインリスク（例: 通常とは異なる場所からのサインイン）を条件としてポリシーに組み込むことで、リスクベースの適応型アクセス制御を実現できます。これにより、リスクが高いと判断された場合にMFAを強制したり、アクセスをブロックしたりできます[1]。</p></li> <li><p><strong>Defender for Cloud Apps (旧 MCAS) との連携</strong>: Microsoft Entra ID P2ライセンスが必要ですが、Defender for Cloud Appsと連携することで、セッション中にリアルタイムで活動を監視し、ファイルダウンロードの制限やコピー＆ペーストの禁止など、詳細なセッション制御を適用できます。これにより、データ漏洩のリスクを低減します[1]。</p></li> <li><p><strong>緊急アクセスアカウント (ブレークグラスアカウント)</strong>: 災害時や条件付きアクセス ポリシーの誤設定によるロックアウト時に備え、すべての条件付きアクセス ポリシーから除外された緊急アクセスアカウントを少なくとも2つ作成し、厳重に管理することが必須です[6]。</p></li> </ul> <h2 class="wp-block-heading">コスト</h2> <p>条件付きアクセス ポリシーの利用には、主にMicrosoft Entra IDのライセンス費用が関係します。</p> <ul class="wp-block-list"> <li><p><strong>Microsoft Entra ID P1 ライセンス</strong>: 条件付きアクセス ポリシーの基本的な機能（MFAの強制、デバイスの状態、場所などに基づくポリシー）を利用するためには、Microsoft Entra ID P1ライセンスが必要です。これはMicrosoft 365 E3などのスイートに含まれています。</p></li> <li><p><strong>Microsoft Entra ID P2 ライセンス</strong>: 高度な機能を利用するにはP2ライセンスが必要です。これには、Entra ID Identity Protectionとの連携（ユーザーリスク、サインインリスクの条件）、デバイスのフィルター、Defender for Cloud Appsとの連携によるセッション制御などが含まれます。Microsoft 365 E5などのスイートに含まれています[3]。</p></li> <li><p><strong>Azure Monitor / Log Analyticsのコスト</strong>: 運用監視のためにサインインログをLog Analyticsワークスペースに送信する場合、ログの取り込み量と保持期間に応じてコストが発生します。ログの保持期間を組織のコンプライアンス要件に合わせて適切に設定し、不要なログをフィルタリングすることでコストを最適化できます。</p></li> </ul> <h2 class="wp-block-heading">落とし穴</h2> <p>条件付きアクセス ポリシーは強力なツールですが、不適切な設定は深刻な問題を引き起こす可能性があります。</p> <ul class="wp-block-list"> <li><p><strong>管理者のロックアウト</strong>: 最も一般的な落とし穴の一つです。すべてのユーザー（特に管理者）を対象とするポリシーを作成し、特定の条件（例: MFA）を強制すると、その条件を満たせない場合に管理者自身がシステムからロックアウトされる可能性があります。緊急アクセスアカウントの準備と、ポリシーからの除外が必須です[6]。</p></li> <li><p><strong>「レポート専用モード」の不使用</strong>: 新しいポリシーをいきなり「有効 (enabled)」モードで展開すると、意図しない影響（ユーザーのアクセス拒否、ビジネス中断）が発生するリスクがあります。必ず「レポート専用モード (reportOnly)」で数日から数週間にわたり評価し、影響範囲を正確に把握してから有効化することが推奨されます[6]。</p></li> <li><p><strong>除外設定の不備</strong>: 緊急アクセスアカウントだけでなく、サービスアカウント（例: 同期ツール、自動化スクリプト）も条件付きアクセスの対象から除外する必要がある場合があります。これらのアカウントはMFAなどの対話型認証ができないことが多いため、ポリシーの対象に含めると機能停止を招く可能性があります。</p></li> <li><p><strong>ポリシーの競合と評価順序</strong>: 複数のポリシーが存在する場合、Entra IDはすべてのポリシーを評価し、ブロックポリシーがあればアクセスを拒否します。許可ポリシーは、すべての必須コントロールが満たされた場合にのみアクセスを許可します。この評価ロジックを理解せずにポリシーを作成すると、意図しない結果につながることがあります。</p></li> <li><p><strong>テスト環境での検証不足</strong>: 可能であれば、実稼働環境に展開する前に、代表的なユーザーとデバイスを持つテスト環境で徹底的にポリシーを検証することが望ましいです。</p></li> </ul> <h2 class="wp-block-heading">まとめ</h2> <p>Microsoft Entra IDの条件付きアクセス ポリシーは、現代のクラウドセキュリティ戦略において不可欠な要素です。適切な設計と運用により、企業はセキュリティ体制を大幅に強化し、データ漏洩や不正アクセスから組織を保護できます。</p> <p>本記事で解説したアーキテクチャ、設定手順、運用監視、セキュリティの考慮事項、コスト、そして落とし穴を理解し、2024年7月29日時点の最新情報を踏まえたベストプラクティスを適用することで、柔軟かつ堅牢なアクセス制御を実現できるでしょう。常に「レポート専用モード」でのテストを忘れず、組織のニーズに合わせた最適なポリシーを構築してください。</p> <hr/> <p><strong>参考文献:</strong> [1] Microsoft Learn. “Azure AD の条件付きアクセスとは”. 最終更新日: 2024年7月12日. <a href="https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/overview">https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/overview</a> [2] Microsoft Learn. “Azure Active Directory の条件付きアクセス ポリシーの一般的なコンポーネント”. 最終更新日: 2024年7月12日. <a href="https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/concept-conditional-access-components">https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/concept-conditional-access-components</a> [3] Microsoft Learn. “Azure AD の条件付きアクセスとは – ライセンスの要件”. 最終更新日: 2024年7月12日. <a href="https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/overview#license-requirements">https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/overview#license-requirements</a> [4] Microsoft Learn. “conditionalAccessPolicy resource type”. 最終更新日: 2024年6月14日. <a href="https://learn.microsoft.com/ja-jp/graph/api/resources/conditionalaccesspolicy?view=graph-rest-1.0">https://learn.microsoft.com/ja-jp/graph/api/resources/conditionalaccesspolicy?view=graph-rest-1.0</a> [5] Microsoft Learn. “条件付きアクセスに関する分析情報とレポートを使用して影響を判断する”. 最終更新日: 2024年5月10日. <a href="https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/howto-conditional-access-insights-reporting">https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/howto-conditional-access-insights-reporting</a> [6] Microsoft Learn. “条件付きアクセスのベスト プラクティス”. 最終更新日: 2024年7月12日. <a href="https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/concept-best-practices">https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/concept-best-practices</a></p>

flowchart TD
    A["ユーザー"] --> |アクセス要求| B("クラウドアプリケーション")
    B --> |認証要求| C("Microsoft Entra ID")
    C --> |ポリシー評価要求| D{"条件付きアクセス ポリシーエンジン"}
    D --> |対象ユーザー/グループ| D1["割り当て: 誰が"]
    D --> |対象クラウドアプリ| D2["割り当て: 何に"]
    D --> |サインインの状況| D3["条件: どこから/どのようなデバイスで/リスクレベルは"]
    D1 & D2 & D3 --|すべての条件が一致| E{"アクセス制御の適用"}
    E --> F1["許可: MFAを要求"]
    E --> F2["許可: 準拠デバイスを要求"]
    E --> F3["セッション制御: クラウドアプリセキュリティ"]
    E --> G["ブロック: アクセス拒否"]
    F1 & F2 & F3 --> H["アクセス許可"]
    G --> I["アクセス拒否"]
    D --|条件不一致またはポリシー対象外| J["通常のアクセス"]
    H --> B
    I --> A
    J --> B

# Microsoft Graph PowerShellモジュールのインストール (初回のみ)


# Install-Module -Name Microsoft.Graph -Scope CurrentUser

# 必要なスコープでMicrosoft Graphに接続


# Policy.ReadWrite.ConditionalAccess スコープは条件付きアクセスポリシーの読み書きに必要


# Group.Read.All と Application.Read.All はグループとアプリケーション情報の取得に必要


# Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess", "Group.Read.All", "Application.Read.All"

# --- 変数定義 ---


# ポリシーを適用するセキュリティグループの表示名 (例: 'SalesTeam')

$groupDisplayName = "営業部ユーザー" 

# ポリシーを適用するクラウドアプリケーションの表示名 (例: 'Office 365 SharePoint Online')

$targetAppDisplayName = "Office 365 SharePoint Online" 

# 作成するポリシーの名前

$policyName = "SharePointOnline_MFA_for_SalesTeam_ReportOnly"

# ポリシーの初期状態: 'reportOnly' (監視のみ), 'enabled' (有効), 'disabled' (無効)


# 最初は必ず 'reportOnly' で作成し、影響を確認することを強く推奨

$policyState = "reportOnly" 

# --- グループのObjectIDを取得 ---


# 前提: 指定した表示名のグループがEntra IDに存在すること

Write-Host "グループ '$groupDisplayName' のObjectIDを取得中..."
$groupId = (Get-MgGroup -Filter "DisplayName eq '$groupDisplayName'").Id
if (-not $groupId) {
    Write-Error "エラー: グループ '$groupDisplayName' が見つかりません。正確な表示名を確認してください。"
    exit
}
Write-Host "グループ '$groupDisplayName' のObjectID: $groupId"

# --- アプリケーションのObjectIDを取得 (サービスプリンシパルとして) ---


# 前提: 指定した表示名のアプリケーションがEntra IDに存在すること

Write-Host "アプリケーション '$targetAppDisplayName' のObjectIDを取得中..."

# Get-MgServicePrincipal を使用してアプリケーションのサービスプリンシパルIDを取得

$appId = (Get-MgServicePrincipal -Filter "DisplayName eq '$targetAppDisplayName'").Id
if (-not $appId) {
    Write-Error "エラー: アプリケーション '$targetAppDisplayName' が見つかりません。正確な表示名を確認してください。"
    exit
}
Write-Host "アプリケーション '$targetAppDisplayName' のObjectID: $appId"

# --- 条件付きアクセス ポリシーの定義 ---


# ポリシーの条件部分

$conditions = @{
    users = @{
        includeGroups = @($groupId) # 特定のグループを対象に含める
        excludeGroups = @()          # 例: 緊急アクセスアカウントのグループObjectIDを除外することも可能
    }
    applications = @{

        # 特定のサービスプリンシパルを対象に含める

        includeServicePrincipals = @($appId) 
    }

    # すべてのクライアントアプリケーション (ブラウザ、モバイルアプリなど) を対象

    clientApplications = @{
        includeClientApplications = @("all")
    }

    # 場所やデバイスの状態など、他の条件を追加することも可能


    # locations = @{ includeLocations = @("All") } # 例: 全ての場所からのアクセスを対象

}

# ポリシーの許可コントロール部分


# "mfa" は多要素認証を意味する組み込みコントロール

$grantControls = @{
    operator = "OR" # 複数のコントロールがある場合、ANDまたはORで結合
    builtInControls = @("mfa") # 多要素認証を必須とする
}

# --- ポリシーの作成 ---

Write-Host "条件付きアクセス ポリシー '$policyName' を作成中 (状態: $policyState)..."
try {
    New-MgIdentityConditionalAccessPolicy `
        -DisplayName $policyName `
        -State $policyState `
        -Conditions $conditions `
        -GrantControls $grantControls

    Write-Host "条件付きアクセス ポリシー '$policyName' を正常に作成しました。"
    Write-Host "現在の状態は '$policyState' (レポート専用モード) です。Azure Portalのサインインログで影響を確認してください。"
    Write-Host "問題がないことを確認した後、'state' を 'enabled' に変更してポリシーを有効化できます。"

} catch {
    Write-Error "ポリシーの作成中にエラーが発生しました: $($_.Exception.Message)"
}

# --- ポリシーの有効化 (テスト後) ---


# テストが完了し、ポリシーを有効化する場合は、以下の手順を実行


# $policyToEnable = Get-MgIdentityConditionalAccessPolicy -Filter "DisplayName eq '$policyName'"


# Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyToEnable.Id -State "enabled"