2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIエージェントはテスト業務をどこまで任せられる?UiPath Delegate for Testingを試してみた

2
Last updated at Posted at 2026-10-25

はじめに

AIチャットへ質問すると、回答や文章を返してくれる。
RPAを実行すると、あらかじめ定義した手順でシステムを操作してくれる。

では、デスクトップ上で仕事をするAIエージェントへ依頼すると、どこまで進められるのでしょうか。

UiPath Delegateは、自然言語による仕事の依頼を理解し、必要な手順とツールを自ら計画して、複数のアプリケーションを操作しながら仕事を進めます。Computer Useによって、デスクトップ上のアプリケーションを画面から操作することもできます。

今回は、テスト業務に特化したDelegate for Testingを使い、その実力を試しました。

注記
本記事は、2026年10月時点でPublic Previewとして提供されているUiPath Delegateを使用した検証に基づいています。Public Preview期間中のため、正式リリースまでに画面、名称、機能、利用条件などが変更される可能性があります。

Delegate for Testingとは

Delegate for Testingは、Delegateとは別のエージェント製品ではありません。汎用のDelegateを基盤として、QA・テスト担当者向けに構成されたエクスペリエンスです。

QA/Testingプロファイルでは、Test Cloudプラグインを通じて提供されるテスト用Skillを利用できます。

<Delegateの機能構成>

Delegateの機能構成

Delegateは、プロンプト、音声、画面録画、添付ファイルなどから、仕事の依頼とコンテキストを受け取ります。その内容をもとに、必要な手順とツールを計画して実行します。

実行中は、必要に応じて人が作業を中断し、指示の修正や方向転換を行えます。

対象システムに応じて、Computer Useによる画面操作だけでなく、API、MCPサーバー、Integration Serviceコネクタ、既存のUiPath資産などを使い分けます。

Delegate for TestingのTest Cloudプラグインは、uip CLIを通じてTest Managerと連携します。

今回のユースケースでは、次の手段を使用しました。

  • 宿泊予約システムの再テスト:Computer Use
  • Test Managerとの連携:uip tm CLI
  • Slackへの通知:Integration Serviceコネクタ

なお、不具合登録の指示では、Test Managerの操作方法をAPIまたはuip tm CLIに限定しています。これは今回の仕事で指定した条件であり、Delegate for Testingの公式な連携方式を説明するものではありません。

これらの処理は、ユーザーの企業IDとアクセス権限、組織ポリシー、承認設定など、UiPath組織の統制下で実行されます。

今回試したテスト業務

テスト担当者からDelegateへ委任した2つのユースケースと、それぞれのタスクで使用したツールを図にまとめました。

<Delegate for Testingで進めるテスト業務のユースケース>
image.png

ここからは、2つのユースケースを順番に紹介します。

ユースケース1:失敗したテストから不具合を登録する

最初のユースケースでは、失敗したテストへの対応をDelegateへ委任しました。

DelegateはTest Managerから失敗したテスト結果を取得し、用意したガイドラインに基づいて重要度と担当者候補を判断しました。

その結果をExcelの不具合一覧へ登録し、Slackを通じて関係者へ通知しました。

重要度と担当者候補の判断は、Delegate for Testingにあらかじめ組み込まれた固定機能ではありません。今回は、用意したガイドラインを仕事のコンテキストとして参照させました。

Delegateへ渡した情報と判断基準

Delegateへは、不具合の登録先となるExcelに加えて、次のガイドラインを渡しました。

  • 重要度と優先度を判断するためのガイドライン
  • 不具合内容から担当者候補を選定するためのガイドライン

<不具合を登録する前のExcel一覧>

不具合を登録する前のExcel一覧

<重要度と優先度を判断するためのガイドライン>

重要度と優先度を判断するためのガイドライン

<不具合内容から担当者候補を選定するためのガイドライン>

不具合内容から担当者候補を選定するためのガイドライン

重要度や担当者候補をDelegateへ自由に推測させるのではなく、人が用意した基準を仕事のコンテキストとして参照させました。

不具合対応をDelegateへ依頼する

用意したExcelとガイドラインを渡し、不具合対応をDelegateへ依頼しました。

