第1回 問題集（全般）

正解: C. C. Microsoft Entra登録済み（Registered）

正解の根拠・詳細解説

Microsoft Entra 登録済み（Entra Registered）は BYOD（私物デバイス）を想定した参加形態で、デバイス自体は個人のアカウントやローカルアカウントで運用したまま、「職場または学校アカウント」を追加する形で組織との関連付けだけを行う。このため組織側が行使できるのは条件付きアクセスによるアクセス制御、コンプライアンス評価、アプリ保護ポリシー（MAM）といった限定的な管理にとどまり、デバイス全体のワイプや詳細な OS 設定の強制まではできない。①Entra 参加済みは組織所有デバイスを職場アカウントでサインインさせるクラウドネイティブな形態、②Entra ハイブリッド参加済みはオンプレミス AD 参加を維持したまま Entra ID にも登録する形態で、いずれも組織所有が前提のため完全な管理が可能。D のローカル AD 参加のみではクラウド側にデバイスオブジェクトが存在せず、条件付きアクセスの対象にできない点にも注意する。

正解: B. B. Microsoft Entraハイブリッド参加済み

正解の根拠・詳細解説

Microsoft Entra ハイブリッド参加済み（Hybrid Entra Join）は、オンプレミス Active Directory ドメインに参加したデバイスを、同時に Entra ID 側にもデバイスオブジェクトとして登録する構成である。仕組みとしては Entra Connect によるオンプレミス AD と Entra ID の同期が前提となり、AD の構成パーティションに書き込まれるサービス接続ポイント（SCP）をデバイスが参照して自動的にデバイス登録を行う。これにより、既存のグループポリシーやドメイン認証の資産を維持したまま、条件付きアクセス・Intune による MDM 管理・シームレス SSO といったクラウド機能を併用できる。A の Entra 参加済みはオンプレミス AD に一切依存しないクラウド専用の形態であり最終形としては望ましいが、AD 依存の業務アプリやログオンスクリプトが残る環境では、段階的にハイブリッド参加を経由するのが実務上の定石となる。

正解: B. B. 動的グループ（ダイナミックグループ）

正解の根拠・詳細解説

動的グループ（ダイナミックグループ）は、メンバーを手動で追加するのではなく、属性に対するメンバーシップ規則を評価してメンバーを自動的に増減させる Entra ID の機能である。デバイスの動的グループでは deviceOwnership（Company / Personal）、deviceOSType、deviceOSVersion、deviceCategory、enrollmentProfileName などの属性を規則式に使え、たとえば「会社所有の Windows デバイスだけに更新リングを割り当てる」といった運用が、登録のたびに管理者が手を動かさなくても成立する。注意点として、①動的グループの利用には Entra ID P1 以上のライセンスが必要、②規則の再評価は即時ではなく反映までにタイムラグがあるため、登録直後にポリシーが当たらないという問い合わせの原因になりやすい、③1 つの動的グループにユーザーとデバイスを混在させることはできない。A の静的グループは手動割り当てで、対象が頻繁に入れ替わる環境では管理負荷が高くなる。

正解: A. A. Microsoft Entra IDとIntuneのMDM自動登録設定の連携

正解の根拠・詳細解説

Windows デバイスの自動登録は、Microsoft Entra 管理センターの「モビリティ（MDM および MAM）」で Microsoft Intune を選び、MDM ユーザースコープを対象ユーザーに割り当てることで有効になる。この設定があると、デバイスが Entra 参加済みまたは Entra ハイブリッド参加済みになったタイミングで MDM 登録が呼び出され、ユーザーがポータル サイトから手動登録しなくても自動的に Intune に登録される。前提としてユーザーに Intune のライセンスが割り当てられていること、自動登録には Entra ID P1 以上が必要であることも押さえておきたい。B の BitLocker 有効化や C のローカル管理者アカウント作成は、登録後に構成プロファイルやエンドポイント セキュリティで設定する対象であって前提条件ではなく、D の Windows Autopatch は更新管理のサービスで登録の可否には関与しない。自動登録が始まらない場合は、まず MDM ユーザースコープの割り当て範囲とライセンスを確認するのが定石。

正解: C. C. Company Portalアプリを使ったユーザー登録

正解の根拠・詳細解説

個人所有（BYOD）の iOS/iPadOS デバイスは、ユーザー自身が App Store からポータル サイト（Company Portal）アプリを入手し、職場アカウントでサインインして管理プロファイルを受け入れる「ユーザー主導の登録」が標準となる。私物端末を組織が一方的に登録することはできないため、ユーザーの同意を伴うこの方式が前提になる。管理者側の必須準備として Intune に Apple MDM プッシュ証明書（APNs 証明書）を構成しておく必要があり、これが未設定または期限切れだと iOS デバイスの登録は一切できない。この証明書は年 1 回の更新が必要で、更新漏れによる登録停止は実務で頻出するトラブルである。B の Apple Business Manager による自動デバイス登録（ADE）や A の Apple Configurator は、組織が購入・所有するデバイスをゼロタッチまたは有線接続で一括登録するための方式であり、私物端末には適用できない。

正解: A. A. フルマネージド（Fully Managed）

正解の根拠・詳細解説

Android Enterprise のフルマネージド（Fully Managed）は COBO（Corporate-Owned, Business-Only）に相当する登録形態で、デバイスを工場出荷状態からプロビジョニングし、個人領域を持たせずデバイス全体を Intune の管理下に置く。アプリのインストール可否、各種設定の強制、デバイス全体のワイプまで組織が制御できるため、業務専用として配布する社用スマートフォンに適する。①C のデディケイテッドは COSU に相当し、受付端末やサイネージのように単一目的で共用される端末向けで、通常は個人ユーザーに紐づけずキオスクとして運用する、②B の個人所有 Work Profile は私物端末上に業務用コンテナだけを作る BYOD 向けで、個人領域は組織から不可視、③D のレガシー Device Administrator は Google が非推奨とした旧来の管理方式で新規採用は避けるべき。「会社所有かつ業務専用でデバイス全体を管理したい」という要件であればフルマネージドが正解になる。

正解: A. A. デディケイテッド（Dedicated）

正解の根拠・詳細解説

Android Enterprise のデディケイテッド（Dedicated、COSU: Corporate-Owned Single-Use）は、受付端末・デジタルサイネージ・在庫スキャナのように、特定の個人に紐づかず単一の目的で使われる共用デバイス向けに設計された登録形態である。Intune の構成プロファイルで単一アプリまたはマルチアプリのキオスクモードを設定し、ホーム画面に表示するアプリを限定して、それ以外の操作や設定変更をユーザーが行えないようロックダウンできる。プロビジョニングは QR コード・NFC・ゼロタッチ登録などで行い、ユーザーがサインインしなくても運用できる点がフルマネージドとの実務上の大きな違いになる。B の Work Profile は私物端末に業務コンテナを作る BYOD 向け、C のフルマネージドは個人が占有する社用端末向けで、いずれも不特定多数が触る共用キオスク用途には適さない。

正解: A. A. フルマネージド + Work Profile（corporate-owned work profile）

正解の根拠・詳細解説

corporate-owned work profile（企業所有の職場プロファイル）は COPE（Corporate-Owned, Personally-Enabled）モデルに対応する Android Enterprise の登録形態で、会社が所有・配布する端末上に業務用の職場プロファイルを作成し、業務データと個人データをコンテナで分離する。組織は職場プロファイル内のアプリとデータを完全に管理でき、加えてデバイス全体に対してもパスコード要件や工場出荷時リセットといった一定のポリシーを適用できる。一方で個人プロファイル内のアプリやデータには踏み込めないよう設計されているため、社用端末の私的利用を認めつつ従業員のプライバシーを保つ運用が成立する。D の BYOD Work Profile は私物端末が前提でデバイス全体への制御が効かず、C のデディケイテッドは共用のキオスク用途、B の Device Administrator は非推奨のレガシー方式であるため、いずれも COPE の要件を満たさない。

正解: A. A. Apple Business Manager（ABM）

正解の根拠・詳細解説

組織所有の macOS／iOS デバイスをゼロタッチで登録するには、Apple Business Manager（ABM、教育機関では Apple School Manager）と Intune を連携させる。手順は、①Intune で Apple MDM プッシュ証明書を構成する、②ABM 側で MDM サーバー（トークン）を作成し Intune に取り込む、③ABM で購入したデバイスをその MDM サーバーへ割り当てる、④Intune で登録プロファイルを作成してデバイスに割り当てる、という流れになる。これにより、開封して初期セットアップ（セットアップ アシスタント）を開始した時点で自動的に Intune に登録され、監視（Supervised）モードとなって管理プロファイルの削除を禁止することもできる。C の Apple Developer Program や D の TestFlight は自社アプリの開発・配布のための仕組みでデバイス登録には関与しない。ABM のトークンには有効期限があり、失効するとデバイス同期と新規登録が止まる点に注意する。

正解: A. A. 登録可能なデバイスプラットフォームの制限

正解の根拠・詳細解説

Intune の登録制限（enrollment restrictions）は、どのようなデバイスの登録を許可するかを事前に定義する機能で、大きく「デバイスの種類の制限」と「デバイスの制限数」の 2 種類がある。前者では iOS/iPadOS・Android（Work Profile やフルマネージドなど方式単位）・Windows・macOS といったプラットフォーム単位の許可／ブロック、最小・最大 OS バージョンの指定、個人所有デバイスのブロックなどを設定でき、後者では 1 ユーザーあたりに登録できるデバイス台数の上限を設ける。これにより、サポート対象外の古い OS や私物端末が管理下に流入するのを未然に防げる。B のライセンス自動更新や C の条件付きアクセスポリシーの作成は Entra ID 側の機能であり、D の BitLocker 回復キーの保存先はディスク暗号化ポリシーで扱う設定で、いずれも登録制限の守備範囲ではない。

正解: A. A. 登録ログ（エラーコード）

正解の根拠・詳細解説

Intune の登録失敗を調査する際は、まず Intune 管理センターの「トラブルシューティング＋サポート」で対象ユーザーを指定し、登録関連のエラーとエラーコードを確認するのが出発点となる。エラーコードから切り分けることで、①ユーザーに Intune ライセンスが割り当てられていない、②登録制限でプラットフォームや OS バージョン、個人所有デバイスがブロックされている、③1 ユーザーあたりの登録台数上限に達している、④Apple MDM プッシュ証明書や ABM トークンの期限切れ、⑤MDM ユーザースコープの割り当て漏れ、といった典型的な原因のどれに当たるかを短時間で特定できる。推測でデバイスを初期化したり再登録を繰り返したりする前に、まずログとエラーコードで事実を押さえるという順序が重要である。B の Wi-Fi パスワードや C のメールボックス容量、D のライセンス購入履歴は登録の成否とは無関係。

正解: A. A. 準拠していないデバイスからのアクセスをブロックまたは制限する

正解の根拠・詳細解説

条件付きアクセス（Conditional Access）で「デバイスは準拠としてマーク済みである必要がある」という許可条件を設定すると、Intune がコンプライアンスポリシーに基づいて評価した準拠状態（準拠／非準拠）が Entra ID に渡され、その結果がサインイン時のアクセス可否判断に使われる。これにより、暗号化されていない、OS バージョンが古い、脱獄・root 化されている、Defender for Endpoint のリスクレベルが高いといったデバイスから Exchange Online や SharePoint Online へアクセスすることをブロックまたは制限できる。重要なのは、Intune のコンプライアンスポリシー単体では「準拠していない」という状態が記録されるだけで実際のアクセス遮断は起きず、条件付きアクセスと組み合わせて初めて強制力が生まれるという点である。設計時は緊急用アカウントを除外し、レポート専用モードで影響を事前検証してから有効化するのが実務上の鉄則。

正解: A. A. パスワードレスの生体認証・PIN認証によるサインインを実現する

正解の根拠・詳細解説

Windows Hello for Business は、パスワードそのものをネットワークに流す従来型の認証を、デバイスに紐づいた非対称鍵ペアによる認証へ置き換える仕組みである。鍵は可能な限り TPM に保護された状態で生成・保管され、顔・指紋・PIN といったジェスチャはその鍵をローカルで解錠するために使われるだけで、生体情報や PIN 自体がネットワーク上を送信されることはない。したがって PIN が漏れても当該デバイス以外では使えず、フィッシングやパスワードリスト型攻撃への耐性が大きく高まる。Intune では登録時の Windows Hello for Business 設定（テナント全体に適用）や構成プロファイル／設定カタログを使って、PIN の最小長・複雑さ、生体認証の許可可否、TPM の必須化といった要件を構成できる。D の BitLocker 回復キーのバックアップはディスク暗号化ポリシーの領域であり、Windows Hello for Business の目的ではない。

正解: A. A. ローカル管理者アカウントのパスワードを自動的にランダム化・ローテーションし、Entra IDに安全に保存する

正解の根拠・詳細解説

Windows LAPS（Local Administrator Password Solution）は、各デバイスのローカル管理者アカウントのパスワードを自動的にランダム生成し、定期的にローテーションしたうえで、Microsoft Entra ID またはオンプレミス Active Directory にバックアップして安全に保管する機能である。狙いは、全端末で同一のローカル管理者パスワードを使い回すことによる横展開攻撃、すなわち 1 台の侵害を足がかりに他の端末へ次々と侵入されるリスクを排除することにある。Intune ではエンドポイント セキュリティのアカウント保護からポリシーを作成し、バックアップ先ディレクトリ、パスワードの長さや複雑さ、有効期間、使用後にローテーションするかどうかを構成できる。保管されたパスワードは権限を持つ管理者だけが管理センターから参照でき、参照操作は監査ログに残るため、誰がいつ管理者パスワードを取得したかを追跡できる点も実務上の利点である。

正解: A. A. アカウント保護ポリシー（ローカルユーザーグループメンバーシップ）

正解の根拠・詳細解説

