UiPath AIエージェント活用ガイド ~ Healing Agentの魅力とは？

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

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

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

:::note info
本記事は、以下のページを参考に作成しています。
ぜひ、[UiPath Healing Agent Community Public Preview](https://forum.uipath.com/t/uipath-healing-agent-community-public-preview/785139)の本文もチェックしてみてください。
:::

# 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](https://cloud.uipath.com) のみ対応。オンプレミス構成は**現在利用不可**。 |
| **Studio・Robot**             | ✅ 最新の Community バージョン（[UiPath公式サイト](https://www.uipath.com) からダウンロード可能）<br> ✅ Enterprise バージョンの 2025.0.157 以降 |
| **UIAutomation パッケージ** | バージョン 25.2-preview 以降 |
| **プロジェクトタイプ** | Windows  と Cross-platformプロジェクト 対応|

:::note info
本記事では、以下のバージョンを利用しています。
- **Studio・Robot**：2025.0.161
- **UIAutomation パッケージ**：25.2.1-preview
:::


## 有効化の設定方法

上記の前提条件を満たすと、Healing Agentを有効化し、自己修復を実施するかを選択できます。
- **プロセスまたはジョブレベル**でHealing Agentを有効化する場合は、Orchestrator側でプロセスやジョブを作成する際に、[Healing Agentを有効化]関連の実行オプション から設定します。
- **個別のアクティビティレベル**でHealing Agentを有効化する場合は、UiPath Studioで対象のアクティビティのオプション [Healing Agentモード] から設定します。


### Orchestrator側で設定する方法

Orchestratorでは、**プロセスレベル** と **ジョブレベル** の設定が可能です。  
プロセスレベルの設定は、次の手順で行います。  
1. フォルダーを選択します。  
2. [オートメーション] → [プロセス]に進み、プロセスの追加または編集を選択します。  
3. 表示される画面で、Healing Agentに関するオプションをチェックして設定を行います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/98c4ed52-23c3-40ad-b227-3343d47b53c0.png)

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

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

### Studio側での設定方法

**個別のアクティビティレベル**でHealing Agentを有効化する場合は、UiPath Studioで対象のアクティビティのオプション [Healing Agentモード] から設定します。

以下は、「確定」ボタンのクリック動作に対してHealing Agentモードを設定する画面です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/5ac2cad9-e0d1-423d-9a7a-27b746db4b8a.png)

:::note info
**[Healing Agentモード] が見つからない場合：**
前提条件で記載した UIAutomation パッケージが 25.2-preview 以降か を確認してください。

**確認手順：**
- パッケージ管理 で確認
- 25.2-preview 以降の UiPath.UIAutomation.Activities がない場合、[プレリリースを含む] をチェック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/8b874f09-deeb-4b65-8d67-aa6c7f29676a.png)

:::

実行時エラーが発生した際に ユーザーへ確認を行う 場合は、以下のオプションも [True] に設定してください。（デフォルト設定：False）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/2e9d60b4-ad0b-4cf9-b304-b248f06aad0c.png)


## 本記事でのHealingAgent関連設定

本記事では、OrchestratorやStudioにおいて、以下の設定を行っています。

- Orchestratorでのプロセス設定: 
    - Healing Agentを有効化：✅
    - Healing Agentの自己修復を有効化：✅
- Studioでの設定：
    - プロジェクト設定での[実行時エラー発生時にユーザーに確認]：`True`
    - アクティビティのプロパティ[Healing Agentモード]：`ジョブの設定を継承(NHealingAgentBehavior.Job)`

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

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

- 変更前後のシステム画面：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/8e50d3e9-c01e-43b2-bd87-d11f72b0aa36.png)
- セレクターの属性(変更前):
    ```vb
    <webctrltag='BUTTON'type='button'class='styled'aaname='確定'/>
    ```
- セレクターの属性(変更後):
    ```vb
    <webctrltag='BUTTON'type='button'class='styled1'aaname='確認'/>
    ```

従来の動作では、以下のエラーが発生し、ロボットの実行が停止してしまいます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/5acc389a-64eb-4f54-bdf5-e9e801a5cffa.png)

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

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

Orchestrator側から、無人オートメーションとしてジョブを開始する場合は、**ユーザー確認の画面が表示されず**、自動的に自己修復が行われ、正常に実行されます。

自己修復による回復が行われたことは、Orchestrator側のログで確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/3ad40822-a968-4a58-875e-086611656d6a.png)

UiPath Healing Agentのタブを開くと、自己修復が行われた際の画面や修正の推奨事項を確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/dadd416d-1319-4a6a-8f2a-554808d27048.png)

