Microsoft Entra Cloud Syncで既存クラウドユーザーとオンプレADユーザーをマージする手順と注意点

Microsoft Entra Cloud Sync で既存のクラウドユーザーとオンプレミス Active Directory ユーザーをマージしたいのに、「結合条件がない」とエラーになって戸惑う――そんなケースは少なくありません。本記事では、ソフトマッチ／ハードマッチの仕組みから Cloud Sync での具体的な設定手順、移行時の落とし穴まで、実運用目線で詳しく解説します。

シナリオ整理：Cloud Sync で「既存クラウドユーザー」と「オンプレADユーザー」を統合したい

よくあるのは次のような状況です。

すでに Microsoft 365／Entra ID 上に クラウド専用ユーザー が存在している（メールも使っている）。
後からオンプレミス AD を整備し、同じユーザーを AD 上にも作成した。
Entra Cloud Sync で AD → Entra ID の同期構成を作ると、
「既存ユーザーと結合できない」「結合条件（Join 条件）がない」といったメッセージが出てマージされない。

Azure AD Connect（従来の Microsoft Entra Connect Sync）では Synchronization Rules Editor の Join ルールを意識すればよかったのに、Cloud Sync にはそれらしい画面がありません。この違いを理解するには、まず Entra ID 側で行われる ソフトマッチ／ハードマッチ のしくみから押さえる必要があります。

Cloud Sync でも変わらない「マッチング」の基本概念

Entra ID では、オンプレ AD から新しいオブジェクトが来たとき、クラウド側に既にあるオブジェクトと結びつけるかどうかを内部的に判定します。この判定ロジックは、Connect Sync と Cloud Sync で共通です。

ソフトマッチ（UPN／SMTP マッチ）

ソフトマッチとは、次の属性をキーに On-prem → Cloud を突き合わせる方法です。

userPrincipalName（UPN）
proxyAddresses のうちプライマリ SMTP（SMTP: で始まる値）

新しいオンプレユーザーが同期されてきたとき、Entra ID は次の順序でマッチを試みます。

まず ハードマッチ（後述）を試す。
うまくいかなければ、UPN やプライマリ SMTP によるソフトマッチを試す。
どちらもヒットしなければ、新しいクラウドユーザーとして 新規プロビジョニングされる。

つまり Cloud Sync で「既存クラウドユーザーとマージしたい」のであれば、同じ UPN か同じプライマリ SMTP を持つように属性を揃えることでソフトマッチを狙うのが基本戦略になります。

ハードマッチ（ImmutableId／ms-DS-ConsistencyGuid）

ハードマッチは、オンプレ AD オブジェクトの sourceAnchor（通常は ms-DS-ConsistencyGuid または objectGUID）と、クラウドオブジェクトの ImmutableId（OnPremisesImmutableId） を用いて 1:1 で強制的に結びつける方法です。

デフォルトでは次のような対応になります。

オンプレ AD 側：ms-DS-ConsistencyGuid（設定されていない場合は objectGUID）
Entra ID 側：OnPremisesImmutableId（Base64 文字列）

この Base64 文字列が一致すると「同じ人物」と強制的にみなされ、クラウド側オブジェクトの 管理主体（Source of Authority）がオンプレ AD に切り替わる、というのがハードマッチです。

管理者ロール付きユーザーはソフトマッチ不可

セキュリティ保護のため、Entra ID は グローバル管理者などの管理者ロールが付与されたクラウドユーザーに対してソフトマッチを行いません。

このようなユーザーをオンプレ AD と統合したい場合は、次のいずれかの方法になります。

一時的にクラウドユーザーからディレクトリロールを外し、ソフトマッチを許可する。
ロールはそのままにし、ハードマッチ（ImmutableId／ms-DS-ConsistencyGuid）で結合する。

後述の通り、Microsoft は管理者アカウントをオンプレ AD と同期させること自体をあまり推奨していません。設計段階で「クラウド専用のブレークグラスアカウント」を残すことを強くおすすめします。

Azure AD Connect と Cloud Sync の違い（Join ルールが見えない理由）

「Azure AD Connect には Join ルールの画面があったのに、Cloud Sync には見当たらない」――これは設計思想の違いによるものです。

