RPAでエラー処理するべき2つの理由

RPAでエラー処理しないといけない理由ってなに?必要性がよくわからないから教えて。

という疑問に答えます。

本記事のテーマ

RPAでエラー処理するべき2つの理由

記事の内容
  • エラー処理を行う前提の話
  •  RPAは本番環境で運用することが基本
  •  本番環境ではエラーが分かりにくい
  • [1]エラー発生後の処理を行いたいから
  •  ①リカバリーのための詳細情報を得る
  •  ②自分以外のユーザーへの情報を伝える
  •  ③正しい終了処理を行う
  • [2]シナリオ実行を続けたいから
記事の信頼性

記事を書いている僕は、RPA関連の書籍を5冊出版しているRPAの専門家です。7年以上、複数の会社でRPAの導入・開発・運用に携わっています。

読者さんへの前書き

本記事は、僕が関わってきたRPAツール(UiPath、WinActor、Power Automate for desktopなど)をイメージして解説しています。

RPA全般について解説していますが、個別のRPAツールに応用してくださいね。

それでは、どうぞ!

この記事を書いた人
この記事を書いた人
こさい
こさい

(株)完全自動化研究所代表のこさいです。

1) エンジニア歴25年超。RPA開発および支援8年超
2) RPA関連の書籍を5冊出版。現在はGPT×PADの書籍を執筆中!
3)当サイトのプレミアム会員募集中!無限回答、動画見放題。詳しくはこちら

エラー処理を行う前提の話

エラー処理を行う前提をお話します。

RPAは本番環境で運用することが基本

まず、これをお伝えしておきます↓↓

RPAは本番環境で運用することが基本です。

開発し終えたシナリオは、開発環境ではなく、実行端末(実行用パソコン)の本番環境で実行します。

シナリオ

RPAツールで開発したオートメーションのことを、僕は「シナリオ」と呼んでいます。UiPathで「ワークフロー」、Power Automate for desktopで「フロー」と呼ばれているものです。

本番環境

UiPathではUiPath Robot(UiPath Assistant)もしくはオーケストレータ―から実行します。Power Automate for desktopでコンソール、またはPower Automate(クラウドフロー)から実行します。

よく目にするのは、開発環境のまま運用している人。
これは「デバッグ環境で実行」している状態です。

今後は、「開発環境のまま運用している」ことを「デバッグ環境で実行している」と表記します。

これは、正しい運用ではありません。
「料理しながら、フライパンにのったままの料理を食べている」感じです。
(それでも、いいという人もいるでしょうけど……。)

ちゃんと、お皿に盛りつけて、テーブルでいただきましょう。
それが、「本番環境で運用する」ということです。

本番環境ではエラーが分かりにくい

デバッグ環境では、エラー発生すると、開発画面内にエラー情報が表示されます。

たとえば、Power Automate for desktopなら、このようにエラーが発生したアクションが赤枠で囲まれます。エラーパネルにも、エラー内容が表示されます。

Power Automate for desktopにおけるエラー発生時の画面

うん、エラーの発生場所も、原因もわかりやすい!すぐにシナリオを直して、再実行することも容易です。多くの人が、デバッグ環境のまま運用している理由の1つは、コレでしょうね。

一方、本番環境でエラーが発生したときは、

エラー情報が少なく、エラーの原因がわかりにくい。その場で、シナリオを直すこともできません。

だからこそ、エラー処理を行う必要があるんです!
逆に、デバッグ環境で運用しているかぎり、エラー処理の重要性はわからないんじゃないかな。

というわけで、ここまではエラー処理を行う理由の前置きでした。
ここから、エラー処理を行う理由の深掘りになります。

[1]エラー発生後の処理を行いたいから

「RPAでエラー処理するべき理由」の1つ目は、「エラー発生後の処理を行いたいから」です。

エラー処理を行わないと、このようにエラーが発生したときのアクションを実行できません。

エラー発生時の処理を行えない

