お問い合わせ
STRATEGY NOTE — 149

オンプレADからGoogle Cloud Identityへ段階移行する設計ロードマップ

PUBLISHED2026.06.13
READ12 分
CATEGORYSTRATEGY

Active Directory（AD）から Google Cloud Identity への段階移行では、一括でのシステム切り替えが現実的に難しいケースがほとんどです。この記事では、Secure LDAP を入口にした3フェーズの移行ロードマップを、設計判断の観点で整理します。

この記事を読んだほうが良い人

  • オンプレ Active Directory と Google Workspace / Cloud Identity を現在ハイブリッドで運用している情シス担当者
  • AD を廃止したいが、一気に切り替えるリスクが取れず移行が止まっている方
  • Active Directory Google Cloud Identity 段階移行の具体的なロードマップと判断基準が必要な方
  • 100 名規模企業で Google Workspace の ID 管理をオンプレ AD から完全移行したいと考えている IT 担当者

オンプレ AD に依存するシステムは多岐にわたります。VPN 認証、Wi-Fi RADIUS サーバー、ファイルサーバー、業務アプリ（Atlassian Jira・GitLab・Confluence など）、Windows 端末の Domain Join がその代表例です。これらを一度に切り替えることは現実的ではなく、移行期間中は AD と Cloud Identity が共存するハイブリッド構成が前提になります。

Google が提供する移行アーキテクチャは、大きく2つのレイヤーで成り立ちます。

  • プロビジョニング層：AD のユーザー・グループを Cloud Identity に同期する（Google Cloud Directory Sync / Directory Sync）
  • 認証層：LDAP アプリや各サービスの認証先を、Cloud Identity の Secure LDAP に順次切り替える

この2レイヤーを段階的に移行するのが、リスクを抑えながら AD 廃止を目指すアプローチの核心です。

GCDS と Directory Sync の違い

同期ツールには2種類あります。Google Cloud Directory Sync（GCDS） はオンプレサーバーにインストールして動かすクライアント型のツールで、長年の実績があります。一方、Directory Sync はクラウドネイティブな後継サービスで、管理コンソールから設定します。同期処理はクラウド側で完結し、オンプレへのソフトウェアインストールは不要です。オンプレ AD への接続には Google Cloud 側の VPC アクセスコネクタを設定します。

現時点で新規導入する場合は Directory Sync を選ぶのが基本方針です。ただし、既存の GCDS 設定が複雑にカスタマイズされている場合は、Directory Sync への切り替え自体を別フェーズとして計画することも検討します。いずれも同期方向は AD から Google への一方向であり、Google 側で手動変更しても次の同期で AD の値に上書きされる動作は共通です。

エディション要件の確認

Secure LDAP の利用可否はエディションに依存するため、移行計画の初期段階で確認が必要です。

  • 利用可能：Cloud Identity Premium、Workspace Business Plus、Enterprise Standard、Enterprise Plus、Frontline Standard、Frontline Plus、Enterprise Essentials Plus、Education Standard、Education Plus
  • 利用不可：Cloud Identity Free

Cloud Identity Free を使用中の場合、Secure LDAP を移行の軸にするロードマップは成立しません。有料エディションへのアップグレードか、移行アーキテクチャ自体の見直しが必要です。現行の契約エディションを確認してから移行計画を立てます。

Secure LDAP と AD 廃止に向けた依存関係チェック

移行フェーズに入る前に、現環境の AD 依存を棚卸しします。この棚卸しの精度が移行の成否を分けます。

依存するシステムを以下の3カテゴリに分けて整理すると、後工程の優先順位が立てやすくなります。

カテゴリ 代表的なシステム 移行方針
LDAP バインド認証 VPN、Wi-Fi RADIUS、Jenkins、Confluence、GitLab Secure LDAP への切り替え候補
Kerberos / Windows 統合認証 IIS アプリ、オンプレ SharePoint、一部の業務パッケージ Managed Microsoft AD への移行 or モダン認証への改修
GPO / ドメイン管理 Windows 端末のドメイン参加、レジストリ配布、スクリプト実行 Endpoint Management への代替 or GCPW 検討

LDAP 認証を使っているアプリ・サービス

VPN、Wi-Fi RADIUS、Jenkins、Confluence、GitLab など、LDAP バインド認証で AD に問い合わせているサービスをリストアップします。これらは Secure LDAP への切り替え候補です。

Kerberos 認証に依存しているアプリ

Windows 統合認証（IWA）や Kerberos チケットを要求するアプリは、Secure LDAP では代替できません。Cloud Identity は Kerberos ドメインコントローラーの役割を果たさないためです。こうしたアプリは Google Cloud の Managed Microsoft AD（Google Cloud が提供するマネージド Active Directory サービス）への移行か、SAML/OIDC などのモダン認証へのアプリ側改修を個別に計画します。Kerberos 依存アプリの見落としは、フェーズ3での最大のリスクになります。

グループポリシー（GPO）依存の Windows 設定

GPO で管理しているレジストリ設定・スクリプト実行・ソフトウェア配布は、Google Workspace の Endpoint Management で代替できる部分とそうでない部分があります。全量の代替可否を確認し、代替不可の設定は別途移行計画に含めます。