Intune で Windows デバイスのローカルグループのメンバーシップを管理するには、エンドポイント セキュリティ配下のアカウント保護ポリシーにある「ローカル ユーザー グループ メンバーシップ」を使用する。ここでは対象のローカルグループ（Administrators、Remote Desktop Users など）を選び、Entra ID のユーザーやグループを追加・置換・削除する操作を指定できる。置換は既存メンバーを入れ替える動作のため、意図せず必要なアカウントを外して端末に管理者が不在になる事故が起きやすく、既存構成を保ったまま追加したい場合は「追加」を選ぶのが安全である。B のコンプライアンスポリシーはデバイスが要件を満たすかを評価するだけで構成変更は行わず、C のアプリ保護ポリシーはアプリ内のデータ保護（MAM）、D の更新リングは Windows Update の配信タイミング管理が目的であり、いずれもローカルグループの制御には使えない。

正解: A. A. クラウドベースでID・デバイス管理を一元化できる

正解の根拠・詳細解説

Microsoft Entra 参加済み（Entra Joined）を前提とした展開の最大の利点は、ID とデバイスの管理をクラウドで一元化し、オンプレミス Active Directory やドメインコントローラーへの依存をなくせる点にある。デバイスは職場アカウントでサインインし、認証は Entra ID が、構成・コンプライアンス評価・アプリ配布は Intune が担うため、社内ネットワークや VPN に接続していないリモート端末にも同じ管理が確実に届く。さらに Windows Autopilot と MDM 自動登録を組み合わせれば、情報システム部門でのキッティング作業なしに利用者の手元で初期構成が完了し、条件付きアクセスによるアクセス制御まで一貫して適用できる。なお「オンプレミス AD への依存がなくなる」ことと「ライセンス費用が不要になる」ことは別問題で、Entra ID P1 や Intune のライセンスは別途必要になる点は誤解しやすいので注意したい。

正解: A. A. Work Profile（BYOD）

正解の根拠・詳細解説

Android Enterprise の個人所有 Work Profile（BYOD）は、私物デバイス上に業務専用のコンテナである職場プロファイルを作成し、業務アプリとデータをそこに隔離する方式である。組織が管理・ワイプできるのは職場プロファイル内に限られ、個人領域のアプリ・写真・連絡先には一切アクセスできないため、従業員のプライバシーを守りながら業務データを保護できる。退職時や紛失時も職場プロファイルだけを削除すれば、個人データを消さずに業務データを確実に除去できる（選択的ワイプ）。B のフルマネージドと C のデディケイテッドは会社所有デバイスを前提にデバイス全体を管理する方式であり、私物端末に適用するのはプライバシーの観点からも現実的でない。D の Device Administrator は Google が非推奨とした旧来の管理方式で、新規展開では選択すべきではない。

正解: A. A. Apple自動デバイス登録（Automated Device Enrollment）

正解の根拠・詳細解説

Apple 自動デバイス登録（ADE、旧称 DEP）は、Apple Business Manager／Apple School Manager に登録された組織所有デバイスを、開封後の初期セットアップ（セットアップ アシスタント）の段階で自動的に Intune へ登録する仕組みである。管理者が事前に登録プロファイルを作成してデバイスへ割り当てておけば、利用者は箱を開けてネットワークに接続するだけで MDM プロファイル・構成プロファイル・必須アプリが適用され、キッティング作業が不要になる。ADE で登録されたデバイスは監視（Supervised）モードとなるため、管理プロファイルの削除をブロックしたり、監視モード限定の制限設定を利用したりできる。B のポータル サイトによる手動登録は BYOD 向けでゼロタッチにはならず、C の Apple Configurator は端末を Mac に有線接続して個別に処理する方式で、大量導入には向かない。

正解: A. A. 特定OS・バージョンのデバイスのみ登録を許可する

正解の根拠・詳細解説

デバイスの種類の制限（プラットフォーム制限）は、Intune の登録制限のうち、どの OS プラットフォームからの登録を許可するかを定義するポリシーである。iOS/iPadOS・Android（Work Profile やフルマネージドといった方式単位）・Windows・macOS ごとに許可／ブロックを切り替えられ、さらに最小・最大 OS バージョンを指定して、セキュリティ更新が提供されなくなった古いバージョンの端末が管理下に入るのを防げる。個人所有デバイスをブロックする設定と組み合わせれば、会社所有として事前に登録された端末だけを受け入れる運用も可能になる。既定の制限に加えて優先度を持つカスタム制限をグループへ割り当てられるため、部門ごとに異なる要件を適用できる。B のライセンス自動割り当て、C のアプリ自動更新、D のネットワーク帯域制限はいずれも登録制限の機能ではない。

正解: A. A. deviceOwnership（会社所有/個人所有）

正解の根拠・詳細解説

Entra ID の動的デバイスグループでは、デバイスオブジェクトが持つ属性を条件式に使ってメンバーシップを自動判定する。規則に利用できる代表的な属性は deviceOwnership（Company / Personal）、deviceOSType、deviceOSVersion、deviceCategory、deviceManufacturer、deviceModel、enrollmentProfileName、deviceTrustType などで、たとえば deviceOwnership が Company かつ deviceOSType が Windows という条件を組み合わせれば、会社所有の Windows 端末だけを対象にコンプライアンスポリシーや更新リングを割り当てられる。B のユーザーの役職名（jobTitle）はユーザーオブジェクトの属性であり、動的「ユーザー」グループの規則では使えても動的デバイスグループの規則には使えないという点が引っかけになりやすい。C・D はそもそもディレクトリ上のデバイス属性ではない。

正解: A. A. フルマネージドデバイスでWork Profileを有効化する構成

正解の根拠・詳細解説

COPE（Corporate-Owned, Personally-Enabled）は、会社が所有・支給する端末で従業員の私的利用も認めるモデルであり、Android Enterprise では「企業所有の職場プロファイル（corporate-owned work profile）」、すなわちフルマネージドのデバイス上に職場プロファイルを設ける構成で実現する。業務アプリとデータは職場プロファイル内に隔離されて組織が完全に管理でき、同時にデバイス全体に対してもパスコード要件や工場出荷時リセットといったポリシーを適用できる一方、個人プロファイルの中身は組織から参照できないため私的利用のプライバシーが保たれる。D の個人所有 Work Profile のみでは会社所有デバイスとしての全体制御ができず、B の Device Administrator は Google が非推奨とした旧方式、C の共有デバイスモードは Android の COPE 要件とは無関係であるため、いずれも適合しない。

正解: A. A. ユーザーへのIntune/Microsoft 365ライセンスの割り当て状況

正解の根拠・詳細解説

「登録に必要なライセンスがありません」というエラーは、サインインしたユーザーに Intune のサービスプランを含むライセンス（Intune Plan 1 単体、または Microsoft 365 E3/E5、Microsoft 365 Business Premium などの上位スイート）が割り当てられていない場合に発生する典型的な症状である。Intune の登録はユーザー単位のライセンスで制御されるため、テナントにライセンスの在庫があるだけでは足りず、対象ユーザーに実際に割り当てられていなければ登録はブロックされる。実務では、Microsoft 365 管理センターやライセンスを配布するグループベースライセンスの割り当て状況をまず確認し、次に登録制限やライセンス数の枯渇を疑う。B のストレージ容量、C の DNS 設定、D のローカル管理者アカウントの有無はこのエラーの原因にはならず、切り分けの初手としては不適切である。

正解: A. A. Microsoft Entra IDで保護された一部のクラウドアプリ・リソースへのSSOアクセス

正解の根拠・詳細解説

Microsoft Entra 登録済み（Registered）デバイスは、私物端末に職場アカウントを紐づけて組織の ID 基盤と関連付ける形態であり、デバイスオブジェクトが Entra ID に存在することで、条件付きアクセスの評価対象になり、Entra ID で保護されたクラウドアプリへのシングルサインオン（SSO）が利用できるようになる。ただしデバイス自体は個人のものであるため、組織が適用できる制御はアプリ保護ポリシーやコンプライアンス評価などに限られ、Entra 参加済みデバイスのようにデバイス全体の構成を強制することはできない。B のオンプレミスファイル共有への全面的なアクセスや C のドメインコントローラーへの管理アクセスは Entra 登録によって付与されるものではなく、D のようにすべての Intune ポリシーが完全に適用されるわけでもない点が、Entra 参加済みとの実務上の決定的な違いになる。

正解: A. A. デバイスの所有形態（会社所有か個人所有か）と用途（個人利用を許可するか）

正解の根拠・詳細解説

Android Enterprise の登録方式は、①デバイスの所有形態が会社所有か個人所有か、②個人利用を許可するか業務専用か、③特定の個人に紐づくか不特定多数の共用か、という軸で決まる。会社所有かつ業務専用であればフルマネージド（COBO）、会社所有だが私的利用も認めるなら企業所有の職場プロファイル（COPE）、個人所有の私物端末に業務コンテナだけを置くなら Work Profile（BYOD）、会社所有で単一目的の共用端末ならデディケイテッド（COSU）が適合する。B の購入時期や C のメーカー、D の接続方式は、対応 OS バージョンや調達の都合として考慮することはあっても、管理モデルそのものを決める基準にはならない。設計の初手として「誰の持ち物で、何に使うのか」を確定させることが、後の運用とプライバシー上の摩擦を避ける最大のポイントになる。

正解: A. A. Microsoft Entraグループ

正解の根拠・詳細解説

Intune の登録プロファイル・構成プロファイル・コンプライアンスポリシー・アプリなど、ほぼすべての割り当て（Assignment）は Microsoft Entra ID のセキュリティグループを単位として行う。ユーザーグループに割り当てればそのユーザーがサインインしたデバイスに、デバイスグループに割り当てればユーザーに依存せずデバイス自体に適用されるという違いがあり、たとえば Windows Autopilot の展開プロファイルやキオスク構成のようにサインイン前に効かせたい設定はデバイスグループへの割り当てが基本になる。動的グループの規則と組み合わせれば、新規登録された端末が条件に合致した時点で自動的に対象へ加わるため、手作業の割り当てが不要になる。B・C・D はいずれも Intune の割り当てスコープとして利用できる単位ではない。

正解: A. A. Apple MDMプッシュ証明書とABMトークンの登録

正解の根拠・詳細解説

Apple Business Manager（ABM）と Intune を連携させて自動デバイス登録（ADE）を機能させるには、Intune 側で 2 種類の資格情報を構成する必要がある。1 つ目は Apple MDM プッシュ証明書（APNs 証明書）で、これは ADE に限らずすべての Apple デバイス管理の前提となり、未構成なら iOS/macOS デバイスは一切登録できない。2 つ目は ABM で MDM サーバーを作成した際に取得するトークン（登録プログラムトークン）で、これを Intune にアップロードすることで ABM 上のデバイス情報が Intune に同期され、登録プロファイルを割り当てられるようになる。どちらの資格情報にも有効期限があり、期限切れは新規登録の停止やデバイス同期の失敗という形で表面化するため、更新期限の管理が運用上の重要な作業になる。B・C・D はいずれも Apple 連携とは無関係の設定である。

正解: A. A. Entra参加済み・ハイブリッド参加済みの両方のWindowsデバイスが自動的にIntuneへMDM登録される

正解の根拠・詳細解説

Microsoft Entra 管理センターの「モビリティ（MDM および MAM）」で Microsoft Intune を開き、MDM ユーザースコープを「すべて」に設定すると、テナント内のすべてのユーザーが自動 MDM 登録の対象となる。この状態で対象ユーザーがサインインし、デバイスが Entra 参加済みまたは Entra ハイブリッド参加済みになると、MDM 登録が自動的に実行され、ユーザーがポータル サイトから手動操作しなくても Intune の管理下に入る。段階展開を行いたい場合は「一部」を選び、パイロット用の Entra グループだけをスコープに指定するのが実務的な運用になる。この設定はあくまで Windows デバイスの MDM 自動登録を制御するものであり、C のように macOS が同時に登録されることはない（Apple デバイスは ADE やポータル サイト経由の登録による）。またユーザーには別途 Intune ライセンスが必要である。

正解: A. A. デバイス registered devices の一覧（登録済みデバイスの監視）

正解の根拠・詳細解説

Intune管理センターの「デバイス」ブレードで、登録状況・コンプライアンス状態・最終チェックイン日時等を一覧で確認できる。 ドメイン②：デバイスの管理と保守（34問・最重要） 出題比率25〜30%で最大のドメイン。Windows Autopilotの各種デプロイモード、Windows 365 Cloud PC、更新リング・機能更新プログラムなど、デバイスのライフサイクル管理全般を問われます。

正解: A. A. デバイス準備ポリシーはMicrosoft Entra参加に最適化され、より高速かつシンプルなプロビジョニングを目的とする新しい仕組み

正解の根拠・詳細解説

Windows Autopilot デバイス準備ポリシー（device preparation policy）は、クラウドネイティブな Microsoft Entra 参加シナリオに最適化された新しいプロビジョニングの仕組みで、従来の Autopilot 展開プロファイルよりも構成がシンプルで初期セットアップが速くなるよう設計されている。従来方式ではデバイスのハードウェアハッシュを事前に取り込んで Autopilot デバイスとして登録しておく必要があったのに対し、デバイス準備ポリシーはデバイス用のセキュリティグループを対象に割り当てる形をとり、プロビジョニング中に適用するアプリやスクリプトを明示的に指定して、その完了までを待たせるという分かりやすいモデルになっている。適用できるアプリ数には上限があるため、大量のアプリを初期展開に含めたい場合は従来の展開プロファイルと Enrollment Status Page の組み合わせを検討する。B・C のようなプラットフォーム限定の仕組みではなく、D のように両者が同一でもない。

正解: A. A. エンドユーザー自身がデバイスの初期セットアップ中にEntra IDでサインインして構成を完了する

正解の根拠・詳細解説

