Microsoft Entra Connectを既存テナントに構成する更新ポイント｜hard match保護と管理者の確認事項

Microsoft Entra Connect を既存の Microsoft Entra テナントに導入する場合、最も重要なのは「既にクラウド上にあるユーザー」と「オンプレミス Active Directory のユーザー」が、どの条件で同一人物として照合されるかを理解することです。照合に成功すると、クラウド管理だったユーザーはオンプレミス管理に切り替わり、Microsoft Entra ID 側の属性がオンプレミス AD の値で上書きされる可能性があります。

2026年7月2日に更新された Microsoft Learn の「Configure Microsoft Entra Connect for an existing tenant」では、既存テナントでの soft match、hard match、属性競合、そして 2026年7月1日から適用される hard match の追加保護が整理されています。特に、特権ロールを持つクラウドアカウントや、すでに onPremisesObjectIdentifier が設定されているアカウントへの hard match はブロックされる可能性があるため、同期前の棚卸しと移行計画が欠かせません。(Microsoft Learn)

Microsoft Entra Connect を既存テナントに構成するとは何か

Microsoft Entra Connect は、オンプレミス Active Directory のユーザー、グループ、連絡先などを Microsoft Entra ID に同期するための仕組みです。多くの導入ガイドは「新しい Microsoft Entra テナントに、オンプレミス AD の情報を初めて同期する」前提で説明されています。

一方で、実務では次のようなケースがよくあります。

よくある状況	何が問題になりやすいか
先に Microsoft 365 を導入し、クラウド上にユーザーを作成済み	後からオンプレミス AD を同期すると、既存クラウドユーザーと AD ユーザーの照合が必要になる
一部の部門だけクラウド管理、一部は AD 管理	ユーザーごとに「どちらが管理元か」が混在し、属性更新の流れを誤解しやすい
既存の管理者アカウントをオンプレミス AD と同期したい	特権アカウントの乗っ取りリスクがあるため、Microsoft は既存の管理者アカウントとの同期を強く推奨していない
M&A、AD 再構築、フォレスト移行がある	sourceAnchor や ImmutableId の不一致により hard match 競合が発生しやすい

この更新情報の本質は、「既存テナントへの同期は、単なるセットアップ作業ではなく、ID の管理元を切り替える作業である」という点です。

既存ユーザーとの同期で起きる soft match と hard match

Microsoft Entra Connect がオンプレミス AD から新しいオブジェクトを同期しようとすると、Microsoft Entra ID 側では既存オブジェクトと同一かどうかを確認します。公式ドキュメントでは、この照合に userPrincipalName、proxyAddresses、sourceAnchor/immutableID が使われると説明されています。userPrincipalName または proxyAddresses による照合は soft match、sourceAnchor による照合は hard match と呼ばれます。(Microsoft Learn)

soft match は UPN とプライマリ SMTP アドレスで照合する

soft match は、主に次の属性を使って既存のクラウドユーザーとオンプレミス AD ユーザーを結び付けます。

照合に使われる属性	実務での確認ポイント
userPrincipalName	サインイン ID として使われることが多いため、クラウドと AD で一致しているか確認する
proxyAddresses	SMTP: で指定されたプライマリメールアドレスが評価対象になるため、重複や古い値に注意する

例えば、Microsoft 365 側に [email protected] のクラウドユーザーが存在し、オンプレミス AD にも同じ UPN またはプライマリ SMTP アドレスを持つユーザーがある場合、soft match によって同一ユーザーとして扱われる可能性があります。

ただし、soft match は「新しく入ってくるオンプレミス AD オブジェクト」に対して評価されます。既存オブジェクトの属性を後から合わせれば自動的に安全に結合される、という単純な仕組みではありません。属性が重複している場合は、照合ではなく同期エラーとして表面化することがあります。

hard match は sourceAnchor と ImmutableId で照合する

