Power Automate でよくあるつまずき10個｜原因と直し方と、止まりにくくするコツ

📝 この記事は、Power Automate でよく相談を受けるつまずきを、原因ごとに整理したものです。
式や関数の仕様はMicrosoft 公式（ワークフロー式の関数リファレンス）で確認しています。

テストは通るのに本番で動かない。エラーの文面が意味不明。変数がいつのまにか空になっている。
どれも、原因が分かってしまえば対処は短いものばかりです。
この記事では、相談の多い10個を、原因と直し方の順でまとめます。

相談を受ける場所は、だいたいこの10個のどれかです。
並べる順番は、出会いやすいものから上にしました。上の5つは、始めて1か月のうちに一度は通るところだと思います。

① Apply to each が勝手に出てくる

原因｜一覧を取得するアクションは配列を返します。
その中の値を使おうとすると、Power Automate が「全件まわしますね」と判断して自動で追加します。

直し方｜1件しか要らないなら、先に絞ります。
フィルター配列で条件を付けるか、first() で最初の1件を取り出せば、ループは不要になります。

② 条件が通らない

原因｜比べている型が違っています。文字列の "100" と数値の 100 は一致しません。

直し方｜そろえてから比べます。数値は int()、文字は string()、
日付は formatDateTime() で書式をそろえます。

③ 選択（Select）が何をしているか分からない

原因｜画面が「キー」と「値」の対応表になっていて、
何を作っているのかが見えにくいためです。

直し方｜配列の形を作り直すアクション、と捉えると分かります。
元の配列から欲しい項目だけ抜いて、新しい形に並べ替えています。
出力を実行履歴で見ると、何が起きたか一目で分かります。

④ 日付の式が呪文に見える

原因｜関数を入れ子で書くため、1行が長くなるからです。

直し方｜内側から読むと分かります。
startOfMonth(addMonths(utcNow(), 1)) なら、
「今 → 1か月進める → その月の頭」の順です。
それでも長いときは、作成アクションに分けて名前を付けます。

⑤ 動的コンテンツに出てこない

原因｜受け取った値が、まだ「ただの文字列」として扱われています。
中に何が入っているかを Power Automate が知らないためです。

直し方｜JSON の解析を通します。スキーマは「サンプルから生成」で
実データを貼り付ければ自動で作られます。
1つだけ欲しいなら、解析せず作成アクションに式を書くほうが早いこともあります。

⑥ 変数の型で事故る

原因｜変数の種類は初期化のときに決まり、あとから変えられません。
数を数えたいのに文字列で作ってしまうと、足し算ができません。

直し方｜作る前に「何を入れる箱か」を決めます。
数えるなら整数、文字をためるなら文字列、真偽なら Boolean。
ループの中で値を足していくなら、必ず整数で作るのが基本です。

⑦ 実行履歴が読めない

原因｜どこを見ればいいか分からないためです。情報自体はすべて残っています。

直し方｜開くのは赤いアクションの「入力」と「出力」の2か所だけです。
入力に想定した値が入っていなければ、原因はその手前にあります。
入力は正しいのに出力がエラーなら、原因はそのアクションです。
この切り分けだけで、原因の場所はほぼ特定できます。

⑦は、自分の中でいちばん効いたところです。
エラーの文面を読むより、入力と出力を見るほうが速い。それに気づいてから、調べる時間がかなり減りました。

⑧ 接続が切れている

原因｜コネクタは、作った人のアカウントで接続を持っています。
パスワード変更や多要素認証の再設定をきっかけに、この接続が無効になることがあります。

直し方｜フローの一覧に警告が出ていないかを確認します。
接続の画面から、該当のコネクタを作り直すと復旧します。
定期的に動くフローなら、失敗時に自分へ通知が飛ぶようにしておくと、気づくのが早くなります。

⑨ 共有したら動かなくなった

原因｜フローは共有できますが、接続まで一緒に渡るわけではありません。
受け取った人の権限で、参照先のファイルやリストを開けない場合に止まります。

直し方｜相手の環境で接続を作り直してもらうか、参照先の権限を見直します。
チームで使うフローなら、
個人の OneDrive ではなく SharePoint に置くほうが、あとから引き継ぎやすくなります。

