無人オートメーションに役立つ概念

無人オートメーションはさまざまなコンポーネントに依存しており、これらのコンポーネントを知っておけば理解に役立ちます。以下のトピックでは、これらのコンポーネントを簡単に定義します。詳細については、その概念を使用する各手順で確認できます。

ロボット アカウント

ロボット アカウントは、特定のユーザーの責任にならないバックオフィスの無人プロセスを実行する必要があるときに役立ちます。これらは、サービス アカウントに相当する RPA 固有のアカウントです。Windows サービスが OAuth モデルのアプリケーション ID として実行するアカウントと同様に、無人プロセスの実行に使用される、非ユーザー ID です。そのため、非常に高い権限を要する操作に最適です。

ロボット アカウントを On-Premises Orchestrator に追加する方法については、こちらをご覧ください。

ロボット アカウントを Cloud Orchestrator に追加する方法については、こちらをご覧ください。

アクセスと権限

ロボット アカウントをモダン フォルダー階層の親フォルダーに割り当てると、ロボット アカウントは、その特定のフォルダーの下層に作成されるすべてのサブフォルダーに対するアクセス権を自動的に取得します (親フォルダー レベルで割り当てられているロールが付与されます)。親フォルダー レベルで割り当てられている権限に加えて、新しい権限をサブフォルダーに追加できますが、継承されたロールを削除することはできません。ロボット アカウントに、親フォルダー レベルよりも高いアクセス レベルをサブフォルダーで付与することはできますが、その逆はできません。

ロボット アカウントにサブフォルダー へのアクセス権のみを付与するには、アクセス権をサブフォルダー レベルで直接割り当てます。こうすると、ロボット アカウントは親レベルは表示できませんが、サブフォルダーとその下層にあるリソースすべてには、割り当てられたロール定義に従ってアクセスできます。ロボット アカウントをサブフォルダー レベルで割り当てても、そのフォルダーの兄弟 (つまり、同じレベルの他のフォルダー) へのアクセス権は付与されません。ただし、ロボット アカウントが同じレベルの他のフォルダーにも明示的に割り当てられている場合や、親レベルで割り当てられている場合を除きます (後者の場合、前述のように下層にあるすべてのフォルダーに対するアクセス権が付与されます)。

現在のフォルダー内のプロセスを実行するために、他のフォルダーのリソースが必要な場合は、その特定のプロセスの実行に使用するすべてのロボット アカウントが、他のリソースがあるフォルダーのロボット アカウントとしても割り当てられている必要があります。また、そのフォルダー内にある、プロセスに必要なリソースをアクセス/作成/変更/削除できる十分な権限も必要です。

グループ

複数のロボット アカウントをグループに追加して管理できます。グループとは、まとめて管理を行う、同様のアクセス権、ロボットの設定、ライセンスを必要とするアカウントのコレクションです。したがって、同じ設定とユース ケースを共有するロボット アカウントをグループ化することのみをお勧めします。たとえば、Windows マシン上でフォアグラウンド オートメーションを処理するロボット アカウントが 5 個と、Linux マシン上でバックグラウンド オートメーションを処理するロボット アカウントが 10 個あるとします。この場合、各カテゴリを専用のグループに追加しますが、結合はしないようにします。

グループを使用すると、ロボットのデプロイや権限の制御といった状況でスケーラビリティを利用できるので、複数のロボット アカウントを一つひとつ構成せずに済み、非常に便利です。

グループを On-Premises Orchestrator に追加する方法については、こちらをご覧ください。

グループを Cloud Orchestrator に追加する方法については、こちらをご覧ください。

UiPath Robot

ロボットは UiPath の実行エンティティです。オートメーションの種類に応じて、サービス モードまたはユーザー モードで実行できます。

サービス モードの Robot

サービス モードの Robot は、無人オートメーションのシナリオや大規模なプラットフォームのデプロイに最適です。プロセスが実行されると、Robot Executor が実行されます。この時、Robot Executor はそれが登録されているユーザーと同じ権限を持ちます。

