UiPath Studio Autopilot はコーディングエージェントとして使えるのか？

UiPath

Posted at 2026-07-31

はじめに

最近、Claude CodeやCodexなどのコーディングエージェントを使って開発する機会が増えてきました。

UiPathでも、Studio AutopilotとUiPath CLI / UiPath Skillsを組み合わせることで、コーディングエージェントを使った開発に近い形で進められるようになっています。

UiPath Studio Autopilotをコーディングエージェントとして使用する方法については、以前の記事を参照してください。

今回は、UiPath Studio Autopilot と Claude Code に同じRPAワークフローを作成してもらい、成果物にどのような違いが出るのかを比較します。

単に「動くワークフローが作れるか」だけではなく、以下の点も見ます。

テストケースまで作成できるか
テスト結果を残せるか
設計書を出力できるか
後から保守しやすい構成になっているか

前提

※ 2026年7月時点の情報です。今後のStudio、Autopilot、Claude Code、UiPath CLIの更新により、結果は変わる可能性があります。

今回の前提は以下です。

UiPath Studio 26.0.197 STS（Autopilot）
Claude Code 2.1.220
モデルは、Sonnet 4.6で統一

作ってもらうワークフロー

今回作成してもらうワークフローは、かなりシンプルです。

入力ダイアログを開き、ユーザーが名前を入力する
入力された値を使って、こんにちは、○○さん とメッセージボックスを表示する
入力値が空の場合は例外をスローする

ただし、ワークフロー本体だけではなく、以下の成果物も依頼しています。

実装後はテストを行い、テストケースと結果はファイルに出力する
ワークフローの処理内容、引数、変数をまとめた設計書を出力する

実際に使ったプロンプトは以下です。

RPAワークフローを作成してください。
不明点あれば勝手に作成せず、必ず確認してください。

RPAワークフローの主な仕様は以下です。

* 入力ダイアログを開き、ユーザーが名前を入力する
* 入力された値を使って、"こんにちは、○○さん"とメッセージボックスを表示する
* 入力値が空の場合は例外をスローする

RPAワークフロー作成以外の要求は以下です。

* 実装後はテストを行い、テストケースと結果はファイルに出力する
* ワークフローの処理内容、引数、変数をまとめた設計書を出力する

今回の検証のポイントは、単にワークフローを作るだけではなく、テストと設計書まで要求している点です。

Studio Autopilotで作った結果

まずは、UiPath StudioのAutopilotにRPAワークフローの作成を依頼します。

Studio Autopilotでは、Main.xaml に一連の処理が作成されました。所要時間は約15分でした。

作成前には、不明な仕様について確認を求められました。

プロジェクト構成は以下の通りです（一部省略）。

project_root/
├── Main.xaml
├── project.json
└── docs/
    ├── design-doc.md
    └── test-results.md

Main.xaml の処理は、以下の流れになっています。

InputDialog で名前を入力する
String.IsNullOrEmpty(userName) で空入力を判定する
空の場合は Throw で例外をスローする
空でない場合は MessageBox で こんにちは、<名前>さん を表示する

ワークフロー本体としては、期待通りのものが作成されました。
一方で、テストについては少し物足りない結果になりました。
テスト結果 docs/test-results.md は作成されていましたが、内容は以下のようなものでした。

テスト	種別	結果
ワークフロー静的検証	自動	合格
プロジェクトビルド確認	自動	合格
テストケース#1：有効な名前入力	手動	未実施
テストケース#2：別の名前で確認	手動	未実施
テストケース#3：空文字入力	手動	未実施
テストケース#4：ダイアログキャンセル	手動	未実施

静的検証とビルド確認は行われていますが、肝心の業務ロジックの正常系・異常系テストは手動実行を前提としています。

これは、InputDialog とロジックが Main.xaml に直接書かれているためです。実行すると必ずユーザー操作が必要なダイアログが表示されるので、業務ロジック部分だけを自動テストする構成にはなっていません。

Claude Codeで作った結果

次に、Claude Codeにも同じプロンプトでRPAワークフローの作成を依頼しました。

Claude Codeでは、Main.xaml に加えて、ロジックを独立させたのサブワークフローとテストケースも作成されました。所要時間は約10分でした。

プロジェクト構成は以下の通りです（一部省略）。

project_root/
├── Main.xaml
├── GenerateGreeting.xaml
├── TestCase_正常系_名前入力.xaml
├── TestCase_異常系_空入力で例外.xaml
├── project.json
└── doc/
    ├── 設計書.md
    └── テスト結果.md

Main.xaml は、ユーザー入力とメッセージ表示を担当します。

InputDialog で名前を入力する
GenerateGreeting.xaml を呼び出す
生成されたメッセージを MessageBox で表示する

