オンプレミスの Active Directory（AD）で運用してきた配布グループ／セキュリティ グループを「SOA（Source of Authority：権限の所在）」切替えで Microsoft Entra ID 側のクラウド管理（Cloud‑managed）へ転換した後、AD から当該グループを削除すると、Azure AD Connect／Microsoft Entra Connect Sync の削除同期（Delete フロー）が失敗して大量のエラーが出る――この“ダッシュボードが赤く染まる”状況を、仕組み面から解きほぐし、実務で確実に解消する方法を体系的にまとめます。環境依存の前提やロールバックも含め、現場でそのまま使える手順書としてご活用ください。
発生する事象の概要
SOA をクラウドへ切り替えたグループを AD 側で削除すると、次回の Connect Sync（以降、Connect）で当該グループに対する Export（削除） が試行されます。しかし既にクラウド側の SOA は「Cloud‑managed」であるため、Connect からの削除要求は矛盾として扱われ、エクスポート エラーの山が生成されます。グループ自体はクラウドに残り続けるため機能上の実害は小さいものの、モニタリングの視認性が著しく低下し、本当に対処が必要な異常の見落としにつながります。
なぜ削除同期エラーが起きるのか（内部挙動の理解）
核心は Connect の設計思想にあります。Connect は「同期スコープ外＝削除」というルールを持ちます。これは、オンプレミスにおける“管理の不在”をクラウド側の“削除”として整合させるためのものです。SOA をクラウドへ切り替えても、一度でも Connect の管理下（メタバース）に取り込まれたオブジェクトがスコープから外れると、Connect はそのオブジェクトに対してクラウド削除を必ず試行します。ここで SOA の衝突が起き、エラーが蓄積されます。
| 項目 | Azure AD Connect / Entra Connect Sync | Entra Cloud Sync |
|---|---|---|
| アーキテクチャ | フル機能、SQL DB 同梱、メタバース中心 | 軽量エージェント複数配置、クラウド制御 |
| スコープ外オブジェクト | 削除扱い（Delete Export を必ず試行） | 削除フローなし（スコープ外でもエラーになりにくい） |
| 得意領域 | フルハイブリッド、特殊な同期変換、PHS/ PTA など | クラウド優先、AD 依存の最小化、運用軽量化 |
| SOA 切替えとの相性 | 衝突が起きやすい（削除試行が残る） | 良好（矛盾が発生しにくい） |
よくある再現パターン
- AD で配布グループ / セキュリティ グループを運用し、Connect で同期。
- Entra ID で該当グループを「Cloud‑managed」に SOA 切替え。
- 運用整理のため、AD 上の同名グループを削除。
- 次の Delta Sync で Connect が “スコープ外＝削除” と判断し、クラウド削除の Export を実施。
- クラウド側は SOA＝Cloud のため削除拒否（整合性エラー）。
- 結果として Export エラーが大量発生し、ダッシュボードが常時エラー状態に。
解決アプローチの比較
| 解決アプローチ | 内容 | メリット | デメリット／注意点 |
|---|---|---|---|
| ① 削除前に同期スコープから除外 | 対象グループの OU / 属性フィルタを一時的に外し、「同期に載せない」状態で SOA をクラウドへ切替え → AD 側を削除。 | 現行の Connect を維持しつつ、エラーの発生を抑制。 | OU / 属性設定のミスで他オブジェクトが同期されなくなるリスク。 Connect はスコープ外＝削除を試行するため、エクスポート停止の運用（後述）が事実上の前提。 |
② preserveInCloud（ExtensionAttribute 等）を設定 | “クラウド保護”フラグを付与して「削除せず残す」ことを Connect に指示。 | 手順がシンプルで導入障壁が低い。 | オブジェクトがスコープ外になると Connect は必ず削除を試行する仕様は変わらないため、完全解決にはならない。運用ミス時の保険程度と捉える。 |
| ③ Entra Cloud Sync へ移行（推奨） | 既存の Connect を段階的に停止し、軽量エージェント型の Cloud Sync に切替え。 手順：1）Cloud Sync 構成と OU 登録 → 2）Connect 側で同一オブジェクトをスコープ外へ → 3）SOA をクラウドへ → 4）AD から削除 | クラウド ネイティブな管理に最適化。 スコープ外＝削除という制約がないため同期エラーを出しにくい。 将来の AD 依存を最小化。 | 切替え作業と検証の工数が発生。並行期間の計画が必要。 |
| ④ エラーを無視 | 実害が小さいため運用で割り切る。 | 変更作業ゼロ。 | 監視コンソールが常時エラーで本当の障害を見落としやすい。監査・運用品質の観点で非推奨。 |
推奨：Entra Cloud Sync へ段階移行する実務手順
根治を目指すなら、スコープ外＝削除という仕様から脱却できる Cloud Sync への移行が最も現実的です。以下は現場向けのプレイブックです。
前提チェックリスト
- 移行対象：グループ単位（配布／セキュリティ／メール有無）を棚卸し。クラウド動的グループは対象外。
- 影響範囲：委任権限、アプリ割り当て、チーム／サイト メンバーシップに依存関係がないか確認。
- Change & Rollback：切替えウィンドウ、連絡、検証、切り戻し（Connect の再有効化）を準備。
ステップ 1：Cloud Sync の初期構成
- Cloud Sync エージェントを冗長構成でインストール（少なくとも 2 台）。
- 同期スコープに対象 OU を登録。属性ベースのフィルタも極力シンプルに。
- “スコープ内オブジェクトの挙動”が期待通りか、テスト用グループで Dry‑Run。
ステップ 2：Connect のエクスポートを安全に止める
Connect が“スコープ外＝削除”をクラウドに投げないよう、事前にエクスポートを停止します。運用負荷を下げるために以下の 2 択から選びます。
- スケジューラ停止（簡易）：
# Connect サーバーで実行（管理者 PowerShell） Set-ADSyncScheduler -SyncCycleEnabled $false # 念のため現在キューに残る Export が無いか確認 Get-ADSyncConnectorRunStatus - Azure AD Connector の Export を一時無効化（厳格）：
Synchronization Rules Editor / MIISClient で対象コネクタの Export プロファイルを実行不可状態にする（運用標準がある場合はそれに従う）。
ステップ 3：一時的に Connect スコープ外へ
- 対象グループだけが外れるよう OU／属性フィルタを調整。
- Full Sync を 1 回実施してメタバースからの離脱を確認。
Start-ADSyncSyncCycle -PolicyType Initial # 結果は MIISClient（Operations）で確認
ステップ 4：SOA をクラウドへ切替え
- Entra ID 管理センターで対象グループの SOA を Cloud‑managed に変更。
- 念のためクラウド側のプロパティ（例：onPremisesSyncEnabled が false 相当であること、onPremisesLastSyncDateTime の更新が止まっていることなど）を確認。
ステップ 5：AD から当該グループを削除
この時点でクラウドは当該グループを“クラウドの資産”として扱うため、AD からの削除はクラウドへ波及しません。
ステップ 6：Cloud Sync による運用へ移行
- Cloud Sync のスコープに同名グループを含めない（Cloud‑managed を維持）。
- 以後はクラウドでメンバーシップ／設定を管理。
ステップ 7：Connect の段階停止 → アンインストール
- 同様の手順で対象範囲を段階的に Cloud Sync へ移譲。
- 最終的に Connect のスケジューラ停止、サービス停止、アンインストール。
切り戻し手順（ローリングバック）
- Connect のエクスポート停止を維持したまま、対象グループを OU／属性でスコープに戻す。
- SOA を一時的に「AD 管理」へ戻し、AD 側でオブジェクトを再作成（必要なら同名）。
- Delta Sync → Export。想定外の削除が無いことを確認後、Cloud Sync スコープから外す。
Connect を継続利用する場合の回避策
アプローチ①：削除前に同期スコープから除外（安全版の実行手順）
- Export 停止（前述の手順）。
- 対象グループを OU／属性でスコープ外へ。
- Full Sync を 1 回実施し、メタバースからのデタッチを確認。
- SOA を Cloud‑managed に切替え。
- AD 側のグループを削除。
- Export を再開。
ポイント：Export を止めずにスコープ外へ出すと、Connect が直ちに削除要求を投げ、エラーが堆積します。運用標準として「削除を伴うスコープ変更は Export 停止が必須」を明文化しましょう。
アプローチ②：preserveInCloud の活用（限定的）
“クラウド保護”フラグを ExtensionAttribute 等に付与し、削除要求を抑止する運用もあります。代表的な実装は「特定の拡張属性に preserveInCloud（または同義のフラグ）を書き、同期ルールで削除フローをブロックする」方式です。
- 利点：単純で導入が容易。既存の Connect 環境を維持しながら試せる。
- 限界：オブジェクトがスコープ外になった事実は変わらず、Connect の“削除試行”自体は発生します。何らかのトリガーでフラグが欠落すれば再びエラー化し得るため、恒久策にはならない点を理解してください。
なお、同期ルールのカスタマイズは影響範囲が広く、検証と変更管理が必須です。本番前にステージング環境（または Connect の Staging Mode）で検証しましょう。
運用・監視のベストプラクティス
- 「スコープ変更＝Export 停止」標準化：削除や大規模移動を伴う OU／属性フィルタ変更は、必ず Export を停止してから実施。
- ステージング モードの活用：Connect を Staging Mode に切り替えると、Import／Sync のみ実行し Export を出しません。Dry‑Run と差分検証に有効です。
- 削除しない運用：SOA 切替え済みのグループは AD で削除せず、一定期間は無効化・説明追記・ OU 隔離で温存するポリシーも有効（監査・トレーサビリティの確保）。
- ダッシュボードの健全化：「意図的なエラー」をゼロ化し、アラート＝本当に対処が必要という状態を保つのが最重要です。
実務で役立つ確認コマンド例（抜粋）
以下は移行前後の状態確認に役立つ PowerShell の例です（実行環境に応じて調整してください）。
# Connect のスケジューラ状態を確認
Get-ADSyncScheduler
# 直近のコネクタ実行状態（Export が残っていないか）
Get-ADSyncConnectorRunStatus
# 各コネクタの統計（MIISClient が使えない時の簡易把握）
(Get-ADSyncConnectorStatistics).ConnectorName, (Get-ADSyncConnectorStatistics).ExportAdd, (Get-ADSyncConnectorStatistics).ExportDelete
# Microsoft Graph PowerShell でグループの“同期由来”をざっくり把握
# ※ 接続と権限付与は事前に実施済みである前提
Connect-MgGraph -Scopes "Group.Read.All"
Select-MgProfile -Name "v1.0"
# SOA 切替え候補（オンプレ同期無効 or 最終同期が古い等）を抽出する一例
Get-MgGroup -All | Where-Object {
($*.OnPremisesSyncEnabled -eq $false -or $*.OnPremisesLastSyncDateTime -lt (Get-Date).AddDays(-30))
} | Select-Object Id, DisplayName, OnPremisesSyncEnabled, OnPremisesLastSyncDateTime シナリオ別ガイド
最終的に AD を縮小・撤廃したい場合
- Cloud Sync を導入し、対象グループを段階的にクラウド管理へ移譲。
- Connect を停止（またはアンインストール）。
- SOA 切替え済みのグループは Cloud‑managed のまま AD から削除（Export 停止中に実施）。
この流れなら、同期エラーを一切出さずにクラウドネイティブ運用へ移れます。
配布グループ／セキュリティ グループの混在環境
- メール対応（配布グループ）：アプリ割当やチーム連携が絡むため、SOA 切替えの前後でメンバーシップを二重書きしないように注意。
- セキュリティ グループ：RBAC／アプリ割り当ての依存が強い。バックアップ（現在メンバーのエクスポート）を必ず取得。
トラブルシュート：エラーが消えないときの確認ポイント
| 症状 | 考えられる原因 | 対処 |
|---|---|---|
| 同じグループで常に Export エラー | Connect がスコープ外として削除を継続試行／SOA が Cloud | Export を停止 → スコープ見直し → Full Sync → SOA 確認 → Export 再開 |
| 意図せぬグループまでエラー化 | OU／属性フィルタの誤設定、ワイルドカードの範囲過大 | フィルタ設計を縮小し、対象限定で再実施。変更は必ずステージングで検証。 |
| SOA を戻しても挙動が不安定 | メタバース残骸、ルールの競合 | Full Sync（初期同期）で再評価。不要なカスタム ルールの棚卸し。 |
FAQ
- Q：ユーザーや連絡先でも同様の問題は起きる？
A：Connect の「スコープ外＝削除」という哲学はオブジェクト種別を問いません。SOA の衝突があれば同型の問題は起こり得ます。 - Q：Group Writeback を使っているが影響は？
A：Writeback も所有権と整合性の管理が重要です。SOA 切替え後は“書き戻し先の AD オブジェクト”の扱いに一層の注意が必要です。 - Q：エラーの放置は本当にダメ？
A：短期的には実害が薄く見えても、監査・SLA・運用品質の観点で悪影響が蓄積します。根治または抑止策の実装を推奨します。
ベストプラクティスのまとめ
- これは仕様通りの挙動であり、完全解消には Entra Cloud Sync への移行が最も現実的。
- 当面 Connect を使うなら、「スコープ変更は Export 停止 → 検証 → 再開」を標準化し、先にスコープから外してから SOA 切替えの順序を徹底。
preserveInCloudは“保険”としては有効だが、恒久対策ではない。- 監視ダッシュボードから“ノイズ”を排除し、アラート＝要対応の状態を維持することが運用の肝。
実務テンプレ：Change プラン（抜粋）
| フェーズ | 作業 | 責任 | 判定基準 |
|---|---|---|---|
| 計画 | 対象グループの棚卸し、依存関係の洗い出し、バックアップ（メンバー CSV） | ID 管理チーム | 対象リスト・影響分析完了、承認取得 |
| 準備 | Cloud Sync 導入、テスト、Connect Export 停止手順のリハーサル | プラットフォーム運用 | 試験結果 OK、切替え Go 判定 |
| 切替え | Export 停止 → スコープ外し → SOA 切替え → AD 削除 | 運用当番 | MIISClient でエラー無し、クラウドにグループが残存 |
| 検証 | メンバーシップ／アプリ割当の健全性確認、監視の閾値チェック | 対象システムオーナー | 利用者影響無しを確認 |
| 終結 | Export 再開、ログ保全、手順書更新 | ID 管理チーム | 次回変更に向けた再発防止策を反映 |
キーポイント早見表
| テーマ | 要点 | 実務の勘所 |
|---|---|---|
| SOA 衝突 | Connect はスコープ外→削除。Cloud 側は Cloud‑managed を優先。 | Export 停止中にスコープ変更と SOA 切替えを行う。 |
| 恒久対策 | Cloud Sync へ移行し“スコープ外＝削除”の縛りから脱却。 | 並行運用期間を設け、段階移行・検証・切り戻しを計画。 |
| 暫定回避 | preserveInCloud 等で削除抑止。 | 恒久策ではない。属性消失に備え監視とバックアップを。 |
| 運用標準 | 「スコープ変更＝Export 停止」を文化にする。 | 手順書・チェックリスト・レビューを定着化。 |
結論
SOA 切替え後のグループを AD から削除した際に発生する同期エラーは、“仕様通りの挙動”が引き起こすものです。根本解決には Entra Cloud Sync への移行が最も効果的で、当面 Connect を使い続ける場合は エクスポート停止 → スコープ外し → SOA 切替え → AD 削除 → エクスポート再開の順序を徹底することで、ダッシュボードを健全に保てます。監視のノイズをゼロ化し、“エラー＝対応が必要”というシンプルな状態を維持することが、ハイブリッド ID 運用の品質を劇的に向上させます。
付録：運用チェックリスト（コピーしてお使いください）
- [ ] 対象グループの棚卸し（DisplayName / ObjectId / 依存先）
- [ ] メンバー CSV バックアップ取得
- [ ] Connect Export 停止手順の確認・権限の準備
- [ ] スコープ変更の影響範囲レビュー（最小化）
- [ ] ステージング（Dry‑Run）結果のレビュー
- [ ] SOA 切替え順序・担当者の明確化
- [ ] 切替え当日の復旧窓口・連絡系統の整備
- [ ] 検証観点（アプリ割当、チーム／サイト、アクセスレビュー）
- [ ] ログ保全・変更記録・手順書の更新
コメント