この記事は LITALICO Advent Calendar 2025 の14日目の記事です。
はじめに
こんにちは！
LITALICOでエンジニアをしている @iwafs です。
今年は、Power Automate for Desktop (PAD) を活用して、定型業務の自動化に取り組んでいました。 「これでルーチンワークから開放される！」と意気込んでフローを作り始めたのですが、いざ動かしてみると 「ボタンを押した後の待機処理」 という、意外な沼にハマってしまいました。
ぶつかった壁
自動化したかったのは、ある社内システムでの処理です。「実行ボタン」を押した後、処理が完了するのを待って次のアクションに進むというシンプルなフローなのですが、ここで問題が発生しました。
- 処理時間がまちまち：数秒で終わることもあれば、システムの混雑状況や通信速度によっては結構な時間がかかることもある
- 標準機能がうまく動かない：PAD標準の「画像を待機」アクションや「ウィンドウを待機する」アクションを使っても、検知されずにフローが止まったままになってしまう（原因不明...）
「待機時間を長めに固定すればいいか」と思って試してみると、今度は全体の処理時間が長くなりすぎて業務効率が悪化するという本末転倒な状態に。
この記事では、そんな環境において、「ベストプラクティスではないかもしれないけれど、ひとまず安定して動かす」 ために私がたどり着いた、ポーリングによる暫定対応の記録を共有します。
同じように「PADの待機アクションが言うことを聞いてくれない！」と頭を抱えている方の参考になれば幸いです。
試行錯誤の過程
「ボタンを押した後、次の画面が出るまで待機する」
言葉にすれば簡単なことですが、ここが最大の難所でした。安定稼働に至るまでに、以下の2つのアプローチを試しては失敗しました。
試したことその1：標準機能「UI要素/画像の待機」を使う
まずは正攻法です。PADには標準で 「画像を待機」 や 「ウィンドウを待機する」 という便利なアクションが用意されています。
「これで動くだろう」と思い、処理完了後に表示されるダイアログや特定のボタンをターゲットに設定しました。 しかし、結果は以下の通り。
- 現象： 画面上には明らかに次の要素が表示されているのに、PADがそれを検知してくれない
- 結果： タイムアウトまで待ち続けるか、設定によっては永遠に待機し続けてしまう
画像のキャプチャ範囲を変更したり、ウィンドウのUI要素のセレクターを見直したりといろいろ試しましたが、なぜか私の環境（対象システム）ではうまく動作しませんでした。
試したことその2：「待機」アクションで時間を固定する
次に考えたのは、力技です。「処理に時間がかかるなら、多めに待てばいいじゃない」と、 「待機」 アクションで長めの時間を設定しました。
- 設定： どんなに遅くても5分あれば終わるだろうと、300秒の固定待機を設定
- 結果： 業務効率が悪すぎる
もし5秒で処理が終わった場合、ロボットは律儀に残り295秒を待ち続けます。これでは自動化の意味が半減してしまいます。
「処理が終わったらすぐに次に進みたい、でもいつ終わるかはわからない」このジレンマを解消するために、次の策をとることにしました。
たどり着いた暫定的な解決策：ポーリング
最終的に採用したのは、 「短い待機と確認を繰り返す（ポーリング）」 というロジックです。 標準の待機アクションで解決できないなら、自分でループを作って監視しようというアプローチです。
実装したロジックの概要
具体的には、以下のようなフローを組みました。
- 最大待機回数の設定：無限ループを防ぐため、変数で「リトライ上限回数（例：60回）」を設定
- ループの開始：「Loop」アクションで指定回数だけ繰り返す
- 短い待機：「待機」アクションで「5秒」だけ待つ
- 状態チェック：「If」アクション（「ウィンドウが表示されている場合」や「画像が存在する場合」など）で、処理完了画面が表示されているか確認
- もし表示されていたら：「ループを抜けるアクション」で次の処理へ
- ループの終了
- エラーハンドリング：ループを抜けた後、まだ完了画面が出ていなければ（最大回数試行してもダメだった場合）、エラーとして通知を送る
この方法のメリット
この「ポーリング」ロジックにしたことで、以下の挙動を実現できました。
- 早ければ即終了：処理が5秒で終われば、1回目のループくらいで検知してすぐに次に進める
- 遅くても待てる：処理が5分かかっても、ループ回数の上限までは粘り強く待ってくれる
- 安全停止：万が一システムがハングアップしても、上限回数に達すればエラーとして停止できる（無限待機しない）
標準アクション一発で済むのが理想ではありますが、 「柔軟性」と「確実性」を両立させるための暫定対応 としては、有効な手段だと感じています。
まとめ
今回は、Power Automate for Desktopで「待機時間が読めない」「標準の待機アクションがうまく動かない」という状況に対する、ポーリングによる解決策をご紹介しました。
学んだこと
- PADにおいて「待機処理」は意外と奥が深く、エラーの温床になりやすい
- 「最大時間に合わせる」と安全だが遅くなる。「状況に合わせて確認する」仕組みを作ると、効率と安全を両立できる
もし同じように「PADが待ってくれない（あるいは待ちすぎる）」とお悩みの方がいれば、ぜひこの解決策を試してみてください。 今はこれで安定稼働していますが、「もっとうまいやり方があるよ！」という方がいれば、ぜひコメントで教えていただけると嬉しいです。