AIものさし

Power Automateでフローが起動しないときrun history前にトリガーを切り分ける

Power Automateのフローが有効でも起動しないとき、run historyを見る前にトリガー条件とイベントを切り分けます。

AIものさし編集部

フローを保存して有効にしたのに、期待したイベントが起きても実行履歴が増えない。そんなときは、アクションの設定を最初から見直すより、まず「イベントが発生したか」「トリガー条件で除外されていないか」「トリガー自体の登録や接続に問題がないか」を分けて調べます。Power Automateでは、トリガー条件が満たされない場合、フローは起動せず、実行履歴も作られません。一方で、最初の実行前にトリガー登録エラーが表示されることもあります。

まず対象フロー、環境、イベントの発生時刻を記録し、影響の小さいテスト入力を1件だけ用意してください。その入力が条件を満たすか、フローの接続が有効かを順番に確認すれば、イベント未発生・条件による除外・接続や環境側の問題を切り分けられます。原因が分からないままトリガーを削除して作り直したり、フローを停止・再開したりするのは後回しにします。設定を変えると、元の原因や再現条件が分からなくなることがあるためです。

目次

まず「履歴がない」の意味を分ける

実行履歴が空という表示だけでは、フローが壊れているとは断定できません。最初に、確認したいのが「今発生したイベントの記録」なのか、「以前の実行記録」なのかを分けます。

Microsoftの履歴欠落に関するトラブルシューティング（2024年9月更新）は、既定で28日保存と説明しています。一方、現行のPower Automate limits資料（新しいタブで開く）は、run開始時からの保存期間を30日と記載しています。資料の記載に差があるため、28日・30日のどちらかを全環境へ一律に当てはめず、対象環境の保持設定と表示範囲を確認してください。管理者がDataverse上のCloud flow run history機能を使って保持日数を管理している環境では、設定が異なる場合があります。したがって、古い実行が見えないことと、現在のトリガーが動いていないことは別の問題です。今回のテスト入力を発生させた時刻を記録し、その直後の新しい履歴があるかを確認してください。

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

見えている状態まず確認すること次の調査先
過去の実行だけ見つからない対象環境の保存・表示期間外か期間・管理者の履歴保持設定
新しいテストイベント後も履歴がないイベントが対象フローの条件に合うかトリガー条件・イベント値
履歴に失敗したRunがあるどのアクションで失敗したかRun detailsの入力・出力
詳細画面にトリガーの問題が表示されるトリガー登録や接続エラーの本文Fix the trigger / underlying error

1. テストイベントを一件に絞る

「イベントがあったはず」という記憶だけでは、条件式の診断材料として足りません。対象となるサイト、リスト、フォルダー、メールボックス、テーブルなどを特定し、テストに使ったレコードやファイルの識別子、作成・変更時刻、実行ユーザーを控えます。共有リソースなら、フロー所有者の接続がその場所へアクセスできるかも確認します。

トリガーによってはイベントを一定間隔で確認するため、操作直後に履歴が出ないことがあります。画面に表示される確認間隔や、対象コネクタの公式説明を見て、即時実行型かポーリング型かを確かめてください。待ち時間が分からない場合は、その点を「未確認」とし、すぐに故障と決めつけないようにします。診断のためのテストイベントを短時間に何度も作ると、重複処理や通知などの副作用が起こり得ます。まず一件で結果を見ます。

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

記録項目例として残す内容
対象フローフロー名、フローID、環境
対象イベントどのリソースで何を作成・変更したか
発生時刻タイムゾーンを含めた時刻
テスト値条件判定に使う列・状態・値
実行主体誰の接続・権限でイベントを作ったか
観察結果履歴なし、条件スキップ、トリガーエラーなど

2. トリガーが有効か、接続が生きているか

Power Automateのフロー詳細画面で対象フローを開き、トリガーに問題があるというバナーがないかを確認します。「There's a problem with the flow's trigger」のような表示がある場合は、Fix the triggerから根本のエラーを開きます。トリガーが初回実行前に失敗していると、通常のRun historyがまだなくても詳細画面に問題が示される場合があります。

Microsoftの説明では、トリガー失敗に含まれる4xx系はユーザー側で直す必要があるエラーであることが多く、接続の変更や無効な入力、Webhookトリガーの登録失敗などが例として挙げられています。5xx系は一時的なシステム問題であることが多いとされています。ただし、ステータスコードだけで原因を確定せず、表示された具体的なメッセージと発生時刻を記録します。5xxが見えた場合も、解消したと判断できるまでは再テストで確認します。

次に、トリガーが使う接続を確認します。接続一覧で状態が切れていないか、認証をやり直す必要がないか、接続所有者のアカウントが無効化・削除されていないかを見ます。接続が「接続済み」と表示されていても、実際に対象リソースを読めるとは限りません。共有メールボックスなら送信・参照権限、SharePointなら対象サイトやライブラリへの権限など、トリガー対象そのものへアクセスできるかを確認してください。権限を変更する必要がある場合は、組織の管理者に確認します。