項目	Microsoft Entra Connect Sync（旧 Azure AD Connect）	Microsoft Entra Cloud Sync
同期エンジンの場所	オンプレミスサーバー上の同期サービス	クラウド側のプロビジョニングサービス＋軽量エージェント
Join 条件の設定方法	Synchronization Rules Editor で Join ルールを定義	Portal 上の「属性マッピング」で「Match objects using this attribute」＋「Matching precedence」を設定
主な利用シナリオ	フル機能・複雑なハイブリッド構成	シンプル／スケーラブルなユーザー・グループ同期
共通点	マッチングそのものは Entra ID サービス側で実行され、 UPN / proxyAddresses / sourceAnchor の 3 種類を使う点は共通

Cloud Sync 側には Synchronization Rules Editor 相当の UI はありません。その代わり、「属性マッピング」画面の各行で「この属性をマッチングに使うかどうか」「優先順位はいくつか」を指定します。アプリケーションプロビジョニングと同じ UI で、「Match objects using this attribute」「Matching precedence」というプロパティが並んでいる画面をイメージすると分かりやすいでしょう。

Cloud Sync で UPN を使ってマージする実践手順（ソフトマッチ）

ここからは、質問の多い「UPN をキーに既存クラウドユーザーとオンプレ AD ユーザーをマージする」具体的な手順を、Cloud Sync の画面ベースで解説します。

事前準備：クラウドとオンプレの属性を揃える

まずはソフトマッチが成立するように、属性の整合性をとります。代表的なパターンを表にまとめます。

パターン	マッチに使う属性	クラウド側（Entra ID）	オンプレ AD 側
UPN マッチ（推奨）	userPrincipalName	ユーザーのサインイン名（例：`[email protected]`）	ユーザーオブジェクトの `userPrincipalName` を同じ値に設定
SMTP マッチ	proxyAddresses のプライマリ SMTP	`proxyAddresses` に `SMTP:[email protected]` が設定されている	同じく `proxyAddresses` に `SMTP:[email protected]` を設定
UPN + SMTP 併用	UPN を優先、SMTP を第 2 候補	UPN と SMTP をどちらも正しく設定	同じく UPN と SMTP を一致させる

ポイントは次の 3 つです。

UPN を使う場合は 完全一致 させる（大文字・小文字は無視されますが、ドメイン部分などタイプミスがないよう注意）。
proxyAddresses を使う場合、
プライマリを大文字 SMTP:、エイリアスを小文字 smtp: で記述する。
クラウド側ユーザーの OnPremisesImmutableId が空 であることを確認する（既に別の AD オブジェクトと結びついているとソフトマッチに失敗します）。

Cloud Sync の属性マッピングで「一致に使用」を設定

属性が揃ったら、Cloud Sync 構成で どの属性をマッチングに使うか を指定します。手順は次の通りです。

管理者アカウントで Microsoft Entra 管理センターにサインイン。
Entra ID > Entra Connect > Cloud Sync を開き、対象の Cloud Sync 構成を選択。
左ペインの [Attribute mapping] をクリック。
画面上部のオブジェクト種別で [User] が選択されていることを確認。
一覧から Target attribute = userPrincipalName の行をクリックし、編集画面へ。
編集画面で次の項目を設定。
- [Match objects using this attribute] をオンにする。
- [Matching precedence] を 1 に設定（最優先でマッチ）。
- [Apply this mapping] は通常 [Always] のままで OK。
必要であれば、Target attribute = proxyAddresses の行も開き、
[Match objects using this attribute] をオン、[Matching precedence] を 2 に設定。
画面右上の [Save schema] をクリックして保存。

ここで設定した内容が、Azure AD Connect でいうところの「Join ルール」に相当します。Cloud Sync では 「対象属性をマッチングに使う」＋「優先順位」 を設定することで、既存オブジェクトとの結合条件を定義します。

Provision on demand で 1 ユーザー単位のテストを行う

いきなり本番同期を走らせるのは不安なので、Cloud Sync が持つ 「Provision on demand（オンデマンド・プロビジョニング）」機能で 1 ユーザーだけテストするのが安全です。

