社内で長年動かしてきたUiPathのロボットについて、Power Automateへの移行を検討するよう言われた担当者は少なくありません。
契約更新のタイミングでライセンス費用の見え方が変わったり、Microsoft 365を中心にした社内方針が示されたりすると、移行そのものは既定路線として降りてきます。
ただし何十本もあるロボットを一斉に作り直すのは現実的ではありません。
この記事では、UiPath資産の棚卸しから可否判定の軸、検証の進め方までを整理しています。
UiPathからPower Automateへの移行は『検証』から始める
UiPathからPower Automateへの移行を検討する際、最初に決めるべきは「全部移行するかどうか」ではありません。
対象ロボットの中から数本を選んで検証し、その結果を見てから全体の方針を決める順番のほうが後戻りが少なくなります。
移行の方針は、大きく3つのパターンに分かれます。
- 全面移行:すべてのロボットをPower Automateへ作り直す
- 作り直し:UiPathの処理内容だけを参考にし、Power Automateの標準機能に合わせて構成から見直す
- ハイブリッド:一部の複雑なロボットはUiPathに残し、単純な処理だけをPower Automateへ移す
どのパターンが適しているかは、検証で個々のロボットの可否を確かめてから判断します。
移行の背景にはMicrosoft 365との統合という事情もあります。
UiPathは自動化専用のプラットフォームとして機能が独立している一方、Power AutomateはExcel、Outlook、Teamsといった日常的に使うアプリと標準で連携できるため、ツール統合を進める中で移行の指示が出ることが多くなっています。
小さく検証してから範囲を広げるという進め方自体は、業務自動化全般に共通する考え方です。
移行前に検証するUiPath資産の棚卸しと可否判定
移行を検証するには、まず稼働中のロボットを一覧化し、1本ずつ移行の可否を判定する作業が欠かせません。
管理するロボットの数が多い組織ほど、この棚卸しを省略して検証に入ると途中で判定基準がぶれてしまいます。
判定は、業務価値、技術的な移行可否、運用形態の3つの軸で行います。
業務価値はロボットが止まったときの業務影響、技術的な移行可否はPower Automateの標準機能で再現できそうかという見立てです。
運用形態は、人が起動するAttended型か、スケジュールで無人稼働するUnattended型かという違いです。
| 判定軸 | 確認するポイント | 判定への影響 |
|---|---|---|
| 業務価値 | 停止した場合に業務へどれだけの影響が出るか | 価値が高いロボットほど検証と移行の優先度が上がる |
| 技術的な移行可否 | シナリオの複雑さ、条件分岐の数、UI操作の方式 | 単純な処理は再現しやすく、複雑な条件分岐は追加検証が必要になる |
| 運用形態（Attended／Unattended） | 人が起動するロボットか、スケジュールで無人稼働するロボットか | Unattended型はOrchestratorの資産設計を先に整理する必要がある |
この3軸で分類すると、優先して検証すべきものと、当面UiPathに残してよいものが自然に分かれてきます。
Orchestrator資産のキュー・アセット・スケジュールをPower Automate側の何に対応させるか整理する
UiPath Orchestratorでは、キュー、アセット、スケジュールといった仕組みでロボットの実行を管理していますが、これらはPower Automateにそのまま移せるわけではなく、対応する機能に置き換えて設計し直す必要があります。
キューは処理待ちの案件を一時的に貯めておく仕組みで、SharePointリストやDataverseのテーブルに案件を登録し、フローがそこを参照しに行く構成に置き換えるのが一般的です。
アセットは資格情報や設定値を一元管理する仕組みで、接続情報や環境変数の管理機能が近い役割を果たします。
スケジュールは、クラウドフローに標準で備わるスケジュールトリガーに置き換えられます。
これらの対応関係は1対1で完全に一致するわけではなく、標準機能で同じ目的を達成できる設計に組み直す発想が必要です。
この当たりをつける作業を検証フェーズに含めておくと、本移行の見積もりが正確になります。
UiPathとPower Automateの対応関係と移行できない部分
UiPathで作られたシナリオは、Power Automateのフローへそのまま自動変換できるわけではありません。
移行支援ツールを使っても処理のロジックを機械的に移し替えることは難しく、対応するアクションを1つずつ組み直す作業が発生します。
大きな違いの1つが、UI要素を認識する方式です。
UiPathは画面上の要素をセレクターという形で細かく指定できますが、Power Automateはブラウザ拡張機能や画像認識ベースの操作が中心で、同じサイトの操作でも認識のやり直しが必要になることがあります。
長時間の処理や大量データを扱う処理では、体感の速度差が話題に上ることもあります。
ただし設定やフローの組み方次第で改善できる余地が残っている部分で、検証を通じて実際の処理時間を確かめてから判断するのが確実です。
こうした移行時の対応関係を整理する目的で、Microsoftも支援ツールを公開しています。
出典：Microsoft「Automation Kit for Power Platform」（ https://microsoft.github.io/powercat-automation-kit/migration/）
検証の初期段階でこのツールに目を通しておくと、どの処理が対応しやすく、どの処理でつまずきやすいかの見当がつけやすくなります。
UiPathからPower Automateへの移行検証の進め方4ステップ
移行検証は、対象を絞った小規模な検証から始め、並行稼働で結果を確かめたうえで全体の判定に進むという4段階で進めます。
Step1. 検証対象を選ぶ
最初のステップは、検証するロボットを2本から10本程度に絞り込むことです。
選ぶ基準は、処理が単純であること、業務価値が高いこと、失敗しても元のUiPath環境にすぐ戻せることの3点です。
いきなり複雑なロボットから始めると、原因が技術的な限界なのか進め方の問題なのかを切り分けにくくなります。
Step2. Power Automate Desktopで再構築する
選んだロボットの処理を、Power Automate Desktopのフローとして組み直します。
UiPathのシナリオを見ながら同じロジックを再現するのではなく、標準アクションで同じ結果を得られる構成を新たに設計する意識で進めると保守がしやすくなります。
Step3. 並行稼働で結果を照合する
再構築したフローを、既存のUiPathロボットと一定期間並行して動かし、出力結果を照合します。
処理件数や処理時間の差、例外処理の挙動の違いなど、この段階でしか見えない差分は多く、並行稼働を省略すると本移行後に不具合として表面化しやすくなります。
Step4. 全面移行かハイブリッドかを判定する
並行稼働の結果をもとに、そのロボットを移行対象に含めるかを判定します。
結果を積み上げると、全面移行が現実的か、一部をUiPathに残すハイブリッド構成が妥当かが実際のデータから見えてきます。
UiPathのライセンス費用とPower Automateの費用の考え方
移行の検討では、費用の構図を把握しておくことも欠かせません。
UiPathは複数のプラン体系を持っており、公式には次の料金構成が案内されています。
出典：UiPath「Commercial licensing plans」（docs.uipath.com）／UiPath公式サイト（uipath.com/pricing）
Unified PricingやFlexといった複数のプランが用意されており、最小構成のBasicプランは月額25ドルから利用でき、それより上位の構成は個別見積もりが必要な形になっています。
一方のPower Automateは、Microsoft 365のライセンスに含まれる無償の範囲と、Premiumコネクタや高度な機能を使うための有償プランに分かれています。
標準的なMicrosoft 365アプリ同士の連携であれば無償の範囲で組めることが多く、外部システムとの接続や高頻度の実行が必要になった場合にPremiumの検討が必要になるという構図です。
既存の自動化資産をPower Automateへ移す検証は、UiPathに限った話ではありません。
Power Automate Desktopでの入力操作そのものについても、別記事で具体的に扱っています。
UiPathからの移行について相談してみませんか？
「何十本もあるロボットをどう移行すればいいか見当がつかない」「Orchestratorで組んだ仕組みをPower Automateにどう置き換えればいいか分からない」「社内に移行を設計できる人材がいない」
少しでもお心当たりがあれば、お気軽にご相談ください。
現在、UiPathからPower Automateへの移行に関するお悩みをお伺いする 無料の個別相談 を実施しています。
UiPathからの移行検証でよくある質問
Q. Power Automateにすると処理が遅くなりませんか
設定やフローの組み方次第で変わります。
UiPathと同じ処理をそのまま移した場合に体感速度の差が出ることはありますが、多くはアクションの組み方や実行環境の設定で改善できる範囲に収まります。
検証の段階で実際の処理時間を測っておくと、本移行後の想定外に気づきやすくなります。
Q. 全部移行しないとだめですか
一部をUiPathに残すハイブリッド構成も選択肢です。
検証の結果、技術的に再現しにくい複雑なロボットが見つかった場合は、そのロボットだけをUiPathに残し、単純な処理から段階的に移していく進め方も現実的です。
Q. 検証にはどれくらいの期間がかかりますか
対象ロボットの本数や複雑さによって変わります。
数本の単純な処理なら数週間程度が目安になりますが、Orchestrator資産のマッピングや並行稼働まで含めると規模に応じて期間が延びることがあります。