上記のタブには、エラーの特定や修正に役立つ情報が含まれています。
- オートメーションを修正するためのデバッグファイルのダウンロード
- エラー発生時のスクリーンショット
- エラー解消のための提案

このように、エラーの詳細を確認し、適切な対応を行うことが可能 です。

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

Assistant から 有人オートメーションとして起動した場合、**要素が見つからない際に確認ダイアログが表示されます**。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/fd8f4be7-fc80-417c-be6f-bed179a71ba1.png)

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

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

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

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

## セレクターの属性の変化

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

**✅ Healing Agentによる解決策**  
- セレクターの変更を自動検知  
- 新しいセレクターを動的に生成
- 検証を行い、アクティビティを再実行

**📝 事例**  
前述の[Healing Agentによる自己修復の動作確認](https://qiita.com/utanesuke/private/08e236872d1e0175f9a3#healing-agent%E3%81%AB%E3%82%88%E3%82%8B%E8%87%AA%E5%B7%B1%E4%BF%AE%E5%BE%A9%E3%81%AE%E5%8B%95%E4%BD%9C%E7%A2%BA%E8%AA%8D)では、ボタンが[確定]から[確認]への変更及びセレクターの属性の変更がありましたが、Healing Agentによって自動的に回復できました。

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

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

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

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

**📝 事例** 
例えば、オブジェクトを認識した時の画面：
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/897f0354-7733-479e-8074-30e34b140b7a.png" alt="" width="500">

実行時の画面（レスポンシブデザインのWeb画面のため、画面の大きさによって画面構造が変化する）
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/71c6f2ac-fee0-43ed-8937-d9887086b823.png" alt="" width="500">

自己修復が動作した際に、Orchestrator側のHealing Agentで、自己修復が行われた際の画面や修正の推奨事項を確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/72c2881a-9887-41f2-8947-9c7e0791d911.png)

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

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

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

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

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

**📝 事例** 

[納品書登録システム](https://junli-web-host.s3.ap-northeast-1.amazonaws.com/%E7%B4%8D%E5%93%81%E6%9B%B8%E7%99%BB%E9%8C%B2.html)の自動化ワークフローがあります。
しかし、バージョンアップの計画があり、次のようなお知らせのポップアップが表示されました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/37d3fa2b-3c09-4a79-b1eb-ffd5145f9614.png)

今までのワークフローであれば、以下のようなエラーが出て、自動化の実行が失敗してしまいます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/79fe51a1-b701-449c-b26b-5a2f214a9a93.png)

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

自己修復が動作した際に、Orchestrator側のHealing Agentで、自己修復が行われた際の画面や修正の推奨事項を確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/01217d85-b960-40f3-aa06-b06582e30896.png)

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


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

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

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

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

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

**📝 事例**

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

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

自己修復が動作した際に、Orchestrator側のHealing Agentで、自己修復が行われた際の画面や修正の推奨事項を確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/971d8bd2-2424-4feb-915c-4a626479b03b.png)

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

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

## UI要素表記の変更

**📌 課題**  

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

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


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

**📝 事例**

以下のように画面上のボタンの表記(LoginからLog Onへ)が変更されました。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/c8214ead-6567-4a11-a3b8-8fd0811f67d9.png" alt="" width="540" height="">

今までのワークフローであれば、以下のように実行中にエラーが出て、失敗してしまいます。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/56620223-928b-49d6-8e68-1e90459fd706.png" alt="" width="540" height="">

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


自己修復が動作した際に、有人実行の場合では以下のようなダイアログが表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/7d43c393-eca5-4d0d-b442-0168d9f085af.png)


無人実行する場合は、Orchestrator側のHealing Agentで、自己修復が行われた際の画面や修正の推奨事項を確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177240/2de71638-a31f-4977-acc3-9cc5ddd8453a.png)

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

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

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

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

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

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

| ❌ 制限事項 | 🔍 詳細 |
|---|---|
| **対応プロジェクトの制限** | ✅ Windows および Crossplatformプロジェクトのみサポート<br>❌ Legacy プロジェクト には対応していません。 |
| **ポップアップ/ダイアログの処理** | Healing Agent がポップアップやダイアログを閉じることができるのは、 UIAutomation activities が VerifyExecution 機能を使用している場合のみ です。<br>それ以外では、ポップアップが意図したものか判断できません。 |
| **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 のさらなる機能強化や対応範囲の拡大が期待されます。本記事が、導入を検討している方や、より安定した自動化を目指している方の参考になれば幸いです。