同じ Cloud Sync 構成で、左ペインから [Provision on demand] を選択。
Distinguished Name (DN) の入力ボックスに、テストしたいオンプレ AD ユーザーの DN（例：CN=User1,OU=Users,DC=contoso,DC=com）を入力。
[Provision] ボタンをクリック。
成功すると、4 つのステップに対して緑色のチェックマークが表示され、詳細には
- クラウド側の既存ユーザーが見つかったか
- どの属性でマッチしたか（UPN／SMTP）
- どの属性が更新されたか／されなかったか
が表示されます。

ここで 「新規ユーザーを作成」ではなく「既存ユーザーを更新」になっているか を必ず確認してください。新規ユーザーが作成されてしまう場合は、属性の整合や ImmutableId の状態をもう一度見直す必要があります。

ソフトマッチがうまくいかないときの原因と解決策

属性を揃えたのにマージしてくれない場合、代表的な原因は次の通りです。

症状・エラー	主な原因	対処方針
InvalidSoftMatch、AttributeValueMustBeUnique など	既存クラウドユーザーの ImmutableId が別オブジェクト由来で、オンプレ側の sourceAnchor と不一致	重複オブジェクトの整理、ImmutableId と ms-DS-ConsistencyGuid の整合を取り必要に応じてハードマッチに切り替え
管理者ロール付きユーザーだけマージされない	Entra ID が管理者ロール付きクラウドユーザーとのソフトマッチを拒否	一時的にロールを外すか、ハードマッチで結合する
そもそもソフトマッチが実行されない	テナント側で SoftMatch がブロックされている、または Cloud Sync 構成で「一致に使用」が設定されていない	テナント設定で SoftMatch ブロックを一時的に解除し、 Cloud Sync の属性マッピングでマッチング属性を設定

InvalidSoftMatch／AttributeValueMustBeUnique が出る場合

Microsoft 公式ドキュメントでは、次のようなケースで AttributeValueMustBeUnique や InvalidSoftMatch が発生すると説明されています。

クラウド側に既に存在するユーザーと UPN／SMTP が一致するが、
sourceAnchor（ImmutableId）が異なる別のオンプレユーザーが同期されてきた。
過去に別の AD オブジェクトで同期されていたアカウントを、別ユーザーの AD アカウントで再度ソフトマッチしようとしている。

この場合、Microsoft は 既存クラウドユーザーの ImmutableId とオンプレユーザーの ms-DS-ConsistencyGuid を一致させる（ハードマッチに持ち込む）ことを推奨しています。

管理者ロール付きクラウドユーザーがマージされない場合

前述の通り、Entra ID はセキュリティ上の理由から 管理者ロールが付与されたクラウドユーザーに対するソフトマッチをブロックします。公式ドキュメントでは回避策として、次の手順が記載されています。

クラウド専用ユーザーから一時的にディレクトリロールを削除する。
同期時に作成された重複オブジェクト（クォarantine オブジェクト）があれば削除する。
再度同期を実行し、マッチングを成立させる。
マッチング完了後、必要に応じてロールを再付与する。

とはいえ、Microsoft は「オンプレアカウントを既存の管理者アカウントと同期させることは推奨しない」とも明言しています。可能であれば、管理者アカウントはクラウド専用で別に用意し、一般ユーザーのみをオンプレ AD と連携する設計を検討しましょう。

テナント設定で SoftMatch／HardMatch がブロックされている場合

2025 年時点では、テナントレベルで ハードマッチ／ソフトマッチを一時的に無効化する設定が提供されています。

BlockCloudObjectTakeoverThroughHardMatchEnabled：ハードマッチによるクラウドオブジェクト乗っ取りをブロック
BlockSoftMatchEnabled：ソフトマッチによるクラウドオブジェクト乗っ取りをブロック

セキュリティ上は これらを有効（ブロック状態）にしておくのが推奨ですが、Cloud Sync で既存クラウドユーザーを取り込む場合は、必要な期間だけ一時的に解除 → マッチング作業 → 再度ブロックという運用が現実的です。

ただし設定変更には Graph PowerShell での管理者権限が必要になり、環境全体に影響するため、社内のセキュリティポリシーに従って慎重に実施してください。

ハードマッチで確実に結合する PowerShell 手順