Windows Autopilot のユーザー主導モード（user-driven mode）は、個人に割り当てるノート PC の展開で最も一般的に使われるモードで、利用者が箱から出したデバイスの電源を入れ、ネットワークに接続して自分の職場アカウントでサインインするだけで、Entra 参加（またはハイブリッド参加）、Intune への自動登録、割り当て済みポリシーとアプリの適用が一連の流れで自動的に進む。サインインしたユーザーがそのデバイスのプライマリユーザーとして紐づくため、ユーザー単位で割り当てたアプリやポリシーもそのまま適用される。B のように管理者が事前に全構成を済ませておく形は事前プロビジョニング（white glove）モード、ユーザーのサインインを必要としない共用端末向けはセルフデプロイモードであり、用途に応じて使い分ける。情報システム部門でのキッティングが不要になり、デバイスをメーカーから利用者へ直送できる点が最大の運用上の利点となる。

正解: A. A. IT部門やパートナーが事前に大半の構成を完了させ、エンドユーザーへの配布時間を短縮する

正解の根拠・詳細解説

Windows Autopilot の事前プロビジョニング（pre-provisioning、旧称 white glove）は、IT 部門や OEM／リセラーがユーザーへ引き渡す前に、デバイス単位で割り当てられたアプリやポリシーの適用といった時間のかかる処理をあらかじめ完了させておくモードである。技術者フェーズで大半の構成を済ませておくため、利用者は受け取った後にサインインするだけで、待ち時間をほとんど感じずに業務を開始できる。特に大容量アプリの配布や複雑なポリシー適用がある環境では、ユーザーの初回起動時の待ち時間が数十分単位で短縮されるという実利がある。技術者フェーズではデバイス認証に TPM 2.0 による構成証明が使われるため、TPM が無効なデバイスや仮想マシンでは失敗しやすい点が実務上の注意点となる。C の工場出荷状態へのリセット自体が目的ではなく、B・D も本モードの狙いではない。

正解: A. A. キオスク端末や共有デバイスなど、ユーザーサインインなしで自動構成したい場合

正解の根拠・詳細解説

Windows Autopilot のセルフデプロイモード（self-deploying mode）は、ユーザーのサインインを一切必要とせずにデバイスを Entra 参加させ、Intune に登録して構成まで完了させるモードで、キオスク端末・デジタルサイネージ・会議室デバイスのようにユーザーが特定されない共用機器に適している。ユーザー資格情報の代わりにデバイス自身の資格情報が使われ、TPM 2.0 による構成証明でデバイスの正当性を検証するため、TPM 2.0 を搭載していないデバイスや構成証明を利用できない環境では成立しない点が最大の前提条件になる。デバイスに紐づく割り当て（デバイスグループへの割り当て）だけが適用され、ユーザーグループに割り当てたアプリやポリシーは適用されないため、必要な構成はすべてデバイスターゲットで設計する必要がある。B の個人専用 PC はユーザー主導モード、C・D は Apple の管理領域である。

正解: A. A. デバイス名テンプレート（device name template）

正解の根拠・詳細解説

Windows Autopilot の展開プロファイルにはデバイス名テンプレート（device name template）を設定でき、プロビジョニング時に規則的なコンピューター名を自動付与できる。テンプレートでは固定の接頭辞に加えて %SERIAL%（デバイスのシリアル番号）や %RAND:x%（指定桁数の乱数）といった変数を組み合わせられるため、CONTOSO-%SERIAL% のような形で一意かつ識別しやすい命名規則を全社に強制できる。注意点として、Windows のコンピューター名は 15 文字までという制約があり、接頭辞を長くしすぎると切り詰めや失敗の原因になる。命名が統一されていると、Intune のデバイス一覧やレポート、資産管理台帳との突合が容易になり、インシデント時の端末特定も速くなる。B・C・D はいずれもデバイス名の付与とは無関係の仕組みである。

正解: A. A. プロビジョニング中の進行状況を表示し、必須アプリ・ポリシー適用が完了するまでユーザーのデスクトップアクセスを制限する

正解の根拠・詳細解説

Enrollment Status Page（ESP、登録状態ページ）は、Autopilot などによるプロビジョニング中に進行状況を全画面で表示し、必須のアプリ・証明書・構成プロファイルの適用が完了するまでユーザーがデスクトップを操作できないようブロックする仕組みである。これにより、セキュリティ設定や業務アプリが未適用の中途半端な状態で端末が使われ始めるのを防ぎ、構成の確実な完了を保証できる。ESP のプロファイルでは、インストールに時間がかかりすぎた場合のタイムアウト値、エラー時にユーザーへ表示するメッセージ、失敗時にリセットや続行を許可するか、ブロック対象とする必須アプリの指定などを構成できる。実務では、ブロック対象アプリを増やしすぎるとタイムアウトによる失敗が多発するため、初期展開に本当に必要なアプリだけを指定するのが定石となる。

正解: A. A. Windows 11準備状況レポート（readiness report）と機能更新プログラムポリシー

正解の根拠・詳細解説

Windows 11 への大規模アップグレードを計画する際は、まず Intune／Endpoint analytics が提供する Windows 11 の準備状況（readiness）レポートで、プロセッサ・TPM 2.0・セキュア ブート・メモリ・ストレージといった要件をデバイスごとに評価し、アップグレード可能な端末と買い替えが必要な端末を可視化する。そのうえで機能更新プログラム（feature update）ポリシーを作成し、対象を Windows 11 の特定バージョンへ段階的に移行させる。パイロットグループから順に適用範囲を広げる設計にすると、業務アプリの互換性問題を早期に検知しつつ影響範囲を限定できる。B の BitLocker 暗号化ポリシー、C の App Control for Business、D の場所ベースの条件付きアクセスは、いずれもセキュリティ制御が目的であり、OS のアップグレード計画・実行を担う機能ではない。

正解: A. A. プロビジョニングポリシーとユーザー設定ポリシー

正解の根拠・詳細解説

Windows 365 の Cloud PC をプロビジョニングするには、2 種類のポリシーを組み合わせる。プロビジョニングポリシーでは、参加の種類（Microsoft Entra 参加またはハイブリッド参加）、使用するイメージ（Microsoft が提供するギャラリーイメージまたはカスタムイメージ）、ネットワーク構成、Cloud PC の名前付け規則などを定義し、割り当てたユーザーグループのメンバーに対して Cloud PC が作成される。ユーザー設定ポリシーでは、利用者に Cloud PC 上のローカル管理者権限を与えるか、復元ポイント（ポイントインタイム リストア）サービスを有効にしその頻度をどうするか、といった利用者側の体験を定義する。前提として対象ユーザーに Windows 365 のライセンスが割り当てられている必要がある。B・C・D はいずれも Cloud PC の作成に必須の構成要素ではない。

正解: A. A. 新しいライセンス（SKU）の割り当てとリサイズ操作の実行

正解の根拠・詳細解説

Cloud PC のリサイズは、仮想化された環境の割り当てリソース（vCPU・メモリ・ストレージ）を変更する操作であり、物理的なハードウェア作業は一切発生しない。手順としては、まず変更後のスペックに対応する Windows 365 ライセンス（SKU）を確保してユーザーに割り当て、次に Intune 管理センターの Windows 365 の Cloud PC 一覧からリサイズ操作を実行する。リサイズ中は Cloud PC が一時的に利用できなくなるため業務時間外に実施するのが望ましく、ユーザーが接続中でないことを確認しておく必要がある。なお、ストレージ容量は上位 SKU への変更で増やせるが縮小方向のリサイズには制約があるため、サイズ選定は余裕を持って行うのが実務上の勘所となる。B・C・D はいずれも物理マシンの話であり、クラウドでホストされる Cloud PC には当てはまらない。

正解: A. A. 特定ユーザー・デバイス単位で登録状況やポリシー適用状況を診断する

正解の根拠・詳細解説

Intune 管理センターの「トラブルシューティング＋サポート」ブレードは、テナント全体の集計ビューではなく、特定のユーザーやデバイスを 1 件指定して、その対象に何が起きているかを縦断的に診断するための画面である。選択したユーザーについて、割り当てられているライセンスやグループ、登録済みデバイスの一覧、登録時のエラーとエラーコード、割り当てられている構成プロファイル・コンプライアンスポリシー・アプリとそれぞれの適用状態（成功／保留中／エラー）を一覧できるため、「このユーザーだけポリシーが当たらない」「登録できない」といった個別の問い合わせを短時間で切り分けられる。B のライセンスコスト集計や D のメールボックス容量の確認は別のサービスの管理センターで行うものであり、C の一括リセットはこのブレードの機能ではない。

正解: A. A. Windows Updateの品質更新プログラム配信タイミングと再起動動作

正解の根拠・詳細解説

更新リング（update ring）は Windows Update for Business の設定を Intune から構成するポリシーで、品質更新プログラムの延期日数、機能更新プログラムの延期日数、アクティブ時間、再起動の期限（デッドライン）と猶予期間、ユーザーによる更新の一時停止やスキャンの許可可否などを定義する。パイロット・早期採用・全社といった複数のリングを作り、延期日数をずらして割り当てることで、問題のある更新が全社に一斉展開されるのを避ける段階的な配信設計が実現できる。B の Microsoft Store アプリ、C の Office のバージョン管理はそれぞれ別の仕組みで管理され、D のドライバー署名検証も更新リングの制御対象ではない。なお、機能更新プログラムポリシーを併用している場合は、そちらが対象 OS バージョンの制御を担うという役割分担になる点を押さえておきたい。

正解: A. A. 対象デバイスを特定のWindowsバージョンへ計画的にアップグレードする

正解の根拠・詳細解説

機能更新プログラム（feature update）ポリシーは、対象デバイス群を管理者が指定した Windows の特定バージョンへ移行させ、かつそのバージョンに留めておくためのポリシーである。更新リングによる延期日数の設定が「どれだけ遅らせるか」という時間軸の制御であるのに対し、機能更新プログラムポリシーは「どのバージョンにするか」というバージョンの制御を行う点が本質的な違いになる。これにより、検証済みのバージョンを部門ごとに段階展開しつつ、未検証の新バージョンへ意図せず上がってしまう事態を防げる。実務上の前提として、Windows Update for Business のデプロイメント サービスを利用するため、対象デバイスで診断データの送信が有効になっている必要があり、これが無効だとポリシーが効かないという見落としが起きやすい。B・C・D はいずれも機能更新プログラムポリシーの守備範囲外である。

正解: A. A. 不具合のある更新プログラムが広範囲に展開される前に影響を抑える

正解の根拠・詳細解説

品質更新プログラムの一時停止（pause）は、特定の更新プログラムに不具合が報告された際に、更新リング単位で配信を止め、まだ適用していないデバイスへの展開拡大を食い止めるための緊急措置である。すでに問題が顕在化している状況では、原因調査と Microsoft からの修正提供を待つ間、被害を受ける端末をこれ以上増やさないことが最優先になるため、この操作が有効に働く。一時停止には最大 35 日という上限があり、期間が満了すると自動的に更新が再開されるほか、再開後にもう一度一時停止するには一定期間のスキャンが必要になる点も押さえておきたい。なお、一時停止は未適用のデバイスに対する予防策であり、すでに適用済みの端末を元に戻すには別途アンインストールやロールバックの対応が必要になる。B・C・D は一時停止の目的とは無関係である。

正解: A. A. カスタムコンプライアンス（PowerShellスクリプトを使ったカスタム準拠設定）

正解の根拠・詳細解説

カスタム コンプライアンス設定は、Intune の組み込みコンプライアンス設定（OS バージョン、暗号化、パスワード要件など）では表現できない独自の準拠要件を、PowerShell の検出スクリプトと JSON 形式のルールファイルの組み合わせで評価する仕組みである。スクリプトは対象デバイス上で値を収集して JSON として返し、管理者がアップロードした JSON ファイルがその値に対する期待条件（データ型・演算子・期待値）と、非準拠時にユーザーへ表示する説明や修復手順を定義する。これにより、たとえば特定のレジストリ値やサードパーティ製エージェントの稼働状態といった、標準設定では扱えない条件を準拠判定に組み込める。B の条件付きアクセスは評価結果を使ってアクセスを制御する側の機能、C の Windows LAPS はローカル管理者パスワード管理、D の Endpoint Privilege Management は昇格制御であり、いずれも準拠判定の拡張を担うものではない。

正解: A. A. Entra Connectを使ったオンプレミスADとの同期、およびオンプレミスへの接続性

正解の根拠・詳細解説

Autopilot で Microsoft Entra ハイブリッド参加を選択する場合、デバイスは最終的にオンプレミス Active Directory のドメインに参加する必要があるため、クラウドだけで完結する Entra 参加とは別に、オンプレミス側の前提条件が加わる。具体的には、①Entra Connect によってオンプレミス AD と Entra ID が同期されていること、②社内に Intune Connector for Active Directory をインストールしたサーバーを配置し、オフラインドメイン参加（ODJ）に必要なコンピューターオブジェクトを AD 上に作成できること、③プロビジョニング中のデバイスがドメインコントローラーへ到達できるネットワーク接続性（社内ネットワークまたは VPN 経由）を持つことが必要になる。特に③はリモートワーク環境で満たしにくく、ハイブリッド参加の Autopilot が失敗する典型的な原因になるため、可能であればクラウドネイティブな Entra 参加への移行を検討するのが現実的な方針となる。B・C・D は Apple／Android 側の構成であり無関係である。

正解: A. A. ローカル管理者権限の付与・再起動の許可

正解の根拠・詳細解説

Windows 365 のユーザー設定ポリシーは、Cloud PC の「作り方」ではなく「使わせ方」を定義するポリシーである。ここで構成できる代表的な項目は、①割り当てられたユーザーに Cloud PC 上のローカル管理者権限を付与するかどうか、②ポイントインタイム リストア（復元ポイント）サービスを有効にし、ユーザー自身に復元操作を許可するか、その取得頻度をどうするか、といった利用者体験に関わる設定になる。これに対して、使用するイメージ、参加の種類、ネットワーク構成、名前付け規則などはプロビジョニングポリシー側で定義するという役割分担になっており、両者を混同しやすい点が試験でも実務でも問われる。B のネットワーク帯域幅、C の BitLocker 回復キーの保存先、D の Defender のシグネチャ更新頻度は、いずれもユーザー設定ポリシーの構成項目ではない。

