はじめに　

皆様、こんにちは。コラムをご覧いただきありがとうございます。
今回は、UiPathの管理ツールOrchestratorについて書いていきます。

筆者は所属プロジェクトで、クライアント様のOrchestrator移行作業を経験しました。
そこで、実際の現場を通して学んだ移行作業のポイントをご紹介します！

UiPath Orchestratorとは?

Orchestrator(以下OC)とはサーバー型のロボット管理ツールのことで、OCの導入によってUiPath Studioを使用して開発したロボットをアップロードして一元的に管理・運用ができるため、ロボットの台数が増えて管理が難しい場合や、同時に多数のロボットが連動する業務を劇的に効率化できます。
詳細は、UiPath公式のスターターガイドをご参照ください。

下記は、OC関連用語です。

表にもありますが、UiPathのロボットにはAttended Robot(以下AR)、Unattended Robot(以下UR)の二種類があります。URには様々なメリットがあるので、本コラムではOC移行とあわせてAR ⇒ URへの移行も取り上げます。

どんな時に、移行がおすすめ？

ここでは、OC移行やUR移行が必要なシチュエーション、移行のメリットをいくつかご紹介します。

☑時間を問わずロボットを実行したい！

URでは、①スケジュール②キュートリガーの二種類のトリガー実行が可能です。
深夜や早朝にロボットを実行したい場合、ARからURに移行することで、業務時間外にロボット実行者が勤務する必要がなくなります。トリガー実行を活用することで、高い費用対効果が期待できるだけでなく、人的作業が不要になりヒューマンエラーの減少が見込める点もURのメリットです。

☑長いプロセスをロボットに任せたい！

ARはエンドユーザーの業務をサポートする形で機能し、小規模な日常業務や業務プロセスに含まれる特定の作業の自動化に適しています。一方でURは、「バックグラウンドで独立して動作する」「複数端末で同時実行が可能」等の特長があり、会社・部署全体の大規模な自動化との相性が良いです。また、ロボットが一度に多くの作業を行う場合、OCではキューを活用した分散処理が可能です。そのため、複数ユーザーやチームで行う業務、実行時間が長い業務をロボット実行する場合は移行がおすすめです。

☑ロボットの台数が増加してきた…

UiPath導入時は少なかった稼働ロボット台数も、様々な業務の自動化を進めるにつれ増加するかと思います。ロボット台数やシナリオが増加すると管理が難しくなり、セキュリティの観点から見てもリスクが大きくなります。OCでロボットを一元管理することで、管理者のいない「野良ロボット」がなくなるだけでなく、ライセンスやパッケージを集中管理できるので端末ごとに設定する必要がなくなります。ログが集約される点、管理画面から稼働状況を一目で確認できる点も、運用者の負担削減の助けとなります。UiPath公式サイトでは、ロボットの台数が10台以上の場合はOCへの移行を推奨しています。
（参考：UiPath『野良ロボット対策 UiPath Orchestrator | UiPath』）

補足：ライセンスについて

ARのライセンスにはもともと、Node Lockedと呼ばれる端末ライセンス(※現在は使用不可)と、Named Userというユーザーごとのライセンスがあります。ユーザーごとにライセンスを使用するNamed Userの場合は、ロボット実行者が10人なら10ライセンスが必要となります。
一方URは、ロボットを同時実行しない限りライセンスは1つでOKです。逆に、ユーザーごとではなく同時実行台数分のライセンスが必要となります。ARとURとでは大きく価格が異なるという面でも、費用対効果をしっかり測って導入を検討する必要があります。
（参考：UiPath『Attended と Unattended ロボット (uipath.com)』）

開発者による移行作業

既存のロボットがOCで実行できるように、開発者は必要に応じてワークフローを変更します。ここでは、筆者のプロジェクトで実際に考慮したポイントをいくつか挙げていきます。

☑印刷処理と人的アクション

プリンターを使用する際は、セキュリティ上従業員のICカード認証が必要なことが多いです。ARではWindows個人アカウントでロボットが実行されますが、URではロボット用アカウントで実行されるため、プリンターの認証に使用する従業員用ICカードをロボット用に発行しなければなりません。そのため、既存の印刷処理を代替出力方法へ変更する必要があります。もちろん、ICカード不要で印刷できる環境であれば考慮は不要です。
また、AR実行中に人手で処理の一部を行うシナリオも注意が必要です。UR実行中は、ダイアログ入力やファイル指定等の人的アクションはできません。そのため、ロボット用設定ファイルで制御し人的アクションを自動化する必要があります。

☑アプリケーションの事前起動

ARではユーザーが任意のタイミングでロボットを動かすため、特定のアプリケーションを起動・ログインしてからロボットを実行することができます。しかしURではユーザーが実行用端末からロボットを実行するのではなく、OCが実行端末に指示してロボットを自動実行します。そのため、事前に特定のアプリケーションを事前に起動した状態でロボットを実行することはできません。アプリケーションの起動は全てワークフロー内で行うよう改修する必要があります。

例えば…
移行前(AR)：ユーザーがブラウザの特定のページを起動してからロボットを実行し、ロボットがボタン押下する
移行後(UR)：ページURLを指定してブラウザを起動するところからロボットが処理する

☑Windows資格情報の廃止

OC移行前(AR)は、ロボット実行の際にWindows個人アカウントへのログインが必要です。一方、移行後(UR)では冒頭の用語一覧にもある「ダイナミックアロケーション」が適用されるため、どのロボットアカウントでどのロボット実行端末にログインするかは動的になります。
Windowsログイン情報は、OCのアセットから取得にするよう変更が必要です。

※「ダイナミックアロケーション」イメージ

☑使用パッケージのバージョン検討

移行に伴って、パッケージの相互運用性を考慮する必要があります。サポート終了日、使いたい機能を考慮してバージョンを選択します。
各パッケージの相互運用性はUiPath公式サイトで一覧表になっているので、ご確認ください。
（参考：UiPath『相互運用性マトリクス』）

例えば…
・OCを、クラシックフォルダー(将来廃止予定)ではなくモダンフォルダーで実行するには、UiPath.System.Activitiesパッケージをv19.10.1以上にする必要があります。
（参考：UiPath『クラシック フォルダーからモダン フォルダーへの移行』）
・Internet Explorer(以下IE)廃止に伴って、EdgeのIEモードに移行を考えられている場合はUiPath.UIAutomation.Activitiesパッケージを20.10.10に上げることが必要です。
（参考：UiPath『Internet Explorerサポート終了に関するワークフローの移行について』）

☑特殊アプリケーションの利用

URでダイナミックアロケーションが適用されることで、一般的なロボット実行端末にはインストールされていない(ユーザーごとにライセンスが必要な)特殊なアプリケーションを利用している場合、アプリケーションのライセンスを新たに用意する必要があります。

☑ファイルのローカル保存処理の有無

URが実行される端末はARとは違い、人が管理することはできません。そのため、ダウンロードしたファイルをローカル保存している場合、HDD圧迫による障害発生の可能性があります。共有フォルダーを使用するよう、ワークフローを改修する必要があります。

おわりに

ここまで読んでいただき、ありがとうございます。
本コラムが、OC移行を検討中の方のヒントになれば幸いです。

BTCでは、RPA開発だけでなく上記のような管理ツールの導入にも対応いたします。
こちらからどうぞお気軽にご相談ください！

関連記事

BTC RPA

RPAの管理でロボットをフル活用できるように！

BTC RPA

UiPathプロジェクト開始時の準備について（フレームワーク・規約）