カスタム属性の洗い出し

部署名・役職・電話番号など AD に格納されているカスタム属性を Google 側でも保持するか決めます。保持する場合は、GCDS または Directory Sync の設定に属性マッピングを追加します。この判断をフェーズ1の開始前に固めておかないと、フェーズ2での設定変更が必要になり同期のやり直しが発生します。

3フェーズ移行ロードマップ

以下の表は3フェーズの全体像と、各フェーズにおける AD の役割をまとめたものです。

フェーズ 主な作業 AD の役割
フェーズ1 GCDS / Directory Sync 初期設定・Secure LDAP 接続テスト 権威サーバー（AD が master）
フェーズ2 属性・グループ同期精緻化、LDAP アプリ本番切り替え 権威サーバー（同期でミラー）
フェーズ3 全依存移行完了・AD 廃止 停止・廃止

フェーズ1：初期同期と Secure LDAP 接続テスト

まず GCDS または Directory Sync を使って、AD のユーザーとグループを Cloud Identity に一方向で同期します。この時点では AD が権威サーバーのままなので、既存業務への影響はありません。

Secure LDAP については、小規模なパイロットグループ（社内テスト用の OU や 10 名前後のアカウント）を対象に接続を設定し、1〜2 本の LDAP アプリを試験的に Cloud Identity の LDAP エンドポイントへ向けてテスト認証を確認します。Secure LDAP への接続にはクライアント証明書が必要で、管理コンソールから発行・ダウンロードします。証明書の有効期限は発行時に確認し、期限切れアラートをカレンダーに登録しておきます。

フェーズ1の主な設計判断ポイント

  • エディション確認：上述の通り、Secure LDAP は Cloud Identity Free では利用できません。フェーズ1の開始前にエディションを確認します
  • Google パスワードと SSO の非互換：Secure LDAP によるバインド認証には、ユーザーが Google パスワードを保持している必要があります。SAML 経由で AD FS（Active Directory Federation Services）などの外部 IdP に認証を委任している SSO 専用のアカウントは Secure LDAP 認証ができません。移行期間中は Google パスワードを持つアカウントと SSO アカウントが混在する設計になるため、どのアカウントがどちらの設定かを早期に整理します
  • 同期の方向は AD → Google の一方向：Google 側で手動変更しても、次の同期で AD の値に上書きされます。Cloud Identity 側を「AD のミラー」として扱うことを設計の前提とします

フェーズ2：属性・グループ同期の精緻化と認証の本番切り替え

フェーズ1でテストが安定したら、同期設定を詳細化します。カスタム属性の追加マッピング、グループネストの設定、Exclusion Rule（特定 OU を同期対象外にするルール）の調整が主な作業です。

認証層では、テスト済みのアプリを本番移行し、残りの LDAP アプリを依存関係リストに沿って順次切り替えます。「Secure LDAP で代替可能か」「Kerberos が必要か」を確認しながらリストを消化します。

Windows 端末と GCPW の判断

Windows 端末の Domain Join の扱いについては、このフェーズで GCPW（Google Credential Provider for Windows）の導入可否を判断します。GCPW は Windows ログインに Google アカウントを使えるようにする仕組みで、AD Domain Join なしで端末を Google の MDM 管理下に置けます。ただし以下の制約を把握した上で判断が必要です。

  • オフライン環境でのログインにはキャッシュ認証の設定が必要で、ポリシー設定を誤ると VPN 未接続時にサインインできなくなるリスクがある
  • GCPW は Windows 専用であり、macOS は別途 Workspace の macOS 管理機能で対応する
  • すでに他の MDM を使っている場合は、共存可否を事前に確認する

リモートワーカーやオフサイト作業が多い環境では、GCPW の導入前にオフライン時の業務継続要件を整理した上で判断します。

AD FS SSO の切り替えタイミング

SAML SSO を AD FS から Cloud Identity ネイティブの IdP 機能に切り替えるかどうかの判断が必要です。切り替えタイミングを誤るとシングルサインオンが一時的に機能しなくなるため、移行計画に十分なロールバック手順を含めてから実施します。AD FS 廃止はフェーズ3の完了後に行うのが安全です。

グループネストの同期動作の確認

AD 側のネストグループが Cloud Identity 側でフラット化されるケースがあります。フェーズ1のパイロット中に期待するグループ構造が維持されているかを確認し、差異があれば同期設定を調整します。グループ権限を多用している環境では、この確認を省略すると権限管理が機能しなくなるリスクがあります。

フェーズ3：AD 完全廃止と Cloud Identity 単独運用

フェーズ2で LDAP アプリの認証切り替えがほぼ完了したら、依存関係リストを最終確認します。「Cloud Identity / Workspace で代替済み」「Managed Microsoft AD に移行済み」「廃止済み」のいずれかが、すべての項目に付いていることが廃止の前提条件です。

