【Microsoft Entra】Entra ConnectからCloud Syncへの移行【手順編】

1. 本記事の目的とできること

Microsoft Entra Connect（以下、Entra Connect）で運用している同期環境を、Microsoft Entra Cloud Sync（以下、Cloud Sync）へ実際に切り替えていく手順を解説します。

具体的には、移行することは決まったものの、実際に進めるとなると不安があるという方に向けた内容です。稼働中のID基盤に手を入れる以上、「どの順序で進めれば安全なのか」「途中で問題が起きたら元に戻せるのか」といった懸念はつきものです。そうした不安の要因になりやすい箇所を明示しながら、進め方を整理します。

移行は一括で切り替えるものではありません。次の流れで、対象範囲を限定した検証から段階的に拡大していきます。

1. 事前準備：現行構成をバックアップし、前提条件を確認
2. パイロット：特定のOUのみを対象に、Cloud Syncへ切り替えて検証
3. 段階移行と最終切り替え（カットオーバー）：問題がなければ対象範囲をバッチ単位で順次拡大し、全対象の移行完了後にEntra Connectの同期を停止

なお判断編では移行全体を6段階に分けて示していますが、本記事では実作業の単位でまとめ、上記の3ステップとして解説します（サーバーの撤去については第3章で触れます）。
それでは、各ステップの中身を順に見ていきます。

2. 移行手順の詳細

ここからは、各ステップで具体的に何を行うのかを見ていきます。なお移行可否のチェック項目そのものは、本記事では扱いません。「Entra ConnectからCloud Syncへの移行 判断編」にまとめてありますので、まだ確認していない場合は先にそちらをご覧ください。条件を満たしていないまま作業を始めると、途中で引き返すことになります。

加えて本記事では、プロビジョニングエージェントの導入やCloud Syncの基本設定そのものは、要点のみに留めています。これらの操作を一から確認したい場合は、別記事「Microsoft Entra Cloud Sync 導入手順」をご覧ください。エージェントのダウンロードからインストール、管理センターでの構成作成、スコープ フィルターによる同期対象の絞り込み、オンデマンドプロビジョニングでの動作検証までを、画面つきで順に解説しています。

本記事で省いた部分を補完できる内容ですので、Cloud Syncを触るのが初めての方は、あわせて開いておくと進めやすくなります。

2-1. ステップ1：事前準備（バックアップと前提確認）

設定変更に着手する前に、ロールバック（元の構成に戻すこと）が可能な状態を確保しておくことが最優先事項です。

1. Cloud Syncの前提条件を確認します。確認する対象は次の3つです。
   • Entra Connectのバージョン
     移行手順は1.4.32.0以降を前提としています。ただしこれは手順が動作する最低条件にすぎません。これとは別に、バージョン 2.5.79.0 以降でなければ2026年9月30日に同期サービスが停止します（1章の枠を参照）。1.4.32.0以降であることを確認して安心せず、2.5.79.0以降であるかまで見てください。
   • エージェントを設置するサーバー
     本記事の検証では、Entra Connectが動作している同期サーバーへエージェントを同居させています。
     エージェントを別のサーバーへ導入する場合は、Entra Connectの要件を流用できません。ドメイン参加・Windows Server 2016以降（Server Coreは非対応）・.NET Framework 4.7.1以上・メモリ4GB以上を、あらためて確認してください。同居させる場合、OSとランタイムの要件はおおむね満たしていますが、次の2点はEntra Connectの要件に含まれないため、別途チェックが必要です。
     • エージェントはgMSA（グループ管理サービス アカウント）で動作します。フォレストにKDSルートキーが未作成の場合は先に作成が必要です。KDSルートキーの作成後、全ドメインコントローラーへ複製が行き渡るまで最長10時間かかり、その間はgMSAを作成できません。未作成のまま構成ウィザードを実行すると、そこで失敗します。長く運用してきたフォレストでも未作成のケースは珍しくないため、事前に確認しておくこと。
     • PowerShellの実行ポリシーが Undefined または RemoteSigned であること。また Windows Credential Manager サービス（VaultSvc）が無効化されていないこと。
   • エージェントの通信要件
     通信先のURLとポートはEntra Connectと同一ではありません。プロキシやファイアウォールの許可リストに追加が必要な場合があります。
     TLS 1.2 の有効化とアウトバウンド 80／443 の許可に加えて、エージェントからドメインコントローラーへ TCP/389（LDAP）と TCP/3268（グローバル カタログ）が到達できる必要があります。Entra Connect側の許可リストで足りるとは限らないため、公式の前提条件ドキュメントで一覧をご確認ください。

   

   バージョンは、AzureADConnect.exe を右クリックして「プロパティ」→「詳細」タブを開き、ファイル バージョン（製品バージョンも同じ値です）で確認できます。既定のインストール先は "C:\Program Files\Microsoft Azure Active Directory Connect" です。