正解: A. A. 地域別のEntraグループを作成し、それぞれに異なる更新リングポリシーを割り当てる

正解の根拠・詳細解説

更新リング（Windows Update for Business のポリシー）は Microsoft Entra のセキュリティグループ単位で割り当てるため、地域や部門ごとにグループを用意し、それぞれに延期日数・アクティブ時間・再起動デッドラインの異なるリングを割り当てるのが標準的な設計になる。地域ごとに業務時間帯や繁忙期、ネットワーク帯域の事情が異なるため、アクティブ時間や再起動の期限を現地の勤務時間に合わせて設定することで、業務中の強制再起動によるトラブルを避けられる。運用上の注意点として、1 台のデバイスが複数の更新リングの対象になると設定が競合するため、動的グループの規則や除外を使って重複を排除し、どのデバイスがどのリングに属するかを一意に決められる設計にしておく必要がある。B の一律適用ではリスク分散も現地事情への対応もできず、C・D は更新管理を担う機能ではない。

正解: A. A. エンドユーザーへの初期セットアップ画面の表示項目を減らし、迅速な展開を実現する

正解の根拠・詳細解説

Autopilot の展開プロファイルでは、OOBE（Out-of-Box Experience）で表示される画面を管理者側で抑制でき、プライバシー設定の選択画面、EULA（使用許諾契約）の表示、Microsoft アカウントによるサインイン、ローカル管理者アカウントの作成といったステップを省略できる。これにより、利用者が判断に迷う選択肢や組織として統一したい設定を画面から取り除き、電源投入からサインインまでの手順を最小化して展開時間を短縮できる。非表示にした項目については、組織のポリシーとして望ましい既定値が適用されるため、診断データの送信レベルなどを厳密に管理したい場合は、別途構成プロファイルや設定カタログで明示的に構成しておくのが実務上の定石になる。B・C・D はいずれもこの設定とは無関係で、BitLocker や Windows Update の制御は専用のポリシーで行う。

正解: A. A. ギャラリーイメージまたは組織がアップロードしたカスタムイメージ

正解の根拠・詳細解説

Windows 365 のプロビジョニングポリシーでは、Cloud PC の元となるイメージとして、Microsoft が提供するギャラリーイメージか、組織が Azure Compute Gallery に登録したカスタムイメージのいずれかを選択できる。ギャラリーイメージは Windows と Microsoft 365 アプリがあらかじめ含まれた状態で提供され、追加の準備なしにすぐ利用を開始できるため、標準的な業務環境ではこちらで十分なことが多い。一方、業務アプリや社内設定を最初から組み込んだ状態で配布したい場合は、汎用化（generalize）した独自イメージを Azure Compute Gallery に登録してカスタムイメージとして参照する。ただしカスタムイメージはイメージそのものの更新・保守が組織の責任になるため、アプリ配布は Intune 側に寄せてイメージは薄く保つほうが長期の運用負荷は小さくなる。C・D のように Windows 以外の OS を Cloud PC のイメージにすることはできない。

正解: A. A. 失敗時もユーザーがデスクトップを継続利用できるようにするか、ブロックを継続するかを選べる

正解の根拠・詳細解説

Enrollment Status Page（ESP）のプロファイルでは、必須アプリやポリシーの適用に失敗した、あるいはタイムアウトした場合の挙動を管理者が選択できる。代表的な設定として、①インストールエラーが発生してもユーザーにデバイスの使用を許可するか（許可すればユーザーは未完了のままデスクトップへ進める）、②エラー時にユーザー自身がデバイスをリセットできるようにするか、③すべての必須アプリとプロファイルがインストールされるまでデバイスの使用をブロックするか、といった項目がある。加えてインストール完了を待つタイムアウト値やエラー時に表示するカスタムメッセージも構成でき、利用者へ問い合わせ先を案内できる。実務では、ブロック対象の必須アプリを絞り込みつつタイムアウトを現実的な値に設定しないと、初回セットアップの失敗が多発する点に注意したい。

正解: A. A. Intuneのプロファイル割り当ての優先度設定に基づき、最も優先度の高いプロファイルが適用される

正解の根拠・詳細解説

1 台のデバイスが複数の Autopilot 展開プロファイルの対象グループに含まれてしまった場合、適用されるプロファイルは無作為や作成順で決まるのではなく、プロファイルに設定された優先度に従って 1 つだけが選ばれる。とはいえ、重複割り当てはプロビジョニング結果が意図と異なるという事故につながりやすいため、実務では優先度に頼るより、そもそも 1 台のデバイスが 1 つのプロファイルにしか一致しないようグループ設計を行うのが原則になる。具体的には、Autopilot のグループタグ（注文 ID）を利用者の用途ごとに付与し、そのタグを条件にした動的デバイスグループを作って各プロファイルを割り当てる、あるいは除外グループを併用して重なりを解消する、といった方法が有効である。B・C の作成順や D の無作為選択という挙動ではない点を押さえておきたい。

正解: A. A. プロビジョニング失敗の原因（ネットワーク・ライセンス等）を事前に診断する

正解の根拠・詳細解説

Windows 365 のヘルスチェックは、Cloud PC のプロビジョニングが成功するために必要な前提条件が満たされているかを事前かつ定期的に検証する仕組みで、特に Azure Network Connection（ANC）を使う構成で重要になる。検証される代表的な項目には、指定したサブネットに Cloud PC を作成できるだけの IP アドレスの空きがあるか、DNS で名前解決ができるか、Windows 365 のサービスエンドポイントへ到達できるか、ハイブリッド参加構成の場合はドメイン参加用の資格情報とドメインコントローラーへの到達性が有効か、といったものがある。ヘルスチェックが失敗している状態のネットワーク接続を使うとプロビジョニングも失敗するため、Cloud PC を大量に払い出す前にこの結果を確認しておくことが、原因不明の失敗を防ぐ実務上の勘所となる。B・C・D はいずれもヘルスチェックの役割ではない。

正解: A. A. 新しい更新プログラムを即時展開せず、一定期間の検証期間を確保する

正解の根拠・詳細解説

品質更新プログラムの延期（deferral）は、Microsoft が更新プログラムを公開してから対象デバイスへ提供されるまでの日数をずらす設定で、リリース直後に判明する不具合の影響を受けないための検証期間を確保することが目的である。延期日数の異なる更新リングをパイロットグループから全社まで段階的に割り当てれば、先行グループで問題が見つかった時点で後続リングを一時停止し、被害を局所化できる。ここで重要なのは、延期はあくまで適用を「遅らせる」設定であって、B のように更新を恒久的に回避するものではないという点である。長期にわたって更新を当てない運用はセキュリティ上の重大なリスクになるため、延期日数は検証に必要な最小限に留め、期限（デッドライン）設定と併用して確実に適用されるよう設計するのが正しい使い方になる。

正解: A. A. 先行グループで検証してから段階的に展開範囲を広げ、リスクを最小化する

正解の根拠・詳細解説

更新リング構成の目的は、更新プログラムの展開範囲を時間差で広げることでリスクを局所化することにある。典型的な設計は、①IT 部門など少数のパイロットリング（延期日数を短く設定）、②影響を検証できる部門を含む早期採用リング、③全社を対象とする広域展開リング（延期日数を長めに設定）という 3 段階以上の構成で、先行リングで業務アプリの互換性や不具合を検知できた場合に、後続リングの配信を一時停止して全社への波及を防げる。B のように全デバイスへ同時配布すると、問題のある更新が一斉に適用されて全社的な業務停止を招くおそれがあり、展開速度と引き換えにするには代償が大きすぎる。なお、リングは Entra のセキュリティグループへの割り当てで実現するため、1 台のデバイスが複数リングに重複して所属しないようグループ設計を行うことが前提になる。

正解: A. A. Microsoft Entra Connectの同期スケジュール

正解の根拠・詳細解説

Autopilot によるハイブリッド参加では、まず社内に配置した Intune Connector for Active Directory がオンプレミス AD 上にコンピューターオブジェクトを作成し、オフラインドメイン参加（ODJ）の情報をデバイスへ渡してドメイン参加を完了させる。その後、作成された AD 上のコンピューターオブジェクトが Microsoft Entra Connect の同期サイクルによって Entra ID へ反映されて、初めてデバイスがハイブリッド参加済みとして認識される。したがって、ドメイン参加からハイブリッド参加の完了までには同期スケジュールに依存した時間差が必然的に生じ、同期間隔が長い環境や同期が停止している環境ではプロビジョニングがタイムアウトすることもある。展開前に Entra Connect の同期が正常に動作しているかを確認し、必要に応じて手動同期を実行しておくのが実務上のトラブル回避策になる。B・C・D はこの同期に関与しない。

正解: A. A. Microsoft Hosted NetworkではなくAzure Network Connection（ANC）

正解の根拠・詳細解説

Windows 365 のネットワーク構成には 2 つの選択肢がある。Microsoft Hosted Network は Microsoft 側が用意するネットワークを利用する簡易構成で、Azure のネットワーク設計を行わずに素早く Cloud PC を払い出せる反面、組織のプライベートネットワーク上のリソースへ直接到達することはできない。これに対して Azure Network Connection（ANC）は、組織が管理する Azure 仮想ネットワーク（VNet）のサブネットに Cloud PC のネットワークインターフェイスを配置する方式で、VNet ピアリングや ExpressRoute／VPN 経由でオンプレミスの業務システムやファイルサーバーへアクセスでき、Entra ハイブリッド参加を行う場合はドメインコントローラーへの到達性が必要になるためこちらが必須になる。ANC を使う場合はサブネットの IP アドレス数やヘルスチェックの結果を事前に確認しておく必要がある。

正解: A. A. Autopilotは基本的に組織が購入・管理するデバイス向けであり、BYODには通常使用しない

正解の根拠・詳細解説

Windows Autopilot は、組織が調達した新品のデバイスを工場出荷状態から自社仕様へ自動構成するための仕組みであり、デバイスのハードウェア ID を事前に Autopilot サービスへ登録しておくことが前提になる。この登録は本来 OEM やリセラー、あるいは組織の IT 部門が行うもので、従業員の私物端末に対して組織が実施する性質のものではない。したがって BYOD デバイスの管理は、利用者自身がポータル サイト（Company Portal）アプリから職場アカウントでサインインして登録する方式、あるいは端末を登録せずアプリ保護ポリシー（MAM）だけでデータを保護する方式が適切になる。B のように BYOD で Autopilot を必須とすることはなく、C の macOS 専用でも D の登録解除専用機能でもない。Autopilot の本質は「組織所有デバイスのキッティング作業をなくす」ことにあると理解しておきたい。

正解: A. A. 後者はユーザーのサインイン後に適用されるアプリ・ポリシーの完了も待つ

正解の根拠・詳細解説

Enrollment Status Page（ESP）は、どのフェーズで進行状況を表示しブロックするかを選択できる。「デバイスの準備」および「デバイスのセットアップ」のみを対象にした場合、デバイスグループに割り当てられたアプリやポリシーの適用完了までを待ち、その後ユーザーはすぐにデスクトップへ進める。一方「アカウントのセットアップ」まで含めた場合は、ユーザーがサインインした後に評価されるユーザーグループ割り当てのアプリやポリシーの適用完了も待つため、利用者は最初のサインイン直後から必要な業務アプリが揃った状態で作業を開始できる。当然ながら待ち時間は後者のほうが長くなるため、B の記述は逆である。実務では、全社共通のアプリはデバイスターゲットで配布して初期セットアップに含め、部門固有のアプリはユーザーターゲットかつ ESP のブロック対象外にすることで、待ち時間と利便性のバランスを取ることが多い。

正解: A. A. シフト制勤務など複数ユーザーが交代でデバイスを共有利用するシナリオ

正解の根拠・詳細解説

Windows 365 Frontline は、シフト制勤務やコールセンター、店舗スタッフのように、多数の従業員が交代で勤務し全員が同時にはログインしない働き方を想定したライセンス形態である。専有型の Windows 365 Enterprise が「ユーザー 1 人につき Cloud PC 1 台」を前提にライセンスを購入するのに対し、Frontline は 1 つのライセンスを複数のユーザーで共有でき、同時に利用できるのはライセンス数までという考え方をとるため、常時全員分の Cloud PC を用意する必要がなくコストを大幅に抑えられる。ただし同時接続数の上限を超えると新たなユーザーはサインインできないため、シフトの重なりやピーク時間帯を踏まえたライセンス数の見積もりが運用設計上の要点になる。B のように単一ユーザーが専有し続ける用途には Frontline ではなく Enterprise が適する。

正解: A. A. 再起動による作業中断を事前に知らせ、ユーザー体験を損なわないようにする

正解の根拠・詳細解説

更新リングでユーザーへの再起動通知や期限（デッドライン）、猶予期間を構成する目的は、セキュリティ更新を確実に適用しつつ、突然の再起動で作業中のデータが失われたり会議や作業が中断されたりする事態を避けることにある。アクティブ時間を設定すれば業務時間帯の自動再起動を抑止でき、デッドラインを設定すれば猶予期間の経過後に確実に再起動が実行されるため、「利用者に配慮しつつ最終的には必ず適用する」という両立が可能になる。通知を過度に抑制すると、利用者が予期しないタイミングで再起動が発生して不信感を招き、逆に通知が多すぎると無視されるようになるため、猶予期間と通知レベルのバランス調整が実務上の腕の見せどころになる。B・C・D はいずれも再起動通知設定の目的ではない。

正解: A. A. デバイスはAutopilot登録済みリストには残るが、Intune管理ポリシーの適用は解除される

正解の根拠・詳細解説

Intune のデバイス一覧からデバイスを削除（登録解除）する操作は、MDM 管理の関係を終了させ、割り当てられていた構成プロファイルやコンプライアンスポリシー、アプリの管理を解除するものである。一方、Windows Autopilot デバイスとしての登録は、デバイスのハードウェア ID（ハードウェアハッシュ）を Autopilot サービスに登録した情報であり、Intune の管理対象から外れても Autopilot 登録済みデバイスの一覧には残り続ける。そのため、初期化して再展開すればそのデバイスは再び Autopilot のフローに乗る。デバイスを組織から完全に切り離す（下取り・売却・譲渡など）場合は、Autopilot デバイス登録の削除と、必要に応じて Entra ID 上のデバイスオブジェクトの削除も併せて行う必要があり、この 3 か所の使い分けが実務で混乱しやすいポイントになる。