hard match は、オンプレミス AD オブジェクトの sourceAnchor と、Microsoft Entra ID 側の ImmutableId に相当する値を使って照合します。既定では、sourceAnchor は mS-DS-ConsistencyGuid、または構成によっては ObjectGUID をもとにした Base64 文字列として扱われます。(Microsoft Learn)

hard match は、正しく使えば AD 再構築やフォレスト移行後のオブジェクト再関連付けに役立ちます。しかし、誤った AD オブジェクトがクラウド上の別ユーザーを「引き継ぐ」と、ソースオブオーソリティが意図せず切り替わり、権限や属性が不正な状態になるリスクがあります。

2026年7月更新で特に重要な変更点

今回の更新で管理者が最初に確認すべきポイントは、hard match に対するセキュリティ保護の強化です。Microsoft Entra ID では、2026年7月1日から hard match 操作に追加保護が適用され、危険な再関連付けを防ぐためのチェックがクラウド側で行われます。これは Microsoft Entra Connect Sync と Microsoft Entra Cloud Sync の両方に適用され、クライアントのバージョンに依存しない cloud-side enforcement として説明されています。(Microsoft Learn)

確認項目	変更・注意点	管理者が取るべき対応
hard match の対象	特権ロールを持つクラウドユーザー、特権ロールに eligible なユーザー、onPremisesObjectIdentifier 設定済みユーザーはブロック対象になり得る	対象アカウントを同期前に棚卸しし、意図した関連付けか確認する
soft match	soft match の挙動自体は別設定で管理される	BlockSoftMatchEnabled の状態を確認し、必要な期間だけ許可する
属性上書き	照合に成功すると、クラウド側の属性がオンプレミス AD の値で上書きされる	AD 側のメール、表示名、電話番号、部署などを同期前に整備する
パスワードハッシュ同期	Express インストールでは password hash sync が有効になり、クラウド側のパスワードハッシュが AD 側で上書きされる	ユーザーにサインイン時のパスワード変更影響を周知する
管理者アカウント	既存の Microsoft Entra 管理者アカウントとオンプレミスアカウントの同期は推奨されない	break-glass 管理者やクラウド専用管理者は同期対象から分離する

ここで重要なのは、「hard match が廃止された」わけではないことです。安全な初回 hard match や、すでに正しく関連付けられているユーザーの継続同期は影響を受けません。一方で、特権アカウントや既存マッピング済みアカウントを強引に再関連付けする運用は、今後より明確にブロックされます。

影響を受けやすい環境

すべての Microsoft Entra テナントが同じ深刻度で影響を受けるわけではありません。特に注意すべきなのは、既存クラウドユーザーが多い状態で後から Microsoft Entra Connect を導入する組織です。

Microsoft 365 を先に使い始めた組織

先に Exchange Online、Teams、SharePoint Online などを使い始め、クラウド上でユーザーやメールアドレスを管理していた組織では、オンプレミス AD 側の属性が古いままになっていることがあります。

例えば、クラウド側では次のように最新化されているとします。

属性	Microsoft Entra ID 側
表示名	山田 太郎
メール	[email protected]
部署	営業企画部
電話番号	03-xxxx-xxxx

一方、オンプレミス AD 側が次の状態だった場合、同期後に古い値で上書きされる可能性があります。

属性	オンプレミス AD 側
表示名	Yamada Taro
メール	[email protected]
部署	営業部
電話番号	未設定

この状態で Microsoft Entra Connect を構成すると、「同期できた」ように見えても、実際には Microsoft 365 のアドレス帳、Teams のユーザープロファイル、Exchange Online のメール属性に影響が出ることがあります。

特権ロールを持つクラウドアカウントがある環境

Global Administrator、Privileged Role Administrator、Exchange Administrator などの特権ロールを持つクラウドアカウントをオンプレミス AD と結び付けようとする運用は危険です。2026年7月1日以降の hard match セキュリティ強化では、特権ロールが割り当てられている、または eligible なクラウドユーザーへの hard match がブロックされる可能性があります。(Microsoft Learn)

実務では、管理者アカウントを次のように分けるのが安全です。

