Intune（Microsoft Endpoint Manager）で「○分間操作がなかったら画面をロックする」ポリシーを配布したのに、管理画面では成功なのに端末がロックされない――。この症状は、再起動待ちの反映遅れや、別プロファイルによる上書き、Intune 画面上の分かりにくい表示名が原因で発生しがちです。本記事では、Windows 10 環境で“確実に”画面ロックを効かせる手順と、どの構成プロファイルが設定しているかを洗い出す方法をまとめます。
症状を整理：Intune では「適用済み」なのに Windows 10 で画面ロックされない
現場でよくあるのが、以下の組み合わせです。
- Intune から「一定時間の非アクティブで画面ロック」ポリシーを配布した
- Intune 管理センター上のステータスは「成功」「適用済み」に見える
- しかし端末側では、待ってもロック画面に切り替わらない／意図した時間でロックされない
- 構成プロファイルが多すぎて、どれが画面ロック時間を触っているのか追えない
結論から言うと、画面ロックは「設定して終わり」ではなく、反映タイミング（再起動）と競合（上書き）が非常に起きやすいカテゴリです。まずは仕組みを押さえたうえで、最短距離で直しましょう。
まず押さえる：画面ロックに見えるものは 4 種類ある
トラブルシュートで混乱しやすいのが、「画面が暗くなる」「スクリーンセーバー」「スリープ」「ロック」が似て見える点です。Intune の設定名も紛らわしいことがあるため、最初に整理しておくと失敗が減ります。
| 現象 | ユーザー視点の見え方 | 主に関係する設定 | 勘違いしやすいポイント |
|---|---|---|---|
| 画面ロック | ロック画面が出てサインインが必要（パスワード/Windows Hello） | DeviceLock（例：MaxInactivityTimeDeviceLock） | 「電源オフ」や「スクリーンセーバー」と混同しやすい |
| スクリーンセーバー | スクリーンセーバーが起動（黒画面やアニメーション等） | スクリーンセーバーのタイムアウト、パスワード保護 | スクリーンセーバーが動かない＝ロックしない、とは限らない |
| ディスプレイ電源オフ | 画面が消える（入力すると戻る） | 電源プラン（ディスプレイのオフ） | 画面が消えてもロックされていない場合がある |
| スリープ | 復帰時にサインインが必要/不要（設定次第） | 電源とスリープ、復帰時のサインイン要件 | 「ロックさせたい」のにスリープで代替しようとして不整合が出る |
本記事の主題は「非アクティブ時間で確実に画面ロックさせる」です。スクリーンセーバーや電源プランは補助的な要素として扱い、まずは DeviceLock を軸に設計・検証します。
原因の全体像：効かないときは「反映待ち」か「上書き」か「見落とし」
Intune で画面ロックが効かない問題は、ほぼ次の 3 パターンに収束します。
| パターン | 管理画面の見え方 | 端末の挙動 | 最優先の切り分け |
|---|---|---|---|
| 反映待ち（再起動が必要） | 成功/適用済み | ロックされない、または古い値のまま | 端末を「再起動」したか（シャットダウンでは不十分な場合あり） |
| 別プロファイル・GPO・ローカル設定の上書き | 成功/適用済み（競合が見えないことも） | 意図しない分数でロック、またはロックしない | 同種の設定が別の場所で有効になっていないか |
| 設定名の誤解・設定箇所の見落とし | 「それっぽい設定」を入れたつもり | 期待と違う | OMA-URI（CSP）の実体名で追う（MaxInactivityTimeDeviceLock をキーにする） |
ここからは、原因別に「なぜ起きるのか」と「どう直すか」を、手順に落として解説します。
原因：DeviceLock 系ポリシーは、適用後に再起動が必要になることがある
Intune で配布したポリシーは端末に同期されますが、設定の種類によっては即時に UI/挙動へ反映されず、再起動後に初めて有効化されるケースがあります。DeviceLock もその代表例で、管理センターの表示が「成功」でも、端末側が古い状態のまま残ることがあります。
特に注意：「シャットダウン→起動」ではなく「再起動」を使う
Windows 10 は環境によって「高速スタートアップ（Fast Startup）」が有効だと、シャットダウンが完全な再起動にならず、ポリシー反映の切り替えが起きにくいことがあります。検証時は以下を徹底すると事故が減ります。
- ポリシー配布後は、まず端末を再起動する
- 「電源を切って入れ直した」ではなく、OS の再起動で反映確認する
- 検証中は値を 1 分など短くして、反映を素早く確認する
再起動を前提にした運用にするコツ
画面ロックはセキュリティ要件に直結することが多く、検証だけでなく運用でも「反映のための再起動」を設計に含めるのが現実的です。
- 段階配布（テスト端末 → パイロットグループ → 全社）で、再起動が必要な設定が混ざっていないか先に確認する
- ユーザー影響が大きい場合は、再起動を促すガイダンス（社内周知）をセットで用意する
- 「配布したのに効かない」という問い合わせの初動チェックに「再起動済みか」を入れておく
原因：別の構成プロファイルが画面ロック時間を上書きしている
次に多いのがこれです。Intune は構成プロファイルが増えるほど、同じ系統の設定が複数箇所に散らばりやすくなります。画面ロック系は特に、次のようなルートで「知らないうちに」上書きが起きます。
- Windows 10 用の「パスワード」関連プロファイルに、Maximum Minutes of Inactivity Until Screen Locks が入っている
- セキュリティベースライン（Security Baseline）側で近い設定を触っている
- オンプレ AD のグループポリシー（GPO）で「マシンの非アクティブ制限」を設定している
- ローカル セキュリティ ポリシーやレジストリが残っている
「使っていないつもり」でも値が入っていると有効になる落とし穴
Intune の設定は、項目が「未構成」なら影響しませんが、値が入っているだけで有効化され、他の設計を上書きします。前任者が試験的に入れた値が残っていたり、テンプレート流用で意図せず有効になっていることが珍しくありません。
画面ロックに関係しやすい設定箇所（上書き元の候補）
「どこを見ればいいか」を最短にするため、候補を表でまとめます。環境によってすべてが存在するわけではありませんが、まずは上から順に疑うのがおすすめです。
| 上書き元の候補 | 管理場所 | 見つけ方 | ありがちな事故 |
|---|---|---|---|
| Intune 構成プロファイル（パスワード系） | 構成プロファイル > Windows 10/11 > パスワード | Maximum Minutes of Inactivity Until Screen Locks の有無 | 「使ってないのに値が入っていた」 |
| Intune カスタム（OMA-URI） | 構成プロファイル > カスタム | MaxInactivityTimeDeviceLock を検索 | 同じ OMA-URI を複数プロファイルで配布 |
| セキュリティベースライン | エンドポイント セキュリティ > セキュリティ ベースライン | ベースラインの割り当てと設定内容を確認 | ベースライン側の“標準値”が想定外に効く |
| GPO（ドメイン） | オンプレ AD（グループポリシー管理） | 端末で gpresult /h などで適用状況を確認 | Intune と GPO の二重管理で値がぶれる |
| ローカル セキュリティ ポリシー/レジストリ | 端末ローカル | セキュリティ オプション、レジストリ値の残存を確認 | 過去の設定が残り続ける |
原因：Intune の表示名・説明が分かりにくく、設定を見誤る
画面ロックの設定は、実体としては OMA-URI（CSP）で管理されますが、Intune の UI では「ロック画面の非アクティブ時間」「スクリーンセーバーが動くまでの時間」のように、実際の挙動とズレた表現で表示されることがあります。
このズレが起きると、管理者側が次のように迷子になります。
- 「ロックの設定を入れたつもりなのに効かない」
- 「スクリーンセーバーの設定を触っただけだった」
- 「同じ意味に見える設定が複数あって、どれが本命か分からない」
対策はシンプルで、画面ロックの議論をするときは、UI 名ではなく OMA-URI 名（MaxInactivityTimeDeviceLock）を主語にすることです。引き継ぎ環境でも、これだけで整理が一気に進みます。
| 現場でよく見る UI 表記 | 実務上の整理の仕方 | 見るべきキーワード |
|---|---|---|
| ロック画面の非アクティブ時間 | DeviceLock のロック時間設定か？を疑う | MaxInactivityTimeDeviceLock / DeviceLock |
| 非アクティブ状態が続いたときに画面をロックするまでの最大分数 | パスワード系プロファイルの上書き候補 | Maximum Minutes of Inactivity Until Screen Locks |
| スクリーンセーバー関連の説明 | ロックではなくスクリーンセーバー設定の可能性 | Screen saver / timeout / password protect |
推奨の解決策：OMA-URI（カスタム）で MaxInactivityTimeDeviceLock を明示して確実に効かせる
「最短で直したい」「競合を避けたい」「意図した値を確実に配布したい」という場合は、OMA-URI のカスタムプロファイルで MaxInactivityTimeDeviceLock を明示するのが堅いです。UI の表記揺れに引きずられず、設定の実体をそのまま指定できます。
設定の作成手順（Windows 10 以降 / カスタム）
- Intune で新しい構成プロファイルを作成
- プラットフォーム：Windows 10 以降
- プロファイルの種類：カスタム
カスタム設定は以下の通りです。
| 項目 | 設定値（例） | ポイント |
|---|---|---|
| 名前 | ScreenLock（任意） | 後から検索しやすい命名にする（例：ScreenLock-DeviceLock） |
| OMA-URI | ./Device/Vendor/MSFT/Policy/Config/DeviceLock/MaxInactivityTimeDeviceLock | この URI を軸に調査・運用すると迷子になりにくい |
| データ型 | Integer（整数） | 文字列ではなく整数 |
| 値 | 1 / 15 など（分） | 検証は 1 分、本番は要件に合わせる |
配布後の手順：成功確認 → 再起動 → 動作確認
ここが最重要です。管理画面の成功だけで判断せず、次の流れで確認します。
- 対象グループに割り当てる
- 配布ステータスが「成功」になったことを確認する
- クライアント PC を再起動する
- 再起動後、設定した分数だけ操作せず放置し、ロックされるか確認する
検証のコツとして、以下も合わせると切り分けが早くなります。
- まずは 1 分で試し、効いたら本番値に戻す
- 動画再生・会議アプリ・プレゼン表示など、操作がなくても「システムを起こし続ける」アプリが動いていない状態で試す
- 「マウスが動いている」「USB デバイスが入力扱いになる」環境（ドック、周辺機器）では、完全なアイドルになっているか注意する
競合対策：既存の「Maximum Minutes of Inactivity Until Screen Locks」を確認し、未構成に戻す
カスタム OMA-URI で正しい値を入れても、別のプロファイルが同等の項目を持っていると、端末側ではどちらが勝つかが分かりにくくなります。特に見落としやすいのが、Windows 10 用の「パスワード」関連プロファイルにある、以下の項目です。
Maximum Minutes of Inactivity Until Screen Locks
（日本語環境では「非アクティブ状態が続いたときに画面をロックするまでの最大分数」など）
確認手順（管理側）
- Intune 管理センターで「デバイス」→「構成プロファイル」を開く
- Windows 10/11 向けのプロファイルを、パスワード関連を中心に確認する
- 各プロファイル内で、Maximum Minutes of Inactivity Until Screen Locks に値が入っていないか確認する
- 画面ロック時間を別の場所（今回の OMA-URI など）で統一したい場合は、この項目を未構成（Not configured）に戻す
- 再配布後、端末を再起動し、意図した分数でロックされるか確認する
「未構成」にする判断基準
運用としては、次のいずれかに寄せるのがおすすめです。
| 運用方針 | おすすめの設定場所 | 向いている組織 |
|---|---|---|
| 画面ロックは OMA-URI で統一 | カスタム（MaxInactivityTimeDeviceLock） | プロファイルが多く、表示名の揺れで混乱しやすい |
| 画面ロックはパスワード系プロファイルで統一 | パスワード設定（Maximum Minutes of Inactivity…） | プロファイル数が少なく、テンプレートで管理したい |
| オンプレ GPO と整合させたい | GPO を主・Intune は最小限 | ドメイン管理が中心で、Intune は補助的 |
大事なのは「同じ意味の設定を複数箇所で同時に持たない」ことです。混在させると、問い合わせ対応・監査対応・引き継ぎのいずれもコストが跳ね上がります。
引き継ぎ環境向け：どのプロファイルが画面ロック時間を配布しているか調べる方法
構成プロファイルが大量にある環境ほど、「どの設定が効いているか」を管理側だけで追うのは難しくなります。そんなときは、端末側の“エクスポート レポート”を使って、実際に入っている MDM 設定から逆引きするのが早いです。
端末側で確認する手順（Export a report）
- 対象 PC で「設定」アプリを開く
- 「アカウント」→「職場または学校にアクセスする」へ移動する
- 対象の職場/学校アカウントをクリックし、「情報」画面を開く
- 「エクスポート レポート（Export a report）」を実行し、HTML レポートを出力する
- 出力された HTML をブラウザーで開き、MaxInactivityTimeDeviceLock または DeviceLock で検索する
- 該当箇所に、どの構成プロファイル由来か（プロファイル名など）が記載されているので、それを手がかりに Intune 側で特定する
この方法の強みは、「端末が実際に受け取っている設定」から辿れることです。管理者の記憶や命名規則に依存せず、証拠ベースで洗い出せます。
検索キーワードのおすすめセット
レポート内検索は、次の順に当てると見つかりやすいです。
- MaxInactivityTimeDeviceLock（最優先）
- DeviceLock
- Inactivity
- Screen Locks
さらに確実にする：端末側で「値が入っているか」を確認する（上級者向け）
「レポートでプロファイルは分かったが、端末に値が反映されているか確証が欲しい」「監査資料として端末側の証跡も欲しい」という場合は、端末側で値の存在を確認すると安心です。
環境差はありますが、Windows のポリシー系はレジストリに反映されることが多く、以下が目安になります。
- MDM/PolicyManager 系のパス（MDM で受けた値が格納されることがある）
- セキュリティポリシー相当のパス（GPO/ローカルで設定されることがある）
例として、ローカル側の「マシンの非アクティブ制限」に近い値は、次のように確認できる場合があります（環境により存在しないことがあります）。
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v InactivityTimeoutSecsまた、MDM 由来の設定は PolicyManager 配下に記録されることがあります。こちらも環境差があるため、まずは存在確認から進めるのが安全です。
reg query "HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceLock" /v MaxInactivityTimeDeviceLockレジストリ確認は「効いている/効いていない」を端末で即判断できる反面、環境によってキー構造が異なる可能性があるため、あくまで補助として使い、基本は MDM レポートの逆引きを軸にするのがおすすめです。
トラブルシュートの実務フロー：最短で原因を確定する手順
問い合わせ対応や検証時に、手戻りを減らすためのフローをまとめます。迷ったらこの順番で潰すと、最短で結論に到達しやすいです。
| 手順 | やること | 確認ポイント | 次に進む条件 |
|---|---|---|---|
| 1 | 対象端末で Intune 同期を実行 | 最後の同期時刻が更新されるか | 同期できた |
| 2 | 配布ステータスが成功か確認 | 対象プロファイルが端末に到達しているか | 成功になった |
| 3 | 端末を再起動 | シャットダウンではなく再起動 | 再起動後に検証できる |
| 4 | 短い値（1分）でロック動作を確認 | 動画再生など “アイドル阻害” がない状態でテスト | ロックした/しないが判明 |
| 5 | Export a report で逆引き | MaxInactivityTimeDeviceLock の由来プロファイル | 上書き元が特定できた |
| 6 | 競合ポリシーを未構成へ | Maximum Minutes of Inactivity… 等が残っていないか | 競合が解消 |
この流れに沿って対応すると、「設定は入っているのに効かない」というケースでも、原因を“再起動待ち”か“上書き”かに絞り込めます。
運用上の注意：画面ロックは競合しやすいからこそ「1カ所で管理」する
画面ロックのポリシーは、Intune の複数プロファイル、セキュリティベースライン、GPO、ローカル設定が絡みやすく、放置すると「いつの間にか値が変わっていた」「端末ごとに挙動が違う」状態になりがちです。そこで、運用として次のベストプラクティスをおすすめします。
管理ポイントを 1 カ所に寄せる
- 画面ロック時間の“正”を決める（例：MaxInactivityTimeDeviceLock を唯一の正とする）
- 他の場所に同等の設定がある場合は未構成に戻す
- 例外端末（共有PC、特定部門など）は別グループで明確に分離する
命名規則で「検索しやすさ」を担保する
引き継ぎ環境で最も効くのは、プロファイルの名前・説明に“実体”を残すことです。
- プロファイル名に DeviceLock や ScreenLock を入れる
- 説明欄に ./Device/Vendor/MSFT/Policy/Config/DeviceLock/MaxInactivityTimeDeviceLock を明記する
- 「何分」「対象」「例外」を説明に書き、誰が見ても意図が分かるようにする
検証は「配布→再起動→動作確認」をセット化する
- Intune の“成功”表示はスタート地点。端末での実動作確認までをワンセットにする
- 検証用の短い値（1分）を用意して、反映と競合の有無を素早く見る
- 本番値へ戻す際も再起動を含めた確認手順を踏む
よくあるつまずき（FAQ）
「Intune では成功」なのに、ずっとロックされません。何から疑うべき？
最初に疑うべきは再起動です。ポリシーが同期されても挙動に反映されないケースがあるため、端末を再起動したうえで、まず 1 分など短い値で再テストしてください。それでもダメなら、Export a report で MaxInactivityTimeDeviceLock の由来を逆引きし、上書き元を潰します。
既存プロファイルが多すぎて、管理側から探せません。
管理側の検索だけで戦うより、端末側のエクスポート レポート（HTML）で「端末が実際に受け取った値」から逆引きする方が早いです。検索キーワードは MaxInactivityTimeDeviceLock が最優先です。
スクリーンセーバーの設定を触ったのにロックされません。
スクリーンセーバーは“表示”の仕組みであり、必ずしも画面ロック（サインイン要求）とは一致しません。非アクティブで確実にロックさせたいなら、DeviceLock（MaxInactivityTimeDeviceLock）を中心に設計し、スクリーンセーバーは補助として扱うのが安全です。
まとめ：MaxInactivityTimeDeviceLock を軸に「再起動」と「競合排除」で解決する
Intune で Windows 10 の画面ロックが効かない問題は、手順さえ決めれば再現性高く解決できます。ポイントは次の 3 つです。
- DeviceLock は再起動後に効き始めることがある（検証は必ず再起動込み）
- 別プロファイル（特にパスワード系）の Maximum Minutes of Inactivity Until Screen Locks が上書きしていないか確認する
- UI 表記に惑わされず、MaxInactivityTimeDeviceLock をキーワードにして追う（Export a report が最短）
これらを押さえて「どこで管理するか」を 1 カ所に統一すれば、問い合わせも監査対応も一気に楽になります。
コメント