Entra ID Lifecycle Workflowsでカスタム拡張(Logic Apps)が作成できない原因と対処|ARMテンプレート検証エラー(graphBetaEndpoint)

Microsoft Entra ID Lifecycle Workflows でカスタム拡張(Logic Apps)を作成しようとすると、「Deployment template validation failed」と表示されて作成に失敗することがあります。監査ログに手掛かりが出にくいこの現象を、エラー文の読み解き方・原因・対処の順で整理します。

日程Fit。無料・登録不要。「いつ空いてる?」を、ひとつのリンクで。リンクを送って、○△×でかんたん日程調整。無料で日程を作る。
目次

現象:Entra ID Lifecycle Workflows のカスタム拡張(Logic Apps)が作成できない

対象は Microsoft Entra ID の Lifecycle Workflows(LCW) で、ワークフロー内から呼び出す カスタム拡張 を作る場面です。カスタム拡張の種類として Logic Apps を選び、作成ボタンを押した直後にエラーになり、拡張が作成されません。

特に厄介なのは、失敗しているのに LCW の監査ログ(Audit Logs)側に決定的な情報が残らず、「どこで何が起きたのか」が追いにくい点です。さらにエラー文に Microsoft Graph Beta を連想させる語(graphBetaEndpoint)が登場し、「本番機能なのに Beta を使っているのでは?」と不安になりやすいのも特徴です。

観点よくある見え方困りポイント
操作カスタム拡張(Logic Apps)を新規作成 → 作成で失敗UI上では「作れない」以上の情報が少ない
エラーDeployment template validation failed を含むARM テンプレート側の問題に見えるが、ユーザーが触れない
ログLCW 監査ログに有用な記録がほぼない原因特定の導線が途切れる
文言graphBetaEndpoint など Beta を想起するパラメータ名が出る「設定ミスか?」「Beta だから不安定か?」と誤解されやすい

エラー例:ARM テンプレート検証エラーとして出る

表示されるエラーは環境によって多少異なりますが、キーワードは共通しており、次のような形になります(抜粋)。

Deployment template validation failed: ...
parameters ... 'graphBetaEndpoint' ...
template ... 'name, location, armResource, issuer' ...

このタイプのエラーは、Azure Resource Manager(ARM)が「デプロイに渡されたパラメータ」と「テンプレート内で定義されたパラメータ」を突き合わせ、整合しない場合に弾くときの典型です。ポイントは graphBetaEndpoint という“テンプレート側に存在しないはずのパラメータ名” が出ていることです。

原因:サービス側デプロイで不要パラメータ(graphBetaEndpoint)が渡され、ARM の検証で失敗していた

結論から言うと、問題の本体はユーザー設定や権限ではなく、Entra 側のデプロイ処理の不具合でした。LCW から Logic Apps の作成を裏側で行う際、ARM テンプレートに対して 不要なパラメータ(graphBetaEndpoint)が追加で渡されていたため、テンプレート側で定義が見つからず、ARM のパラメータ検証で失敗していました。

何が起きていたか本来あるべき状態実際に起きていた状態結果
ARM テンプレート必要なパラメータだけ定義されているテンプレート自体に graphBetaEndpoint の定義がないテンプレート側は受け取れない
デプロイ時のパラメータテンプレートで定義された名前だけを渡すサービス側が graphBetaEndpoint を“余分に”渡していたARM が検証で拒否
ユーザー操作作成ボタンで正常にデプロイが完了作成直後に検証で止まる拡張が作成されない

ここで重要なのは、「余分なパラメータを渡したら無視される」のではなく「検証で失敗する」という点です。ARM テンプレートは、タイポや想定外入力を早期に検知するために、テンプレートに存在しないパラメータが渡された場合はエラーにする設計になっています。今回の事象は、その仕様にサービス側の不具合がぶつかった形です。

監査ログ(LCW Audit Logs)に有用な記録が出にくい理由

LCW の監査ログは「ワークフローの作成・更新」「実行」「ステップの結果」など、Entra 側の操作やワークフロー実行の観点では有効です。一方で今回のように Logic Apps 作成のための ARM デプロイが“検証段階で失敗”すると、Entra 側では「作成要求を出した」以上の確定情報が残らず、ログが薄く見えることがあります。

