RDP画面を人が開いている間だけ動くUiPathプロセスを、セッション切断後も確実に動かす解決策は、入力方式のチェックを変えることではなく、UiPath RobotをService Modeで導入し、OrchestratorからUnattendedジョブとして実行することです。ジョブ開始時にRobot Serviceが対象マシン上でコンソールまたはRDPのWindowsセッションを作成・利用し、その中でRobot Executorを起動します。Unattended runtime、machine template、robot account、Windows資格情報を正しく構成すれば、運用者が手動RDPを接続し続ける必要はありません。
なぜ手動RDPの切断で止まるのか
画面上のボタンや文字を操作するForeground Automationは、対話可能なWindowsセッション、解像度、ログオンユーザー、デスクトップ状態に依存します。開発者がRDPでログオンしてUiPath AssistantやStudioから実行しただけの構成では、その人の対話セッションを切断・ログオフしたときに画面要素が利用できず、クリック、画像認識、キーボード入力が失敗することがあります。
「Simulate」や「Window Messages」は対象アプリが対応していれば人の入力イベントへの依存を減らせますが、Windowsセッション、アプリのログオン、画面解像度、UAC、資格情報まで不要にする設定ではありません。アクティビティ単位の入力方式は補助的な互換性設定として検証し、Unattended基盤の代わりにはしません。
利用できるエディションとライセンスを確認する
UiPathのUnattended実行には、対象提供形態で利用可能なOrchestratorと、マシンへ割り当てるProduction（Unattended）またはTesting等のruntimeが必要です。UiPath公式では、一つのruntimeで同時に一つのUnattended Automationを実行し、割り当て数が同時実行上限になります。Attendedのユーザーライセンスだけでは、同じ構成のUnattended実行にはなりません。
Automation Cloud、Automation Suite、Standalone Orchestratorでは画面やライセンス名、利用可能なRobot種類が異なります。この記事の設定名は現行のAutomation CloudとStandalone Robot公式資料を基準にしています。自組織の契約、Orchestratorの版、Robotの版、Windows ServerまたはWindowsクライアント、High-Density Robotの利用有無を先に台帳化し、同じ版の公式ページで再確認します。
- Orchestratorへ接続できるUiPath Robotが対象マシンにService Modeでインストールされている。
- machine templateが作成され、対象ホストがそのテンプレートへ接続されている。
- machine templateへ必要数のUnattended runtimeが割り当てられている。
- robot accountまたは実行ユーザーにUnattended機能が設定され、process、machine、accountが同じfolderで利用可能である。
- 実行するWindowsアカウント、ドメイン、パスワード、対話ログオン権限、対象アプリの権限が正しい。
- Windows、UiPath Robot、対象アプリのライセンスが無人実行と同時接続数を許可している。
Service Mode Robotを前提にする
UiPathStudio.msiのQuick SetupなどでUser Mode Robotを入れた環境では、Robotはそのユーザーの権限とログオン状態に依存します。UiPath公式のUnattended構成では、Service Mode Robotを使い、Robot ServiceがLocal Systemで動作してOrchestratorからの指示を受け、対象ユーザーのWindowsセッションを管理します。既存環境を入れ替える場合は、Robot設定と接続情報をバックアップし、保守時間に公式インストーラーで構成します。
サービスアカウントだからDomain Adminが必要ということではありません。対象アプリ、ファイル共有、ブラウザー、証明書ストア、業務システムへ必要な最小権限を付与し、RDPによる対話ログオンや「サービスとしてログオン」など必要権限をセキュリティ担当と確認します。管理者権限を付けて症状を隠すのではなく、失敗ログから不足権限を特定します。
Orchestrator側の実行要素をそろえる
machine templateは実行能力を表し、そこへUnattended runtimeを割り当てます。対象ホストはmachine keyまたはclient credentialsでOrchestratorへ接続します。process、machine template、robot accountが同じfolderで見えるよう割り当て、Automation User等の必要なfolder roleを確認します。folderがずれていると、接続済みでもジョブが利用可能なマシンやアカウントを見つけられません。
実行アカウントのUnattended setupでは、環境に応じて既定のVM Windowsアカウントまたは特定のWindowsアカウントを選び、DomainUsernameとPasswordを登録します。資格情報はOrchestratorまたは統合したcredential storeで管理し、XAML、Config.xlsx、スクリプト、Robotログへ平文保存しません。パスワード変更時の更新責任者と試験手順も決めます。
Login To Consoleの意味
UiPath公式のWindows sessionsによると、RobotはOrchestratorのLoginToConsole設定に基づきコンソールまたはRDPセッションを使います。Tenant→Manage Access→Robot accounts→Robot Settingsで「Login To Console」を明示的に設定します。設定スイッチ自体が無効表示でも既定はコンソール実行と説明されているため、意図した方式を明文化して確認します。
Yes：コンソールセッション
Login To Consoleを有効にしてYesを選ぶとコンソールセッションを使います。ホストの表示解像度に依存する自動化や、一台で順番に実行する構成に向きます。アクティブなRDPセッション中にOrchestratorジョブが開始すると、そのRDPセッションは自動的に終了すると公式資料にあるため、保守担当が同じマシンへ接続中の時間帯を避けます。アクティブなコンソールセッションは一つだけです。
No：RDPセッション
Login To Consoleを有効にしてNoを選ぶと、RobotはRDPセッションを使います。カスタム解像度を指定したい場合や、Windows Serverで複数ユーザーのセッションを使う場合の候補です。ジョブ開始時に既存のRDPセッションがあれば、そのセッション内でジョブを実行します。運用者の手動RDPとRobotの実行が衝突しないよう、専用アカウントと接続禁止時間を決めます。
High-Density RobotsはRDPセッションだけを使います。同じユーザーの複数RDPセッションではHardware eventsに依存するUI Automationに制約があるため、入力方式とアプリ互換性を実機で検証します。コンソールとRDPのどちらが正しいかはタイトルだけでは決まらず、対象アプリの表示、解像度、同時実行、Windowsライセンスで選びます。
手動RDPを切断した状態でのテスト
- 本番データを使わないテストprocessをpublishし、専用テストfolder、machine template、robot accountへ割り当てる。
- Windows資格情報が有効で、対象アカウントがロックされておらず、対象アプリへログオンできることを確認する。
- Login To ConsoleをYesまたはNoへ明示し、解像度、色深度、タイムアウトをprocess要件に合わせる。
- 運用者のRDPからログオフするのではなく、まずOrchestratorからジョブを開始し、UiPathが作った実行セッションとJobログを確認する。
- ジョブ完了後に手動RDPを切断した状態で次のジョブを起動し、同じ結果になることを確認する。
- 成功、業務エラー、アプリ停止、パスワード期限切れ、マシン再起動、通信断を順に試し、回復方法を記録する。
期待する状態は、OrchestratorのJobがPendingからRunningへ進み、対象マシン上に指定Windowsユーザーの実行セッションが作成または再利用され、Robot Executorがそのセッション内で動くことです。人のRDPクライアントが接続中である必要はありません。完了後のセッションがログオフされるか切断状態で残るかはRobot設定とWindowsポリシーに依存するため、セッション一覧とログで確認します。
RDS時間制限との衝突を確認する
RD Session Hostの「アクティブ」「アイドル」「切断済み」セッション時間制限が短いと、UiPathが作成したRDPセッションや長時間ジョブへ影響する場合があります。対象マシンのGroup Policy ResultsでTerminalServer.admxの時間制限を確認し、ジョブ最大時間、無入力時間、再試行時間より短くないかを検証します。制限を全体で無効にせず、専用Robot OUとセキュリティ要件を合意します。
Windowsの画面ロック、スクリーンセーバー、同時ログオン制限、既存RDP、保守担当のコンソール接続も競合候補です。UiPath実行中に人が同じアカウントへRDP接続すると、解像度変更、フォーカス移動、セッション切替でUI操作が失敗します。Robot専用アカウントを人の保守アカウントと分け、ジョブ中の接続ルールを定めます。
資格情報とOrchestratorを安全に運用する
Windowsパスワード、machine key、client secret、業務アプリのIDをメールや手順書へ平文で残しません。Orchestratorのcredential store統合、Asset、ロボットアカウントの資格情報設定を使い、閲覧・編集できるroleを最小化します。スクリーンショット、SessionScreenshots、Robotログ、失敗時の例外メッセージに秘密が写らないかも確認します。
パスワード期限、ロックアウト、退職・異動、証明書更新、MFA要件を無人アカウントのライフサイクルへ組み込みます。対話MFAを毎回要求するアプリは、そのままでは無人実行できない場合があります。MFAを無効化するのではなく、サービスアカウント、OAuth、証明書、APIなど製品が公式に提供する無人認証方式を採用します。
失敗したときの読み方と回復
JobがPendingのままならruntime、folder、machine接続、account割当を確認します。Startingで失敗するならWindows資格情報、対話ログオン、既存セッション、RDSポリシーを確認します。Running後にSelectorや画像認識で失敗するなら、解像度、表示倍率、アプリ状態、入力方式、ポップアップ、既存RDPの競合を調べます。段階を分けることで、資格情報とUI Automationを混同しません。
Windowsセッション作成に失敗した場合、UiPath Robot Serviceはセッション準備中のスクリーンショットを取得し、成功時は削除、失敗時は%ProgramData%UiPathSessionScreenshotsへ保存すると公式資料にあります。アクセス権を限定して原因確認に使い、画面に個人情報やパスワードが写る可能性を考慮して、解決後は組織の証跡保持規程に従います。
切戻しと本番移行の合格条件
Unattended化で業務結果が変わる、有人時より誤操作が増える、資格情報管理が確立できない場合はトリガーを無効化し、対象processのUnattended実行を停止します。元の有人process版と設定を保存しておき、利用者が監視する手順へ戻します。runtimeやmachineを削除して証拠を失わず、Jobログ、Robotログ、対象アプリの監査ログを保全して原因を調べます。
本番移行は、手動RDP未接続で連続実行できること、コンソールまたはRDPの選択理由が文書化されていること、資格情報が保護されていること、RDS時間制限と競合しないこと、アプリ異常時に安全停止できること、再実行が二重登録を起こさないことを条件にします。これで「切断後に動く」は偶然のセッション維持ではなく、UiPathが管理する再現可能なUnattended運用になります。
公式情報・参考資料
以下は2026年7月17日時点で確認した公式一次資料です。画面名や仕様が変わる可能性があるため、実作業の直前にも対象ページを確認してください。
コメント
コメント一覧 （3件）
コメント失礼します。
こちらの方法でクリックなどの操作はセッションを切断しても行ってくれるようになりました。
しかし現在、スクリーンショットを作成しExcelへ貼り付ける際のメソッド呼び出しで止まってしまいます。
エラー内容を分析した所どうやら変数の中身が空のようでした。セッションを開いた状態で実行した際は問題なかったのですが、、何か解決策等ありますでしょうか？
スクリーンショットは難しいと思います。
スクショは基本的にディスプレーに表示されている情報を取得するので難しいかと。
画面を閉じた状態でのスクリーンショットは難しそうです。。。