ベスト プラクティス

新規または既存の UI Automation ワークフローに ScreenPlay を導入するための推奨アプローチと、ワークフローを大規模かつ高速かつ経済的に維持するためのプラクティス。

ScreenPlay を既存の UI Automation ワークフローに統合する場合でも、新しいエージェント ドリブンなオートメーションを構築する場合でも ScreenPlay を採用する場合、およびオートメーションが大規模に実行された後も高速かつ経済的に保つ場合に推奨されるアプローチ。

オートメーションにおける ScreenPlay の所属

ScreenPlay は、大きな負担のかかる特定のポイント ( 制御されたエージェントのシナリオとも呼ばれる) で優れた性能を発揮するように設計されています。このポイントは、従来のツールが最も脆弱な、小規模で重要な自動化の領域です。ScreenPlay では、ワークフロー全体を置き換えるのではなく、最も必要とされる部分にエージェントによる実行を提供します。

• 中断の多い不安定なセレクター
• 複雑な UI 構造と動的な要素
• ポップアップ、仮想化されたリスト、埋め込みテーブル、カスタム コントロールなど、アクセスしにくい UI 要素

当然の帰結も同様に重要です。無人オートメーションでは、自分が監視していない実行を信頼する必要があり、ワークフローの決定論的な部分だけが、毎回同じように動作します。また、実行が最も速く、最も安価であるため、数千回の実行で実行可能です。

目標は、最大限の決定論的で最小限のエージェンティックなワークフローです。つまり、インターフェイスが安定していてステップが既知の場合はクラシック UI Automation を使用し、ビジネス ニーズを確実に満たす唯一の方法はエージェンティック実行である ScreenPlay です。

スタート アップ ガイド

コンテキストに応じて、次のパスを使用できます。

問題のあるオートメーションをアップグレードする

[ScreenPlay] アクティビティを使用して、現在の UI Automation にある以下のような問題のあるステップを修正できます。

• 繰り返し失敗するセレクター。
• UI が変更されるとオートメーションが動作しなくなる。
• 単純なタスク向けに記述された過度に複雑なロジック。

使用するアクションは、不安定なセレクターや長いカスタム ロジックではなく、自然言語のプロンプトを通じて定義できます。これにより、開発が簡素化されるほか、時間の経過とともにオートメーションの回復力も向上します。

オートメーションをゼロからきめ細かく構築する

UI Automation をゼロから開始する場合は、ScreenPlay を使用してきめ細かく対応しながら、全体を構築することができます。

各 [ScreenPlay] アクティビティは、スコープの適切な、プロセス内の小さなステップに対応している必要があります。自然なまとまりのある 2 つまたは 3 つのステップが最適です。

このような細かい部分に絞るアプローチには、次のような利点があります。

• 精度を最大化する。
• エージェントのフォーカスを維持する。
• 多すぎるコンテキストによるモデルの過負荷を回避する。

各ステップの複雑さに応じて、適切な AI モデルを選択し、費用対効果と機能のバランスをとることができます。

コーディング エージェントを使用して構築する

また、UiPath エージェント スキルを使用して AI コーディング エージェントでオートメーションを構築することもできます。このスキルにより、開発環境から UiPath のオートメーションを作成、実行、テスト、デプロイする方法をエージェントに教えます。カタログとインストールの手順については、「 UiPath Agent Skills リポジトリ」をご覧ください。

オーサリング スキルは RPA の生成に重点を置いているため、コーディング エージェントが生成する内容は既定で決定論的であり、これが必要なベースラインです。推奨されるアプローチは、生成されたワークフローを確認し、エージェンティックなアプローチが必要な箇所に ScreenPlay アクティビティを追加することです。

これらの追加は意図的に、そして少なくすべきです。それぞれが、動作が保証されなくなり、実行時間とトークンの消費が増加する場所になります。

スピードとコストを考慮した大規模な設計

1 日に数回実行されるオートメーションと、何千回も実行されるオートメーションは、経済性が大きく異なります。次の手法により、信頼性を損なうことなくレイテンシとトークン消費を削減できます。

