2020.01.14
今回は、RPAツールの一つであるUiPathの各ライセンスの説明を行っていきたいと思います。
UiPathでは使用するロボットの特性に応じて様々なライセンス形態を準備していますので、
それぞれの特徴、どのような用途に向いているのか、などを詳述してまいります。
また、各ライセンスの金額についてはリセラー様により変動しますのでこのブログでは割愛いたします。
※これから述べる情報は2019年12月時点のものであり、
将来的にUiPathのほうで他の新ライセンスや既存ライセンスの仕様変更が行われる可能性もあることを留意していただけたらと思います。
UiPathのライセンス形態は複雑ですので、まず大枠の話をします。
UiPathのライセンスはまずその用途から、
・Studio
・Attended Robot(以後ARと略します)
・Unattended Robot（UR）
・Orchestrator（OC）
上記4つに分かれます。
Studioはシナリオの開発（xamlファイルの作成）をする際に必要な開発ツールです。
これはライセンスという形で購入することもできますが、
まずは初心者の方向けにUiPathが無料のトライアル版を公開しているので、それをダウンロードして試すのが良いでしょう。
Studio内の各種機能詳細については、UiPathの公式ページや他サイトでも書かれているので、
ここでは、特にそのライセンスの特徴について述べていきます。
RPAのシナリオ作成をする際に、当たり前ですが都度作成したシナリオをテストとして動かす必要があります。
なので、完成したシナリオを後述する実行用ロボットであるAR/URに行わせずに、Studioで実行させる運用も理論上は可能です。
ですが、実現場ですと開発者と日々RPAを使用するユーザーは異なることが通常ですので、実運用となると実行用にAR/URを購入するのが一般的です。
RPAツールは、本来エンドユーザーでも開発できること
（これを業界用語でエンドユーザーコンピュ―ティング、略してEUCと呼びます）を理想として謳っていますが、
会社によっては「開発は絶対ベンダー任せ」のところもあるかと思います。
そういう時に、よく言われるのが「実行用のAR/URは買うから、Studioは買わないようにできない？」というご質問です。
これはUiPath側のポリシーとして基本的には禁じられています。
ユーザー側の企業がAR/URをご購入する際は、最低1つのStudioライセンスも購入する前提でいていただけたらと思います。
2019年秋よりUiPathから新しいStudioツールである「Studio X」が公開されました。
こちらは、従来のStudioと比べ、より現場ユーザー向けの簡潔な仕様となっています。
プログラミング未経験者の現場ユーザーが従来のStudioを扱うと、かなり柔軟に細かく設定ができる一方、
ボタンやアクティビティが多く、とっつきにくい印象を持たれていたと思います。
（ちょっと画像加工をしたいビギナーの方がAdobe IllustratorのUIを見た時に受ける印象と一緒です。）
そこで、新たに開発されたStudio XではよりEUC向けに、ボタン数もぐっと減り、
アクティビティ名もプログラミングにあまり明るくない方にも分かりやすくなるように表示されています。
またＸで作ったxamlは、今までのStudioへの変換が可能です。
但し、従来StudioからＸへの互換性はありませんので注意が必要です。
まずARとURの違いは、手動でしか起動できないか／否かで分かれます。
ARのＡがAttendedであることを示す通り、人間が起動時に在席していることが前提のロボットとなります。
従って、深夜や祝日に起動させたい業務内容の場合、ARは向きません。
一方、URは手動での起動ももちろんできますが、OCと繋げることで予めスケジュールを設定しておけば自動で起動します。
その代わり、URのライセンス料金はARよりも4倍弱高価であるのが相場となっています。
ここでよくクライアント様に言われるのが、Windowsのタスクスケジューラとの関係です。
テクニカルに言えば、ARであってもタスクスケジューラを経由して自動起動させることはできます。
ただ、こちらはUiPath側としては認めておらず、規則を守るのであればURを使用することが求められます。
ただ、そうは言っても基本的にはURは、後述するRobot管理用のツールであるOCがあってこそその威力が活きるRobotです。
OC無しのユーザー企業がURを導入するケースはほぼ無く、あったとしても将来的にOCを入れる前提で過渡期としてOC無しでURを導入するケースがあるくらいです。
本ブログのテーマであるライセンスの話から少し脱線してしまいますが、
ここで敢えてAR/URを動かす端末の話をしたいと思います。
前述したとおりARは手動での起動が前提、URは自動での起動が可能という特徴があります。
その場合、それぞれのRobotが実装される端末は以下のパターンに分かれます。
まずARでは、実際にRobotが動作するときに社員も同席しているような業務を行う為、一般的なPC上で動作させることが多いです。
エクセルのマクロのような感覚で手軽に使いたい場合は社員自身のPC内でクリックしてARを起動させる事も可能です。
ただ、その代わりその間、社員は他の作業ができませんので、現実的に多いのが、専用のPCを設けるパターンです。
もしくは、あまり頻度はそこまで多くはありませんが、このARの段階からサーバ上のVM（仮想マシン）で動かすケースもあります。
その場合、社員は自分のＰＣからリモートデスクトップでＶＭに繋ぎ、そこからＡＲを起動させる手順となります。
次に、URの場合ですが、この段階になると多くの企業がVMを採用します。
原理的には物理的なローカルPCでもURを動かすことはできますが、URになると実働時に人間が介入することはなくなるので、
ネットワークの安定性やセキュリティの観点からVMに実装させることのほうが多いです。
OC導入の過渡期のクライアント様の中には、OC前はARにしてOC入れたらURにしようというような方もいらっしゃるかもしれません。
しかし、基本的にARの契約期間中にURにアップグレードすることは認められておらず、
ユーザー側は別途URライセンスを購入する必要があります。
（そしてARは契約期間になったらそのまま終了させる。）
なので最終的にOC導入後にARを使う予定の無いユーザー様については、最初のOC導入前段階からUR購入しておく必要があります。
先ほどURは基本的にOC前提のRobotと申し上げましたが、もちろんARもOC環境下で動かせます。
実際に大手企業様でUiPathを活用している場合だと、ARとURのライセンスを両方購入して、うまく業務内容に応じて使い分けています。
最後はAR/URの開発段階での活用についてです。
Studioでシナリオは作成されますが、Studio上で「実行」が上手くいったとしても、
本番環境のAR/URで動かした時になぜかエラーが起きてしまうこともあります。
これは両者の実行スピードが異なる等の理由が挙げられます。
例えばStudioではdebugモードで実行するとスピードが落ちるのですが、AR/URで動かすと高速になり、
そのためサイト上のボタンやデータを掴めないでエラーが出るなどのケースです。
また、Studioは基本的にローカルのPC端末で動かしますが、
URはサーバ上のVMで動かすとなると環境自体が違うのでやはりエラーがでる可能性はあります。
このようなケースに対処するために必要なのがステージングの考え方です。
ステージング/UATのために開発段階においてもAR/URを使えるようにし、
本番環境と同じ条件下でテストできるようにしておくことが重要になってきます。
その際に、UiPathが提供開始したのが、Non-Productionと呼ばれるライセンス形態です。
これはAR/UR両方に適用できます。
このライセンス形態は本番環境で使わないことが規約上求められているのですが、
通常のライセンスにくらべて格段に安くなっています。
Orchestrator（OC）は、特にRPAロボットが増えた状況下で有益となるRobot管理ツールです。
Blue Prism等では、このような管理ツールは有無を言わさず最初から導入しておくのが前提となっていますが、
「小さく始めたい」ユーザーニーズも拾う志向が強いUiPathではオプションという位置づけです。
とはいえ、このOC、以前は1種類しかなくかなり高価な代物であり、
UiPathを試験導入した企業にとって一寸敷居が高く感じるものでした。
ただ2019年秋より「Orchestrator Basic」という（今までのはOrchestrator Standardと呼ばれるようになりました）、
より価格を抑えたタイプが発売され、今後導入する企業が増えることが期待されています。
まず、このBasicとStandardの違いを説明する前に、
このOCで何ができるようになるのか、その特徴を伝えていきたいと思います。
OCでできることは細々と多くありますが、
ここでは特にユーザー様側で理解しやすいメリットを中心に述べていこうと思います。
これはAR/URの章で既に述べておりますが、
OCを導入することでURに「毎週●曜日●時●分にこの業務を行いなさい」と指示を出す事が出来ます。
このタイムスケジュール管理はOCが持つ強力な機能の一つです。
本来RPAで最も効果が高く、人間の生産性向上に結び付くのはこのような「完全自動化」対象となる定型業務です。
いちいち人間側がロボットをキックさせなくても決められた時刻に、
例えば深夜にロボットを起動させることができれば翌朝、人間はロボットが終わった処理から業務をスタートすることができます。
また、本来本当の意味で「毎日」行うべき外部サイトからのデータスクレイピング業務についても、
人間だと土日に行うのは無理ですが、このOCの機能を使うと可能になります。
この時間設定の機能について詳細が気になる方も多いかと思います。
例えば、「ロボットに作業させたい日時が月によってかなり変動する。どのように時間設定を変更できるのか」というようなご質問もあるかと思います。
この時間設定の機能がOCでコントロールしている以上、それはOC側で設定する事項となります。
ただその時に、「一般ユーザーにOCにアクセスしていじらせてしまってよいものか。。。」という難題が出てきます。
通常、OCにアクセスして細々とした設定変更を行うのは
情報システム部などのごく一部の限られた人たちだけにするのが一般的です。
ユーザー部門から新しい日時を情報システム部が受けOC設定するのも可能ですが、
あまりにもその頻度が多すぎると情報システム部の負荷が増え敬遠されます。
そのような時に、アイデアとしては「OCの時間設定変更用のロボットを新たに作る」というものがあります。
ユーザー側に何かエクセルなりで時間設定変更の申請書をメール／フォルダ格納で提出させ（承認フローが必要でしょうが）、
ロボットがその情報をもとにOCの設定を更新する方法です。
このやり方だと、そのロボットにだけOCアクセスの権限を付加すればよく管理上の手間およびリスクは軽減されます。
これは特にURに自動で業務をさせるときに必要になります。
ARの場合、人間が同席しておりますので、
Robotを起動させる端末のWindowsログイン情報およびSAP等の外部システムのID/Passといった情報は人間に入力させれば事たります。
しかし、URの場合、どこからかその情報を取ってこないといけないので、その管理方法を考える必要が出てきます。
その方法としては一般的に「Windows資格情報の機能を使う」か「アクセス権限のある特定のフォルダにエクセル等で格納」か、
そして最後に「OCに持たせるか」の3つに分かれます。
ただし、この3つの方法が選べるのは外部システムのID/Passについてです。
URのロボットが起動する端末のWindowsアカウント情報については、「OCに持たせる」しか選択肢はありません。
（それかURが起動する端末マシンを常にログイン状態にしておくか、です）
そもそも人間が介在しないURの場合、
最初にそのロボットが動く端末のWindowsにログインして起動状態にしておかないといけません。
URの場合、それをOCの指示で行います。
従ってWindowsのアカウント情報だけはOC側で管理しておく必要があります。
実際にロボットが起動したあとに業務上必要となる外部システムのID/Passについて、上記3つの方法いずれでも技術上可能です。
そこで外部システムのID/Passを管理する一手段としてOCのクレデンシャル情報管理機能（GetCredential）が使えます。
ロボット側が作動毎にクレデンシャル情報をOCからもらって使用する形態になります。
これによりクレデンシャル情報はロボット端末側で管理する必要はなく漏洩リスクは軽減されます。
また、開発段階ではテスト環境下での仮ID/Passを開発ベンダーに教えて、
本番環境についてはGetCredential機能を使わせるようにすれば開発ベンダーに本番のID/Passを教える必要は無くなります。
この機能もＯＣ導入を促す強力な要素です。
RPAの利用が拡大していくと、それこそ自社のＥＵＣ用途やベンダー向けに複数のStudio ライセンスが必要になりますし、
またAR/URの数も膨大になります。
OC無しの環境下では、基本的にStudioやAR/URのライセンスは
「ユーザー単位（大雑把に言うとWindowsアカウント単位）」もしくは「PC端末単位」で付与されます。
これをUiPathの用語では、「Named User」と「Node Locked」という呼び方で表現します。
一寸、色々なライセンス形態の話が出て来るので混乱してしまう方もいらっしゃると思いますが、
StudioやAR、URのそれぞれのライセンスの下で「Named User」や「Node Locked」といったタイプを選べると思っていただければと思います。
（正確に言うとURではNamed Userの概念が無かったりしますがここでは割愛します。）
つまり「Named User」のライセンス形態の場合、ユーザーが同じであればPCが変わっても利用が可能です。
ただし、同時に動かせるのは1ライセンス1台のみとなります。
一方、「Node Locked」になると、PCが同じであればユーザー数は問いません。
この形態は、例えばARにおいて複数の派遣社員の方々が同じ端末だけど
ログインアカウント変えてRobotを使用する時などに向いています。
いずれにせよ、この「Named User」や「Node Locked」では、
ライセンスがユーザーやＰＣ端末に縛られていまい柔軟に付け替えできない問題があります。
これは例えば、実際には「同時」には最大3人ぐらいしか使わないのに、
開発するユーザーアカウントが10人分必要だからStudioライセンスを10購入しなければならない。。といった非効率を生みます。
このような特に役に立つのが、OC下でのみ可能となる「Concurrent」というライセンス形態になります。
（正確にはConcurrentも更にUserとRuntimeに分かれますが、ここでは割愛します。）
「Concurrent」においては、複数のユーザー／PC端末間でライセンスのシェアができます。
つまり、開発者が10人いたとしても、同時利用が最大3人であればStudioライセンスは3つで足り、
さらにAR/URにおいても同時刻に行われる業務が最大5つ程度であれば、5ライセンスで足ります。
この観点は、特にRPAを利用する部門やベンダーが多岐に渡るようになってきたときにライセンス消費を効率化する点で重要になります。
この場合、そのライセンス枠から外れてしまった場合、
例えば3つのUR（Concurrent）ライセンスしかないのに4つ目の業務が来てしまった場合、
その実行を先行する業務が終わるまで「待たせる」機能もつけることができます。
（Queue(キュー)とTransaction(トランザクション)）
ちなみに補足ですが、OC導入前にUR（Node Locked）を購入し、
OC導入後に同ライセンスをUR（Concurrent）に途中切り替えするのは可能です。
詳細はリセラーのポリシーにもよりますが、
現行ではNode Locked→Concurrentは追加費用なしで切替できるところが多いようです。
（Named User → Concurrentの場合はおそらく追加費用が発生）
このように色々と便利な機能が付くOCですが、今まで問題となっていたのが、その金額の高さです。
大手で本気でRPA導入を進めている企業であれば、年間システム開発費に比べて微々たる額だとは思いますが、
これからRPAを本気で取り組むべきか否かまだ迷っている企業様においては無視できない金額でした。
そこでUiPathが2019年秋より公開したのが「Orchestrator Basic」です。
このBasicの特徴について述べていきたいと思います。
OCのBasicでは、接続可能なUiPath Robot（AR/UR）およびUiPath Studioはそれぞれ5つとなります。
またOC内で設定するテナント（ライセンスを管理するグループ単位）の利用可能数は1つになります。
一方、通常のOCだと、接続可能なRobotおよびStudioの数は無制限です。
但しBasicの価格より高価になります。
これはリセラー側のポリシーによるところもあるのですが、
現時点ではOC BasicからOC Standardへの契約期間中の変更は可能であり、
残り期間中のBasicとStandardの価格差分だけを支払うことになるケースが多いです。
以上、UiPathのライセンス概要について説明しました。
UiPathのライセンス形態は複雑で、初心者の方にとっては折角RPAをやろうとしているのに、
いきなり心が折れるような気持ちなるかもしれません。
そのような時は是非、弊社に問い合わせをしていただけたらと思います。
