UiPathと言えば、まず頭に浮かぶのは画面操作の自動化ですよね。
しかし、操作対象のシステムの画面が変更されると、本来動くはずのロボットが突然止まってしまうことはありませんか？
おそらく、一度は経験したことがあるでしょう。

このような場合、多くの人はワークフローを修正し、再パブリッシュする必要があります。
でも、もしロボットが自動で修正し、そのまま継続して動作できたらどうでしょうか？

そこで登場するのが、UiPath Healing Agentです。

本記事は、以下のページを参考に作成しています。
ぜひ、UiPath Healing Agent Community Public Previewの本文もチェックしてみてください。

1. UiPath Healing Agentの基本機能と役割

UiPath Healing Agentは、AIを活用して、UiPath Robots、Orchestrator、Studioに、画面の変更や予期せぬポップアップに対応し、ロボットが自動で自己修復する仕組みを提供します。
従来のRPAでは対処しきれなかった 環境変化への耐性を強化することで、運用負担を大幅に軽減できます。

では、このHealing Agentがどのように機能し、どんな役割を果たすのか？

UIベースの自動化に対するインテリジェントな自己修復：
- アプリケーションのインターフェース変更やUI干渉が発生しても、Healing Agentが問題を修復し、自動化を中断せずに継続できます。
アクション可能な推奨事項：
- アプリケーションインターフェースを AIが分析し、トラブルシューティングやデバッグの時間を最小化するためのターゲットを絞った推奨事項を提供します。これにより、迅速に問題を解決し、自動化をすぐに本番稼働へ戻すことが可能です。

2. 利用にあたっての前提条件と設定

Healing Agent を利用するためには、以下の 前提条件 と設定が必要です。

前提条件

Orchestratorはクラウド環境でのみサポートされており、オンプレミス環境では利用できない点に注意が必要です。

🔍 前提条件	📌 説明
Orchestrator	UiPath Cloud のみ対応。オンプレミス構成は現在利用不可。
Studio	✅ 最新の Community バージョン（UiPath公式サイトからダウンロード可能） ✅ Enterprise バージョンの 2025.0.157 以降
Robot	バージョン 25.2 以降
UIAutomation パッケージ	バージョン 25.2-preview 以降
プロジェクトタイプ	Windows と Cross-platformプロジェクト対応

有効化の設定方法

上記の前提条件を満たすと、Healing Agentを有効化し、自己修復を実施するかを選択できます。
既にパブリッシュ済みのワークフローにHealing Agentを有効化する場合は、Orchestrator側で設定できます。
さらに、UiPath Studioを利用してテスト実行時にも自己修復を行いたい場合は、Studio側でも設定が可能です。

Orchestrator側で設定する方法

Orchestratorでは、プロセスレベル と ジョブレベル の設定が可能です。
プロセスレベルの設定は、次の手順で行います。

フォルダーを選択します。
[オートメーション] → [プロセス]に進み、プロセスの追加または編集を選択します。
表示される画面で、Healing Agentに関するオプションをチェックして設定を行います。

Healing Agentの自己修復を有効化チェックボックスについて
[Healing Agent の自己修復を有効化] がチェックされていない場合、Healing Agent は自己修復を実行しません。
この場合、詳細なデバッグ情報は提供されますが、推奨事項は限定的になります。

ジョブレベルで設定を行うと、プロセスレベルの設定よりも優先されます。
ジョブレベルの有効化方法はプロセスレベルの設定方法と同じため、ここでは詳細を省略します。

Studio側での設定方法

UiPath Studio を利用してテスト実行時にも自己修復を行いたい場合は、Studio 側で設定できます。

設定手順

プロジェクト設定の歯車アイコンをクリック
[UI Automation モダン] 画面の一番下に移動
[試験段階] の [回復を有効化] を設定し、[OK]をクリック。

試験段階の設定項目が見つからない場合：
前提条件で記載した UIAutomation パッケージが 25.2-preview 以降かを確認してください。

確認手順：