正解: A. A. 競合が発生し、いずれか1つのポリシーのみが有効になる（割り当て設計の見直しが必要）

正解の根拠・詳細解説

1 台のデバイスに複数の機能更新プログラム（feature update）ポリシーが割り当てられると、目標とする Windows のバージョンについて矛盾した指示が同時に与えられることになり、競合状態となっていずれか 1 つしか有効にならない。どちらが有効になるかを管理者が確実にコントロールできるわけではないため、意図しないバージョンに固定される、あるいは想定した時期にアップグレードが始まらないといった不具合につながる。したがって設計の原則として、機能更新プログラムポリシーは 1 台のデバイスが必ず 1 つだけの対象になるようグループを組み、重なりが生じる場合は除外グループで解消しておく必要がある。展開後は Intune のレポートでポリシーの適用状態と競合の有無を確認するのが定石で、B の同時適用や C の自動的な優先解決といった挙動は期待できない。

正解: A. A. スナップショットから以前の状態にCloud PCを戻す

正解の根拠・詳細解説

Windows 365 のポイントインタイム リストア（復元）は、Cloud PC のディスクを定期的に取得している復元ポイント（スナップショット）の時点まで巻き戻す機能で、更新やアプリのインストールで環境が壊れた場合、あるいはランサムウェア被害からの復旧といった場面で有効に働く。復元ポイントの取得頻度や、利用者自身に復元操作を許可するかどうかは、ユーザー設定ポリシーで構成する。重要な注意点として、復元は Cloud PC 全体を過去の状態に戻す操作であるため、その時点以降に保存したデータや設定はすべて失われる。したがって業務データは OneDrive や SharePoint に保存し、Cloud PC のローカルディスクを一次保存先にしない運用と組み合わせることが前提になる。B・C・D はいずれもクラウドでホストされる Cloud PC には当てはまらない操作である。

正解: A. A. OEMからの事前登録、またはPowerShellスクリプト/Configuration Managerによる収集

正解の根拠・詳細解説

ハードウェアハッシュはOEMが購入時に登録するか、既存デバイスではPowerShellスクリプト（Get-WindowsAutoPilotInfo）やConfiguration Managerで収集してAutopilotに登録する。 ドメイン③：デバイスの保護（22問） 出題比率15〜20%。アンチウイルス・ファイアウォール・ASRルール・セキュリティベースライン・Defender for Endpoint統合など、エンドポイントセキュリティの実装範囲です。

正解: A. A. Microsoft Defenderウイルス対策のスキャン設定・除外設定

正解の根拠・詳細解説

エンドポイント セキュリティのアンチウイルス（ウイルス対策）ポリシーは、Microsoft Defender ウイルス対策の動作を Intune から集中管理するためのポリシーである。構成できる代表的な項目は、リアルタイム保護の有効化、クイックスキャン／フルスキャンの実行スケジュールと時刻、クラウド提供の保護とその保護レベル、望ましくない可能性のあるアプリ（PUA）の扱い、修復アクション、そしてファイル・フォルダー・拡張子・プロセス単位の除外設定などである。これらをポリシーとして配布することで、端末ごとにローカルで設定する必要がなくなり、設定の逸脱も検知できる。B の VPN 接続先は構成プロファイルの VPN プロファイル、C の BitLocker 回復キーの保存先はディスク暗号化ポリシー、D のライセンス割り当ては Entra ID／Microsoft 365 管理センターの領域であり、いずれもアンチウイルスポリシーの対象外である。

正解: A. A. BitLockerを使ったデバイス暗号化の強制とリカバリーキーの管理

正解の根拠・詳細解説

エンドポイント セキュリティのディスク暗号化ポリシーは、Windows では BitLocker、macOS では FileVault の構成を担う。BitLocker では、OS ドライブ・固定データドライブ・リムーバブルドライブそれぞれの暗号化要件、暗号化方式（XTS-AES 128／256 など）、暗号化する領域（使用領域のみか、ドライブ全体か）、そして回復キーを Microsoft Entra ID にバックアップ（エスクロー）するかどうかを構成できる。ユーザーに操作させずに暗号化を開始する「サイレント有効化」も構成でき、この場合は TPM を備えた Entra 参加済みデバイスであることが前提になる。回復キーの保存先を Entra ID に指定しておくことが特に重要で、これを怠ると回復パスワードが必要になった際にデータへアクセスできなくなる。B・C・D はディスク暗号化ポリシーの守備範囲ではない。

正解: A. A. ヘルプデスクへの問い合わせを減らし、ユーザー自身がポータルで回復キーを取得できるようにする

正解の根拠・詳細解説

BitLocker の回復キーが Microsoft Entra ID にエスクローされていれば、ユーザー自身が「マイ アカウント」ポータルのデバイス画面から自分が所有するデバイスの回復キーを参照できる。これにより、出張先や在宅勤務中に回復画面が表示された場合でも、ヘルプデスクの営業時間を待たずに自力で復旧でき、サポート部門の問い合わせ負荷も削減できる。一方で、回復キーの参照はデバイスのロックを解除できる強力な権限であるため、組織のセキュリティ要件によっては Entra ID のデバイス設定で利用者による回復キーの取得を制限し、管理者やヘルプデスクだけが参照できるようにするという選択肢もある。利便性とリスクのどちらを重視するかを組織として決めたうえで設定するのが正しい進め方で、B・C のように暗号化そのものを無効化する話ではない。

正解: A. A. Windows Defenderファイアウォールの受信・送信ルール

正解の根拠・詳細解説

エンドポイント セキュリティのファイアウォールポリシーでは、Microsoft Defender ファイアウォールの動作を Intune から一括構成できる。ドメイン・プライベート・パブリックの各ネットワークプロファイルごとに、ファイアウォールを有効にするか、既定の受信・送信動作をどうするか、通知を表示するかといった全体設定を定義できるほか、ファイアウォール規則ポリシーで、アプリ・ポート・プロトコル・IP アドレス範囲を指定した個別の受信／送信ルールを配布できる。ローカルで作成された規則とポリシーで配布した規則をマージするかどうかも制御できるため、端末ごとに勝手に追加された穴を塞ぐ運用も可能になる。B の BitLocker 暗号化方式はディスク暗号化ポリシー、D の Entra ID のパスワードポリシーは Entra 側の設定であり、ファイアウォールポリシーとは別領域である。

正解: A. A. マルウェアがよく利用する手法（不審なスクリプト実行・Office由来の子プロセス作成等）を事前にブロックする

正解の根拠・詳細解説

攻撃面の減少（ASR: Attack Surface Reduction）ルールは、特定のマルウェアを検体として検知するのではなく、攻撃者が常用する「振る舞い」そのものをブロックすることでリスクの入口を塞ぐ仕組みである。代表的なルールには、Office アプリからの子プロセス生成のブロック、難読化されたスクリプトの実行のブロック、メールクライアントや Web メールから取得した実行可能コンテンツの実行のブロック、USB から実行される信頼されていないプロセスのブロックなどがある。シグネチャに依存しないため未知のマルウェアにも効果があり、多層防御の一角として機能する。各ルールは「未構成／監査／ブロック／警告」といった状態を個別に設定でき、まず監査モードで業務影響を測ってからブロックへ移行するのが定石である。B・C・D は ASR ルールの目的ではない。

正解: A. A. Microsoft推奨のセキュリティ設定値をテンプレートとして適用し、ゼロから設定を作る手間を省ける

正解の根拠・詳細解説

セキュリティ ベースラインは、Windows や Microsoft Defender for Endpoint、Microsoft Edge などについて、Microsoft のセキュリティチームが推奨する設定値をまとめて提供するテンプレートである。数百に及ぶ設定を一つひとつ調査・検討してゼロから構成する必要がなくなり、まず堅牢な既定状態を素早く作れる点が最大の利点になる。ベースラインにはバージョンがあり、Windows の新バージョンや脅威動向に応じて Microsoft が更新するため、新しいバージョンが公開された際は差分を確認して移行するという運用が発生する。注意点として、C のようにベースラインが何かを無効化してくれるわけではなく、D のようにアプリ互換性を保証するものでもないため、業務アプリへの影響はパイロットグループで必ず検証してから全社展開する必要がある。

正解: A. A. デバイスのリスクスコアに基づいたコンプライアンス評価とEDR機能の活用

正解の根拠・詳細解説

Intune と Microsoft Defender for Endpoint（MDE）を接続すると、MDE がデバイスの挙動から算出したリスクレベル（クリア／低／中／高）が Intune へ共有され、コンプライアンスポリシーの条件として「デバイスの脅威レベルが○○以下であること」を指定できるようになる。この結果を条件付きアクセスと組み合わせることで、侵害の疑いがある端末を自動的に非準拠と判定し、Microsoft 365 のリソースへのアクセスを遮断するという動的な防御が成立する。さらに MDE 側の EDR 機能（高度な検出、インシデントの調査、デバイスの隔離、自動調査と修復）も併せて活用でき、Intune からは EDR ポリシーやオンボーディング設定を配布して展開を効率化できる。B・C・D はいずれも別サービスの機能であり、この統合の目的ではない。

正解: A. A. エンドポイントセキュリティのオンボーディングポリシーをグループに割り当てる

正解の根拠・詳細解説

多数のデバイスを Microsoft Defender for Endpoint にオンボーディングする際は、端末ごとにスクリプトを実行するのではなく、Intune のエンドポイント セキュリティにあるオンボーディング用のポリシー（EDR ポリシー）を作成し、対象の Entra グループへ割り当てるのが標準的な手法である。Intune と MDE のコネクタを有効にしておけば、オンボーディングに必要な構成がポリシー経由で配布され、新規に登録されたデバイスも動的グループ経由で自動的にオンボーディング対象になるため、展開が継続的かつ自動的に維持される。展開状況は Intune や Defender ポータルのレポートで確認でき、オンボーディング済み／未実施のデバイスを追跡できる。B・C・D はオンボーディングとは無関係で、特に D の ASR ルール無効化は防御力を下げるだけの誤った選択肢である。

正解: A. A. アラートの重大度・影響を受けたデバイス/ユーザー・攻撃のタイムライン

正解の根拠・詳細解説

Defender for Endpoint のインシデントは、関連する複数のアラートを 1 つの攻撃ストーリーとしてまとめたものである。トリアージではまず、①アラートの重大度と分類（誤検知か真の脅威か）、②影響範囲（関与したデバイス・ユーザーアカウント・ファイル・IP などのエンティティ）、③攻撃のタイムライン（初期侵入から何が実行され、どこへ広がろうとしたかの時系列）を確認し、対応の優先順位を決める。この 3 点が揃って初めて、封じ込めが必要か、デバイスの隔離やアカウントの無効化を行うべきか、といった判断が下せる。対応としてはデバイスの分離、ファイルの制限、自動調査と修復の結果確認などが用意されている。B・C・D はインシデント対応の判断材料にはならず、特に D のように単一の情報源だけで判断するのは危険である。

正解: A. A. 許可されたアプリケーション・実行ファイルのみをデバイス上で実行可能にする

正解の根拠・詳細解説

App Control for Business（旧 Windows Defender Application Control、WDAC）は、実行を許可するアプリケーションやスクリプトを明示的に定義し、それ以外の実行をブロックする許可リスト方式（アプリケーション制御）の仕組みである。マルウェア対策製品が「悪いものを見つけて止める」拒否リスト方式であるのに対し、App Control は「良いと分かっているものだけを動かす」という逆のアプローチをとるため、未知のマルウェアや正規ツールを悪用する攻撃にも原理的に強い。許可の判断は、発行元の署名証明書、アプリの評価、パス、ハッシュなどを基準にポリシーで定義する。強力な反面、許可漏れがあると業務アプリが起動できなくなるため、まず監査モードで実行実績を収集し、必要なものを許可リストに反映してから強制モードへ移行するという段階的な展開が不可欠になる。

正解: A. A. 暗号化されていないデバイスを非準拠と判定し、Conditional Accessでアクセスを制限できるようにする

正解の根拠・詳細解説

コンプライアンスポリシーに「ストレージの暗号化が必要」といった条件を含めると、暗号化されていないデバイスは非準拠と判定され、その状態が Microsoft Entra ID に共有される。これを条件付きアクセスの「デバイスは準拠としてマーク済みである必要がある」条件と組み合わせることで、紛失・盗難時に情報漏えいリスクが高い未暗号化端末から Exchange Online や SharePoint Online へアクセスすることを実際に遮断できる。重要なのは役割分担で、暗号化を実際に有効化するのはエンドポイント セキュリティのディスク暗号化ポリシー、その状態を評価するのがコンプライアンスポリシー、評価結果を使ってアクセスを止めるのが条件付きアクセスという 3 段構えになっている。非準拠と判定された際にユーザーへ猶予期間を与える設定も併用すると、いきなり業務が止まる事態を避けられる。

正解: A. A. 業務アプリへの誤検知（ブロック）の影響を事前に把握してから強制ブロックに切り替えるため

正解の根拠・詳細解説

ASR ルールを最初から「ブロック」で展開すると、業務で常用している正規のアプリやマクロ、社内製の自動化スクリプトが攻撃の振る舞いに似ているという理由で停止し、広範囲の業務停止を招くおそれがある。監査（Audit）モードでは実際のブロックを行わず、ルールに合致した事象をイベントログや Defender ポータルの高度な検索（Advanced hunting）に記録するだけなので、本番と同じ条件で「もしブロックしていたら何が止まっていたか」を安全に把握できる。その結果を基に、必要な業務アプリを除外設定に登録したうえでブロックモードへ切り替えれば、防御力を高めながら業務影響を最小化できる。ルールごとに個別の状態を設定できるため、影響の小さいルールから順にブロック化していく段階的な進め方が実務では有効である。B・C・D は監査モードの理由として誤りである。