Robot サービスはオートメーションの実行中に行われるすべての操作を司るブレーンで、無人オートメーションの実行はローカル システム下で開始されます。これは対話型の Windows セッションを開くことができ、マシン管理者のすべての権限があります。したがって、無人ジョブの自動セッション管理 (ログオンやログオフなど) が可能です。

UiPathStudio.msi を使用して Robot をインストールすると、既定でサービス モードの Robot がデプロイされます。Robot をコマンド プロンプトからインストールすることもできます。

注:

無人オートメーションは、ローカル システムにインストールされたサービス モードの Robot で使用するのが最適です。Unattended ロボットは、ローカル ユーザー (ユーザー モードの Robot) でも実行できます。ただし特定のユーザーが手動でそのマシンにログインしない限りロボットを実行できないため、この手法は推奨されません。

サービス モードの Robot は、マシン上のすべてのユーザーにインストールされます。サービス モードの Robot が Windows Server マシンにインストールされている場合は、自動セッション管理を使用して複数の無人ジョブを同時に実行できます。つまり、シームレスな無人オートメーションのシナリオが実現します。Windows Server 上のユーザー モードの Robot でもジョブを同時に実行できますが、自動セッション管理はできません。

ユーザー モードの Robot

ユーザー モードの Robot は、有人オートメーションのシナリオに最適です。このプロセスを開始するユーザーの下で実行され、そのユーザーとまったく同じ権限を持ちます。

.msi インストーラーでクイック インストール オプションを選択すると、既定で Robot がユーザー モードでデプロイされます。

Robot と Assistant

UiPath Assistant はロボットのインターフェイスであり、Studio で作成したプロジェクトを操作できます。

ただし、無人のシナリオでは、ユーザーが無人マシンにログインして潜在的な問題を確認・修正するときに、デバッグの目的でのみ Assistant を使用します。

マシン テンプレート

マシン テンプレートは、無人オートメーションに推奨されるマシンの種類です。マシン テンプレートを使用すると、一度設定を定義すれば複数のロボットを Orchestrator に接続できるため、複数のホスト マシンのデプロイが簡単に行えます。また、ホスト マシンの名前やそのマシンにログオンしているユーザーにかかわらず、複数のホスト マシンでデプロイされている UiPath Robot を Orchestrator に接続できます。

マシン テンプレートは、その名前が示すようにテンプレートとして機能し、その設定は同一の物理的セットアップを持つホスト マシンのグループに適用されます。1 つのキーまたは一連のクライアント資格情報を使用して、複数のホスト マシンを同じテンプレートに簡単に接続できます。このキーまたはロボットの資格情報は、ロボットがホスト マシンにログインして Orchestrator のリソースにアクセスするために使用されます。

同一のマシン テンプレート下でホスト マシンをグループ化する場合は、以下のプラクティスに従うことをお勧めします。

• ホスト マシンが共有テンプレートに基づいてデプロイされている。または、少なくとも共有テンプレートに基づいているかのように構成されている。

• マシンには同じアプリケーションをインストールする必要がある。また、アプリケーションは各マシンの同じパスにインストールされており、すべてのマシンで同じバージョンのアプリケーションを使用することが非常に重要です。

• これらのマシンでアプリケーションにログインするユーザーは、マシン上のアプリケーションに対して同一のアクセス権を持つ必要がある。

注意すべき重要な側面の 1 つとして、無人オートメーションを開始するアルゴリズムは、フォルダーに割り当てられているどのユーザー (特定のユーザーを手動で選択した場合を除く) でも、さらにマシン テンプレートに割り当てられているどのホスト マシンでもジョブを開始できます。したがって、実行用として選択できるすべてのアカウントが、そのフォルダーに割り当てられているすべてのマシン上で、対応するアカウントを持っていることが重要です。そうしないと、エラーが発生する確率が非常に高くなります。これを回避するには、特定のマシン テンプレートとペアにするユーザーがテンプレート内のすべてのマシン上に作成されていることを確認するか、または別個のテンプレートを用意し、そのそれぞれに、より少ない数のマシンと関連ユーザーを設定して、有効な組み合わせのみを各フォルダーに定義することが重要です。

