Power Automateの「ActionFailed」とSkippedを見て最初の失敗箇所を特定する

Power AutomateのActionFailedとSkippedが出たrunから、最初に失敗したアクション、API応答、Run after設定を確認し、原因を切り分けます。

確認日 2026年10月18日AIものさし編集部

Power Automateのrun全体がFailedになり、後続アクションがSkippedになっていても、画面の最後に表示された「ActionFailed」が根本原因とは限りません。Microsoft LearnではActionFailedを、実際のAPI応答や子フローなどの詳細を包む一般的なエラーとして説明しています。まずrun historyでScopeを展開し、最初に失敗した処理、その直前の結果、Run after設定を確認します。条件に合わず意図的にSkippedになった処理と、前段の失敗を受けて動かなかった処理を分ければ、直す場所を絞れます。

例外通知を作ったのに届かないときは、通知アクションが失敗した処理の「あと」に設定されているかも確認します。既定の成功後実行のままでは、前段が失敗したとき通知処理も実行されない場合があります。状況を決めつけず、run historyと各アクションのConfigure run afterを照合してください。

最初の赤いActionを探す

対象runを開き、全体のFailed表示から各Scope、Apply to each、条件分岐へ進みます。
最後に失敗したラッパー表示だけで止まらず、内側のアクションを展開します。
最初に失敗したActionのOutputsを確認し、実際のstatus code、API message、request IDを記録します。
そのActionのInputsと直前の成功出力を比べ、接続先、対象resource、必須値、式、型、権限など次に検証する仮説を絞ります。
エラー本文やrun inputに顧客データ、メールアドレス、tokenが含まれる場合、記録を共有する前に伏せます。

ActionFailedは原因そのものではなく、失敗状態を伝えるラッパーであることがあります。Microsoftのerror referenceは、action outputの詳細を開いて実際のAPI errorを確認するよう案内しています。403ならDLP・resource permission・tenant restriction・licenseの候補、401ならconnection認証、400なら入力形式など、コードに合う公式資料へ進みます。短いメッセージだけで原因を断定せず、そのrunのAction outputを優先してください。

Skippedを二つに分ける

Skippedは表示だけで異常と判断しません。条件の結果としてactionが意図的に実行されなかった場合と、依存する前のactionが失敗・timeout・cancelledとなり、その結果として実行されなかった場合があります。どのRun after条件が有効かを確認し、前段actionの状態と組み合わせて解釈します。

表は横にスクロールできます

観察した状態	確認する箇所	次の判断
Conditionの片側だけSkipped	Conditionの評価結果、入力値	選択されなかった枝なら想定どおりか確認
前段がFailedで後段がSkipped	後段のConfigure run after	Failed時にも実行する設定か、既定条件のままか確認
Timeoutの後に通知がSkipped	Timeoutの扱い	Timed out条件がRun afterに含まれているか確認
Scope内にActionFailedがありScopeもFailed	Scopeを展開し最初の内部Failureを確認	内側の原因を直す。外側の表示だけでは原因を確定しない
Scope内のActionFailedだけでは原因不明	Action output / scope history	最初に失敗した内部Actionと、後続の依存失敗を分けて確認

Try / Catch / Finallyの依存を確認する

複数のactionをScopeにまとめるとき、Try、Catch、Finallyという名前を付けただけでは例外処理になりません。各Scopeがどの前段Scopeの結果を受けて動くか、Run afterを設定して初めて経路が決まります。Try内の最初の失敗をcatchで処理するなら、Catch側のScopeがTryのFailed（必要に応じてTimed out）に対して実行される設定かを確認します。最後の記録処理をFinallyとして置く場合も、成功・失敗・timeoutのどの状態で動くかを明示します。


Try Scope

  ├─ 通常処理がすべて成功 → Catchは実行しない → Finally

  ├─ ActionがFailed → Catchを実行 → Finally

  └─ ActionがTimed out → timeoutを捕捉する設定があればCatch → Finally

この図は構成の考え方です。Power Automateの実際のScope、Configure run after、終了アクションの設定を画面で確認し、想定したrunだけでなく成功・失敗・timeout・意図的skipの各ケースを検証します。Catchの中で通知アクションが再び失敗した場合、最初の原因と通知側の二次エラーを分けて記録してください。

具体例：更新失敗時に通知する

例として、SharePoint行を更新した後に通知するflowを考えます。更新が成功したときだけ完了通知を出すなら、通知のRun afterはSucceededを対象にします。更新に失敗したときに管理者へ通知したいなら、別の通知Actionを作り、そのRun afterをFailedへ設定します。失敗通知の本文には、run ID、flow名、失敗Action名、機密を除いたエラー要約などを入れ、顧客レコードや接続tokenはそのまま転送しません。