正解: A. A. 未知の脅威に対してより積極的にクラウドベースの保護機能を適用する

正解の根拠・詳細解説

クラウド提供の保護（クラウド保護）は、ローカルの定義ファイルだけで判断せず、ファイルのメタデータやハッシュを Microsoft のクラウドサービスに照会し、機械学習と世界規模の脅威インテリジェンスに基づいて判定する仕組みである。クラウド保護レベルを高く設定するほど、判定に迷う未知のファイルに対してより積極的（厳格）にブロック側へ倒すようになり、シグネチャが未提供の新種マルウェアに対する初期防御力が向上する。その反面、正規のアプリや社内製ツールが誤検知される可能性も高まるため、レベルを上げる際は監視と除外設定の運用をセットで準備しておく必要がある。なお、この機能はクラウドへの照会が前提となるため、クラウド提供の保護そのものと、サンプル送信に関する設定が有効になっていることが実効性の条件になる。B・C・D はクラウド保護レベルとは無関係である。

正解: A. A. デバイス故障やパスワード忘れ時にも管理者またはユーザーが回復キーを取得できる

正解の根拠・詳細解説

BitLocker の回復キーを Microsoft Entra ID にエスクロー（バックアップ）しておく最大の利点は、回復画面が表示される事態が起きても、組織として確実にデータへアクセスする手段が残る点にある。TPM の状態変化、ファームウェアやハードウェアの構成変更、起動順序の変更、更新の失敗などをきっかけに回復キーの入力を求められることは実運用で珍しくなく、キーがローカルの紙や USB にしか存在しない場合は、それを紛失した時点でデータが完全に失われる。Entra ID に保存されていれば、管理者は Intune や Entra 管理センターのデバイス画面から、ユーザー自身は「マイ アカウント」ポータルから回復キーを取得して復旧できる。したがってディスク暗号化ポリシーでは、回復キーを Entra ID に保存する設定を必ず有効にしておくことが実務上の必須事項となる。

正解: A. A. Defender for Endpointのセンサー設定（サンプル共有・タグ付け等）を一元管理する

正解の根拠・詳細解説

Intune の EDR（Endpoint Detection and Response）ポリシーは、Microsoft Defender for Endpoint のセンサー側の動作をデバイス群に対して一括で構成するためのポリシーである。構成できる代表的な項目には、疑わしいファイルのサンプルを自動的に Microsoft へ提出するかどうか（サンプル共有）、デバイスをグループ分けするための組織タグの付与、そしてデバイスを Defender for Endpoint にオンボーディングするための構成が含まれる。組織タグを付けておくと、Defender ポータル側でデバイスグループを作成して、地域や部門ごとに自動調査と修復のレベルや役割ベースのアクセス制御を分けられるため、大規模環境の運用で効いてくる。B の VPN プロファイル配布は構成プロファイル、C・D はそれぞれ別の管理領域であり、EDR ポリシーの機能ではない。

正解: A. A. ネットワークからのデバイスの可視性を下げ、未承諾の通信要求への応答を抑制する

正解の根拠・詳細解説

ファイアウォールのステルスモードは、外部からの未承諾の通信要求に対して応答を返さない動作を指し、有効にすると ping（ICMP エコー）やポートスキャンに対してデバイスが「存在しない」ように振る舞う。攻撃者は侵入対象を探す最初の段階でネットワークをスキャンして応答のあるホストを列挙するため、応答を返さないことで探索段階での発見自体を難しくし、攻撃対象になる確率を下げられる。特に公共の Wi-Fi など、信頼できないネットワークに接続する可能性があるモバイル端末では有効性が高い。一方で、社内の監視ツールが ICMP による死活監視を行っている場合は、ステルスモードの影響で監視が機能しなくなることがあるため、ネットワークプロファイル（ドメイン／プライベート／パブリック）ごとに適用範囲を切り分けるのが実務上の工夫になる。

正解: A. A. ベースラインをコピーし、組織要件に応じて個別項目を上書きするプロファイルを作成する

正解の根拠・詳細解説

セキュリティ ベースラインを組織要件に合わせて調整する場合は、既存のベースラインプロファイルを複製（コピー）し、その複製に対して必要な項目だけを変更するのが推奨される進め方である。元のベースラインをそのまま残しておけば、Microsoft が新しいバージョンのベースラインを公開した際に、自組織で変更した項目と Microsoft の推奨値の差分を把握しやすく、移行の判断もしやすくなる。加えて、複数のベースラインや構成プロファイルを同一デバイスに割り当てると設定が競合する可能性があるため、どのポリシーがどの設定を担当するかを整理し、Intune のレポートで競合が発生していないかを確認することも重要になる。C のようにカスタマイズが一切できないわけでも、D のように既定値を必ず維持しなければならないわけでもなく、業務要件に応じた調整は前提とされている。

正解: A. A. デバイス上のソフトウェアの既知の脆弱性を可視化し、リスクベースの優先順位付けを支援する

正解の根拠・詳細解説

Microsoft Defender の脆弱性管理は、エージェントが収集したデバイス上のソフトウェア インベントリと構成情報を基に、既知の脆弱性（CVE）やセキュリティ構成の弱点を継続的に可視化する機能である。単に脆弱性を一覧するのではなく、その脆弱性が実際に悪用されているか、組織内でどれだけの端末が影響を受けるか、公開された悪用コードが存在するかといった要素を加味して、対処すべき優先順位をリスクベースで提示する点に価値がある。これにより、限られた工数を最も危険な項目から順に投入できる。さらに、提示されたセキュリティ推奨事項から Intune 側の修復タスクを作成して担当者へ引き渡すこともでき、検知から修復までの流れを 1 つのワークフローにつなげられる。B・C・D は脆弱性管理の役割ではない。

正解: A. A. 標準ユーザーに対して特定のタスクのみ昇格権限を一時的に付与し、常時管理者権限を持たせるリスクを減らす

正解の根拠・詳細解説

Endpoint Privilege Management（EPM）は、利用者に常時ローカル管理者権限を与えることなく、業務上必要な特定の操作に限って一時的に昇格を許可する仕組みで、最小権限の原則を現実の業務と両立させるための機能である。管理者権限を常時付与している環境では、マルウェアがユーザーの権限をそのまま奪って自由にシステムを改変できてしまうが、EPM を使えばその攻撃面を大幅に縮小できる。運用としては、対象のアプリやファイルを条件とする昇格ルールを作成し、自動的に昇格する、ユーザーの確認や理由入力を求める、あるいは管理者の承認を経て昇格するといった動作を選べる。なお EPM は Microsoft Intune Suite（または個別のアドオン）に含まれる有償の追加機能であり、標準の Intune Plan 1 だけでは利用できない点も押さえておきたい。

正解: A. A. 業務アプリの正常動作に必要なファイル・フォルダを誤検知から除外するため

正解の根拠・詳細解説

ウイルス対策の除外設定は、業務アプリの動作に必要なファイル・フォルダー・拡張子・プロセスを、リアルタイム保護やスキャンの対象から外すための設定で、データベースやバックアップソフトなど大量の I/O を伴う製品がスキャンと競合して性能低下やファイルロックを起こす場合に用いる。多くの製品ベンダーは推奨する除外パスを公開しており、それに従って必要最小限の範囲だけを除外するのが原則になる。ここで重要なのは、除外した領域は保護されなくなるという事実で、攻撃者は除外されたフォルダーを悪用先として狙うことが知られている。したがって、フォルダー全体やドライブ全体を安易に除外する、C ドライブ直下を除外するといった運用は避け、除外の内容を定期的に棚卸しして不要になったものを削除する運用が求められる。

正解: A. A. Microsoftのクラウドインテリジェンスによる評価を組み合わせ、未知の悪意あるアプリの実行をより柔軟にブロックできる

正解の根拠・詳細解説

Smart App Control は App Control for Business と同じアプリケーション制御エンジンを土台としつつ、許可・拒否の判断を管理者が作成したポリシーではなく、Microsoft のクラウドインテリジェンスによるアプリの評価予測に委ねる仕組みである。実行しようとしているファイルが安全と判断できる場合は許可し、悪意があると予測される場合や、署名がなく評価情報も得られないファイルはブロックするため、管理者が許可リストを網羅的に整備しなくても未知のマルウェアに対する防御が働く。ただし Smart App Control は Windows のクリーンインストール後に評価期間を経て有効化される仕組みで、一度オフにすると再インストールなしには戻せないという制約があるため、組織として確実に制御したい場合は Intune から配布する App Control for Business ポリシーで許可条件を明示的に管理するのが基本方針になる。B・C・D は本機能とは無関係である。

正解: A. A. ユーザーへの通知メール送信や一定期間後のアクセス制限などの段階的アクション

正解の根拠・詳細解説

コンプライアンスポリシーの「アクション」では、即時ブロックの前に通知や猶予期間付きのエスカレーションを段階的に設定できる。 ドメイン④：アプリケーションの管理と保護（21問） 出題比率15〜20%。Win32アプリ配布、アプリ保護ポリシー（MAM）、アプリ構成ポリシー、Microsoft 365 Appsの展開などアプリケーション関連の範囲です。

正解: A. A. Win32 Content Prep Toolでインストーラーを.intunewin形式に変換する

正解の根拠・詳細解説

Intune で Win32 アプリを配布するには、EXE や MSI などのインストーラーとその関連ファイルを、Microsoft が提供する Microsoft Win32 Content Prep Tool（IntuneWinAppUtil）で .intunewin 形式のパッケージに変換してからアップロードする必要がある。このツールはソースフォルダー・セットアップファイル・出力先を指定して実行し、コンテンツを暗号化・圧縮した単一ファイルにまとめる。アップロード後は、サイレントインストール／アンインストールのコマンドライン、対象 OS やアーキテクチャなどの要件（Requirements）、そしてインストール済みかどうかを判定する検出規則（MSI プロダクトコード、ファイルやフォルダーの存在、レジストリ値、カスタムスクリプト）を必ず設定する。特に検出規則の誤りは「インストールが繰り返される」「常に失敗と表示される」といった典型的な不具合の原因になるため、実務では最も慎重に設計すべき箇所になる。

正解: A. A. 利用可能（Available）

正解の根拠・詳細解説

Intune のアプリ割り当てには意図（intent）があり、「利用可能（Available）」を指定したアプリはポータル サイト（Company Portal）のカタログに表示され、利用者が必要と判断したときに自分でインストールできる。強制はされないため、一部のユーザーだけが使う専門ツールや任意のユーティリティを配布するのに適している。これに対して「必須（Required）」は、利用者の操作を待たずにデバイス側で自動的にインストールが実行される意図で、全社共通の業務アプリやセキュリティ関連エージェントの展開に用いる。「アンインストール（Uninstall）」は対象から該当アプリを削除する意図である。なお Available はユーザーグループへの割り当てが基本で、デバイスグループには割り当てられない点、そして D の「自動拒否」という意図は存在しない点も押さえておきたい。

正解: A. A. デバイスの完全管理（MDM登録）なしでも、業務データをアプリレベルで保護する

正解の根拠・詳細解説

アプリ保護ポリシー（App Protection Policy、MAM）は、デバイスそのものではなくアプリとその中の業務データを保護対象とするポリシーである。Outlook や Teams、OneDrive といったポリシー管理対象アプリに対して、アプリ起動時の PIN 要求、業務データの暗号化、他アプリへのコピー＆ペーストや「別のアプリで開く」操作の制限、名前を付けて保存の制限、スクリーンキャプチャの禁止、そして業務データだけを消す選択的ワイプといった制御を適用できる。最大の特徴は、デバイスが Intune に MDM 登録されているかどうかに関わらず適用できる点で、私物端末を組織の管理下に置けない BYOD シナリオでも情報漏えい対策を実現できる。B の BitLocker、C の Windows Update、D のファイアウォールはいずれもデバイス側を構成する仕組みであり、アプリ保護ポリシーの範囲ではない。

正解: A. A. 個人所有デバイス（BYOD）でMicrosoft 365アプリのみを業務利用する

正解の根拠・詳細解説

登録なしのモバイルアプリ管理（MAM without enrollment、MAM-WE）は、私物のスマートフォンやタブレットを MDM 登録させずに、業務で使う Microsoft 365 アプリの内部だけを保護する方式である。利用者は自分の端末を組織に管理させることなく、アプリに職場アカウントでサインインするだけで済み、組織はそのアプリ内の業務データに対して PIN 要求・暗号化・コピー制限・選択的ワイプを適用できる。デバイスの位置情報やインストール済みアプリの一覧を組織が見ることはないため、従業員のプライバシー上の抵抗が小さく、私物端末利用を認めやすいという実務上の利点が大きい。組織所有デバイスを網羅的に管理したい B のケースは MDM 登録を伴う管理が適切で、C の Windows 自動展開は Autopilot の領域、D は本機能の説明として成立しない。

正解: A. A. アプリの動作設定（既定のサーバーURL等）をユーザーの手動入力なしで事前構成する

正解の根拠・詳細解説

アプリ構成ポリシー（App Configuration Policy）は、アプリを配布した後に利用者が手動で入力・設定しなければならない項目を、管理者側があらかじめ定義して配布する仕組みである。たとえば接続先サーバーの URL、既定のアカウント情報、特定機能の有効／無効といったアプリ固有の設定をキーと値の形で指定でき、利用者は初回起動時から正しい設定で使い始められる。設定ミスによる問い合わせが減り、展開の再現性も高まる。ポリシーには MDM 登録済みデバイスを対象とする「マネージド デバイス」向けと、登録の有無に関わらずアプリを対象とする「マネージド アプリ」向けの 2 種類があり、BYOD で MAM のみを運用している場合は後者を使う。B のようにアプリの実行をブロックする機能ではなく、C・D も本ポリシーとは無関係である。

正解: A. A. 月次エンタープライズチャネル・半期エンタープライズチャネル等の複数チャネル

正解の根拠・詳細解説