エラー発生後の処理として、よく行うことを3つ解説します。

エラー処理の目的
  • ①リカバリーのための詳細情報を得る
  • ②自分以外のユーザーへの情報を伝える
  • ③正しい終了処理を行う

それでは、1つずつ、詳しく解説していきます。

①リカバリーのための詳細情報を得る

エラー処理の目的の1つ目は「リカバリーのための詳細情報を得る」ことです。

本番環境でエラーが発生したときに、適切にリカバリーするには、

  • どこでエラーが発生したのか
  • どんな原因でエラーが発生したのか

を知りたい、ですね。

RPAツール自体の仕組みで、エラー内容を表示してくれるケースもあります。
しかし、このエラー情報が足りないなら、エラー情報を詳しく得るための処理を行います。

具体的には、

  • ポップアップメッセージで、詳しいエラー情報を表示する
  • ログに詳しいエラー情報を書き出す

といった方法です。

②自分以外のユーザーへの情報を伝える

エラー処理の目的の2つ目は「自分以外のユーザーへの情報を伝える」ことです。

RPAは「自分で作って、自分で使う」というケースだけではありません。

「RPAを作れる人がシナリオを作って、RPAにあまり詳しくないユーザーが使う」というケースはよくありますよね。このケースを考えてみましょう。

↓↓

ユーザー
ユーザー

エラーが発生したら、なんか不親切なエラーメッセージが表示される

これでは、ユーザーは困惑してしまいます。
シナリオを作った開発者に、すぐ問い合わせするでしょう。

シナリオを作った人も、何回も問い合わせを受けて、疲弊します。

RPA開発者
RPA開発者

問い合わせ対応ばかりで、開発が進まないよ……

こういうケースを防ぐために、エラー発生時には、

  • わかりやすいエラーメッセージに変えて、表示する
  • このあと、どうすればいいのかを教える

といった処理を加えるのが、いい方法です。

③正しい終了処理を行う

エラー処理の目的の最後は「正しい終了処理を行う」ことです。

本番環境でエラーが発生したら、そこでシナリオの実行は終了します。

もし、RPAツールがExcelの操作途中だったら、途中で終了、というわけ。

このとき、Excelを非表示で操作していたら?
Excelのインスタンス(実体)は残ったままになってしまいますね。
(「裏で生きている」と言ったりします)

このまま、再度シナリオを実行したら、別のエラーが発生するかも!

ユーザー
ユーザー

「Excelは既に開いている」って言われた……

エラー発生時には、エラー処理を行い、Excelを適切に終了させることが重要なことがわかりますね。

Excelだけではなく、アプリケーションやWebサイトの操作でも同じ。
正しい方法でログアウトして、ウィンドウを閉じましょう。

[2]シナリオ実行を続けたいから

エラー処理を行う理由の2つ目は「シナリオ実行を続けたいから」です。

エラー発生時も自動的にリカバリーできるケースもあります。そのリカバリーアクションを設定していなかったら、このようにフローはそこで終了します。

フローを続けられない

せっかく、リカバリー方法があるのに、、
エラー発生のたびに手動でリカバリーしないといけなかったら、大変だし、ムダ!!

自動リカバリー可能なケースだったら、その処理を組み込みましょう。リカバリーして、また正常なシナリオに復帰できれば、運用の工数が減りますね。

まとめ

この記事では、『RPAでエラー処理が必要な理由』を解説してきました。

  • エラー処理を行う前提の話

「RPAでエラー処理って必要か?」と疑問に思う人は、「エラー処理を行う前提の話」で書いたように、デバッグ環境で運用しているから、かも。

で、RPAでエラー処理が必要な理由は、大きく分けると次の2つ。

  • [1]エラー発生後の処理を行いたいから
  • [2]シナリオ実行を続けたいから

です。

本番環境で運用して、かつ、エラー処理を行うことで、RPAをMAXで活用できるようになりますよ!

それでは、また♪