MENU

Entra IDでemployeeLeaveDateTime（退職日時）を手動設定する方法｜UI不可・Microsoft Graph/PowerShellで更新

Azure

Entra IDで退職日時（employeeLeaveDateTime）を入れたいのに、ユーザー画面に項目が見当たらない…。結論から言うと、管理センターのUIでは設定できず、Microsoft Graph（API/PowerShell）で更新します。手順と運用のコツをまとめます。

目次

employeeLeaveDateTime（退職日時）とは

employeeLeaveDateTime は、Microsoft Entra ID（旧 Azure AD）のユーザー オブジェクトが持つ属性のひとつで、「退職（離職）した、または退職予定の日時」を DateTime 形式で保持します。特に Microsoft Entra ID Governance の Lifecycle Workflows（ライフサイクル ワークフロー）では、この値をもとに「退職日の何日前／何日後にオフボーディング処理を自動実行する」といったスケジュール トリガーを組めます。

名前が似ている属性に employeeHireDate（入社日）がありますが、Joiner（入社）と Leaver（退職）で使い分けるイメージです。Lifecycle Workflows を使わない場合でも、社内の人事データと Entra ID をつなぐ「基準日」として扱いやすく、退職予定者のライセンス棚卸し・権限見直し・棚卸しレポート作成などにも応用できます。

結論：Entra 管理センター（UI）からは手動設定できない

探しても見つからないのは仕様です。Entra 管理センター（entra.microsoft.com）のユーザー編集 UI から employeeLeaveDateTime を直接入力・更新することはできません。設定するには Microsoft Graph（REST API）または Microsoft Graph PowerShell SDK を利用します。

やりたいことEntra 管理センター（UI）Microsoft Graph（API/PowerShell）現実的な使い分け
employeeLeaveDateTime を1人だけ更新不可可Graph Explorer / PowerShell で手動更新
employeeLeaveDateTime を複数人まとめて更新不可可CSV + PowerShell、または HR システム連携
退職日を入力して自動オフボーディングを走らせたいトリガー設定は可（値の編集は不可）値の投入が可「入力（Graph）＋実行（Lifecycle Workflows）」の分業が基本

なぜ UI に項目がないのか（設計上のポイント）

employeeLeaveDateTime は「誰でも気軽に編集できる通常のプロフィール項目」とは扱いが異なります。Microsoft Graph の権限体系でも、一般的なユーザー更新権限（User.ReadWrite.All）では employeeLeaveDateTime の更新が例外として禁止され、専用の権限（User-LifeCycleInfo.ReadWrite.All）が必要です。

この属性は Lifecycle Workflows のスケジュール トリガーに直結し、誤設定すると「退職者が出ていないのにアカウント停止や権限削除が走る」「本来の退職日に処理が動かない」といった事故に繋がります。UI で無制限に編集できるようにしないことで、運用設計（誰がいつ更新するか、監査ログをどう残すか）を強制しやすい、という面もあります。

更新に必要な前提（権限・ロール・対象）

employeeLeaveDateTime を更新するには、Graph 側で専用の許可が必要です。公式の手順では、最小権限の例として User.Read.All と User-LifeCycleInfo.ReadWrite.All の組み合わせが示されています。

方式必要な Graph 権限（例）管理者ロール（委任の場合）向いている場面
Graph Explorer（委任）User.Read.All + User-LifeCycleInfo.ReadWrite.AllGlobal Administrator が必要今すぐ1人だけ直したい／検証したい
Graph PowerShell（委任）User.Read.All + User-LifeCycleInfo.ReadWrite.AllGlobal Administrator が必要手動でも複数人を一括更新したい
アプリ（アプリケーション権限）User.Read.All + User-LifeCycleInfo.ReadWrite.All（アプリ同意で完結）人事システム連携、定期同期、ワークフロー自動化

また、読み取りだけなら User-LifeCycleInfo.Read.All など別の要件になる場合があり、PowerShell のコマンドレット解説には「読み取りに必要な権限」「委任シナリオで参照できるロール」も整理されています。

Microsoft Graph API で employeeLeaveDateTime を設定する

API 仕様（PATCH /users/{id}）

更新はユーザー更新 API を使い、employeeLeaveDateTime に ISO 8601（UTC の Z 付き）で日時を入れます。成功すると 204 No Content が返ります。

PATCH https://graph.microsoft.com/v1.0/users/{id-or-upn}
Content-Type: application/json

{
  "employeeLeaveDateTime": "2026-03-31T14:59:59Z"
}

ポイントは次の3つです。

  • v1.0 エンドポイントで操作できる（beta 固定ではありません）。
  • 日時は UTC（Z）で指定する。JST など現地時刻で管理している場合は変換が必要。
  • 値を消したいときは null を PATCH する。