アカウント種別	推奨される考え方
日常業務ユーザー	必要に応じてオンプレミス AD と同期する
管理者アカウント	原則としてクラウド専用または専用管理アカウントとして分離する
break-glass アカウント	同期対象に含めず、MFA 障害時などの緊急用途として厳格に管理する
移行用の一時管理者	移行完了後に権限を削除し、残存しないようにする

AD 再構築、フォレスト移行、M&A がある環境

AD ユーザーを再作成したり、別フォレストへ移動したりすると、同じ人物であっても sourceAnchor が変わることがあります。Microsoft Entra ID 側では、以前の ImmutableId と新しい AD オブジェクトの sourceAnchor が一致しないため、InvalidSoftMatch や AttributeValueMustBeUnique といったエラーにつながります。

この場合、単に UPN やメールアドレスを合わせるだけでは不十分です。どのオンプレミス AD オブジェクトを正しい管理元にするのか、mS-DS-ConsistencyGuid や onPremisesImmutableId の対応関係を確認したうえで修復する必要があります。

hard match がブロックされた場合の代表的な原因と対応

Microsoft Learn の同期エラー解説では、2026年7月1日から hard match security hardening が自動的に適用され、特権ロール、既存の onPremisesObjectIdentifier、テナント側の hard match ブロック設定などが原因で InvalidHardMatch や AttributeUpdateNotAllowed が発生する場合があると説明されています。(Microsoft Learn)

発生しやすい状況	表面化するエラー例	対応の考え方
クラウドユーザーに特権ロールが割り当てられている	InvalidHardMatch	意図した関連付けであることを確認し、必要な場合のみ一時的にロールを外して同期後に戻す
PIM などで特権ロールに eligible になっている	InvalidHardMatch	eligibility を一時的に外し、同期完了後に復元する
クラウドユーザーが soft-deleted 状態かつ特権を持つ	InvalidHardMatch	必要に応じてユーザーを復元してから、特権ロール関連の修復を行う
onPremisesObjectIdentifier がすでに設定されている	AttributeUpdateNotAllowed	意図したマッピングを確認し、必要な場合のみ null にクリアして再同期する
hard match のブロック設定が有効	InvalidHardMatch	意図的な takeover が必要な期間だけ設定を見直し、作業後に再度ブロックする

最も避けるべきなのは、エラーを消すことだけを目的に hard match を繰り返す運用です。hard match は「同一人物であることが確認済みのクラウドユーザーと AD ユーザーを関連付ける」ための手段であり、特権アカウントや既に別 AD オブジェクトへ関連付いているアカウントの一般的な修復手段として使うべきではありません。

hard match と soft match のブロック設定をどう扱うべきか

Microsoft Entra ID には、hard match や soft match によるクラウドオブジェクトの takeover をブロックするためのテナントレベル設定があります。公式ドキュメントでは、hard matching や soft matching を無効化する構成オプションとして、Microsoft Graph PowerShell の Update-MgDirectoryOnPremiseSynchronization を使う例が示されています。(Microsoft Learn)

通常運用では、不要な takeover を防ぐため、ブロック設定を有効にしておくのが安全です。一方、既存クラウドユーザーを計画的にオンプレミス AD へ引き継ぐ移行期間だけ、一時的に許可する判断もあります。

Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"

$OnPremSync = Get-MgDirectoryOnPremiseSynchronization

$OnPremSync.Features.BlockCloudObjectTakeoverThroughHardMatchEnabled = $true
$OnPremSync.Features.BlockSoftMatchEnabled = $true

Update-MgDirectoryOnPremiseSynchronization `
  -OnPremisesDirectorySynchronizationId $OnPremSync.Id `
  -Features $OnPremSync.Features

設定判断は、次のように考えると実務で迷いにくくなります。