更新actionが実際には成功しているのに、通知の式が壊れて全体がFailedになった場合もあります。最初に赤いActionが通知なら、SharePoint更新をやり直す前に通知の式・参照名・Run afterを見ます。最初に赤いActionが更新なら、通知Actionを直すより更新先の権限、対象ID、接続状態、入力データを確認します。これが「最後の表示」ではなく「最初に失敗したAction」を探す理由です。

4ケースで検証する

Run afterやCatchを変更したら、テスト環境または機密を含まないテストデータで最低限次を確認します。

表は横にスクロールできます

ケース	入力・状態	確認する結果
成功	必須値を満たす正常データ	通常処理が成功し、成功経路の通知だけが実行される
Action失敗	テスト用の無効な参照や拒否されたテスト操作	最初の失敗Actionが判別でき、想定したCatch/通知が動く
Timeout	安全に再現できる遅延・timeout条件	timeout時のRun after経路が意図どおりか確認
条件によるSkip	Conditionが片側だけを選ぶデータ	選ばれなかったbranchのSkippedが正常扱いされる

実環境で故意に本番処理を失敗させる必要はありません。再現しにくいケースはテスト条件を作るか、既存runの記録から静的に設定を確認し、「実行検証済み」と「設定レビューのみ」を分けてください。テストでは通知が一度だけ届くこと、Catch内エラーを元のエラーと混同しないこと、finally相当の後処理が必要な状態で実行されることを確認します。

よくある原因と直し方

ActionFailedだけを見て同じActionを再実行する： まずOutputsを開き、実際のAPI errorや子フローの失敗を確認します。
後続がSkippedなので、そのActionを修正する： 先行処理の状態とRun afterを見ます。後続actionは単に依存条件を満たさなかった可能性があります。
Catchを作ったのに通らない： Catch Scopeとその先頭ActionのConfigure run afterを確認します。FailedだけでなくTimed outを扱う必要があるかは要件ごとに判断します。
「Succeeded」の通知しかなく失敗通知が届かない： 成功通知とは別にfailure pathを作り、Run afterでFailedを指定します。
エラー全文をチャットへ貼る： run ID、Action名、status、機密を伏せた要約に置き換えます。
全体Failedを直すため最後のActionを変更する： 最初の失敗Actionと後続cascadeを分離してから変更します。

Error reference上のActionFailedは、下流APIが返した4xx/5xx、child flow、予期しない応答、Run after条件などが関係し得る一般的な状態です。原因を一つに決めつけず、run historyの証拠から分岐します。エラー表示は製品更新で変わることがあるため、現行の公式エラー項目と画面表示を照らし合わせてください。

管理者へ渡す最小情報

調査を引き継ぐときは、次の項目をまとめます。

Flow名またはID、Environment、run ID、発生日時
最初に失敗したActionとScope内の位置
status code、request ID、機密を除いたerror summary
直前のAction statusとConfigure run afterの条件
接続名・接続状態（secret値は含めない）
直近のflow、connection、policy変更
成功/失敗/timeout/skipテストのうち確認できた範囲
実行検証、設定レビュー、未確認事項の区別

run historyを共有する前にInputs/Outputsへ個人情報や機密が含まれていないか確認します。診断目的で必要な情報を確保しつつ、機密値を社内チャット、メール、課題管理ツールへコピーしないようにします。

次に行うこと

失敗したrunを一つ選び、外側のFailed表示からScopeを展開し、最初の失敗Actionを特定してください。そのActionのOutputsにある実際のエラーを読み、Run afterの条件と後続Skippedを対応表にします。原因を一つに絞って修正し、成功・失敗・timeout・意図的skipを機密のないテストデータで確認します。Failure通知が必要なら、失敗処理の後に分岐する設定まで確認してから運用へ戻します。

出典（確認日：2026-10-15）

Microsoft Learn, Cloud flow error code reference: https://learn.microsoft.com/en-us/power-automate/error-reference（新しいタブで開く）
Microsoft Learn, Employ robust error handling: https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/error-handling（新しいタブで開く）
Microsoft Learn, Troubleshoot cloud flow errors: https://learn.microsoft.com/en-us/power-automate/troubleshoot-flow-errors（新しいタブで開く）

注：この記事は公式資料に基づく一般的な診断手順です。特定テナントのFlowで実行確認はしていません。