#4 RPA運用はどう変わる?「Healing Agent」の実力を探る
RPA(ロボティック・プロセス・オートメーション)による業務の自動化を実現したものの、操作対象システムの改修や高負荷状態によって実行エラーが発生し、メンテナンスに苦労されている方も多いのではないでしょうか?そこで注目したいのが、UiPath社が提供する新機能「Healing Agent」です。一般的にRPAが苦手とする「予期しない変化」に、柔軟に対応する機能となっています。RPAによる業務の自動化に関して、現場が抱えている悩みを解消する糸口になるかもしれません。本コラムでは、TISのRPAエンジニアが検証したHealing Agentの機能と検証結果を紹介します。Healing Agentとは一体どのような機能なのか、本コラムで是非一緒に覗いてみましょう。
目次
1.RPA運用の壁とは?
RPAによる業務の自動化は多くの企業で導入・展開が進んでいます。大企業ではすでに一般化し、中小企業でも活用が広がるなど、RPAによる業務の自動化は、今や当たり前となりつつあります。
RPAが抱える課題
RPAは定型業務の自動化に強みを持っており、事前に定められた手順やルールに従って業務を実施します。また、タイムアウトエラーやUIの変化(例:日付部分が変化)といった可変的な要素も、事前に予測可能であれば、対応することが可能です。
一方、事前に定められていない、つまり予期しない状況での対応は苦手です。例えば、「不要なポップアップが表示されたから閉じる」といった対応は、人間にとっては簡単な判断でしょう。しかし、「ポップアップを閉じる」という動作が事前に定義されていなければ、RPAにとっては実行エラーの原因となってしまいます(図1)。そのため、自動化対象のシステムが更改されるたび、既存RPAの挙動確認、および処理内容の修正が必要でした。
Healing Agentの登場
そんなRPAの課題に光を差し込む機能が登場しました。それが、Healing Agentです。RPAが苦手とする柔軟な対応を実現する機能であり、既存課題を突破することが期待できます。では、Healing Agentの特徴を次章で確認しましょう。
2.技術的観点から見る!Healing Agentの特徴
Healing Agentの主な特徴は以下の通りです。
機能①推奨事項の提案
実行エラーの内容をもとに、Healing Agentがプロセスの修正案を提示してくれます。新しいセレクターや想定外のポップアップに対する追加処理、待機時間の追加等が、修正案の例です(表1)。具体的な修正内容は、Orchestratorのジョブ詳細画面から確認できます(図2)。
従来は、実行エラーの解析から、修正方法の検討、修正作業の全てを人間が実施していました。しかし、Healing Agentを利用すると、修正方法の検討まで自動で実施されるため、開発時間の削減が期待できます。提示された修正方法に従うだけで済むため、開発者間のスキルにばらつきがあっても、修正内容に大きな差が出ない点もメリットです。
| エラー原因 | 自己修復例 |
|---|---|
| セレクターが見つからない | 新しいセレクターに変更 |
| 想定外のポップアップが出現 | ポップアップを閉じて後続処理を継続 |
| アクティビティのタイムアウトが発生 | 待機時間を自動で延長 |
表1:Healing Agentで自己修復可能なエラー種別
機能②自己修復
処理中にエラー箇所を発見した際、Healing Agentが自動で修正案を考え、処理内容を自己修復します。自己修復に成功した場合、実行を中断することなく後続処理が継続されます。そのため、手動で再実行する必要はありません。
なお、修復内容の詳細は、「推奨事項の提案」時と同様、Orchestrator画面から確認可能です。自己修復の場合、処理結果がエラーにならない、つまり自己修復が成功する限り、1つのプロセスに存在する複数のエラー箇所にも対応できます。(詳細は、次章をご覧ください。)
前提条件
Healing Agentを利用するためには、以下を満たす必要があります(表2)。
詳細はUiPath公式ドキュメントを参照ください(参照:https://docs.uipath.com/ja/agents/automation-cloud/latest/user-guide-ha/healing-agent-prerequisites#prerequisites)。
| プロジェクト種別 | Windowsプロジェクト、クロスプラットフォーム |
|---|---|
| UI Automationアクティビティ | モダンアクティビティ(一部(*1)を除く) |
| UI Automationバージョン数 | ver25.10.2以降 |
| Robotバージョン数 | ver24.10以降(Enterprise版)(*2) |
| Studioバージョン数 | ver24.10以降(Enterprise版)(*3)(*4) |
| Orchestrator環境 | Automation Cloud |
| 実行種別 | ジョブ(トリガーやテストケースは対象外) |
表2:Healing Agentの利用前提条件
(*1)対象アクティビティは以下を参照。
https://docs.uipath.com/ja/agents/automation-cloud/latest/user-guide-ha/healing-agent-limitations#unsupported-activities
(*2)UiPath Insightsを利用する場合は、「ver2025.0.161以降」の利用が必要。
(*3)Orchestratorジョブ画面のHealing Agentパネルから、直接Studioを起動する機能を利用する場合は、「ver2025.0.157以降(Enterprise Cloud 版)」の利用が必要。
(*4)Studio「ver24.10.x」を利用する場合は、「<Studioインストールパス>/Profiles/Development.json」の、「EnableAiRobot」 プロパティを true に変更する必要がある。
利用方法
Orchestrator上のプロセス単位でHealing Agentを有効化します(図3)。「推奨事項の提案」のみ、または「推奨事項の提案+自己修復」のいずれかを設定可能です(表3)。Orchestratorからジョブ実行する際はプロセスの設定内容が引き継がれますが、ジョブ単位でHealing Agentの設定を変更して実行することもできます。
| Healing Agentを有効化 | 推奨事項の提案 |
|---|---|
| Healing Agentの自己修復を有効化(*1) | 推奨事項の提案+自己修復 |
表3:Healing Agentの設定パターン
(*1)「Healing Agentを有効化」をONにした際のみ表示される設定項目です。
3.Healing Agentを検証してみた!
本章では、Healing Agentを実際に検証した結果を、ご紹介します。なお、検証において、「Healing Agentを有効化した」というのは、「推奨事項の提案」および「自己修復」をいずれも有効化している状態を指しています。
検証準備
まず、図4に示す作業をRPAで自動化します。次に、業務システムの一部を変更します(図5)。変更点は、以下の2つです。
変更点①:
業務画面を開いた際に、ポップアップが表示される点です。ポップアップ上の「OK」ボタンをクリックしない限り、後続操作ができない状態になります。
変更点②:
クリック対象のボタン名が、日本語ではなく英語で表示される点です。なお、各クリックアクティビティのセレクター情報には、日本語のボタン名が設定されています。
検証内容
まず、Healing Agentを無効化した状態でRPAの挙動を確認します。プロセスにはポップアップを閉じる処理が実装されていないため、後続操作が不可となり、実行エラーが発生する状態です。また、ポップアップを手動で閉じて、無理やり後続操作を継続させた場合も、クリック対象として指定した日本語のボタン名が見つからず、実行エラーが発生します。
では、Healing Agentを有効化した状態でRPAを実行した場合、どのような挙動になるのでしょうか。
検証結果
Healing Agentの自己修復機能によりエラー要因が自動で修正され、RPAの処理が正常に完了することを確認できました。また、1つのプロセスにエラー要因が複数存在する場合も、Healing Agentが有効に機能することが検証で得られています。
変更点①については、ポップアップの表示を検知するだけでなく、ポップアップを閉じる処理も、Healing Agentの自己修復機能によって成功しています。なお、自己修復した結果をもとに、開発者が処理内容を修正できるように、修正内容も提示されました(図6)。
変更点②については、既存のセレクターをもとに予測した結果、新しいセレクターを定義した上で、処理を実行しています(図7)。なお、図7では「検索」ボタンの自己修復を取り上げていますが、「在庫確認」ボタンについても同様に自己修復されていました。
4.Healing AgentでRPAはどう変わる?
Healing Agentの強みや、改善が期待される点としては、以下が挙げられると考えています。
○:エラー発生時も無人実行の継続が可能
Healing Agentを無効化した状態で、無人実行時にエラーが発生した場合、エラー発生時点で処理が中断されます。そのため、再実行する場合、通常実行時と比較して業務にロスタイムが生じます。
しかし、Healing Agentを有効化した状態であれば、検証結果の通り、自己修復によって処理は継続されるため、再実行の必要はありません。よって、業務のロスタイムを最小限に抑えることができます。
○:修正案が自動で提示される
Healing Agentを無効化した状態で、実行エラーが発生した場合、エラー原因を人間が調査する必要がありました。開発者のスキルによっては原因調査に時間を要す可能性があります。また、修正方法の検討にさらに多くの時間がかかる場合も少なくありません。
しかし、Healing Agentを有効化すれば、エラー原因を自動で分析してくれます。その上でエラー原因を解消するための修正案を考え、具体的な修正方法まで提示してくれるのです。よって、Healing Agentは開発者にとって強力なサポーターとなり、開発コストの削減も期待できるでしょう。
△:「エラー解消率100%」ではない
当然ですが、すべてのエラーがHealing Agentによって解決できるわけではありません。本コラムでは、自己修復に成功した検証結果をご紹介していますが、自己修復に失敗し、実行エラーとなるケースも確認されました。想定外のポップアップ上に複数の選択ボタンが表示されており、特定のボタンをクリックした場合のみポップアップが閉じるケースが例として挙げられます。選択ボタンの種類によっては、ポップアップを閉じるためのボタンを判断できず、実行エラーとなりました。それでもなお、Healing Agentによって解決できるエラーが多数存在するため、導入する価値は十分にあると考えています。
△:追加ライセンスが必要
Healing Agentは、利用回数に応じてライセンスが消費されます。そのため、プロセスを実行する際に毎回Healing Agentを有効化するのではなく、計画的に活用することが重要です。
例えば、操作対象のシステムを改修後に、Healing Agentを有効化して初回実行を実施することで、どの処理でエラーが発生するのか事前に判断することが可能です。また、開発経験の浅い開発者にHealing Agentの利用を許可することで、開発者が自走できるようになり、サポートにかかるコストの削減が期待されます。
このように、運用目的や状況に応じて利用することで、Healing Agentの効果を最大限に引き出すことができます。
なお、回数制限はあるものの、Healing Agentを無償利用できるライセンスプランも用意されています。詳細はUiPath公式ドキュメントを参照ください(参照:https://docs.uipath.com/ja/agents/automation-cloud/latest/user-guide-ha/licensing#licensing)。
5.まとめ
本コラムでは、Healing Agentについてご紹介しました。
我々SIerのエンジニアは、セレクターの変化やシステム負荷を考慮して設計しますが、市民開発者にとっては対応が難しい場合も多いです。また、システム改修によって操作対象画面に想定外の変化が加わると、事前の設計では対応しきれない場合もあります。このような課題に対して、Healing Agentが有効であると検証を通して実感しました。
「RPAを導入しているけど安定運用の実現に課題がある」という皆さんにとって、Healing Agentが解決策の1つになれば幸いです。
さいごに
TISでは、UiPathの導入から運用後の課題解決まで、現場に寄り添ったサポートを行っています。今回ご紹介した内容以外にも、実際の現場で得られた知見が多数ございますので、ご関心があればぜひご相談ください。
執筆者:中山 瑞穂
※本コラムはTISエンジニアの実体験・知見に基づく内容を記載していますが、記載された情報や手順が全ての環境で同様に動作することを保証するものではありません。万が一、本コラム内容を参考にしたことによる損害等が生じた場合、当社は責任を負いかねますのでご了承ください。また、記載されている情報はコラム公開時点のものであり、予告なく変更される場合があります。