状況	推奨される判断
新規ユーザーだけを同期する	hard match / soft match による takeover は不要なため、ブロックを有効にする
既存クラウドユーザーを AD 管理へ移す	対象ユーザーを限定し、検証期間だけ必要な照合を許可する
特権アカウントを含む	原則として同期対象から外す。やむを得ない場合はロール、eligibility、対象オブジェクトを個別に確認する
M&A やフォレスト移行	sourceAnchor と onPremisesImmutableId の対応を確認し、作業ログを残して段階的に実施する
作業完了後	takeover を許可したままにせず、ブロック設定を再度有効化する

同期前に確認すべき属性

既存テナントで Microsoft Entra Connect を構成する前に、最低限確認すべき属性があります。ここを省略すると、照合エラーだけでなく、同期後のユーザー体験にも影響します。

確認対象	確認内容	失敗すると起きること
userPrincipalName	Microsoft Entra ID と AD で同一ユーザーの値が一致しているか	soft match 失敗、別ユーザー作成、サインイン混乱
proxyAddresses	プライマリ SMTP が正しいか、重複がないか	メールアドレス競合、InvalidSoftMatch、AttributeValueMustBeUnique
mail	Microsoft 365 側の実利用メールと矛盾しないか	アドレス帳やメール関連属性の不整合
mS-DS-ConsistencyGuid	sourceAnchor として使う値が適切か	hard match 失敗、再関連付けミス
onPremisesObjectIdentifier	既存クラウドユーザーにすでに設定されていないか	hard match ブロック、AttributeUpdateNotAllowed
管理者ロール	特権ロールまたは PIM eligibility がないか	hard match ブロック
同期スコープ	対象 OU、グループ、ドメインが正しいか	意図しないユーザー同期、削除、参照切れ
パスワード同期方式	Password Hash Sync、Pass-through Authentication、AD FS のどれか	サインイン影響、ユーザー周知漏れ

特に proxyAddresses は、ユーザーだけでなく、メール有効グループや連絡先とも重複することがあります。人間の目では「ユーザー同士の重複」だけを探しがちですが、実際にはグループ、共有メールボックス、連絡先も含めて確認する必要があります。

AttributeValueMustBeUnique や InvalidSoftMatch の直し方

同期エラーでよく見るのが、AttributeValueMustBeUnique と InvalidSoftMatch です。どちらも「同じ人物のはずなのに結び付かない」または「別オブジェクトなのに同じ属性値を持っている」場合に発生しやすいエラーです。

Microsoft Entra ID では、proxyAddresses、userPrincipalName、onPremisesSecurityIdentifier、objectId、immutableId など、重複できない属性があります。同期エラーのトラブルシューティングでは、まず重複属性と関係するオブジェクトを特定し、どちらが正しい値を持つべきかを判断してから修正します。(Microsoft Learn)

エラー	よくある原因	修正手順
InvalidSoftMatch	UPN または proxyAddresses は一致するが、既存オブジェクトに別の ImmutableId がある	重複している属性を特定し、正しいオブジェクトだけに残す
AttributeValueMustBeUnique	同じメールアドレスや UPN が複数オブジェクトに存在する	不要な重複値を削除し、オンプレミス AD またはクラウド側の管理元で修正する
ObjectTypeMismatch	ユーザー、グループ、連絡先など異なる種類のオブジェクトで同じ proxyAddresses を持つ	メールアドレスを使うべきオブジェクトを決め、他方から削除する
InvalidHardMatch	hard match 対象が特権アカウント、既存マッピング済み、またはブロック設定対象	特権ロール、onPremisesObjectIdentifier、ブロック設定を確認する

修正時のポイントは、Microsoft Entra ID 側だけを見ないことです。オンプレミス AD が管理元になっている属性は、AD 側で直さなければ次回同期で再び上書きされます。逆に、クラウド専用オブジェクトの属性をオンプレミス側の都合だけで消すと、Microsoft 365 側の運用に影響することがあります。

onPremisesObjectIdentifier をクリアする場合の注意点

hard match が onPremisesObjectIdentifier によってブロックされる場合、Microsoft Graph または ADSyncTools を使って値を null にクリアする回復パスが公式ドキュメントで示されています。ただし、これは「正しいオンプレミス AD オブジェクトへ関連付け直す」ことが確認できている場合に限るべきです。(Microsoft Learn)

