Power Automate（パワーオートメイト）のフローは、作った日は動いても、数か月たつと止まります。パスワードの変更で接続が切れる、SharePoint の列名を誰かが変える、フォルダーが消える、といった理由です。困るのは止まったことに誰も気づかず、2週間分の請求書PDFが保存されていなかったと月末に分かるような場合です。この記事では、社員15名の「サンプル工務店」のフローを例に、実行履歴で失敗の原因を読む方法、よくあるエラーの直し方、失敗を受け止めて Teams に知らせる作り方、再実行のときに二重に処理しない注意までを書きます。クラウドフローを1本以上作って動かしたことがある前提です。
この記事の内容
先に決めること
エラー処理は、フローを作り終えてから足すと、つぎはぎになります。作り始める前に次の4つを決めておきます。
1. 失敗を誰が受け取るか
フローが失敗すると、Power Automate は所有者に「修復のヒント」のメールを送ります。ただし届くのは所有者だけです。事務Bが作ったフローなら事務Bの受信トレイに届き、事務Bが休みの日や辞めたあとは誰も見ません。サンプル工務店では、失敗の知らせは個人ではなく Teams のチーム「事務」に作った「フローの失敗」チャネルに集めると決めました。事務3名と代表が見るので、誰か1人は気づきます。
2. 失敗したら止めるか、続けるか
たとえば請求書PDFを保存するフローで、10件の添付のうち1件だけ保存に失敗したとき、残りの9件は保存してほしいのか、全部止めてほしいのか。多くの場合は「できるものは進めて、失敗したものだけ知らせる」が正解です。逆に、見積の金額を会計ソフトに送るような処理は、途中で失敗したら後ろを動かさないほうが安全です。フローごとにどちらかを決めてから組みます。
3. 再実行してよい作りか
失敗した実行を「再送信」すると、フローは最初のアクションからもう一度動きます。失敗する前に成功していたアクションも、もう一度動きます。SharePoint リストに行を足すアクションが成功したあとで失敗したなら、再送信すると同じ行が2つできます。再送信する前提なら、「すでにあれば足さない」作りにしておく必要があります。
4. どのフローに付けるか
失敗の通知は、例外なく全フローに付けます。外したフローほど、止まったときに誰も気づきません。付け方は後の「失敗をTeamsかメールに知らせる仕組みを全フローに付ける」で、コピーして貼るだけの形にします。
実行履歴の見方
失敗の原因は、ほぼすべて実行履歴に書いてあります。ここを読めると直す時間が大きく変わります。
- Power Automate（make.powerautomate.com）にサインインする
- 左の「マイ フロー」を選ぶ
- 失敗したフローの名前を選ぶ。フローの詳細ページが開く
- 「28 日間の実行履歴」の一覧で、状態が「失敗」の行の開始日時を選ぶ
- フローの図が開き、失敗したアクションに赤い感嘆符が付いている。そのアクションを選ぶ
- 右側（新しいデザイナーでは構成ペイン）にエラーの詳細と、直し方のヒントが出る
入力と出力を読む
失敗したアクションを開くと、「入力」と「出力」を展開できます。入力はアクションが送った中身、出力は相手のサービスから返ってきた中身です。
- 入力を見ると、どのフォルダーに、どのファイル名で、どの行IDに対して何をしようとしたかが分かる。動的コンテンツが空のまま送られていないか、ここで見る
- 出力を見ると、相手のサービスの実際のエラーメッセージと状態コード（
statusCode）が分かる。デザイナーの上に出る短いメッセージより、出力の本文のほうが詳しい - 成功したアクションも同じように開ける。「条件」のアクションを開くと、何と何を比べて結果が真か偽かが見えるので、思った分岐に行かなかった原因が分かる
実際に運用していると、エラーの半分以上は「前のアクションの出力が空だった」「違う列の値が入っていた」のどちらかです。1つ前、2つ前のアクションの出力もさかのぼって見ます。
状態の種類
| 状態 | 意味 | することの例 |
|---|---|---|
| 成功 | 最後まで動いた | 結果が正しいかは中身で確かめる |
| 失敗 | どこかのアクションが失敗した | 赤い感嘆符のアクションを開く |
| 実行中 | まだ動いている。承認待ちなども含む | 30日を過ぎると保留中のステップはタイムアウトする |
| 待機中 | 同時実行の上限に達し順番を待っている | 同時実行制御の設定を見直す |
| キャンセル済み | 人が取り消した | 必要なら再送信する |
実行の中の各アクションには、ほかに「スキップ」という状態が付きます。前のアクションが失敗したので動かなかった、という意味です。スキップされたアクション自体に問題はありません。最初に失敗したアクションを探します。
実行履歴に列を足す
1日に何十回も動くフローでは、どの実行が誰のどのメールのものか、開始日時だけでは分かりません。フローの詳細ページで「列の編集」を選び、トリガーの出力（メールの件名、差出人、添付があるか、など）を列として足すと、実行履歴の一覧で目当ての実行を探せます。
履歴が残る期間
実行の記録は、開始時刻から30日間残ります（2026年10月時点）。詳細ページに出るのは「28 日間の実行履歴」です。それより前の実行は見られないので、月末にまとめて確かめる運用だと、月初の失敗の記録はもう消えていることがあります。長く残したい記録は、後の「応用」で書くように SharePoint リストに自分で書き出します。
よくあるエラーと直し方
エラーの詳細に出る状態コードで、原因の見当がつきます。
| コード・表示 | 意味 | 小さな会社でよくある原因 | 直し方 |
|---|---|---|---|
| 401 権限がありません | 接続の認証が切れた | フローを作った人がパスワードを変えた、多要素認証をやり直した | フローの「接続」で「編集」→「接続の管理」を開き、「権限がありません」と出ている接続で「再接続」を選んでサインインし直す |
| 403 許可されていません | 認証はできたが権限がない | SharePoint サイトの権限を外された。管理者のデータ ポリシー（DLP）でコネクタが止められた。Premium のコネクタを Microsoft 365 のライセンスで使った | サイトの権限を確かめる。DLP は管理者に聞く。Premium なら所有者・実行する人に Power Automate Premium が要る |
| 404 見つかりません | 相手のファイル・フォルダー・リストがない | フォルダーやリストの名前を変えた・消した。Teams のチャネルを消した | 相手が今もあるか確かめ、アクションの宛先を選び直す |
| 429 | 短い時間に呼びすぎた | ループの中で同じコネクタを何百回も呼んだ | 再試行ポリシーで待って再試行させる。ループの前に件数を絞る。ループの中に「延期」を入れる |
| 400 無効な要求 | 送った中身の形が合わない | 数値の列に文字を送った。1行テキストの列（255文字まで）に長い文を入れた。ファイル名に使えない文字が入った | 入力を開いて実際に送った値を見る。式で型を変える、長さを切る、文字を置き換える |
| ExpressionEvaluationFailed | 式が実行時に計算できなかった | 空（null）の値に int() や formatDateTime() を使った | coalesce() や empty() で空のときの値を決めてから使う |
| ActionTimedOut | アクションが時間内に終わらなかった | 相手のサービスが遅い。大きなファイル | アクションの「設定」でタイムアウトを延ばす。件数・サイズを減らす |
| 500・502 | 相手のサービス側の一時的な不調 | Microsoft 側や外部サービスの障害 | 時間を置いて再送信する。続くならサービスの正常性を確かめる |
401 と 403 は、作った人のアカウントの事情で起きます。サンプル工務店でも、事務Bがパスワードを変えた翌日に、事務Bの作った4本のフローが一斉に 401 で止まりました。誰のアカウントでフローを動かすかは「Power Automateの運用ルール：所有者・退職・接続切れ・DLPでフローを止めない」で詳しく書きます。
400 は、以前は動いていたフローで急に出たら、相手の側が変わった合図です。SharePoint リストの列名を変えた、選択肢の値を変えた、といった変更のあとで出ます。列を足した・変えたときは、フローの中のそのアクションを一度消して入れ直さないと、新しい列がデザイナーに出てこないことがあります。
式のエラーは、式の書き方を「Power Automateの式と変数：日付・文字列・配列をよく使う関数で扱う」で確かめます。空のときの扱いでよく使うのは次の2つです。
coalesce(triggerOutputs()?['body/Title'], '（件名なし）')
if(empty(triggerOutputs()?['body/Amount']), 0, int(triggerOutputs()?['body/Amount']))「以後の実行」で、失敗したときに次を動かす
ふつうのアクションは、1つ前のアクションが成功したときだけ動きます。前が失敗すると、後ろのアクションは全部「スキップ」になって、フロー全体が「失敗」で終わります。この「前がどうなったら動くか」を変えるのが、アクションの設定の「以後の実行」です。
- デザイナーでフローを開き、失敗したときに動かしたいアクション（例: Teams への投稿）を、見張りたいアクションの直後に置く
- そのアクションを選び、構成ペインの「設定」タブを開く
- 「以後の実行」で、直前のアクションを展開する
- 「失敗」と「タイムアウト」にチェックを入れ、「成功」のチェックを外す。チェックは最低1つ残す決まりなので、先に別の状態を選んでから「成功」を外す
- フローを保存する
選べる状態は「成功」「失敗」「スキップ」「タイムアウト」の4つです。組み合わせによって動き方が変わります。
| チェックする状態 | 動くとき | 使う場面 |
|---|---|---|
| 成功（既定） | 前が成功したとき | ふつうの処理 |
| 失敗・タイムアウト | 前が失敗したとき | 失敗の知らせ、後始末 |
| スキップ | 前が動かなかったとき | 前の前で失敗したときもまとめて拾いたい |
| 4つ全部 | 前がどうなっても | 最後に必ず記録を残す処理 |
アクション1つずつにこれを付けると、アクションが10個あるフローでは通知も10個になります。そこで次のスコープを使います。
スコープで try/catch を作る
スコープは、複数のアクションを1つの箱にまとめるアクションです。箱の中のどれか1つが失敗すると、箱全体が「失敗」になります。これを使って、プログラムでいう try/catch の形を作ります。中身を入れる「Try」の箱と、Try が失敗したときだけ動く「Catch」の箱の2つを並べます。
例にするのは、サンプル工務店の共有メールボックス info@sample-koumuten.example に届く協力会社の請求書PDFを、SharePoint の「工事案件」サイトに保存して、経費精算のリストに1行足すフローです。
- フローを開き、トリガーの下に「＋」から「スコープ」（組み込みツールの「コントロール」にある）を追加する
- スコープの名前を「Try」に変える（カードの名前を選んで書き換える）
- 今あるアクション（添付の保存、リストへの行の追加）を、Try の中へドラッグして移す
- Try の下に、もう1つ「スコープ」を追加し、名前を「Catch」に変える
- Catch を選び、「設定」タブの実行条件で、Try に対して「失敗」と「タイムアウト」だけにチェックを入れる
- Catch の中に「配列のフィルター処理」を追加する。「差出人」に式
result('Try')を入れ、条件を「item()?['status']がFailedに等しい」にする - Catch の中に、Teams に知らせるアクションを追加する（次の節で中身を書く）
- Catch の最後に「終了」を追加し、状態を「失敗」にする。メッセージに「請求書の保存に失敗」と入れる
- 保存し、わざと失敗させて（保存先のフォルダー名を一時的に存在しない名前にするなど）Catch が動くか確かめる。確かめたら元に戻す
![「配列のフィルター処理」の構成ペイン。差出人に result('Try')、条件に item()?['status'] と Failed が入っている状態](https://nexly.co.jp/power-automate/wp-content/uploads/2026/10/pa-11-143.png)
手順8の「終了」を入れるのには理由があります。Catch が最後まで成功すると、フロー全体の状態は「成功」で終わってしまいます。実行履歴の一覧では失敗が見えなくなり、後で探せません。「終了」で状態を「失敗」にしておくと、実行履歴でも失敗として残り、所有者への修復のヒントのメールも届きます。
result() が返すのは、スコープの直下にあるアクションの結果だけです。Try の中に「条件」や「Apply to each」があって、その内側で失敗した場合、result('Try') で取れるのは「条件」アクションが失敗したことまでで、内側のどのアクションかは出ません。内側まで知りたいときは、条件の中にもう1段スコープを置くか、エラーメッセージに実行履歴のURLを付けて、人が開いて見る形にします。
Finally も欲しいとき
成功しても失敗しても必ず最後にやりたい処理（処理件数の記録など）があれば、Catch の下に3つ目のスコープ「Finally」を置き、実行条件で Catch に対して4つの状態すべてにチェックを入れます。Try が成功すると Catch はスキップされるので、Catch の「スキップ」も選んでおかないと Finally が動きません。
失敗をTeamsかメールに知らせる仕組みを全フローに付ける
Catch に入れる通知は、全フローで同じ形にそろえます。知らせを見た人が、フローを開かなくても「何が・いつ・どこで」止まったか分かることが目標です。
通知に入れるもの
| 項目 | 入れ方 |
|---|---|
| フロー名 | workflow()?['tags']?['flowDisplayName'] |
| 起きた日時 | convertFromUtc(utcNow(), 'Tokyo Standard Time', 'yyyy/MM/dd HH:mm') |
| 失敗したアクション名 | 配列のフィルター処理の結果の name |
| エラーの中身 | 結果の outputs の本文の message、なければ error の message |
| 実行履歴へのURL | 下の式で組み立てる |
| 何のデータか | メールの件名や差出人など、トリガーの値 |
実行履歴のURLは、workflow() 関数の値から組み立てます。「作成」アクションに次の式を入れます。
concat('https://make.powerautomate.com/environments/', workflow()?['tags']?['environmentName'], '/flows/', workflow()?['tags']?['logicAppName'], '/runs/', workflow()?['run']?['name'])失敗したアクションの名前とメッセージは、配列のフィルター処理の1件目から取ります。
first(body('配列のフィルター処理'))?['name']
coalesce(first(body('配列のフィルター処理'))?['outputs']?['body']?['message'], first(body('配列のフィルター処理'))?['error']?['message'], '詳細は実行履歴を確認')式の中のアクション名は、デザイナーで付けた名前の空白を _ に置き換えたものです。アクションの名前を変えたら式も直します。
Teams に投稿する
- Catch の中で「＋」から Microsoft Teams の「チャットまたはチャネルでメッセージを投稿する」を追加する
- 「次のように投稿する」で「Flow ボット」を選ぶ
- 「投稿」でチャネルに出す選択肢を選び、チームに「事務」、チャネルに「フローの失敗」を選ぶ
- メッセージに、上の表の項目を並べる。例は次のとおり
【フローの失敗】@{workflow()?['tags']?['flowDisplayName']}
日時: @{convertFromUtc(utcNow(), 'Tokyo Standard Time', 'yyyy/MM/dd HH:mm')}
止まった所: @{first(body('配列のフィルター処理'))?['name']}
内容: @{outputs('エラーの中身')}
メール件名: @{triggerOutputs()?['body/subject']}
実行履歴: @{outputs('実行履歴URL')}
投稿者を「Flow ボット」にすると、投稿はボットの名前で出ます。「ユーザー」にすると接続を作った人の名前で出るので、本人が投稿したように見えて紛らわしくなります。失敗の通知はボットにします。Teams への投稿の細かい選び方は「Power AutomateでTeamsに自動投稿：チャネルへの通知とメンションの付け方」にまとめています。
Teams を使わない人に知らせたいときは、同じ中身で Office 365 Outlook の「メールを送信する (V2)」を使い、宛先を担当者の個人アドレスではなく事務のグループのアドレスにします。
全フローに付ける手順
毎回ゼロから作ると、フローごとに通知の中身がばらつきます。1本、上の形で完成させたら、それを手本にします。
- 手本のフローを開き、Catch スコープを右クリックして「アクションのコピー」を選ぶ
- 通知を付けたいフローを開き、中身を Try スコープに入れる
- Try の下の「＋」を右クリックして「アクションの貼り付け」を選ぶ。名前の後ろに「-copy」が付くので「Catch」に直す
- Catch の実行条件を、このフローの Try に対して「失敗」「タイムアウト」に設定し直す
- 式の中のアクション名がこのフローと合っているか見て、保存し、わざと失敗させて確かめる
サンプル工務店では、フローの一覧（SharePoint リストの簡単な台帳）に「失敗通知あり」の列を作り、全フローで「はい」になるまで付けて回りました。新しいフローも、この列が「はい」になってから本番に出します。
再実行（再送信）の仕方と、二重に処理しないための注意
原因を直したら、失敗した実行をやり直します。
1件ずつ再送信する
- 失敗した実行を開く
- 上の「再送信」を選ぶ
- 同じトリガーの入力（同じメール、同じリストの行）で、フローが最初から動く
修正したフローで動かし直す場合は、先にフローを直して保存してから再送信します。再送信は、その時点で保存されているフローの中身で動きます。
まとめて再送信する
- 「マイ フロー」でフローを選び、詳細ページで「すべての実行」を選ぶ
- 実行履歴の一覧で、再送信したい実行にチェックを入れる。一度に選べるのは20件まで
- 「フロー実行を再送信する」を選ぶ
インスタント フロー（ボタンで手で動かすフロー）の実行は、自分が動かした分はいつでも再送信できます。他の人が動かした実行も再送信できるようにするには、Power Platform 管理センターの「設定」で「Power Automate フロー実行の再送信」を有効にします。
二重に処理しないために
再送信は、途中から再開するのではなく、最初からやり直します。失敗する前に成功していた処理は、もう一度行われます。
| 成功していた処理 | 再送信で起きること | 防ぎ方 |
|---|---|---|
| SharePoint リストに行を追加 | 同じ行が2つできる | 追加の前に「アイテムを取得」でメールのIDなどを探し、あれば追加しない |
| ファイルを作成する | 同じ名前のファイルでエラー、または別名で2つできる | ファイル名を一意にし、作成の前に存在を確かめる |
| メールの送信・Teams への投稿 | 相手に同じ知らせが2回届く | 送信はフローの最後に置く。再送信の前に送信済みか確かめる |
| 会計ソフトなど外のサービスへの登録 | 二重計上 | 外に送る処理は別のフローに分け、送ったかどうかをリストに記録して確かめる |
金額の入った処理が二重になると後始末に時間がかかります。サンプル工務店では、経費精算のリストに「メッセージID」の列を作り、行を足す前に同じIDの行があるか確かめる形にしています。こうしておけば、何度再送信しても行は1つです。
間違って大量に動いたときは取り消す
フローの作りを間違えて、同じ実行が大量に走ってしまうことがあります。そのときは詳細ページの「すべての実行」を開き、上の「実行履歴」のメニューから「すべてのフロー実行をキャンセル」を選びます。確認のメッセージで「はい」を選ぶと、実行中と待機中の実行がまとめて取り消されます。そのとき、フローをオフにするチェックも入れられます。取り消しが終わるまでに最大24時間かかることがあります。
フローが自動でオフになる条件と通知
フローは、人がオフにしなくても止まることがあります。公式の制限のページに書かれている条件は次のとおりです（2026年10月時点）。
| 条件 | 期間 | 補足 |
|---|---|---|
| トリガーかアクションが失敗し続ける | 14日 | 失敗し続けたフローはオフになる |
| 一度もトリガーされない | 90日 | Microsoft 365 のライセンスだけの人のフローは対象。Premium か Process のライセンスを持つ人のフローは対象外。止まる30日前に所有者と共有者へ通知がある |
| 要求の上限を超え続ける（スロットル） | 14日 | 上限を下回るようにフローを直す |
| 所有者の Premium が外れた（Premium が要るフロー） | 14日以内 | 性能を落として動き、所有者全員に通知が届く。管理者にもメールで知らせが届く |
| Premium のない人に所有者を変えた | 30日 | 30日は動き、その間に新しい所有者が Premium を得なければオフになる |
止まったフローは、マイ フローや管理センターで「中断済み」と表示されます。年に1回しか使わない「年末の休暇申請の集計」のようなフローは、90日の条件に引っかかります。通知のメールが来たら、フローを開いてオンにし直せば続けて使えます。
オンに戻す手順は次のとおりです。
- 「マイ フロー」で止まったフローの「⋮」を選ぶ
- 「オンにする」を選ぶ。詳細ページを開いているなら、上のメニューの「オンにする」でもよい
- 失敗が続いて止まったフローは、先に原因を直してからオンにする。直さずにオンにしても、また失敗が続く
失敗が14日続いてオフになったなら、14日間誰も気づかなかったということです。
応用
再試行ポリシーを決める
一時的なエラー（429 や 500 番台）は、少し待てば通ることが多いので、アクションの「設定」タブにある「再試行ポリシー」で自動の再試行に任せます。既定は間隔を広げながら繰り返す指数間隔で、Microsoft 365 のライセンスで動くフロー（パフォーマンス プロファイルが「低」）は2回までです（2026年10月時点）。外部のサービスが不安定で2回では足りないときは、「指数間隔」を選んで回数と間隔を自分で決めます。逆に、二重に処理されると困る登録のアクションでは「なし」を選び、失敗はCatchで人に知らせる形にします。
失敗の記録を残す
実行履歴は30日で消えるので、失敗の記録を長く見たいときは、Catch の中で SharePoint リスト「フローの失敗記録」に1行足します。列は日時・フロー名・止まったアクション・エラー内容・実行履歴URL・対応済み、の6つで足ります。月に1回この一覧を見ると、同じフローが毎月同じ理由で止まっている、といった傾向が分かります。
トリガーが動かないことに気づく
Catch の通知は、フローが動いて途中で失敗したときにしか出ません。トリガーが一度も動かなかったときは、実行履歴にも何も残りません。毎日必ず何かが届くはずのフローなら、別に「スケジュール済みクラウド フロー」を1本作り、毎朝、前日に記録が1件もなければ Teams に知らせる、という見張りを置きます。
できないことと、その代わり
- 30日より前の実行履歴は見られない。前の項の「失敗の記録」で自分で残す
- 失敗したアクションから途中だけやり直すことはできない。再送信は必ず最初から。重複しない作りにしておくしかない
- 所有者以外に、失敗の知らせを自動で送る設定はない。修復のヒントのメールは所有者宛てだけなので、Catch で Teams やグループのアドレスに送る
result()は入れ子の内側の失敗を返さない。内側にもスコープを置くか、実行履歴のURLを付けて人が見る- トリガーが動かなかったことは実行履歴に出ない。前の項の見張りのフローで補う
- 何十本ものフローの失敗を一覧で監視し、しきい値で警報を出すような監視は、Power Automate の画面だけでは難しい。規模が大きい会社は Application Insights などの監視の仕組みを使う。社員15名の会社なら、Teams のチャネルと失敗記録のリストで足りる
- 外部のサービスとのやり取りが中心で、エラーごとに細かく分岐させたい処理は、Power Automate より n8n のほうが組みやすいことがある。会計の基幹処理のように厳しい監査が要る仕事は、専用のシステムに任せる
よく詰まるところ
| 症状 | 原因 | 直し方 |
|---|---|---|
| Catch が動かない | Catch の実行条件が Try の「成功」のまま | Catch の「設定」タブで Try に対し「失敗」「タイムアウト」を選び、「成功」を外す |
| Catch が動いたのにフローが「成功」と表示される | Catch が最後まで成功したので全体も成功扱い | Catch の最後に「終了」を置き、状態を「失敗」にする |
| 配列のフィルター処理の結果が空 | 失敗したのが条件やループの内側で、result() に出ていない | 条件・ループの中にスコープを置くか、条件の名前で失敗を拾う |
| 通知の式でエラーになる | 式の中のアクション名が違う（空白と _、名前を変えた） | 動的コンテンツから選び直すか、アクション名を正確に書き直す |
| 再送信したらリストに同じ行が2つできた | 再送信は最初から動く | 追加の前に同じキーの行を探し、あれば追加しない作りにする |
| 再送信したのに同じエラーで失敗する | フローを直す前に再送信した、または接続が切れたまま | 先に原因を直して保存し、接続を確かめてから再送信する |
| 401 が毎月のように出る | 作った人のパスワード変更・多要素認証のやり直し | 接続を直す。共用のアカウントで接続する運用に変える |
| 急に 400 が出るようになった | SharePoint リストの列名や選択肢を変えた | アクションの入力を開いて送った値を見る。アクションを入れ直して新しい列を読み込ませる |
| 実行履歴に何も出ない | トリガーが動いていない、またはフローが中断済み | 詳細ページで状態を確かめる。トリガーの条件を外して試す |
| フローが知らないうちにオフになっていた | 90日動かなかった、または失敗が14日続いた | オンに戻す。年に数回しか動かないフローは、時期の前に動作を確かめる |
| テスト中に「タイムアウト」と出るのに実際は動いている | 10分を超えるフローのテストは画面がタイムアウトを表示することがある | 実行履歴を開き直して今の状態を見る |
| 429 が出てフローが遅い | ループの中で同じコネクタを呼びすぎ | ループの前に件数を絞る。「延期」を入れる。再試行に任せる |
次にやること
エラーに気づける形ができたら、止まる原因そのものを減らします。
- トリガーが動かない、実行履歴に何も出ないときは「Power Automateのトリガー：よく使うトリガーの一覧と、動かないときの確かめ方」
- 所有者の退職や接続切れでフローを止めない決まりは「Power Automateの運用ルール：所有者・退職・接続切れ・DLPでフローを止めない」
- Try の中の分岐やループを整理するなら「Power Automateの条件分岐とループ：条件・スイッチ・Apply to eachの使い方」
- 通知の式や空の値の扱いを詳しく知るなら「Power Automateの式と変数：日付・文字列・配列をよく使う関数で扱う」