Microsoft が Intune の BitLocker 展開ガイダンスを更新した今、最初に押さえるべき結論はシンプルです。2026年の企業運用で重要なのは、BitLocker を単に有効化することではなく、標準展開かサイレント展開かを分けて設計し、ポリシー競合を避け、回復キー運用まで含めて回せる状態にすることです。Microsoft Learn の現行ガイドも、Endpoint security > Disk encryption を推奨し、暗号化レポート、回復キー管理、PDE まで含めて整理しています。 (Microsoft Learn)
この記事では、今回の更新をどう読むべきか、なぜ Intune 管理の BitLocker が 2026 年も実用的な強化トピックなのか、どのポリシーを選ぶべきか、どこで失敗しやすいのかを、現場でそのまま使える判断基準に落として整理します。
今回の更新で押さえるべきこと
まず事実関係を厳密に見ると、Microsoft Learn の公開ページでは該当記事の最終更新が 2025-12-01 と表示される一方、MicrosoftDocs のリポジトリでは 2026-04-08 に該当ファイルへのコミットがあり、コミット名は Folder Move です。つまり、4月8日の動きは大規模な新機能追加というより、ドキュメントの配置や導線を含む更新として読むのが安全です。 (Microsoft Learn)
ただし、現行ガイダンス自体は実務上かなり重要です。特に現場が見るべき論点は次のとおりです。 (Microsoft Learn)
| 論点 | 現行ガイダンスの要点 | 実務での意味 |
|---|---|---|
| 展開方式 | 標準展開とサイレント展開を明確に分離 | 端末条件が揃わないのに silent 前提で進めない |
| 推奨ポリシー | Endpoint security > Disk encryption が推奨 | BitLocker を専用ポリシーとして設計しやすい |
| Settings Catalog の扱い | silent 展開に必要な TPM 起動認証制御が不足 | Settings Catalog 単体で silent を完結させない |
| PDE | BitLocker の代替ではなく追加レイヤー | Windows 11 環境でデータ保護を一段深くできる |
| 監視と回復 | Encryption report、回復キー参照、key rotation を整理 | 暗号化後の運用まで含めて設計する前提になる |
要するに、今回のガイダンス更新で本当に見るべきなのは「どうオンにするか」ではなく、どう失敗を減らし、どう運用を回すかです。 (Microsoft Learn)
なぜ2026年も Intune 管理の BitLocker が重要なのか
BitLocker が 2026 年も重要な理由の一つは、Zero Trust の文脈で「データ保護の基礎層」だからです。Microsoft は、Intune で適切に BitLocker を構成していない Windows 端末は、ディスクの取り外しや外部メディア起動のような物理攻撃で組織データに不正アクセスされやすいと位置づけています。 (Microsoft Learn)
しかも Intune 管理の BitLocker は、暗号化の有無を確認して終わりではありません。Windows の BitLocker 構成は Intune の compliance policies と組み合わせられ、Conditional Access の判断材料にもできます。Windows の compliance settings には単純な暗号化チェックだけでなく、TPM ベースで BitLocker 状態を検証する Require BitLocker もあり、より実務向きです。 (Microsoft Learn)
さらに 2026 年は、Windows 10 サポート終了後の混在運用が現実です。Microsoft は Windows 10 を Intune の許容バージョンとして残しているものの、機能は保証されず変動しうると明記しています。だからこそ、Windows 11 へ移行しながら暗号化ポリシーを Intune 側で標準化する価値が高まっています。 (Microsoft Learn)
Windows 11 を使う企業では、PDE も見逃せません。PDE はファイル単位の暗号化で、BitLocker の代替ではなく追加レイヤーです。Windows Hello for Business サインインを前提に鍵を解放するため、「端末全体は BitLocker」「ユーザーデータの追加防御は PDE」という設計がしやすくなっています。 (Microsoft Learn)
Intune BitLocker は「標準展開」と「サイレント展開」を分けて考える
ここで最も重要な判断が、Intune BitLocker を標準展開で進めるか、サイレント展開で進めるかです。公式ガイドはこの2つを明確に分けており、必要条件も運用難易度もかなり違います。 (Microsoft Learn)
| 項目 | 標準BitLocker展開 | サイレントBitLocker展開 |
|---|---|---|
| ユーザー操作 | あり | なし |
| 向く環境 | 機種差や前提差が大きい環境、段階導入 | 企業貸与PC中心で前提条件が揃う環境 |
| 主な前提 | 比較的緩い | Entra joined / hybrid joined、TPM、UEFI、Secure Boot、WinRE |
| 暗号化方式 | 比較的柔軟に決めやすい | ハードウェアに応じて自動決定される部分がある |
| 失敗しやすい点 | ユーザーが後回しにする | 前提不足やポリシー競合で失敗しやすい |
迷ったら、前提が揃っていない端末群にいきなりサイレント展開を当てないことです。特に TPM、UEFI、WinRE、Microsoft Entra 参加状態が機種ごとにばらつく環境では、まず標準展開または限定パイロットで実態を見た方が失敗が少なくなります。 (Microsoft Learn)
なお、OOBE 中の自動暗号化と、Intune のサイレント BitLocker は同じではありません。サイレント BitLocker は Intune が BitLocker CSP 設定でユーザー操作を抑制する方式なので、「Autopilot で自動的に同じことが起きるはず」と考えると設計がずれます。 (Microsoft Learn)
まず選ぶべきポリシーと設計の考え方
新規に設計するなら、第一候補は Endpoint security > Disk encryption です。Microsoft 自身がこれを推奨しており、BitLocker 用の専用プロファイルとして管理しやすく、PDE も同じ系統で扱えます。一方、Device configuration の Endpoint protection でも構成できますが、BitLocker 以外の設定が混ざりやすく、設計が散りやすい点には注意が必要です。 (Microsoft Learn)
特に重要なのは、Settings Catalog を BitLocker で多用しすぎないことです。Microsoft は、サイレント BitLocker に必要な TPM 起動認証の制御が Settings Catalog だけでは足りないと明記しています。暗号化タイプの細かな制御に Settings Catalog を使うのは有効ですが、silent 展開の中核は Endpoint security か Device configuration で持つ方が安全です。 (Microsoft Learn)
暗号化方式を細かく決めたいときも注意が必要です。サイレント BitLocker では、非 Modern Standby 端末はフルディスク暗号化、Modern Standby 端末は使用領域のみの暗号化が自動で選ばれ、そこは silent 前提ではカスタマイズできません。OS ドライブの暗号化タイプを明示したい場合は、Settings Catalog の Enforce drive encryption type on operating system drives を使って別途制御します。 (Microsoft Learn)
鍵長は「とりあえず256bit」で決めるより、性能要件と規制要件で判断した方が現実的です。Windows の BitLocker ガイドは XTS-AES を推奨し、128bit と 256bit はデバイス性能や規制要件に応じて選ぶよう案内しています。未設定時の既定は XTS-AES 128-bit です。 (Microsoft Learn)
サイレントBitLockerを成功させる必須チェック
サイレント BitLocker を成功させる条件は、設定値そのものより前提確認にあります。少なくとも次の項目は、配布前に端末棚卸しやパイロットで確認しておきたいところです。 (Microsoft Learn)
Microsoft Entra 参加状態
silent 展開の前提は、Microsoft Entra joined か Microsoft Entra hybrid joined です。登録だけで済んでいる端末や、参加状態が曖昧な端末は、最初の切り分け対象にするべきです。 (Microsoft Learn)
TPM・UEFI・Secure Boot・WinRE
TPM 1.2 以降、ネイティブ UEFI、Secure Boot、有効な WinRE が揃っていないと、silent 展開はかなり不安定になります。Microsoft のトラブルシュート文書でも、TPM 不在、WinRE 未構成、Secure Boot 関連の問題は典型例として挙がっています。 (Microsoft Learn)
標準ユーザー端末の設定
標準ユーザーが使う端末では Allow Standard User Encryption = Enabled が必要です。また、TPM startup PIN や startup key にユーザー入力を要する設定が混ざると silent は失敗しやすくなります。特に PIN や startup key を Required にする設計は、silent 展開とは相性がよくありません。 (Microsoft Learn)
他社暗号化製品の残存
最も事故につながりやすいのは、McAfee、Symantec、Check Point などの他社暗号化製品が残っているのに、Allow Warning For Other Disk Encryption = Disabled で進めるケースです。Microsoft はこの設定について、データ損失、起動失敗、複数暗号化レイヤーによる複雑な復旧リスクを明示しています。 (Microsoft Learn)
回復キー運用を後回しにしない
BitLocker 導入で後回しにしがちですが、Microsoft もガイダンスの早い段階で Recovery planning を置いています。Intune では暗号化レポートやデバイス画面から回復キーを参照でき、閲覧は監査ログに残ります。つまり、設計すべき対象は「暗号化成功」だけではなく、「誰が、いつ、どこから回復キーに触れるか」です。 (Microsoft Learn)
閲覧権限
回復キー参照には、Intune 側の権限だけでなく、Microsoft Entra 側の microsoft.directory/bitlockerKeys/key/read 権限も関係します。運用設計では、ヘルプデスクにどこまで見せるかを最初に決めておかないと、緊急時に詰まります。 (Microsoft Learn)
サポート後のローテーション
ヘルプデスクが回復キーを案内した後に、リモートで BitLocker key rotation できることは大きな利点です。Microsoft は、Windows 10 version 1909 以降と Windows 11 でこのリモートアクションを案内しており、回復キーが露出した可能性がある端末の後処理として実用的です。 (Microsoft Learn)
セルフサービスを許すかどうか
Company Portal や My Account ポータルからのセルフサービス回復は、問い合わせ削減に効きます。ただし、テナント設定でユーザーへの公開範囲を制限でき、さらに Conditional Access で「準拠デバイスからのみ回復キー参照可」のような制御も組めます。全社に開くか、役職・部門で制限するかは先に決めておくべきです。 (Microsoft Learn)
保持上限と削除運用
見落としやすい注意点もあります。Microsoft Entra ID が保持できる BitLocker 回復キーは 1 台あたり最大 200 個で、上限に達すると silent encryption の開始前バックアップが失敗しえます。また、BitLocker 保護中の Microsoft Entra 参加端末で Intune オブジェクトを削除すると、OS ボリュームの key protectors が外れ、BitLocker が一時停止状態になると案内されています。 (Microsoft Learn)
失敗しやすいポイントと対処
Intune BitLocker で典型的に詰まるのは、機能不足ではなく「前提不足」と「ポリシー競合」です。Microsoft のトラブルシュート文書を基にすると、まず見るべき症状は次の通りです。 (Microsoft Learn)
| 症状 | 起きやすい原因 | 最初の確認ポイント |
|---|---|---|
| サイレントのはずがユーザー操作を求める | TPM startup PIN / key 関連設定、ベースラインとの競合 | BitLocker 設定値、policy conflict detection |
Not ready のまま進まない | TPM、UEFI、Secure Boot、WinRE、Entra 参加状態の不足 | Encryption report の status details |
Failed to enable Silent Encryption | silent 不可な設定の混在、GPO 競合 | BitLocker-API ログ、割り当て済みポリシー |
| TPM not available / WinRE not configured | ハードウェアまたは OS 前提不足 | tpm.msc、get-tpm、WinRE 状態 |
| 既に暗号化済みだが準拠しない | 既存暗号化方式とポリシーの不一致 | Encryption report、現在の暗号化状態 |
切り分けの起点は Intune の Encryption report です。Microsoft は、失敗を「端末が前提を満たさない」「Intune ポリシー誤設定や GPO 競合」「すでに暗号化済みだが方式が合わない」の3系統で見るよう案内しています。なお、暗号化状態の反映には最大24時間ほどかかることがあるため、配布直後の見え方だけで失敗判定しない方が安全です。 (Microsoft Learn)
より深く追うときは、Event Viewer の Microsoft > Windows > BitLocker-API を優先して確認します。Microsoft はここで Failed to enable Silent Encryption、TPM が見つからない、WinRE 未構成、Secure Boot 変数を読めない、回復設定の GPO 競合などの手掛かりを追うよう案内しています。 (Microsoft Learn)
2026年版の現実的な導入手順
- まず
Devices > Monitor > Encryption reportと資産台帳を見て、TPM、UEFI、WinRE、Entra 参加状態、既存暗号化製品、既存 GPO・セキュリティ ベースラインの重複を洗い出します。 (Microsoft Learn) - 次に端末群を分けます。企業貸与の標準機はサイレント展開、条件が揃わない混在群は標準展開または限定パイロットから始める方が現実的です。 (Microsoft Learn)
- 新規設計は
Endpoint security > Disk encryptionを軸にし、PDE や暗号化タイプ制御が必要な箇所だけ追加で設計します。 (Microsoft Learn) - 広域展開前に、回復キーのエスクロー、閲覧権限、Company Portal のセルフサービス、サポート後の key rotation まで一連の流れをテストします。 (Microsoft Learn)
- パイロットで安定したら、
Require BitLockerを含む compliance policies と Conditional Access を組み合わせ、未暗号化端末を業務アクセスの例外にしない設計へ進めます。 (Microsoft Learn) - 展開は一気に広げず、Encryption report の反映遅延と policy conflict detection を前提に、波状展開で広げます。 (Microsoft Learn)
この順序にする理由は、Microsoft の現行ガイダンスが BitLocker を「設定項目」ではなく「監視・回復・権限管理まで含む運用フロー」として扱っているからです。最初にやるべきことは設定画面を開くことではなく、重複ポリシーの棚卸しと、サイレント展開の前提確認、回復キー運用の検証です。ここを先に済ませると、導入後の問い合わせと失敗率が大きく下がります。 (Microsoft Learn)
Microsoft が Intune の BitLocker 展開ガイダンスを更新した意義は、2026年になっても BitLocker が「古い機能」ではなく、「クラウド管理された端末暗号化の基礎」であり続けることを、より実務寄りに示した点にあります。今すぐ着手するなら、まずは Endpoint security ベースの設計に寄せ、サイレント展開の前提を洗い出し、回復キーの運用をエンドツーエンドで確認してください。それが、Intune BitLocker を“設定しただけ”で終わらせない最短ルートです。 (Microsoft Learn)
コメント