重要なのは、onPremisesObjectIdentifier を別の任意値に書き換えるのではなく、null にクリアする点です。クリア後、再同期が成功すると新しい値がスタンプされます。また、この操作には Microsoft Graph の権限や、Global Administrator または Hybrid Identity Administrator ロールが必要になる場合があります。

実務では、次の順序で進めると安全です。

手順	作業内容
事前確認	クラウドユーザーと AD ユーザーが本当に同一人物か確認する
バックアップ	現在の onPremisesObjectIdentifier、onPremisesImmutableId、UPN、proxyAddresses を記録する
特権確認	管理者ロールや PIM eligibility がないか確認する
クリア	必要な場合のみ onPremisesObjectIdentifier を null にする
再同期	Microsoft Entra Connect または Cloud Sync で同期を再実行する
検証	対象ユーザーが意図した AD オブジェクトに関連付いたか確認する
復元	一時的に外したロールや eligibility を必要に応じて戻す

この作業は、広範囲に一括実行するのではなく、まず少数ユーザーで検証するべきです。特に役員、管理者、共有アカウント、アプリケーション所有者のアカウントは、誤った再関連付けによる影響が大きくなります。

Microsoft Entra Connect のバージョンと移行期限

今回の「既存テナントへの Microsoft Entra Connect 構成」ドキュメント自体は、全テナント共通の Cloud Sync 移行期限を示すものではありません。ただし、関連する公式情報として、Microsoft Entra Connect Sync のバージョン要件と Cloud Sync への移行計画は必ず確認しておくべきです。

Microsoft Entra Connect Sync は、2026年9月30日までに少なくともバージョン 2.5.79.0 へアップグレードしていない場合、すべての同期サービスが停止すると公式のバージョン履歴で案内されています。さらに、インストーラーは Microsoft Entra 管理センターから提供され、.NET Framework 4.7.2 と TLS 1.2 などの前提条件も確認が必要です。(Microsoft Learn)

期限・時期	内容	対応
2026年7月1日以降	hard match の追加保護が適用	特権アカウント、既存マッピング、hard match エラーを確認する
2026年7月以降	Microsoft 365 Message Center、Entra Connect Health、対象メールなどで Cloud Sync 移行タイムラインが通知される	自社テナントの通知を監視し、移行対象か確認する
2026年9月30日	Microsoft Entra Connect Sync 2.5.79.0 未満では同期サービス停止の可能性	バージョン確認とアップグレード計画を優先する

Microsoft は、Microsoft Entra Connect Sync から Microsoft Entra Cloud Sync への移行を段階的に進める方針を示しています。初期フェーズでは、Cloud Sync で現在の同期要件を満たせる比較的シンプルな構成のテナントが優先され、大規模ディレクトリや高度な機能に依存する組織は後続フェーズで案内されるとされています。(Microsoft Learn)

Cloud Sync への移行判断で確認すべきこと

Microsoft Entra Cloud Sync は、クラウド管理型の同期構成、複数エージェントによる冗長化、切り離された複数フォレストへの対応など、Connect Sync より運用を軽くできる場面があります。一方で、すべての Connect Sync 構成をそのまま置き換えられるわけではありません。

公式の移行判断ガイドでは、Cloud Sync が Microsoft のハイブリッド ID 同期における推奨方向であり、新しい同期・プロビジョニング機能の多くが Cloud Sync を中心に開発されると説明されています。ただし、Hybrid Azure AD Join のデバイス同期、複雑な同期ルール、大規模グループ、複雑なクロスフォレスト参照などは、移行前に機能差を確認する必要があります。(Microsoft Learn)

現在の構成	Cloud Sync 移行の見方
単一フォレスト、OU ベースの単純な同期	比較的移行を検討しやすい
1 ドメインあたり 150,000 オブジェクト未満	Cloud Sync のスケール条件に合いやすい
50,000 メンバーを超える大規模グループがない	移行候補になりやすい
Hybrid Azure AD Join のデバイス同期に依存	代替設計を確認してから判断する
高度なカスタム同期ルールを多用	Connect Sync 継続または再設計が必要になる可能性がある
複雑なクロスフォレスト参照がある	Cloud Sync の対応範囲を慎重に確認する

