Microsoft Intune で Windows デバイスを BitLocker 暗号化する場合、2026年7月1日時点で管理者が最優先で確認すべきなのは「サイレント暗号化の前提条件」「回復キーの保管とローテーション」「既存の暗号化ソフトとの競合」「Windows 10 サポート終了後の運用リスク」です。公式リポジトリの履歴では、2026年7月1日の更新は “Metadata updates” として記録されており、BitLocker 設定そのものの新しい移行期限や破壊的変更が追加された内容ではありません。(GitHub)
一方で、Microsoft Intune の「Encrypt Windows devices with BitLocker using Intune」は、単なる BitLocker 有効化手順ではなく、標準暗号化、サイレント暗号化、Windows 11 の Personal Data Encryption（PDE）、回復キー管理まで含む運用設計の基準になるドキュメントです。Intune 管理者は「ポリシーを作る」だけでなく、展開前の端末棚卸し、ポリシー競合の確認、回復手順のテストまでをセットで進める必要があります。(Microsoft Learn)
Microsoft Intune の BitLocker 暗号化で確認すべき更新ポイント
今回確認すべきポイントは、「新機能が増えたか」よりも「現在の公式情報に沿って、安全に展開できる状態か」を見直すことです。
Microsoft Learn の該当ページでは、Intune を使って Windows デバイスの BitLocker 暗号化と、Windows 11 Version 22H2 以降の Personal Data Encryption（PDE）を構成できると説明されています。また、BitLocker の展開方式として、ユーザー操作を伴う標準暗号化と、ユーザー操作なしで自動的に暗号化するサイレント暗号化の2パターンが整理されています。(Microsoft Learn)
特に重要なのは、サイレント暗号化を使う場合です。サイレント暗号化はユーザー操作に依存せずに暗号化を進められるため、グローバル企業や多数の Windows 端末を管理する組織では有効です。しかし、TPM、UEFI、Secure Boot、WinRE、Microsoft Entra join 状態、既存のサードパーティ暗号化ソフトの有無など、事前条件を満たしていないと失敗や起動トラブルにつながります。(Microsoft Learn)
影響範囲：対象になるデバイスと管理者
今回の内容が影響するのは、Microsoft Intune で Windows デバイスを管理し、BitLocker または PDE をポリシーで構成している組織です。
| 対象 | 影響内容 | 管理者が見るべきポイント |
|---|---|---|
| Windows 11 デバイス | BitLocker と PDE の両方を設計対象にできる | BitLocker はドライブ暗号化、PDE はファイル単位の追加保護として整理する |
| Windows 10 デバイス | Intune で登録や一部機能利用は可能だが、サポート終了後の保証に注意 | Windows 11 移行計画と暗号化ポリシーの再確認が必要 |
| Microsoft Entra joined / hybrid joined デバイス | サイレント暗号化や回復キー保管の前提になる | Join 状態、TPM、Secure Boot、WinRE を棚卸しする |
| 標準ユーザーで利用する端末 | サイレント暗号化に追加設定が必要 | Allow Standard User Encryption を有効にするか確認する |
| 既存の暗号化ソフト導入済み端末 | BitLocker と競合するリスクがある | 先に復号・削除・移行計画を作る |
Windows 10 については、Microsoft Learn 上でも 2025年10月14日にサポート終了となり、品質更新や機能更新を受け取らないこと、Intune 登録は可能でも機能が保証されない場合があることが明記されています。既存の Windows 10 管理端末に BitLocker ポリシーを継続適用する場合は、暗号化そのものだけでなく、OS ライフサイクルの観点でリスクを評価する必要があります。(Microsoft Learn)
設定方式は「Endpoint security」が基本
Microsoft Intune で BitLocker を構成する方法は複数ありますが、実務上は Endpoint security > Disk encryption の BitLocker プロファイルを第一候補にするのが分かりやすい選択です。
公式情報では、BitLocker 構成に使えるポリシーとして、Endpoint security policy と Device configuration policy が示されています。Endpoint security の Disk encryption は、BitLocker や PDE に特化したセキュリティ構成として整理されており、デバイス構成プロファイルは Endpoint protection テンプレート内の一部として BitLocker を扱います。(Microsoft Learn)
| 構成方式 | 向いているケース | 注意点 |
|---|---|---|
| Endpoint security > Disk encryption | BitLocker をセキュリティポリシーとして明確に管理したい場合 | 基本はこちらを優先する |
| Device configuration > Endpoint protection | 既存の構成テンプレート運用に合わせたい場合 | BitLocker 以外の設定も含まれ、管理が複雑になりやすい |
| Settings Catalog | 特定の BitLocker 関連設定を補助的に構成したい場合 | サイレント BitLocker に必要な TPM 起動認証制御を十分に含まないため、単独利用には注意 |
特に見落としやすいのが Settings Catalog の扱いです。公式ドキュメントでは、Settings Catalog には信頼性の高いサイレント BitLocker 有効化に必要な TPM 起動認証コントロールが含まれないため、BitLocker シナリオでは Endpoint security または Device configuration policy を使うよう説明されています。(Microsoft Learn)
ただし、暗号化タイプを「フルディスク暗号化」または「使用済み領域のみ暗号化」に制御したい場合は、Settings Catalog の「Enforce drive encryption type on operating system drives」を使う場面があります。つまり、Settings Catalog は主役ではなく、補助的な制御として位置付けるのが安全です。(GitHub)
標準暗号化とサイレント暗号化の違い
BitLocker 展開で最初に決めるべきことは、標準暗号化にするか、サイレント暗号化にするかです。
| 項目 | 標準 BitLocker 暗号化 | サイレント BitLocker 暗号化 |
|---|---|---|
| ユーザー操作 | 発生する場合がある | 原則として不要 |
| 管理者権限 | 構成によって必要になる場合がある | 条件を満たせば不要 |
| 展開の確実性 | ユーザー対応に左右されやすい | 条件が整えば大規模展開しやすい |
| 事前確認の重要度 | 中 | 高 |
| 向いている環境 | 小規模、例外端末、手動確認を許容できる環境 | 大規模展開、Autopilot、標準化された端末管理 |
グローバル環境では、サイレント暗号化の方が運用負荷を下げやすい一方、失敗時の影響範囲も大きくなります。たとえば、日本、米国、欧州、アジア拠点で調達端末のメーカーや BIOS 設定が異なる場合、同じ Intune ポリシーでも一部地域だけ BitLocker が有効にならないことがあります。
そのため、いきなり全社配布するのではなく、地域、端末モデル、OS バージョン、Entra join 種別ごとに小さなパイロットグループを作ることが重要です。
サイレント BitLocker 暗号化の必須条件
サイレント BitLocker 暗号化では、デバイスが複数の条件を満たす必要があります。公式ドキュメントでは、標準ユーザーの場合は Windows 10 version 1809 以降または Windows 11、管理者ユーザーの場合は Windows 10 version 1803 以降または Windows 11 が条件として示されています。加えて、Microsoft Entra joined または hybrid joined、TPM 1.2 以上、ネイティブ UEFI BIOS、Secure Boot、WinRE が必要です。(Microsoft Learn)
| 確認項目 | 確認方法の例 | NG の場合に起きること |
|---|---|---|
| Microsoft Entra joined / hybrid joined | Intune のデバイス情報、Entra 管理センターで確認 | 回復キーの自動バックアップやサイレント暗号化が失敗しやすい |
| TPM 1.2 以上 | Intune の Encryption report、端末の TPM 管理画面で確認 | BitLocker の自動有効化が失敗する |
| UEFI / Secure Boot | BIOS/UEFI 設定、Windows 情報で確認 | サイレント暗号化の前提を満たさない |
| WinRE | reagentc /info で確認 | 暗号化失敗や回復時の問題につながる |
| Modern Standby | powercfg /a で確認 | 暗号化タイプの挙動が想定と異なる場合がある |
| 現在の暗号化状態 | manage-bde -status c: で確認 | 既存暗号化との不一致やポリシーエラーを見落とす |
公式ドキュメントでも、Modern Standby 対応の確認には powercfg /a、現在の暗号化タイプ確認には管理者権限のコマンドプロンプトで manage-bde -status c: を実行する方法が示されています。(GitHub)
サイレント暗号化で変更すべき主要設定
Endpoint security policy でサイレント BitLocker を構成する場合、少なくとも次の設定が重要です。
| 設定 | 推奨される考え方 | 注意点 |
|---|---|---|
| Require Device Encryption | Enabled | BitLocker 暗号化を要求する基本設定 |
| Allow Warning For Other Disk Encryption | Disabled | 既存暗号化ソフトの警告を表示せず進めるため、事前棚卸しが必須 |
| Allow Standard User Encryption | Enabled | 標準ユーザーが使う端末でサイレント暗号化を成立させるために必要 |
| TPM startup PIN | Do not allow | PIN 入力が必要だとサイレント暗号化を妨げる |
| TPM startup key | Do not allow | USB キーなどの操作が必要になり、無人展開に不向き |
| TPM startup key and PIN | Do not allow | ユーザー操作が必要なためサイレント化を阻害する |
公式ドキュメントでは、Endpoint security policy の BitLocker プロファイルで「Require Device Encryption = Enabled」「Allow Warning For Other Disk Encryption = Disabled」がサイレント暗号化の必須設定として示されています。また、標準ユーザーが利用する端末では「Allow Standard User Encryption = Enabled」が必要です。(Microsoft Learn)
ただし、「Allow Warning For Other Disk Encryption」を無効にする設定は便利な反面、危険もあります。既存の McAfee、Symantec、Check Point などの暗号化ソフトが残っている端末で BitLocker を自動有効化すると、二重暗号化、起動不能、データ損失につながる可能性があります。公式ドキュメントでも、サイレント BitLocker ポリシーを展開する前に既存の暗号化ソフトを特定し、移行戦略、パイロットテスト、ロールバック手順を準備するよう注意しています。(Microsoft Learn)
既存ポリシーとの競合に注意する
BitLocker 展開でよくある失敗は、「BitLocker ポリシーだけを見て問題ないと判断する」ことです。実際には、セキュリティベースライン、デバイス構成プロファイル、Settings Catalog、過去に作った Endpoint protection テンプレートが同じ領域を触っている場合があります。
特に注意したいのは TPM 起動 PIN です。公式ドキュメントでは、Microsoft Defender のセキュリティベースラインなどが TPM startup PIN や startup key を有効にする可能性があり、これがサイレント有効化をブロックする例として挙げられています。(Microsoft Learn)
確認すべき実務ポイントは次の通りです。
| 確認対象 | 確認する内容 | 判断基準 |
|---|---|---|
| Endpoint security > Disk encryption | BitLocker プロファイルの設定値 | サイレント暗号化に必要な設定が揃っているか |
| Security baselines | TPM startup PIN / key 関連設定 | ユーザー入力を要求する設定が有効になっていないか |
| Device configuration profiles | Windows Encryption の重複設定 | Endpoint security と矛盾していないか |
| Settings Catalog | BitLocker 関連の個別設定 | 補助設定が主ポリシーを上書きしていないか |
| Assignment | 対象グループと除外グループ | パイロット、例外、地域別展開が整理されているか |
ポリシー競合が疑われる場合は、Intune のポリシー競合検出やデバイスごとの状態確認を使い、どのポリシーがどの設定を適用しているかを追跡します。
暗号化タイプは端末条件によって変わる
BitLocker 展開では、「フルディスク暗号化にしたつもりなのに、使用済み領域のみ暗号化になっている」といった問い合わせが発生することがあります。
公式ドキュメントでは、SystemDrivesEncryptionType が未構成の場合、Modern Standby 対応デバイスでサイレント暗号化を使うと「使用済み領域のみ暗号化」、非 Modern Standby デバイスでは「フルディスク暗号化」になると説明されています。(GitHub)
これは不具合ではなく、ハードウェア能力とサイレント暗号化構成に基づく既定動作です。監査部門やセキュリティ部門が「全端末をフルディスク暗号化」と定義している場合は、Intune のポリシー設計だけでなく、実際の manage-bde -status c: の結果を確認する運用が必要です。
PDE は BitLocker の代替ではなく追加保護
Windows 11 Version 22H2 以降では、Personal Data Encryption（PDE）も Intune から構成できます。PDE は BitLocker と違い、ドライブ全体ではなくファイル単位で暗号化します。公式ドキュメントでは、PDE は BitLocker と併用する追加保護であり、Windows Hello for Business によるサインイン後に暗号化キーが解放される仕組みとして説明されています。(GitHub)
| 項目 | BitLocker | PDE |
|---|---|---|
| 保護対象 | ドライブ、ボリューム | ファイル |
| 主な目的 | 紛失・盗難時のデータ保護 | サインイン状態やユーザー認証に連動した追加保護 |
| 必要条件 | Windows の対応エディション、TPM など | Windows 11 22H2 以降、Windows Hello for Business |
| 位置付け | 基本のデバイス暗号化 | BitLocker を補完する多層防御 |
実務では、まず BitLocker で端末紛失・盗難時の基本的なデータ保護を整備し、重要部門や高機密データを扱うユーザーに PDE を追加する設計が現実的です。全社一律で PDE まで展開すると、Windows Hello for Business の利用状況やユーザー体験への影響を受けやすいため、対象部門を絞った検証から始める方が安全です。
回復キー管理は展開前に決めておく
BitLocker 展開で最も避けるべきなのは、「暗号化は成功したが、回復キーを取り出せない」状態です。Intune では、暗号化レポートからデバイスの暗号化状態を確認し、BitLocker 回復キーを管理できます。公式ドキュメントでは、Intune 管理センターのデバイス詳細から Recovery keys を開き、Show Recovery Key を選択すると監査ログが生成されることも説明されています。(GitHub)
回復キー管理では、次の3点を事前に決めてください。
| 決めること | 推奨される運用 |
|---|---|
| 誰が回復キーを閲覧できるか | Helpdesk Administrator、Cloud Device Administrator など、必要最小限のロールに限定する |
| ユーザー自身の回復を許可するか | Company Portal や My Account ポータルを使う場合は、条件付きアクセスと監査をセットにする |
| 回復キーをいつローテーションするか | 回復キー使用後や端末再割り当て時にローテーションする手順を用意する |
Microsoft Entra ID では、1デバイスあたり最大200個の BitLocker 回復キーがサポートされます。上限に達すると、暗号化前の回復キー保存に失敗し、サイレント暗号化が失敗する可能性があります。大量の再暗号化や再プロビジョニングを行う環境では、古いキーが蓄積していないかも確認しておきましょう。(GitHub)
レポート確認で見落としやすいポイント
Microsoft Intune の encryption report は、暗号化状態や回復キー管理を確認する中心的な場所です。公式ドキュメントでは、Encryption report がデバイスの暗号化状態の詳細確認と回復キー管理のための一元的な場所であると説明されています。(Microsoft Learn)
ただし、レポートの見え方には注意が必要です。Windows デバイスの暗号化ステータスは OS ドライブの暗号化状態を示し、固定データドライブなど他のドライブまでは見ない場合があります。また、Intune が暗号化状態や変更をレポートするまで最大24時間かかることがあります。(Microsoft Learn)
| 状況 | 誤解しやすい点 | 正しい確認方法 |
|---|---|---|
| 暗号化直後 | Intune 上で未暗号化に見える | 最大24時間の反映遅延を考慮する |
| OS ドライブのみ暗号化 | 全ドライブ暗号化済みと誤解する | 固定ドライブ、リムーバブルドライブのポリシーも確認する |
| Recovery key backup failed | 暗号化だけを再実行しようとする | イベントログと回復キー escrow 状態を確認する |
| TPM not ready | Intune ポリシーの問題と判断する | BIOS/UEFI、TPM 初期化状態を確認する |
| WinRE not configured | サイレント暗号化が失敗する | reagentc /info で状態を確認する |
暗号化レポートだけで完結させず、パイロット端末では manage-bde -status c:、イベントログ、Intune のデバイス状態、Entra ID の回復キー表示を組み合わせて確認するのが実務的です。
移行期限と既存プロファイルの扱い
今回の公式情報から読み取れる範囲では、2026年7月1日付で BitLocker 構成に新しい強制移行期限が追加されたわけではありません。注意すべき期限系の情報は、Windows 10 のサポート終了と、過去の BitLocker プロファイル形式の扱いです。
Endpoint security の Disk encryption settings に関する公式ページでは、2023年6月19日以降、Windows 向け BitLocker プロファイルが Settings Catalog と同じ設定形式に更新され、古いプロファイルの新規作成はできなくなったと説明されています。既存の古いプロファイルは引き続き利用・編集できますが、古い形式は今後の新規開発対象ではありません。(Microsoft Learn)
| 項目 | 状態 | 管理者の判断 |
|---|---|---|
| 2026年7月1日の更新 | 公式リポジトリ履歴上はメタデータ更新 | すぐに設定変更が必要な更新ではない |
| Windows 10 | 2025年10月14日にサポート終了 | 暗号化運用より先に OS 移行計画を確認 |
| 旧 BitLocker プロファイル | 新規作成不可、既存利用・編集は可能 | 新規展開や大規模見直し時は新形式へ寄せる |
| Settings Catalog | 一部制御に利用可能 | サイレント BitLocker の主設定として単独利用しない |
既存環境では、「古いプロファイルがまだ動いているから問題ない」と判断するのではなく、新規端末、Autopilot 展開、Windows 11 移行、セキュリティベースライン更新のタイミングで BitLocker ポリシーを棚卸しするのが安全です。
管理者が今すぐ確認すべきチェックリスト
Microsoft Intune で BitLocker を安定運用するには、次の順番で確認すると効率的です。
| 優先度 | 確認項目 | 実施内容 |
|---|---|---|
| 高 | 既存暗号化ソフトの有無 | サードパーティ暗号化製品が残っていないか棚卸しする |
| 高 | 回復キーの保存先 | Microsoft Entra ID に回復キーが保存される構成か確認する |
| 高 | サイレント暗号化の前提条件 | TPM、UEFI、Secure Boot、WinRE、Entra join 状態を確認する |
| 高 | 標準ユーザー対応 | 標準ユーザー端末では Allow Standard User Encryption を確認する |
| 中 | TPM 起動 PIN の競合 | セキュリティベースラインや別ポリシーで PIN 要求が有効でないか確認する |
| 中 | 暗号化タイプ | フルディスク暗号化と使用済み領域のみ暗号化のどちらになるか確認する |
| 中 | レポート反映 | Intune レポートの最大24時間遅延を運用手順に入れる |
| 中 | Windows 10 端末 | Windows 11 移行計画と合わせて BitLocker ポリシーを見直す |
| 低 | PDE の適用範囲 | 高機密ユーザーや特定部門から段階的に検証する |
特にグローバル展開では、端末モデルや調達ルートが地域ごとに異なるため、全社一律の「成功率」だけを見ると問題を見落とします。地域別、OS 別、端末モデル別、Join 種別別にレポートを分けると、失敗パターンを早く見つけられます。
実務でのおすすめ展開手順
BitLocker をまだ本格展開していない、または Windows 11 移行に合わせて見直す場合は、次の流れで進めると失敗しにくくなります。
現状を棚卸しする
最初に、対象端末の OS、TPM、Secure Boot、WinRE、Entra join 状態、既存暗号化ソフトの有無を確認します。ここを省略すると、サイレント暗号化の失敗や起動不能が後から発覚します。
パイロットグループを作る
本社だけでなく、主要地域ごとに代表端末を含めます。たとえば、米国の Dell、欧州の HP、日本の Lenovo など、実際の調達構成に近い端末で検証します。
Endpoint security の Disk encryption でポリシーを作る
新規展開では、Endpoint security > Disk encryption の BitLocker プロファイルを基本にします。Device configuration の Endpoint protection テンプレートを既に使っている場合は、重複設定がないか確認します。
サイレント暗号化の条件を満たす
Require Device Encryption、Allow Warning For Other Disk Encryption、Allow Standard User Encryption、TPM startup PIN/key の設定を確認します。特に TPM startup PIN は、セキュリティ要件として設定したくなる項目ですが、サイレント暗号化とは相性が悪い点に注意が必要です。
回復キーの運用をテストする
暗号化が成功した端末で、Intune 管理センターから回復キーを表示できるか確認します。表示操作が監査ログに残ること、ヘルプデスク担当者が必要最小限の権限で対応できることも確認します。
レポートと現場確認を突き合わせる
Intune の Encryption report、manage-bde -status c:、イベントログを照合します。Intune 反映に時間がかかることを前提に、展開直後の問い合わせ対応手順も作っておくと混乱を防げます。
失敗しやすいポイントと対策
| よくある失敗 | 原因 | 対策 |
|---|---|---|
| サイレント暗号化が始まらない | TPM startup PIN や startup key が要求されている | セキュリティベースラインを含めて競合設定を確認する |
| 一部地域だけ失敗する | 端末モデルや BIOS 設定が地域で異なる | 地域別・モデル別にパイロットを分ける |
| 回復キーが見つからない | Entra ID への保存が失敗している | 回復キー escrow を暗号化前提条件として確認する |
| 既存暗号化ソフトと競合する | サードパーティ暗号化を残したまま BitLocker を有効化 | 先に既存ソフトを復号・削除し、移行手順を作る |
| レポート上は未暗号化に見える | Intune への状態反映に時間がかかる | 最大24時間の遅延を考慮し、端末側コマンドでも確認する |
| フルディスク暗号化にならない | Modern Standby や設定未構成による既定動作 | 暗号化タイプの要件を明文化し、Settings Catalog で補助制御する |
BitLocker は「オンにすれば終わり」の機能ではありません。むしろ、端末紛失や起動不能が発生したときに、回復キーを誰が、どの手順で、安全に取り出せるかまで設計して初めて運用が成立します。
まとめ：Intune の BitLocker 管理は展開前チェックが成否を分ける
Microsoft Intune の「Encrypt Windows devices with BitLocker using Intune」は、Windows デバイス暗号化の設定手順だけでなく、標準暗号化、サイレント暗号化、PDE、回復キー管理、監視までを整理するための重要な公式情報です。
2026年7月1日の履歴はメタデータ更新であり、BitLocker 設定に新しい強制移行期限が追加された内容ではありません。ただし、Windows 10 サポート終了、旧 BitLocker プロファイル形式、サイレント暗号化の前提条件、回復キー管理の重要性を踏まえると、管理者は今の構成を一度棚卸しする価値があります。
まずは、既存暗号化ソフトの有無、TPM・UEFI・Secure Boot・WinRE、Entra join 状態、回復キー保存、ポリシー競合を確認してください。そのうえで、小規模パイロットから Endpoint security の Disk encryption ポリシーを展開し、Intune レポートと端末側コマンドの両方で結果を確認する流れが、最も現実的で安全な進め方です。
コメント