3. トリガー条件とテスト値を照合する

トリガー設定のTrigger conditionsに式がある場合、イベントの内容がその条件を満たさなければフローは起動しません。条件未達のイベントはRun historyに記録されないことがあるため、履歴がないときはここが重要な確認箇所です。

Power Automateデザイナーでトリガーカードを開き、SettingsのTrigger conditionsを確認します。条件が空なら、追加のカスタム条件による絞り込みはありません。条件がある場合は、式を読んだつもりで判断せず、今回のテストイベントに入っている実値と一項目ずつ照合してください。

たとえば条件が「StatusがApprovedのとき」なら、テストレコードのStatusが実際にApprovedであるか、比較している値が表示ラベルなのか内部値なのか、空白・大文字小文字・型の違いがないかを見ます。式が複数条件を含む場合は、どの条件が偽になったかを分解します。これは診断例であり、利用中のトリガーや列名がこの例と同じだと仮定するものではありません。

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

確認記録するもの
条件式Trigger conditionsに保存されている式
対象フィールド式が参照する列・プロパティ
テストイベント値イベント受信時点の実データ
判定条件ごとのtrue / false
期待との差どの値・型・条件でずれたか

条件を一時的に外して試す方法は、意図しないデータを処理する可能性があります。業務フローではその場で条件を無効化せず、テスト環境や複製フローなど、組織の安全な検証手順を使ってください。テスト環境がない場合は、管理者と相談してから設定変更します。

複数のTrigger conditionsを「どれか一つ」と読まない

Microsoftの案内では、Trigger conditionsへ複数の式を追加した場合、既定ではすべてを満たす必要があります。「Approved、またはHighのどちらかなら起動」を意図して二つの式を別々に追加すると、両方を満たすイベントだけが対象になってしまいます。どれか一つを満たせばよい場合は、ORの関係を一つの式として表します。Microsoft：Customize your triggers with conditions（新しいタブで開く）

以下は、イベント本文に文字列のStatusとPriorityが直接入る架空の例です。SharePoint等の実際の列がこの形で届くとは限りません。対象トリガーの出力構造を先に確認し、プロパティ名と値を置き換えてください。

@or(equals(triggerBody()?['Status'], 'Approved'), equals(triggerBody()?['Priority'], 'High'))

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

StatusPriority二条件を別々に追加した場合の期待上のOR式の期待
ApprovedNormal起動しない起動
DraftHigh起動しない起動
ApprovedHigh起動起動
DraftNormal起動しない起動しない

この表は論理の説明で、実フローの実行結果ではありません。フィールド欠損、オブジェクト型、内部値と表示名の違いは、この四行だけでは検証できません。入力構造が不明なら、条件を外して業務フローを起動するのでなく、必要な形のテストデータを用意できる環境で確認します。

修正前の条件式、意図したAND/OR、各式の真偽、最終判定を一組に残します。期待と合わない場合は、フィールド参照の問題か論理の組合せの問題かを分けてから変更してください。

4. トリガー登録エラー、環境、ポリシーを調べる

条件と接続に問題が見つからず、トリガー登録のエラーが出ている場合は、エラーの本文を確認します。Webhook型トリガーでは、サービス側がトリガーを登録できないことが原因になる場合があります。組織ネットワークの許可リスト、接続先の変更、認証ポリシーなどが関係していないか、エラー内容を添えて管理者へ確認します。Webhookの登録失敗がすべてネットワーク制限によるとは限りません。

フローの状態がSuspendedまたは組織によって停止されていないかも確認します。Microsoftの案内では、DLPポリシーに違反したフローは停止され、トリガーが動かない場合があります。フローチェッカーや詳細画面に組織ポリシーの警告が出ていれば、ポリシー変更を自分で試さず、管理者にどのポリシーが該当したかを確認します。

環境の管理モードも、対象フローが使うトリガーに応じて確認します。たとえばDataverseトリガーはバックグラウンド処理に依存するため、環境でそれが停止されている場合、トリガーが動かないことがあります。これはすべてのトリガーが管理モードの影響を同じように受けるという意味ではありません。環境ID、トリガーの種類、管理モードの状態を管理者と一緒に確認します。環境URLの変更後に問題が始まった場合も、変更時期と対象コネクタを記録してから、公式トラブルシューティングにある該当ケースを確認してください。

プレミアムコネクタのトリガーを使っている場合は、フロー詳細に表示されるライセンスと、組織で割り当てられている利用権を確認します。すべてのトリガーに同じライセンス条件が適用されるわけではありません。対象コネクタがプレミアムかどうか、フローの所有者・実行者に必要なライセンスがあるかを管理者に確認し、記事上の一般論だけで契約状態を判断しないでください。

5. 観察結果から次の手を選ぶ

切り分けの目的は、思いついた修正を順番に試すことではありません。観察結果と次の確認先を結びつけ、変更前に原因候補を狭めることです。

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