パッケージ管理で確認
25.2-preview 以降の UiPath.UIAutomation.Activities がない場合、[プレリリースを含む] をチェック

実行時エラーが発生した際にユーザーへ確認を行う場合は、以下のオプションも [True] に設定してください。（デフォルト設定：True）

設定に関する補足説明

Studio での Healing Agent 設定と OC 側での Healing Agent 設定は、必ず両方を設定する必要はありません。
以下のテーブルを参照し、適切な設定を行ってください。

3. Healing Agentによる自己修復の動作確認

例えば、以下のような登録システムの自動化を行いました。
しかし、その後ボタンの名前が [確定] から [確認] へ変更され、関連属性も変更されました。

変更前後のシステム画面：

セレクターの属性(変更前):

<webctrltag='BUTTON'type='button'class='styled'aaname='確定'/>

セレクターの属性(変更後):

<webctrltag='BUTTON'type='button'class='styled1'aaname='確認'/>

従来の動作では、以下のエラーが発生し、ロボットの実行が停止してしまいます。

Healing Agent を有効化すると、有人オートメーション実行と無人オートメーション実行のそれぞれのケースでどのように動作するのかを確認してみましょう。

有人オートメーションの場合

Studio 側の設定で、[回復を有効化]および[実行時エラー発生時にユーザーに確認]の両方を[True]にすると、Studio や Assistant から有人実行として起動した場合、要素が見つからない際に確認ダイアログが表示されます。

(上記がStudio Desktop から起動した場合)

「続行」をクリックすると、[確認]ボタンが押され、正常に実行されます。

Assistant から起動した場合は、左下に「例外を報告」というチェックボックスが追加されます。
これをチェックをすると、例外のデータが収集され、トラブルシューティングのために送信されます。

Assistantから実行する場合も、Orchestrator側でジョブの履歴を確認できます。
該当ジョブの右端にある詳細アイコンをクリックし、UiPath Healing Agentのタブを開くと、
自己修復が行われた際の画面や修正の推奨事項を確認できます。

上記のタブには、エラーの特定や修正に役立つ情報が含まれています。

オートメーションを修正するためのデバッグファイルのダウンロード
エラー発生時のスクリーンショット
エラー解消のための提案

このように、有人オートメーション実行時には、エラーの詳細を確認し、適切な対応を行うことが可能です。

無人オートメーションの場合

Orchestrator側で [Healing Agent] と [自己修復を有効化] の両方をチェックすると、
無人実行時にはユーザー確認の画面が表示されず、自動的に自己修復が行われ、正常に実行されます。

自己修復による回復が行われたことは、Orchestrator側のログで確認できます。

また、Orchestratorの UiPath Healing Agent タブには、有人オートメーション実行時と同じ内容が表示されるため、詳細説明は省略します。

4. UiPath Healing Agentが役立つユースケースとは？

前述のように、予期せぬ UI の変更や一時的なエラーが発生する環境では、Healing Agent がその効果を最大限に発揮します。
これにより、自動化プロセスの中断を最小限に抑え、運用の効率化が期待できます。

では、具体的にどのようなケースで役立つのでしょうか？
次に、Healing Agent が活躍するユースケースについて詳しく見ていきましょう。

セレクターの属性の変化

📌 課題
アプリケーションのバージョンアップにより、ユーザーインターフェース（UI）が頻繁に変更される自動化プロセスでは、セレクターの変更が発生することがあります。
このような変更は、セレクターの属性の変化を引き起こし、自動化の失敗や手動での修正作業を必要とする原因となります。

✅ Healing Agentによる解決策

セレクターの変更を自動検知
新しいセレクターを動的に生成
検証を行い、アクティビティを再実行

📝 事例
前述のHealing Agentによる自己修復の動作確認では、ボタンが[確定]から[確認]への変更及びセレクターの属性の変更がありましたが、Healing Agentによって自動的に回復できました。

レスポンシブデザインのWeb 画面の構造変化