⑩ テストは通るのに本番で止まる

原因｜テストで使ったデータが、たまたま都合の良いものだったケースがほとんどです。
任意項目が全部埋まっていた、対象が1件だけだった、といった具合です。

直し方｜次の3つを、わざと作って試します。

• 空欄があるデータ｜任意項目を空にして送る
• 0件になる条件｜絞り込みが1件も返らない状態
• 件数が多いデータ｜上限にかかるかを見る

この3つを通れば、本番で止まる確率はかなり下がります。

エラーが出たあとの動き方

止まったフローは、直したあとに再実行できます。
実行履歴から該当の実行を開いて再送信すれば、同じ入力でもう一度走ります。

ただし、すでに完了している処理ももう一度動きます。
メール送信を含むフローを再実行すると、同じメールが2通届きます。

相談を受けるときに最初に聞く3つ

社内で相談を受けるとき、この3つを聞けば、たいてい場所が絞れます。

• 「実行履歴は赤いですか、それとも成功していますか」｜成功しているなら、条件の分岐先が違っています
• 「止まっているアクションの入力に、想定した値は入っていますか」｜入っていなければ、原因は手前です
• 「前は動いていましたか」｜動いていたなら、接続かデータの変化を疑います

エラーの文面を読むより、この3つのほうが速いです。

止まりにくいフローにするために

作る前に決めておく3つ

ここまでは、止まったあとの話でした。最後に、止まりにくくするために先に決めておくことを書きます。

名前を付けるのは、作っているあいだはいちばん面倒に感じるところです。
ただ、半年後に直すのは自分です。「作成7」と書かれたアクションの中身は、私は思い出せませんでした。それ以来、面倒でも付けるようにしています。

それでも分からないときの調べ方

エラーの文面をそのまま検索しても、出てこないことがあります。
そういうときは、固有の部分を外してから検索します。

ファイル名やIDが含まれていたら、そこを削ります。
残った部分が、同じ現象を踏んだ人と共通する言葉になります。

もう1つ有効なのが、アクション名で調べる方法です。
「Power Automate 選択 テキストモード」のように、
使っているアクションの名前と、やりたいことを並べます。
エラー文より、アクション名のほうが情報が見つかりやすいです。

補足：エラーメッセージの読み方

文面は英語のことが多いですが、見るのは2か所だけです。

どのアクションで起きたか｜実行履歴で赤くなっている場所です。
文面より先に、ここを見ます。

何が足りないと言っているか｜
「見つからない」「型が違う」「権限がない」のどれかであることがほとんどです。
この3つに当てはめてしまえば、次に見る場所は決まります。

• 見つからない｜参照先のファイル名・リスト名・列名を確認します。名前を変えていませんか
• 型が違う｜数値と文字列が混ざっています。int() や string() でそろえます
• 権限がない｜接続しているアカウントで、その場所を開けるか確認します

直したあとに必ずやること

直して動いたら、そこで終わりにせず2つだけやっておきます。

同じ原因が他のフローにも無いか見る｜
1本で起きたことは、たいてい他でも起きます。
日付のずれや空欄の扱いは、特に横に広がりやすいところです。

何が原因だったかを1行残す｜
フローの説明欄でも、メモでも構いません。
半年後に同じところで止まったとき、この1行があるだけで復旧が早くなります。

直した記録は、次に同じ相談を受けたときの答えになります。
社内で広めていくなら、ここを残しておくかどうかが効いてきます。

止まらないフローを作るより、止まったときにすぐ直せるフローを作るほうが現実的だと思っています。
データも業務も変わるので、いつかは必ず止まります。気づける仕組みと、追える名前を先に用意しておく。私はここに時間を使うようにしました。

この記事に挙げた10個は、どれも一度踏めば次からは避けられるものばかりです。
止まったこと自体より、原因の場所を絞れるかどうかが効いてきます。

まとめ

※ 本記事は公開日時点の内容です。筆者が実際に試した手順をまとめたもので、Power Automate の仕様は今後変わる可能性があります。
※ 記事の構成・図解の一部は、AIを壁打ち相手にしながら作成しています。