観察結果判断次の一手
テストイベントが発生していないフロー以前の入力・操作を確認対象システムでイベント記録を確認
条件式がテスト値を除外するTrigger conditionによる未起動の可能性条件とイベント実値の対応を確認
詳細画面にtrigger errorがある登録、接続、入力などのエラー候補エラー本文とステータスを保存
接続が壊れている／認証要求がある接続・権限の問題候補接続所有者または管理者へ再認証を依頼
Flow checkerにDLP等の警告がある組織ポリシーの影響候補管理者へポリシー名・対象環境を確認
Dataverse対象で管理モードが有効背景処理の停止が関係する可能性環境管理者へ設定・変更履歴を確認
Run自体はあるがアクションで失敗トリガーは起動しているRun detailsから失敗アクションを調べる

確認結果を記録するまでは、トリガーの削除・再作成、接続の差し替え、フローの停止・再開をしないでください。Microsoftの一般的なトラブルシューティングには、設定を変えて再登録を試す手順もありますが、業務データを処理するフローでは重複実行やデータ欠落が起こらないかを先に確認する必要があります。変更が必要なら、変更前の設定を保存し、影響範囲を把握してから実施します。

6. 再テスト記録の残し方

修正または原因確認の後は、同じ条件で一件だけ再テストします。テスト入力、発生時刻、期待した条件判定、実際の履歴、トリガーまたはアクションのエラーをまとめて残してください。再テストでRunが作られた場合も、その後のアクションが最後まで成功したかは別に確認します。トリガーが起動したことと、業務処理全体が成功したことは同じではありません。

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

試行入力の識別条件判定期待観察した結果次に進む先
1レコードID等条件ごとの値起動 / 除外履歴なし / runあり / error原因候補
2修正後の1件条件ごとの値起動run状態とアクション結果完了 / 追加調査

自分の権限で設定や環境状態を確認できない場合は、フローID、環境、トリガー名、テスト時刻、条件式、エラー表示を整理して管理者へ渡します。管理者に「フローが動きません」とだけ伝えるより、どのイベントをどの条件で試し、何が観察されたかが分かる方が調査が進みます。

この順番で切り分ける理由

Run historyに失敗があるなら、まずそのRunのアクションを調べます。今回のイベントに対応するrunが作られていないと確認できれば、そのrunのアクションはまだ実行されていません。保存期間外や閲覧条件による非表示とは分けます。条件でイベントが除外されているのか、イベントが起きていないのか、トリガー登録・接続・環境ポリシーのいずれかが止めているのかを先に分けます。ここを飛ばして後続アクションを編集すると、原因とは関係のない変更が増えてしまいます。

診断の第一手は、「テスト入力を一つ決める」「発生時刻を記録する」「条件式と実値を照合する」「詳細画面のトリガーエラーを読む」です。ここまで分かれば、設定変更が必要なのか、接続所有者や管理者へ依頼するのか、イベント側を直すのかが見えてきます。

FAQ

履歴が空なら、フローは一度も起動していませんか？

現在の表示期間に新しいRunがないことは分かりますが、過去に一度も動いていないとは限りません。履歴欠落のトラブルシューティングには28日、現行limits資料には30日の記載があるため、対象環境の保持設定と表示範囲を確認します。今回のイベントを発生させた時刻と、新しいRunが作られたかで確認してください。

Trigger conditionに何か書かれているか分かりません。

トリガーカードのSettingsを開き、Trigger conditions欄を確認します。式があれば、テストイベントの実データを式へ代入するように条件ごとに照合します。値が画面表示と内部値で異なる場合もあるため、イベント出力と対象フィールドを確認してください。

すぐにトリガーを削除して作り直してよいですか？

原因が分からない状態では避けてください。Webhook登録エラーの修復などで再登録が必要な場合はありますが、設定変更によりフローの動作や処理対象が変わる可能性があります。変更前の設定、テスト条件、重複実行への対策を保存してから、必要な場合だけ管理者やフロー所有者と実施します。

どこまで調べても原因が見つかりません。

対象環境、フローID、トリガー、テスト値、発生時刻、Trigger conditions、接続状態、表示されたエラーをまとめて管理者またはMicrosoftサポートへ渡します。権限がない管理設定を推測で変更しないことが重要です。

まとめ：一件のテスト入力から原因を分ける

履歴が空なら、最初にアクションではなくトリガーを見ます。古い履歴が保存期間外で見えない場合と、今日のイベントでRunが作られない場合を混同せず、テスト入力の時刻を決めて確認してください。

次は、フロー詳細のトリガーエラー、接続の状態、Trigger conditionsとテスト値、DLPや環境管理モードをこの順に確認します。表示されたエラーや条件が権限外なら、その情報を添えて管理者に依頼してください。原因が確認できるまでは、業務フローのトリガーを削除・再作成したり、条件を無効化したりせずに止めておくのが安全です。

Sources