はじめに
Healing Agent（以下はHAと略称します）は、UI要素が見つからないといったエラーが発生した際に、提案または自動的に回復してくれるUiPathの新機能です。HAに関する紹介は、UiPath AIエージェント活用ガイド ~ Healing Agentの魅力とは？をご参考ください。
本記事は、セレクターの回復を試す際に、Ancestryデータ（以下は先祖情報と称する）の有無に対する回復戦略に影響を説明していきたいと思います。
HAの回復戦略
公式ドキュメントは、以下のようにHAの回復戦略を記述しています。
"HAは、さまざまなシナリオに合わせた複数の回復戦略を採用しています。これらの回復戦略はAIドリブンであり、可能性がある一致を新たに生成します。すべての回復戦略の結果を比較して高い精度を確保し、誤検知を最小限に抑えることによって、最終的なターゲット要素を特定します。"
公式ドキュメントのほうでも、すべての戦略を羅列して深く説明していませんが、HAがよく使う回復戦略は、あいまい検索を利用するFuzzySearch、先祖情報を利用するAncestrySeach、画像分析の技術を利用するComputerVision、それ以外、TimeoutIssue、Semantic、Responsive、Closeといった方法もあります。
すべての回復戦略が知りたい方は、デバッグファイルのAnalyzersStatisticsキーのバリューを確認してください。本文デバッグファイルの結果を説明するところは、AnalyzersStatisticsに少し触れています。
今回は、先祖情報の有無によるAncestrySeachへの影響のみ話させてください。
先祖情報とは
UI要素の情報を取得する際に、UiPathは要素を特定できる重要な属性のみをセレクターエディターにまとめます。だが、それはUiPathが取得したすべて情報ではありません。セレクターエディターより詳細な情報は、プロジェクトに付随して保存されています。
例：RPAChallengeのSubmitボタンをクリックする場合、セレクターエディターは、以下のようですが。
プロジェクトフォルダ￥.storage￥.runtime￥AncestryPersistenceServiceに、1つのUI操作アクティビティにつき、1つの先祖情報ファイルが生成されます。それを開いて確認すると、セレクターに含まれていない情報も記録されています。
HAの回復における先祖情報の役割
意図としてセレクターを改ざんし、実行に際してエラーを出させることで、先祖情報はどのように回復戦略に影響を及ぼしているのかを確認してみました。
検証環境
まず、上記検証を実施する環境を説明します。
①Studio 24.10.9
②UiPath.UIAutomation.Activities 25.10.12
③検証サイトは、RPAChallengeを使います。以下はRPAChallengeのフォーム入力画面です。
サンプルコード
First Nameを入力した後、Submitをクリックするという同様のサンプルコードを2つ用意しておきました。検証の目標は、それぞれ先祖情報のある、ない状態で、HAはどのように動作するかということです。
サンプルコードの構成は以下の通りです。
検証手順
サンプルコードAを先祖情報を残した状態で実行します。一方で、サンプルコードBを先祖情報を削除した状態で実行します。それぞれ、HA動作の違いを比較します。
サンプルコードA：先祖情報を残した状態で実行する
①「First Name」のテキストボックスに「文字を入力」アクティビティでセレクターを取り、「テスト」を入力する
②「Submit」ボタンを「クリック」アクティビティでセレクターを取得する
③Studioで「Submit」のセレクターを手動で編集する
aanameとcheck:textの値を、「Submit」から「提出」に変更する
④プロジェクトフォルダ￥.storage￥.runtime￥AncestryPersistenceService中の先祖情報を確認する
手動でセレクターを編集しましたが、先祖情報データは取得時のままで、変わらないことがわかりました。
⑤Orchestratorでプロセスとしてデプロイして、HAをオンにした状態で実行する
⑥実行完了後、HAのデバッグファイルの中身を確認する
HAのデバッグファイルについて、以前qiita記事を作成しましたが、まだ読み方がわからない方はぜひご参考ください。
参考資料：Healing Agentデバッグファイルの適用方法
サンプルコードAのデバッグファイルを分析する
①回復戦略の統計分析結果（AnalyzersStatistics）
AnalyzersStatisticsは、HAにあるすべての回復戦略を羅列し、その戦略が試された場合は、"DetectionsCount":1にし、試されなかった場合は、"DetectionsCount":0にするという統計データを記録しています。
FindAlternativeAncestryTargetStrategy（先祖情報にかかわる戦略）は1になったため、HAはこの戦略を試したと意味しています。ついでに、FindAlternativeFuzzyTargetStrategy（あいまい検索にかかわる戦略）も1になりました。
②採用された回復戦略（InferMethod）
"RecoverySuccessful": trueになったため、回復に成功したとわかります。
それに、HAはいろいろと試したところ、最後に"AncestrySearch", "FuzzySearch"という２つの回復戦略を採用しました。
以上で、先祖情報データがある場合、HAは、UI要素が見つからなかった時に、先祖情報を参照して回復を試すことがわかりました。そのため、対向システム（RPAChallenge）のHTMLデータに変更がない場合、先祖情報を用いたら容易に要素が検出できるでしょう。
サンプルコードB：先祖情報を削除した状態で実行する
①「First Name」のテキストボックスに「文字を入力」アクティビティでセレクターを取り、「テスト」を入力する
②「Submit」ボタンを「クリック」アクティビティでセレクターを取得する
③Studioで「Submit」のセレクターを手動で編集する
aanameとcheck:textの値を、「Submit」から「提出」に変更する
④プロジェクトフォルダ￥.storage￥.runtime￥AncestryPersistenceService中の先祖情報を削除する
⑤Orchestratorでプロセスとしてデプロイして、HAをオンにした状態で実行する
⑥実行完了後、HAのデバッグファイルの中身を確認する
サンプルコードBのデバッグファイルを分析する
①回復戦略の統計分析結果（AnalyzersStatistics）
このたび、FindAlternativeAncestryTargetStrategyは0になりました。その代わりに、HAはFindAlternativeSemanticTargetStrategy（セマンティックにかかわる戦略）、FindAlternativeFuzzyTargetStrategy、FindAlternativeTextAttributeTargetStrategyを試しました。
②採用された回復戦略（InferMethod）
"RecoverySuccessful": trueになったため、回復に成功したとわかります。
それに、HAはいろいろと試したところ、最後に"Semantic", "FuzzySearch"の回復戦略を採用しました。
つまり、先祖情報データのない状態でも、HAは、その他の方法を試し、要素の回復に努力します。先祖情報データもない、セレクターも変わった状態で要素の検出が非常に難しいと思いきや、検出できたのは、HAの強さを感じました。
終わりに
今回は、HAの回復における先祖情報データの役割について検証しました。先祖情報データは、あくまでも数多い回復戦略の中の1つで、このデータがあれば、セレクター取得時の豊富な情報を十分に利用し、比較的に容易な方法で回復してくれます。一方で、要素に関するデータをすべて削除し、セレクターも編集した状態でも、HAは他の戦略を採用して回復を試してくれます。なんと賢いAgentですね。