UiPath から Power Automate への移行｜BOT棚卸しと再実装の優先度付け

RPA（Robotic Process Automation）黎明期からUiPathを導入し、多くの業務を自動化してきた企業が今、大きな転換期を迎えています。その背景にあるのは、Microsoft 365エコシステムとの親和性が高い「Power Automate」の台頭と、UiPathのライセンス体系変更に伴うコスト増大です。

しかし、UiPathからPower Automateへの移行は、単なるツールの乗り換えではありません。ソースコードの互換性がないため、実態は「全BOTの再定義と再実装」を伴う大規模なDXプロジェクトとなります。本記事では、IT実務者の視点から、既存資産の棚卸し方法、移行の優先順位付け、そしてPower Automateへの具体的な再実装プロセスを網羅的に解説します。

1. UiPathからPower Automateへ移行すべき判断基準とコスト比較

移行を検討する最大の動機はコストですが、機能的なトレードオフを理解せずに進めると、移行後に「以前はできていたことができない」という事態に陥ります。

1.1 UiPathとPower Automateのライセンス構造の違い

UiPathは、開発環境（Studio）、実行環境（Robot）、管理環境（Orchestrator）のそれぞれに高額なライセンス費用が発生する傾向にあります。対してPower Automateは、Microsoft 365のライセンスをベースに、ユーザー単位またはプロセス単位での課金体系となっており、特に小〜中規模の自動化においては圧倒的なコスト優位性を持ちます。

※料金の詳細は、UiPath公式料金ページおよびMicrosoft Power Automate公式料金ページを必ず参照してください。

1.2 コスト削減効果（ROI）の試算例

例えば、20台の非アテンド型ロボットを運用し、年間数百万円〜一千万円以上のライセンス料を支払っている場合、Power Automateの「Processライセンス（旧Per Flow）」へ集約することで、維持費を30%〜60%程度削減できるケースが多く見られます。ただし、Power Automateで「非アテンド型（Unattended）」を実行する場合、別途仮想マシン（VM）の用意や、特定ライセンスが必要になる点に注意が必要です。

このようなインフラコストの最適化については、SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方の考え方が非常に参考になります。単にツールを置き換えるだけでなく、インフラ全体の負債を解消する視点が不可欠です。

2. 失敗しない「BOT棚卸し」の4象限マトリックス

既存のUiPathプロジェクトをすべてPower Automateへ移行しようとするのは、非効率なアプローチです。まずは「棚卸し」を行い、移行の必要性を精査します。

2.1 移行不要なBOTの選別

以下の条件に当てはまるBOTは、移行対象から除外するか、別の手段を検討します。

• 稼働頻度が極端に低い: 年に数回しか動かないBOTは、手動に戻すか、Power Automate Desktopの無料範囲で対応する。
• SaaSの標準機能で代替可能: 以前はRPAで繋いでいたが、現在はAPIやSaaS間の直接連携（例：freeeとSalesforceの連携等）が可能な場合。
• 入力元データが整理されていない: 野良BOT化しており、仕様が不明確なものは再実装コストが膨らむため、業務フロー自体を見直す。

2.2 業務影響度と実装難易度による優先順位付け

移行プロジェクトを円滑に進めるため、以下の4象限で優先順位を決定します。

• 【優先度：高】影響度：大 / 難易度：低

  基幹業務に関わり、かつAPI（クラウドフロー）で完結するフロー。早期に成功体験を作り、コスト削減効果を証明できます。

• 【優先度：中】影響度：大 / 難易度：高

  複雑なUI操作を含むレガシーシステム操作。UiPathのセレクター技術からPower Automate Desktopへの読み替えに工数を要するため、慎重な設計が必要です。

• 【優先度：低】影響度：小 / 難易度：低

  個人の事務補助。現場ユーザーにPower Automateの教育を行い、セルフサービスで移行を促します。

• 【非推奨】影響度：小 / 難易度：高

  特殊なブラウザ挙動や画像認識に依存するマイナー業務。移行コストがリターンを上回るため、廃棄を検討します。

3. Power Automateへの再実装に向けたアーキテクチャ設計

UiPathの「アクティビティ」をそのままPower Automateの「アクション」に置き換えるだけでは、安定したフローは構築できません。

3.1 「UI操作」から「API連携（コネクタ）」へのパラダイムシフト

UiPathはブラウザやアプリの画面を操作するUIオートメーションに強みがありますが、Power Automateの本質は「クラウドフロー（API連携）」にあります。例えば、Excelのデータを読み取る際、UiPathではExcelアプリを起動してセルを読み取ることが多いですが、Power Automateでは「Excel Online (Business)コネクタ」を使用して、ファイルを直接操作する方が高速かつ安定します。