Graph Explorer での手動設定手順

  1. Graph Explorer にサインインし、対象テナントを選択します。
  2. 権限（Scopes）に User.Read.All と User-LifeCycleInfo.ReadWrite.All を追加し、管理者同意を完了します。
  3. まずは値の確認として、GET /users/{id}?$select=displayName,employeeLeaveDateTime を実行します（返らない場合は後述の「よくある落とし穴」を参照）。
  4. 問題なければ PATCH を実行して値を設定します。

JST（日本時間）を UTC に変換する実務のコツ

日本企業の「退職日」は日付（YYYY/MM/DD）で扱われることが多く、時刻まで厳密に決めていないケースが大半です。その場合、Lifecycle Workflows の実行タイミングがずれないように「退職日の終業後」を表す時刻に寄せて設定するのが安全です。Microsoft の同期ガイドでも、employeeLeaveDateTime は「1日の終わりに近い時間（例：21時や23時）」に寄せることや、テナント側のスケジュール実行間隔により遅延しうる点が述べられています。

社内の決め方（例）JST の表現Graph に入れる UTC（Z）意図
退職日の「当日いっぱい」2026-03-31 23:59:59（+09:00）2026-03-31T14:59:59Z翌日になってから誤って走らないよう終端に寄せる
退職日の「21時運用」2026-03-31 21:00:00（+09:00）2026-03-31T12:00:00Zバッチ遅延を見込んで少し早めに設定
退職日の「午前中に実行」2026-03-31 05:00:00（+09:00）2026-03-30T20:00:00Z退職日当日の朝に処理を確実に終えたい

どれが正解かは組織のオフボーディング設計次第ですが、「人事が扱う退職日（=日付）」と「IT が実行したい退職処理（=時刻）」を同じフィールドに押し込むとズレが起きがちです。運用で迷う場合は、退職日そのものは別の台帳（HR）に置き、employeeLeaveDateTime は “IT 実行基準の日時” と割り切ると事故が減ります。

Microsoft Graph PowerShell SDK で設定する（単体・一括）

単体更新（最短手順）

PowerShell でも同じく Graph に対して更新します。公式チュートリアルでは次のように Update-MgUser を使って employeeLeaveDateTime を設定できます。

# 初回のみ：必要なモジュール
Install-Module Microsoft.Graph -Scope CurrentUser

# 接続（委任）
Connect-MgGraph -Scopes "User.Read.All","User-LifeCycleInfo.ReadWrite.All"
Select-MgProfile -Name "v1.0"

# 退職日時の設定（UTCのZ付き）
$userId = "aaaaaaaa-bbbb-cccc-1111-222222222222"  # Object ID でも UPN でも可
$leave = "2026-03-31T14:59:59Z"
Update-MgUser -UserId $userId -EmployeeLeaveDateTime $leave

# 確認（プロパティは明示的に取得）
(Get-MgUser -UserId $userId -Property EmployeeLeaveDateTime).EmployeeLeaveDateTime

Update-MgUser のパラメーター説明にも、employeeLeaveDateTime の読み書きに必要な権限・委任時のロール要件が明記されています。

CSV で一括更新（運用向け）

「毎月退職者リストが届く」「人事が確定した分をまとめて入れたい」という現場では、CSV で一括投入できる形にしておくと便利です。例として、UPN と LeaveDateJST（例：2026-03-31）を受け取り、JST 終端（23:59:59）を UTC に変換して登録するスクリプト例です。

# CSV例:
# UPN,LeaveDateJST
# [email protected],2026-03-31
# [email protected],2026-04-15

Connect-MgGraph -Scopes "User.Read.All","User-LifeCycleInfo.ReadWrite.All"
Select-MgProfile -Name "v1.0"

Import-Csv .\\leavers.csv | ForEach-Object {
  $upn = $_.UPN
  $date = [datetime]::ParseExact($_.LeaveDateJST, "yyyy-MM-dd", $null)

  # JST 23:59:59 を作って UTC に変換（JST=UTC+9）
  $jst = [datetime]::SpecifyKind($date.AddDays(1).AddSeconds(-1), [DateTimeKind]::Unspecified)
  $offset = New-Object System.DateTimeOffset($jst, [TimeSpan]::FromHours(9))
  $utc = $offset.ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")

  try {
    Update-MgUser -UserId $upn -EmployeeLeaveDateTime $utc
    Write-Host "OK: $upn -> $utc"
  } catch {
    Write-Warning "NG: $upn ($($_.Exception.Message))"
  }
}