📌 課題
UIレイアウトは、レスポンシブデザインによって変化することがあり、画面サイズや解像度によって要素の位置が移動することがあります。

従来の自動化では、アンカー（自動化の基準となる参照ポイント）が期待した位置にない場合、処理が失敗する可能性があります。

✅ Healing Agentによる解決策

アンカーの位置がターゲットに対して変化しても認識可能
リアルタイムで自動化を適応
レイアウト変更があっても、自動化タスクを正確に実行

📝 事例
例えば、オブジェクトを認識した時の画面：

実行時の画面（レスポンシブデザインのWeb画面のため、画面の大きさによって画面構造が変化する）

自己修復が動作した際に、Orchestrator側のHealing Agentで、自己修復が行われた際の画面や修正の推奨事項を確認できます。

上記の提案を基に、入力やクリックアクティビティのプロパティで[レスポンシブ対応のWebサイト]をチェックできることが分かります。

UI要素を妨げるポップアップの出現

📌 課題
自動化プロセスの実行中にポップアップウィンドウが表示され、ターゲットのUI要素を妨げることがあります。

これは、通知・エラーメッセージ・モーダルウィンドウなどが表示される一般的なケースであり、これらの予期しないポップアップは自動化の失敗を引き起こし、手動での対応が必要になることがあります。

✅ Healing Agentによる解決策

検証を行い、アクティビティを再実行
ポップアップウィンドウを自動で閉じる
ポップアップによって遮られたターゲット要素を検知

📝 事例

納品書登録システムの自動化ワークフローがあります。
しかし、バージョンアップの計画があり、次のようなお知らせのポップアップが表示されました。

今までのワークフローであれば、以下のようなエラーが出て、自動化の実行が失敗してしまいます。

Healing Agentを有効化すると、該当のポップアップが自動的に閉じられ、ワークフローも正常に実行されました。

自己修復が動作した際に、Orchestrator側のHealing Agentで、自己修復が行われた際の画面や修正の推奨事項を確認できます。

特に最後には、的確な提案内容とターゲットまで提示されました。これにより、ワークフローの修正に大変役立つ情報が得られます。

補足：すべてのポップアップに対応できるわけではなく、ポップアップの作り方によって対処できないケースもあります。

ネットワーク遅延で指定画面出現のタイムアウト

📌 課題
自動化処理が、ターゲットのアプリケーションや要素が完全に読み込まれる前にアクションを実行しようとすることで、失敗することがあります。

これは、システムのパフォーマンスやネットワーク遅延によってアプリケーションの読み込みが遅くなる場合に発生し、自動化が必要な要素をタイミングよく認識できず、エラーや中断が発生する原因となります。

✅ Healing Agentによる解決策

ターゲット要素が準備完了したタイミングを検知
必要な時間だけ適切に待機
検証を行い、アクティビティを再実行

📝 事例

対向システムのページは、通常30秒以内に開くため、ワークフローのタイムアウト時間がデフォルトの30秒に設定しています。しかし、ネットワークの遅延で30秒以上になるケースがあります。

今までのワークフローであれば、実行中にエラーが出て、失敗してしまいます。
Healing Agentを有効化すると、必要な時間適切に待機し、ワークフローも正常に実行されました。

自己修復が動作した際に、Orchestrator側のHealing Agentで、自己修復が行われた際の画面や修正の推奨事項を確認できます。

最後の提案には、ターゲットアクティビティのタイムアウト値を60秒に増やすことが提示されました。

補足：すべてのタイムアウトの問題が自己修復されるわけではありません。タイミングや画面などによっては、タイムアウトの延長が必要と判断されない場合があり、その結果、セレクターが見つからないエラーが発生することがありました。

UI要素表記の変更

📌 課題

対象のアプリケーション要素が更新されても、本来の目的は維持されている場合があります。例えば、「Submit」（送信）ボタンが「Confirm」（確認）に名称変更されたり、レイアウト内でフィールドが移動しても、本来の機能はそのまま残るようなケースです。

このような変更は、静的な要素定義に依存する従来の自動化を壊してしまうことがよくあります。