依頼には、主に次の条件を含めました。

  • 過去7日間に完了した失敗結果を取得する
  • Test Managerの操作にはAPIまたはuip tm CLIを使用する
  • 同じ実行結果を重複登録しない
  • 既存の不具合と今回取得した候補から類似不具合を判定する
  • ガイドラインに基づいて重要度と担当者候補を判断する
  • 指定した項目をExcelの不具合一覧へ登録する
  • 新規登録した不具合ごとに、Slackへ1件ずつ通知する
Delegateへ渡した指示の全文

Test Managerのプロジェクト「ホテル予約システム」について、実行時点のタイムゾーンで過去7日間に完了した失敗テストケース実行結果を、UiPath Test Manager API/uip tm CLIだけで取得してください。

実行時のユーザー名と、実行時に指定するローカルExcelファイルを使用してください。

未指定の場合は、現在のユーザーのDownloads配下にある「ホテル予約システムテスト管理¥バグ管理一覧.xlsx」を使用します。

番号:シーケンシャル番号
題名:テストケース名
概要:失敗ステップの不具合内容。実測結果と期待結果の差分を具体的に記載
実行ログへのリンク:APIで取得した実行IDとテストケースIDから生成したハイパーリンク。表示文字列は「リンクをクリック」
ステータス:新規
起票日・更新日:実行時点のローカル日付
起票者:実行時のTest Managerユーザー名
重要度・担当者:Excel内の「重要度ガイドライン」「対応担当者ガイド」に従う
コメント:重要度・担当者の判断根拠、失敗内容、類似バグ情報

同じ実行IDのリンクが既にある場合は、重複登録・既存行の更新をしないでください。

類似バグは、既存バグだけでなく、同じ処理回で取得した他の新規候補とも比較してください。

題名、概要、機能・画面、症状、実測結果と期待結果の差分が類似するものを類似バグとします。

候補自身は除外し、類似候補が複数ある場合は起票日が最も古いもの、同日なら番号が小さいものを選び、コメント末尾に「類似バグ:番号N」と記載してください。

類似がない場合だけ「類似バグ:なし」と記載してください。

登録前に重複判定・採番・類似判定をすべて確定し、登録後に内容、ハイパーリンク、重複なし、類似バグ番号、数式エラーを確認して保存してください。

対象がない場合はExcelを変更せず、件数だけ報告してください。

Excelへの登録・保存・検証がすべて成功した場合のみ、新規登録した不具合1件につき1件のSlackメッセージを、接続済みのUiPath Integration Service Slackコネクタ経由で、公開チャンネル「#バグ登録通知」へ投稿してください。

Slack MCPやUI操作は使用しないでください。

本文には、番号、題名、概要、重要度、ステータス、起票日、起票者、担当者、類似バグ番号、実行結果リンクを含めてください。リンクは「<URL|リンクをクリック>」形式とし、URLを表示文字列にしないでください。

複数件は個別投稿してください。

重複除外、新規登録0件、Excel登録失敗時は投稿しないでください。投稿成功をAPI応答で確認し、通信エラーなどで成否不明の場合は、履歴を確認してから再送してください。

Excel登録済みの内容は取り消したり再登録したりせず、失敗または成否不明の場合は対象番号とエラー内容を報告してください。

Excelへ登録された不具合

Delegateは、取得した失敗結果を不具合情報として整理し、Excelの不具合一覧へ登録しました。

不具合内容に加えて、ガイドラインを参照して判断された重要度と担当者候補、判断理由、類似不具合の情報も記録されています。

<DelegateによってExcelへ登録された不具合情報>

DelegateによってExcelへ登録された不具合情報

Slackへ送信された通知

Excelへの登録と検証が成功した不具合について、DelegateはIntegration ServiceのSlackコネクタを使用し、関係者へ通知しました。

<Slackへ送信された不具合通知>

Slackへ送信された不具合通知

不具合一覧への登録だけでなく、対応が必要な関係者への通知まで委任できました。

成功した仕事をRoutineとして再利用する

正常に完了した仕事は、Routineとして保存できます。

<正常に完了した仕事をRoutineとして登録>

image.png

保存したRoutineは一覧から確認し、必要なときに再実行できます。

<登録済みのRoutine一覧>

登録済みのRoutine一覧

Routineの価値は、単にプロンプトを保存することではありません。
一度成功した仕事の進め方を、再実行可能な形で利用できる点にあります。

保存したRoutineを使えば、同じ種類の仕事を再びDelegateへ委任できます。手動での再実行に加えて、指定日時や一定間隔でのスケジュール実行にも利用できます。

動画で実演

ユースケース2:修正済みの不具合を再テストする

