©️ arts & crafts All rights reserved.
少しの工夫でRPAはもっと安定稼働できる
目次
UiPath（RPA）を開発して動かした結果
UiPathをはじめとして、RPAを用いて業務を自動化した際、使用しているブラウザやWebサイトなどの不具合や、ロボットの事前準備や別作業で操作していたロボットの作業ミスによってロボットが停止してしまうことは、どんなに気を付けて設計しても完全には避けて通れません。
人間が作業する際は途中で作業ミスに気付いた時臨機応変に対応できますが、ロボットによって作成されたロボットは最初からエラーになった場合を想定していない限り、不測の事態に対応できず、Webサイトや使用しているシステムのレイアウトが変わった際にセレクターを取得できずエラーになってしまったり、ダウンロードファイルを指定フォルダ以外に格納した際に見つけられなくなったりという理由でエラーを発生させてしまいます。
だからと言って、毎回ロボットが途中でストップしてしまうことや、人の手で何回もロボット実行をリトライして作業工数を取られてしまうと、RPAを導入したメリットが全くなくなってしまいます。
今回は、そんなエラーになるべく対処していく方法を自分の備忘も兼ねてですが、記事としてまとめてみました。
エラーパターンを想定する
なにより最初に行うべきことは、「自動化する対象の業務において、どういったエラーが発生し得るか？」ということを洗い出すことです。
自動化する前に、普段どういった工程で作業しているかを改めて手順書やフロー図として考えてみることが一番でしょう。元々手順書がある場合は、それが最新の作業手順に沿っているか確認しつつ、どのようにロボットで自動化していくかを落とし込むとよいでしょう。
因みに、この「自動化対象の業務の手順書やフロー図を用意する」ことは、UiPathをはじめとしたRPA開発を開発者に依頼する場合も非常に役立つ資料となりますし、実際の手順を改めて洗い出すことで作業の無駄に気が付くことができるので、自動化する前に用意しておいて損はありません。また、資料がない状態で開発を進めていくと認識相違や設計の抜け漏れが発生する可能性もありますので、手戻りを防ぐためにも資料があったほうが望ましいです。
それでは例として、RPAでとりわけ考慮すべきエラーとなりうるパターンをいくつか挙げてみます。
エラーパターンを洗い出す際は、下図のようにExcelを使用してどの作業のどこでどういったエラーが発生するかを一覧で確認できるようにするとよいでしょう。
① ダウンロードファイルが存在しない
ロボットでExcelファイルなどを使用する際に、SharePointやWebサイトからダウンロードする処理は頻出の動作です。ただ、ダウンロードが必ず成功するとは限りません。
回線が重くファイルが完全にダウンロードできない、Webサイトのレイアウトが変わってしまってダウンロードボタンがクリックできない、そもそもファイルが格納されていない、など原因はいくつか考えられます。
② ファイルが存在しない
上記と似たような原因ではありますが、例えば前処理で人の手でファイルを格納しておく必要があったり、ロボットによってファイル移動する必要があったりした場合、移動元のファイルが存在しない、移動先のパスが間違っているなどの原因でファイルが存在せずエラーになる可能性があります。
③ セレクターが誤っている
Webサイトのセレクターや、各種アプリケーションウィンドウに対するセレクターが変わってしまったことによってクリックや文字入力ができなくなる可能性があります。
ありがちな例としては、Webサイトや社内システムのレイアウトが変わったことによって従来のセレクターでは正しく操作できなくなってしまうことが挙げられます。
セレクターの取得はそもそもただ設定すればいいというものではないので、最初に取得する際にどこまで変更を許容できるかが肝心になってきます。
④ 入力規則が一致しない
日付形式、時間形式など、特定の入力規則（例えばyyyyMMddであったり、yyyy年MM月dd日であったり）で入力する必要がある際に、人の手で設定した値が間違っている・Excel等から取得した値が間違っているといった理由で値が正しく入力できないエラーが考えられます。
想定したエラーに対して回避策を設計する
上で洗い出したエラーに対して、ロボットがどうするべきか？ を次に洗い出して、ロボットに実装します。
なお、こういったエラーが発生する可能性のある操作に関しては、TryCatchアクティビティを使用してエラーが発生したらCatchに遷移する、という処理がほぼ必須となります。Catchに遷移した後は、ThrowアクティビティやRethrowアクティビティを使用して、再実行だったりエラーログの出力だったりを行う形が一般的です。
ロボットがするべきこととしては、そのロボットがどのような形で起動しているかも考慮する必要があります。UiPathで言うと、UnattendedRobotか、AttendedRobotか、です。
UnattendedRobotの場合ですと、ロボットは誰も見ていない状態で自動的に起動し、動作を完了させます。つまり、一旦画面を止めて人の判断を仰ぐ、という方法を使ってしまうとそこからずっと動かない状態になってしまいますので避けるべきです。
AtrendedRobotでは、逆に人が見ながらロボットが動作しているので、エラーが発生した場合にエラー原因を記載したポップアップウィンドウを出現させて一度動作を止め、人の手で対応出来る場合は対応してから再びロボット動作に戻る、対応できない場合はロボットを停止する、といった処理が可能となります。
また、ファイルが最初から格納されていない場合は時間の無駄になってしまいますが、ファイルのダウンロードが完全に完了していなかったり、ページの読み込みが完全に完了していなかったりとロボットの操作が早すぎることに起因するエラーを想定して、リトライスコープでアクティビティを囲むことは基本の対応です。
先に挙げた例に合わせて、簡単に対処方法を考えていきましょう。
① ダウンロードファイルが存在しない
この場合は、大まかに「ダウンロードは行っているが、ファイルが重い、回線が悪いなどの理由で完全にダウンロードしきっていない」場合と「そもそもダウンロードすべきファイルが存在していない」場合に分けられます。
前者の場合の対応方法はリトライスコープを使用してファイルが使用できるようになるまで待機しながら実行をリトライしたり、最近登場した「ダウンロードを待機」アクティビティを使用したりすることで回避可能です。
後者の場合は判断が難しいので、AttendedRobotの場合はポップアップウィンドウでファイルがない旨を表示してユーザに確認してもらい、対処できる場合は操作してもらって対処後にロボットを続行、できない場合はスローアクティビティでCatchに送り、最初から再実行するか、ロボットを中断する方法が考えられます。
② ファイルが存在しない
対象のファイルの種類に応じて処理を分ける方法を挙げます。
まず、存在していないファイルがロボットの実行に必要な設定ファイルの場合、それ以降の処理に必要な値が取得できなくなってしまうのでロボットを停止すべきです。
業務の処理対象ファイルであり、複数処理対象のうちのひとつがないなどの場合は、その対象ファイルをスキップして次のファイルに移動しても処理の続行が可能であれば、都度スキップしてロボットは最後まで実行、エラーのあったファイルはログに出力する形が良いでしょう。
AttendedRobotの場合は、必要に応じてロボットを一時中断、人の手でファイル移動などの処理を行い続行する方法でも問題ないでしょう。
③ セレクターが誤っている
Webサイトを使用している場合は、サイトのレイアウトなどが変わっていないかをまず確認する必要があるエラーです。また、セレクターの問題の場合は一度停止して人の手で復旧させることは難しいので、基本的に一度ロボットをエラー停止させて、開発者にてロボットロボット自体を修正してから再度実行、となるでしょう。
ただ、スキップして続行が可能な場合やAttendedRobotで人がクリック操作などできる場合、クリック後出てくるウィンドウの有無や、画面要素の有無を判定して、出てこなければスキップや一時停止して人が操作してからロボット操作に戻すことも可能です。
因みにセレクターの取得でエラーが発生した際に確認すべき箇所は、「セレクターにidxを使用していないか？」「開いているウィンドウとセレクターを取得しているウィンドウは正しいか？」「変数で指定すべき箇所はないか？」が挙げられます。日時などがウィンドウタイトルなどに含まれてしまう場合は、そこを変数化もしくはアスタリスク（ワイルドカード）を使用して置換できるようにしておく必要があります。
レイアウトが変わってしまっている場合はロボット上で要素を取得しなおし、新しく取得したセレクターに問題がない確認してから再度パブリッシュするようにしてください。
④ 入力規則が一致しない
「テキストの一致を確認」アクティビティを使用して、入力する文字列が正しい入力規則になっているかを確認するのが一番簡単な方法です。
一致していればそのまま続行、一致していなければエラー処理を行うだけなので、簡単に対処が可能です。
ここまでの基本の処理と、例として挙げた①から④までのサンプルエラー処理を下図にまとめてみましたので、必要であれば参考にしてみてください。
異常系テストを実行する
ロボットの実装が完了して、動作検証や各種テストを行う際、正常系テストのみ実行して本番環境で動作させてしまうことは望ましくありません。
正常系テストのみだと、いざエラーが発生した際に想定した動作を組んでいても、エラー処理アクティビティ側でエラーになってしまって手戻りになってしまう可能性があるからです。
先に洗いだしたエラーになる原因を含んだテストデータをあえて作って実行して、エラー時に想定した動作が正しく実行されるか（ロボットが正しいポップアップウィンドウを出すかだったり、エラーメッセージをログして終了したりが挙げられます）もあわせて確認してから、本番環境で動作開始するべきです。
例えばExcelファイルを格納せずにロボットを実行したり、あえて誤ったデータの入った参照ファイルを読み込んだりする方法が一番簡単です。サイトのレイアウト変更によるエラーテストは、検証用サイトがない限り難しいですが、ダウンロード作業であれば一度WiFiを切断してみる、ロボットをデバッグモードで実行して、ダウンロード開始後に一時停止してダウンロードしたファイルを削除してから続行してみるといった方法で対処できます。
再びUiPathの話にはなりますが、現在のUiPathには動作検証・テストを補助するアクティビティ、機能を使用することができます。
UiPath Test Suite
UiPath Test Suiteは、UiPath上で複数のテストデータを使用してテストを実行し、その結果の検証やテストパターンをどの程度網羅したか確認できる機能です。カバレッジが確認できるため、より網羅的な動作確認が可能になります。
使用するためには、UiPath StudioでTest Activityをインストールする必要があります。基本的なテストだけならばこれで十分ですが、Orchestratorと接続することでテスト結果をOrchestratorに送ったり、複数のテストデータをまとめて使用したりとより高度なテストが可能です。
以下に、簡単にではありますがUiPath Test Suiteの使い方をまとめてみました。
こちらで使用している環境は、UiPath Studio 2023.8.0 Community Editionとなります。UiPath.Testing.Activities自体は2020.04以上のバージョンのStudioでの使用が推奨されています。パッケージのインストールが必要になりますので、お使いの環境によっては使用できない可能性もあるため、UiPathを全社利用されている場合などはご注意ください。
少しの工夫と労力でより安定するロボットに
RPAを使用して業務を自動化するのであれば、なるべくメンテナンスを最小限に抑えて、長期間安定して稼働するロボットを作ることが最もコストパフォーマンスがよく、導入する意義があります。
そのためには、RPAのロボット設計前から業務整理を行い、エラーになりうる箇所を洗い出して事前にリトライや回避可能な措置を取り、早い段階でリカバリできるようにする仕組みを組み込んでおくことが肝心です。
人の手で作業するよりも融通が利かないということを念頭に置きつつ、しっかりと設計すれば人が作業するよりも早く、ミスなく業務ができるようになりますので、これからRPAを導入しようと考えている方や、RPA開発初心者の方はエラーに備えることも重要だと覚えておいてほしいポイントです。
この記事が皆様のUiPath開発の一助になりましたら幸いです。
【参考】
熊谷菜海
アーツアンドクラフツConsulting & Solution事業部/プログラマー。得意分野はRPA
