目次
先に見るのはフロー全体のSucceededではなくactionごとの履歴
Power Automateのrunが最後にSucceededと表示されても、途中のactionがSkippedになっていることがあります。これは必ずしも実行失敗ではありません。Conditionの片方のbranchを通らなかった、Run afterで前のactionの特定statusだけを許可している、Scope内の処理がスキップされたなど、設計どおりの制御フローでも起きます。
一方、後続actionが本来必要なのにSkippedなら、条件式、参照しているaction、分岐経路、Run after設定のどこかが意図と違う可能性があります。確認の順は、①Skipped actionの位置、②直前actionのstatus、③Conditionの実結果、④Run afterの許可status、⑤成功・失敗時に期待する処理です。run全体の緑色だけで処理完了と判断しないでください。
「Skipped」と「ActionConditionFailed」を分ける
Run historyにはactionごとの状態が表示され、親run全体の状態とは一致しないことがあります。Conditionがfalseになったため一方のbranchが実行されないケース、前段がSkippedだったため後段の依存条件が成立しないケース、前段の失敗時だけ動くCatch actionを通常成功時に通らないケースは、意図的なskipとしてあり得ます。
ActionConditionFailedという表示がある場合も、画面上の状態だけで不具合と決めず、該当actionのInputs、Outputs、依存するaction、Conditionの評価結果を開きます。親actionにActionFailedだけが出ているとき、Microsoftのerror referenceは実際の下流errorをaction outputで調べるよう案内しています。表面のstatus名から原因を断定せず、最初に条件が不成立となった地点を特定します。
まず、対象runでExpected pathを書き出します。たとえば「ファイルが存在するなら更新、存在しなければ作成、どちらの結果も監査ログへ記録」のように、入力条件と必要actionを列挙します。その後、run historyで実際に通ったbranchと照らせば、正常な分岐と実行漏れを区別できます。
Run historyで辿る4つの位置
1. Skipped actionの直前を開く
該当actionの直前にあるaction、Condition、Scope、Apply to eachを一段ずつ開きます。直前actionがSucceededなのか、Failed / Timed outなのか、それ自体がSkippedなのかを見ます。画面上で一つ飛ばして表示されている場合、さらに前にあるConditionやScopeの状態が実際の原因になっていることがあります。
Skipped actionのInputsに値がないことだけで判断しないでください。actionが実行されなければ入力が評価されていない場合があります。入力を組み立てるexpressionが間違っているかは、同じrunの評価済みCondition、前段Outputs、式で参照した動的コンテンツを併せて確認します。
2. Conditionの評価を入力と比較する
Conditionに使った値をrun historyから確認し、期待していた値・型・空値処理と照合します。文字列"false"とbooleanのfalse、空文字とnull、数値と文字列、タイムゾーンを含む日時は別の値として扱われることがあります。式の見た目が正しくても、実際の入力値が違えばbranch結果は変わります。
Conditionが意図しないbranchへ進む場合は、テスト入力を一つずつ固定し、条件の真偽を記録します。例外値や空の入力も試し、どの条件でtrue/falseになるか表にします。条件を削除してすべてのpathを通すことは原因特定の代わりにならず、不要な更新や通知を発生させる危険があります。
3. Run afterのstatus選択を確認する
Microsoftの公式error handling guideでは、Run afterで前のactionがSucceeded、Failed、Timed out、Skippedのどの状態だった場合に次のactionを実行するか設定できると説明しています。たとえばCatch scopeをTry scopeがFailedのときだけ動かす構成なら、TryがSucceededの通常runでCatch側がSkippedなのは期待どおりです。
後続actionを右側のメニューから設定し直すときは、どのactionへの依存を編集しているか確認します。Run afterは表示上の位置だけでなく、特定actionの結果に結びついています。前段を追加・名前変更・分岐移動した場合、後続actionの依存先が意図したstepのままかも点検します。
4. Branch・Scope・loopの境界を上へ辿る
Conditionのnot-run branch、Switchの別case、Scope内の失敗・skip、Apply to eachの特定itemなど、Skippedが発生する境界を確認します。一つのitemだけSkippedなのか、全itemがSkippedなのかを分け、run全体の集計に埋もれないようにします。Apply to eachではitem indexや元データの安全な識別子を用いて、対象itemの状態と前段結果を照合します。
判定マトリクス
表は横にスクロールできます
| 観測 | まず確認するもの | 判断の目安 |
|---|---|---|
| Condition branchの反対側がSkipped | Conditionの評価値、想定入力 | 条件がfalseで反対branchが通らない設計なら正常 |
| Catch scopeが通常runでSkipped | Try scopeの結果、Run after | TryがSucceededならCatchが動かない設計か確認 |
| 必須の成功処理がSkipped | 直前status、Run afterの許可status、依存action | 成功時に走るべきなら依存先やstatus選択を確認 |
| 前段がFailedなのに後段がSkipped | 後段Run afterとerror handling branch | 失敗を捕捉すべきならFailed statusが許可されているか確認 |
| 前段もSkippedで後段もSkipped | 最初にskipされたCondition/branch | 上流の分岐を原因として追う |
| Apply to eachの一部itemだけSkipped | itemごとの入力・Condition・依存status | そのitemのデータと分岐条件を個別照合 |
| run全体Succeededだが重要なactionがSkipped | 業務上必須のaction一覧と実path | 「Succeeded」を完了の根拠にせず、必要結果が出たか検証 |
この表は目視した状態から次に開く箇所を示します。statusだけで業務上の成功・失敗は決まりません。重要なのは、定義したCompletion Conditionを満たす出力が生成されたかです。
実例：存在するファイルは更新、なければ作成
ファイル処理フローで「対象があるときは更新、ないときは新規作成」を行う場合、最初に検索actionの結果をConditionへ渡します。対象が見つかったrunではUpdate branchが動き、Create branchはSkippedでも正常です。見つからないrunでは反対になります。
もし両方Skippedなら、Condition actionが実行されなかったのか、そのConditionより前のScopeがSkippedなのかを見ます。Create branchだけ必ず実行したいと考えて条件分岐を外すと、既存ファイルを重複作成することがあります。想定する結果は「片方のbranchが実行される」であって「全actionがSucceeded」ではありません。
UpdateがSkippedなのにrun全体がSucceededの場合、対象が存在したか、Conditionが意図した判定をしたか、Updateの前提となる上流actionがSucceededだったかを照合します。run後の最終データや出力を確認し、必要なファイルが本当に更新されたことまで確認して完了とします。
失敗処理の設計を点検する
通常処理とエラー処理をScopeへ分ける場合、Try scopeのFailed / Timed out時にCatch scopeを実行し、必要なerror detailsを安全に記録する設計が候補です。成功時にCatchがSkippedになるのは正常です。MicrosoftはRun afterとScopeを使ったtry-catch型のerror handlingを案内しています。
retry policyは一時的なネットワーク・サービス障害などtransient fault向けです。Microsoftのガイドは固定間隔とexponential intervalの設定を説明し、頻繁なretryでシステムを過負荷にしないよう指数的間隔を推奨しています。論理Conditionがfalseのケースや必須入力の欠落は、retryで直るとは限りません。失敗の種類を見ずにすべてのactionへretryを追加しないでください。
error loggingにはrun ID、action名、発生status、必要なerror codeなどを最小限記録します。token、個人情報、完全な入力payloadを不用意に保存しないようにし、ログaction自体が実行回数とフロー負荷を増やす点も考慮します。
調査から修正までの手順
-
完了条件を定義：フローが成功したと言える業務結果を一文で書き、どのactionが必須か決める。
-
対象runを固定：run ID、対象item、開始時刻を記録し、同じ条件のrunと比較できるようにする。
-
最初の不一致を探す：Expected pathとactual pathを並べ、最初に条件またはstatusが想定と異なる地点を特定する。
-
値と式を照合：評価済みCondition、前段Outputs、空値・型・日付形式を確認する。機微値はマスクする。
-
Run afterを確認：依存actionと許可statusが設計どおりか、branch・Scopeの変更後に古い依存が残っていないかを見る。
-
最小修正をテスト：正常・条件不成立・前段失敗・timeoutを再現するテスト入力を用意し、分岐と記録を確認する。
-
結果を確認：run statusだけでなく、必要なデータ更新・作成・通知が一度だけ行われたか、不要な処理が行われていないかを検証する。
修正を本番flowへ適用する必要がある場合は、通知・データ更新・外部連携への影響を確認し、変更・rollback手順を用意します。この記事は個別flowの実行や接続を確認していません。具体的な設定変更は対象環境のownerと運用条件に沿って行います。
よくある誤り
「Skippedは全部エラー」：条件分岐で実行されないbranchや、失敗時だけ動くCatch actionは、正常runでSkippedになり得ます。
「runがSucceededなら全部完了」：Succeededはrun全体の状態です。業務上必要なactionが実行されたか、期待するデータが生成されたかは別に確認します。
「Run afterを全部のstatusへ広げれば直る」：Failed後に成功時処理まで動かすなど、副作用や不整合を招く場合があります。必要なstatusだけを設計に合わせて許可します。
「Conditionを外せば原因が分かる」：入力を制御しないテストは誤作成や二重通知を発生させる可能性があります。再現用データで真偽を記録します。
「CatchがSkippedならエラー処理が壊れている」：Tryが成功したときCatchを動かさないRun after設定なら正常です。Tryの実結果を見て判断します。
テストケースの作り方
少なくとも次の入力経路をテストします。
・Conditionがtrueとなり、true branchの必須actionが一度実行される。
・Conditionがfalseとなり、反対branchがSkippedであっても期待結果が成立する。
・前段actionを意図的に失敗させ、Run afterで指定したCatch / error handlingが動く。
・前段actionがTimed outまたはSkippedのとき、後続actionが意図したstatusに従う。
・Apply to eachで複数itemのうち一部が分岐し、各itemの結果が正しい。
それぞれでrun status、action status、Condition結果、期待した副作用、重複・欠落を記録します。テストで意図的に外部メールを送る、Productionデータを更新するなどの副作用がある場合は、テスト環境と安全な宛先を使用してください。
公式資料と確認範囲
次のMicrosoft Learn公式資料を2026-10-15に確認しました。Error handlingはRun afterでSucceeded / Failed / Timed out / Skippedを条件にし、Scopeによるtry-catch型設計を説明しています。error referenceはActionFailedの下流出力確認を案内しています。個別flowの実行履歴、設定、ユーザーデータは未確認です。
・Employ robust error handling：https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/error-handling（新しいタブで開く）
・Cloud flow error code reference：https://learn.microsoft.com/en-us/power-automate/error-reference（新しいタブで開く）