Microsoft Entra IDで「オンプレ管理」グループが削除できない原因と対処法：Azure AD Connect同期エラーをGraphで解消

Microsoft Entra ID（旧Azure AD）で、オンプレADでは削除したはずのグループが「このオブジェクトはオンプレミスで管理されています」と表示され、削除できない・同期エラーになることがあります。本記事では原因の見立てから、Azure AD Connect／Cloud Syncでの再伝搬、最終手段としてのMicrosoft Graphによる手動削除まで、現場で詰まりやすいポイント込みで解説します。

現象：Entra IDで「オンプレ管理」と表示され、削除ボタンが効かない

対象のグループをEntra管理センターで開くと、ソースや説明欄に「オンプレミスで管理」「同期されているオブジェクト」などの表示が出て、GUIから削除できません。さらに、Azure AD Connect（またはCloud Sync）の同期が失敗し、以下のような状態になりがちです。

• オンプレAD上ではグループが見つからない（既に削除済み）
• クラウド側にだけグループが残り続ける
• 同期エラーにより運用が止まる（新規作成・更新が進まない等）

なぜ起きる？「同期オブジェクトの削除伝搬」が途切れると“孤立（オーファン）”が残る

Entra IDで「オンプレ管理」と扱われるグループは、基本的にクラウド側がマスターではありません。削除も同様で、原則はオンプレ側で削除 → 同期が削除（deprovision）をクラウドへ反映という流れです。

ところが、何らかの理由で「削除」がExport（クラウド反映）まで届かないと、クラウド側には“オンプレ管理フラグを持ったまま存在する”グループが残り続けます。これが、いわゆる孤立（オーファン）オブジェクトの代表例です。

種類	マスター	ポータルで削除	よくあるトラブル
クラウドのみグループ	Entra ID	可能	削除後、復元期間（ソフト削除）に注意
オンプレ同期グループ（Azure AD Connect/Cloud Sync）	オンプレAD	原則不可	削除伝搬が止まると「オンプレ管理」のまま残留

作業前チェック：まず“どの方式で同期しているか”を確定する

解決ルートが分かれるので、最初に同期方式を押さえます。

確認項目	見る場所	判断
同期方式	Entra管理センターの同期（Cloud Sync）／サーバーのAzure AD Connect	Azure AD Connect か Cloud Sync かを確定
グループの影響範囲	グループ種別（セキュリティ／Microsoft 365）・割り当て	アプリ割り当て、ロール、条件付きアクセス参照の有無
削除が“保留”されていないか	Azure AD Connectの同期サービス（Operations）／プロビジョニングログ	Exportエラー、偶発的大量削除の防止で止まっていないか

解決の基本方針：まず同期で削除伝搬をやり直し、残るなら手動でクリーンアップ

実務でのおすすめ手順は次の順番です。いきなり“強制削除”に寄せると、同名/同IDの再出現や、参照関係の破損で別の事故が起きやすくなります。

1. 同期をフル（初期同期）で回して、削除が伝搬するか確認
2. それでも残る場合、孤立（オーファン）としてGraphで手動削除
3. 削除確認（監査ログ・ポータル）＋再同期で残骸チェック

手順：同期をフル実行して削除の再伝搬を試す（Azure AD Connect）

Azure AD Connect 環境では、まず同期サーバー上でフル同期（Initial）を回して「削除」イベントがクラウドへExportされるか確認します。エラーが出ていた場合でも、原因を解消した後にInitialを回すと消えるケースが多いです。

必要モジュール（同期/管理）

• ADSync（Azure AD Connect）：Start-ADSyncSyncCycle を使うため（同期サーバー上に存在）
• Microsoft Graph PowerShell SDK：後段の確認・手動削除で使用

フル同期の実行（同期サーバーで実施）

Azure AD Connect サーバーでPowerShellを起動し、以下を実行します。

Start-ADSyncSyncCycle -PolicyType Initial

補足として、通常運用ではDelta（差分）同期が多いですが、削除伝搬が怪しいときはInitialで「全体をなめる」ほうが復旧が早いことがあります。

# 参考：差分同期
Start-ADSyncSyncCycle -PolicyType Delta

Cloud Sync利用時の考え方

