オンプレミスの Active Directory ユーザーをうっかり削除してしまったのに、Microsoft 365（Entra ID）側のユーザーは生きている──ハイブリッド環境ではとてもよくある事故です。さらにあわててオンプレ側に同名ユーザーを作り直すと、クラウドとオンプレで別人扱いになり、メールやTeams、OneDrive との整合性が崩れてしまいます。本記事では、この「AD 削除 → M365 二重化」状態を、安全に１つのユーザーとして再リンクする具体的な手順と考え方を解説します。
オンプレ AD ユーザー誤削除 → Microsoft 365 だけ残ったとき何が起きているか
まずは、よくあるトラブルのシナリオを整理します。
- オンプレミス Active Directory のユーザーアカウントを誤って削除してしまった。
- ハイブリッド構成のため、Microsoft 365（Entra ID）側には同期済みユーザーが残っている。
- ユーザー本人は引き続き、メールボックス / OneDrive / Teams / SharePoint にアクセスできている。
- 慌ててオンプレ AD に同じ名前・同じメールアドレスでユーザーを作り直した。
- ところが、この新しいオンプレユーザーは、クラウド側の既存ユーザーとは紐付かず、「別人」として扱われる。
ここで大事なのは、Microsoft 365 では「表示名」や「UPN」が同じでも、内部的には別のオブジェクト ID（およびソースアンカー）として扱われるという点です。人間から見ると「同じ山田さん」でも、システムから見ると「山田さんA」「山田さんB」と別物になってしまいます。
この状態で無理やりどちらかのユーザーを削除したり、メールボックスを移行し直そうとすると、メールやファイルのアクセス権を失うリスクが高くなります。解決のポイントは「アカウントを合体する」のではなく、クラウド側ユーザーとオンプレ側ユーザーのひも付け（ソースアンカー）を合わせることです。
結論：アカウントの「合体」ではなく、ソースアンカーを合わせて再同期する
ハイブリッド ID 環境では、ユーザーを一意に識別するために ソースアンカー（Source Anchor） という値が用意されています。オンプレ AD 側ではふつう mS-DS-ConsistencyGuid（または旧来の objectGUID）、クラウド側（Entra ID / Microsoft 365）では ImmutableId が対応します。
頭の中を整理するために、対応関係を表にしてみます。
| 役割 | オンプレ AD 側属性 | クラウド側属性 | 備考 |
|---|---|---|---|
| ソースアンカー（推奨） | mS-DS-ConsistencyGuid | ImmutableId | 現在の既定。GUID が Base64 化されてクラウドに保存される。 |
| ソースアンカー（旧方式） | objectGUID | ImmutableId | 古い Azure AD Connect で採用。今もこの方式の環境が残っている場合がある。 |
| サインイン ID | userPrincipalName | userPrincipalName | ユーザーがサインインに使う ID。ソースアンカーではない。 |
今回のゴールはこのソースアンカーを合わせることです。具体的には、
- クラウド側に残っているユーザーの
ImmutableIdを読み取る - Base64 → GUID に変換する
- オンプレで作り直したユーザーの
mS-DS-ConsistencyGuidに同じ値を書き込む - Entra Connect（旧 Azure AD Connect）で同期する
この操作により、「このオンプレユーザーは、もともとクラウドに存在しているこのユーザーと同一人物です」とシステムに教え直すイメージです。この手順を一般に ハードマッチ（Hard Match） と呼びます。
最短・最安全ルート：AD リサイクル ビンから元ユーザーを復元できないか確認
もし Active Directory Recycle Bin（AD リサイクル ビン） が有効で、なおかつ元のユーザーオブジェクトが残っているなら、それを復元して再同期するのが最も安全でシンプルです。
- リサイクル ビンからユーザーを復元すると、元の
objectGUID/mS-DS-ConsistencyGuidがそのまま戻る。 - その結果、Entra Connect が再度同期したとき、自動的にクラウド側の既存ユーザーと再リンクされる。
- オンプレ由来のグループメンバーシップなども、かなりの範囲で元に戻せる。
逆にいうと、
- リサイクル ビンが無効
- 有効だが、保持期間を過ぎて完全削除されている
といった場合は、これから紹介するハードマッチ（またはソフトマッチ）での対応が必要になります。
ハードマッチで再リンクする手順（推奨・確実）
ここからは、mS-DS-ConsistencyGuid をソースアンカーに使っている環境 を前提に、ハードマッチの具体的な手順を解説します。
前提と準備
- オンプレ AD / Entra ID が同期されたハイブリッド環境である。
- ソースアンカーが
mS-DS-ConsistencyGuidになっている（既定設定）。 - オンプレ側に新しいユーザー（誤って削除したユーザーと同じ人物）が作成済み。
- クラウド側ユーザーは削除していない。
ソースアンカーの設定がわからない場合は、Entra Connect の構成ウィザードや同期ルール（Synchronization Rules Editor）で確認できます。古い構成では objectGUID が使われていることもあるので、その場合は「ConsistencyGuid」と「objectGUID」が入れ替わるだけだと考えてください。
ステップ1：同期スケジューラを一時停止する
まずは、作業中に中途半端な状態が同期されないよう、Entra Connect サーバーで同期スケジューラを止めておきます。
# Entra Connect サーバー上で実行
Set-ADSyncScheduler -SyncCycleEnabled $false
これで自動同期が止まるので、以降の変更は手動でデルタ同期をかけるまでクラウドに反映されません。
ステップ2：オンプレ新ユーザーの基本属性をクラウド側と合わせる
次に、オンプレで作り直したユーザーの属性を、クラウド側ユーザーと極力そろえます。特に重要なのは以下の属性です。
| 属性名 | 例 | ポイント |
|---|---|---|
userPrincipalName | [email protected] | クラウド側と完全一致させるのが理想。 |
mail | [email protected] | SMTP アドレスと揃える。クラウド側と同じに。 |
mailNickname | user | Exchange のエイリアス。クラウド側と同じ値に。 |
displayName | 山田 太郎 | 表示名。多少違っても致命傷ではないが、可能なかぎり合わせる。 |
proxyAddresses | SMTP:[email protected], smtp:[email protected] | 最重要ポイント。クラウド側と重複・不足がないか要確認。 |
特に proxyAddresses の重複 は、同期時に Duplicate attribute エラーの原因になります。オンプレ側に設定する前に、クラウド側に同じ SMTP アドレスを持つユーザーやグループが存在しないか、必ず確認してください。
ステップ3：クラウド側ユーザーの ImmutableId を取得する
続いて、クラウド側（Entra ID）ユーザーの ImmutableId を PowerShell で取得します。
現在は Microsoft Graph PowerShell の利用が推奨です。
Connect-MgGraph -Scopes "User.Read.All"
# 対象ユーザーの UPN で取得
$user = Get-MgUser -UserId "[email protected]" -Property OnPremisesImmutableId
$immutableId = $user.OnPremisesImmutableId # ここに Base64 文字列が入る
$immutableId
レガシーな MSOnline モジュール がまだ使える環境であれば、次のようにも取得できます。
Connect-MsolService
$immutableId = (Get-MsolUser -UserPrincipalName "[email protected]").ImmutableId
$immutableId
いずれも、出力されるのは Base64 文字列 です。これを GUID に戻し、オンプレ側の mS-DS-ConsistencyGuid に書き込むのが次のステップです。
ステップ4：Base64 → GUID に変換する
ImmutableId の Base64 文字列を GUID に変換します。
$bytes = [Convert]::FromBase64String($immutableId)
$guid = [Guid]::new($bytes)
$guid # 例: 12345678-90ab-cdef-1234-567890abcdef
表示された GUID が、元々オンプレ側ユーザーの mS-DS-ConsistencyGuid（あるいは objectGUID）として使われていた値に相当します。
ステップ5：GUID をオンプレユーザーの mS-DS-ConsistencyGuid に書き込む
GUID を取得したら、それをオンプレミス AD の新規ユーザーの mS-DS-ConsistencyGuid に書き込みます。
# "samAccountNameまたはDN" の部分は実際のユーザー識別子に置き換えて実行
Set-ADUser -Identity "samAccountNameまたはDN" -Replace @{
'mS-DS-ConsistencyGuid' = $guid.ToByteArray()
}
この瞬間、オンプレ側のユーザーは「ソースアンカー的には元のユーザーと同じ存在」として定義されます。あとは同期をかけて、クラウド側ユーザーと自動的に結びつけるだけです。
ステップ6：同期を再開してデルタ同期を実行
準備ができたら、同期スケジューラを元に戻し、デルタ同期を実行します。
# 自動同期を再開
Set-ADSyncScheduler -SyncCycleEnabled $true
# 即時デルタ同期を実行
Start-ADSyncSyncCycle -PolicyType Delta
同期に成功すると、Entra Connect は「ソースアンカーが一致するユーザーがクラウドにいる」と判断し、既存のクラウドユーザーとオンプレ新ユーザーが再リンクされます。
ステップ7：リンク状態の確認ポイント
同期後は、以下の観点で結果を確認しましょう。
- Entra 管理センターで該当ユーザーを開き、「ソース：Windows Server AD」や「同期済み」 といった表示になっているか。
- Exchange Online 管理センターで、受信者の種類が 「同期済みユーザー」または「同期済みメールボックス」 になっているか。
- 同期エラー（特に Duplicate attribute, ConstraintViolation）が発生していないか。
- ユーザー本人に依頼して、サインイン・メール送受信・Teams / OneDrive へのアクセス を確認してもらう。
同期エラーが出ている場合は、miisclient.exe（同期サービス マネージャー）でコネクタ スペースの詳細を確認し、問題の属性（UPN や proxyAddresses 等）を修正したうえで再同期します。
ソフトマッチで再リンクするパターン（ImmutableId が空の場合）
ハードマッチのほかに、ソフトマッチ（SMTP/UPN マッチ） という方法もあります。これは、クラウド側ユーザーの ImmutableId が空の場合に機能する仕組みです。
ソフトマッチでは、次の条件がそろっていると、同期時に「同一人物」と自動判定されます。
- クラウド側ユーザーの
ImmutableIdが設定されていない（null）。 - オンプレユーザーとクラウドユーザーで、
userPrincipalNameが完全一致。 - オンプレユーザーの
proxyAddressesのプライマリ SMTP（SMTP:～）が、クラウドユーザーのプライマリ SMTP と完全一致。
環境によっては、元々クラウドのみで作られたユーザー（いわゆるクラウド専用アカウント）を後からオンプレと紐付けるときに、このソフトマッチを使うケースがあります。
ImmutableId をクリアしてソフトマッチさせる手順（自己責任）
既に ImmutableId が入っているユーザーを「ソフトマッチで扱いたい」場合は、自己責任になりますが ImmutableId をいったん空にすることもできます。レガシーな MSOnline モジュールの例を挙げます。
Connect-MsolService
# ImmutableId をクリア（null にする）
Set-MsolUser -UserPrincipalName "[email protected]" -ImmutableId $null
そのうえで、オンプレ側の UPN / SMTP をクラウド側と完全一致させ、デルタ同期を実行します。
Start-ADSyncSyncCycle -PolicyType Delta
ただし、ソフトマッチは条件に少しでもズレがあると失敗しやすく、アドレス競合や別ユーザーとの誤マッチのリスク もあります。確実性・安全性の観点から、可能であれば前述の ハードマッチを第一候補 にすることを強くおすすめします。
運用上の注意点・ベストプラクティス
今回のような事故をきっかけに、運用面の見直しもしておくと再発防止につながります。ポイントを整理しておきます。
Microsoft 365 側ユーザーはできるだけ削除しない
- クラウド側ユーザーを安易に削除すると、メールボックス / OneDrive / Teams / SharePoint 権限 など大量の関連データが巻き込まれます。
- 「オンプレユーザーを消してしまった！」というタイミングでは、クラウド側ユーザーは一切触らないのが鉄則です。
オンプレ由来のグループや権限は再付与が必要
- ハードマッチにより、クラウド側の Object ID はそのまま維持されます。
- その結果、Teams / SharePoint / Exchange Online 上の権限は基本的に変わりません。
- 一方で、オンプレ AD グループのメンバーシップ は、新規ユーザーとして復元し直す必要があります。
proxyAddresses と UPN の重複チェックを習慣化する
- 新規ユーザーや再作成ユーザーを作る前に、同じメールアドレスや UPN を持つアカウントが既に存在しないか、検索で確認する。
- 特に
proxyAddressesは、ユーザー / グループ / 共有メールボックスすべてが一意 である必要があります。
ハイブリッド Exchange 環境では、アドレス帳属性はオンプレで一元管理
- ハイブリッド構成の原則は「アドレス帳関連属性（
proxyAddressesなど）はオンプレで編集 → 同期でクラウドへ反映」です。 - クラウド側だけでアドレスをいじると、オンプレとクラウドで情報が二重管理になり、将来のトラブルの種になります。
バックアップと事前エクスポート
- 重要ユーザーの属性は、定期的に
Get-ADUserや CSV エクスポートで控えておくと、復旧時に非常に役立ちます。 - 大規模変更の前には、必ずバックアップやスナップショットを検討しましょう。
Entra Connect / Cloud Sync の種類を把握しておく
- オンプレにサーバー型の Entra Connect を置く方式と、Cloud Sync（エージェント）方式では構成や管理画面が異なります。
- どちらの方式でも「ソースアンカーを合わせる」という考え方は同じです。
よくある質問・ハマりどころ
Q. ソースアンカーが objectGUID か ConsistencyGuid かわからない
A. Entra Connect の構成ウィザードや「Synchronization Rules Editor」を開き、ユーザーの「Source Anchor」の定義を確認してください。mS-DS-ConsistencyGuid が指定されていれば新方式、objectGUID なら旧方式です。旧方式の場合は、「ConsistencyGuid」の代わりに objectGUID を扱うことになります。
Q. オンプレ側に元ユーザーの objectGUID が残っていないが大丈夫？
A. 今回のように「クラウド側に ImmutableId が残っている」のであれば、それを逆算して GUID を復元できます。つまり、クラウドに残っている情報を起点にオンプレを再構築するイメージです。
Q. そもそも ImmutableId が空だった
A. もともとクラウド専用ユーザーだった可能性があります。この場合、オンプレユーザーと UPN / SMTP を合わせてソフトマッチさせるパターンも考えられます。今後もハイブリッド管理を行う予定であれば、ハードマッチで mS-DS-ConsistencyGuid を決めておく方が運用が安定します。
Q. 似た名前のユーザーが複数いて、どれが本物かわからない
A. 氏名だけで判断せず、UPN・メールアドレス・使用中のライセンスやグループ など、総合的に確認してください。特に削除済みユーザーや共有メールボックスと混同しないよう注意が必要です。
Q. Entra Connect の同期エラーが怖くて本番で試せない
A. 可能であれば、テスト用ドメイン / テストユーザーで同じ手順を事前にリハーサルしておくと安心です。また、本番では業務時間外に作業し、事前にロールバック案（たとえば ImmutableId を元に戻すための控え）を用意してから実行しましょう。
チェックリスト：作業前・作業後に確認しておきたいポイント
| タイミング | 項目 | 確認内容 |
|---|---|---|
| 作業前 | AD リサイクル ビン | 元ユーザーオブジェクトが復元可能かどうか。 |
| 作業前 | クラウド側ユーザーの特定 | UPN・メールアドレス・表示名・ライセンスなどから、対象ユーザーを誤りなく特定したか。 |
| 作業前 | ImmutableId の取得 | 対象クラウドユーザーの ImmutableId を安全な場所に控えたか。 |
| 作業前 | proxyAddresses 重複確認 | 同じ SMTP アドレスを持つユーザーやグループが他にいないか。 |
| 作業中 | 同期停止 | Set-ADSyncScheduler -SyncCycleEnabled $false を実行したか。 |
| 作業中 | ConsistencyGuid 設定 | Base64 → GUID → mS-DS-ConsistencyGuid の設定を誤りなく実施したか。 |
| 作業後 | 同期再開・デルタ同期 | 同期を有効化し、デルタ同期を実行したか。 |
| 作業後 | 同期エラー確認 | Entra Connect／Entra 管理センターでエラーが出ていないか。 |
| 作業後 | ユーザー影響確認 | ユーザーによるサインイン、メール送受信、Teams/OneDrive 利用に問題がないか。 |
コマンド早見表（抜粋）
本記事で紹介した主な PowerShell コマンドを、一覧としてまとめておきます。
# --- 同期制御関連 ---
# 同期の一時停止
Set-ADSyncScheduler -SyncCycleEnabled $false
# 同期の再開
Set-ADSyncScheduler -SyncCycleEnabled $true
# 即時デルタ同期
Start-ADSyncSyncCycle -PolicyType Delta
# --- クラウド（Graph）から ImmutableId を取得 ---
Connect-MgGraph -Scopes "User.Read.All"
# UPN でユーザーを取得
$user = Get-MgUser -UserId "[email protected]" -Property OnPremisesImmutableId
$immutableId = $user.OnPremisesImmutableId
$immutableId
# --- Base64 → GUID に変換し、mS-DS-ConsistencyGuid に設定 ---
$immutableId = "<Base64 文字列>"
# Base64 をバイト配列に
$bytes = [Convert]::FromBase64String($immutableId)
# GUID 化
$guid = [Guid]::new($bytes)
# AD ユーザーに mS-DS-ConsistencyGuid として書き込み
Set-ADUser -Identity "samAccountName" -Replace @{
'mS-DS-ConsistencyGuid' = $guid.ToByteArray()
}
# --- 逆方向：オンプレ GUID → Base64 → クラウドに設定（MSOnline 例） ---
# オンプレユーザーの ConsistencyGuid / ObjectGUID を取得
$adUser = Get-ADUser "samAccountName" -Properties 'mS-DS-ConsistencyGuid','ObjectGUID'
# ConsistencyGuid があればそれを、無ければ objectGUID を使う
$anchor = $(
if ($adUser.'mS-DS-ConsistencyGuid') {
$adUser.'mS-DS-ConsistencyGuid'
} else {
$adUser.ObjectGUID
}
)
# Base64 へ変換
$immutableIdB64 = [Convert]::ToBase64String($anchor.ToByteArray())
# クラウド側ユーザーに ImmutableId として設定
Connect-MsolService
Set-MsolUser -UserPrincipalName "[email protected]" -ImmutableId $immutableIdB64
# --- ソフトマッチ用（ImmutableId をクリア：自己責任） ---
Connect-MsolService
Set-MsolUser -UserPrincipalName "[email protected]" -ImmutableId $null
まとめ：事故を「学び」に変えて、ハイブリッド ID を堅牢にする
オンプレ AD ユーザーの誤削除は、規模の大小を問わずどの現場でも起こり得ます。重要なのは、
- クラウド側ユーザーはむやみに削除しない
- 復旧の最優先は AD リサイクル ビンからの復元
- 復元できない場合は、ソースアンカー（ImmutableId ⇔ mS-DS-ConsistencyGuid）を合わせるハードマッチ を基本とする
- proxyAddresses や UPN の一意性をしっかり管理する
この流れさえ押さえておけば、「AD を消してしまった！」という場面でも冷静に対応できます。今回紹介した手順とチェックリストを、自社環境向けの運用手順書やナレッジとして整備しておくと、将来のトラブルシュート時間を大きく削減できるはずです。
ハイブリッド ID の肝は、見た目の表示名や UPN ではなく、ソースアンカーの一貫性です。ImmutableId と mS-DS-ConsistencyGuid の関係を正しく理解し、確実に扱えるようになれば、ユーザーアカウント管理のレベルは一段上がります。
コメント