Intune から Microsoft 365 Apps を配布する際は、アプリの構成として更新チャネルを選択できる。代表的なチャネルには、新機能が最も早く届く「現在のチャネル」、月に一度まとめて機能更新が提供され検証しやすい「月次エンタープライズ チャネル」、年 2 回の機能更新で安定性を最優先する「半期エンタープライズ チャネル」があり、さらに事前検証用のプレビュー版チャネルも用意されている。組織の検証体制やアドイン・マクロへの依存度に応じて、一般利用者は月次エンタープライズ チャネル、業務システムと密結合した部門は半期エンタープライズ チャネルというように使い分けるのが一般的である。同じ画面では 32 ビット／64 ビットの選択、インストールする言語、既存の MSI 版 Office を削除するかどうかも構成できる。C のようにチャネルを選べないわけではない。

正解: A. A. PINの試行回数超過時のデータワイプ、ジェイルブレイク検知時のアクセスブロック等

正解の根拠・詳細解説

条件付き起動（Conditional Launch）は、アプリ保護ポリシーの中でアプリが起動される瞬間にデバイスやアプリの状態を評価し、条件を満たさない場合にあらかじめ決めたアクションを実行する仕組みである。評価できる条件には、PIN の試行回数の上限、オフラインでの猶予期間、最小 OS バージョン、最小アプリバージョン、脱獄・root 化されたデバイスの検知、Defender が報告するデバイス脅威レベルなどがあり、アクションとしては警告の表示、アプリのアクセスのブロック、そして業務データの消去（選択的ワイプ）を選べる。これにより、MDM 登録していない私物端末に対しても「古い OS のまま業務データを扱わせない」「改造された端末からはデータを消す」といった実効的な制御ができる。B・C・D はいずれもデバイス側のポリシーであり条件付き起動の設定項目ではない。

正解: A. A. 組織で購入したiOS/iPadOSアプリのライセンスを一括管理・割り当てする

正解の根拠・詳細解説

Apple のボリューム購入（旧 VPP、現在は Apple Business Manager の「アプリとブック」）と Intune を連携させると、組織がまとめて購入した iOS/iPadOS や macOS のアプリライセンスを Intune 側で一元管理し、ユーザーまたはデバイス単位で割り当て・回収できるようになる。ABM で取得したトークンを Intune にアップロードすると購入済みアプリの情報が同期され、Intune のアプリ一覧からライセンスの消費状況を確認しながら配布できる。ライセンスの割り当て方式には、個人の Apple ID に紐づくユーザーライセンスと、Apple ID を必要としないデバイスライセンスがあり、共用端末やキオスク用途では後者が適する。退職者からライセンスを回収して別のユーザーへ再割り当てできる点も、個人購入では得られない大きな利点になる。B・C・D は Apple のボリューム購入とは無関係である。

正解: A. A. 組織が独自に開発した社内アプリのインストーラーファイルを直接アップロードして配布する

正解の根拠・詳細解説

LOB（Line-of-Business）アプリは、組織が自社開発した、あるいは公開ストアに掲載されていない業務専用アプリを配布するためのアプリ種別で、インストーラーファイル（Android なら .apk、iOS/iPadOS なら .ipa、Windows なら .msi や .appx／.msix など）を Intune へ直接アップロードして配布する。パブリックストアの審査や掲載を経る必要がないため、社内限定のアプリを外部に公開せず展開できる。ただし iOS の場合はアプリが適切な配布用プロビジョニング プロファイルで署名されている必要があり、その有効期限が切れるとアプリが起動しなくなるため、期限管理と再署名・再アップロードの運用が必須になる。なお Windows 向けの複雑なインストーラーは、より柔軟な検出規則や依存関係を扱える Win32 アプリ（.intunewin）として配布することも可能で、D の記述は誤りである。

正解: A. A. 特定グループから不要になったアプリを強制的に削除する

正解の根拠・詳細解説

アンインストール（Uninstall）の割り当て意図は、対象のユーザーまたはデバイスから指定したアプリを自動的に削除させるためのもので、ライセンス契約が終了した製品、脆弱性が判明して使用を禁止した製品、別製品へ移行して不要になったアプリを組織的に一掃する場面で使う。Win32 アプリの場合は、アプリ登録時に指定したアンインストールコマンドラインが実行されるため、そのコマンドがサイレントで確実に動作することを事前に検証しておく必要がある。実務上の注意点として、同じアプリが同一の対象に対して「必須」と「アンインストール」の両方で割り当てられていると意図が競合するため、移行時は古い必須割り当てを外してからアンインストール割り当てを行う、という順序を守ることが重要になる。B・C・D はこの意図の用途ではない。

正解: A. A. Microsoft Storeとの連携設定（テナント登録）を有効化する

正解の根拠・詳細解説

Microsoft Store のアプリを Intune 経由で配布する従来の方式では、Microsoft Store for Business／for Education にテナントを関連付け、Intune 側でストアとの同期を有効化するという前提設定が必要だった。この関連付けを行わないとストアの購入済みアプリが Intune に同期されず、割り当ての対象として選択できない。現在は「Microsoft Store アプリ（新）」というアプリ種別が用意され、Intune の画面からストアのカタログを直接検索してアプリを追加できるようになっているため、代わりにデバイスが Store および関連サービスのエンドポイントへ通信できることが実質的な前提条件になる。プロキシやファイアウォールでストアへの通信が遮断されているとインストールが失敗するため、通信要件の確認が実務上の確認ポイントになる。C の Win32 Content Prep Tool は自前パッケージを配布する場合のツールで、ストアアプリには不要である。

正解: A. A. 業務アプリから個人アプリへのコピー&ペースト・「アプリで開く」操作の制限

正解の根拠・詳細解説

アプリ保護ポリシーのデータ転送に関する設定では、ポリシー管理対象アプリが扱う業務データが、管理されていない個人アプリへ流出しないよう境界を引くことができる。具体的には、他のアプリへ組織データを送信できる範囲（すべてのアプリ／ポリシー管理対象アプリのみ／なし）、他のアプリから組織アプリへデータを受信できる範囲、他アプリとの間で切り取り・コピー・貼り付けを許可する範囲、組織データを保存できる保存先（OneDrive for Business や SharePoint のみに限定し、ローカルや個人のクラウドストレージへの保存を禁止する）などを指定する。これにより、たとえば Outlook の添付ファイルを個人のメモアプリへ「別のアプリで開く」といった操作を遮断できる。B・C・D はいずれもデバイス側の構成であり、アプリ保護ポリシーの設定項目ではない。

正解: A. A. Android EnterpriseとマネージドGoogle Playアカウントの連携設定

正解の根拠・詳細解説

Intune から Android のアプリを配布するには、事前にテナントを Android Enterprise（マネージド Google Play）と接続しておく必要がある。テナント管理の Android 登録画面から Google Play の管理アカウントを作成して結び付けると、Intune のアプリ一覧からマネージド Google Play のカタログを直接参照し、必要なアプリを承認して配布対象に追加できるようになる。この連携は Work Profile・フルマネージド・デディケイテッドといった Android Enterprise の各登録方式に共通する前提であり、連携がない状態では登録もアプリ配布も行えない。なお、この接続はテナント全体で 1 つのマネージド Google Play アカウントに紐づき、個人の Google アカウントは不要である点も特徴になる。B の BitLocker、C の Apple Business Manager、D の Windows Autopilot はいずれも他プラットフォームの仕組みである。

正解: A. A. あるアプリのインストール前に必要な前提アプリ（例: ランタイム）を自動的に先にインストールする

正解の根拠・詳細解説

Win32 アプリの依存関係（dependency）は、あるアプリをインストールする前に必ず存在していなければならない前提アプリを指定する機能で、たとえば .NET ランタイム、Visual C++ 再頒布可能パッケージ、独自の共通ライブラリなどを先に導入させたい場合に使う。依存関係として登録したアプリには「自動インストールする」かどうかを指定でき、自動インストールを有効にすれば、対象アプリの配布時に前提アプリが未導入であれば Intune が先にそれを展開してから本体のインストールを進める。依存関係は入れ子にもでき、複数階層の前提条件を表現できる。ただし依存関係の連鎖が深くなると失敗時の切り分けが難しくなり、いずれかの前提アプリの検出規則が誤っているだけで本体が延々と保留状態になるため、階層は必要最小限に抑えるのが実務上の原則になる。

正解: A. A. 新バージョンのアプリで旧バージョンを自動的に置き換える（アップグレード）

正解の根拠・詳細解説

置き換え（supersedence）は、Win32 アプリに設定できる関係で、新しいバージョンのアプリが旧バージョンを置き換えることを Intune に伝える機能である。置き換え関係を定義したうえで新バージョンを配布すると、旧バージョンがインストールされている端末では、旧バージョンをアンインストールしてから新バージョンを入れる、あるいはアンインストールせずに上書き更新する（アプリ自身のアップグレード動作に任せる）という挙動を選択できる。これにより、旧バージョンの割り当てを手作業で外して回る運用が不要になり、バージョン移行を一つのワークフローとして管理できる。注意点として、置き換えを設定する際は旧バージョンのアンインストールコマンドと新バージョンの検出規則が正確であることが前提で、これを誤ると更新が失敗したまま滞留する。B のように完全削除を目的とする機能ではない。

正解: A. A. 通常MDMのアプリ保護設定が優先され、重複適用を避けるよう設計を検討する必要がある

正解の根拠・詳細解説

デバイスが Intune に MDM 登録されている状態で、同じユーザーにアプリ保護ポリシー（MAM）も割り当てられている場合、そのアプリはデバイス側の構成とアプリ側の保護設定の両方の影響を受けることになる。両者が同じ領域（たとえばアプリのデータ保護やコピー制限に関わる挙動）を別々に定義していると、意図した動作にならなかったり、利用者から見て理由の分からない制限が発生したりする原因になる。したがって設計時には、どの制御をどちらの仕組みで担わせるかを整理し、重複を避けることが重要になる。実務上有効な手立てとして、アプリ保護ポリシーの割り当て時にデバイスの種類（マネージド／アンマネージド）を指定し、MAM ポリシーの適用対象を未登録の私物端末だけに絞るという方法がある。B・C のようにどちらかが完全に無効化されるわけでも、D のように登録が解除されるわけでもない。

正解: A. A. 対象アプリへのアクセス時に、適切なアプリ保護ポリシーが適用された状態であることを要求する

正解の根拠・詳細解説

条件付きアクセスの許可条件にある「承認されたクライアント アプリが必要」や「アプリの保護ポリシーが必要」を設定すると、対象のクラウドアプリへアクセスする際に、Intune のアプリ保護ポリシーが適用された状態のアプリからのアクセスであることが要求される。これにより、たとえば私物のスマートフォンで標準のメールアプリや任意のサードパーティ製アプリから Exchange Online に接続しようとしても拒否され、保護ポリシーが効いている Outlook からのみ接続できる、という制御が実現する。デバイスの登録を前提にしないため BYOD と相性がよく、「端末は管理しないがデータは守る」という方針を技術的に担保できる点が大きい。C のようにデバイスの登録（準拠）を要求するのは別の条件であり、両者は目的も前提も異なるので混同しないよう注意したい。

正解: A. A. 「管理対象アプリ」へのコピー&ペーストのみ許可する制限

正解の根拠・詳細解説

アプリ保護ポリシーのデータ転送設定にある「切り取り、コピー、貼り付けを他のアプリと共有する」を「ポリシーで管理されたアプリ」に設定すると、業務データのコピー＆ペーストがポリシー適用済みのアプリ同士の間だけに制限され、個人利用のメモアプリや SNS アプリへの貼り付けが遮断される。これは業務データの利便性を大きく損なわずに漏えい経路を塞ぐ、実務でバランスの取れた設定として広く採用されている。B のようにすべてのアプリへのコピーを許可すれば保護にならず、C のようにコピー機能を完全に無効化すると業務効率が著しく落ちて利用者が別の抜け道を探す原因になる。関連設定として、貼り付け可能な文字数の上限を設ける項目もあり、パスワードなど短い文字列のコピーだけを許容するといった細かな調整も可能である。D の BitLocker はデバイスの暗号化であり、アプリ間のデータ移動を制御するものではない。

正解: A. A. アプリのインストール状態レポートとエラーコード

正解の根拠・詳細解説

アプリのインストール失敗を調査する際は、Intune 管理センターで対象アプリの「デバイスのインストール状態」「ユーザーのインストール状態」レポートを開き、成功・失敗・保留中の内訳と、失敗したデバイスに記録されているエラーコードを確認するのが基本手順になる。エラーコードを手がかりに、ディスク容量不足、依存関係アプリの未解決、要件（OS バージョンやアーキテクチャ）の不一致、検出規則の誤りによる誤判定、インストールコマンドのサイレント実行オプションの不備、ネットワークやプロキシによるコンテンツ取得の失敗といった原因を切り分ける。Win32 アプリの場合はクライアント側の Intune 管理拡張機能（IME）のログが残るため、より詳細な原因を追跡できる。B・C・D はアプリのインストール成否とは無関係な情報である。

正解: A. A. リアルタイムのセッション制御によるリスクベースのアクセス判断

正解の根拠・詳細解説

Microsoft Defender for Cloud Apps（旧 MCAS）は、条件付きアクセスのアプリ制御と組み合わせることで、サインインの可否を判定する一度きりの制御にとどまらず、セッションが継続している間ずっとユーザーの操作を監視し、リスクに応じて制御を加えられる点に特徴がある。セッションポリシーでは、ファイルのダウンロードのブロックやダウンロード時の秘密度ラベルの自動付与、コピー＆ペーストや印刷の制限、不審な操作の監視といったリアルタイムのアクションを定義でき、これを Intune のアプリ保護ポリシーによるアプリ内保護と重ねることで、管理外の端末やブラウザ経由のアクセスに対しても多層的にデータを保護できる。B の BitLocker キーの状態、C のファイアウォールルール、D の ASR ルールはいずれもデバイス側の構成情報であり、セッション中の動的なリスク判断に利用されるものではない。

正解: A. A. Company Portal上でアプリを分類し、ユーザーが目的のアプリを見つけやすくする