2. 移行対象のオブジェクトに mS-DS-ConsistencyGuid が設定されているかを確認します。Cloud Syncはこの値を使ってEntra ID側の既存オブジェクトと突き合わせ、値がない場合は objectGUID にフォールバックします。突き合わせに失敗すると同じユーザーが別オブジェクトとして重複作成されるおそれがあるため、着手前に状態を把握しておきます。
   • Entra Connectのソース アンカーが objectGUID または mS-DS-ConsistencyGuid である必要があります。Cloud Sync側はソース アンカーを変更できないため、これ以外の属性（社員番号などの独自属性）を使用している環境は、本手順の対象外です。この場合はソース アンカーの移し替えから検討することになるため、Microsoftサポートまたは公式の意思決定ガイドで扱いをご確認ください。
   • グループオブジェクトには既定で設定されません。Cloud Sync側にこの属性を書き戻す機能も公開されていないため、グループは objectGUID による突き合わせになります。Entra Connectもユーザー以外のオブジェクトには objectGUID を使うため、これは移行前後で変わりません。グループについて、事前に何かを設定する必要はありません。

   

3. Entra Connectの構成設定をエクスポートし、バックアップを取得します。手順は次のとおりです。 移行作業中の切り戻しは、Cloud Syncの構成とカスタム規則を無効化する方法（2-2節）やステージングモード（2-3節）で行います。エクスポートしたJSONは、それでも元に戻らない場合や、同期サーバーそのものを作り直すことになった場合の備えです。あとから取り直せないタイミングがあるため、着手前に必ず実施してください。
   • デスクトップの「Microsoft Entra Connect Sync」を起動します。
   • タスク一覧から「現在の構成の表示またはエクスポート」を選択します。
   • 「ソリューションのレビュー」画面が表示されるので、「エクスポート設定」をクリックします。
   • JSONファイルとして保存します。（既定の保存先は "%ProgramData%\AADConnect"）

   

   

   ⚠ エクスポートで必ず押さえる2点：
   ① Entra Connectウィザードで構成を変更すると、その都度JSONが "%ProgramData%\AADConnect" へ自動的に書き出されます。定期的にエクスポートする機能ではありませんので、「放っておいても最新のバックアップがある」状態にはなりません。一方、PowerShellや同期規則エディター、Synchronization Service Managerで加えた変更はこの自動出力の対象外です。これらを残すには、上の箇条書きで説明した「現在の構成の表示またはエクスポート」の操作が必須です（これが手動エクスポートにあたります）。
   本記事の2-2節ではNo-Flow規則を同期規則エディターで作成するため、その作成後にも、あらためてこの手動エクスポートを実施してください。
   ② 出力したJSONは、サーバー障害時に備えて同期サーバーの外にある安全な場所へ保管してください。

4. 本番環境に適用する前に、検証用のテストフォレストで一度通しておきます。この手順では規則の方向（受信／送信）とスコープの指定を手で入力するため、指定ミスが起きやすい箇所です。影響のない環境で先に洗い出しておくと、本番での手戻りを避けられます。

2-2. ステップ2：パイロット（一部のOUで試す）

限定した範囲で検証を行います。この工程で最も重要なのは、同一オブジェクトがEntra ConnectとCloud Syncの両方から同期されない状態を作ることです。