Cloud Sync へ段階移行する場合、パイロットや共存期間中に Microsoft Entra Connect Sync のスコープから OU、ドメイン、グループ、ユーザー、連絡先などを不用意に外してはいけません。公式の移行手順では、最終カットオーバーまで既存スコープを維持し、cloudNoFlow と JoinNoFlow ルールを使って不要なエクスポートを防ぐ共存モデルが説明されています。(Microsoft Learn)

管理者が今すぐ確認すべきチェックリスト

既存テナントに Microsoft Entra Connect を導入する、または既存構成を見直す場合は、次の順番で確認すると手戻りを減らせます。

現在の同期構成を棚卸しする

まず、Microsoft Entra Connect サーバーのバージョン、同期方式、同期対象 OU、カスタム同期ルール、サインイン方式を確認します。特に 2026年9月30日のバージョン要件に関係するため、2.5.79.0 未満の環境は優先的にアップグレード計画を立てる必要があります。

確認すべき項目は次のとおりです。

項目	確認方法の例
Microsoft Entra Connect Sync のバージョン	サーバー上のアプリ情報、Microsoft Entra Connect 管理画面、バージョン履歴との照合
同期対象 OU	Synchronization Service Manager、構成エクスポート
sourceAnchor 構成	既定値か、mS-DS-ConsistencyGuid を使っているか
サインイン方式	Password Hash Sync、Pass-through Authentication、AD FS
カスタム同期ルール	Synchronization Rules Editor
Connect Health	同期エラー、警告、通知の確認

既存クラウドユーザーと AD ユーザーを突き合わせる

次に、既存の Microsoft Entra ID ユーザーとオンプレミス AD ユーザーを比較します。見るべき軸は、UPN、プライマリ SMTP、社員番号、表示名、部署、管理者属性などです。

この時点で、「同じ人物なのに UPN が違う」「退職者のメールアドレスが別ユーザーに残っている」「共有メールボックスとユーザーで proxyAddresses が重複している」といった問題を発見できます。

特権アカウントを同期対象から分離する

既存の管理者アカウントは、通常ユーザーとは別に扱います。Microsoft Entra の特権ロールが割り当てられているアカウント、PIM で eligible なアカウント、break-glass アカウントは、同期対象に含める前に設計を見直してください。

特に、クラウド専用の管理者アカウントをオンプレミス AD の一般ユーザーへ hard match させる設計は避けるべきです。管理者権限の継承元が不明確になり、監査やインシデント対応で原因追跡が難しくなります。

属性の正を決めてから同期する

既存テナントでは、「クラウドの値が正しいのか」「オンプレミス AD の値が正しいのか」を属性ごとに決める必要があります。Microsoft Entra Connect によってオンプレミス管理へ切り替わると、AD 側の値が優先されるため、クラウドで最新化していた情報が失われることがあります。

判断基準は次のように整理できます。

属性	正にしやすい管理元	理由
氏名、部署、役職	人事システムまたは AD	組織情報として一元管理しやすい
メールアドレス	Exchange 管理または AD	Exchange ハイブリッド構成では属性整合性が重要
電話番号	人事・内線管理システム	現場更新が多いため更新元を明確にする
管理者属性	AD または人事連携	Teams、承認フロー、組織図に影響する
特権ロール	Microsoft Entra ID / PIM	オンプレミス属性とは分離して最小権限で管理する

パイロット同期で確認する

全社同期の前に、少数ユーザーでパイロットを行います。パイロット対象は、一般ユーザー、メール利用者、Teams 利用者、部署変更済みユーザーなど、属性差分が見えやすいユーザーを含めると検証しやすくなります。

パイロットでは、次の観点で確認します。