ソフトマッチが使えない場合（管理者ロール付きユーザー／ImmutableId 競合など）は、ハードマッチで確実に結合します。ここでは Cloud Sync を前提にした 2 つの代表的なパターンを紹介します。

パターン1：オンプレ AD の GUID から ImmutableId を生成してクラウドユーザーに設定

これは、既存のオンプレ AD ユーザーに合わせてクラウドユーザーを取り込むパターンです。

オンプレ AD で対象ユーザーの objectGUID（または msDS-ConsistencyGuid）を取得。
GUID を Base64 文字列に変換（これが OnPremisesImmutableId）。
Microsoft Graph PowerShell でクラウドユーザーの OnPremisesImmutableId に設定。

サンプルスクリプトは次の通りです。

# On-prem AD モジュールと Microsoft.Graph モジュールを使用
Install-Module Microsoft.Graph -Scope CurrentUser

# Graph に接続（テナント管理者で実行）
Connect-MgGraph -Scopes "User.ReadWrite.All"

# 1) オンプレ AD ユーザーの GUID を取得して Base64 に変換
$AdSam    = "user1"                 # オンプレ AD の sAMAccountName
$CloudUpn = "[email protected]"    # 既存クラウドユーザーの UPN

$adUser = Get-ADUser $AdSam -Properties ObjectGuid
$guid   = $adUser.ObjectGuid
$immutableId = [Convert]::ToBase64String($guid.ToByteArray())

# 2) クラウドユーザーの OnPremisesImmutableId を設定（ハードマッチ）
Update-MgUser -UserId $CloudUpn -OnPremisesImmutableId $immutableId

注意点：

誤った GUID を設定すると 別人のクラウドユーザーと結合する危険があるため、GUID と UPN が本当に同一人物かを二重三重に確認してください。
ハードマッチ成功後は、クラウド側の属性がオンプレ側で上書きされます。メールエイリアスや表示名など、クラウドでしか管理していなかった情報は事前にオンプレに反映しておきましょう。
ハードマッチの悪用によるアカウント乗っ取り（Syncjacking）といった攻撃手法も報告されているため、作業アカウントの権限管理や監査ログの確認を忘れないでください。

パターン2：クラウド側 ImmutableId から ms-DS-ConsistencyGuid を設定して解決

公式ドキュメントでは、AttributeValueMustBeUnique などの競合を解決する方法として、既存クラウドユーザーの ImmutableId をもとにオンプレ AD の msDS-ConsistencyGuid を更新し、ハードマッチを成立させる手順が案内されています。

Graph PowerShell でクラウドユーザーの OnPremisesImmutableId を取得。
Base64 を GUID にデコード。
オンプレ AD の msDS-ConsistencyGuid 属性に書き込む。

イメージコードは次のようになります（実運用では十分な検証とバックアップを取ってから実行してください）。

# 1) クラウドユーザーの OnPremisesImmutableId を取得
$CloudUpn = "[email protected]"
$cloudUser = Get-MgUser -UserId $CloudUpn -Property OnPremisesImmutableId
$immutableId = $cloudUser.OnPremisesImmutableId

# 2) ImmutableId (Base64) を GUID に変換
$bytes = [Convert]::FromBase64String($immutableId)
$guid  = New-Object Guid ($bytes)

# 3) オンプレ AD ユーザーの msDS-ConsistencyGuid に設定
$AdSam = "user1"
Set-ADUser $AdSam -Replace @{ 'msDS-ConsistencyGuid' = $guid.ToByteArray() }

この方法ではオンプレ側の GUID をクラウドに合わせるため、「クラウドを真」として扱いたいときに適しています。一方で、AD 側の RID プールの問題などで GUID が重複しているような異常環境では別のトラブルを誘発する可能性もあるため、事前の AD 健全性チェックは必須です。

Azure AD Connect から Cloud Sync への移行時のポイント

既に Azure AD Connect（Entra Connect Sync）が稼働している環境で Cloud Sync に移行する場合、両方のツールが同じユーザーを同時に管理しないことが重要です。

