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

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

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

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では、プロセスレベル と ジョブレベル の設定が可能です。
プロセスレベルの設定は、次の手順で行います。

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

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

Studio側での設定方法

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

設定手順

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

実行時エラーが発生した際に ユーザーへ確認を行う 場合は、以下のオプションも [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から実行する場合も、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 のさらなる機能強化や対応範囲の拡大が期待されます。本記事が、導入を検討している方や、より安定した自動化を目指している方の参考になれば幸いです。