確認観点	チェック内容
照合結果	既存クラウドユーザーが意図した AD ユーザーに関連付いたか
属性上書き	表示名、メール、部署、電話番号が想定どおりか
サインイン	パスワード、MFA、条件付きアクセスに影響がないか
メール	proxyAddresses、プライマリ SMTP、メール配送に問題がないか
Teams / SharePoint	ユーザープロファイルや権限に不整合がないか
同期エラー	Connect Health や Synchronization Service Manager にエラーがないか

よくある失敗と回避策

既存テナントへの Microsoft Entra Connect 導入では、設定そのものよりも事前確認不足が失敗の原因になります。

よくある失敗	なぜ起きるか	回避策
クラウド側の最新属性が消える	AD 側の属性が古いまま同期された	同期前に AD 側へ正しい値を反映する
管理者アカウントが hard match でエラーになる	特権ロールや PIM eligibility がある	管理者アカウントを同期対象から分離する
同じメールアドレスで同期エラーになる	proxyAddresses がユーザー、グループ、連絡先で重複している	全オブジェクト種別でメール属性を棚卸しする
UPN を合わせたのに結合されない	既存オブジェクトに別の ImmutableId がある	sourceAnchor と ImmutableId の対応を確認する
Cloud Sync 移行中にグループメンバーが消える	パイロット OU を Connect Sync スコープから外した	最終カットオーバーまでスコープを維持する
古い Connect のまま運用する	自動アップグレード対象外や手動更新漏れ	バージョン履歴を確認し、期限前にアップグレードする
作業後も takeover 許可設定を戻さない	一時設定の管理台帳がない	変更前後の設定値と戻し作業をチケット化する

実務での推奨対応フロー

既存 Microsoft Entra テナントに Microsoft Entra Connect を導入する場合は、次の流れで進めるのが安全です。

フェーズ	実施内容	完了条件
調査	Connect バージョン、同期対象、既存クラウドユーザー、特権ロールを棚卸し	影響対象ユーザーとリスクが一覧化されている
属性整理	UPN、proxyAddresses、mail、sourceAnchor、重複属性を修正	競合候補が解消されている
設計	管理元、同期スコープ、管理者アカウント方針、ブロック設定を決める	運用ルールとして承認されている
パイロット	少数ユーザーで soft match / hard match と属性反映を確認	サインイン、メール、Teams、同期エラーに問題がない
本番展開	部門または OU 単位で段階同期	影響を監視しながらロールバック可能な状態で進む
安定化	ブロック設定を戻し、Connect Health と監査ログを確認	不要な takeover 許可や一時権限が残っていない
次期計画	Cloud Sync 移行可否と Microsoft からの移行通知を確認	自社の移行方針とタイムラインが決まっている

まとめ：既存テナントの Entra Connect 設定は「照合」と「管理元の切り替え」を慎重に扱う

Microsoft Entra Connect を既存テナントに構成する際の核心は、既にあるクラウドユーザーとオンプレミス AD ユーザーをどう安全に照合するかです。soft match は UPN やプライマリ SMTP、hard match は sourceAnchor と ImmutableId を使います。照合に成功すると、クラウド管理のユーザーがオンプレミス管理へ切り替わり、属性やパスワードハッシュ同期に実運用上の影響が出る可能性があります。

2026年7月1日以降は hard match の保護が強化され、特権ロールを持つクラウドアカウントや、すでに onPremisesObjectIdentifier が設定されているアカウントではブロックが発生しやすくなります。さらに、Microsoft Entra Connect Sync は 2026年9月30日までに少なくとも 2.5.79.0 へ上げる必要があるため、既存テナントの同期設計だけでなく、バージョン管理と Cloud Sync への移行準備も同時に進めるべきです。

まず行うべきことは、Microsoft Entra Connect のバージョン確認、既存クラウドユーザーと AD ユーザーの属性突き合わせ、特権アカウントの分離、UPN と proxyAddresses の重複解消です。そのうえで、少数ユーザーのパイロット同期を行い、hard match / soft match の結果、属性上書き、サインイン影響を確認してから本番展開に進むのが安全です。