2つ目のユースケースでは、修正済みの不具合に対する再テストをDelegateへ委任しました。

Delegateは、Excelの不具合一覧からステータスが「解決」になっている不具合を特定し、宿泊予約システムを再テストしました。

その結果をTest Managerへ反映し、Excelの不具合ステータスも更新しました。

再テストの対象を特定する

DelegateはExcelの不具合一覧を確認し、ステータスが「解決」になっている不具合から再テストの対象を特定しました。

<再テスト対象となる修正済み(解決)の不具合>

image.png

再テストをDelegateへ依頼する

再テストの対象、合否に応じたステータスの更新ルール、Test Managerからテストケースを検索する手段などを指定し、Delegateへ依頼しました。

バグ一覧のステータスで解決になっているバグのテストを再実行して、合格の場合はステータスを終了、不合格の場合はフィードバックに更新します。
更新日は実行した年月日で更新してください。バグ一覧のExcelファイルは、現在のユーザーのDownloads配下にある「ホテル予約システムテスト管理¥バグ管理一覧.xlsx」を使用します。
再実行するテストケースは、バグ一覧の題名からTest Managerのプロジェクト「ホテル予約システム」に格納されているテストケース名をUiPath Test Manager API/uip tm CLIだけで検索してください。
オートメーションが登録されていない場合は、手動ステップの手順でテストし、結果のログをアップロードしてください。

依頼を受けたDelegateは、不具合一覧に記録された題名を手がかりに、Test Managerから対応するテストケースを探しました。

今回はオートメーションが登録されていなかったため、テストケースに定義された手動ステップを確認し、その手順をもとに再テストを進めます。

Computer Useで再テストする

DelegateはComputer Useを使い、テスト自動化の学習用の練習サイト 宿泊予約システムを実際に操作しながら、手動ステップに沿って再テストを実行しました。

<不具合内容に対応する条件を入力した再テスト>

不具合内容に対応する条件を入力した再テスト

再テスト結果をTest Managerへ反映する

再テストが完了すると、Delegateはその結果をTest Managerへ反映しました。

<Test Managerへ反映された再テスト結果>

Test Managerへ反映された再テスト結果

不具合ステータスを更新する

Test Managerへの結果反映後、Delegateは再テストの合否に応じてExcelの不具合ステータスを更新しました。
依頼では、再テストに合格した場合は「終了」、不合格の場合は「フィードバック」へ更新するよう指定しました。
今回は再テストに合格したため、Excelの不具合ステータスが「終了」に更新されました。

<再テスト結果に基づいて更新された不具合ステータス>

image.png

これにより、Test Managerの再テスト結果と、Excelで管理している不具合の状態が一致しました。

動画で実演

実際に試して分かったこと

1.クラウドとローカルをまたぐ仕事も委任できる

クラウド上のTest Managerとクラウド型のチケット管理システムは、対応するAPIやコネクタが利用できれば連携できます。

一方、チケット管理システムがオンプレミス環境にあり、クラウドサービスから直接接続できないこともあります。

Delegateは、クラウドサービスだけでなく、デスクトップ上のアプリケーションやローカルファイルも操作できます。

そのため、クラウドとローカルのリソースをまたぐ仕事も、1つの仕事として委任できることが分かりました。

今回は、その分かりやすい例として、クラウド上のTest Managerから取得した情報をローカルのExcelへ登録しました。

接続先がすべてクラウド上になくても、Delegateを介してクラウドとローカルをつなぎ、一連の仕事として進められることが分かり、こうした環境でも活用できる可能性を感じました。

2.使用する手段は指示した方がよい

Delegateがシステムを操作する手段は、Computer Useだけではありません。API、CLI、Integration Serviceコネクタ、MCPなど、複数の選択肢があります。

今回試した範囲では、利用できる手段が複数ある場合、必ずしも想定した方法が選択されるとは限りませんでした。

Integration ServiceのSlackコネクタを設定していても、SlackへのMCP接続やUI操作が試みられました。
そのため、最終的な指示には次の条件を明記しました。

  • Test Managerの操作にはAPIまたはuip tm CLIを使用する
  • Slackへの通知にはIntegration Serviceコネクタを使用する
  • Slack MCPやUI操作は使用しない

複数の操作手段が利用できる場合は、すべてをDelegateの選択に任せるのではなく、優先する手段と使用させたくない手段をあらかじめ指定した方がよいことが分かりました。

