PCデスクトップをドライブレコーダーのように録画できたら、再現性の低いRPAの不具合原因特定が少しだけ楽になるかも？

RPAによる画面操作は、ほとんど人が見ていないところで行われていますので、画面操作中に発生したトラブルの原因特定が難しい場合があります。
エラー発生のタイミングで、スクリーンショットを保存するようにしておくことで、どこまで処理が動いてエラーになったか分かりますし、表示内容が変更になった場合であれば、エラー原因がスクリーンショットに証拠として残っていますので、エラー発生時のスクリーンショットを取得する処理を実装しておくことは、RPAでは必須といえます。
# 表示内容が原因の不具合にはスクリーンショットが役に立つ
表示内容が原因（例えば、これまではタイトルが[作成]だったボタンが、[登録]に変わったことが原因）の不具合では、スクリーンショットが役に立ちます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/128425/89a9e1fa-8700-7aa4-aff1-4d44c0ca99cf.png)
### スクリーンショットが役に立たない例（内部属性値の変更）
しかしながら、障害発生時のスクリーンショットだけでは原因が特定できない場合もあります。ボタンの内部属性値が変更になった場合は、スクリーンショットがあっても、それだけでは原因を特定することができません。
この場合は、実際に画面を表示して、現在のセレクター設定でボタンが認識できるかどうか検証することで、ボタンの内部属性値が変更になったことが原因であったと、特定することができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/128425/a5e7fcae-9194-85ef-f2aa-4a957ad32502.png)
### スクリーンショットが役に立たない例（外部要因が操作を妨害?）
ところが、ボタンのタイトルが変更になった訳でも、ボタンの内部属性値が変更になった訳でもない場合は、原因の特定が非常に難しくなります。
どういった状況になっていたら、[作成]ボタンをクリックできないのか、考えられる原因をあれやこれや挙げて、絞り込んでいくしかありません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/128425/b44ee7ad-66d5-2d77-abfa-4742ff85190a.png)

たとえば、こんなことが起きたのではないかと考える訳です。
【想定1】ボタンが非活性状態(disable)のときクリックを実行してしまったのだろうか？
【想定2】ボタンをクリックするタイミングでポップアップが表示したのだろうか？
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/128425/4aa8e3c0-0b20-5639-c73a-af3d881560f3.png)

このように、いろいろな可能性が考えられます。しかしながら、このような不具合は再現性が低いことが多く、なかなか原因が特定できないことが多いと思います。
# デスクトップをドライブレコーダーのように録画しておけば
そこで、RPA実行端末のデスクトップを、ドライブレコーダーのように録画する仕掛けを実装しておけば、再現性の低い不具合が発生した場合でも、原因の特定がもう少し容易になるのではないかと考えました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/128425/e99106a4-ab95-d895-68a6-46356676c55e.png)
### 録画機能の目的・用途
デスクトップをドライブレコーダーのように録画する機能は、どのような課題の解決に役立つのか、改めて想定する使い方を考えてみましょう。私が考えたのはこの２つです。
《用途1》
不具合現象を再現することができなくて、原因を特定することができなかった不具合をそのままにするのではなく、再現したときに決定的な証拠が得られるように仕掛けておく。
《用途2》
また、不具合対策だけでなく、RPAの説明や保守資料作成のために、特定のRPAの画面遷移(操作や表示内容)を知りたいときに使う。
### デスクトップ録画の機能要件
この目的・用途に対しての機能要件は何でしょうか。私は、「自動録画」と「対象RPA限定」が、必要であると考えました。
「自動録画」にする理由は、本番で動作しているRPAには、できるだけ手を加えたくないからです。
「対象RPA限定」にする理由ですが、録画ファイルを保存するハードディスク等のストレージの空きが、録画ファイルのために無くなっては困るので、随時ストレージの空きを確保してから録画する必要があります。ドライブレコーダーでも空きを作るときは過去ファイルから削除しています。RPAは実行端末1台で複数のRPAを動作させることが多いので、録画対象のRPAを限定せず、どのRPAが実行するときでも自動録画してしまうと、決定的な証拠を録画しているかもしれないファイルが、ストレージの空きを確保するために削除されるリスクがあります。「対象RPA限定」にする理由は、そのリスクを回避するためです。
### UiPathの場合の実装例
実は、UiPathには、Orchestratorで設定するだけでビデオを保存する機能が実装されていたりするんですが、プロセス終了直前の３分間しか録画されないことと、UiPathを使うとプロセスの開始・終了イベントでの動作確認がやり易かったので、UiPathの場合で実装してみました。

:::note info
UiPathの「ジョブの記録」についての情報はこちら
[Orchestrator ユーザー ガイド - レコーディング](https://docs.uipath.com/ja/orchestrator/standalone/2023.4/user-guide/about-recording)
:::

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/128425/e9a87b84-c400-d8c2-3f6c-958c3443568c.png)
新たに開発環境を用意しなくてもいいように、Windows標準でインストール済みのPowerShellを使って実装した例です。録画の開始から終了までの流れですが、まずRPAが開始するときUiPath.Executorのプロセスが新しく生成されますので、このプロセスの作成イベントで、録画コントローラーを実行します。（図の①）
録画コントローラーは、ストレージの空き容量を確保するため、古いファイルを削除します。録画ファイルを保存するフォルダ内のファイルサイズの最大容量を設定ファイルで決めておいて、次の1ファイルを保存するのに必要な空きが無いときは、古いファイルから順に削除します。（図の②）
次に、録画時間・ファイル保存先フォルダーパスを指定してFFmpegを実行します。（図の③）
FFmpegは、指定された時間が経過すると、録画ファイルを保存して終了します。（図の④）
録画コントローラーが一定周期（図の例では60秒）で図の②と③の処理を実行することで、途切れることなく録画することができます。
# あとがき
UiPath Executorのプロセス作成・終了のイベントで、PCデスクトップを自動録画するアイデアについて紹介しました。UiPathに限らず、RPAプロセスの開始・終了イベントを捉えることができるRPAであれば、この考え方が共通的に使えると思います。この方法なら、既存のRPAに手を加えることなく外付けで自動録画できるので、再現性の低いRPAの不具合が発生した際に、原因特定までに時間が掛かったり、原因が特定できなかったりするリスクに対して、少しだけ有効な手が打てるようになると思います。

### 関連動画
:movie_camera:動画：[Udemy講座『保守支援ツール for UiPath 「FFmpegでRPAの実行状況を録画する」』](https://www.udemy.com/course/ffmpeg-rpa/?referralCode=FC181CDC4A0FA50A582F)