AD サーバーの停止は一度に行わず、レプリカ DC を先に停止して業務影響を観察し、問題がなければプライマリ DC を停止する手順が標準的です。停止後も AD のバックアップは少なくとも30日間は保持します。予期しない依存が発覚した場合のリカバリ手段として残しておきます。

GCDS または Directory Sync は同期元（AD）の廃止とともに停止します。それ以降のユーザー・グループ管理は管理コンソールから直接行うか、HR システムとの SCIM（System for Cross-domain Identity Management）連携に移行するタイミングでもあります。SCIM 連携を採用する場合は、GCDS を止める前に SCIM プロビジョニングの設定を完了させ、同期の空白期間が生じないように計画します。

次のフェーズへ進む判断基準

段階移行でよくある問題が「判断基準が曖昧なまま次フェーズに進んでしまう」ことです。各フェーズの終了条件を事前に数値で定義することで、移行判断を属人化させないことが重要です。

フェーズ1 → フェーズ2 の条件

以下がすべて満たされてから次フェーズへ進みます。

  • パイロットグループ（10 名前後）での Secure LDAP 認証がすべて正常に動作している
  • 差分同期が 24 時間以上エラーなく継続している
  • 同期されたユーザーの主要属性（メールアドレス・表示名）が AD の値と一致している
  • クライアント証明書の有効期限がフェーズ2終了予定時点から 6ヶ月以上残っている

フェーズ2 → フェーズ3 の条件

以下がすべて満たされてから AD 廃止に進みます。

  • AD 依存リストのすべての項目が「移行済み」または「廃止済み」になっている
  • 同期を 一時停止した状態で1週間以上業務への影響が確認されていない（本番停止前のドライラン実施済み）
  • AD 関連のサービスデスク問い合わせが移行後 2 週間ゼロになっている
  • AD FS を使っている場合は、AD FS ログに認証リクエストが流れていないことを確認済み

ハイブリッド期間中のトラブルパターン

移行期間中に発生しやすいトラブルは、パターンに分けて事前に対処方針を決めておくことで影響を最小化できます。

パターン1：同期タイムラグによる認証失敗

AD で作成した直後のアカウントが Secure LDAP で認証できないケースは、同期間隔が原因のことが多いです。GCDS は定期実行で即時反映ではありません。オンボーディング直後のアカウントには手動で同期を走らせるか、次の同期タイミングを待つオペレーションを標準手順として定義します。Directory Sync に移行済みであれば、管理コンソールから即時同期をトリガーする手順を運用手順書に含めます。

パターン2：クライアント証明書の期限切れ

Secure LDAP の接続にはクライアント証明書が必要で、有効期限が切れると突然 LDAP アプリが認証不能になります。証明書の更新リマインダーをカレンダーに登録し、期限30日前にアラートが出る仕組みを作っておくことが重要です。フェーズ1のパイロット開始時点で証明書の有効期限を確認し、フェーズ2終了前に更新が必要なら早めに対応します。

パターン3：グループネストの意図しないフラット化

AD のネストグループが Cloud Identity 側でフラットなグループとして展開される設定になっていると、グループに紐づいた権限管理が機能しません。フェーズ1のテスト期間中にグループネスト同期設定を確認し、期待通りの構造になっているか検証します。

パターン4：GCPW キャッシュ認証の失敗

GCPW 導入後にオフライン環境でログインできないという問題が発生するケースがあります。GCPW はオフライン時のキャッシュ認証に制限があり、ポリシー設定と端末の接続状況によって挙動が変わります。GCPW の導入前にオフライン時の業務継続要件を整理し、検証環境で実機確認を済ませてから本番展開に進みます。

パターン5：SSO の設定が古い IdP を向いたまま残存

AD FS を経由した SAML SSO の設定を Cloud Identity に切り替えた後、一部のサービスプロバイダ（SP）が古い IdP（AD FS）を向いたままになっているケースがあります。SP 側の設定変更は個別対応が必要なため、フェーズ2の初期に対象アプリの一覧を作成し、優先順位をつけて順次対応します。

まとめ：移行を止める3つの落とし穴と対策

AD から Cloud Identity への段階移行で詰まる原因は、多くの場合、次の3点に集中します。

  1. Kerberos 依存の見落とし：Secure LDAP では代替できないアプリを移行リストから落としてしまい、フェーズ3でブロックされます。移行前の依存関係棚卸しで必ず洗い出します
  2. Secure LDAP と SSO の非互換の軽視：SSO 設定済みアカウントは Secure LDAP 認証ができないことを設計段階で考慮せず、移行後に認証障害が発生するリスクがあります
  3. 次フェーズ移行の判断基準の欠如：「だいたい動いているからフェーズ2へ」という曖昧な判断が後工程でのトラブルにつながります。フェーズ終了条件を事前に数値で定義することで防げます

3フェーズの流れ自体はシンプルです。実務的なリスクは「移行前の棚卸し」と「判断基準の設計」に集中しています。この2点に最も工数をかけることで、ハイブリッド期間中の大きな障害を防ぎ、AD廃止まで安定して到達できます。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。

CONTACT

御社の IT 部門、ここにあります。

「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。

無料相談を予約する → サービス詳細を見る
一社ずつ、一から。