特に経理業務の自動化において、CSVの加工やアップロードをRPAで行っている場合は、楽楽精算×freee会計の「CSV手作業」を滅ぼすアーキテクチャで語られているような、APIベースの設計へ転換する絶好の機会です。

3.2 デスクトップフローとクラウドフローの使い分け

Power Automate移行のキモは、「どこまでをクラウドフローで処理し、どこでデスクトップフロー（PAD）にバトンタッチするか」の境界線設計です。

• クラウドフロー: トリガー（メール受信、スケジュール、Webhook）、SaaS間連携、承認ワークフロー、条件分岐。
• デスクトップフロー（PAD）: APIが提供されていない古い基幹システム、Windowsアプリ操作、複雑なブラウザ操作。

3.3 UiPath独自機能の再現方法

UiPathで多用される以下の機能は、Power Automateでは異なるアプローチで実装します。

• Retry Scope（リトライ）: クラウドフローの設定メニューにある「再試行ポリシー」を構成するか、Do Untilループを用いたカスタムリトライを構築します。
• Assets（アセット）: 環境変数（Environment Variables）またはAzure Key Vaultを使用します。
• Queues（キュー）: Power Automateの「作業キュー（Work Queues）」機能（有償ライセンスが必要）を利用します。

4. ステップバイステップ：移行プロジェクトの実務手順

実務担当者がプロジェクトを推進するための標準的なステップを解説します。

STEP 1：現行ロボットの定義書・ソースコードの回収

UiPathのプロジェクトフォルダから、Main.xamlや各種サブフローを確認します。同時に、現在そのロボットが「何のために」「誰が」動かしているのか、最新の業務マニュアルを回収します。UiPathの「Object Repository」を使用している場合は、セレクター情報を事前にテキスト化しておくと再利用がスムーズです。

STEP 2：ターゲット環境（Power Platform）のガバナンス設定

移行を開始する前に、Power Platform管理センターで「環境」を分離します（開発・検証・本番）。また、DLP（データ損失防止）ポリシーを設定し、ビジネスコネクタと非ビジネスコネクタの混在を制限します。これを怠ると、社内の機密データが個人用SNSなどに転送されるリスクが生じます。

STEP 3：プロトタイプ開発とコネクタ利用可否の検証

最も重要なステップです。UiPathで操作していた対象システム（特にJava AppletやSilverlight等の古い技術を用いたアプリ）が、Power Automate Desktopのレコーダーやセレクターで正しく認識できるかを検証します。もし認識できない場合は、画像認識や座標指定への切り替え、あるいはAPIの自作が必要になります。

もし、現場主導での開発を継続したい場合は、Google Workspace × AppSheetによる業務DXのような、よりシンプルなノーコードツールへの移行も選択肢に含めるべきです。

STEP 4：本実装とUAT（ユーザー受入テスト）

実装が完了したら、UiPath側を一時停止し、Power Automate側で並行稼働テストを行います。出力されるデータがUiPath時代と一致するか、処理時間に許容できない乖離がないかを検証します。

5. 移行時に直面する「よくあるエラー」と解決策

5.1 セレクターが安定しない

UiPathの「セレクター（完全セレクター/部分セレクター）」と比較し、Power Automate Desktopの「UI要素」は、動的なIDを持つWeb要素に対して脆弱な場合があります。この場合、UI要素のエディターを開き、IDの代わりに「Name」や「Class」属性を使用し、必要に応じて「正規表現」を用いたマッチングに修正してください。

5.2 大容量データのループ処理におけるタイムアウト

クラウドフローで数千行のデータをループ（Apply to each）で処理すると、デフォルトでは直列処理のため非常に時間がかかります。「設定」から「並列制御」をオンにし、並列度を上げる（最大50）ことで高速化が可能ですが、接続先SaaSのAPIレートリミットに抵触しないよう調整が必要です。

5.3 オンプレミスデータゲートウェイの接続トラブル

クラウドフローから社内サーバー上のファイルやPADを呼び出す場合、「オンプレミスデータゲートウェイ」の設置が必須です。ゲートウェイが「切断済み」になるエラーの多くは、Windowsのスリープ設定や、ファイアウォールによるAzure Service Busへの通信遮断が原因です。443ポートのアウトバウンド通信が許可されているか確認してください。

6. まとめ：RPAの「点」からPower Platformの「面」へ

UiPathからPower Automateへの移行は、単なるツールの置き換えではなく、自動化の「民主化」と「標準化」を進める絶好の機会です。UiPathが得意とした「高度な個別最適」から、Power Platformが提供する「組織全体のデータ連携」へと視点を移すことで、移行コストを上回るDXの成果が得られるはずです。

棚卸しで不要なロボットを捨て、必要なものをAPI中心のアーキテクチャで再構築する。このプロセスを通じて、メンテナンス性の高い、持続可能な自動化基盤を構築しましょう。