オンプレミス Active Directory（AD）の独自属性 xyz を、Microsoft Entra ID の既定属性 state（都道府県など所在地）に反映したい――その設計と実装を、運用でつまずきやすい「優先度（Precedence）」や「競合回避」を含め、実務目線で詳解します。既定ルールは変更せず、追加のカスタム同期ルールだけで安全に実現します。
前提とゴールの整理
目標は、オンプレ AD のユーザー属性 xyz を Microsoft Entra ID の state に同期することです。ここでは Microsoft Entra Connect Sync（旧 Azure AD Connect）を前提に、以下の条件を満たす構成を解説します。
- 既定の同期ルールは編集しない（製品アップデートの影響を回避）。
- 必要最小限のカスタム同期ルールを追加して実現。
- 既存の
st→stateの既定フローと共存（xyz が空なら従来どおりstを採用）。 - ロールバックと検証が容易。
メタバースと優先度（Precedence）を正しく理解する
Entra Connect Sync は、各コネクタ（AD・Entra ID など）から取り込んだ属性を「メタバース（MV）」に集約し、そこから宛先へ流します。属性には「複数の同期ルール」が寄与できますが、より小さい番号の Precedence が優先され、最初に値（Null 以外）を出したルールが勝つのが基本挙動です。したがって、
- 「既定フローを上書きしたい」＝既定より低い番号を付けた独自ルールを作る。
- 「値がなければ既定にフォールバックしたい」＝式で Null を返す（空なら不寄与とみなされ、次の寄与者＝既定ルールが採用される）。
実装パターンの選び方
要件は 2 通りのパターンで満たせます。運用の好みに合わせて選んでください。
| パターン | 概要 | カスタムルール数 | 既定ルールの変更 | 競合リスク | ロールバック容易性 | おすすめ度 |
|---|---|---|---|---|---|---|
| A（推奨）：Inbound 1 本のみ | AD xyz → MV st を条件付きで寄与。Outbound は既定 st → Entra state を利用。 | 1 | なし（追加のみ） | 低い（式で空なら不寄与） | 簡単（ルール無効化で即復旧） | ◎ |
| B：Inbound + Outbound 2 本 | AD xyz → MV の未使用属性（例 extensionAttribute15）。さらに MV → Entra state を条件付きで寄与。 | 2 | なし（追加のみ） | 中（MV 拡張属性の利用状況に注意） | 簡単（どちらか停止で切替） | ○（MV の st に触れたくない場合） |
どちらのパターンでも「Outbound だけ追加」では値が MV に存在しないため同期されません。少なくとも Inbound で MV に値を載せる必要があります。
事前チェック（ゼロダウンで安全に）
| 項目 | 確認内容 | 補足 |
|---|---|---|
| 権限 | Sync Rules Editor 実行権限、同期サーバーの管理権限 | 本番サーバーで作業します。 |
| 属性スキーマ | AD スキーマに xyz が存在し、コネクタで参照可能 | 未表示の場合は「Refresh Schema」を実行。 |
| 既存利用 | MV の st／拡張属性の既存フロー有無 | 二重寄与を避けるため事前棚卸し。 |
| テスト計画 | 対象 OU／ユーザー、ロールバック手順 | 可能なら Staging Mode や検証環境で先行試験。 |
パターン A（推奨）：Inbound 1 本で完結させる手順
0）スキーマの更新
- 同期サーバーで「Synchronization Service」を起動。
- 左ペイン「Connectors」→ AD DS コネクタを右クリック → Refresh Schema。
- 完了後、Sync Rules Editor を起動して
xyzが選択できることを確認。
1）Inbound カスタムルールの作成（AD → MV）
Sync Rules Editor → Add new rule から次のとおり設定します。
| フィールド | 設定値（例） | 説明 |
|---|---|---|
| Name | In from AD – User xyz to st (Custom) | 判別しやすい命名に。 |
| Connected System | 対象の AD DS コネクタ | ドメインを選択。 |
| Connected System Object Type | user | ユーザーのみを対象。 |
| Metaverse Object Type | person | 既定どおり。 |
| Link Type | Join | 既存 MV オブジェクトへ結合。 |
| Precedence | 既定の「In from AD – User Common」などの st 寄与ルールより小さい値 | 例：既定が 100 なら 50。小さいほど優先。 |
| Scoping filter | 任意（OU 条件や xyz IsPresent） | 段階導入するなら OU で限定。 |
| Transformations | FlowType: Expression Target: stExpression: IIF(IsNullOrEmpty(Trim([xyz])), NULL, Trim([xyz])) | xyz が空なら Null（不寄与）。既定の st→st がフォールバックで有効化。 |
この 1 本だけで、MV の st に xyz が入るときは本ルールが勝ち、空のときは既定の Inbound が採用されます。Outbound は既定の st → Entra state が働くため、追加は不要です。
2）同期の実行
PowerShell
# 初回はフル（スキーマ更新や新規ルール導入時）
Start-ADSyncSyncCycle -PolicyType Initial
# 以降は差分
Start-ADSyncSyncCycle -PolicyType Delta </code></pre>
<h3>3）結果の確認</h3>
<ul>
<li>ポータル：ユーザーの <strong>State</strong> を確認。</li>
<li>PowerShell（Microsoft Graph 推奨）：
<pre><code>PowerShell
# 任意のユーザーを確認
Get-MgUser -UserId [email protected] | Select-Object DisplayName, State
「Synchronization Service」→ Metaverse Search で MV の st を確認。
パターン B：Inbound + Outbound 2 本で分離する手順
MV の st を触らずに、新規の MV 属性（例：extensionAttribute15）を中継してから Entra state に寄与する方法です。既存フローに手を触れたくない運用で有効です。
1）Inbound カスタムルール（AD → MV）
| フィールド | 設定値（例） | 説明 |
|---|---|---|
| Name | In from AD – User xyz to ext15 (Custom) | |
| Direction | Inbound | |
| Target (MV Attribute) | extensionAttribute15（未使用の拡張属性） | 空き属性を選定。既存利用があれば別番号へ。 |
| FlowType | Direct または Expression | 整形が不要なら Direct、必要なら Expression で Trim([xyz]) など。 |
| Scoping filter | xyz IsPresent など任意 | 限定導入が可能。 |
2）Outbound カスタムルール（MV → Entra）
| フィールド | 設定値（例） | 説明 |
|---|---|---|
| Name | Out to Entra – User ext15 to state (Custom) | |
| Connected System | Microsoft Entra ID | |
| Direction | Outbound | |
| Precedence | 既定の st→state ルールより小さい値 | 小さいほど優先。式で空なら不寄与 → 既定が採用。 |
| Transformations | Target: stateFlowType: Expression Expression: IIF(IsNullOrEmpty(Trim([extensionAttribute15])), NULL, Trim([extensionAttribute15])) | 空で Null を返し、既定 st→state にフォールバック。 |
3）同期と確認
パターン A と同じく Start-ADSyncSyncCycle を実行し、ポータル・Graph・Metaverse Search で結果を確認します。
既定フローと共存させるコツ（式の作り方）
次の 3 点が肝です。
- Precedence は既定より小さく（先に評価させる）。
- 空なら Null を返す式で「不寄与」にする。
- 必要に応じて整形（Trim/ToUpper/Replace）をかける。
| 目的 | サンプル式 | 解説 |
|---|---|---|
| 空なら既定にフォールバック | IIF(IsNullOrEmpty(Trim([xyz])), NULL, Trim([xyz])) | 空や空白のみは Null（不寄与）。 |
| 全角/半角スペース除去 | Replace(Replace([xyz], " ", ""), " ", "") | 必要に応じて併用。 |
| 文字数制限（例：最大 128 文字） | IIF(Len([xyz]) > 128, Left([xyz],128), [xyz]) | 過長データの輸出エラー回避。 |
| 大文字化 | ToUpper(Trim([xyz])) | 統一表記に。 |
検証のベストプラクティス
- Preview 機能（Synchronization Service → AD コネクタ → 対象ユーザー → Preview）で、Inbound/Outbound の寄与元・寄与結果を可視化。
- Metaverse Search で
stないし中継属性の値を直接確認。 - Entra 側コネクタの Export で pending export の差分をレビューしてから同期。
- 本番前に、対象 OU を限定するスコーピングや、Staging Mode の別サーバーでドライランを実施。
トラブルシューティング
| 症状 | 原因の当たり | 対処 |
|---|---|---|
Entra の state が更新されない | MV に値がない／Outbound が不寄与／既定ルールが先勝ち | MV の値を確認。カスタムルールの Precedence を既定より小さくし、式で空時 Null を返す。 |
| 一部ユーザーだけ反映されない | xyz が空／スコーピング条件から漏れ | 対象ユーザーの AD 属性を実データで確認。OU やフィルタを見直し。 |
| エクスポートエラー（過長・不正文字） | 値の整形不足 | Len/Left/Replace/Trim で前処理。無効文字は Replace。 |
既定の st に戻ってしまう | カスタム Outbound の Precedence が既定より大きい | 小さい番号に変更（先に評価）。空時 Null を返して既定に委ねる。 |
Sync Rules Editor に xyz が表示されない | コネクタスキーマ未更新 | 「Refresh Schema」を実行後に再確認。 |
データ品質と正規化のヒント（都道府県の統一）
state は表示項目です。ユーザー入力にばらつきがある場合、最低限の正規化を式で行うと保守が楽になります。
| 要件 | 式の例 | 説明 |
|---|---|---|
| 語尾の「県」「府」「都」「道」を除去 | Replace(Replace(Replace(Replace([xyz],"県",""),"府",""),"都",""),"道","") | 必要に応じて。 |
| 全角・半角のゆらぎ吸収 | Trim(Replace(Replace([xyz]," "," "), " "," ")) | 二重スペースを 1 つに。 |
| コードから名称へ（簡易置換） | IIF([xyz]="13","東京", IIF([xyz]="27","大阪",[xyz])) | 本格的なマスタは HR など upstream を推奨。 |
運用・変更管理（安全なロールバック）
- ルール名・作成者・目的・チケット番号を Description に明記。
- 本番導入は就業時間外に初回 Initial を実行してハレーションを抑制。
- 問題発生時はルールの Enabled をオフ（または削除）→ Delta 同期 → 既定フローへ即時復帰。
よくある質問（FAQ）
既存ルールを「編集」せずに本当に実現できますか？
はい。ここで紹介したとおり、既定ルールは一切編集せず、追加のカスタムルールのみで実現できます。Precedence と式（空時 Null）で既定フローと共存します。
Outbound だけ作れば良いのでは？
いいえ。MV に値が存在しなければ Outbound ルールは寄与できません。必ず Inbound で MV に値を載せる必要があります。パターン A では Inbound 1 本のみで完結、パターン B では Inbound + Outbound の 2 本で分離します。
どの Precedence 数値にすべきですか？
環境により既定ルールの番号が異なるため、対象属性（st または state）に寄与する既定ルールの番号を確認し、それより小さい番号を設定してください。小さいほど優先されます。
Cloud Sync（エージェント方式）を使っています。対応できますか？
可能です。ただし Cloud Sync はポータル側でマッピングと式を定義します（ここでは Connect Sync を前提に解説）。同等の発想（空時 Null、既定へのフォールバック、優先順）で組めば再現できます。
実装サマリー（最短手順）
| 手順 | 作業 | ポイント |
|---|---|---|
| 1 | スキーマ更新（Refresh Schema） | xyz をコネクタに認識させる。 |
| 2 | （A）Inbound 1 本を作成し xyz → MV st | Precedence は既定より小さく、式は空時 Null。 |
| （代替） | （B）Inbound（xyz → MV 拡張属性）+ Outbound（拡張属性 → state） | Outbound も既定より小さい Precedence + 空時 Null。 |
| 3 | Initial → Delta 同期 | 初回は Initial を推奨。 |
| 4 | Metaverse/Preview/Graph で検証 | 寄与元・最終値を三面チェック。 |
具体例：式テンプレート（コピペ可）
パターン A（Inbound）
IIF(IsNullOrEmpty(Trim([xyz])), NULL, Left(Trim([xyz]), 128))空・空白は不寄与、過長は 128 文字に丸めて MV st へ。
パターン B（Outbound）
IIF(IsNullOrEmpty(Trim([extensionAttribute15])), NULL, Left(Trim([extensionAttribute15]), 128))MV の拡張属性が空なら不寄与→既定 st→state が採用。
チェックリスト（導入前後）
- スキーマ更新済みで
xyzが選択可能。 - カスタムルールは Enabled、Precedence は既定より小さい。
- スコーピング（OU や IsPresent）で段階導入。
- Preview で「寄与元＝カスタム」「空時＝既定」が確認できる。
- Export 差分をレビューし想定どおりの件数。
- ロールバック手順（無効化 → Delta）が確立。
まとめ
オンプレ AD の xyz を Entra ID の state に同期する最短の道は、「空なら Null」「既定より小さい Precedence」という 2 点を守ることです。よりシンプルに済ませるなら Inbound 1 本（パターン A）、既存の MV st に触れたくない運用なら Inbound + Outbound（パターン B） を選びましょう。いずれも既定ルールは編集不要、追加のみで安全に共存できます。初回は Initial、以後は Delta の通常運転に戻し、Metaverse/Preview/Graph の三点確認で運用の品質を確保してください。
コメント