>
>
公開日
最終更新日
BitLockerはWindowsのドライブ全体を暗号化する標準機能です。
情シス担当者が扱うべき論点は、暗号化のオン・オフ操作だけではありません。貸与PCの回復キーを誰がどこで保管するか、利用者が保護を中断できない状態をどう作るか、BIOS/UEFI更新前に完全復号せず安全に保守するにはどうするかまで決める必要があります。
BitLockerは「ビットロッカー」と読みます。本記事では、Windowsのデバイスの暗号化やEFSとの違いを整理したうえで、BitLocker GPOの構成、無効化と保護の一時停止の手順、回復キーを要求されたときの対応フローを解説します。対象は、Windows PCを組織的に管理する情報システム部門です。
BitLockerとは？基礎知識と運用のポイント
BitLockerは、PCが起動していない状態でストレージを取り外されても、保存データを読み取られにくくするためのドライブ暗号化機能です。
本記事のポイント
BitLockerはWindows 10/11 Pro、Enterprise、Educationで利用できるドライブ暗号化機能です。
回復キーは48桁の数字であり、暗号化の設定と同時に保管先を統制します。
ドメインGPOは回復情報の保管と利用条件の統制に使い、暗号化開始は別途展開手段で実行します。
BIOS更新では完全な無効化ではなく、原則として保護の一時停止を使います。
MicrosoftはBitLocker の概要で、OSドライブ、固定データドライブ、リムーバブルドライブを保護対象として案内しています。OSドライブではTPMと連携し、起動構成やファームウェアの変化を検知した場合に通常の自動解除を止め、回復キーの入力を求めます。
TPMは標準的な構成で使われますが、BitLockerの必須条件ではありません。ローカルまたはドメインのポリシーで「スタートアップ時に追加の認証を要求する」を有効にし、互換TPMなしでの利用を許可すれば、USBスタートアップキーやパスワードを用いる構成を選べます。ただし、USBキーを端末と同じ場所に保管すると盗難対策にならないため、TPM非搭載端末では保管・配布手順まで含めて設計します。
暗号方式は環境により異なりますが、BitLockerではWindows 10 バージョン1511以降、XTS-AESが既定方式として使われています。GPOまたはIntuneで鍵長を指定する場合、XTS-AES 128ビットまたはXTS-AES 256ビットから選択します。暗号化だけでマルウェア感染や不正なクラウド共有を防げるわけではなく、BitLockerはストレージの物理的な持ち出しに対する保護に限定されます。端末からのデータ流出経路はネットワーク送信やクラウド共有など複数あるため、アクセス制御や操作ログと組み合わせて経路ごとに対策を設計します。
ドライブ暗号化を含めた社用PC全般の統合管理を進める際は、法人・企業用IT資産と社用デバイスを一元管理する方法をご覧ください。
デバイスの暗号化とEFSの使い分け
デバイスの暗号化、BitLocker、EFSは保護範囲と管理方法が異なるため、同じ機能として扱わないことが運用事故の防止につながります。
Windowsの画面上では類似した名称が表示されますが、「デバイスの暗号化」はBitLockerと同じ暗号化技術を基盤とし、対応ハードウェアで自動的に有効化される簡易設定です。「BitLocker ドライブ暗号化」はドライブ種別ごとのポリシーや回復方法を細かく管理できる機能であり、GPOやIntuneによる法人統制が可能です。画面上の名称が異なっても、内部の暗号化技術は共通であるため、管理画面の違いによって操作手順と回復キーの保管先が変わります。MicrosoftのWindows のデバイスの暗号化に関する公式案内では、対応デバイスでMicrosoftアカウントまたは職場・学校アカウントを使ってセットアップを完了すると、デバイスの暗号化が有効になる場合があると説明しています。
項目 | デバイスの暗号化 | BitLocker ドライブ暗号化 | EFS |
|---|---|---|---|
主な対象 | 対応ハードウェアのWindows端末 | Pro、Enterprise、EducationのWindows端末 | Pro、Enterprise、EducationのNTFSファイル |
保護範囲 | 主にシステムドライブ | OS、固定、リムーバブルドライブ | ファイルまたはフォルダ |
有効化の契機 | OOBE完了時に自動で有効となる場合があります | 管理者または管理ポリシーに基づく設定 | 利用者または管理者によるファイル設定 |
法人での統制 | 端末条件に左右されます | GPO、Intune、AD DS、Entra IDと連携できます | 証明書と復旧エージェントの設計が必要です |
主な目的 | 端末紛失時の基本保護 | 組織端末の暗号化と回復管理 | 特定ファイルのアクセス保護 |
24H2などの更新後に「暗号化した覚えがないのに回復キーを求められた」となる事象は、BitLocker全般の自動有効化ではなく、対応端末におけるデバイスの暗号化とOOBEの条件をまず切り分けます。［設定］に［デバイスの暗号化］が表示される端末は同機能、コントロールパネルの［BitLocker ドライブ暗号化］にドライブ別の管理画面が表示される端末はBitLockerとして確認します。
EFSの運用上の限界
EFSはファイル単位で暗号化できますが、暗号化したユーザーがWindowsにサインインしている間は通常、対象ファイルが透過的に復号されます。そのため、EFSだけでログイン済み利用者による持ち出しやマルウェアによる窃取を止めることはできません。機密ファイルを扱う場合は、共有権限、DLP、監査ログ、情報保護ラベルを組み合わせ、誰がどの経路で外部へ送ったかを追跡できる状態にします。
GPOやIntuneを用いた端末統制の具体像を把握したい方は、Microsoft Intuneの機能やライセンス体系を解説したガイドをご参照ください。
▲ 「デバイスの暗号化」「BitLocker」「EFS」の保護範囲と運用方式の違い
BitLocker導入の効果と管理方式の比較
Windows標準のBitLockerを使う場合でも、回復キーと暗号化状態を中央で把握できなければ、端末紛失時と障害時の両方で運用が止まります。
矢野経済研究所は、2025年度の国内サイバーセキュリティ市場を前年度比9.2％増の1兆9,471億円と推計しています。IDC Japanは、国内Endpoint Security Software市場が前年比10.1％増の1,734億3,100万円となり、EDR分野が前年比22.8％成長したと公表しました。端末対策は暗号化単体では完結せず、端末の可視化、権限統制、検知・対応を組み合わせる方向へ進んでいます。矢野経済研究所の2025年度市場予測およびIDC Japanの市場調査が根拠です。
管理方式 | 暗号化エンジン | 回復キーの保管 | 統制の特徴 | 追加費用 |
|---|---|---|---|---|
BitLocker＋AD DS/GPO | BitLocker | AD DS | オンプレミスのドメインポリシーで統制します | Windowsライセンス外の管理基盤費用が必要です |
BitLocker＋Intune/Entra ID | BitLocker | Entra ID | クラウド管理端末の準拠状態を把握しやすくなります | 契約ライセンスの確認が必要です |
BitLocker＋資産管理ツール | BitLocker | 製品または連携先 | 暗号化状態、回復キー、端末台帳をまとめて扱えます | 料金は製品ごとに要問合せです |
追加の暗号化エンジンを導入しない方式では、Windowsに含まれる機能を生かせるため、別製品の暗号化ライセンスやOS更新時の互換性検証を減らせます。ただし、BitLockerだけでは資産台帳、操作ログ、EDRの代替にはなりません。端末台帳がすでに整備され、AD DSまたはEntra IDへ回復キーを確実に保存できるなら、標準機能を軸に統制を組み立てます。
国内企業の導入事例
竹中工務店は、全国約800カ所、約14,000台のPCでSCSKの「PerfectWatch for BitLocker」を導入しています。SCSKの竹中工務店の導入事例では、BitLockerの暗号化状況と回復キーを管理する運用が紹介されています。大規模端末での論点は暗号化率だけでなく、回復キーの照会をヘルプデスクが再現性をもって処理できることです。
リコーグループも、国内13社・5万台以上のPCインフラでSKYSEA Client Viewを導入した事例を公開しています。Sky株式会社のリコーグループ導入事例では、端末管理の標準化とBitLocker活用が紹介されています。自組織で採る方式は、回復キーの保管先、端末の参加形態、運用担当者が暗号化状態を日常的に確認できるかの3点で決めます。
暗号化状態や端末情報をクラウド上で一元把握したい場合は、MDM連携による台帳自動更新の仕組みと運用ポイントをあわせてご確認ください。
BitLocker GPOによる有効化と回復キー管理
ドメインGPOでは回復キーをAD DSへ保存する条件を先に固め、暗号化開始は展開スクリプトや端末管理基盤で実行します。
ここで混同しやすいのが、gpedit.mscとgpmc.mscです。gpedit.mscは単一端末のローカル グループポリシー エディターです。Active Directoryドメインの組織単位にポリシーをリンクして配布する管理画面は、グループ ポリシーの管理コンソールであるgpmc.mscです。
ドメインGPOの構成順序
対象OUを決めます。検証端末用OUを用意し、本番PCを含むOUへ直ちにリンクしません。
GPMCで新しいGPOを作成し、対象OUにリンクします。管理対象がOSドライブ、固定データドライブ、リムーバブルドライブのどれかを分けて設計します。
回復情報の保存ポリシーを設定します。［コンピューターの構成］＞［ポリシー］＞［管理用テンプレート］＞［Windows コンポーネント］＞［BitLocker ドライブ暗号化］＞［オペレーティング システムのドライブ］で、回復方法とAD DSへの回復情報保存を構成します。
保存失敗時の開始可否を設定します。回復情報がAD DSに保存されるまでBitLockerを有効化しない設定を選べる環境では、その条件を有効にします。
暗号化開始を配布します。スタートアップスクリプト、端末管理ツール、またはIntuneのディスク暗号化ポリシーで有効化を実行します。
回復キー照会をテストします。ADユーザーとコンピューターなどの管理画面で、対象端末の回復情報をヘルプデスクが検索できることを確認します。
MicrosoftのBitLocker 運用ガイドでは、回復情報の展開・管理を含む運用設計が案内されています。回復キーをAD DSに保存するポリシーだけでは暗号化は始まりません。GPOで保管条件を統制し、別の配布手段で暗号化を開始するという役割分担が正しい構成です。
Entra ID管理端末の回復情報
クラウド参加端末では、回復キーをEntra IDへエスクローする構成を採ります。端末がAD DS参加かEntra ID参加か、またはハイブリッド参加かを台帳で判定し、参加形態ごとに保管先を一つに定めます。AD DSとEntra IDの両方で検索できるか曖昧なまま展開すると、障害時に担当者がキーを探し回ることになります。
端末展開時のポリシー適用や初期設定手順を標準化したい方は、PCキッティング手順書のサンプルと効率化のコツを参考にしてみてください。
▲ GPOによるBitLocker設定と回復キー保護の構成手順
無効化と保護の一時停止の操作手順
BIOS更新や修理のために必要なのは、多くの場合、暗号化を完全解除する無効化ではなくBitLocker保護の一時停止です。
完全な無効化はドライブを復号する処理です。容量やデータ量によって完了まで時間がかかり、その間は紛失・盗難時の暗号化保護がありません。一方、保護の一時停止はデータを暗号化したまま、次回再起動時などの構成変更で回復キーを要求しないよう保護機能を一時的に止める操作です。
デバイスの暗号化の無効化
［設定］＞［プライバシーとセキュリティ］＞［デバイスの暗号化］が表示される端末では、同画面のスイッチをオフにすると復号を開始できます。この画面が存在しない場合は、端末がデバイスの暗号化の対象外であるか、BitLockerドライブ暗号化として管理されている構成です。どちらであるかは、コントロールパネルの［BitLocker ドライブ暗号化］にドライブ別の管理画面が表示されるかで判断し、表示される場合はその画面から操作します。表示されない場合は、組織の管理ポリシーと回復キーの保管先を確認したうえで担当部門へ問い合わせます。
BitLockerの完全無効化
管理者権限のアカウントで［コントロール パネル］＞［システムとセキュリティ］＞［BitLocker ドライブ暗号化］を開きます。
対象ドライブで［BitLocker を無効にする］を選び、確認画面で復号を開始します。
進捗が完了するまで電源断やストレージ取り外しを行わず、
manage-bde -status C:で暗号化状態を確認します。
管理者として実行したコマンドプロンプトでは、manage-bde -off C:で完全復号を開始できます。PowerShellではDisable-BitLocker -MountPoint "C:"を使えます。端末を廃棄・再利用する前の再構成など、暗号化を継続できない明確な理由がある場合に限定します。
BIOS更新前の保護一時停止
BIOS/UEFI更新やTPM設定変更の前には、管理者権限でSuspend-BitLocker -MountPoint "C:" -RebootCount 1を実行します。コマンドプロンプトならmanage-bde -protectors -disable C: -RebootCount 1です。なお、-RebootCount 1は再起動1回分の猶予であり、ファームウェア更新が複数回の再起動を伴う場合は更新回数に合わせてカウントを増やすか、更新完了まで保護停止を維持します。更新と再起動後にResume-BitLocker -MountPoint "C:"またはmanage-bde -protectors -enable C:で保護が有効かを確認します。マザーボード交換やTPM交換では、保護を停止していても回復キーの入力が必要になる場合があります。作業前に回復キーが保管先から取り出せることを確認し、メーカーや修理事業者の手順書と照合したうえで実施します。
Microsoftの回復ガイドは、BIOS/UEFI変更、TPM初期化、マザーボード交換などを回復キー要求の代表例として挙げています。保守作業の申請フローに「回復キー保管確認」「保護停止」「更新」「保護再開」「状態記録」を組み込み、復号を標準手順にしない運用へ切り替えます。
▲ 作業目的と端末状態に応じた「保護の一時停止」と「完全無効化」の選択フロー
勝手な無効化を防ぐ統制方法
利用者によるBitLockerの無効化や保護中断を防ぐ基本は、日常利用アカウントからローカル管理者権限を外すことです。
ローカル管理者が常用される端末では、BitLockerの設定変更だけでなく、暗号化機能を悪用するスクリプトやセキュリティ設定の改変も実行されやすくなります。Windowsのローカル管理者アカウントでサインインしている利用者は、BitLockerの設定変更や解除を実行できます。情シスは、管理者権限を持つ利用者を前提に「設定変更を禁止する」だけでは統制できません。
端末統制の優先順位
標準ユーザー化します。通常業務のアカウントからローカルAdministratorsグループへの所属を外します。
昇格手順を分離します。ソフトウェア導入や保守で権限が必要な場合は、情シスが承認した一時的な管理者昇格に限定します。
暗号化ポリシーを再適用します。GPOまたはIntuneで暗号化要件を設定し、未暗号化端末を検出できる状態にします。
状態と回復キーを照合します。端末台帳、暗号化状態、回復キー保管先を定期的に突合します。
特に、管理者権限を残したまま「BitLockerをオフにしないよう周知する」だけでは防止策になりません。利用者が管理者権限を必要とする業務があるなら、端末ごとに恒久付与するのではなく、申請・承認・期限・操作ログを残す方式へ変えます。
IPAは2024年度に中小企業4,191社を対象とした情報セキュリティ対策に関する実態調査を実施しています（IPAのニュースリリース）。同調査では、クライアントPCの設定・資産管理製品の導入が中小企業で十分に進んでいない実態が報告されており、暗号化の設定だけでなく、端末状態を一覧で把握する基盤が整備されにくい状況を示しています。台帳とGPOの対象OUが一致していない場合は、まず管理対象端末を確定し、その後に暗号化率の確認へ進みます。
万が一の端末紛失・盗難時に備えてデータの遠隔消去手段を整備したい方は、リモートワイプの仕組みとPC消去手順をまとめた解説をご覧ください。
BitLockerのデメリットと回復キー紛失の失敗パターン
BitLockerのデメリットは、性能影響よりも回復キー管理と変更作業の統制が不十分なときに業務停止へ直結する点です。
暗号化処理には端末性能への影響があります。EaseUSは2025年第1四半期の117,198台を対象とする「2025 Q1 Windows System Drive Usage Report」でBitLockerの有効化率を4.59％と公表しています。性能への影響はCPUの暗号化支援命令（AES-NI）の有無、SSDの種類、暗号化方式、業務アプリの負荷によって大きく異なるため、特定ベンダーの数値を自組織の全端末に当てはめることはできません。標準イメージの代表端末で暗号化前後の起動時間、業務アプリの応答、ファイル操作を実測してから本番展開の可否を判断します。
やってはいけない運用
回復キーを端末内の同じドライブや、利用者だけがアクセスできる場所に保存する運用です。
BIOS更新のたびにBitLockerを完全無効化し、再暗号化漏れを許す運用です。
回復キーのAD DSまたはEntra ID保存を検証せず、全社へ暗号化開始だけを配布する運用です。
通常利用者へローカル管理者権限を恒久的に付与する運用です。
回復キー要求時の対応フロー
端末を初期化しません。初期化はデータ復旧の選択肢を狭めます。
画面の回復キーIDを記録します。48桁の回復キーそのものをチケット本文やメールに記載しません。
管理台帳で端末の参加形態を判定します。Entra ID参加ならEntra ID、ドメイン参加ならAD DSの保管情報を優先して検索します。
保管先にキーがなければ変更履歴を確認します。直前のBIOS更新、TPM初期化、基板交換、OS再展開の有無を調べます。
キーを取得できない場合は復旧ではなく再展開を判断します。回復キーを迂回する手段を探さず、データ復元の可否と端末再セットアップを分けて扱います。
回復キーの紛失は、暗号化機能の故障ではなく保管プロセスの失敗です。MCoreは、BitLocker回復キーである48桁の数字を自動収集し一元管理する機能を案内しています。管理基盤を使う場合も、取得済み件数と管理対象PC数を照合し、キー未取得端末を展開完了と扱わないルールを設定します。
情シス向けの導入前チェックリスト
BitLockerの展開可否は、暗号化を開始できるかではなく、障害時に回復キーを確実に取り出せるかで判断します。
以下は、新規端末展開、既存端末の暗号化、BIOS更新フローを見直す際に使える確認項目です。すべてに回答できれば本番展開へ進み、一つでも未確定なら対象OUまたは端末グループを限定して検証します。
確認項目 | 確認結果による判断 |
|---|---|
端末がAD DS、Entra ID、ハイブリッドのどれに参加しているか | 参加形態ごとに回復キーの保管先と照会担当を分けます。 |
回復キーが暗号化開始前に保存されるポリシーか | 保存を確認できれば展開し、確認できなければポリシー検証を先に行います。 |
通常利用者がローカル管理者ではないか | 管理者なら権限分離を先行し、標準ユーザーなら暗号化統制へ進みます。 |
BIOS更新の実施主体と保護停止手順が定義されているか | 定義済みなら更新作業へ組み込み、未定義なら手順書と復旧責任者を決めます。 |
OS、固定、USBドライブのどこまで暗号化対象か | 対象別にGPOを分け、同一ポリシーで一律に扱いません。 |
端末台帳と暗号化状態を突合できるか | 突合できれば例外端末を追跡し、できなければ台帳整備を優先します。 |
既存の端末統制を見直す際は、Microsoft Intuneのリモート管理機能、ドライブ暗号化の基本、端末紛失時の対応フローもあわせて確認すると、暗号化後の端末管理まで設計しやすくなります。
暗号化設定を含む端末調達から廃棄までの運用工数を削減したい方は、デバイスLCM効率化のメリットと運用改善のポイントをご確認ください。
まとめ
BitLockerは、Windows端末のストレージを暗号化し、紛失・盗難時のデータ漏えいを抑える標準機能です。情シスの運用では、デバイスの暗号化とBitLockerを画面名だけで混同せず、AD DSまたはEntra IDへの回復キー保存、管理者権限の分離、GPOによるポリシー統制を先に整えます。
明日着手するなら、まず端末台帳から1台を選び、暗号化状態、参加形態、48桁の回復キー保管先を照合します。保管先を確認できた端末だけでBIOS更新前の保護一時停止を検証し、その結果を標準手順へ反映します。完全無効化を保守作業の標準にしないことが、暗号化漏れと回復不能の両方を防ぐ出発点です。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