例

以下のエンティティがあります。

• フォルダー F1。以下が含まれます。

  • ロボット アカウント R1、R2、R3

  • マシン テンプレート T1

• マシン テンプレート T1。ホスト マシン M1 および M2 に接続されています。

このシナリオでは、M1 と M2 の両方に、ロボット アカウント R1、R2、R3 と同じ資格情報を持つアカウントが定義されていることを確認する必要があります。こうすることで、オートメーションはどのロボットとマシンの組み合わせでも実行できます。

Active Directory との連携を使用したマシン テンプレート

最も粒度が高いグループに属するユーザーにはすべて、同じマシン設定をその特定のグループのメンバーとしてデプロイすることをお勧めします。たとえば、ユーザーがグループ AllUsers、ContactCenter、ContactCenter_ITIssues に属している場合、このユーザーは ContactCenter_ITIssues の他のユーザーと同じ設定を共有します。さらに、前述の他のユーザーと同じ Orchestrator マシン テンプレートも共有する必要があります。また、可能であれば既存の Active Directory 構造に従ってマシン テンプレートを作成することをお勧めします。

ライセンス - ランタイム

Unattended ロボットを使用して無人オートメーションを実行するには、専用のサービス ライセンスが必要です。これはランタイムと呼ばれ、無人プロセスの実行に使用するマシン オブジェクトに割り当てられます。このためには、以下の手順に従います。

1. テナント レベルで [マシン] にアクセスします。

2. 目的のマシンを選択して [その他のアクション]をクリックします。

3. [ランタイムの詳細] セクションで、数字を挿入するか、上矢印を使用して [Production (Unattended)] フィールドにランタイムの数を入力します。

マシン オブジェクトに割り当てられたランタイムの数は、そのマシン オブジェクトにアタッチされた各ホスト マシンでオートメーションを実行できる能力を表します。無人オートメーションに関しては、推奨されるマシン オブジェクトはマシン テンプレートです。

ランタイムはテナント レベルで割り当てられ、テナントのランタイム プールを構成します。ホスト マシンが UiPath Orchestrator に接続されると、そのマシンに関連するマシン オブジェクトに割り当てられたランタイムの数がテナント プールから取得されます。このランタイムは、マシン上でプロセスの実行中に消費されます。ホスト マシンを切断すると、ランタイムはテナント プールに戻ります。

例

例 1

3 つの Unattended ランタイムを割り当てるマシン テンプレートがあるとします。

• そのマシン テンプレートに 1 つのホスト マシンを接続すると、そのホスト マシン上で 3 つのオートメーションを実行できます。

• そのマシン テンプレートに 3 つのホスト マシンを接続すると、3 つのホスト マシンのそれぞれで 3 つ、合計 9 個のオートメーションを実行できます。

ランタイムをマシン テンプレートに割り当てる際は、マシン テンプレートが定義されているすべてのフォルダーで同時に実行される無人/テスト/非運用環境の実行をすべてカバーできる十分な数のランタイムを割り当ててください。このためには、すべての同時実行をカバーできる十分な数のマシンを接続する必要もあります。

例 2

以下が必要です。

• フォルダー A で同時に開始予定の 10 個の無人ジョブ

• フォルダー B で同時に実行予定の 5 つの無人ジョブ (フォルダー A で定義された 10 個のジョブと重複します)

• フォルダー A とフォルダー B の両方に割り当てられた 1 つのマシン テンプレート TemplateAB

続いて、15 個の Unattended ランタイムを TemplateAB に割り当てて、実際に 15 台の同じマシンを利用できるようにして TemplateAB のマシン キーに接続し、定義されているすべてのスケジュールで実行を可能にする必要があります。