Cloud Syncの場合はサーバー上のStart-ADSyncSyncCycleではなく、Entra管理センターのCloud Syncから同期ジョブを再実行し、プロビジョニングログで削除が出ているか確認します。Cloud SyncはAzure AD Connectとログの見方が少し違うため、「削除が求められているのに反映されない」のか、「削除イベント自体が起きていない」のかを切り分けるのがコツです。

それでも消えないときに多い“同期側の引っ掛かり”

フル同期を回しても残る場合、削除がクラウドに届く前後のどこかで止まっている可能性が高いです。特に多いのが次の3つです。

詰まりポイント	症状	確認・対処の方向性
Export（クラウド反映）エラー	同期ジョブは走るが、削除が反映されない	Synchronization Service ManagerのOperationsでExport失敗を確認し、エラー原因（権限、競合、参照）を潰す
偶発的な大量削除の防止	削除が“保留”され、想定より残留が多い	しきい値で止まっていないかを確認（大規模変更直後に多い）。必要なら計画的に解除/調整
コネクタスペース残骸（不整合）	オンプレには無いのに、クラウド側でオンプレ管理のまま	コネクタスペース/メタバースの状態確認、再同期で整合。残るなら孤立として手動クリーンアップへ

ここまでで消えるなら、基本は「同期の削除伝搬が復旧した」状態です。以降の手動削除は不要です。

最終手段：孤立（オーファン）オブジェクトとしてGraphで手動削除する

オンプレ側に確実に存在せず、同期を回しても消えない場合は、クラウド側に残った孤立グループを手動で削除します。ここで役に立つのがMicrosoft Graph PowerShellです。

必要ロール・権限の目安

最小権限で済ませたい気持ちは分かりますが、削除周りは権限不足で詰まりやすいです。PIMを使っている場合は、作業前に必ず昇格してから実行します。

対象	必要になりやすい権限	備考
グループの削除	全体管理者 / グループ管理者 相当	テナントのポリシーにより差が出る
Graphの操作	Group.ReadWrite.All	初回は同意（Admin consent）が必要な場合あり

Microsoft Graph PowerShell SDKの準備

管理端末で実施する場合はインストール／更新します。

Install-Module Microsoft.Graph -Scope AllUsers
Update-Module Microsoft.Graph

Graphへ接続して対象グループを確認→削除

対象はグループID（GUID）が確実です。まず存在確認をしてから削除します。

# 必要な権限スコープでサインイン（同意が必要）
Connect-MgGraph -Scopes "Group.ReadWrite.All"

# 対象の存在確認（GUIDは実際のグループIDに置き換え）

Get-MgGroup -GroupId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

# 手動削除

Remove-MgGroup -GroupId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

# 後片付け（任意）

Disconnect-MgGraph

よくあるつまずきとして、Connect-MgGraphで要求したスコープの同意が完了していない、あるいはPIM昇格前に実行している、などで削除が失敗します。エラーが出たら、まず「権限」と「同意」を疑うのが近道です。

GUIDが分からないときの探し方（表示名から検索）

表示名（displayName）から絞り込みたい場合は、完全一致ならFilterが手堅いです。同名が多い環境は、結果が複数返る前提で慎重にIDを確認してください。

# 完全一致の例
Get-MgGroup -Filter "displayName eq 'Old-Group-Name'"

# 部分一致に寄せたい場合（環境によってはConsistencyLevel等が必要になることがあります）

Get-MgGroup -Search '"displayName:Old-Group-Name"' -ConsistencyLevel eventual -CountVariable c

「オンプレ管理」かどうかを属性で見分ける

ポータル表示だけでなく、Graphで属性を見ると切り分けが速くなります。代表的には次のような値がヒントになります。

属性（例）	意味合い	読み取りのコツ
onPremisesSyncEnabled	オンプレ同期対象として扱われているか	trueのままなら、クラウド単体での削除が拒否されることがある
onPremisesDomainName	同期元ドメイン情報	値が残っているのにオンプレに実体が無い場合は不整合の疑い
onPremisesLastSyncDateTime（相当）	最後に同期された時刻	極端に古い場合、削除伝搬の停止期間が長い可能性

取得するプロパティを明示して確認したい場合は、以下のように指定します（環境により取得可能なプロパティ名は差が出ます）。