正解の根拠・詳細解説

アプリカテゴリを設定すると、Company Portalのアプリ一覧がジャンル別に整理され、ユーザーの検索性が向上する。 ドメイン⑤：エンドポイント運用の最適化（15問） 出題比率10〜15%。Endpoint Analytics、プロアクティブな修復スクリプト、レポート・ワークブック、テナント運用監視など、運用フェーズの効率化範囲です。

正解: A. A. 組み込みレポートのフィルター・列のカスタマイズおよびエクスポート

正解の根拠・詳細解説

Intune の「レポート」には、デバイスのコンプライアンス、構成プロファイルの適用状況、アプリのインストール状態、更新プログラムの展開状況などを扱う組み込みレポートが多数用意されており、これらは表示する列の選択、条件によるフィルター、期間の指定といったカスタマイズが可能で、結果を CSV などの形式でエクスポートできる。エクスポートしたデータを Excel や BI ツールで加工すれば、経営層向けの定例報告や監査対応の証跡として利用できる。さらに大規模な分析が必要な場合は、診断設定で Intune のログを Azure Monitor の Log Analytics ワークスペースへ送り、ワークブックで独自のダッシュボードを構築するという発展的な方法もある。B・C・D はレポート機能とは無関係で、Intune のレポートはあくまで既存データの可視化と抽出を担う機能である。

正解: A. A. デバイスの起動・サインインに要する時間の傾向

正解の根拠・詳細解説

エンドポイント分析（Endpoint Analytics）のスタートアップ パフォーマンス レポートは、デバイスの電源投入からデスクトップが利用可能になるまでに要する時間を、起動フェーズとサインインフェーズに分けて可視化する。単に平均値を示すだけでなく、どのデバイスモデルが遅いのか、起動時に実行されるアプリやグループポリシーの処理がどれだけ時間を消費しているのかといった内訳まで確認できるため、体感の遅さに対する客観的な根拠を得られる。これにより、買い替え対象とすべき機種の特定、スタートアップアプリの整理、不要なログオンスクリプトの削減といった具体的な改善策につなげられる。利用者からの「PC が遅い」という漠然とした申告を、数値で裏付けて優先順位を付けられる点が実務上の価値になる。B・C・D はスタートアップ パフォーマンスの指標ではない。

正解: A. A. 検出スクリプトで問題を検知し、該当する場合のみ修復スクリプトを実行する

正解の根拠・詳細解説

修復（Remediations、旧称 Proactive Remediations）は、検出スクリプトと修復スクリプトの 2 つの PowerShell スクリプトを組み合わせて、問題を自動的に見つけて直す仕組みである。まず検出スクリプトが対象デバイス上で状態を確認し、問題がなければ終了コード 0 を返して何も起きず、問題を検知した場合のみ非ゼロを返すことで修復スクリプトが実行される。この 2 段構えにより、B のように全デバイスへ無条件に変更を加えることなく、必要な端末にだけ最小限の変更を適用できる。証明書の期限切れ、レジストリ設定の逸脱、サービスの停止、ディスクの空き容量不足といった典型的な不具合を、利用者からの問い合わせが発生する前に解消できるため、ヘルプデスクの負荷削減に直結する。なお本機能の利用には対象デバイスに応じた上位ライセンスが必要になる点も押さえておきたい。

正解: A. A. 原因（再起動頻度・アプリクラッシュ等）を分析し、修復スクリプトや設定変更で改善する

正解の根拠・詳細解説

エンドポイント分析のスコアが低いデバイスに対しては、まずスコアを構成している要素、すなわち起動やサインインに要する時間、予期しない再起動やブルースクリーンの発生頻度、アプリのクラッシュや応答停止の状況といった内訳を確認して、何が足を引っ張っているのかを特定する。そのうえで、ドライバーやファームウェアの更新、問題のあるアプリのバージョン更新や置き換え、スタートアップアプリの整理、修復（Remediations）スクリプトによる自動是正といった具体的な対策を打ち、改善後にスコアの推移を確認して効果を検証する。この「計測 → 原因分析 → 対処 → 再計測」のサイクルを回すことが本機能の狙いであり、B のように即座に廃棄するのは費用対効果の面でも短絡的な対応になる。C・D はスコアの改善とは無関係である。

正解: A. A. アプリのクラッシュ頻度や応答停止の発生状況

正解の根拠・詳細解説

エンドポイント分析のアプリの信頼性（App reliability）スコアは、管理下のデバイスで実行されているアプリについて、クラッシュや応答停止（ハング）がどの程度の頻度で発生しているかを集計し、利用者体験を損なっているアプリを特定するための指標である。アプリごと、あるいはデバイスごとに問題の発生状況を確認できるため、「特定のバージョンのアプリを入れた端末群でだけクラッシュが多発している」といった相関を早期に見つけられる。実務では、この情報を基にアプリのバージョン更新や設定変更、場合によっては別製品への置き換えを判断し、利用者から個別に苦情が来る前に手を打てる点が価値になる。B の費用や C の著作権情報はこのスコアの評価対象ではなく、D のストレージ使用量だけを見るものでもない。

正解: A. A. Microsoft 365管理センターのサービス状態（Service Health）とIntuneのメッセージセンター

正解の根拠・詳細解説

Intune を含む Microsoft 365 サービスの稼働状況や計画的な変更を把握するには、Microsoft 365 管理センターのサービス正常性（Service Health）と、メッセージセンターの 2 つを確認する。サービス正常性は現在発生している障害や機能低下、その影響範囲と復旧見込みを示すもので、「ポリシーが配信されない」「ポータルにアクセスできない」といった事象が自社固有の問題なのかサービス側の障害なのかを切り分ける第一の手がかりになる。一方メッセージセンターは、新機能の追加、既存機能の変更、廃止予定といった今後の予定を管理者へ事前に通知するもので、運用への影響を先読みして準備するために定期的な確認が欠かせない。障害調査の際は、自環境の設定を疑って時間を溶かす前にまずサービス正常性を見る、という順序が実務上の鉄則になる。

正解: A. A. コンプライアンス変更に対するアラートルールの設定

正解の根拠・詳細解説

デバイスが一度は準拠と判定されても、設定の変更、更新の未適用、暗号化の解除といった要因で後から非準拠へ転じることがあり、これを放置すると気付かないうちに保護されていない端末が増えていく。これを早期に把握するには、コンプライアンスの状況を継続的に監視し、準拠率が急落するなど注意すべき変化が起きた時点で管理者へ通知が届くようにしておくことが有効である。Intune のアラート ルールでは監視対象の条件としきい値、重大度、通知先のメールアドレスを設定でき、条件に合致した際に管理センター上の通知やメールで知らせてくれる。さらに詳細な監視が必要な場合は、診断設定で Intune のログを Log Analytics へ送り、Azure Monitor 側でカスタムのアラートを構成するという方法もある。B・C・D はいずれも準拠状態の逸脱を検知する手段にはならない。

正解: A. A. Azure Monitor／Log Analyticsのデータを使ったカスタムダッシュボードの作成

正解の根拠・詳細解説

Intune のワークブック（Workbooks）は、Azure Monitor が提供する可視化機能で、診断設定によって Log Analytics ワークスペースへ送信した Intune のログデータを、クエリ（KQL）とグラフ・表を組み合わせた独自のダッシュボードとして表現できる。組み込みレポートでは表現できない切り口、たとえば長期間にわたる準拠率の推移、特定エラーコードの発生傾向、部門横断での比較といった分析を自由に組み立てられる点が利点になる。前提として、Intune 側で診断設定を構成し、対象のログカテゴリを Log Analytics ワークスペースへ転送しておく必要があり、ワークスペースのデータ保持期間と取り込み量に応じた Azure の費用が発生する点も設計時に考慮すべき事項になる。B・C・D はワークブックの用途ではない。

正解: A. A. 実行頻度（毎日・毎週等）と実行時刻のオフセット

正解の根拠・詳細解説

修復（Remediations）スクリプトを作成する際は、検出と修復のスクリプトをアップロードするだけでなく、実行に関するオプションとスケジュールを構成する。スケジュールでは、1 回だけ実行するのか、1 時間ごとに繰り返すのか、1 日ごとに指定した時刻に実行するのかといった頻度と時間を指定でき、実行タイミングを分散させることで、多数の端末が同時にスクリプトを走らせて業務やネットワークに影響を与える事態を避けられる。あわせて、サインイン中のユーザーの資格情報で実行するか、64 ビットの PowerShell で実行するか、スクリプトの署名チェックを行うかといった実行コンテキストも指定できる。展開後は検出・修復の結果と終了コードをレポートで確認し、想定どおりに動作しているかを検証することが重要になる。B・C・D はこの設定項目ではない。

正解: A. A. 組織全体のセキュリティ体制の遵守状況を定量的に示す

正解の根拠・詳細解説

デバイスのコンプライアンス概要レポートは、組織全体で何台のデバイスが準拠・非準拠・猶予期間中・未評価のいずれの状態にあるかを集計して示すもので、セキュリティ体制の遵守状況を数値として提示できる。経営層や監査部門への報告では、個別デバイスの技術的な詳細よりも「全社の何％が定めた基準を満たしているか」「前四半期と比べて改善しているか」といった定量的な傾向が求められるため、このレポートはガバナンス報告の根拠資料として適している。あわせて、非準拠の内訳（暗号化未実施、OS バージョン不足など）を示せば、改善に必要な投資や施策の優先順位を議論する材料にもなる。B のように個人のファイルを覗くための機能ではなく、C のように回復キーを公開する用途でもない点は、プライバシーとセキュリティの観点から明確に区別しておく必要がある。

正解: A. A. CSV形式でのエクスポート

正解の根拠・詳細解説

Intune の多くの組み込みレポートは、画面上での閲覧に加えて CSV 形式でのエクスポートに対応しており、抽出したデータを Excel や BI ツールに取り込んで独自の集計・可視化を行える。これにより、監査で求められる特定時点の一覧の保全、資産管理システムとの突合、部門別の集計といった、管理センターの画面だけでは完結しない業務に対応できる。大量のデータを扱うレポートではエクスポート処理が非同期で行われ、生成完了後にダウンロードする方式になる点も実務上知っておくとよい。さらに自動化したい場合は、Microsoft Graph の API を通じてレポートデータを取得し、定期的に社内システムへ連携するという方法もある。C のように PDF のみに限られるわけではなく、D のようにエクスポートできないわけでもない。

正解: A. A. Entraグループによるスコープ（範囲）の絞り込み

正解の根拠・詳細解説

エンドポイント分析では、Microsoft Entra のグループを使って集計対象のスコープを絞り込めるため、部門別・拠点別・機種別といった単位でスコアやパフォーマンス指標を比較できる。これにより、「特定の拠点だけ起動時間が突出して長い」「ある部門でだけアプリのクラッシュが多い」といった偏りを発見し、原因を局所化して調査できる。加えて、比較の基準となるベースラインとして、全商用テナントの中央値を用いる既定のベースラインのほか、自組織の特定時点の値を保存した独自ベースラインを作成でき、施策の前後で改善したかどうかを客観的に評価できる。前提として、対象デバイスがエンドポイント分析に登録され、データを送信していることが必要になる。B・C・D はエンドポイント分析のスコープ指定に用いる要素ではない。

正解: A. A. 今後の機能変更・廃止予定・サービス更新に関するお知らせ

正解の根拠・詳細解説

メッセージセンターは、Microsoft 365 管理センター内にある管理者向けの通知窓口で、Intune を含む各サービスについて、新機能の追加、既存機能の仕様変更、非推奨化や廃止の予定、必要となる対応作業といった運用上重要な情報が事前に届けられる。障害情報を扱うサービス正常性とは役割が異なり、こちらは「これから起きる変更」に備えるためのものである。廃止予定の機能を使い続けていると、ある日を境にポリシーが機能しなくなるといった事態を招くため、定期的に確認し、必要に応じて代替手段への移行計画を立てることが管理者の重要な業務になる。通知はメールで受け取るよう構成でき、関連する担当者へ転送することもできる。B のパスワードや C の暗号化キー、D のソースコードといった機微な情報がここに流れることはない。

正解: A. A. 現在のデバイス健全性・コンプライアンス率などの現状値

正解の根拠・詳細解説

運用改善に取り組む際にまず行うべきなのは、現状を定量的に把握して基準値（ベースライン）を確定させることである。具体的には、エンドポイント分析のスコアや起動・サインイン時間、アプリの信頼性、デバイスのコンプライアンス準拠率、更新プログラムの適用率、登録エラーの発生件数といった指標を測定し、記録しておく。基準値がなければ、施策を実施した後にそれが本当に効果を上げたのかを証明できず、改善活動が主観的な感想の域を出なくなってしまう。エンドポイント分析では自組織の値を独自ベースラインとして保存し、全商用テナントの中央値と比較することもできるため、社内の推移と業界水準の両面から評価できる。B の将来価格や C の他社事例は参考情報にはなり得ても、自組織の改善効果を測る基準にはならない。

正解: A. A. 異常検知や高度なベンチマーク分析などのより深いインサイト

正解の根拠・詳細解説

Endpoint Analyticsは標準機能として起動時間やアプリの信頼性などをスコア化し、組織全体の傾向を把握できるようにする。Intune Suiteアドオンに含まれるAdvanced Analyticsは、この分析基盤をさらに拡張するもので、異常検知によってクラッシュやポリシー適用失敗の急増を自動的に検出し、影響を受けているデバイス群を絞り込める。加えて、対象デバイスに対してリアルタイムに状態を問い合わせるデバイスクエリや、部署や機種などのセグメント単位での比較、より詳細なレポートが利用できる。いずれも「見えていなかった状態を可視化し、問題が広がる前に手を打つ」ための分析強化であり、ユーザーからの問い合わせが来る前に不具合の予兆を掴むプロアクティブな運用に役立つ。一方、BのBitLocker暗号化の高速化やCのファイアウォールのステルスモードはOS側の機能であって分析アドオンの守備範囲ではなく、Dのアプリライセンスの自動購入という機能も提供されない。