「ログがない=自分の操作が届いていない」ではなく、届いたが裏側のデプロイ検証で止まっているケースがある、という整理をしておくと切り分けが早くなります。

Microsoft 側の修正:不要パラメータを渡さないように変更され、正常作成できるようになった

この不具合は Microsoft 側(エンジニアリングチーム)で修正され、デプロイ時に 不要なパラメータ(graphBetaEndpoint)を渡さないよう変更されたことで、同じ操作でも正常に作成できるようになりました。実際に、修正反映後は “continue” タイプのカスタム拡張(Logic App) が作成できることが確認されています。

ユーザー側でテンプレートを書き換えたり、特殊な回避設定を入れたりする類の問題ではなく、サービス側の挙動修正が本筋です。

ユーザー側でやること:まず再実行、ダメならエスカレーション

まずは同じ手順で作成を再実行する

サービス側修正の反映後であれば、同じ手順をもう一度実行するだけで通る可能性が高いです。作成失敗が続くと「設定をいじらないと直らないのでは」と考えがちですが、このケースでは過度な変更は逆に切り分けを難しくします。

  1. Entra 管理センターで Lifecycle Workflows を開く
  2. 対象ワークフローの設計(または拡張の管理)画面へ移動する
  3. カスタム拡張の種類で Logic Apps を選択し、作成を再試行する
  4. 作成後に、拡張が一覧に残ること、タイプ(例:continue)が意図どおりであることを確認する

再試行の際は、失敗時に出たエラー全文をコピーできる状態にしておくと、次のステップが速くなります(後述のエスカレーション時に必須級の材料になります)。

それでも失敗する場合は、発生日時とエラー全文を添えてサポート/コミュニティへ

同様のエラーが継続する場合、ユーザー側の設定で回避できるタイプではない可能性が高いため、発生日時・エラー全文(省略しない)を揃えて、サポートやコミュニティにエスカレーションするのが最短です。相談の質は「情報の粒度」で決まるため、次の表の項目を押さえておくと、やり取りが一気にスムーズになります。

用意しておく情報具体例なぜ必要か
発生日時ローカル時刻+できればUTCもサービス側ログ照合で時間が最重要キーになる
エラー全文Deployment template validation failed を含む全体原因パターンの特定(graphBetaEndpoint の有無など)に直結する
画面・操作手順どの画面から、何を選んで、どこで失敗したか再現確認が可能になり、調査が前に進む
対象の種類カスタム拡張(Logic Apps)/タイプ(continue など)影響範囲の切り分け(特定タイプのみか)に役立つ
テナント情報テナントID(可能な範囲で)サポートが環境を特定できる
補足スクリーンショットエラー表示部分、直前の入力画面文言の取り違えや省略を防げる

サポート依頼やコミュニティ投稿用に、文章テンプレートを用意しておくと便利です。以下はそのまま使える例です。

件名:Entra ID Lifecycle Workflows のカスタム拡張(Logic Apps)作成で ARM 検証エラーが発生

発生日時:YYYY/MM/DD HH:MM(タイムゾーン:JST など)
現象:Lifecycle Workflows でカスタム拡張(Logic Apps)を作成しようとすると作成に失敗
エラー全文:Deployment template validation failed: ... graphBetaEndpoint ...
対象:カスタム拡張(Logic Apps)/タイプ:continue
補足:LCW Audit Logs に有用な記録が見当たらない(または詳細が出ない)

切り分けのコツ:似たエラーと混同しない

「Deployment template validation failed」は広いカテゴリのため、別原因でも出ることがあります。今回の不具合を最短で見分けるには、エラー文中に graphBetaEndpoint が含まれるかをまず確認するのが有効です。

エラーの特徴可能性が高い原因優先アクション
graphBetaEndpoint が明示的に出るサービス側が不要パラメータを渡す不具合パターン再試行 → 継続なら日時・全文を添えてエスカレーション
パラメータ名が別(例:locationname などの欠落)入力値不足・必須項目不整合・リソース作成条件の不一致など必須項目・選択肢を再確認し、どの値で失敗するかを特定
権限・アクセス拒否(Authorization)を示す文言がある実行者のロール不足、作成先の権限不足必要ロールの付与、管理者での再実行、権限の監査
リージョンやプロバイダー登録を示す文言があるLogic Apps の利用条件やサービス制約利用リージョン、リソースプロバイダー、制約条件の確認