Get-MgGroup -GroupId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" -Property "id,displayName,onPremisesSyncEnabled,onPremisesDomainName" | 
  Select-Object id,displayName,onPremisesSyncEnabled,onPremisesDomainName

削除後の確認：ポータルとログで「本当に消えたか」を必ず見る

削除コマンドが成功しても、運用上は「参照が残っていないか」「再同期で復活しないか」まで確認して完了です。

• Entra管理センターで対象グループが表示されないこと
• 監査ログ（Audit logs）で削除イベントが記録されていること
• 同期を再実行して、同じID/同じ表示名のグループが再出現しないこと

削除済み（ソフト削除）に残って邪魔をするケース

グループによっては、削除後に一定期間「削除済みアイテム」に残ります。再作成がブロックされたり、競合の引き金になる場合は、削除済み領域に残っていないかも確認します（誤って必要なものを消さないよう要注意）。

# 参考：削除済みディレクトリアイテムの検索（グループとして取得できる場合）
Get-MgDirectoryDeletedItemAsGroup -All

# 参考：削除済みアイテムの完全削除（ID指定）

Remove-MgDirectoryDeletedItem -DirectoryObjectId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

Graphで削除できない場合：エラー別の現実的な打ち手

「オーファンだからGraphで消せばOK」と行きたいところですが、環境によっては削除が拒否されることがあります。代表的なパターンと対処の考え方をまとめます。

状況/エラーの方向性	原因の見立て	優先する対処
「同期されているため削除できない」系	クラウド側が“同期オブジェクト”として強く扱っている	Azure AD Connect/Cloud Syncで削除伝搬を復旧（Exportエラー解消→再同期）
削除は成功するが、後で復活する	オンプレ側から再作成/再結合されている、または同等オブジェクトが再同期されている	同期スコープ・フィルタ・ルール、同名グループの自動生成、復元ジョブを点検
同名グループが作れない/競合する	削除済み（ソフト削除）に残ってブロック	削除済み領域の確認、必要に応じて完全削除（慎重に）

どうしても詰まるときの「最小リスク」な進め方

• まず同期側のエラーをゼロにする（Export失敗が残ったままだと、別の削除も詰まりやすい）
• 参照関係を外してから削除（アプリ割り当て、ロール割り当て、条件付きアクセス参照があると失敗要因になりやすい）
• Microsoft 365グループは影響範囲が大きい（Teams/SharePoint/Exchangeが連動するため、削除対象の見極めを厳しめに）

再発防止：孤立グループを作らない運用ポイント

「一度直して終わり」になりやすい問題ですが、しれっと再発します。特に大規模なOUフィルタ変更・同期ルール変更・ドメイン移行の直後は要注意です。

観点	おすすめ	理由
監視	同期エラーの定期チェック（Operations/プロビジョニングログ）	削除伝搬の停止は気づきにくいが、早期なら復旧が簡単
変更管理	OU/フィルタ変更前後で削除数の見積りを取る	偶発的大量削除の防止（しきい値）に引っ掛かりやすい
権限	PIMの昇格手順を手順書化	権限不足で復旧が長引くのが一番もったいない
復元手段	オンプレADの復元（AD Recycle Bin等）を整備	「削除が中途半端」な時に、正しく削除伝搬し直せる

よくある質問

ポータルで削除できないのに、Graphで削除できるのはなぜ？

ポータルの操作は“同期オブジェクトはオンプレで管理”という前提に強く縛られます。一方で、クラウド側に孤立した矛盾状態になっている場合、Graphによる削除が通ることがあります。ただし環境や状態によってはGraphでも拒否されるため、まずは同期側の削除伝搬を復旧するのが安全です。

対象がMicrosoft 365グループ（Teams連動）でも同じ手順でいい？

削除の入口は同じでも、影響範囲が大きい点が違います。Teams/SharePoint/Exchangeの関連リソースまで消えるため、参照・利用状況を確認したうえで実施してください。運用上は「削除ではなくアーカイブ」など別解が適切なケースもあります。

最短で直すなら結局どれ？

多くの現場での最短は次の流れです。

1. 同期サーバーでStart-ADSyncSyncCycle -PolicyType Initial（Cloud Syncならジョブ再実行）
2. 残る場合、Graphで存在確認→削除（Remove-MgGroup）
3. 監査ログ・ポータルで削除確認し、再同期で残骸がないことをチェック