Microsoft Entra ID のライフサイクル ワークフローを本格導入しようとすると、多くの方が最初につまずくのが「extensionAttribute1～15 をトリガーに使いたいのに、属性変更トリガーの候補に出てこない」問題です。本記事では 2024～2025 年の仕様の変遷を踏まえつつ、未対応期の現実的な回避策と、現在提供されている「カスタム属性トリガー（プレビュー）」の使いどころを、実務目線で整理します。
問題の本質：なぜ extensionAttribute1～15 がトリガーに出てこないのか
まず「なぜドロップダウンに extensionAttribute1～15 が出てこないのか？」という根本原因を整理します。
- ライフサイクル ワークフローのトリガー「属性変更」は、利用できる属性が限定されたホワイトリスト方式です。
- 2024 年 11 月時点の公式回答では、オンプレミス拡張属性（extensionAttribute1～15）・Directory extensions・カスタム セキュリティ属性はトリガーに未対応と明言されていました。
- そのため、extensionAttribute1～15 を Entra で使っていても、属性変更トリガーのドロップダウンには表示されず、選択できません。
つまり「自分のテナントだけ UI がおかしい」のではなく、当時の製品仕様として、拡張属性をトリガーにできなかったというのが出発点です。
2024～2025 年の仕様の変遷と現在の位置づけ
2024-11-21 時点：拡張属性はトリガー未対応
2024 年 11 月の Microsoft Q&A では、ライフサイクル ワークフローの「属性変更」トリガーについて、次のような回答が出ています（意訳）：
- トリガーとして使えるのは、以下のような標準ユーザー属性のみ
- オンプレミス拡張属性（extensionAttribute1～15）・Directory extensions・カスタム セキュリティ属性はトリガーとしては未サポート
- エンジニアリングチームがサポート拡張を検討中だが、ETA（提供時期）は未定
この回答に添付されたリストを整理すると、当時「属性変更」トリガーでサポートされていた主な属性は以下の通りです。
| カテゴリ | 日本語名 | プロパティ名 | 典型的な用途 |
|---|---|---|---|
| 組織情報 | 部署 | department | 部署異動（Mover）の検知 |
| 組織情報 | 役職 | jobTitle | 職位によるアクセス権変更 |
| 組織情報 | 従業員区分 | employeeType | 正社員 / 派遣 / 業務委託などの判定 |
| 組織情報 | 上司 | manager | マネージャー変更時の処理 |
| 組織情報 | 会社名 | companyName | グループ企業間の差異吸収 |
| 組織情報 | 従業員 ID | employeeId | 人事システムとの突合 |
| 所在地 | 使用場所 | usageLocation | ライセンス割り当て条件 |
| 所在地 | 都道府県 | state | 国内拠点ごとのアクセス制御 |
| 氏名表示 | 姓 / 名 / 表示名 | surname / givenName / displayName | 表示名ルール変更の検知など |
| メール | メール アドレス | メールボックスや DL の制御 | |
| メール | エイリアス | mailNickname | ユーザー ID 変更の検知 |
| 連絡先 | 携帯電話番号 | mobilePhone | MFA 連絡先の更新検知 |
| アカウント | サインイン名 | userPrincipalName | UPN 変更に伴う各種更新 |
| アカウント | ユーザー種別 | userType | メンバー / ゲストの判定 |
| アカウント | アカウント有効 | accountEnabled | 有効 / 無効の切替検知 |
| アカウント | 割り当て済みプラン | assignedPlans | アプリ ライセンス状態の変化検知 |
ご覧の通り、既定属性だけで JML（Joiner / Mover / Leaver）の典型パターンは十分に作れる一方、拡張属性で持っている業務固有フラグには直接紐付けられない、というのが当時の状況でした。
2025-08-25 時点：UI に拡張属性が見えるがバグっぽい挙動
その後 2025 年 8 月には、同じく Q&A のコメントで、次のような報告が上がっています（要約）：
- 一部環境では、属性ドロップダウンに カスタム拡張プロパティやカスタム セキュリティ属性が表示されるようになった。
- しかし、カスタム拡張プロパティを選ぶとワークフローが保存できないエラーが発生。
- カスタム セキュリティ属性を条件にした場合、スコープが正しく効かず、属性を持たないユーザーにも適用されてしまう。
つまり「UI には出てきたが、裏側の実装が追いついていない（もしくはバグ）」という、実装途中らしき状態だったわけです。
2025-10 以降：カスタム属性トリガー（プレビュー）の正式ドキュメント化
2025 年 10 月末には、Microsoft Learn に 「カスタム属性トリガーをライフサイクル ワークフローで利用する（プレビュー）」というドキュメントが公開され、状況が大きく変わりました。
このプレビュー機能では、「属性変更」トリガーの対象として、次の属性群が公式にサポートされたと明記されています。
- カスタム セキュリティ属性（Custom Security Attributes）
- Directory extension 属性
- オンプレミス拡張属性（extensionAttribute1～15）
- EmployeeOrgData 系属性
ポイントを整理すると：
- トリガー タイプは従来同様 「属性変更（Attribute changes）」 を使用。
- 「トリガー属性」の選択肢に、上記カスタム属性が表示される。
- スケジュールされたワークフローのみがカスタム属性の変更を拾う。
- カスタム属性の値がワークフロー エンジンに届くまで、最大 4 時間程度の遅延が起こり得る（FAQ でも上限 4 時間と説明）。
つまり 2025 年末時点では、extensionAttribute1～15 そのものをトリガーにする道が（プレビューではあるものの）公式に開かれたと言えます。一方で、本記事の主眼である「未対応期間の回避策」は、
- プレビュー機能をまだ利用できないテナント
- プレビューではなく GA（正式リリース）機能だけで設計したい組織
にとって、依然として有効な考え方です。
ライフサイクル ワークフローのトリガーの全体像
extensionAttribute をどう扱うかを考える前に、ライフサイクル ワークフローの「トリガーそのもの」を俯瞰しておきます。ライフサイクル ワークフローでは、ワークフローの実行条件は「トリガー」と「スコープ」の 2 つで構成されます。
| トリガー種別 | 概要 | 代表的なユースケース |
|---|---|---|
| Time based attribute （時間ベース属性） | employeeHireDate / employeeLeaveDateTime などの日付を基準に、指定日前後で自動実行 | 入社 7 日前の事前準備、退職 30 日後のアカウント削除など |
| Attribute changes （属性変更） | 指定した属性の変更を検知し、変更値に応じて実行 | 部署変更時の権限見直し、userType 変更時の制御など |
| Group membership change | 指定グループへの追加 / 削除を検知して実行 | グループ ベース アクセスの自動付与 / 削除 |
| Sign-in activity | 最終サインインからの経過日数に基づき実行 | 長期間未使用アカウントの棚卸し |
| On-demand only | 手動実行のみ。スケジュール実行なし | 個別対応が必要なイレギュラー処理 |
extensionAttribute1～15 の話はあくまで 「Attribute changes」トリガーにおける、トリガー属性としての扱いに関する制限です。Time based attribute や Group membership change など、他のトリガーとも組み合わせると設計の幅が広がります。
「属性変更」トリガーで extensionAttribute を使えないときの考え方
プレビュー機能がまだ使えない、あるいは GA 機能に限定して設計したい場合、extensionAttribute1～15 をどう扱うべきでしょうか。本質的には、次の 2 つの問いに分解すると整理しやすくなります。
- 「誰が対象か」を、どの属性で表現するか？
- 「いつ動かすか」を、どのトリガーで表現するか？
extensionAttribute1～15 は、しばしば「Joiner か Mover か」「この人は特定システムの対象か」といった、対象ユーザーを判定するためのフラグとして使われています。そのため、
- extensionAttributeX → 他のサポート属性に写し替えてトリガー / スコープに使う
- extensionAttributeX → ダイナミック グループの条件に使い、グループ ベースの仕組みに処理を寄せる
- extensionAttributeX → 外部オートメーション（Power Automate / Logic Apps 等）側で拾って処理
といった設計パターンが現実的です。
パターン 1：拡張属性の“写し替え”で対応（推奨パターン）
もっとも堅実で管理しやすいのが、extensionAttributeX の値を別のサポート属性にコピーしておき、ライフサイクル ワークフローは「写し替え先属性」を見て動くようにするパターンです。
どの属性に写し替えるか？設計の指針
写し替え先の候補として、よく使われるのは次のような属性です。
| 写し替え先属性 | 用途イメージ | メリット | 注意点 |
|---|---|---|---|
| employeeType | 「JML ステータス」「雇用区分＋フラグ」など | 元々「従業員区分」用途なので意味づけしやすい | 既に人事区分に使っている場合は値の設計を工夫する必要 |
| department | 論理的な「部門グルーピング」として使用 | ダイナミック グループ等でもよく使われる | 物理部署と齟齬が出ないように命名ルールを整理 |
| usageLocation | リージョン単位の処理分岐 | ライセンスや条件付きアクセスとの整合を取りやすい | 実際の居住国 / 利用国とも連動しているケースでは慎重に |
| custom: ダミー属性用に空いている既定属性 | JML 専用のフラグ用として占有 | 他システムの意味と完全に切り離して設計可能 | どの属性を「ダミー」として占有するかの合意形成が必要 |
おすすめは、「人が見ても意味が通る」形で値設計できる属性を選ぶことです。例えば employeeType に「Permanent」「Contingent」に加えて「JoinerFlag」「MoverFlag」のような値を追加すると、後から見直したときにも直感的に理解しやすくなります。
写し替え実装のやり方（Cloud Sync / Connect / Power Automate）
写し替えの実装にはいくつか選択肢があります。
- Microsoft Entra Connect cloud sync / Connect Sync のカスタム マッピング
- HR Inbound Provisioning（Workday / SuccessFactors 等）での属性マッピング
- Power Automate / Logic Apps によるポーリング更新
例えば、オンプレミス AD から employeeHireDate 等を同期するための公式ドキュメントでは、
「AD の任意の文字列属性（例: msDS-cloudExtensionAttribute1）を Entra の employeeHireDate に変換して流し込む」パターンが紹介されています。
この考え方を応用し、たとえば次のようなマッピングを定義します。
| ソース | ターゲット | 変換例 | 備考 |
|---|---|---|---|
| on-premises extensionAttribute10 | employeeType | 「J」「M」「L」 → 「Joiner」「Mover」「Leaver」 | JML ステータスを employeeType に反映 |
| on-premises extensionAttribute11 | department | 「SLS」 → 「Sales-JML-Target」 | 特殊な処理対象部署としてマーキング |
こうして employeeType や department に写し替えておけば、ライフサイクル ワークフローでは
- トリガー属性：employeeType（値 = “Joiner” に変わった時）
- スコープ：department equals “Sales-JML-Target”
といった設定で、拡張属性で持っていた条件を正式サポート属性だけで再現できます。
このパターンのメリット / デメリット
- メリット
- ライフサイクル ワークフロー側は GA 機能のみで構成できる。
- 将来カスタム属性トリガーが GA になっても、既存設計をそのまま流用しやすい。
- extensionAttribute1～15 が既に別用途で使われていても、写し替え側で値設計を整理できる。
- デメリット
- 写し替えロジックの分だけ構成が一段複雑になる。
- 「元属性」と「写し替え先属性」の不整合が生じないよう、変更フローをしっかり設計する必要がある。
パターン 2：スケジュール実行 + 条件抽出で “徐々に拾う”
extensionAttribute1～15 を直接トリガーにできない場合でも、スケジュール実行のワークフローで対象ユーザーをじわじわ絞り込むという発想も取れます。
基本アイデアは次の通りです。
- トリガーは「Time based attribute」や「Sign-in activity」等、サポートされている属性だけで構成する。
- スコープ条件で、できるだけ拡張属性に近い条件を既定属性だけで表現する。
- どうしても extensionAttributeX の値そのものが必要なら、パターン 1 の写し替えと併用する。
例えば「employeeHireDate の 1 日前に Joiner 処理をするが、そのうち extensionAttribute10 = “Y” の人だけに限定したい」といったケースでは、
- extensionAttribute10 → employeeType へ写し替え（”Y” → “JoinerFlag”）
- トリガー：Time based attribute（employeeHireDate の 1 日前）
- スコープ：employeeType equals “JoinerFlag”
という構成で、実質的に「拡張属性フラグ付き Joiner」のみを自動処理対象にできます。
パターン 3：ダイナミック グループを使って処理を“グループ ベース”へ寄せる
extensionAttribute1～15 は、ダイナミック グループのメンバーシップ ルールでは比較的一早くから利用可能でした。Microsoft Entra ID のドキュメントでも、ダイナミック グループはユーザー属性（含む拡張属性）ベースのメンバーシップをサポートすることが示されています。
また、extensionAttribute を使ったダイナミック グループ構成例を紹介するブログ記事も複数公開されています。
この性質を利用すると、次のような設計が可能になります。
- extensionAttributeX を条件にしたダイナミック グループ（例：
user.extensionAttribute10 -eq "JML-Target"）を作成。 - このグループを対象に、アクセス パッケージ / アプリ割り当て / ライセンス付与などを自動化。
- ライフサイクル ワークフロー自体は、より汎用的なトリガー（employeeHireDate / department など）に専念させる。
つまり、「権限・アプリ付与系はダイナミック グループに寄せる」「アカウント ライフサイクル系はライフサイクル ワークフローに寄せる」と役割分担するイメージです。
ダイナミック グループを使うときの注意点
- Entra ID P1 以上のライセンスが必要になり得る。
- ルールが複雑になりすぎると、評価コスト・トラブルシュート難度が上がる。
- extensionAttribute を多用しすぎると「何のグループを何のルールで作ったか」が分かりにくくなるため、命名規則とドキュメント化が重要。
パターン 4：外部オートメーションで extensionAttribute の変更を検知する
どうしてもライフサイクル ワークフロー側では上手く表現できない、あるいはワークフローで用意されていない処理（外部システム連携など）が必要な場合には、Power Automate / Logic Apps などのオートメーション基盤に役割を分担させるのも有効です。
設計例：
- Graph API / 監査ログ / 変更通知などを使い、extensionAttributeX の変更をトリガーに Power Automate を起動。
- フロー内で、条件に応じて次のような処理を実行：
- アプリ（SaaS）側のユーザー プロビジョニング
- チケット システムへのチケット起票
- Slack / Teams への通知
- 別の Entra 属性の更新（＝ライフサイクル ワークフローにバトンを渡す）
このとき「最後はライフサイクル ワークフローに渡したい」のであれば、Power Automate 側で employeeType などのサポート属性を書き換えるようにし、ワークフローのトリガーは引き続き GA 機能に限定しておくと安心です。
運用設計で絶対に押さえておきたいポイント
検証環境でのテストは必須
カスタム属性トリガーのプレビューを含め、UI に属性が表示されていても、
- 保存時にエラーになる
- スコープ条件が無視される
といった挙動が過去に報告されています。必ず検証テナントやパイロット グループで動作を確認してから、本番に適用しましょう。
監査ログ / Azure Monitor で「本当に動いたか」を追う
写し替えや外部オートメーションを組み合わせると、トリガー → スコープ → タスク → 外部システム、と処理経路が複数に分かれます。
- Entra の監査ログ（ワークフロー実行履歴）
- Azure Monitor / Log Analytics のクエリ
- Power Automate / Logic Apps の実行履歴
などを活用し、「どのユーザーに何が起こったか」を後から説明できる状態を作っておくことが重要です。
設計ドキュメント化と責任分界
特に「extensionAttributeX → employeeType に写し替えて使う」ような構成では、
- 人事システムの値を変えるチーム
- オンプレ AD を管理するチーム
- Entra ID / ライフサイクル ワークフローを管理するチーム
など、複数の担当者が絡みます。どの属性をどの用途で使っているのか、責任分界とロールバック手順まで含めて明文化しておくと、トラブル時に「誰の責任か」で揉めずに済みます。
最新情報を定期的にチェックする
今回取り上げたように、ライフサイクル ワークフロー関連の機能は 2024～2025 年にかけて活発にアップデートされています。
- Lifecycle workflows の概要 / テンプレート / タスク一覧
- Execution conditions（トリガーとスケジュール）の仕様
- Custom attribute triggers（プレビュー）の制約と FAQ
などのドキュメントは、少なくとも四半期ごとにチェックするとよいでしょう。
【2025 年末時点】カスタム属性トリガー（プレビュー）をどう使うか？
最後に、現在提供されている カスタム属性トリガー（プレビュー） をどう位置づけるかを整理します。
基本的な使い方の流れ
- 必要なライセンス（Entra ID Governance / Entra Suite 等）があることを確認。
- 管理者ロールとして、Lifecycle Workflows Administrator と Attribute Assignment Administrator を付与。
- Entra 管理センターで「ID Governance > Lifecycle workflows > Create a workflow」を開く。
- テンプレートを選択し、トリガー タイプに Attribute changes を指定。
- トリガー属性のドロップダウンから、extensionAttribute1～15 / Directory extension / カスタム セキュリティ属性等を選択。
- スコープ条件でも、同じ属性や別の属性を組み合わせて対象ユーザーを絞り込む。
注意すべき制約と設計上のポイント
- スケジュールされたワークフローにしか効かない
- On-demand only のワークフローでは、カスタム属性トリガーは意味を持ちません。
- 属性の伝播に最大数時間かかる可能性
- カスタム属性の値が内部サービスに反映されるまで最大 4 時間程度かかる可能性があるとされています。
- 「変更から数分以内に必ず動いてほしい」ようなリアルタイム性の高いシナリオには不向きです。
- プレビューであることを忘れない
- 仕様が変わる可能性や、一部シナリオでの不具合のリスクを前提に、段階的な導入を検討しましょう。
- 重要なビジネス プロセスでは、パターン 1 の写し替えなど GA 機能ベースのバックアップ パスを残すのがおすすめです。
シナリオ別・おすすめアーキテクチャ
① クリティカルな業務フローで extensionAttribute を使いたい
「退職処理」「特定システムのアクセス停止」など、失敗が許されないフローでは、現時点では次のような構成が無難です。
- extensionAttribute1～15 は引き続きフラグ用途として活用。
- 写し替え用の既定属性（employeeType 等）を 1 つ決めて、Cloud Sync / Connect / Power Automate で同期。
- ライフサイクル ワークフローは GA でサポートされている属性のみをトリガー / スコープに使用。
- カスタム属性トリガーは、将来 GA になったタイミングで段階的に切り替えを検討。
② 新機能を積極的に試したい（プレビュー歓迎）
テナントや組織としてプレビュー機能の利用に前向きであれば、
- パイロット用のワークフローを別途作成し、カスタム属性トリガーを使用。
- 同じロジックを GA 機能ベース（写し替え）でも用意し、結果を比較。
- 両者の実行ログを見比べて、遅延や抜け漏れがないか検証。
といった方法で、「プレビューを活かしつつも GA ベースの保険を維持する」構成が取りやすくなります。
③ 既に HR Inbound Provisioning を使っている
Workday / SuccessFactors などから HR Inbound Provisioning を行っている場合、既に employeeHireDate / employeeLeaveDateTime / employeeType などはシステムで一元管理されているはずです。
- 拡張属性はあくまで「人事システム側で持ちきれない補助情報」に限定。
- ライフサイクル ワークフローのトリガーは、できるだけ HR 属性側（employeeHireDate など）を優先。
- どうしても extensionAttributeX をトリガーにしたいケースのみ、写し替え or カスタム属性トリガー（プレビュー）を使用。
こうすることで、「中核は HR システム」「補助的な振る舞いは拡張属性＋ワークフロー」と役割を分離しやすくなります。
まとめ
extensionAttribute1～15 をライフサイクル ワークフローのトリガーに使いたい、というニーズは非常に多く、Microsoft も 2024～2025 年にかけて対応を進めてきました。
- 2024-11-21 時点では、拡張属性（extensionAttribute1～15）・Directory extensions・カスタム セキュリティ属性は属性変更トリガーで未サポートであり、ドロップダウンにも表示されませんでした。
- 2025-08-25 時点では、一部テナントで UI 上にカスタム属性が見えるものの、保存エラーやスコープ無視などの不具合らしき挙動が報告されています。
- その後 2025-10 に カスタム属性トリガー（プレビュー） が正式にドキュメント化され、extensionAttribute1～15 や Directory extensions、カスタム セキュリティ属性などをトリガーとして利用できるようになりました（ただし遅延やスケジュール実行のみなどの制約あり）。
現時点でのベスト プラクティスは、次のようにまとめられます。
- 安定性が最優先の業務フロー：
- 「サポート属性への写し替え」＋「属性変更トリガー（既定属性）」で設計する。
- 新機能を活かしたいシナリオ：
- カスタム属性トリガー（プレビュー）をパイロット的に活用しつつ、同等ロジックを GA 機能でも用意して比較検証する。
- 権限・アプリ配布中心のシナリオ：
- extensionAttribute1～15 をダイナミック グループの条件に使い、グループ ベースの割り当てやアクセス パッケージに処理を寄せる。
- 外部システム連携が多いシナリオ：
- Power Automate / Logic Apps など外部オートメーションを併用し、必要に応じて Entra の属性を更新してライフサイクル ワークフローにバトンを渡す。
extensionAttribute1～15 は、オンプレミス AD 時代から「とりあえず拡張情報を突っ込む場所」として使われてきた歴史があり、組織ごとに意味づけがバラバラになりがちです。ライフサイクル ワークフローと組み合わせるタイミングは、「どの拡張属性に何の意味を持たせるか」を整理し直す絶好のチャンスでもあります。
本記事で紹介したパターンと注意点をベースに、まずは小さなパイロットから、extensionAttribute とライフサイクル ワークフローの“付き合い方”を固めていってみてください。
コメント