その手段として、Entra Connect側には「止める」操作が3種類あります。名前が似ていて紛らわしいのですが、止まる範囲がそれぞれ異なります。

本章で使うのはスケジューラの停止です。スケジューラの停止とステージングモードはどちらもサーバー単位の操作ですが、止め方が違います。前者が同期規則を編集している間だけの一時停止であるのに対し、ステージングモードは解除するまでEntra IDへの反映を止め続ける待機状態です。一部のOUだけを移行するパイロットでステージングモードを使うと、まだEntra Connectが担当している他のOUの更新まで止め続けることになるため、ここでは使いません。

1. 検証対象とするOU（組織単位）を決定します。新規に作成しても、既存のOUを利用しても構いません。
2. 対象OU内のユーザー数を事前に把握します（後の検証時に同期結果と突き合わせるためです）。ドメイン参加サーバー上で、ActiveDirectoryモジュール（RSAT-AD-PowerShell）が入った環境で実行してください。
   PowerShell ： 対象OU内のユーザー数を取得する

   # <OUの識別名（DN）> は OU=Sales,DC=contoso,DC=com のような形式で指定する
   (Get-ADUser -Filter * -SearchBase "<OUの識別名（DN）>" | Measure-Object).Count

3. Entra Connectのスケジューラを停止します。同期サーバーで管理者としてPowerShellを開き、次の2つを順に実行します。
   PowerShell ： スケジューラを停止する

   # 実行中の同期サイクルを止める
   Stop-ADSyncSyncCycle
   
   # スケジュール実行そのものを無効化する
   Set-ADSyncScheduler -SyncCycleEnabled $false

