Microsoft Entra ID（旧Azure AD）の動的グループを「Cost center」で自動化したいのに、ユーザープロファイルの「Employee org data」がルールで参照できず詰まることがあります。この記事では、現時点の仕様上の制約を整理しつつ、拡張属性に値をコピーして動的グループ化する現実的な実装パターンをまとめます。
Microsoft Entra IDでEmployee org dataのCost centerを動的グループ条件にできるか
結論から言うと、現時点のMicrosoft Entra IDの動的メンバーシップルールでは、Employee org dataの「Cost center」を直接参照できません。Microsoft Q&Aでも「employeeOrgData（Cost centerなど）は動的グループルールから参照できない」と明確に案内されています。
そのため、次のようなルールはルールとして成立しない（またはメンバーが期待どおりに入らない）ケースが一般的です。
user.employeeOrgData.costCenter -eq "100"user.costCenter -eq "100"「Cost centerの値はHRISからEmployee org dataに同期されているのに、なぜ…？」となりがちですが、動的グループは参照できる属性が明確に限定されています。employeeOrgDataのようなフィールドは、その対象に入っていません。
そもそもEmployee org dataとは何か
Microsoft Graph上では、Employee org dataはユーザーの組織データを表すリソースで、costCenter と division を持ちます。ここで重要なのは、Graphの仕様としてemployeeOrgDataは$selectで明示した場合にのみ返る点です（「見えない」「nullになる」と感じる原因がここにあることもあります）。
Graphでの確認例（employeeOrgDataを明示して取得）:
GET https://graph.microsoft.com/v1.0/users/{id}?$select=id,displayName,employeeOrgDataemployeeOrgDataのプロパティとして、costCenterは「Returned only on $select. Supports $filter」とされており、Graph API上はフィルタも可能です。ただし、Graphで$filterできることと、動的グループのルールで使えることは別で、動的グループ側の「サポート属性一覧」に含まれない限りルール条件にはできません。
動的グループで使える属性は公式ドキュメントの一覧に限られる
Microsoft Entra IDの動的メンバーシップルールは、Boolean / dateTime / string / string collection などの型ごとにサポートされるユーザー属性が一覧で定義されています。例えば department、companyName、employeeId、userPrincipalName などは載っていますが、employeeOrgData や costCenter はここに出てきません。
この「サポート属性一覧に載っていない＝ルールで参照できない」というのが、今回の根本原因です。
実務的な解決策はCost centerを使える属性にコピーすること
現場での落としどころはシンプルで、Cost centerの値を、動的グループで参照できる別の属性へコピーして条件にすることです。Microsoft側も「ワークアラウンドはカスタム属性（拡張属性）を作ってそこに値を入れること」と案内しています。
代表的なコピー先は次の3パターンです。
| コピー先 | 動的グループでの利用 | 向いている環境 | 特徴 |
|---|---|---|---|
| extensionAttribute1〜15 | 可能 | クラウドのみ / ハイブリッド両方 | 最短で実装しやすいが枠は15個 |
| カスタム拡張プロパティ（directory extension） | 可能 | クラウドのみ / ハイブリッド両方 | 属性名を用途別に増やしやすい（app IDが名前に入る） |
| Entra ConnectのDirectory extensions | 可能 | オンプレAD連携あり | 同期の仕組みに組み込みやすい（Tenant Schema Extension Appが作られる） |
この中で「まず動かす」ならextensionAttributeを優先し、属性の増加や命名の分かりやすさが必要ならカスタム拡張プロパティへ、オンプレ起点で管理したいならEntra ConnectのDirectory extensionsに寄せる、という判断がしやすいです。
パターン1：extensionAttributeで最短実装する
動的グループのルールでは、extensionAttribute1〜15が文字列プロパティとしてサポートされています。ドキュメントでも「ExtensionAttribute<X>（1〜15）」形式で使えること、例として user.extensionAttribute15 が示されています。
手順の流れ
- どのextensionAttributeを使うか決める（既存用途と衝突しない番号を選ぶ）
- Cost centerの値をextensionAttributeへ書き込む（HRIS同期、Entra Connect、Graph、スクリプトなど）
- 動的グループのルールでextensionAttributeを参照する
動的グループルール例
社員アカウントに限定し、無効化アカウントも除外しつつ、Cost centerが100のユーザーを集める例です。
(user.userType -eq "Member") -and (user.accountEnabled -eq true) -and (user.extensionAttribute1 -eq "100")Boolean属性のaccountEnabledは true/false が想定され、サポート属性として記載されています。
複数コストセンターをまとめたい場合
「100、200、300のいずれか」といった条件なら、-in演算子が便利です。
user.extensionAttribute1 -in ["100","200","300"]-in演算子の使い方は公式ドキュメントで案内されています。
GraphでextensionAttributeに値を書き込む例
Microsoft Graphの拡張性ドキュメントでは、ユーザーに対して onPremisesExtensionAttributes の extensionAttribute1 などへ PATCH で値を入れる例が示されています。Cost centerのコピー処理を自動化するときの基本形になります。
PATCH https://graph.microsoft.com/v1.0/users/{id}
{
"onPremisesExtensionAttributes": {
"extensionAttribute1": "100"
}
}extensionAttributeは便利ですが、名前が汎用的で「何を入れている枠なのか」が運用で迷子になりやすいので、社内で用途を明文化しておくのがおすすめです（例：extensionAttribute1＝CostCenter、extensionAttribute2＝雇用区分 など）。
パターン2：カスタム拡張プロパティでCostCenter専用の項目を作る
「extensionAttributeの枠を汚したくない」「CostCenterという名前で保持したい」「将来、拡張項目が増える」なら、カスタム拡張プロパティ（directory extension / custom extension properties）が向いています。動的メンバーシップルールは、カスタム拡張プロパティを文字列としてサポートしており、プロパティ名は user.extension_[GUID]_[Attribute] 形式になります。
さらに、Entra管理センターのルール作成画面では、Get custom extension properties からアプリIDを入力して利用できるカスタム拡張プロパティ一覧を取得できることが案内されています。つまり「正しい属性名が分からない」問題をUIで解消しやすい設計です。
動的グループルール例
プロパティ名はテナント（アプリ）ごとに変わるため、ここでは例として書きます。
(user.extension_c272a57b722d4eb29bfe327874ae79cb_CostCenter -eq "100")この形式は公式ドキュメントに例があり、GUID部分は「その属性を作ったアプリのIDからハイフンを除いたもの」と説明されています。
属性名を正確に把握するコツ
- 動的グループのルールビルダーで Get custom extension properties を使う
- Graph Explorerでユーザーを取得し、AdditionalPropertiesの中から extension_〜 を探す
ドキュメントでも、Graph Explorerでユーザーのプロパティをクエリしてカスタムプロパティ名を見つけられるとされています。
パターン3：Entra ConnectのDirectory extensionsで同期して使う
オンプレADと同期している環境なら、Microsoft Entra ConnectのDirectory extensionsを使って、オンプレ側の属性や独自属性をEntra IDに公開し、その拡張属性を動的グループで参照できます。公式ドキュメントでも「動的グループメンバーシップで使える」と明記されています。
この方式のポイントは、Entra Connectが内部的に Tenant Schema Extension App というアプリを作り、拡張属性が extension_{ApplicationId}_{attributeName} 形式で現れることです。ドキュメントには、Graphでの取得例や動的グループルール例まで載っています。
動的グループルール例（ドキュメントの例）:
(user.extension_9d98ed114c4840d298fad781915f27e4_division -eq "Sales and marketing")自社のCost center用に directory extension を用意した場合も、基本的な参照の形は同じです。
設計の要点：HRISから動的グループまでのデータの流れを整える
「Employee org dataに入っているCost centerを、動的グループ用の属性へコピーする」だけなら簡単に見えますが、運用を安定させるにはどこでコピーするかが重要です。
| コピーの実行ポイント | メリット | 注意点 |
|---|---|---|
| HRIS→Entra IDのプロビジョニング時に直接書く | 遅延が少なく、二重管理になりにくい | 連携コネクタの柔軟性が必要 |
| Entra Connect（オンプレ属性→拡張属性）で同期する | オンプレ起点で統制しやすい | 同期設計・変更管理が必要 |
| Graphの定期ジョブでコピーする | 既存連携を変えずに追加できる | 遅延・失敗時のリトライ・監視が必要 |
なお、employeeOrgDataをGraphで更新する場合は「更新時に両方のプロパティ値を含めないと、未指定の方がnullになる」とドキュメントに明記されています。Cost centerだけ更新してdivisionを消してしまう事故が起きやすいので、もしemployeeOrgData側を触る処理を書くならこの挙動は必ず押さえてください。
動的グループ運用で押さえるべきポイント
ライセンス要件
動的メンバーシップグループの利用には、Microsoft Entra ID P1（またはIntune for Education）ライセンス要件があります。ドキュメントでは「動的グループのメンバーとなるユニークユーザー数をカバーするだけのライセンスが必要」と説明されています。
ルールビルダーの制約と編集方法
管理センターのルールビルダーは、最大5つの式までの作成を支援します。より複雑な条件はテキストボックスで直接編集する前提です。また、カスタム拡張プロパティは「Get custom extension properties」から取得できると案内されています。
メンバー反映の遅延と状態確認
動的グループは「属性が変わるたびに全ルールが評価され、条件に合えば追加・外れれば削除」という仕組みで、手動での追加・削除はできません。処理ステータスとして Evaluating / Processing / Update complete / Processing error / Update paused などが表示され、管理者は一時停止と再開もできます。メンバーが増えないときは、まずこのステータスとエラーを確認するのが最短ルートです。
性能面でのルール設計
ドキュメントには「MatchやContainsの多用を最小化する」旨の注意もあります。Cost centerのようにコードが固定であれば、-containsより-eq（完全一致）や-in（集合）に寄せた方が運用上もトラブルが少なくなります。
よくあるつまずきと切り分けチェック
| 症状 | よくある原因 | 対処 |
|---|---|---|
| employeeOrgDataでルールを書いてもメンバーが入らない | employeeOrgDataは動的グループのサポート属性ではない | 拡張属性へ値をコピーして参照する |
| employeeOrgDataがGraphでnullに見える | $selectしていないため返っていない | $select=employeeOrgData を付けて取得する |
| カスタム拡張プロパティ名が分からない | app ID由来の名前になるため推測しづらい | Get custom extension propertiesで一覧取得、Graph Explorerで確認 |
| 値は入っているのに反映されない | 動的グループの評価待ち、または処理エラー | Processing statusを確認し、必要なら一時停止→再開で再評価 |
| Cost centerを拡張属性に入れるのが不安 | 拡張機能は機密情報格納向けではない | 機密情報は避け、必要なら別アプローチを検討 |
拡張機能に関しては、Microsoft Graphの拡張性ドキュメントでも「機密性の高い個人情報をextensionsに保存しない」旨が明記されています。Cost center自体は一般に機密度は高くないことが多いものの、社内ポリシー的に慎重に扱うべき属性なら、格納先や閲覧権限の設計を先に固めてください。
似た機能の注意点：Open extensionsとCustom security attributes
「拡張できるなら何でも動的グループに使えるのでは？」と思われがちですが、そうではありません。
- Open extensions：Microsoft Graphのドキュメント上「強い型付けがなく、discoverableでもfilterableでもない」とされています。動的グループの条件はサポート属性に限られるため、open extensionsを条件にする発想は避けるのが無難です。
- Custom security attributes：柔軟でRBACにより読み書きを絞れる一方、公式FAQで「ユーザーに割り当てたcustom security attributesは動的メンバーシップグループのルール構成にはサポートされない」と明記されています。
結果として、Cost centerで動的グループを作る目的に対しては、現時点ではextensionAttributeまたはカスタム拡張プロパティが現実解になります。
将来的にEmployee org dataを直接条件にしたい場合
「employeeOrgDataをそのまま動的グループに使えるようにしてほしい」という要望がある場合、Microsoftのフィードバックポータルへ提案する流れが案内されています。Microsoft側も制限を認識している旨を述べており、フィードバックは開発チームが継続的にモニタリングしているとされています。
まとめ
- Employee org dataのCost centerは、現時点ではMicrosoft Entra IDの動的グループルールから参照できない
- 回避策として、Cost centerを動的ルールで使える属性へコピーしてグループ条件にする
- 最短実装は extensionAttribute、命名や拡張性を重視するならカスタム拡張プロパティ、オンプレ起点ならEntra ConnectのDirectory extensionsが有力
- ライセンス要件と、処理ステータスの確認、ルール性能（-eqや-in優先）を押さえると運用が安定する
コメント