上記のルールの唯一の例外はバックグラウンド プロセスです。バックグラウンド プロセスの場合、すべての同時プロセス実行に対応できる十分な数のランタイムをテンプレートに割り当てる必要がありますが、テンプレートに接続されているホスト マシンの数は限られています。バックグラウンド プロセスは同じマシン上で実質的にいくつでも実行できますが、一度に実行できるフォアグラウンド プロセス (UI が必要なプロセス) は 1 つだけであるからです。

例 3

10 個のバックグラウンド プロセスと 1 つのフォアグラウンド プロセスを同時に実行する場合、テンプレートに接続されているホスト マシンは 1 台だけで十分ですが、その特定のテンプレートには 11 個のランタイムが割り当てられている必要があります。ただし、2 つ目のフォアグラウンド プロセスを追加し、このプロセスを最初に定義したフォアグラウンド プロセスと同時に実行する必要がある場合や、最初のフォアグラウンド プロセスを 2 回同時に実行する必要がある場合は、フォアグラウンド プロセスの両方のインスタンスを実行できるようにするために、マシン テンプレートに接続された 2 つ目のマシンが必要になります。

利用可能なランタイムの完全なリストについては、UiPath ライセンス ポータルの「Robot Tiers」セクションをご覧ください。

プロセス

プロセスは Studio のオートメーション パッケージに基づいています。プロセスはフォルダーごとのリソースであり、プロセスがデプロイされたフォルダーでのみ実行できます。ただし、他のフォルダー内のプロセスからプロセスを開始できます。その条件は、特定のフォルダー内のユーザーが、目的のプロセスがデプロイされているフォルダーで必要な権限を持っていることです。

プロセスの種類

操作できるプロセスには、次の 2 つの種類があります。

• バックグラウンド プロセスには、ユーザー インターフェイスの操作や人間の介入は必要ありません。

• フォアグラウンド プロセスは、ユーザー インターフェイスから開始および/または管理する必要があり、一度に 1 つだけ実行できます。

注:

• このようなプロセスの各実行では、Unattended/NonProduction のランタイムが 1 つ消費されます。

• 複数のバックグラウンド プロセスと 1 つのフォアグラウンド プロセスを同時に実行できます。

プロセスの対応 OS

Studio でプロジェクトを作成するときに、開発者はオートメーション プロジェクトの基になるターゲット フレームワークと、対応するオペレーティング システムに影響を与える、相互運用性の属性を設定する必要があります。この設定は、Studio の [対応 OS] フィールドで設定します。

以下の表では、プロセスの実行に必要な Robot のバージョンをターゲット フレームワークおよび対応 OS 別に示します。

ターゲット フレームワーク	オペレーティング システム	Robot のバージョン
.NET Framework 4.6.1	Windows - レガシ	すべて
.NET 5.0+	Windows	2021.10+
.NET 5.0+	クロスプラットフォーム	2021.10+

マシン テンプレートの設定

マシン テンプレートには、このような対応 OS に関する考慮事項に合致する専用の設定があります。これにより、マシンを専用にしてリソースを最大限に活用できます。

Cloud ロボット

UiPath がユーザーに代わって Automation Cloud でロボット プールを管理できます。ユーザーが独自の関与レベルを選択することも、UiPath に割り当てた関与レベルを選択することもできます。

この機能のメリットを得るには、以下のいずれかの種類のマシンを作成します (テナント レベル > [マシン] > [マシンを追加])。

• エラスティック ロボット プール - UiPath がロボットを管理し、ユーザーは委託するオーケストレーション プロセスの量を決定します。

• Cloud ロボット - 仮想マシン - UiPath がオーケストレーション プロセスを処理し、オートメーションを実行する仮想マシンをユーザーに提供します。

• Cloud ロボット - サーバーレス - UiPath がインフラストラクチャとオーケストレーション プロセスの両方をユーザーに代わって処理します。この種類のロボットは Automation Suite でも利用できます。