Microsoft Entraの「Microsoft Entra documentation update: Update durationBeforeTimeout limit for custom tasks」は、カスタムタスク拡張機能の待機タイムアウトに関する制限変更です。結論から言うと、durationBeforeTimeout、またはMicrosoft GraphのcallbackConfiguration.timeoutDurationで扱う待機時間の下限が、従来の5分から30分に引き上げられています。上限の3時間は変わりません。
特に確認が必要なのは、Microsoft Entra ID Governanceのライフサイクルワークフローでカスタムタスク拡張機能を使い、Azure Logic Appsや外部システム連携を「待機あり」で実行している環境です。PT5M、PT10M、PT15Mのような短いタイムアウトをテンプレート、PowerShell、Microsoft Graph API、IaCに埋め込んでいる場合は、30分以上に見直す必要があります。
Microsoft Entra documentation updateで変わったdurationBeforeTimeoutの要点
今回の更新は、Microsoft Entra ID Governanceのサービス制限に関するドキュメント更新です。GitHubの公式PRでは、durationBeforeTimeout range of custom task extensionsの値が「5 minutes-3 hours」から「30 minutes-3 hours」に変更されており、コメントにはコード変更に合わせて待機時間を更新する旨が記載されています。(GitHub)
Microsoft Learnの日本語版「Microsoft Entra ID ガバナンス サービスの制限事項」でも、ライフサイクルワークフローの制限として「カスタム タスク拡張機能の durationBeforeTimeout の範囲」は30分から3時間と記載されています。(Microsoft Learn) また、Microsoft GraphのcustomTaskExtensionCallbackConfigurationでも、コールバックのタイムアウト時間として受け付ける範囲は30分から3時間、例としてPT30MとPT3Hが示されています。(Microsoft Learn)
| 項目 | 変更前 | 変更後 | 管理者・開発者が見るべきポイント |
|---|---|---|---|
| 最小待機時間 | 5分 | 30分 | 30分未満の値を設定しているテンプレートやAPI呼び出しを修正する |
| 最大待機時間 | 3時間 | 3時間 | 上限は変わらないため、3時間を超える処理は設計を分ける |
| 主な対象 | カスタムタスク拡張機能 | カスタムタスク拡張機能 | 組み込みタスクだけを使うワークフローは基本的に対象外 |
| 関連する設定名 | durationBeforeTimeout | durationBeforeTimeout / timeoutDuration | エンタイトルメント管理とライフサイクルワークフローで名称が異なる場合があるため混同しない |
ここで重要なのは、「ワークフローが必ず30分待つ」という意味ではない点です。30分はタイムアウトとして設定できる最小値です。Logic Apps側が正常終了または失敗を早く返す設計であれば、処理そのものを30分引き延ばす必要はありません。
影響を受けるのはカスタムタスク拡張機能とLogic Apps連携
Microsoft GraphのcustomTaskExtensionは、ライフサイクルワークフローとAzure Logic Appsを統合し、組み込みタスク「Run a custom task extension」からLogic Appsを呼び出すためのリソースです。(Microsoft Learn) Microsoft Entraのライフサイクルワークフローでは「カスタム タスク拡張機能を実行する」タスクが用意されており、実行には互換性のあるLogic Appsが前提になります。(Microsoft Learn)
影響が出やすいのは、次のような構成です。
| 構成・運用 | 影響度 | 確認ポイント |
|---|---|---|
| Graph APIやPowerShellでカスタムタスク拡張機能を作成・更新している | 高 | PT5Mなど30分未満の値が残っていないか |
| Terraform、Bicep、ARMテンプレート、CI/CDで値を固定している | 高 | 変数の既定値、サンプルJSON、検証ルール |
| Logic Appsの失敗検知をEntra側のタイムアウトに依存している | 高 | 失敗時はLogic Apps側から早めに結果を返す設計にする |
| 既存ワークフローの監視で「5分以内に失敗する」前提を置いている | 中 | アラート条件、SLA、運用手順を修正する |
| 組み込みタスクだけを使っている | 低 | カスタムタスク拡張機能が含まれていなければ影響は限定的 |
すでにPT30M以上を設定している | 低 | ただしLogic Appsの実行時間と再試行設定は再確認する |
特に注意したいのは、短いタイムアウトを「安全側の設定」として使っていた環境です。5分で失敗させる設計にしていた場合、単純にPT30Mへ変更すると、外部システム障害時の検知が遅れる可能性があります。タイムアウトを障害検知の主手段にするのではなく、Logic Apps側でエラーを捕捉し、失敗結果を明示的に返す設計に寄せるのが安全です。
管理者がまず確認すべき設定
最初にやるべきことは、全ワークフローの棚卸しではなく、カスタムタスク拡張機能を使っている箇所の特定です。対象を絞らずに確認を始めると、組み込みタスクや関係のないワークフローまで調査して時間を浪費します。
| 確認項目 | 具体的な見方 | 判断基準 |
|---|---|---|
| タイムアウト値 | callbackConfiguration.timeoutDurationまたはdurationBeforeTimeout | 30分未満なら修正対象 |
| Logic Appsの平均・最大実行時間 | 実行履歴、外部APIの応答時間、再試行回数 | 30分に近い処理は余裕を持って60分などを検討 |
| 失敗時の挙動 | Logic Appsが失敗結果を返すか、タイムアウト待ちか | タイムアウト待ちは避ける |
| 再試行設定 | Logic Appsアクション、HTTP呼び出し、外部API側のリトライ | リトライが積み上がってタイムアウトに近づかないか |
| セキュリティ設定 | SAS、マネージドID、最小特権、PoPトークン | 旧構成のまま残っていないか |
Microsoft Graphで一覧を取得する場合は、GET /identityGovernance/lifecycleWorkflows/customTaskExtensionsを使います。このAPIはcustomTaskExtensionオブジェクトとプロパティの一覧を取得するためのもので、最小権限として読み取り系のLifecycleWorkflows-CustomExt.Read.Allが示されています。(Microsoft Learn)
GET https://graph.microsoft.com/v1.0/identityGovernance/lifecycleWorkflows/customTaskExtensions?$select=id,displayName,callbackConfiguration
Authorization: Bearer {token}取得結果では、次のようにtimeoutDurationを確認します。
{
"id": "00000000-0000-0000-0000-000000000000",
"displayName": "Update employee profile in external HR system",
"callbackConfiguration": {
"@odata.type": "#microsoft.graph.identityGovernance.customTaskExtensionCallbackConfiguration",
"timeoutDuration": "PT30M"
}
}PT30Mは30分、PT1Hは1時間、PT3Hは3時間を意味します。PT5MやPT15Mのような値を前提にした設定、テストコード、手順書が残っている場合は、現在の制限に合わせて更新してください。
30分以上へ更新する場合のMicrosoft Graph例
カスタムタスク拡張機能の更新は、Microsoft GraphのPATCH /identityGovernance/lifecycleWorkflows/customTaskExtensions/{customTaskExtensionId}で行います。更新APIでは、要求本文に更新するプロパティの値のみを指定でき、最小権限としてLifecycleWorkflows-CustomExt.ReadWrite.Allが示されています。(Microsoft Learn)
PATCH https://graph.microsoft.com/v1.0/identityGovernance/lifecycleWorkflows/customTaskExtensions/{customTaskExtensionId}
Content-Type: application/json
Authorization: Bearer {token}
{
"callbackConfiguration": {
"@odata.type": "#microsoft.graph.identityGovernance.customTaskExtensionCallbackConfiguration",
"timeoutDuration": "PT30M"
}
}本番環境で更新する前に、必ず既存値をGETで控えてください。特にauthorizedAppsなど、コールバックを許可するアプリケーション設定を使っている場合は、更新後に意図せず設定が変わっていないか確認が必要です。
また、作成・更新APIでは、呼び出し元にMicrosoft Graphの権限だけでなく、指定したAzure Logic Appに対するAzure Resource Managerロールが必要になる点にも注意してください。公式ドキュメントでは、Logic App Contributor、Contributor、Ownerのいずれかが必要とされています。(Microsoft Learn)
開発者が修正すべきコードとテンプレート
開発者が見落としやすいのは、本番の設定値ではなく、サンプルコードやテストデータに残った短いタイムアウトです。以前の検証用テンプレートでPT5Mを使っていた場合、新規環境のデプロイや再作成時に失敗する可能性があります。
確認対象は次の通りです。
| 対象 | ありがちな問題 | 修正方針 |
|---|---|---|
| PowerShellスクリプト | timeoutDuration = "PT5M"が固定されている | 既定値をPT30M以上に変更 |
| JSONテンプレート | サンプル値が5分や10分のまま | 入力検証で30分未満を拒否 |
| CI/CD | テスト環境だけ短い値を使っている | テストも本番と同じ最小値に合わせる |
| アプリケーションコード | タイムアウト値を文字列で直書きしている | 定数化し、下限チェックを入れる |
| 監視テスト | 5分でタイムアウトする前提のテスト | Logic Apps側の失敗応答を検証対象にする |
例えば、タイムアウト値をユーザー入力や環境変数で受け取る場合は、単に文字列をGraph APIへ渡すのではなく、30分以上3時間以下であることをアプリ側でも検証してください。API側のエラーで初めて気付く設計にすると、デプロイ時に原因調査が長引きます。
移行・展開時の注意点
今回の変更は、単純に「5分を30分へ置き換える」だけで終わらせない方が安全です。待機時間の下限が上がることで、障害検知、再実行、監視、運用手順に副作用が出ることがあります。
既存ワークフローは値を棚卸ししてから変更する
既存ワークフローに30分未満の値が残っている場合でも、すぐに全件を一括変更するのは避けてください。まずは、次の3種類に分類します。
| 分類 | 例 | 対応 |
|---|---|---|
| すぐ修正 | 新規作成・更新に使うテンプレートがPT5M | PT30M以上へ変更し、デプロイテスト |
| 設計見直し | 5分タイムアウトで外部API障害を検知している | Logic Apps側で明示的に失敗を返す |
| 経過観察 | すでにPT30M以上 | 実行履歴と監視条件だけ確認 |
何でも3時間にしない
最大値のPT3Hを設定すれば失敗しにくく見えますが、失敗検知が遅れます。オフボーディングやアクセス削除のように、後続処理の遅延がリスクになるワークフローでは、むやみに長くしないことが重要です。
判断基準は次のように置くと実務で扱いやすくなります。
| 推奨値 | 向いている処理 |
|---|---|
PT30M | 通常は数分で終わるAPI連携、短時間の外部システム更新 |
PT1H | 外部APIの応答が不安定、複数ステップのLogic Apps処理 |
PT2H〜PT3H | 一時的な外部システム待ちが発生するが、3時間以内に完了する設計 |
| 3時間超が必要 | カスタムタスク拡張機能の待機に載せず、非同期ジョブや別プロセスに分ける |
3時間を超える業務プロセスをライフサイクルワークフローの待機にそのまま載せると、運用が複雑になります。長時間処理が必要な場合は、キューに投入して別の監視・通知プロセスで追跡する、またはワークフローを分割する設計を検討してください。
セキュリティ面で一緒に確認すべきポイント
今回の更新自体は、脆弱性修正というよりも待機時間の制限変更です。ただし、Microsoft Entra ID Governanceのカスタム拡張機能は、ユーザーの入社・異動・退職、アクセス付与・削除など、権限に直結する処理とつながりやすい領域です。設定変更のタイミングで、Logic Apps連携のセキュリティも見直す価値があります。
Microsoftのベストプラクティスでは、Logic Appsを使うカスタム拡張機能について、SASの無効化、マネージドIDの使用、最小特権、所有証明（PoP）の利用などが挙げられています。(Microsoft Learn)
特に古いLogic Appsは、SAS認可が残っていないかを確認してください。Microsoft Entra ID GovernanceからLogic Appsへの呼び出しはMicrosoft Entra IDアクセストークン認可スキームを使用するため、SASは必須ではなく、無効化が推奨されています。(Microsoft Learn)
また、「起動と待機」パターンでは、Logic AppsのマネージドIDを使ってMicrosoft Entra ID Governanceへの再開呼び出しを認証することが推奨されています。ライフサイクルワークフローでは、「起動と待機」のカスタム拡張機能に対してマネージドIDが自動的に有効化・承認される一方、「起動して続行」では自分で有効化が必要です。(Microsoft Learn)
さらに、古いカスタム拡張機能でBearerトークンに依存している場合は、PoPトークンへの移行可否を確認してください。公式ドキュメントでは、一般提供後にMicrosoft Entra ID Governance UIおよびMicrosoft Graph v1.0エンドポイント経由で作成されたカスタム拡張機能は、既定でPoPアクセストークンを使うと説明されています。(Microsoft Learn)
よくある誤解と失敗しやすいポイント
30分に変更すると、処理が必ず30分遅くなる？
遅くなるとは限りません。30分はタイムアウト値として設定できる最小値です。Logic Appsが処理結果を早く返せる設計であれば、ワークフローはその結果に応じて進みます。問題になるのは、失敗時に結果を返さず、タイムアウトまで待たせている設計です。
clientConfiguration.timeoutInMillisecondsと同じ設定？
別物です。clientConfigurationはLogic AppsへのHTTP接続やリトライに関する設定です。一方、今回の主題であるcallbackConfiguration.timeoutDurationは、Logic Appsからのコールバックをどの時間幅で待つかに関係します。customTaskExtensionのプロパティでも、clientConfigurationとcallbackConfigurationは別の設定として定義されています。(Microsoft Learn)
既存のPT5M設定はそのまま使ってよい？
公式ドキュメント上の受け付け範囲は30分から3時間に更新されています。既存値が即座にどう扱われるかはテナントや更新タイミングで確認が必要ですが、少なくとも新規作成・更新・再デプロイで30分未満の値を前提にするのは避けるべきです。
エンタイトルメント管理のdurationBeforeTimeoutも同じように見るべき？
今回のPRで直接更新されたのは、Microsoft Entra ID Governanceのサービス制限ページにあるライフサイクルワークフローのカスタムタスク拡張機能です。一方で、エンタイトルメント管理のカスタムワークフロー拡張機能ではdurationBeforeTimeoutという名称が使われる例もあります。名称が似ているため、ライフサイクルワークフローのtimeoutDurationと混同せず、対象サービスごとの公式ドキュメントを確認してください。
管理者・開発者が次に取るべき行動
今回のMicrosoft Entra documentation updateで最も重要なのは、カスタムタスク拡張機能の待機タイムアウト下限が30分になった点です。変更の影響は、すべてのMicrosoft Entra環境に一律で出るわけではありません。対象は主に、ライフサイクルワークフローでAzure Logic Apps連携を使い、コールバック待機を設定している環境です。
まず、Microsoft Graphや管理センターでカスタムタスク拡張機能を一覧化し、PT30M未満の値が残っていないか確認します。次に、PowerShell、JSONテンプレート、CI/CD、IaC、手順書にある古い値を更新します。最後に、Logic Apps側で失敗時に明示的な結果を返せるか、SASやBearerトークンなど古いセキュリティ構成が残っていないかを確認してください。
単にタイムアウト値を長くするのではなく、「短時間で失敗を返す設計」と「30分以上3時間以内の待機設定」を両立させることが、今回の更新に対する実務上の正しい対応です。
コメント