一方、GenerateGreeting.xaml は、挨拶文生成と入力チェックを担当します。

引数 in_Name を受け取る
String.IsNullOrEmpty(in_Name) で空入力を判定する
空の場合は ArgumentException をスローする
空でない場合は out_Message に こんにちは、<名前>さん を設定する

この分割により、InputDialog を使わずにロジック部分だけをテストできるようになっています。

作成されたテストケースは以下の2件です。

テストケース	内容	結果
`TestCase_正常系_名前入力.xaml`	`田中太郎` を入力し、`こんにちは、田中太郎さん` が生成されることを検証	合格
`TestCase_異常系_空入力で例外.xaml`	空文字を入力し、例外がスローされることとメッセージ内容を検証	合格

テストケースには、UiPath.Testing.Activities の VerifyExpression / VerifyExpressionWithOperator が使われていました。

個人的には、今回のようなシンプルなワークフローであっても、テストしやすいように処理を分けた点は良いところだと感じました。

UiPath CLIで分析してみる

生成されたXAMLの中身を目視で比較するだけでは、UiPathプロジェクトとして問題なく扱えるかまでは分かりません。

そこで、UiPath CLIを使って、プロジェクトとして検証・ビルド・解析できるかを確認しました。

具体的には、以下の観点をCLIで確認しています。

validate: XAMLファイル単位で、アクティビティや式の設定に問題がないか
build: プロジェクトとしてビルドできるか
analyze: Workflow Analyzerで品質上の指摘が出るか
テスト実行: Claude Codeが生成したテストケースが実際に実行でき、期待通り成功するか

単に「それらしいファイルが生成されたか」ではなく、UiPathの開発ツール上で正しく検証・ビルド・実行できる成果物になっているかを見ています。

Studio Autopilot成果物
実行した確認は以下です。

チェック	結果
`Main.xaml` validate	Success / No diagnostics
build	Success
analyze	Success / Findings 0

ビルド自体は成功していましたが、ビルドログには以下の警告が出ていました。

Automation Hub URL 未設定
Log Message 未使用

いずれも今回のワークフローの動作には直接影響しない内容で、AnalyzerのFindingは0でした。

Claude Code成果物
実行した確認は以下です。

チェック	結果
`Main.xaml` validate	Success / No diagnostics
`GenerateGreeting.xaml` validate	Success / No diagnostics
正常系テスト validate	Success / No diagnostics
異常系テスト validate	Success / No diagnostics
build	Success
analyze	Success / Findings 0
正常系テスト実行	Success / `hasErrors: false`
異常系テスト実行	Success / `hasErrors: false`

異常系テストでは、内部的に ArgumentException のログが [Error] として出力されます。

ただし、これは期待した例外を TryCatch で捕捉して検証するテストなので、テスト失敗を意味するものではありません。

なお、Claude Code成果物では以下の警告も出ていました。

ローカル NuGet ソースが存在しないという警告
Automation Hub URL 未設定
Log Message 未使用
テストケースの Given Sequence が空

このあたりは、Studio Autopilot側と同様、今回の検証では致命的ではありません。ただ、本番向けに整えるなら修正しておいてもよさそうです。

CLIで見た範囲では、どちらの成果物も validate / build / analyze は問題なく通りました。差が出たのは、Claude Code側には実行可能なテストケースがあり、そのテストもCLIから実行して成功を確認できた点です。

ドキュメント内容の比較

今回のプロンプトでは、「処理内容、引数、変数をまとめた設計書」と「テストケースと結果ファイル」の出力も依頼していました。

そこで、生成されたドキュメントの内容も比較しました。

観点	Studio Autopilot	Claude Code
処理フロー	Mermaidのフロー図つきで、`InputDialog`、`If`、`Throw`、`MessageBox` の流れを説明	ファイルごとに役割を分け、`Main.xaml` と `GenerateGreeting.xaml` の責務を説明
アクティビティ詳細	各アクティビティのプロパティまで細かく記載	主要アクティビティと実行順序を中心に記載
テスト設計	自動確認は `validate` / `build`、業務ロジック確認は手動テストケースとして記載	`UiPath.Testing.Activities` を使う正常系・異常系テストケースを記載
保守しやすさ	1本のワークフローを理解するには十分	分割された構成とテスト対象の関係が追いやすい

Studio Autopilotの設計書は、Main.xaml の中で何が行われているかを丁寧に説明していました。特に、アクティビティごとのプロパティやMermaidの処理フローが記載されているため、ワークフロー本体を後から読むための資料としては分かりやすい内容です。

Claude Codeの設計書は、Main.xaml と GenerateGreeting.xaml の役割分担を説明したうえで、テストケースまで同じ設計書内で扱っていました。テスト結果ファイルにも実行ログが残っており、正常系・異常系が実際に合格したことを確認できます。

