Microsoft Entra IDの条件付きアクセスを運用している管理者が2026年4月更新でまず押さえるべき結論は、4月23日の差分は大規模な仕様変更というより、macOSとChrome周辺のドキュメント整理が中心という点です。ただし、4月1日の更新を含めて見ると、古いWindowsやSkype for Business関連の記載整理、ブラウザー・デバイス条件の見直し、リスク条件やデバイスフィルターの再確認が必要です。特にsecurity admins、identity teams、compliance teamsは、「Conditions」を単なる設定項目の一覧ではなく、誰に・どの端末で・どのリスク状態なら・どのアプリへアクセスを許可するかを決める判断材料として棚卸しする必要があります。
Microsoft Learnの該当ページは表示上「Last updated on 2026-04-01」となっています。一方、GitHubの履歴には2026年4月23日のコミットがあり、差分は「macOS行のChromeリンク調整」と「macOSのChrome補足記載の整理」が中心です。つまり、2026年4月23日更新を理由に即座に本番ポリシーを変更するというより、既存の条件付きアクセス設計が現在の公式記載とずれていないかを確認するのが現実的な対応です。(Microsoft Learn)
Microsoft EntraのConditional Access Conditionsとは何か
Microsoft Entraの条件付きアクセスは、ユーザー、デバイス、場所、アプリ、リスクなどのシグナルを組み合わせてアクセス判断を行う仕組みです。MicrosoftはConditional Accessを「Zero Trust policy engine」と説明しており、考え方としては「もしユーザーが特定のリソースへアクセスするなら、MFAや準拠デバイスなどの条件を満たす必要がある」というif-then型の制御です。(Microsoft Learn)
この中で「Conditions」は、ポリシーを発動させるための条件です。たとえば、次のような判断に使います。
- サインインリスクが高い場合だけMFAを要求する
- 管理対象外デバイスからSharePointへのアクセスをブロックする
- レガシ認証を使うクライアントをブロックする
- 特定のデバイスプラットフォームやブラウザー利用時だけ制御を強める
- Microsoft Purviewのインサイダーリスクをアクセス制御に反映する
重要なのは、Conditionsだけでは最終的な制御にならない点です。Conditionsで「どのサインインにポリシーを適用するか」を決め、Grant controlsやSession controlsで「ブロックする」「MFAを要求する」「準拠デバイスを要求する」といった動作を決めます。
2026年4月更新で何が変わったのか
今回の更新ポイントは、2026年4月23日の差分だけを見ると小さく見えます。しかし、4月1日の更新を含めると、運用資料や既存ポリシーの見直しに影響する項目があります。
| 確認ポイント | 2026年4月更新として見るべき内容 | 実務上の影響 |
|---|---|---|
| 2026年4月23日の差分 | macOSのサポートブラウザー表でChromeへのリンクがChrome supportセクションに整理され、macOS/Chrome補足の重複が調整された | macOSでChromeを使い、デバイスベースの条件付きアクセスを運用している組織は、Enterprise SSOプラグインやMicrosoft Single Sign On拡張機能の展開状況を確認する |
| 2026年4月1日の差分 | Windows 7/8.1、古いChromeレジストリ設定、Skype for Business関連の記載が削除・整理された | 古いOSや廃止済みサービスを前提にした運用手順書、例外ポリシー、問い合わせテンプレートを更新する |
| Conditions全体の整理 | Agent risk、User risk、Sign-in risk、Insider risk、Device platforms、Client apps、Filter for devices、Authentication flowsなどを扱う | 「場所＋MFA」だけの単純な設計から、リスク・デバイス・認証フローを含めた多層判断へ見直す |
| Device state | Device stateは非推奨で、Filter for devicesの利用が推奨されている | 旧来のDevice state条件に依存したポリシーを、trustTypeやisCompliantなどを使うデバイスフィルター設計へ移行する |
| Client apps | 新規作成ポリシーは、Client apps条件を構成しなくても既定で全クライアントアプリ種別に適用される | 「ブラウザーだけに効いているつもり」「モバイルアプリだけに効いているつもり」という誤解を避ける |
Microsoftの2026年4月1日コミットでは、条件付きアクセス関連の品質修正として、Windows 7/8.1参照の削除、Skype for Business行の削除、古いChromeレジストリキー記載の削除などが明記されています。(GitHub)
現在のConditionsで押さえるべき主要項目
Microsoft Learnの「Conditional Access: Conditions」では、条件付きアクセスの判断に使えるシグナルとして、リスク情報、ネットワークの場所、デバイス情報などが説明されています。2026年4月時点で、実務上特に重要なのは次の項目です。(Microsoft Learn)
| Condition | 使いどころ | 注意点 |
|---|---|---|
| Agent risk（プレビュー） | AIエージェントやエージェントIDのリスクをアクセス判断に組み込む | プレビュー機能のため、本番適用前に対象範囲と影響確認が必要 |
| User risk | アカウント侵害の可能性が高いユーザーに対して制御を強める | Microsoft Entra ID Protectionとの連携が前提になる |
| Sign-in risk | 普段と異なるサインイン、疑わしい認証要求に対してMFAなどを要求する | User riskとは別ポリシーで設計するのが基本 |
| Insider risk | Microsoft Purviewのリスクシグナルを条件付きアクセスに反映する | Purview側のデータガバナンス、リスク、コンプライアンス設計とセットで考える |
| Device platforms | Windows、macOS、iOS、Android、Linuxなどの端末種別で制御する | ユーザーエージェント文字列に基づくため、単独で信頼判定に使いすぎない |
| Locations | IPアドレス範囲や国・地域など、ネットワークベースの条件に使う | 「社内IPなら安全」と決め打ちせず、リスクやデバイス条件と組み合わせる |
| Client apps | ブラウザー、モバイルアプリ、デスクトップクライアント、レガシ認証を制御する | レガシ認証はMFAやデバイス状態を渡せないため、ブロック設計が重要 |
| Filter for devices | デバイスプロパティに基づいて対象端末を細かく含める・除外する | Device stateの代替として使う。Device stateと同じポリシー内では併用できない |
| Authentication flows（プレビュー） | デバイスコードフローや認証転送など、特定の認証フローを制御する | 共有デバイス、デジタルサイネージ、入力手段の少ない端末で特に確認が必要 |
4月23日更新で特に見るべきmacOSとChromeの運用
2026年4月23日のGitHub差分では、macOSのサポートブラウザー表におけるChromeのリンク先整理と、macOSでChromeを使う場合の補足記載の配置調整が行われています。差分自体は2行追加・4行削除の小規模なものですが、macOS端末でChromeを標準ブラウザーにしている組織では見落とせません。(GitHub)
Microsoft Learnでは、デバイスベースの条件付きアクセスを満たすブラウザーとして、Windows、Windows Server、iOS、Android、macOS、Linux Desktopごとに対応ブラウザーが整理されています。macOSではMicrosoft Edge、Chrome、Firefox 133以降、Safariが挙げられていますが、ChromeでSSOやデバイスベースの条件付きアクセスを成立させるには、Enterprise SSOプラグインやMicrosoft Single Sign On拡張機能の構成が重要になります。(Microsoft Learn)
macOSとChromeを使う環境では、次の点を確認してください。
| 確認項目 | 確認する理由 |
|---|---|
| Enterprise SSOプラグインがIntuneなどで正しく展開されているか | macOS上のSSOとデバイスベース条件付きアクセスの前提になる |
| ChromeにMicrosoft Single Sign On拡張機能が展開されているか | Chrome利用時にデバイスIDやSSO連携が期待通り動作しない可能性がある |
| プライベートモードやCookie無効化を許可していないか | Microsoft Learnでは、プライベートモードやCookie無効化によりデバイスチェックが失敗すると説明されている |
| Safari、Edge、Chrome、Firefoxで同じ結果になるか | ブラウザーごとに満たせる条件が異なる場合がある |
| 「承認済みクライアントアプリを必須にする」「アプリ保護ポリシーを必須にする」との組み合わせ | Safariなど一部ブラウザーでは、特定の要件を満たせないケースがある |
実務では、macOS利用者を一つのグループとして扱うのではなく、「macOS＋Edge」「macOS＋Chrome」「macOS＋Safari」のように、主要ブラウザー別にサインインログを確認するのが安全です。
Windows 7/8.1やSkype for Businessの名残を残さない
2026年4月1日の更新では、Windows 7/8.1に関する記載や、Skype for Business関連の行が削除・整理されています。これは、単にドキュメントが短くなったという話ではありません。古いOSや廃止済みサービスを前提にした例外ポリシーが残っている場合、セキュリティホールや監査上の説明不足につながります。(GitHub)
たとえば、次のような状態は見直し対象です。
| 残りがちな古い前提 | 起こり得る問題 | 見直し方 |
|---|---|---|
| 「Windows 7/8.1利用者向け例外」 | 退職者・未使用端末・古いグループが例外として残る | 対象ユーザーと端末を棚卸しし、不要なら例外を削除 |
| 「Skype for Business用の許可」 | 使っていないサービスのために広いアクセスが残る | サインインログで利用実績を確認し、不要な対象アプリや条件を削る |
| 古いChromeレジストリ設定を前提にした手順 | 現行OSや現行Chromeの管理方針とずれる | 現在のChrome Enterpriseポリシー、Intune配布、SSO拡張機能の方式に更新 |
| 「古いOfficeクライアントを許可」 | レガシ認証や基本認証を許す抜け道になる | モダン認証対応クライアントへ移行し、レガシ認証は原則ブロック |
条件付きアクセスの見直しでは、ポリシー本体だけでなく、運用手順書、申請フォーム、例外承認フロー、ヘルプデスク向けFAQも同時に更新する必要があります。
レガシ認証は「MFAを要求すれば安全」ではない
Client apps条件で特に重要なのが、レガシ認証クライアントの扱いです。Microsoft Learnでは、レガシ認証クライアントからのサインインはMFAをサポートせず、デバイス状態情報も渡せないため、MFAや準拠デバイスを要求するGrant controlではブロックされると説明されています。(Microsoft Learn)
つまり、レガシ認証対策では「MFAを必須にしたから大丈夫」では不十分です。基本方針は次のように考えるべきです。
| 方針 | 推奨度 | 理由 |
|---|---|---|
| レガシ認証を原則ブロックする | 高 | MFAやデバイス準拠を適用できないため |
| どうしても必要なアカウントだけ一時的に例外化する | 中 | 業務影響を避けつつ、期限付きで移行するため |
| レガシ認証を使う全ユーザーを広く除外する | 低 | 条件付きアクセスの抜け道になりやすい |
| サービスアカウントをユーザー向けポリシーだけで守る | 低 | サービスプリンシパルはユーザー対象ポリシーではブロックされない場合がある |
POP、IMAP、SMTP、EWS、古いOfficeクライアントなどが残っている場合は、Exchange Onlineやアプリ側のログも合わせて確認しましょう。特にグローバル企業では、地域拠点や買収企業で古いメールクライアントが残っていることがあります。
User riskとSign-in riskは同じポリシーに混ぜない
リスクベースの条件付きアクセスでは、User riskとSign-in riskを分けて考えることが重要です。Microsoft LearnのID Protectionリスクポリシーでは、Sign-in risk条件とUser risk条件を同じ条件付きアクセスポリシーに組み合わせず、それぞれ別ポリシーを作成するよう警告されています。(Microsoft Learn)
違いを簡単に整理すると、User riskは「このアカウント自体が侵害されている可能性」、Sign-in riskは「このサインイン試行が本人によるものではない可能性」に近い考え方です。
| リスク条件 | 典型的な用途 | 設計例 |
|---|---|---|
| User risk | 認証情報漏えい、アカウント侵害の疑い | 高リスクユーザーにリスク修復を要求する |
| Sign-in risk | 不審な場所、匿名IP、通常と異なるサインイン | 中または高リスクのサインインにMFAや強い認証を要求する |
実務では、次のような命名にしておくと監査やトラブルシュートがしやすくなります。
| ポリシー名の例 | 目的 |
|---|---|
CA-RISK-UserRisk-High-RequireRemediation | 高いUser riskにリスク修復を要求 |
CA-RISK-SignInRisk-MedHigh-RequireMFA | 中・高のSign-in riskにMFAを要求 |
CA-LEGACY-Block-AllUsers | レガシ認証を全ユーザーでブロック |
CA-DEVICE-RequireCompliant-SharePoint | SharePointアクセスに準拠デバイスを要求 |
Device platformsは便利だが、単独で信頼しすぎない
Device platforms条件では、Windows、macOS、Linux、iOS、Androidなどの端末種別を条件にできます。ただし、Microsoft Learnでは、条件付きアクセスがユーザーエージェント文字列などデバイスから提供される情報を使ってデバイスプラットフォームを識別し、その情報は変更可能で検証済みではないと説明されています。(Microsoft Learn)
そのため、Device platformsは次のように使うのが現実的です。
| 使い方 | 判断 |
|---|---|
| Intuneの準拠デバイスポリシーと組み合わせる | 推奨 |
| 未サポートのデバイスプラットフォームをブロックする | 推奨 |
| 「Windowsだから安全」と判断する | 非推奨 |
| ユーザーエージェントだけで特権アクセスを許可する | 非推奨 |
| Chrome OSや未管理端末を対象外にする条件として使う | 有効 |
特権管理者、財務部門、人事部門、ソースコード管理システムにアクセスする開発者などは、Device platformsだけでなく、準拠デバイス、認証強度、場所、リスク条件を組み合わせて設計するべきです。
Device stateからFilter for devicesへ移行する
Microsoft Learnでは、Device state条件は非推奨であり、以前Device stateで実現していたシナリオにはFilter for devicesを使うよう案内されています。また、Device stateとFilter for devicesは同じ条件付きアクセスポリシー内で併用できません。(Microsoft Learn)
Filter for devicesでは、デバイスプロパティを使って対象端末を細かく含めたり除外したりできます。たとえば、次のような設計に向いています。
| シナリオ | Filter for devicesの使い方 |
|---|---|
| 特権アクセスワークステーションだけを許可したい | デバイス名、拡張属性、準拠状態などで対象を絞る |
| ハイブリッド参加端末とEntra参加端末で条件を分けたい | trustTypeなどのプロパティを使って分岐する |
| 準拠デバイスだけに機密アプリを許可したい | isCompliantを使って対象を絞る |
| 一部の共有端末を除外したい | 除外条件としてデバイス属性を指定する |
移行時は、既存ポリシーをいきなり編集するより、新しいFilter for devicesベースのポリシーをReport-onlyで作り、サインインログで差分を確認してから切り替える方が安全です。
変更前に実施すべき確認手順
条件付きアクセスは強力ですが、設定ミスをすると管理者自身がロックアウトされたり、業務アプリが使えなくなったりします。Microsoft Learnでも、Report-only modeやWhat Ifツールを使った影響確認が案内されています。Report-only modeでは、ポリシーを強制せずに評価結果をサインインログなどで確認できます。(Microsoft Learn)
| 手順 | 実施内容 | 見るべきポイント |
|---|---|---|
| 既存ポリシーの棚卸し | 条件付きアクセスポリシーを一覧化する | 対象ユーザー、対象アプリ、Conditions、Grant controls、除外設定 |
| 古い前提の確認 | Windows 7/8.1、Skype for Business、古いOffice、レガシ認証の例外を探す | 実利用がない例外を削除候補にする |
| リスク条件の分離 | User riskとSign-in riskが同一ポリシーに混在していないか確認する | 混在している場合は別ポリシーへ分割する |
| ブラウザー別検証 | macOS、Windows、iOS、Androidで主要ブラウザーのサインインを確認する | Chrome、Edge、Safari、Firefoxでデバイス条件が満たされるか |
| What Ifでシミュレーション | 特定ユーザー、エージェントID、サービスプリンシパルの条件を試す | どのポリシーが適用されるか、なぜ適用されないか |
| Report-onlyで検証 | 新規・変更ポリシーをReport-onlyで一定期間運用する | 予期しないブロック、MFA要求、対象外ユーザー |
| 段階的に有効化 | パイロットグループから本番グループへ広げる | ヘルプデスク問い合わせ、失敗サインイン、業務影響 |
What Ifツールは、特定のユーザー、エージェントID、シングルテナントサービスプリンシパルに対して、どの条件付きアクセスポリシーが適用されるかをシミュレーションできます。ただし、Microsoft Teamsに対するポリシー評価でExchange Onlineなどのサービス依存関係まではテストしないと説明されているため、最終確認はサインインログやReport-onlyの結果と組み合わせて行う必要があります。(Microsoft Learn)
よくある失敗と回避策
条件付きアクセスのトラブルは、機能不足よりも設計・検証不足で起こることが多いです。特にグローバル組織では、地域、端末、認証方式、例外アカウントが複雑になりやすいため、次の失敗を避ける必要があります。
| 失敗しやすいポイント | 起こること | 回避策 |
|---|---|---|
| すべての管理者に厳しいポリシーを一気に適用する | 管理者がロックアウトされる | 緊急アクセスアカウントを除外し、定期的に利用確認する |
| レガシ認証をMFAで守れると思い込む | MFAが適用されず、想定外にブロックまたは許可される | レガシ認証は原則ブロックし、必要な例外は期限付きにする |
| User riskとSign-in riskを同じポリシーに入れる | 期待通りにリスク制御が発動しない | リスク条件ごとに別ポリシーを作成する |
| Device platformsだけで端末を信頼する | 偽装可能な情報に依存する | Intune準拠、デバイスフィルター、認証強度と組み合わせる |
| macOS/ChromeのSSO構成を確認しない | デバイスベース条件付きアクセスが失敗する | Enterprise SSOプラグインとSSO拡張機能の展開を確認する |
| Report-onlyのログを見ない | 影響確認をしたつもりで実態が分からない | サインインログ、Conditional Accessタブ、Report-onlyタブを確認する |
| 古い例外グループを放置する | 退職者や不要端末がアクセス可能なまま残る | 例外グループに所有者と有効期限を設定する |
MicrosoftのID Protectionリスクポリシーでは、ポリシー誤設定によるロックアウトを防ぐため、緊急アクセスまたはブレークグラスアカウントを除外することが推奨されています。(Microsoft Learn)
コンプライアンスチームが見るべき観点
compliance teamsにとって重要なのは、「条件付きアクセスを設定しているか」ではなく、「どのリスクに対して、どの条件で、どの制御を適用しているか」を説明できることです。
監査対応では、次のように整理すると説明しやすくなります。
| リスクシナリオ | Conditions | Controls | 証跡 |
|---|---|---|---|
| アカウント侵害の疑い | User risk | リスク修復、再認証、セッション取り消し | ID Protection、サインインログ |
| 不審なサインイン | Sign-in risk | MFA、認証強度、サインイン頻度 | Conditional Accessログ |
| 未管理端末からの機密データアクセス | Device platforms、Filter for devices | 準拠デバイス要求、ブロック | Intune準拠状態、サインインログ |
| 社外・国外からのアクセス | Locations | MFA、ブロック、セッション制御 | ネットワーク条件、Named locations |
| 内部不正リスク | Insider risk | ブロック、強い認証、利用規約同意 | Microsoft Purview、アクセスログ |
| レガシ認証利用 | Client apps | ブロック | Exchange Onlineログ、サインインログ |
グローバル読者向けに記事や社内標準を作る場合は、「日本拠点だけのネットワーク」や「国内勤務だけの前提」で書かないことも大切です。国・地域、子会社、買収企業、外部ユーザー、委託先、サービスアカウントの扱いを明記しておくと、運用の属人化を防げます。
2026年4月更新後に取るべき次のアクション
今回の更新を受けて、まず実施すべきことは本番ポリシーの即時変更ではありません。優先順位は、既存ポリシーと運用ドキュメントの棚卸しです。
最初に、条件付きアクセスポリシーのうち、Device platforms、Client apps、User risk、Sign-in risk、Filter for devicesを使っているものを抽出します。次に、Windows 7/8.1、Skype for Business、古いChrome設定、レガシ認証例外など、2026年4月時点の公式記載とずれている前提が残っていないか確認します。そのうえで、macOSとChromeを使うユーザー、特権管理者、機密データへアクセスする部門を優先してReport-onlyとWhat Ifで検証します。
Microsoft EntraのConditional Access Conditionsは、設定項目を増やすための機能ではなく、組織のアクセス判断をリスクに応じて細かくするための基盤です。2026年4月更新を機に、古い例外を減らし、リスク条件を分離し、デバイス条件を検証可能な形に寄せることで、セキュリティと業務継続性の両方を高められます。
コメント