RPA後片付けの話（Power Automate Desktop改善事例）
この記事は、Microsoft Power Automate Advent Calendar 2025 の12月25日担当分の記事です。
はじめに
2025年4月に異動もあり、RPA（Power Automate Desktop、以下PAD）担当になりました。
実は、前部署にいた時点で現在の部署のRPAが組織的に末期だと指摘していました。
「フローが複雑」「属人化している」「保守できない」など、外から見て問題があり、指摘していたのですが、残念ながら神様は見ているようでまさかの異動先に…。
この記事では、組織に既に組み込まれてしまった末期RPA後片付け記録です。長文ですが、運用で詰んでいる人が読んで一助になれば幸いです。
問題点の全容把握
管理者から異動早々に部署で利用している問題あるRPAを立て直してほしいと言われ、確認した時点で以下のような問題を抱えていました。
組織的な問題
- ① RPA利用者は「ボタンを押すだけ」、処理内容を理解していない
- ② 中間管理職でさえ、自部署で利用されているRPAを理解していない
- ③ 中間管理職がRPA保守者に対して休暇中にも関わらず対応を強要
- ④ 不要な業務までRPA化
- ⑤ 複数RPA製品の利用
技術的な問題
- ⑥ デバッグ不可
- ⑦ フローが長い
- ⑧ IF分のネスト
- ⑨ ラベルアクションの多用
- ⑩ UI要素のゴミ
- ⑪ UI要素が多い
問題の処理方針
- RPA利用者とRPA保守者の責任の分離
- 保守コストの削減（RDB等のシステム設計の考えに基づき構築）
- 業務整理の優先
- 手段と目的の分離
対応したこと
① RPA利用者は「ボタンを押すだけ」、処理内容を理解していない
RPA利用者と保守者の責任が曖昧で、全てRPA保守者に負担が寄っている状態であったので責任の分離を行いました。組織としてRPA停止時にRPA利用者が運用できない業務についてはRPAで対応しないことにしました。従前までRPA停止中の負担が全てRPA保守者に偏り、RPA保守者が自身の通常業務+RPA改修+RPAで稼働していたはずの業務まで行っていたためです。このことにより、RPA保守者が効率化をしたくても自身に負担がよる構造であったため、二の足を踏む状態だったからです。
② 中間管理職でさえ、自部署で利用されているRPAを把握していない
私の部署のRPA利用者には中間管理職も含まれていました。何をしているのか意味もわからず、ボタンを押し、停止すればRPA保守者に業務対応してもらう状態に疑問を持たない状態でした。そのため、RPAで対応している作業内容について伝え、停止時には直接手を動かして対応できるように操作指示を行いました。
③ 中間管理職がRPA保守者に対して休暇中にも関わらず対応を強要
「② 中間管理職でさえ、自部署で利用されているRPAを把握していない」と共通する内容になりますが、前任者の時代には、休暇中であっても中間管理職から対応を強要される状況でした。
背景には、RPAが停止すると当該部署のコア業務がすべて停止してしまい、どのように再開すべきかをRPA保守者以外が判断できない体制であったためです。
本来、コア業務が停止するリスクに対して何の対策も講じていないことは管理者側の能力不足に起因する問題ですが、その責任がRPA保守者に転嫁されていました。
RPA利用者自身に手作業で対応させる運用に切り替えたことで、少なくとも最低限のコア業務は継続できる状態となりました。
④ 不要な業務までRPA化
RPAにしない方が良い業務もあります。それは、利用頻度が低く、開発コスト、保守コストに見合わない業務です。PADでも従前まであったアクションが使えなくなる等(Tesseract OCR)、まれに発生します。利用頻度の低いものはRPA化しない判断も重要だと思っています。
RPA化の判断は、
「自動化できるからRPA化する」のではなく、「自動化し続ける価値があるからRPA化する」
だと思っています。
⑤ 複数RPA製品の利用
他社製品のRPA(B…o!)を導入していたこともあり、一部業務だけRPA(B…o!)が稼働していました。私のPADを利用した成功事例を見て、新規業務だけPADでRPA化したことにより、RPA保守者が複数の製品操作を覚える必要が生じました。そのため、PADに一元化し、将来のRPA保守者の習得コストを下げました。
なお、RPA(B…o!)の製品が悪いわけではなく、RPA(B…o!)の改修を全てベンダー任せでRPA保守者も含めて操作できなかったことが失敗だと思っています。
…勉強したくても自宅パソコンでRPA(B…o!)をテスト操作することもできず、一部の担当者しか職場で利用できない製品は担当者にとって学習コストが無駄になることも習得の阻害要因かなと思ったりします。PADに関して言えば、無料のライセンスでもある程度できることがあるため、習得コストが無駄にならない点はメリットだと思います。
やっとQiitaらしくPADの技術的なことを記載します。
通常は利用者からRPAの内容を聞き、業務に合わせて修正すれば済むだけの話なのですが、残念ながら、私の異動した部署はRPA利用者が全く業務内容を理解しておらず、前任者は私の異動と同時に退職だったのでエラーが頻発するフローから業務を読み解き、対応したかった業務内容を把握してからフローを直す必要がありました。
⑥ デバッグ不可問題の解消
何をどこに入力しているかわかるように修正
左のExcelシートを元に右のフローでシステム入力をしているとイメージしてください。
このフローの良くない点はキーの送信を見るとわかりやすいのですが、CurrentItem[0]がいったい何で、どこに対して送信しているかフローでは不明な点です。
RPA以外にも、ExcelシートのB1:G6の番号を振ってあることから推測するに前任のExcelは"VLOOKUP(検索値, 検索範囲, 列番号, 検索方法)"としており、列番号で読み解き修正していく必要がありそうです。ちなみにこのようなExcelを読みやすくするため、通常は該当箇所をテーブル(Ctrl + Tを押す)に直して、構造化参照を利用します。
例 =XLOOKUP(検索値,テーブル名[検索値で指定したヘッダー名],テーブル名[返却ヘッダー名],"",0)
読取先のヘッダー名が取れるようにアクションの「Excelワークシートから読み取る」を修正しました。
「Excelワークシートから最初の空の列や行を取得」から最終行を取得して次のアクションに利用している通り、今回だとB4:G13をデータテーブルとしてExcelDataに読み取っています。ヘッダーなしの情報で読み取りしていることで以降のアクションがどのデータを利用しているか不明になります。そこで、B3:G13を読み取りできるように修正しました。
※本当はB3セル開始ではなく、A1セルを開始にしたかったのですが、該当ファイルを他でも利用している可能性を排除できなかったため、ひとまずRPAの把握のため、3行目をヘッダーとして読取できるように修正しました。
読取テーブルからヘッダー情報を含むように変更したため、次は「キー送信」の送信内容がわかるように修正しました。
これでひとまず入力している項目がわかるようになりました。
次はどこに入力しているか現状のフォアグラウンドウィンドウでは1アクション毎のデバックできません。そこで、UI要素を取得して送信先を指定します。
これで、何をどこに送信しているか指定することができました。
実は前任の方、レコーダーを利用してフローを組んだため、「キーの送信」後の次の「キーの送信」アクションがタブで画面遷移となっておりました。そのため、送信するテキストが「{Tab}{Tab}{Tab}{Tab}{Tab}%CurrentItem[5]%」のように登録されており、何をどこに入力しているかわからないため、ひとまず、{Tab}{Tab}{Tab}... → {Tab:5} のように簡素化しました
簡素化したことでやっと、どこに入力しているか判別できました。tabキーでの画面遷移を削除して直接UIに送信するように指定しました。
これで、送信先を指定したことにより１アクション毎のデバックが可能になりました。
…実務は怖いです。{Tab}{Tab}{Tab}…の100連打が頻発しており、頑張って除去しました。
「キー送信」から「ウィンドウ内の テキストフィールドに入力する」に変更
必須ではないですが、基幹システム等で入力前に既に入力があり、置換したい場合は「ウィンドウ内の テキストフィールドに入力する」を利用した方が良いです。キーの送信と異なり、置換機能があるためです。
…実務は怖いです。置換機能を知らずに、「キーの送信」で{Tab}{Tab}{Tab}…の連打後に{Delete}{Delete}{Delete}…の連打がありました。
ちなみに、基幹システムで補完入力が既にされており、実際には何も入力の必要がない時は以下のように「%''%」とすると文字を削除することができます。
⑦ フローが長い問題の解消
1フロー400アクション越えという超大作が数十件ある状態で、どのフローも安定しない状態でした。
PADのバージョン2.62になるまで、変数は全てグローバル変数だったこともあり、PADは他社製品と比較して大規模開発には向かないRPAでした。(裏を返せば、全てがグローバル変数というのは初学者にとって明確なとっつきやすさのメリットがあります。)
そこで、該当フローのみで共通する部分はサブフローに集約して、共通化しました。共通化したサブフローは「サブフローの実行」より稼働させました。
また、システムのログイン操作のように他のフローでも共通する部分はデスクトップフローを別に作成して、共通部分を部品化しました。
この操作に伴い、1フロー400アクション越えという超大作から1フロー150アクション程度まで削減され、シンプルになりました。
PADのバージョン2.62(2025年11月頃)以前までの全てグローバル変数時代の個人的な感覚ですが、プロ開発でない限り、1フロー100アクションを超えるあたりからロジックに何かしら問題があるのでは？と疑って良いと思っています。
⑧ IF分のネスト解消
RPAが初めてのプログラミングの方はネストって何？と思うかもしれないのですが、入れ子構造のことです。入れ子構造と言ってもよくわからないかもしれないのですが、IF文の中にIF文が入っていると思って頂いてよいです。この構造だと可読性が落ちるため、避けるようにプログラムでは記述します。
例えば、今回のExcelシートだと支店名が東京支店の部署が総務部と支店名が名古屋支店の部署が営業部だけ入力するとしたら、以下のようになります。
IFの中にIFが入っており、これが何個もあると読みづらくなります。そこでSwith文を使います。
Swith文を使うと後から条件追加があっても記述量が少なくて済み、可読しやすいです。
前任の方が作成したRPAも大量にネストしており、可読しやすいように修正を行いました。
⑨ ラベルアクションの多用解消
エラーが発生するとラベルに移動するアクションを多用していました。
ラベルアクションはなぜ避けた方が良いでしょうか？それは可読性が落ち、フローが読みにくいからです。
また、失敗したら初めに戻るを多用することで無限ループになっていることに気づかないこともあります。
（余談ですが、ラベルアクションと同じ役割をするGo-to文をプログラミングとして初めて見た時、音楽のダルセーニョはセーニョに戻ると同じだなと思った記憶があります）
ちなみにエラー時のクリック操作が画像判定であったこともラベルアクション多用の要因でした。
クリックが確実に押せるように秒数での「待機」アクションではなく、「ウィンドウ コンテンツを待機」でUIが現れるのを待ってクリックや「Webページのコンテンツを待機」のように確実に動く条件に変更しました。
クリックする際の指定方法の優先順位は以下の通りです。
- UIで指定
- ショートカットキーでの選択
- OCR等の画像での選択になります
⑩ UI要素のゴミ解消
レコーダーを利用して使わなかったアクションを削除してもUI要素はそのまま残ります。利用しなかったものが大量に残り、どれを利用しているかわかりにくかったため、不要なUI要素を全て削除しました。
※これは知っているかどうかだけの差ですが、職場のPADのフロー確認依頼が来た際にフローと関係がないUI要素のごみがあるかないかを見て、その人が何かしらで学習しているか把握する一つの指標かと思っています。
⑪ UI要素が多い問題の解消
レコーダーで作成すると同じ箇所のクリックでも別のUIとして複数登録されることがあります。
そうすると本来一つの登録で済む内容が何個も登録されます。動いている時はそこまで問題になりませんが、UI要素が変わった時に一手間かかります。このままだと一つ修正すれば済むものを複数修正する必要が生じます。
そこで、共通のUI要素があるか確認してまとめていきました。
ここまで読んで頂きありがとうございました。
RPAは直感的に操作できる反面、データ設計やプログラム設計といった「本来理解していて当然の前提」を意識しなくても動くものが作れてしまいます。
個人利用であれば「動けばよい」でも問題になりにくいですが、組織で稼働させるRPAでは、保守性・引き継ぎ・例外対応まで含めた設計が求められます。
RPAが一般的なツールとなった今、過去に作られたRPAが負債として残っている現場も少なくありません。
本記事が、RPAを新たな負債にしないための視点、そして既存の負債を整理・改善する側に回るきっかけになれば幸いです。
Tipsまとめ
[ 設計・運用編 ]
- 「自動化できる」ではなく「自動化し続ける価値があるか」が判断ポイント
- RPA停止時に人が業務を継続できない運用は、そもそも危険
- RPA利用者とRPA保守者の責任を分離しないと、改善ではなく疲弊が進む
- 組織利用のRPAは「便利ツール」ではなく「小さな業務システム」
- 管理者がRPAの内容を理解していない状態は、事故の前兆
- 複数RPA製品の併用は、保守コストを静かに爆増
[ フロー設計編 ]
- 1フロー100アクション超えたあたりから「何かがおかしい」と疑う
- 共通処理はサブフロー化・デスクトップフロー化して部品化
- IFの多重ネストは、読めないフローの第一歩
- 条件分岐が増えそうなら最初からSwitchを検討
- ラベル（GoTo）は最後の手段。多用はほぼ設計負債
[ デバッグ・保守編 ]
- CurrentItem[0] のままでは、未来の自分が詰む
- データテーブルは必ずヘッダー付きで読み込む
- 「何を」「どこに」入力しているかがフロー上で即読める状態を作る
- キー送信より「ウィンドウ内のテキストフィールドに入力」を優先する
- UI要素は“使っているものだけ”が残っている状態が正
- 「待機（秒）」より「コンテンツを待機」で不安定の解消
- 同一UIが複数登録されていないか確認
- UI要素の整理状況を見ると、その人の学習度がだいたいわかる
[ 心構え ]
- RPAは作るフェーズより、壊れた後の対応フェーズの方が長い
- 「とりあえず動く」は、必ずツケを払う
- PADは“誰でも触れる”が、“雑に作っていい”わけではない
質問や改善案があればコメント頂けるとありがたいです。