✅ Healing Agentによる解決策

要素の名称変更がその本来の意味や機能に影響しないことを識別
変更された UI に合わせて自動化を更新
アクティビティを検証し、再実行

📝 事例

以下のように画面上のボタンの表記(LoginからLog Onへ)が変更されました。

今までのワークフローであれば、以下のように実行中にエラーが出て、失敗してしまいます。

Healing Agentを有効化すると、代わりに[Log On]をクリックし、ワークフローも正常に実行されました。

自己修復が動作した際に、有人実行の場合では以下のようなダイアログが表示されます。

無人実行する場合は、Orchestrator側のHealing Agentで、自己修復が行われた際の画面や修正の推奨事項を確認できます。

特に最後には、推奨ターゲットまで提示されました。これにより、ワークフローの修正に大変役立つ情報が得られます。

5. 既知制限とよくある質問

UiPath Healing Agent は、さまざまなケースに適用できますが、利用するには対応範囲や使用条件を理解しておくことが重要です。以下に、その詳細をよくある質問と既知制限でまとめました。

💡UiPath Healing Agentに関するよくある質問（FAQ）

❓ 質問	✅ 回答
対応しているプロジェクトの種類は？	Windows およびクロスプラットフォームのプロジェクトタイプをサポートしています。
既存プロジェクトと新規プロジェクト、どちらでも使えますか？	いくつかの自己回復は既存のプロジェクトにも適用できますが、新規プロジェクト向けに設計されたものもあります。 ⚠️ 注意: - `UIAutomation.Activities` パッケージは 25.2-preview 以上である必要があります。 - `Robot` のバージョンは 25.2以上でなければなりません。
UIAutomationのModernとClassic、どちらのアクティビティに対応していますか？	✅ Modern UIAutomation activities のみサポートされています。 ❌ Classic activities には対応していません。
対応しているアプリケーションや環境は？	✅ デスクトップアプリおよび Webアプリの両方をサポートしています。 🔹 また、リモート環境（例：Citrix）で動作するオートメーションの回復も可能です。

⚠️ UiPath Healing Agent の制限事項（Limitations）

❌ 制限事項	🔍 詳細
対応プロジェクトの制限	✅ Windows および Crossplatformプロジェクトのみサポート ❌ Legacy プロジェクトには対応していません。
ポップアップ/ダイアログの処理	Healing Agent がポップアップやダイアログを閉じることができるのは、 UIAutomation activities が VerifyExecution 機能を使用している場合のみです。それ以外では、ポップアップが意図したものか判断できません。
Computer Vision のターゲット	Computer Vision のみを使用したターゲットは、現在のところ回復できません。
Classic UIAutomation activities の非対応	Classic UIAutomation activities はサポートされていません。
RDP, Citrix, VMware 環境での制限	RDP, Citrix, VMware を介して実行されるアプリでは、Healing Agent はダイアログや干渉する外部アプリを検出できません。
Server-less Robots での制限	サーバーレスロボットで実行されるオートメーションでは、Healing Agent はアラートやプロンプトを検出できません。

💡 注意: 上記の制限を考慮し、対応する環境や機能を適切に設定することで、UiPath Healing Agent を効果的に活用できます！

6. 最後に

本記事では、UiPath Healing Agent の基本機能、設定方法、動作検証、そして実際のユースケースについて解説しました。

Healing Agent を活用することで、予期せぬ UI の変更やエラーによる自動化の中断を最小限に抑え、運用負担を軽減できる ことがわかりました。特に、自己修復機能を有効活用することで、有人・無人オートメーションのどちらにおいても、ロボットの安定した実行を維持することが可能 です。

ただし、すべてのケースで完全な自己修復が行えるわけではなく、環境や構成による制限がある ため、適用範囲を理解した上で導入することが重要です。

今後、UiPath Healing Agent のさらなる機能強化や対応範囲の拡大が期待されます。本記事が、導入を検討している方や、より安定した自動化を目指している方の参考になれば幸いです。