Entra Domain Services（旧 Azure AD Domain Services）で同期されるユーザーが増えすぎると、検証環境や部門限定のドメイン運用では無駄が出ます。本記事では、同期スコープ設定をAPIで直接触れない前提で、スコープ付き同期とグループ運用でオンプレ属性ベースに対象を絞る実践手順を解説します。
結論：Entra Domain Services の同期対象は「スコープ付き同期」＋グループ運用で絞り込む
Entra Domain Services（以下、Entra DS）に同期されるユーザー数を減らしたい場合、まず押さえるべきポイントは「同期スコープ設定そのものを Microsoft Graph API などで直接変更する」発想を捨てることです。現実的には、Entra DS が提供するスコープ付き同期（Scoped synchronization）を Entra DS 側で有効化し、同期対象を特定のグループに限定します。その上で、オンプレミス AD の属性（部署、拡張属性、フラグ用カスタム属性など）を元に、グループのメンバーシップを自動更新していく設計が、運用面・監査面のバランスが取りやすい解決策です。
言い換えると、操作の中心は「Entra DS の設定」ではなく、同期対象グループに誰を入れるかです。グループはオンプレで管理して同期させてもよいですし、Entra ID 側で動的グループにしてもよいですし、Microsoft Graph API / PowerShell でメンバー追加・削除を自動化しても構いません。
なぜ「同期対象の制限」が重要なのか
Entra DS は、Azure 上にマネージドな Active Directory ドメインを提供するサービスです。オンプレ AD のようにドメイン参加・LDAP・Kerberos/NTLM を使える一方、ユーザーやグループの元データは Entra ID（旧 Azure AD）から同期されます。そのため、Entra ID 側に大量のユーザーがいるテナントで何も考えずに導入すると、次のような「想定外」が起きがちです。
- 検証・開発用途なのに全社ユーザーが同期される（管理・監査・トラブルシュートの対象が増える）
- 部門だけで運用したいのに不要なユーザーが見える（セキュリティポリシーや権限設計が複雑になる）
- 同期オブジェクトが増えて運用負荷が上がる（パスワード同期・アクセス制御・問い合わせ対応など）
- 段階導入がやりにくい（対象ユーザーを少しずつ増やして検証する、といった進め方が難しくなる）
同期対象を意図的に絞れると、「必要な人だけがドメイン認証できる」状態を作りやすくなります。これはゼロトラストの観点でも分かりやすいメリットです。
Entra DS の同期の流れを整理する（オンプレ属性で制御したい人ほど重要）
「オンプレ AD の属性で同期対象を決めたい」という要望が出る背景には、ID 情報の源泉がオンプレ AD にあるケースが多いからです。ここで混乱しやすいので、データの流れを簡単に整理します。
| レイヤー | 役割 | 代表的な制御点 |
|---|---|---|
| オンプレミス AD | 人事情報に近い属性（部署・役職・社員区分・フラグ属性など）を保持 | 属性の更新、オンプレグループ運用、スクリプト/IAM によるメンテ |
| Entra ID | クラウド ID の中心。アプリの認証・条件付きアクセス・グループなど | 動的グループ、Graph API によるグループ管理、プロビジョニング |
| Entra Domain Services | LDAP/Kerberos/NTLM を必要とするワークロード向けのマネージド AD | スコープ付き同期（どのグループのユーザーを同期するか） |
ポイントは、Entra DS は「オンプレ AD から直接」同期しているわけではなく、基本的に Entra ID を起点に同期する点です。したがって、オンプレ属性を基準にしたい場合でも、最終的にはEntra ID 上のグループメンバーシップという形に落とし込むのが分かりやすい、という結論になります。
スコープ付き同期の設計：実務で外さない考え方
スコープ付き同期を成功させるコツは、同期対象のグループを「ただのグループ」ではなく、運用の境界（スコープ境界）として扱うことです。おすすめは次の方針です。
- 同期対象グループは用途を限定して命名する（例：EntraDS-Users / EntraDS-Prod-Users など）
- メンバー追加条件を明文化する（部署、雇用形態、対象アプリ、端末要件など）
- 例外（必ず含めるユーザー）を用意する（管理者、運用アカウント、緊急アカウント）
- 削除（スコープ外）時の影響を先に合意する（ログオン不可、アクセス不可、問い合わせ導線など）
典型的な構成イメージ
| 要素 | 例 | 目的 |
|---|---|---|
| 同期対象グループ（スコープ境界） | EntraDS-Users | このグループに入っているユーザーだけが Entra DS に同期される |
| オンプレ属性（判定用） | department / extensionAttribute / カスタム属性 など | 「同期させたい人」を機械的に選別する |
| メンバー更新の仕組み | PowerShell / IAM / 動的グループ | 属性 → グループメンバーシップ を自動化する |
同期対象グループのメンバーを「オンプレ属性で」管理する3つの方法
「オンプレ属性が基準」という要件は、多くの場合グループメンバーの作り方の問題に分解できます。代表的な方法を3つに整理します。
| 方法 | どこで判定するか | 向いているケース | 注意点 |
|---|---|---|---|
| オンプレ AD グループを運用し、Entra ID に同期 | オンプレ AD | 既にオンプレ運用が整っている／クラウド側の自動化を増やしたくない | グループやメンバーが Entra ID に同期される前提（同期ルールの確認が必要） |
| Entra ID の動的グループ（属性ベース）を使う | Entra ID | オンプレ属性が Entra ID に同期されている／ルールで自動化したい | ライセンス要件や属性の同期遅延を考慮。ルール変更の影響が広い |
| Graph API / PowerShell でメンバーシップを同期 | スクリプト/IAM | 細かな例外や複雑条件がある／既存のワークフローに組み込みたい | 削除ロジックが事故りやすい。必ずテストとロールバック設計が必要 |
「API で同期スコープを操作したい」という発想は、実際には「同期対象グループのメンバーシップを API で操作する」に置き換えると要件を満たしやすくなります。
手順：Entra DS 側でスコープ付き同期を有効化する
まずは Entra DS 側で「スコープ付き同期」を有効化し、同期対象グループを指定します。ここは基本的にポータル操作になります（組織の変更管理の観点でも、まずは手動で一度確定させる運用が無難です）。
- 同期対象にしたいセキュリティグループを用意します（例：EntraDS-Users）。
- Entra Domain Services の管理ポータルを開き、Synchronization（同期） タブへ移動します。
- 同期モードを Scoped synchronization（スコープ付き同期） に切り替えます。
- 同期対象として、手順1で用意したグループを指定して保存します。
- 同期が完了するまで待ち、対象ユーザーがマネージド ドメイン側に作成されることを確認します（テスト用 VM へのドメイン参加や LDAP クエリで検証すると確実です）。
重要：スコープ付き同期に切り替えると、グループ外のユーザーは原則として Entra DS 側に同期されなくなります。既存環境で切り替える場合は「誰がログオンできなくなるか」「どのアプリが影響を受けるか」を事前に棚卸しし、段階的に移行するのが安全です。
APIでできること／できないことを整理する
多くの人がつまずくのがここです。結論から言うと、運用で狙うべきは「スコープ設定の API 化」ではなく「スコープ対象グループのメンバー管理の API 化」です。
| やりたいこと | 現実的な手段 | 補足 |
|---|---|---|
| Entra DS の同期スコープ設定（Scoped/All）を API で切り替えたい | 基本はポータルで設定し、運用では頻繁に切り替えない | 公開された専用 API が前提として示されていないケースが多く、変更管理上もリスクが大きい |
| 同期対象をオンプレ属性でコントロールしたい | 属性 → グループメンバーシップ の自動更新 | オンプレでグループ管理するか、クラウドで動的グループにするかを選ぶ |
| グループメンバーを API で追加・削除したい | Microsoft Graph API / Graph PowerShell で操作 | 最も現実的。削除ロジックだけは慎重に（誤削除の影響が大きい） |
Microsoft Graph で「同期対象グループのメンバー」を操作する考え方
Entra DS のスコープ付き同期が「グループに属しているかどうか」で同期対象を決める以上、グループメンバーシップを更新できれば、結果として同期対象を API 経由でコントロールできます。ここでは、実装の考え方と事故を減らすポイントを整理します。
安全なメンバー同期アルゴリズム（実装前に決める）
スクリプトの事故はほぼ「削除条件のミス」で起きます。特に、ドキュメントのサンプルスクリプトをそのまま本番で実行すると、意図しないユーザーがスコープ外になり、影響範囲が読めなくなることがあります。最低限、次のアルゴリズムにしておくと安全性が上がります。
- Desired（あるべきメンバー一覧）をオンプレ属性から計算する
- Current（現状のメンバー一覧）をグループから取得する
- Add = Desired – Current（不足分だけ追加）
- Remove = Current – Desired（余剰分だけ削除）
- ただし Remove は「例外アカウント」「手動維持アカウント」を必ず除外する
- 最初は Remove を実行せず、差分レポートだけ出して検証する
「サンプルが危ない」場面でよくあるミス
| ミスの種類 | 起きがちな原因 | 回避策 |
|---|---|---|
| 差分計算の方向が逆 | Current と Desired の引き算を逆にしてしまい、必要な人を Remove に入れてしまう | ADD/REMOVE の候補を必ずレポート出力し、テストで目視確認してから適用 |
| 変数名の取り違え | 取得したユーザー一覧とグループ一覧を混同し、別の配列を削除対象にしてしまう | 変数名を「desiredUsers/currentUsers」など意味が明確な名前に固定し、ログに値を残す |
| 例外ユーザーの未考慮 | 管理者や運用アカウントが属性条件を満たさず Remove される | 除外リスト（必ず残す UPN / objectId）を別管理し、Remove 前に必ずフィルタ |
| 削除を最初から自動化 | 初回運用でいきなり Remove を有効化し、誤削除の影響が顕在化 | 導入初期は「追加のみ」＋「削除候補レポート」で運用を成熟させる |
Graph REST API のイメージ（概念レベル）
Graph API では、グループにユーザーを追加する操作は「メンバー参照を追加する」形になります。実際のエンドポイントや権限は利用形態（委任/アプリケーション）で変わるため、ここでは処理の形を掴むための例として示します。
POST https://graph.microsoft.com/v1.0/groups/{group-id}/members/$ref
Content-Type: application/json
{
"@odata.id": "[https://graph.microsoft.com/v1.0/directoryObjects/{user-id}](https://graph.microsoft.com/v1.0/directoryObjects/{user-id})"
}削除は、対象メンバーの参照を削除する操作になります。
DELETE https://graph.microsoft.com/v1.0/groups/{group-id}/members/{user-id}/$ref実務のコツ：追加は比較的安全ですが、削除は必ず「差分確認」「除外リスト」「段階適用」をセットにしてください。運用・監査の観点では「いつ、誰が、なぜ削除されたか」を追跡できるログ設計も重要です。
Graph に与える権限は最小化する
グループメンバー更新は影響が大きいため、アプリ登録や自動化基盤（Azure Automation / Functions など）を使う場合は、権限を広くしすぎない設計が重要です。概念としては次の考え方が安全です。
- 対象グループを限定できるなら、テナント全体の書き換え権限ではなく、グループ運用に必要な範囲に絞る
- 読み取り（User/Group Read）と書き込み（Group Member Write）を分離できるなら分離する
- 「誰が実行したか（実行主体）」と「何を変更したか（差分）」が追えるログを残す
Graph PowerShell での操作例（テスト向け）
PowerShell で試したい場合は、Microsoft Graph PowerShell SDK を使うと分かりやすいです。次は概念例です（権限付与や認証方法は環境に合わせて設計してください）。
# 例：対話ログイン（検証用途）
Connect-MgGraph -Scopes "Group.ReadWrite.All","User.Read.All"
# 同期対象グループ
$groupId = "00000000-0000-0000-0000-000000000000"
# 追加したいユーザー（オブジェクトID）
$userId = "11111111-1111-1111-1111-111111111111"
# メンバー追加
New-MgGroupMemberByRef -GroupId $groupId -BodyParameter @{
"@odata.id" = "[https://graph.microsoft.com/v1.0/directoryObjects/$userId](https://graph.microsoft.com/v1.0/directoryObjects/$userId)"
}削除は次のようなイメージになります（実行前に必ず対象を確認してください）。
# メンバー削除（要確認）
Remove-MgGroupMemberByRef -GroupId $groupId -DirectoryObjectId $userIdオンプレ属性からメンバーを決める具体例：PowerShell で「差分」運用する
ここでは、オンプレ AD の属性（例：extensionAttribute1 に AADDS が入っているユーザー）を基準に、同期対象グループへ追加する設計例を紹介します。ポイントはいきなり削除しないことです。
例：オンプレで対象ユーザーを抽出
# ActiveDirectory モジュールが必要
Import-Module ActiveDirectory
# 例：extensionAttribute1 が "AADDS" のユーザーを対象とする
$desiredUsers = Get-ADUser -LDAPFilter "(extensionAttribute1=AADDS)" -Properties extensionAttribute1 |
Where-Object { $_.Enabled -eq $true } |
Select-Object -ExpandProperty UserPrincipalNameこの時点で、対象ユーザーが意図通りかを必ず確認します。部署や雇用形態など複数条件にしたい場合は、ここで絞り込みロジックを作ります（例：department=Sales かつ extensionAttribute1=AADDS）。
例：グループの現状メンバーと比較し、まずは追加だけ行う
# 例：Graph 側の現在メンバーを取得（概念例）
# 実際には Get-MgGroupMember で objectId を取り、UPN と突合するなど環境に合わせる
$currentUsers = @() # ここに現状メンバーの UPN 一覧が入る想定
# 不足分だけ追加
$toAdd = $desiredUsers | Where-Object { $_ -notin $currentUsers }
# 削除は一旦やらず、レポートだけ出す
$toRemove = $currentUsers | Where-Object { $_ -notin $desiredUsers }
$toAdd | ForEach-Object { "ADD: $($*)" }
$toRemove | ForEach-Object { "REMOVE候補: $($*)" }削除が必要になった段階で、例外リスト（必ず残すユーザー）を入れたうえで、段階的に実施します。サンプルスクリプトにロジックミスが入りやすいのはまさにこの部分なので、条件式・変数名・比較方向を一つずつ検証してください。
動的グループを使うと「オンプレ属性ベース」をよりシンプルにできることがある
オンプレ属性を Entra ID に同期できている場合は、Entra ID の動的グループ（Dynamic membership）で同期対象グループを自動運用できる可能性があります。運用がハマると、スクリプトの保守や誤削除リスクを大幅に下げられます。
動的グループのルール例
例えば「extensionAttribute1 が AADDS のユーザーだけ」を対象にするなら、次のようなルールの考え方になります（属性名はテナントの設計により変わるため、管理画面で実際に選べるプロパティを確認してください）。
(user.extensionAttribute1 -eq "AADDS") and (user.accountEnabled -eq true)動的グループ運用のメリット／デメリット
| 観点 | メリット | デメリット |
|---|---|---|
| 自動化 | スクリプト不要。属性が変われば自動でメンバーが更新される | ルール変更の影響が大きく、変更管理が必須 |
| 安全性 | 差分計算や削除処理の実装ミスが減る | 属性の誤更新がそのままスコープ外につながる（属性運用の品質が重要） |
| 要件 | クラウド側で完結する | ライセンス要件や、属性が Entra ID に同期される前提がある |
運用で必ず押さえたい注意点（落とし穴まとめ）
スコープ付き同期は強力ですが、「同期されない」こと自体がシステム障害の原因になります。導入前に次の観点をチェックしてください。
管理者・運用アカウントをスコープから漏らさない
- Entra DS の管理に必要なアカウントは、同期対象グループに必ず含める
- 緊急時のブレークグラス用アカウントを別途用意し、除外されないようにする
- 「部署属性が変わったら運用者が外れる」といった事故が起きないよう、例外ルールを作る
パスワード・認証の前提を確認する
- Entra DS では、同期されたユーザーがドメイン認証できるように、パスワードハッシュの同期や更新が前提になる
- 対象ユーザーの追加直後は、反映までタイムラグがある。切り替え直後に「ログオンできない」が出やすい
- 運用上は「いつから利用可能になるか」の目安と、切り戻し手順を用意する
スコープ外のユーザー・グループに依存した ACL を避ける
- ファイルサーバーやアプリが「特定グループ」や「ユーザーの存在」を前提にする場合、スコープ外になると障害に直結する
- まずは「このマネージド ドメインが面倒を見る利用者の集合」を明確にし、境界を越える依存を減らす
変更は段階的に：いきなり本番全体をスコープ化しない
- 最初は小さなグループで検証し、対象ユーザーを段階的に増やす
- スクリプト運用の場合は、追加のみ→差分レポート→削除適用の順に成熟させる
- 運用監査のために「メンバー変更の証跡（ログ）」を残す
よくある質問
同期対象グループから外すと、Entra DS 側ではどう見える？
基本的には「同期対象外」として扱われるため、ログオンできなくなったり、LDAP で見えなくなったりといった影響が出ます。どのタイミングで反映されるか、既存オブジェクトがどう扱われるかは環境や状態により差が出るため、切り替え前にテスト環境で「外した瞬間に何が起きるか」を確認してください。
オンプレ属性ベースの制御は、Entra Connect（旧 Azure AD Connect）側でやるべき？
「Entra ID にも同期したくない」という要求なら、Entra Connect 側のフィルタリング（OU フィルタやグループ フィルタなど）でそもそものクラウド同期範囲を絞る設計が有効です。一方、「Entra ID には必要だが、Entra DS にだけは同期したくない」なら、本記事のように Entra DS 側のスコープ付き同期で制御するのが分かりやすいです。
複数条件（部署＋フラグなど）で対象を選びたいときは？
おすすめは「条件をすべて満たしたユーザーだけが入る“同期対象グループ”」を1つ作り、そのグループをスコープとして指定することです。条件は、動的グループのルールに書くか、スクリプトで Desired を計算するか、オンプレ側の運用ルールで担保します。スコープ自体を頻繁に切り替えるより、グループ運用で完結させたほうが安定します。
スクリプトのサンプルをそのまま使っても大丈夫？
サンプルはあくまで参考実装です。特に「削除処理」「変数の扱い」「例外ユーザーの除外」などは、環境依存のミスが起きやすいポイントです。必ずテスト環境で差分が意図通りかを検証し、いきなり削除まで自動化しない運用（レポート→承認→適用）から始めるのが安全です。
まとめ：APIで“スコープ設定”をいじるより、グループ運用を設計する
Entra Domain Services（Azure AD Domain Services / AADDS）の同期対象を制限したい場合、王道はスコープ付き同期を使い、同期対象を特定グループに限定することです。オンプレ属性でコントロールしたいなら、属性の値をもとにそのグループのメンバーを更新する仕組みを作れば、結果として「APIで同期対象を制御している」のと同じ状態を実現できます。
最初にやるべきことは、対象ユーザーの条件を決め、同期対象グループをスコープ境界として運用設計を固めることです。動的グループでシンプルにするのか、スクリプト/IAMで柔軟にするのかを選び、誤削除を避ける差分運用と段階導入を徹底すれば、Entra DS を安全に小さく始めて大きく育てられます。
コメント