グループポリシーでMicrosoft OneDriveを管理するには、対象端末と同じ更新系列のOneDrive同期アプリからOneDrive.admxと対応言語のOneDrive.admlを取り出し、Active Directoryの中央ストアへ対で配置します。最初に確認するのは、同期アプリがユーザー単位かコンピューター単位か、現在のビルド、対象Windows、Microsoft 365テナントID、既存のIntune設定との競合です。2026年7月時点では、公式資料が示す同期アプリのadmフォルダーを使い、インターネット上の転載テンプレートは使いません。中央ストアを丸ごと上書きせず、バックアップと差分レビュー後に検証OUで「OneDrive」が管理用テンプレートに表示され、設定が実機へ届くことまで確認してから展開します。
管理テンプレート追加前に決めること
ADMXを置くだけではOneDrive管理方針は完成しません。サインインを自動化するのか、個人用OneDriveを許可するのか、既知のフォルダー移動を使うのか、Files On-Demandを必須にするのか、同期帯域や更新リングをどう扱うのかを先に決めます。設定ごとに対象ユーザーまたは端末、目的、例外、検証条件、戻し方を台帳へ記録してください。OneDriveの同期対象には個人データや組織文書が含まれるため、設定を誤ると大量ダウンロード、ディスク不足、意図しないテナント同期、利用者のフォルダー移動につながります。最初は表示確認だけのGPOを作り、データ移動を伴う設定は別GPOへ分離すると影響を追跡しやすくなります。
- ユーザー単位インストールか、共有PC向けのコンピューター単位インストールかを端末台帳で確認する。
- OneDrive同期アプリのバージョン、更新リング、Windowsの版とビルドを記録する。
- 対象テナントのTenant IDをMicrosoft Entra管理情報から確認し、記事の例示値を使わない。
- 既存のGPO、Intune管理用テンプレート、設定カタログ、レジストリ配布の重複を洗い出す。
- 同期ヘルス、ディスク空き容量、ネットワーク帯域、問い合わせ件数を展開判断の指標にする。
OneDrive ADMXとADMLの公式な取得場所
MicrosoftのOneDrive管理資料では、Windows用同期アプリをインストールするとADMX/ADMLも取得されると説明されています。ユーザー単位インストールでは通常、利用者プロファイル配下のMicrosoft、OneDrive、ビルド番号、admフォルダーを確認します。コンピューター単位インストールでは、OSアーキテクチャに応じてProgram FilesまたはProgram Files (x86)配下のMicrosoft OneDrive、ビルド番号、admを確認します。OneDrive.admxは言語に依存しない定義で、ja-JPやen-USなどのサブフォルダーにあるOneDrive.admlが表示文字列です。片方だけを更新するとGPMCで説明が欠けたりリソース参照エラーになったりするため、必ず同じビルドから対で取得します。
取得元にする端末は、利用者が偶然入れた古い同期アプリではなく、IT部門が検証したビルドの管理端末にします。OneDriveの設定画面にあるバージョン情報とadmの親フォルダー名を照合し、取得日、ファイルサイズ、ハッシュを記録してください。同期アプリは段階的に更新されるため、同じ日に全端末が同じビルドとは限りません。新しいテンプレートにある設定を古い同期アプリへ配ると、ポリシー値が存在しても機能しない可能性があります。先に検証対象の最低同期アプリ版を定め、アプリ更新とテンプレート更新を同じ変更計画に含めます。
中央ストアをバックアップして差分を確認する
ドメインで管理用テンプレートを共有する場合、GPMCはSYSVOLにあるPolicyDefinitions中央ストアを優先します。中央ストアが既にある環境では、ローカルのC:\Windows\PolicyDefinitionsへOneDrive.admxを置いてもGPMCへ表示されません。まずドメインのPolicyDefinitionsが存在するか、どの言語フォルダーを使うかを確認します。変更前にフォルダー全体を読み取り専用のバックアップ場所へコピーし、復元担当と復元手順を決めてください。Microsoftも、アプリケーション用ADMXを含むリポジトリを保つこと、版を示す中央ストア候補を作ってテストする方法を説明しています。稼働中の中央ストアへWindowsの全テンプレートを無差別に上書きしません。
- 既存PolicyDefinitionsのパス、サイズ、ファイル一覧、言語フォルダーを取得して変更記録へ保存する。
- 中央ストア全体を世代バックアップし、OneDrive.admxとOneDrive.admlの既存版を別に保管する。
- 検証済みOneDriveビルドのadmからADMXと必要言語のADMLを作業フォルダーへコピーする。
- 新旧ファイルのハッシュと更新日時を比較し、追加されたポリシー名を公式資料と照合する。
- 検証時間帯に中央ストアへ配置し、複数ドメインコントローラーのSYSVOL複製完了を確認する。
- 二台以上の管理端末からGPMCを開き、エラーなくOneDrive項目と説明が表示されるか確認する。
OneDrive.admxと各言語のADMLを配置する
OneDrive.admxはPolicyDefinitions直下、OneDrive.admlはPolicyDefinitionsのja-JPやen-USなど使用言語のサブフォルダーへ置きます。GPMCを日本語環境と英語環境の両方で使うなら、両言語のADMLを同じビルドから配置します。ファイル名の大小文字や似た名前の旧SkyDriveテンプレートを取り違えないでください。配置権限はDomain Adminsを日常利用するのではなく、組織の変更管理に従う専用管理経路へ限定します。SYSVOLの編集は全ドメインコントローラーへ複製される変更です。コピーの途中でGPMCを開く管理者がいると不整合な表示になることがあるため、作業時間を周知し、配置後の複製状態とイベントを確認します。
管理用テンプレートが表示されない場合は、同じファイルを繰り返し上書きする前に、GPMCが中央ストアを参照しているか、ADMLの言語フォルダーが管理端末の表示言語と一致するか、ADMXとADMLが同じビルドかを確認します。OneDrive設定が「従来の管理用テンプレート」に見つからない場合も、表示ツリーの場所を公式ポリシー一覧で検索します。設定名は同期アプリ更新で追加・説明変更されるため、古いブログ画面と一致しなくても不具合とは限りません。GPMCのポリシー説明、対応レジストリ、必要同期アプリ版を公式ページで照合してください。
検証用GPOを作り対象を限定する
テンプレート確認と本番設定を同じ巨大GPOへ入れず、目的が分かるOneDrive専用GPOを作ります。コンピューター構成の設定は端末アカウントを含む検証OU、ユーザー構成は利用者アカウントを含む検証OUへリンクします。共有PCでユーザー設定を端末基準にする場合だけループバック処理を設計し、既存GPOへの影響を別に検証します。セキュリティフィルター、WMIフィルター、継承、リンク順序を台帳へ記録し、最初から全社OUへリンクしません。GPOには「OneDrive-Policy-Pilot-2026」のような名前を付け、各設定の所有者と変更チケットを説明へ残します。
最初に検討する代表的なOneDriveポリシー
テンプレートには多数の設定がありますが、すべてを有効にする必要はありません。サインイン、Files On-Demand、既知のフォルダー移動、同期対象テナント、個人アカウント、帯域、更新リング、同期ヘルスなど、業務要件のあるものだけを選びます。設定名の「有効」が機能を許可する意味とは限らず、「特定機能を禁止する」を有効にするような二重否定もあります。各ポリシーの説明にある適用範囲、必要バージョン、値形式を読み、有効・無効・未構成の三状態を検証してください。テナントIDやライブラリIDなどの識別子は管理ポータルから正確に取得し、Web記事のサンプルGUIDを使用しません。
- サイレントサインインは端末の参加状態、Microsoft Entra ID、認証要件を満たすか確認する。
- Files On-Demandはディスク節約に有効だが、オフライン業務で必要なファイル保持方針を決める。
- Known Folder MoveはDesktop、Documents、Picturesの移動と既存データ量、アプリ互換を事前調査する。
- 個人用OneDrive禁止やテナント制限は、取引先テナントやゲスト業務の例外を確認する。
- アップロード・ダウンロード帯域は拠点回線と他のクラウド通信を測定してから決める。
- 同期ヘルスレポートは管理者権限、データの扱い、対象端末版を確認して段階導入する。
OneDrive更新とOffice更新を混同しない
OneDrive同期アプリは、Microsoft 365 Appsと一緒に展開した場合でもOffice更新ポリシーとは独立して更新を確認します。同期アプリは更新リングと段階展開に従い、実行中であれば必要に応じて停止・更新・再起動されます。そのため、Officeの更新チャネルを固定しただけではOneDriveのビルドを固定できません。テンプレートを更新する際は、OneDriveのリリースノート、更新リング、到達に必要なMicrosoftのURL、端末の実バージョンを確認します。更新を全面停止するのではなく、検証リングで先に業務アプリ、同期、Known Folder Moveを試し、本番リングとの差を監視します。古すぎる同期アプリは一段階で最新にならない場合もあるため、最低対応版を台帳にします。
GPOの適用を端末で確認する
- 検証端末を再起動し、検証ユーザーでサインインしてOneDriveのビルドとインストール方式を記録する。
- gpresultのHTMLレポートで対象のコンピューターGPOとユーザーGPOが適用されたか確認する。
- 公式資料に示されるポリシー対応レジストリを読み取り、値の有無とデータ形式を照合する。
- OneDriveを再起動または再サインインし、設定画面、サインイン、同期対象、Files On-Demandを確認する。
- 小容量の検証ファイルでアップロード、ダウンロード、名前変更、競合、オフライン復帰を確認する。
- イベント、OneDriveログ、同期ヘルスでエラーとバージョンを確認し、利用者画面だけで成功判定しない。
設定が反映されない場合は、ADMXの再配置より先にGPO適用範囲を調べます。ユーザー設定を端末OUへリンクしていないか、コンピューター設定をユーザーOUへリンクしていないか、セキュリティフィルターが拒否していないか、Intuneが反対の値を配っていないかを確認します。レジストリへ値があるのに動作しない場合は、同期アプリの最低版、値形式、再起動・再サインイン要件、テナントIDを確認します。トラブル切り分けのために利用者の同期フォルダーを削除したり、クラウドファイルを大量に移動したりしないでください。検証アカウントと小さなテストライブラリを使います。
Known Folder Moveは独立した移行として扱う
デスクトップ、ドキュメント、画像をOneDriveへ移すKnown Folder Moveは、単なる表示設定ではなく利用者データの保存場所を変える移行です。対象フォルダー容量、禁止拡張子、長いパス、既存同期エラー、FSLogixやVDI、業務アプリの固定パス、ネットワーク帯域を調査します。サイレント移行を全社へ一度に有効化せず、代表部門でバックアップと復旧を試してください。ポリシー解除時にファイルが自動で元の場所へ戻るとは限りません。移行前の場所、OneDrive同期完了、クラウド側の保持、端末交換時の復元を文書化し、利用者へ「移動」「同期」「バックアップ」の違いを説明します。
段階展開と戻し方
本番展開はIT部門、少人数の協力部門、拠点単位、全社の順に進めます。同期エラー率、サインイン失敗、Known Folder Move成功率、ディスク空き容量、ネットワーク転送量、同期アプリ版、問い合わせ件数を判定材料にします。問題が出たときは、GPOリンクを無効にする、対象セキュリティグループを縮小する、問題の設定だけを未構成または検証済みの復旧値へ戻す、旧ADMXへ戻す、のどれが必要かを事前に決めます。ADMXを旧版へ戻しても、既にクライアントへ書かれたポリシー値や移動済みデータが自動復旧するとは限りません。GPOバックアップ、中央ストア旧版、設定レポート、データ移行手順を同じ変更単位で保管します。
OneDriveをGPOで一元管理する要点は、公式同期アプリから同じビルドのADMX/ADMLを取得し、中央ストアへ安全に配置し、アプリ版と設定要件を一致させることです。テンプレートが表示された段階は準備にすぎません。検証OUでGPO、レジストリ、OneDrive実動作、同期ヘルス、データ移動、ロールバックまで確認し、管理経路をGPOかIntuneのどちらかへ整理してから展開してください。
コメント