4. Entra Connect側の同期規則エディターで、カスタム同期規則を2本作成します。対象OU内のオブジェクトに cloudNoFlow=True という目印を付ける受信規則と、その目印が付いたオブジェクトのエクスポートを止める、リンク種別 JoinNoFlow の送信規則です。この2本が、上の枠で触れたNo-Flow規則にあたります。
   • この2つの規則により、Entra Connectは対象オブジェクトの追加・削除・属性更新をクラウドへ送らなくなります。
   • 一方で member や manager といった参照属性の更新は、参照を解決するために引き続き流れます。これは属性の書き込みを止めるNo-Flow規則の例外ではなく、同期エンジンが参照先のオブジェクトを突き合わせるための内部動作が残るという意味です。グループの所属やマネージャーの紐付けを保つための仕組みで、第3章の注意①が禁じている「両ツールによる並行同期」には当たりません。（補足：参照の解決とは、属性が指し示す相手のオブジェクトを同期エンジンが突き合わせる処理のことです。）
   • パスワードハッシュ同期（PHS）はNo-Flow規則の対象外です。PHSは同期規則とは別のサイクル（2分ごと）で動き、スコープ内のユーザーを一部だけ対象から外すことはできません（絞れるのはコネクタ単位です）。そのため、No-Flow規則を適用したOUのユーザーについても、Entra Connect側のPHSは動き続けます。ここでCloud Syncの構成でもPHSを有効にすると、同じユーザーに対して両方のPHSが動く状態になります。本記事の検証環境ではCloud Sync側もPHSを有効にしたまま進め、パイロット中に問題は発生しませんでしたが、公式の移行手順にはパイロット中のPHSの扱いについての記載がありません。本番環境での可否は、自社の認証方式に合わせてご判断ください。
   • 規則はユーザー・グループ・連絡先といったオブジェクトの種類ごとに必要です。ADコネクタ（フォレスト）が複数ある場合はコネクタごとにも作成するため、想定より本数が増える点は工数見積りで注意してください。

   同期規則エディターは、スタートメニューの「Azure AD Connect」フォルダー配下にある「Synchronization Rules Editor」から起動します（スタートメニュー上は旧名称の「Azure AD Connect」のまま表示されます）。

   

   画面右上の「Add new rule」をクリックすると、規則作成のウィザードが開きます。上段に並ぶ項目は既存の規則を絞り込むフィルターで、ここで値を選んでも規則は作成されません。

   

   1本目：受信規則　ウィザードの4つのページを順に設定します。

   ①［Description］　規則の名前と、対象にするオブジェクトの種類・結合方法を指定する画面です。ユーザー向けの受信規則では、次の値を指定します。

   設定項目	指定する値
   規則の名前	任意。オブジェクトの種類が判別できる名前にする
   コネクタ	ADコネクタ（フォレスト）
   Connected System Object Type	user
   Metaverse Object Type	person
   Link Type	Join
   Precedence	100未満で、他の規則と重複しない値

   Precedence は数値が小さいほど優先されます。既定の同期規則と衝突しないよう、100未満の値を規則ごとに重複しないように指定します。

   

   ②［Scoping filter］　この規則を適用する対象を絞り込む画面です。dn が対象OUの識別名（DN）で終わるオブジェクトに限定します。

   

   ③［Join rules］　AD側のオブジェクトを、メタバース上の既存オブジェクトとどう突き合わせるかの条件を指定する画面です。ここでは既定の結合を使うため、設定せずに次へ進みます。（補足：メタバースとは、Entra ConnectがオンプレADとクラウドの間に持つ中間データベースのことです。）

   

   ④［Transformations］　どの属性にどんな値を流すかを定義する画面です。ここで目印になる cloudNoFlow に、定数で True を流します。この画面の設定が受信規則の本体です。

   

   2本目：送信規則　続けて、目印が付いたオブジェクトのエクスポートを止める規則を作成します。

   ⚠ 先にエディター上部の「Direction」を Outbound に変更してください
   「Add new rule」は、上部フィルターで選ばれている方向を引き継いで開きます。Inbound のまま押すと受信規則の作成画面が開き、そのまま入力すると意図と逆向きの規則ができてしまいます。ウィザードのタイトルが Create outbound synchronization rule になっていることを確認してから進めてください。このフィルターは絞り込み用と説明しましたが、方向だけは新規作成にも影響します。

   

   ①［Description］　受信規則と同じ画面です。コネクタにEntra ID コネクタを選び、Connected System Object Type と Metaverse Object Type は受信規則と揃えたうえで、Link Type に JoinNoFlow を指定します。Precedence も100未満で、受信規則と重複しない値にします。

   

   ②［Scoping filter］　受信規則が立てた目印を条件にします。cloudNoFlow が True のオブジェクトが対象です。

   

   ③［Join rules］　受信規則と同じく突き合わせ条件の画面です。ここでも設定せずに次へ進みます。

   

   ④［Transformations］　受信規則とは異なり、送信規則側では変換を設定しません。何も追加せず「Add」で保存します。属性を流さないことがこの規則の目的なので、変換は空で正解です。

   

5. オンプレサーバーにプロビジョニングエージェントをインストールします。インストーラーはMicrosoft Entra管理センターの「クラウド同期」→「エージェント」から入手でき、実行後のウィザードでgMSA（グループ管理サービス アカウント）とドメインへの接続を設定します。
6. エージェントが正しく動作しているかを2か所で確認します。ここを飛ばすと、以降の同期が動かない原因の切り分けが難しくなります。
   • 管理センター側：「クラウド同期」→「エージェント」に対象サーバーが表示され、状態が「アクティブ」になっていること。
   • サーバー側：services.msc で「Microsoft Azure AD Connect Agent Updater」と「Microsoft Azure AD Connect プロビジョニング エージェント」の2つが「実行中」であること。
7. Microsoft Entra管理センターでCloud Syncの構成を新規作成し、スコープ フィルターで対象OUのみを同期対象に指定します。（補足：スコープとは同期対象の範囲設定のことです。ここを絞ることで検証範囲を限定できます。）

   ⚠ 保存しただけでは同期は始まりません
   スコープ フィルターを保存した時点では、構成の状態は「無効」のままです。「概要」を開き、「構成を有効にする」を実行してください。設定内容は正しく保存されているため画面上は完成して見えますが、この操作を行うまでEntra ID側には何も現れません。原因に気づきにくい箇所です。

   