もちろん現場では複合要因もあり得ますが、graphBetaEndpoint が出ているかどうかは最初の分岐として非常に強いシグナルになります。

技術背景:ARM テンプレートの「パラメータ検証」が原因特定の鍵になる

今回のエラーを理解するうえで、ARM テンプレートの基本を押さえておくと納得感が出ます。ARM ではデプロイ開始前に、テンプレート構文とパラメータの整合性をチェックします。ここで不整合があると、リソース作成に入る前に止まります。

フェーズ何をするかここで失敗するとどう見えるか
テンプレート検証テンプレート構文、パラメータの定義と入力の整合を確認Deployment template validation failed が出やすい
デプロイ実行リソースの作成・更新を実施プロバイダー側エラーや権限エラーが出やすい
完了後処理出力の確定、関連設定の反映UI上では作成済みだが後続が失敗することもある

検証フェーズで止まるということは、ユーザーが作成先のリソースグループや Logic Apps の詳細設定を触る前段階で落ちる可能性が高い、という意味でもあります。だからこそ「監査ログが薄い」「Azure 側に痕跡が残らない」状態になりやすく、今回のようなサービス側パラメータ混入が原因として浮上します。

運用の観点:再発時に慌てないためのチェックリスト

この種の“不具合起因の失敗”は、発生した瞬間にやれることが限られます。だからこそ、運用として「集めるべき情報」と「変更してはいけないポイント」を決めておくと強いです。

  • エラー全文は省略せず保存(短縮表示のまま貼らない。可能ならコピーしてテキストで保管)
  • 発生時刻を必ずメモ(タイムゾーンもセット。後から思い出すのは困難)
  • 設定変更を連打しない(原因がサービス側のとき、変更を重ねると再現条件が曖昧になる)
  • 再試行は“同一条件”で(同じ種類・同じタイプ・同じ画面遷移で、結果が変わるかを見る)
  • 成功後は必ず検証(拡張が作成できても、ワークフロー実行で期待どおりに動くかは別)

よくある質問

graphBetaEndpoint が出るなら Microsoft Graph Beta を使っているのですか?

今回の事象では、エラー文に Beta を想起する名前が出ますが、ポイントはそこではなく 「テンプレートに存在しないパラメータを渡している」点です。名前に Beta が含まれていても、ユーザーが Graph Beta を有効化する必要がある、という話ではありません。むしろ、不要なパラメータが混ざったこと自体が不具合の核心です。

Logic Apps(Azure 側)の設定やサブスクリプションが原因では?

一般論として、Logic Apps の作成には権限や利用条件が関係します。ただし今回のケースは、ARM の“検証”で落ちているため、ユーザーが調整できる Azure 側設定の問題ではない可能性が高いです。エラーに graphBetaEndpoint が含まれる場合は、まずサービス側不具合パターンとして扱い、再試行とエスカレーションを優先してください。

LCW 監査ログに何も残らないのが不安です

検証段階で止まると、ワークフローの「実行ログ」や「ステップ結果」が残らない(または薄い)ことがあります。ログが薄いこと自体は異常の証拠ではありますが、原因を断定する材料にはなりにくいので、画面に出たエラー全文と発生時刻を一次情報として扱うのが現実的です。

“continue” タイプ以外でも起こりますか?

少なくとも “continue” タイプのカスタム拡張(Logic App)が、修正反映後に作成できることは確認されています。他タイプでも似た経路でデプロイが走る場合は影響する可能性がありますが、まずはエラー文のパラメータ名と発生条件を揃えて記録し、同様のパターンかどうかを切り分けるのが安全です。

まとめ:このエラーは「ユーザーの設定ミス」ではなく「サービス側のパラメータ混入」だった

Entra ID Lifecycle Workflows でカスタム拡張(Logic Apps)が作成できず、Deployment template validation failedgraphBetaEndpoint が出る場合、原因は ARM テンプレートに存在しない不要パラメータがサービス側から渡されたことにあります。Microsoft 側で修正が入ったことで正常に作成できるようになっているため、まずは同じ手順で再実行し、継続する場合は発生時刻とエラー全文を添えてサポート/コミュニティへエスカレーションしてください。

この記事を書いた人

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

コメント

コメントする

目次