やってはいけないこと	推奨される進め方
Connect Sync と Cloud Sync の両方で同じユーザー OU／グループを対象にする	パイロット用 OU／グループを作成し、その単位で「Connect Sync から Cloud Sync へ」スコープを切り替えていく
何も考えずに Connect Sync を停止して Cloud Sync のみ有効化	公式の移行ガイドに沿って、事前チェック → パイロット → スコープ拡大 → 最終的に Connect Sync を停止、の順に段階移行
ImmutableId／msDS-ConsistencyGuid を一括で書き換える	パイロット対象だけを丁寧に確認しながら変更し、 Cloud Sync の「Provision on demand」で都度テスト

特にハイブリッド Azure AD Join（オンプレ PC のハイブリッド参加）や Pass-through Authentication など、Cloud Sync がサポートしない機能を利用している場合は、Connect Sync を完全に置き換えられないケースもあります。この点は必ず最新のドキュメントで確認してください。

運用設計のベストプラクティスとチェックリスト

属性設計のベストプラクティス

UPN とメールアドレスのルールを明文化し、オンプレ AD と Entra ID で一貫性を持たせる。
proxyAddresses のプライマリ SMTP は常に正しいメールアドレスを設定し、
クラウド側でしか管理されていないアドレスがないようにする。
将来的なドメイン変更（contoso.local → contoso.com）も見据えて、
UPN と SMTP の関係を決めておく。
管理者アカウントは クラウド専用アカウント＋オンプレ連携アカウントを分離する（ブレークグラス）。

マージ作業前のチェックリスト

マージ対象ユーザーの一覧（UPN／メールアドレス／所属 OU）を棚卸ししたか。
各ユーザーで クラウド側 UPN とオンプレ側 UPN が一致しているか。
ImmutableId／msDS-ConsistencyGuid の値を確認し、競合がないかを確認したか。
Cloud Sync 構成の Attribute mapping で「Match objects using this attribute」が正しく設定されているか。
テナント設定で SoftMatch／HardMatch のブロックが不要に有効になっていないか。
本番前に Provision on demand で代表ユーザーをテストしたか。

セキュリティ観点での注意点

ハードマッチは便利な一方で、誤用すると 別人の AD アカウントを既存クラウドアカウントに紐づける危険があります。
ImmutableId／msDS-ConsistencyGuid を編集できるアカウントは、最小限の管理者に限定し、操作ログを必ず記録・監査しましょう。
マッチング作業中以外は、テナントの SoftMatch／HardMatch ブロック設定を有効に戻すことを忘れないでください。

まとめ：Cloud Sync でのユーザーマージ最短レシピ

最後に、本記事の要点を「最短レシピ」としてまとめます。

一般ユーザーは、まず UPN 一致のソフトマッチを狙う。
- オンプレ AD とクラウドの userPrincipalName／proxyAddresses を揃える。
- Cloud Sync の Attribute mapping で userPrincipalName を Matching precedence=1、proxyAddresses を 2 に設定。
- Provision on demand で 1 ユーザー単位のテストを行う。
管理者ロール付きユーザー／競合があるユーザーは、ハードマッチを計画する。
- オンプレ GUID → ImmutableId の方向で合わせるか、ImmutableId → msDS-ConsistencyGuid の方向で合わせるかを決める。
- Graph PowerShell と AD PowerShell を用いて、GUID と ImmutableId を 1:1 で結びつける。
- 作業中は SoftMatch／HardMatch ブロック設定も含め、セキュリティと監査を厳格にする。
Azure AD Connect から Cloud Sync への移行は、必ずパイロット → スコープ拡大 → 切り替えの順で進める。
- Connect Sync と Cloud Sync が同じユーザーを同時に管理しないよう、OU／グループでスコープを分離。
- Cloud Sync 側の属性マッピングとテスト機能（Provision on demand）を活用して、小さく試しながら移行する。

Cloud Sync には Azure AD Connect のような「Join ルール」画面はありませんが、属性マッピングの Matching 設定こそが実質的な Join 条件です。
UPN／SMTP／ImmutableId の関係を正しく理解し、小さなパイロットから検証を重ねれば、既存クラウドユーザーとオンプレ AD ユーザーのマージも安全に実現できます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Microsoft Entra Cloud Syncで既存クラウドユーザーとオンプレADユーザーをマージする手順と注意点

シナリオ整理：Cloud Sync で「既存クラウドユーザー」と「オンプレADユーザー」を統合したい