はじめに
中小企業では、メール・ファイル共有・日常のコラボレーション基盤として Google Workspace を使っている一方で、業務端末は Windows PC という構成がよくあります。
この場合、次のような課題が出ます。
・オンプレADをやめたい
・Windows端末をクラウドで管理したい
・Google Workspaceはそのまま使い続けたい
・Microsoft 365へ全面移行する必要はない
・ただしWindows端末のセキュリティは強化したい
・社員数が増えても破綻しないID/端末管理にしたい
本記事では、Google Workspaceを使い続けながら、Windows端末管理だけを Microsoft Entra ID / Intune / Defender for Business に寄せる設計パターンを整理します。
この記事は特定環境の実構成ではなく、数十名規模の企業を想定した公開用の抽象化モデルです。実ドメイン、実ユーザー名、実グループ名、具体的なネットワーク構成は記載しません。
なお、本記事では例示用ドメインとして example.co.jp を使用しています。
想定する前提
この記事では、以下のような企業を想定します。
・社員数は20〜50名程度
・Google Workspaceを利用中
・GmailとGoogle Driveが業務基盤
・Windows 11 Pro端末を利用
・一部ユーザーだけOfficeデスクトップアプリが必要
・オンプレADを段階的に廃止したい
・ファイルサーバはGoogle Driveへ移行済み、または移行予定
・Windows端末はクラウド管理へ移行したい
・Google WorkspaceをMicrosoft 365へ全面移行する予定はない
重要なのは、Google Workspaceを捨てる設計ではないという点です。
Google Workspaceは、メール・ファイル・カレンダー・コラボレーションの基盤として残します。
一方で、Windows端末管理はMicrosoftの仕組みに寄せます。
結論
この構成では、役割を次のように分けます。
Google Workspace:
Gmail
Google Drive
Google Calendar
Google Vault
Google側のユーザー管理
Microsoft Entra ID:
Windows端末利用者のID
Windowsサインイン
Intune / Defender / Office利用の前提ID
Microsoft Intune:
Windows端末管理
BitLocker
Windows Update
アプリ配布
ローカル管理者制御
コンプライアンス管理
Microsoft Defender for Business:
Windows端末のエンドポイント保護
脅威検知
アラート
修復支援
会社メールアドレス:
ベンダ非依存の独自ドメインを正本にする
つまり、GoogleとMicrosoftをどちらか一方に完全統合するのではなく、役割分担します。
なぜWindows端末管理はMicrosoft側に寄せるのか
Google Workspaceを使っていても、Windows端末そのものの管理は別問題です。
Windows端末では、以下のような管理が必要になります。
・端末の登録
・ディスク暗号化
・Windows Update
・ローカル管理者権限
・端末準拠性
・アプリ配布
・ウイルス対策
・紛失、返却、再利用時のワイプ
Microsoft Intuneは、クラウドベースのエンドポイント管理基盤です。Microsoftの公式ドキュメントでも、Intuneはユーザーアクセス、アプリ、デバイスを管理するクラウドベースのエンドポイント管理ソリューションとして説明されています。
Windows端末がMicrosoft Entra IDに参加または登録されると、設定に応じてIntuneへ自動登録できます。これにより、端末セットアップ時点から会社の管理ポリシーを適用できます。
Windows 11 Proを会社端末として管理するなら、Intuneを使う構成は自然です。
Microsoft Entra IDは「個人のMicrosoftアカウント」ではない
ここは誤解されやすい点です。
Microsoft Entra IDユーザー:
会社・組織のID
Microsoftアカウント:
個人用のID
会社のWindows端末管理に使うのは、Microsoft Entra IDユーザーです。
個人用Microsoftアカウントではありません。
Windows端末をMicrosoft Entra joinedにすると、ユーザーは会社のEntra IDでWindowsへサインインできます。Entra joined deviceは、組織所有端末をクラウドIDで管理するための基本構成です。
全体構成イメージ
公開用に抽象化すると、構成は次のようになります。
ポイントは、Google WorkspaceとMicrosoft Entraを無理に一体化しないことです。
IDの考え方
この設計では、次のようにIDを分けます。
会社メール:
user@example.co.jp
Google ID:
user@g.example.co.jp
Microsoft ID:
user@ms.example.co.jp
@ の前、つまり user 部分は同じにします。
これにより、GoogleとMicrosoftのアカウントを人間にも機械にも対応付けやすくなります。
この設計の利点は次です。
・会社メールアドレスをベンダ非依存にできる
・GoogleとMicrosoftのID空間を分けられる
・将来どちらかのサービスを変更しても影響を限定できる
・ID台帳で対応関係を管理しやすい
・既存のGoogle/Microsoftユーザーを作り直さずに済む
一方で、欠点もあります。
・ユーザーに複数のログインIDを説明する必要がある
・SSOや自動プロビジョニングは設計が少し複雑になる
・入退社時にGoogleとMicrosoftの両方を扱う必要がある
・Google側グループとMicrosoft側グループが不整合になりやすい
そのため、後段ではIDaaSを使って、ID突合・グループ・ライセンス管理を自動化する余地があります。
ただし、最初からIDaaSを唯一の認証基盤にする必要はありません。
ユーザー区分とライセンス設計
ユーザーは端末とOffice利用有無で分けます。
1. Windows端末あり、Officeあり
2. Windows端末あり、Officeなし
3. Chromebookのみ
4. 端末なし
考え方は次です。
Windows + Officeあり:
Google Workspace
Microsoft 365 Business Premium
Windows + Officeなし:
Google Workspace
Microsoft Entra ID P1
Microsoft Intune Plan 1
Microsoft Defender for Business
Chromebookのみ:
Google Workspace
必要に応じてChromeOS端末管理
端末なし:
Google Workspaceのみ
Microsoft 365 Business Premiumには、Intune、Microsoft Entra ID P1、Defender for Businessが含まれるため、Officeを使うWindowsユーザーでは候補になりやすいです。
Officeを使わないWindowsユーザーは、Intune / Entra ID P1 / Defender for Businessを個別に付与する構成が考えられます。
端末移行の考え方
既存のオンプレAD参加PCをそのまま最終形にするのは、基本的には避けます。
標準方針は次です。
新規PC:
初回起動時にMicrosoft Entra join
Intuneへ自動登録
Defender for Businessへオンボード
既存AD参加PC:
データ退避
ワイプ
Microsoft Entra join
Intune登録
必要アプリ再配布
データ戻し
短期的には、AD参加PCにIntuneやDefenderを載せて橋渡し運用することはあります。
ただし、AD廃止後の最終形を確認するには、Microsoft Entra joined / DomainJoined = No の端末で業務が回るかを確認する必要があります。
新規PCの標準セットアップ
新規PCでは、利用者本人が初回起動時に会社のEntra IDでサインインする構成にできます。
1. PCを起動
2. インターネットへ接続
3. 「職場または学校にセットアップ」を選択
4. Microsoft Entra IDユーザーでサインイン
5. Intuneへ自動登録
6. BitLocker、Defender、Windows Update、アプリ配布が適用
より標準化したい場合は、Windows Autopilotを使います。
Autopilotを使うと、利用者へPCを渡す前に端末を事前登録し、初回セットアップ時の挙動を制御できます。
回収PCの再利用
一度利用したPCを回収して別ユーザーに渡す場合は、ユーザーに初期化させず、管理者が管理画面から初期化します。
標準は次です。
利用者:
ローカルデータを同期・退避
私用アカウントや不要なローカルデータを整理
PCと付属品を返却
管理者:
資産番号と状態を確認
Intuneでデバイスを確認
必要に応じてデータ退避
Wipeを実行
次の利用者に引き渡し
会社端末の再利用では、基本は Wipe です。
個人データや旧ユーザー設定を残したまま別ユーザーへ渡す運用は避けます。
AD廃止で見るべき依存関係
ADを廃止する前に、次を確認します。
・ファイルサーバ
・プリンタ
・VPN
・RADIUS
・業務アプリのWindows統合認証
・ログオンスクリプト
・GPO
・共有アカウント
・ローカル管理者権限
ファイルサーバがGoogle Driveへ移行済みで、プリンタサーバやVPN依存が少ない場合は、AD廃止の難易度は下がります。
逆に、Windows統合認証やGPO依存が多い場合は、Intuneへの移行だけでは解決しません。
IDaaSはどう位置づけるか
GoogleとMicrosoftのIDを分けると、どうしても運用負荷が発生します。
・入社時にGoogleとMicrosoftの両方を作る
・退職時に両方を停止する
・Windows利用者だけMicrosoftライセンスを付ける
・Officeあり/なしでライセンスを分ける
・Google側グループとMicrosoft側グループを合わせる
この問題に対して、IDaaSを導入する余地があります。
ただし、IDaaSを入れる場合でも、いきなり次のようにはしません。
・IDaaSを唯一の認証基盤にする
・IDaaSを唯一のID正本にする
・Google/Microsoftの既存ユーザーを作り直す
・ユーザー削除を完全自動化する
最初は、次の役割に限定するのが安全です。
・既存Google/Microsoftユーザーの突合
・差分確認
・グループ連携
・ライセンス連携
・入退社処理の補助
つまり、IDaaSは「すべてを任せる基盤」ではなく、壊れても手動運用へ戻せる自動化層として使います。
この構成のメリット
・Google Workspaceをそのまま活かせる
・Microsoft 365への全面移行が不要
・Windows端末管理はMicrosoft純正基盤に寄せられる
・Defender for Businessで端末セキュリティを強化できる
・会社メールアドレスをベンダ非依存にできる
・Google / Microsoft のID空間を分けたまま運用できる
・IDaaS導入時も、依存しすぎない設計にできる
この構成の注意点
・Google IDとMicrosoft IDの対応表が必要
・最初から自動プロビジョニングを入れると事故りやすい
・旧AD参加PCは原則ワイプ再構成を前提にする
・break-glass管理者は自動化対象外にする
・hard deleteは自動化しない
・メール保全はGoogle Vaultと配送経路の整理が必要
特に重要なのは、削除を自動化しすぎないことです。
入退社処理では、まず停止・ライセンス剥奪・グループ削除までを自動化し、完全削除は管理者承認にする方が安全です。
段階導入ロードマップ
現実的には、次の順番で進めます。
Phase 1:
Google / Microsoftの既存ユーザー突合
Windows利用者区分の整理
Pilotユーザー作成
Phase 2:
Intune / Entra / Defenderの試験導入
新規PCでEntra join検証
既存PCの移行手順検証
Phase 3:
Windows端末の標準ポリシー作成
BitLocker
Windows Update
Defender
ローカル管理者制御
アプリ配布
Phase 4:
旧AD依存の棚卸し
ファイル、プリンタ、VPN、業務アプリ確認
Phase 5:
IDaaSによるID突合・グループ・ライセンス連携の検討
Phase 6:
Google Vaultとメール配送経路の整理
まとめ
Google Workspaceを使っている企業がWindows端末管理をクラウド化する場合、必ずしもMicrosoft 365へ全面移行する必要はありません。
現実的には、次の役割分担が有効です。
Google Workspace:
メール、ファイル、コラボレーション、Vault
Microsoft Entra / Intune / Defender:
Windows端末管理、端末セキュリティ、Office利用者管理
会社メールアドレス:
ベンダ非依存の独自ドメイン
IDaaS:
必要に応じてID突合・連携・ライフサイクル管理を補助
重要なのは、どれか一つのベンダに全てを寄せることではなく、役割を分けたうえで、壊れても手動運用へ戻せる構成にすることです。
次回は、IDをベンダに依存させないためのGoogle / Microsoft分離設計について整理します。