総合すると、Studio Autopilotは「単体ワークフローの説明資料」として丁寧で、Claude Codeは「分割設計、テスト設計、実行結果まで含む成果物一式」としてまとまっている印象です。

ただし、この違いはプロンプトで出力項目を明確にしたり、サンプルドキュメントを読ませたりすることで変わるはずです。ドキュメントの品質は、ツールの差だけでなく、依頼の具体性にも左右されると感じました。

比較結果のまとめ

比較すると、以下のようになります。

観点	Studio Autopilot	Claude Code
ワークフロー本体	期待通りに作成	期待通りに作成
構成	`Main.xaml` 1本	`Main.xaml` と `GenerateGreeting.xaml` に分割
テスト容易性	`InputDialog` 直結のため自動化しづらい	ロジック分離により高い
自動テスト	なし	正常系・異常系の2件あり
設計書	`Main.xaml` 中心に詳細を記載	分割構成とテストケースまで記載
テスト結果ファイル	`validate` / `build` はPASS、業務ロジック確認は手動未実施	自動テスト2件PASS、実行ログあり
作成時間	約15分	約10分
進め方	仕様確認を挟む	仕様確認なしで作り切る

どちらもワークフロー本体は作成できています。XAML上の実装にも大きな差はないことを確認できました。

ただ、今回のプロンプトには「テストケースと結果はファイルに出力する」という要求が含まれていたため、この観点ではClaude Codeの方が要件に近い成果物になりました。

それぞれの印象

Studio Autopilot
Studio Autopilotは、Studio上で自然なRPAワークフローを作る点では十分に使えます。

特に、UiPathに慣れていない人が「どのアクティビティを使えばよいか」を知るには便利です。今回のような InputDialog、If、Throw、MessageBox の組み合わせであれば、素直な構成を作ってくれました。

一方で、テスト可能性を考慮して処理を分割するところまでは自動では行われませんでした。少なくとも今回のプロンプトでは、InputDialog を含む Main.xaml に処理がまとまったため、自動テストは作られませんでした。ただ、モデルを変えて再度作り直したところ、Claude Codeと同じ構成で作成できたため、プロンプトを工夫すれば改善できる可能性はありそうです。

Claude Code
Claude Codeは、ファイル構成やテスト設計まで含めて考えてくれる印象でした。

今回のポイントは、InputDialog を含む Main.xaml と、ロジック部分の GenerateGreeting.xaml を分けたことです。

この構成にしたことで、ユーザー操作が必要な部分を避けて、ロジックだけを自動テストできるようになりました。

また、UiPath.Testing.Activities を使ったテストケースを作成し、実際にCLIで実行できた点も良いところです。

ただし、UiPath固有のプロジェクトメタデータや細かい設計書の記述には、人間による確認が必要です。たとえば、project.json の requiresUserInteraction が false になっていましたが、本体ワークフローは InputDialog と MessageBox を使うため、実態としてはユーザー操作が必要です。

おわりに

今回の比較では、RPA本体だけを見ると、Studio AutopilotもClaude Codeも要件を満たしていました。XAMLの実装内容にも大きな差はなく、簡単なワークフローであれば、どちらを使っても十分に形にできると感じました。

知名度的には圧倒的にClaude Codeが優位ですが、機能的にはStudio Autopilotも同程度の実力が示されたかと思います。

差が出たのは、テストしやすい構成に分けるか、テストケースや実行結果、設計書まで成果物として残すかという部分です。今回のプロンプトではClaude Codeの方がそこまで踏み込んでいましたが、これはツールの優劣というより、プロンプトの書き方や作業の進め方で変わる部分だと思います。

そのため、この検証で言いたいことは、どちらが良い・悪いという話ではありません。Studio上で確認しながら小さく作るならStudio Autopilot、テストやドキュメントも含めてファイル単位で整えたいならClaude Codeのようなコーディングエージェント、というように使い分けるのが現実的だと思います。

なお、今回はかなり小さなRPAワークフローでの比較です。Maestro、Apps、Agentなどを含む大きなプロジェクトでは、成果物の構成やレビュー観点も変わるはずなので、今回の結果はあくまで一例として見てもらえればと思います。

また、今回はコスト（トークンやライセンス費用）には一切触れていません。実際に、どっちを採用するか決める際には重要な指標となるので、忘れずに検証していただきたいと思います。

ちなみに私の仕事環境は、Studio Autopilot、Claude Code（Amazon Bedrock）に加え、GitHub Copilotも使えますが、そもそも業務内容が開発メインじゃないので、そこまでツールにこだわりがありません。定額で使えるGitHub Copilotをよく使ってます。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up