外部サービスからPower Automateのフローを呼び出していたのに、通知・Webhook・HTTP要求が届かなくなった場合は、まず旧URLの移行対象かを確認します。2025年11月30日以降、Microsoft Learnは、Logic Appsアーキテクチャ上のPower Automate環境にあるHTTPまたはTeams Webhookトリガーで、URLにlogic.azure.comを含む旧URLは動作しなくなると案内しています。該当フローでは、トリガーカードに表示される現行URLへ外部参照を更新し、呼び出し元から再試験する必要があります。
ただし、名前に「Webhook」が付くものすべてが対象ではありません。Azure Logic Appsリソース、Teamsの旧Office Webhook、任意のHTTP APIまで一括して移行する話ではありません。対象はPower Automateの特定のtrigger、URL、環境アーキテクチャの組み合わせです。対象を確認する前にフローを作り直したり、URL文字列を手で書き換えたりしないでください。
目次
最初に対象範囲を判定する
Microsoft Learnが示す2025年の変更対象は、HTTP triggerまたはTeams Webhook triggerを使用し、環境がLogic Apps architectureで、trigger URLにlogic.azure.comを含むPower Automate flowです。Self Host MultiTenant（MTA）環境はこの旧URL移行の対象外とされています。まず環境とtriggerを確認し、対象外ならこの移行だけを原因と決めつけないでください。
環境アーキテクチャはPower Automateで対象Environmentを選び、Ctrl+Alt+Aでenvironment debug infoを表示し、environmentFlowHostingTypeの値を調べる方法がMicrosoft Learnに記載されています。値がLogicAppsなら現在のアーキテクチャ、SelfHostMultiTenantなら新しいアーキテクチャです。画面操作や管理権限が異なる場合は、Power Platform管理者へ確認してください。debug infoの値や環境名には組織情報が含まれることがあるため、公開の問い合わせへ貼り付けないでください。
|確認軸|対象を示す状態|次の判断|
|サービス|Power Automate cloud flow|Azure Logic Apps resourceなら別の移行情報を確認|
|trigger|HTTPまたはTeams Webhook|別種triggerならこの旧URL変更の対象と即断しない|
|環境|environmentFlowHostingTypeがLogicApps|SelfHostMultiTenantはこの変更の対象外|
|旧URL|trigger URLにlogic.azure.comがある|現行trigger cardのURLを確認|
|呼出し元|そのURLを保存している外部システム・親flow|呼び出し元ごとに参照箇所を棚卸し|
旧URLと2026年のURL形式変更を混同しない
Microsoftの現行トラブルシューティング資料には、別時点の二つの変更が記載されています。第一は、2025年11月30日以降、対象環境のHTTP / Teams Webhook triggerで旧logic.azure.com URLが停止する移行です。第二は、2026年6月2日から、HTTP trigger callback URLにscale unit識別子が含まれる形式変更です。第二の説明では新しい形式を使うと性能面で推奨される一方、以前のcallback形式も引き続き動作するとされています。
この「旧URLも動く」という記述を、2025年に移行対象となったlogic.azure.com URLの復活と解釈しないでください。旧ドメイン移行と、新しいcallback URL経路でのパス形式変更は別の話です。実際に使うべき値は文字列を推測して生成せず、該当flowのtrigger cardまたはMicrosoftが指定する管理画面からコピーした現在のURLです。URLのホストやパスだけを置換すると、認証情報やrouteが壊れます。
影響するflowと呼出し元を洗い出す
まず対象environmentでflowを特定します。管理権限がある場合、MicrosoftはMicrosoft.PowerApps.Administration.PowerShellのGet-AdminFlowWithMigratingTriggerUrlを使い、移行対象URLを持つflowを列挙する方法を案内しています。権限がない場合は、flowの詳細画面に警告が表示されるか、対象trigger cardに旧URLに関する案内があるかを確認し、管理者へ対象flow名を問い合わせます。
次に、旧URLを保存した場所を一つずつ探します。外部のWebアプリ、スクリプト、監視サービス、フォーム、別のPower Automate flow、Teams連携、設定ファイルなどが候補です。URLを検索するときは、秘密情報を含むURL全体をチケットやチャットへ貼らないでください。ドメイン・パスの種類と保管場所だけを記録し、署名付きquery parameterやtokenはマスクします。
|呼出し元の種類|調べる場所|更新時に残す記録|
|外部アプリ・サービス|endpoint設定、環境変数、接続設定|system名、owner、変更日時、試験結果|
|親Power Automate flowのHTTP action|子flowを呼び出すactionと環境|親flow ID、参照action、更新者|
|Teams Webhook利用先|Webhook設定・通知先の管理画面|対象channel/system、管理者、試験結果|
|スクリプト・定期処理|secret管理やjob設定|保存先の識別子、更新担当、実行ログ|
|Power AutomateのRun a child flow|子flow呼び出し方式|この方式ならURL差し替えが不要か確認|
親flowがHTTP actionで子flowを呼び出している場合、Microsoftは親flowを外部システムと同様に扱い、子flowのtrigger cardに表示される新URLへ更新するよう案内しています。一方、Run a child flow actionを使う呼び出しは、このURL変更のための差し替え不要とされています。画面上の名前だけで判断せず、実際のaction種別を確認します。
現行URLを安全に更新する
対象flowを開き、HTTPまたはTeams Webhook trigger cardに表示された現在のURLをコピーします。URLを手作業で組み立てず、host、path、query stringの一部を編集しないでください。署名・SAS認証などの秘密値を含むことがあるため、URL全体を公開ログ、Issue、スクリーンショットへそのまま載せないようにします。変更前後の値を記録する必要があるときは、完全なURLを制限されたsecret保管先で扱い、通常の変更記録にはマスク済みの識別情報を残します。
更新前に、呼出し先の入力仕様とHTTP method、body、headerが変わっていないかも確認します。URL更新だけであれば通常は呼び出し先設定の差し替えが中心ですが、認証設定やtrigger inputを同時に変えないでください。原因と修正の対応を追えるよう、変更対象を一つずつにします。
新URLが255文字を超えることがある点も確認します。Microsoftは特にShared Access Signature（SAS）authenticationの場合にURLが255文字を超える可能性を挙げ、呼出し元が長いURLを保存・送信できるか確認するよう案内しています。255文字はすべての呼出し元の共通上限と断定する数字ではなく、互換性を点検するための警告です。実際の上限は呼出し元の製品仕様と設定で確認します。上限を超える場合、URL短縮サービスで秘密値を隠すのではなく、承認されたproxy/API management等の構成を管理者と検討してください。
relative pathを使うtriggerでは、relative path欄にbackslash（\）が含まれていないか確認します。Microsoft資料は、欄内のbackslashが二重slash errorにつながる可能性を示しています。既存値を変える前にtrigger cardと生成URLを比較し、必要な変更だけを適用してテストします。
テストは呼出し元から行い、Run historyまで照合する
保存後のテストは、Power Automateの手動テストだけで終わらせず、実際の呼出し元から安全なtest payloadを送ります。処理が業務データを作成するflowなら、重複登録や通知送信を防げるテスト環境・テストレコードを使います。本番データに対して検証する場合は、組織の承認済み手順に従ってください。
|検証段階|確認すること|不合格時の次の確認|
|呼出し元の設定|新URLを保存し、完全なURLが切れていない|設定欄の長さ制限、引用符、改行、secret redaction|
|送信|正しいHTTP method、body、headerで要求した|呼出し元の送信ログ、network、proxy|
|trigger|flowが起動し、期待する入力を受け取った|trigger URL、 relative path、認証、run history|
|処理|対象actionが成功し、意図した結果になった|action別エラー、connection、権限、DLP|
|重複|一回の試験で意図しない複数処理がない|再送・retry、重複した呼出し元、idempotency|
失敗したら、まずエラー時刻と相関できるflow runを検索します。Run historyに実行がないなら、要求が正しいtriggerへ届かなかった、認証で拒否された、外部システムに古い参照が残るなどを調べます。runが存在しているなら、URL移行ではなく、trigger condition、connection、権限、後続actionの失敗へ切り替えます。Microsoftの一般trigger troubleshootingも、特定runを識別してtriggerと後続処理を分ける診断を推奨しています。
旧URL移行後も止まる場合
旧URLを置き換えたあとに連携が動かない場合、すぐにflowを複製しないでください。次の順で未解決点を分離します。
-
environmentFlowHostingTypeとflowの環境が対象条件に一致していたか再確認する。
-
URLが移行後のtrigger cardからコピーした完全な値か、query末尾まで保存できたかを確認する。secretは共有せず、管理された安全な比較方法を使う。
-
呼出し元の設定が実際に新しい値を使っているか、deploy・cache・環境別設定を確認する。
-
HTTP method、payload、header、認証方式、URL長の制約を呼出し元の公式仕様と照合する。
-
relative path欄にbackslash（\）が含まれていないか確認し、生成URLとの整合を確認する。
-
同じ時刻のPower Automate run historyを開き、trigger未到達とaction失敗を区別する。
-
移行後形式のURLを使っている場合、2026年6月のscale unit path変更を含む現行URLが表示されているか管理画面で確認する。pathを手で追加・削除しない。
-
呼出し元からtest requestを再送し、起動回数と結果を記録する。
MTA環境、対象外のtrigger、またはAzure Logic Appsそのものなら、この移行手順をそのまま当てはめません。各製品・環境の公式資料と管理画面で対象を確認し直します。原因が特定できず、flow runも呼出し元の送信記録もない場合は、URLだけの問題と断定せず、運用担当・管理者へ両側の記録を渡します。
移行完了の記録
すべての呼出し元を更新したら、次の記録を残します。完全なtrigger URLやSAS tokenは監査票に保存せず、secret vaultの参照名、対象flow ID、呼出し元名、更新者、時刻、結果を使います。
|記録項目|保存する値|
|対象判定|Power Automate / trigger種別 / environment architecture|
|旧URLの痕跡|旧domainがあったか。秘密queryは保存しない|
|現行URL|trigger cardから取得したこと、取得日時、secret保管先の参照|
|呼出し元|参照箇所、owner、更新状態、未更新理由|
|検証|test request時刻、flow run ID、triggerと処理結果、重複有無|
|残課題|URL長制約、権限不足、未特定参照、管理者対応|
変更の完了条件は、旧URLらしい文字列が検索で見つからなくなることだけではありません。対象flowの範囲が正しく、すべての有効な呼出し元が現行URLを使い、安全なtest requestがflow runとして記録され、後続処理の結果まで確認できた状態です。テストできない呼出し元やowner不明の参照は、完了扱いにせず担当と次の確認日を残します。
Microsoft公式情報
-
Troubleshoot common problems with Power Automate triggers（2025年11月30日のlogic.azure.com移行、対象環境、URL更新、255文字、relative path、2026年6月形式変更）: https://learn.microsoft.com/en-us/troubleshoot/power-platform/power-automate/flow-run-issues/triggers-troubleshoot（新しいタブで開く）
-
Power Automate environments move to new architecture（environmentFlowHostingTypeの確認、LogicAppsとSelfHostMultiTenant）: https://learn.microsoft.com/en-us/power-automate/environment-architecture（新しいタブで開く）
公式情報は2026年10月15日に確認しました。記事は一般的な移行確認手順です。特定のテナント、flow、呼出し元で移行や疎通を実行した記録ではありません。表示名や画面は更新されるため、現行のMicrosoft Learnと対象environmentの管理画面で確認してください。