エージェンティック サーフェスを小さく保つ

これは最も影響の大きい決定であり、後で調整するのではなく設計時に行われます。決定論的に表すことができるすべてのステップは、モデルの呼び出しのコストもかからず、待機時間も追加されず、実行間で変化することもできないステップです。

決定論的なベースラインが最初にあり、エージェンティック ステップは適切な場所にのみ追加されます。

各ステップに適したモデルを選択する

[ モデル ] ドロップダウンで利用可能なモデルは、高速化とパフォーマンスを同時に向上させるため、速度と品質のトレードオフは以前よりも大幅に少なくなっています。

[ScreenPlay] アクティビティごとに独自のモデル選択項目があるため、モデルをステップの難易度に合わせることができます。日常的な操作には高速な基本層のモデルを使用し、さらに推論をさらに必要とするステップには標準層のモデルを使用できます。利用可能なモデルの完全なリストについては、「 ScreenPlay」をご覧ください。

オートメーションが古いモデルを使用して構築されている場合、選択を再検討することは、利用可能な最も簡単な速度改善の 1 つです。

同じ画面上で複数のアクションをバッチ処理する

ScreenPlay のエージェンティック ハーネスでは、モデルの呼び出しごとに 1 つのアクションを実行するのではなく、同じ画面上で複数のアクションを 1 つのバッチで実行できます。モデルのラウンド トリップが少ないということは、エンドツーエンドのレイテンシが短いことを意味します。この違いは、長いフォームのようなアクション密度の高い画面で最も顕著です。

これは既定の動作ではありません。既定では、ハーネスは一度に 1 つのアクションを実行し、バッチ処理はタスク プロンプトで明示的に要求された場合にのみ行われます。ハーネスは、アクションが同じ画面を対象としている場合、これらの表示を尊重します。

たとえば、 の代わりに:

Fill in the customer details form.

次の URL を使用します。

Fill in the customer details form. Fill in all the fields visible on the screen in one go, then submit.

バッチ処理は、現在表示されている画面で実行できるアクションにのみ適用されます。ナビゲーション、ページ遷移、またはアプリケーションの変更が必要なステップは、モデルが次に何をするかを決定する前に新しい画面を観察する必要があるため、順番に実行されます。

最適化を停止すべき状況

純粋に実行時間とトークンの消費だけを最適化すると、不安定で維持にコストがかかる決定論的な実装に追い込まれる可能性があります。セレクターを多用するワークフローは、UI をわずかに変更するたびに動作しなくなるため、その有効期間を通じて、節約したトークンよりも多くのコストがかかる可能性があります。

Healing Agent はそのギャップを縮めますが、埋めることはできません。その 回復戦略 は、定義済みで限定されたセットであり、それらはすべて、すでに存在するアクティビティのターゲット要素を再識別するレベルで機能します。

• セレクターの属性が変更されました。
• タイミング。
• アンカーの位置。
• AppCard のタイトル。
• 設計時のセマンティック セレクターのフォールバック。

Healing Agent は、以下にも AI ベースの戦略を適用します。

• ターゲット要素を遮るポップアップ
• ラベルの意味的に言い換えられたラベル。
• Computer Vision

これにより、日常的な UI のドリフトの大部分はカバーされていますが、新しい確認ダイアログ、一連の画面の順序が変更される、フィールドが別のステップに移動する、別のアクションのシーケンスが必要になったフローなど、対話自体の変更を吸収することはできません。

Healing Agent を有効化しても、ワークフローを適切に設計することに代わるものではありません。また、脆弱な決定論的な実装を無期限に維持できるわけでもありません。

アプリケーション内でそのような変更が予想される部分には、ScreenPlay がより良い答えです。結果を自然言語で説明し、実行時にエージェントに対話を解決させることで、モデルの呼び出しを犠牲にして、これらのステップのメンテナンスの負担を排除できます。どのステップがその治療に値するかを判断することは、ターゲットアプリケーションの進化に合わせて再検討する価値があります。