8. 対象ユーザーが正しくプロビジョニングされたかを確認します。件数が手順2で把握した数と一致していれば正常です。
9. 確認が完了したら、停止していたEntra Connectのスケジューラを再開します。停止時とは逆に、有効化してから開始する順序になります。
   PowerShell ： スケジューラを再開する

   # スケジュール実行を有効に戻す
   Set-ADSyncScheduler -SyncCycleEnabled $true
   
   # 同期サイクルを開始する
   Start-ADSyncSyncCycle

「オブジェクトのプロビジョニング」画面で、ユーザーのインポート／スコープ内かどうかの確認／ソース システムとターゲット システム間での照合／アクションの実行の4工程すべてに緑のチェックが付けば、対象ユーザーが正しく同期されたことを意味します。

2-3. ステップ3：段階移行と最終切り替え（カットオーバー）

パイロットで問題がないことを確認できたら、対象範囲を拡大していきます。

1. 残りのユーザー・グループ・連絡先について、OU単位などのバッチに分割した移行計画を策定します。
2. 各バッチに対して、パイロットと同じ手順を適用します。移行が完了するまでは、Entra Connectのスコープからは外さず、No-Flow規則を適用した状態で維持します。

バッチ移行の実例：TEST_OU（2巡目）の5工程

2巡目のバッチとして TEST_OU を移行した例で、実際の流れを示します。パイロットで扱った TEST_OU_CS はユーザーだけの単一OUでしたが、TEST_OU にはユーザーに加えてグループ（test_groupGlobalSec ほか）と連絡先（test contact）が含まれます。スケジューラを停止してから規則を編集する流れはパイロットと変わりません。以下は、そこから先の5工程です。

• 工程①　No-Flow規則（受信・送信）を作成する
  2-2節と同じ手順で、TEST_OU向けの受信規則（dn がTEST_OUの識別名で終わるユーザーに cloudNoFlow=True を立てる規則）と、対になる送信規則を作成しました。送信規則で指定した値は次のとおりです。画面つきの操作は2-2節で説明済みのため、ここでは値のみを示します。
  • Direction：Outbound／Connected System：Entra ID コネクタ／Link Type：JoinNoFlow
  • スコープ フィルター：cloudNoFlow EQUAL True
  • 変換（Transformations）：何も追加せず「Add」で保存
• 工程②　オブジェクトの種類ごとに規則を追加する
  ここで、2-2節の注意書き（規則はユーザー・グループ・連絡先といったオブジェクトの種類ごとに必要）が実際に効いてきます。TEST_OUはユーザー以外のオブジェクトを含むため、パイロットと同じ2本では足りません。

  ⚠ ユーザー用の2本だけで次の工程へ進まないこと
  No-Flow規則はオブジェクトの種類ごとに評価されます。ユーザー用の受信・送信2本しかない状態では、グループ test_groupGlobalSec と連絡先 test contact に cloudNoFlow の目印が立たず、送信規則の対象にもなりません。その結果、グループと連絡先はEntra Connectが同期し続けます。一方でCloud Sync側はOU単位でスコープを見るため、同じオブジェクトを両方のツールが扱う状態（第3章の注意①）に近づきます。
  グループと連絡先についても、受信・送信を1組ずつ追加してください。TEST_OUのように3種類が混在するバッチでは、規則は合計6本になります。

  自分のバッチに含まれる種類の行だけを見て、受信・送信の2本が揃っているかをご確認ください。

  オブジェクトの種類	受信規則（cloudNoFlow）	送信規則（JoinNoFlow）	状態
  ユーザー	In from AD - User cloudNoFlow	Out to AAD - User JoinNoFlow	作成済み
  グループ （test_groupGlobalSec）	In from AD - Group cloudNoFlow	Out to AAD - Group JoinNoFlow	追加で作成が必要
  連絡先 （test contact）	In from AD - Contact cloudNoFlow	Out to AAD - Contact JoinNoFlow	追加で作成が必要

  規則名は任意ですが、種類が判別できる名前にしておくと、本数が増えたときの管理が楽になります。設定値は種類が変わっても同じで、受信規則のスコープを対象OUの 識別名（DN）、送信規則のスコープを cloudNoFlow EQUAL True にします。