これにより、不要な画面操作や接続の試行を抑え、想定した方法で仕事を進めやすくなります。

3.処理の実装を意識せず、どうしてほしいか指示できる

今回委任した仕事には、単純な転記だけでなく、次のような条件も含めました。

  • 取得したURLからハイパーリンクを作成し、Excelへ設定する
  • 同じ実行結果が登録済みの場合は、重複登録しない

これらを従来のRPAで実現する場合、条件分岐、検索、比較、例外処理などをワークフローとして組み立てる必要があります。

Delegateでは、必要な条件や完了状態を自然言語で具体的に伝えることで、一連の仕事として委任できました。

もちろん、短く曖昧な指示だけで、常に期待どおりの結果が得られるという意味ではありません。重複の判定条件、失敗時の扱い、通知の実行条件などは具体的に伝える必要があります。

それでも、処理を一つずつ実装するのではなく、仕事のルールとして条件を渡せる点は、従来のワークフロー開発との大きな違いです。

4.仕事の中にAIによる判断を組み込める

Delegateは、指示された操作を順番に実行するだけではありません。

今回のユースケースでは、不具合の内容とガイドラインを照合し、重要度と担当者候補を判断しました。既存の不具合や同じ処理で取得した候補と比較し、類似不具合も判定しました。

重要度や担当者が固定された条件だけで決まるのであれば、ルールとしてワークフローへ実装できます。

しかし、実際の不具合対応では、エラー内容、影響範囲、対象機能など、複数の情報を読み取ったうえで判断する必要があります。

Delegateでは、人が用意した判断基準を参照させ、仕事を進める途中にAIによる判断を組み込むことができます。

これは、すべてをDelegateへ自由に判断させるという意味ではありません。今回は判断に使用するガイドラインを渡し、判断結果だけでなく、その根拠もExcelのコメントへ記録させました。

決められた手順を実行するだけでなく、取得した情報と判断基準に応じて、仕事の中で判断しながら柔軟に進められることが、今回Delegateを試して特に印象に残った点です。

AIチャット、従来のRPA、Delegateの違い

今回の結果をもとに、AIチャット、従来のRPA、Delegateの仕事の進め方を整理すると、次のようになります。

これは各製品の厳密な仕様比較ではなく、今回のユースケースにおける役割の違いを示したものです。

観点 AIチャット 従来のRPA Delegate
主な入力 質問、文章作成の依頼 実行指示、トリガー、業務データ 自然言語による仕事の依頼、関連資料
仕事の進め方 対話に対して回答する あらかじめ定義した手順を実行する 依頼を理解し、必要な手順とツールを計画して実行する
判断 回答の中で行う 条件やルールを処理内に実装する 依頼内容、コンテキスト、取得した情報を参照する
主な成果 回答や生成物 ワークフローの実行結果 システム上に反映された業務結果
再利用 会話やプロンプト ワークフロー Routine

Delegateが従来のRPAを置き換えるわけではありません。

手順が明確で、同じ処理を大量かつ安定的に実行する仕事には、事前に設計されたオートメーションが適しています。

一方、自然言語による依頼を起点に、状況に応じて必要な手順やツールを選びながら進める業務は、Delegateの活用候補になります。

おわりに

今回試して感じたのは、Delegateを使う主役は、自動化を開発する人ではなく、仕事を任せたいエンドユーザーだということです。

仕事を委任するエンドユーザーに求められるのは、プログラムを組む知識ではありません。

どのような仕事を、どのような条件や判断基準に従って、どの状態まで進めてほしいのかを伝えること

です。

もちろん、曖昧な指示だけで意図したとおりに進むわけではありません。今回も、参照するガイドライン、使用するツール、重複時の扱い、完了条件などを具体的に伝えました。

それでも、必要なのは処理手順を一つずつ実装することではありません。自身の業務を理解し、その仕事をDelegateへ委任するための指示です。

Delegateの幅広い作業能力を前提にすると、

「AIで何ができるのか」
「AIを何に活用できるのか」

と、AIを起点にユースケースを探すアプローチは、すでに変わり始めているのかもしれません。

特別なAI活用のテーマを探さなくても、自分が日々行っている業務そのものが、委任を検討する対象になるからです。

AIに何をさせるかではなく、自分のどの仕事を任せるか。

Delegateは、これまでの自動化とは異なる視点で、仕事の進め方を考えさせるAIエージェントでした。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?