RPAでエラー処理しないといけない理由ってなに？必要性がよくわからないから教えて。
という疑問に答えます。
RPAでエラー処理するべき2つの理由
- エラー処理を行う前提の話
- RPAは本番環境で運用することが基本
- 本番環境ではエラーが分かりにくい
- [1]エラー発生後の処理を行いたいから
- ①リカバリーのための詳細情報を得る
- ②自分以外のユーザーへの情報を伝える
- ③正しい終了処理を行う
- [2]シナリオ実行を続けたいから
記事を書いている僕は、RPA関連の書籍を5冊出版しているRPAの専門家です。7年以上、複数の会社でRPAの導入・開発・運用に携わっています。
本記事は、僕が関わってきたRPAツール（UiPath、WinActor、Power Automate for desktopなど）をイメージして解説しています。
RPA全般について解説していますが、個別のRPAツールに応用してくださいね。
それでは、どうぞ！
（株）完全自動化研究所代表のこさいです。
1) エンジニア歴25年超。開発から業務改善まで幅広く経験してきました
2) 複数の企業においてRPAのコンサルティングを行っています
3) RPA関連の書籍を5冊出版しています
エラー処理を行う前提の話
エラー処理を行う前提をお話します。
RPAは本番環境で運用することが基本
まず、これをお伝えしておきます↓↓
RPAは本番環境で運用することが基本です。
開発し終えたシナリオは、開発環境ではなく、実行端末（実行用パソコン）の本番環境で実行します。
RPAツールで開発したオートメーションのことを、僕は「シナリオ」と呼んでいます。UiPathで「ワークフロー」、Power Automate for desktopで「フロー」と呼ばれているものです。
UiPathではUiPath Robot（UiPath Assistant）もしくはオーケストレータ―から実行します。Power Automate for desktopでコンソール、またはPower Automate（クラウドフロー）から実行します。
よく目にするのは、開発環境のまま運用している人。
これは「デバッグ環境で実行」している状態です。
これは、正しい運用ではありません。
「料理しながら、フライパンにのったままの料理を食べている」感じです。
（それでも、いいという人もいるでしょうけど……。）
ちゃんと、お皿に盛りつけて、テーブルでいただきましょう。
それが、「本番環境で運用する」ということです。
本番環境ではエラーが分かりにくい
デバッグ環境では、エラー発生すると、開発画面内にエラー情報が表示されます。
たとえば、Power Automate for desktopなら、このようにエラーが発生したアクションが赤枠で囲まれます。エラーパネルにも、エラー内容が表示されます。
うん、エラーの発生場所も、原因もわかりやすい！すぐにシナリオを直して、再実行することも容易です。多くの人が、デバッグ環境のまま運用している理由の１つは、コレでしょうね。
一方、本番環境でエラーが発生したときは、
エラー情報が少なく、エラーの原因がわかりにくい。その場で、シナリオを直すこともできません。
だからこそ、エラー処理を行う必要があるんです！
逆に、デバッグ環境で運用しているかぎり、エラー処理の重要性はわからないんじゃないかな。
というわけで、ここまではエラー処理を行う理由の前置きでした。
ここから、エラー処理を行う理由の深掘りになります。
[1]エラー発生後の処理を行いたいから
「RPAでエラー処理するべき理由」の1つ目は、「エラー発生後の処理を行いたいから」です。
エラー処理を行わないと、このようにエラーが発生したときのアクションを実行できません。
エラー発生後の処理として、よく行うことを3つ解説します。
- ①リカバリーのための詳細情報を得る
- ②自分以外のユーザーへの情報を伝える
- ③正しい終了処理を行う
それでは、1つずつ、詳しく解説していきます。
①リカバリーのための詳細情報を得る
エラー処理の目的の1つ目は「リカバリーのための詳細情報を得る」ことです。
本番環境でエラーが発生したときに、適切にリカバリーするには、
- どこでエラーが発生したのか
- どんな原因でエラーが発生したのか
を知りたい、ですね。
RPAツール自体の仕組みで、エラー内容を表示してくれるケースもあります。
しかし、このエラー情報が足りないなら、エラー情報を詳しく得るための処理を行います。
具体的には、
- ポップアップメッセージで、詳しいエラー情報を表示する
- ログに詳しいエラー情報を書き出す
といった方法です。
②自分以外のユーザーへの情報を伝える
エラー処理の目的の2つ目は「自分以外のユーザーへの情報を伝える」ことです。
RPAは「自分で作って、自分で使う」というケースだけではありません。
「RPAを作れる人がシナリオを作って、RPAにあまり詳しくないユーザーが使う」というケースはよくありますよね。このケースを考えてみましょう。
↓↓
エラーが発生したら、なんか不親切なエラーメッセージが表示される
これでは、ユーザーは困惑してしまいます。
シナリオを作った開発者に、すぐ問い合わせするでしょう。
シナリオを作った人も、何回も問い合わせを受けて、疲弊します。
問い合わせ対応ばかりで、開発が進まないよ……
こういうケースを防ぐために、エラー発生時には、
- わかりやすいエラーメッセージに変えて、表示する
- このあと、どうすればいいのかを教える
といった処理を加えるのが、いい方法です。
③正しい終了処理を行う
エラー処理の目的の最後は「正しい終了処理を行う」ことです。
本番環境でエラーが発生したら、そこでシナリオの実行は終了します。
もし、RPAツールがExcelの操作途中だったら、途中で終了、というわけ。
このとき、Excelを非表示で操作していたら？
Excelのインスタンス（実体）は残ったままになってしまいますね。
（「裏で生きている」と言ったりします）
このまま、再度シナリオを実行したら、別のエラーが発生するかも！
「Excelは既に開いている」って言われた……
エラー発生時には、エラー処理を行い、Excelを適切に終了させることが重要なことがわかりますね。
Excelだけではなく、アプリケーションやWebサイトの操作でも同じ。
正しい方法でログアウトして、ウィンドウを閉じましょう。
[2]シナリオ実行を続けたいから
エラー処理を行う理由の2つ目は「シナリオ実行を続けたいから」です。
エラー発生時も自動的にリカバリーできるケースもあります。そのリカバリーアクションを設定していなかったら、このようにフローはそこで終了します。
せっかく、リカバリー方法があるのに、、
エラー発生のたびに手動でリカバリーしないといけなかったら、大変だし、ムダ！！
自動リカバリー可能なケースだったら、その処理を組み込みましょう。リカバリーして、また正常なシナリオに復帰できれば、運用の工数が減りますね。
まとめ
この記事では、『RPAでエラー処理が必要な理由』を解説してきました。
- エラー処理を行う前提の話
「RPAでエラー処理って必要か？」と疑問に思う人は、「エラー処理を行う前提の話」で書いたように、デバッグ環境で運用しているから、かも。
で、RPAでエラー処理が必要な理由は、大きく分けると次の2つ。
- [1]エラー発生後の処理を行いたいから
- [2]シナリオ実行を続けたいから
です。
本番環境で運用して、かつ、エラー処理を行うことで、RPAをMAXで活用できるようになりますよ！
それでは、また♪