• 工程③　プロビジョニングエージェントの導入と稼働確認
  TEST_OU_CSの検証で導入と稼働確認まで終えている場合、この工程は不要です。エージェントは同じADフォレストを対象とするかぎり複数のOU・複数の構成で共用できるため、バッチごとに追加インストールする必要はありません。2巡目では新規導入を行わず、管理センターで状態が「アクティブ」であること、サーバー側で2つのサービスが「実行中」であることの確認だけを行いました。
• 工程④　Cloud Syncの構成にTEST_OUをスコープ追加する
  構成を新しく作るのではなく、パイロットで作成した既存の構成（現在 TEST_OU_CS を指定中）に、TEST_OUの識別名（DN）をスコープ フィルターとして追加します。保存したあとは、構成ページの「Restart sync」（同期の再開）を実行してください。スコープの変更は差分同期では反映されないことがあるためです。

  混同しやすい点：ここでいう「同期の再開」はCloud Sync側の操作で、このあとの「スケジューラを再開する」で行うEntra Connect側の操作とは別物です。名前は似ていますが、対象のツールも操作する場所も異なります。

  • 同期の再開（Restart sync）：Cloud Syncの操作。Microsoft Entra管理センターの構成ページで実行し、変更したスコープを反映。
  • スケジューラの再開：Entra Connectの操作。オンプレサーバーでPowerShellから実行し、停止していた定期同期を元に戻す。
• 工程⑤　スケジューラを再開する
  最後に、Entra Connect側で最初に停止していたスケジューラを再開します。コマンドはパイロットと同じです。
  PowerShell ： スケジューラを再開する

  # スケジュール実行を有効に戻す
  Set-ADSyncScheduler -SyncCycleEnabled $true
  
  # 同期サイクルを開始する
  Start-ADSyncSyncCycle

以降のバッチも、この5工程の繰り返しになります。作業量が増えるのは、そのバッチに新しい種類のオブジェクトが登場したときだけです。規則が揃っていれば、あとはスコープの追加と再開の操作で進みます。

3. 全対象オブジェクトがCloud Syncでプロビジョニングされ、グループメンバーシップやマネージャー属性などの参照関係が維持されていることを確認します。
4. 問題がなければ、カットオーバーとして対象スコープのEntra Connectによる同期を停止します。ここでの「停止」は、2-2で挙げたスケジューラの停止（Set-ADSyncScheduler -SyncCycleEnabled $false）か、ステージングモードへの切り替えを指します。切り戻しに備えるならステージングモードのほうが安全です（Microsoftの移行ガイドは「同期を停止する」とのみ記載しており、手段は指定していません）。
5. Microsoftは、項番4で止めた状態を解除せずに一定期間そのまま維持することを推奨しています。サーバー自体はまだ残したままです。移行が成功したと確認できてから、Entra Connectをアンインストールしてサーバーを撤去します。

3. 移行時に気をつけたいポイント

ここでは、実務上つまずきやすい点を整理します。特に最初の2項目は必ず遵守すべき重要事項です。

そのほか、次の点も事前に押さえておくべきポイントです。

• 構成のバックアップは必須：
  移行前に必ず現行構成をエクスポートし、ロールバック可能な状態を確保します。
• 本番同期の前に検証を挟む：
  構成変更後は、オンデマンドプロビジョニングで単一ユーザーの動作を確認してから、運用同期へ進みます。
• スケール上限の事前確認：
  上限（ドメインあたり150,000オブジェクト、グループ50,000メンバー）を超える環境では、ドメインまたはOU単位でのセグメント化移行が可能かを検討します。
• デバイス同期方式の整理：
  Microsoft Entra ハイブリッド参加を利用している場合は、Cloud Kerberos Trustなど代替方式への切り替えが可能かを先に確認します。
• 認証機能は同期ツールとは別管理：
  Pass-Through認証（PTA）やシームレスSSOは同期ツールとは独立して構成されているため、移行後もそのまま動作を継続します。一方、ADFSの統合セットアップはCloud Syncでは別途対応が必要です。（補足：PTAはオンプレADに認証を委任する方式、シームレスSSOは社内PCからのサインインを自動化する機能です。いずれも同期の切り替えとは無関係に動作します。）