運用に載せるなら、更新履歴（CSVの保存、実行ログ、監査ログ）を残す、例外ユーザー（役員・特権管理者）を除外する、などのガードレールも合わせて設計しておくと安心です。

よくある落とし穴とエラー対応

症状原因の候補対処補足
403 Forbidden / Insufficient privilegesUser.ReadWrite.All だけで更新しようとしているUser-LifeCycleInfo.ReadWrite.All を付与し、管理者同意するUser.ReadWrite.All では employeeLeaveDateTime は更新対象外
値を設定したのに GET で見えない$select / -Property を付けずに取得しているGET に $select=employeeLeaveDateTime、PowerShell なら -Property を付けるチュートリアルでも明示的な取得が前提
退職日「当日」に処理が走らない／遅れる属性の時刻、テナントスケジュール、時差の考慮漏れ時刻を適切に設定し、遅延を見込んだ運用にするテナントスケジュールの遅延や時刻の重要性が案内されている
オンプレ同期ユーザーで値が入らないAD に対応属性がなく、マッピング・形式変換が必要AD 側の文字列属性を選び、所定の形式で同期するAD に直接対応する属性はない

Lifecycle Workflows と組み合わせるときの運用設計

Lifecycle Workflows で leaver シナリオを回す場合、employeeLeaveDateTime は「トリガーの起点」です。つまり、入力の品質がそのまま自動化の品質になります。入力運用を雑にすると、自動化がむしろ事故の源になります。

おすすめの役割分担

  • 人事（HR）：退職日の確定、変更、取消の正本を持つ
  • IT（ID管理）：確定情報を employeeLeaveDateTime に反映（自動連携 or バッチ）
  • ワークフロー管理者：Lifecycle Workflows のトリガーと手順（停止・ライセンス回収等）を設計

Microsoft Learn のガイドでも、employeeLeaveDateTime は HR プロビジョニングや Entra Connect、カスタム同期などで 自動更新するのが望ましい、という前提で書かれています。

同期（HR/オンプレ）で入れる場合のポイント

オンプレ AD には employeeLeaveDateTime に対応するネイティブ属性がないため、どの属性を “器” にするか決め、文字列から DateTime に変換して同期します。形式要件や例（Graph は YYYY-MM-DDThh:mm:ssZ）もドキュメントにまとまっています。

また、Entra Connect の既定ルールに employeeLeaveDateTime のフローが取り込まれたバージョン情報も明記されているため、ハイブリッド環境では「自前の同期ルールが必要か」を判断する材料になります。

「どうしても画面で入力したい」場合の現実解（回避策）

employeeLeaveDateTime 自体は UI から編集できませんが、「画面で入力できるフィールド」を別に用意し、そこから Graph で転記する方法なら現場の要望をかなえやすいです。代表例が カスタム セキュリティ属性（custom security attributes） です。これは Entra 管理センターのユーザー画面から割り当て・更新できる “キーと値” の属性で、業務用の分類情報などを保存できます。

回避策の構成イメージ

  • 人事／情シスが UI で「退職予定日」(例：YYYY-MM-DD) をカスタム セキュリティ属性に入力
  • 夜間バッチ（PowerShell / Azure Automation / Logic Apps など）が、その値を読み取り、employeeLeaveDateTime に変換して書き込む
  • Lifecycle Workflows は employeeLeaveDateTime を参照して予定日に実行

UI で入力できる理由と注意点

カスタム セキュリティ属性は、専用の Entra ロール（Attribute Assignment Administrator など）を付けたユーザーが、管理センターの「ユーザー > カスタム セキュリティ属性」から操作できます。既定では Global Administrator でも読めない、という点は運用上のメリットにもデメリットにもなり得ます。必要最小限の担当者だけに割り当てる設計が安全です。

「UI で入力したい」という要望は、たいてい “入力担当が PowerShell を使えない／使わせたくない” が本質です。入力と反映を分離し、入力は UI、反映は自動化に寄せると、監査・再現性・一括処理のすべてが良くなります。

まとめ

  • employeeLeaveDateTime（退職日時）は Entra 管理センター（UI）からは設定できない。
  • 設定・更新は Microsoft Graph（API/PowerShell）で行い、専用権限 User-LifeCycleInfo.ReadWrite.All が必要。
  • Lifecycle Workflows と連携するなら、UTC 変換・時刻の決め方・スケジュール遅延を織り込んで運用する。
  • どうしても “画面入力” が必要なら、カスタム セキュリティ属性を UI 入力欄として用意し、Graph で転記する構成が現実的。
Azure
PowerShell Microsoft Graph Entra ID employeeLeaveDateTime Lifecycle Workflows

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次