• 移行対象通知と例外申請：
  Microsoftから移行対象としての通知を受けた場合、推奨期間内に移行できないときは例外申請が必要です。承認されれば、Microsoftサポート等と連携しつつ既存構成を継続利用できます。
• スケジュールに余裕を確保する：
  所要期間は、対象オブジェクト数、カスタム同期規則の量、対象OU数といった環境の複雑さに依存します。

4. よくある疑問（FAQ）

移行作業を進めるうえで、現場でよく挙がる疑問にお答えします。

• Q. Entra ConnectとCloud Syncを並行して運用できますか？
  A. 同一オブジェクトに対する並行運用はサポートされていません。ただしOU単位でスコープを分けることで、各OUを一方のツールのみが管理する形の共存は可能です。これが段階移行の前提となります。
• Q. 途中で中止して元に戻せますか？
  A. 移行中はEntra Connectをステージングモードにでき、必要に応じて以前の構成へロールバックできます。ただしこれは事前のバックアップが前提となるため、構成のエクスポートは必ず実施してください。
• Q. 現在の構成はそのまま引き継がれますか？
  A. 自動では引き継がれません。Cloud Syncの構成はEntra ID側で新たに作成するため、スコープ フィルターや属性マッピングは設定し直す必要があります。とくにカスタム同期規則はCloud Syncに同等の機能がなく、式ビルダーで代替できるかを個別に確認することになります。設定後は最初の運用同期に進む前に、必ずオンデマンドプロビジョニングで期待どおり動作するかを検証してください。
• Q. 移行作業を自動化してくれるツールはありますか？
  A. 2026年9月16日リリースのEntra Connect v2.6.91.0で、Cloud Syncへのガイド付き移行ワークフローが追加されました。公式のリリースノートでは、構成の評価、プロビジョニングエージェントのセットアップ、段階的な有効化、検証を含むとされています（Azureパブリッククラウドのみ）。
  ただし2026年9月時点では専用の公式ドキュメントが公開されておらず、対応できる構成の範囲は明示されていません。本記事が扱うのは手動での移行手順です。ワークフローが表示されない場合や、対応しない構成では、引き続きこの手順で進めることになります。まずはお使いのEntra Connectのバージョンをご確認ください。

5. まとめ

6. 参考リンク（Microsoft公式ドキュメント）

• Microsoft Entra Connect を Microsoft Entra クラウド同期に移行する
• チュートリアル：同期されたActive DirectoryフォレストのMicrosoft Entra Cloud Syncに移行する
• Microsoft Entra Connect からクラウド同期への移行：意思決定ガイド
• Microsoft Entra Connect Sync から Cloud Sync への移行に関する FAQ
• Microsoft Entra クラウド同期の前提条件
• Microsoft Entra プロビジョニング エージェントをインストールする
• Active Directory を Microsoft Entra ID にプロビジョニングする - 構成
• Microsoft Entra Cloud Sync でのオンデマンド プロビジョニング
• Microsoft Entra Connect 構成設定をインポートおよびエクスポートする
• Microsoft Entra Connect：ステージング サーバーとディザスター リカバリー
• Microsoft Entra Connect をアップグレードする
• Microsoft Entra Connect：バージョンのリリース履歴

弊社では、ID管理に関する他の記事も公開しています。
ご興味のある方は、ぜひこちらもあわせてご覧ください！

ID管理 ブログ一覧 | QES ブログ
QESのエンジニアが ID管理 の情報を発信中！
 

※このブログで参照されている、Microsoft、Microsoft Entra、Microsoft Entra ID、Microsoft Entra ID Governance、Microsoft Entra Connect Sync、Microsoft Entra Cloud Sync、Active Directory、Azure、Azure Active Directory、Windows、Windows Server、PowerShell、Microsoft 365、Teamsは、米国Microsoft Corporationの米国およびその他の国における商標または登録商標です。

×