[主にRPAユーザー向け] サービスとユーザーモードの違い

概要

ちょっとTwitterで見かけた嘆き（？）について。

元ネタ的にはUiPathの話題なのですが、UiPathに限らず、RPAを使う上では割と、「ユーザー」と「サービス」の対比とか、それに関連する挙動でひっかかる人が多いので、ちょっと記事をしたためようと思った次第です。

前提の話

　色々書きますが、知ってる感じの内容だったら読み飛ばしてください。

実行ユーザーの話

　Windowsでは¹アプリケーションを実行する際は、「どのユーザーの権限で実行するか」という要素が 必ず あります。
　もうちょっと深堀りすると、「アプリケーションを実行する」というのは、「プロセスを起動する（あるいはプロセスを開始する）」と言い換えられます。アプリケーションの実行は、１つ以上のプロセスで行われます。
　もっとも、複数のプロセスを手動で起動しなければいけないアプリケーション、というのはあまりなくて、最初に起動したプロセスが、必要なら別のプロセスを開始してくれる、といった形になるのが大半でしょう。
　あるいは「メモ帳」を複数起動したときのように、同じアプリケーションの複数のプロセスが、それぞれ無関係に起動する、といった使われ方もあります。

　さて、Windowsの場合、おおまかに「一般ユーザー」と「管理者ユーザー」があります。厳密にはもうちょっと種類が色々あるのですが、あえて無視します。

　ひらたく言ってしまえば、「管理者ユーザー」は、管理者権限に昇格 できる ユーザーです。「管理者権限がある」とかざっくり言っちゃうことが多いですが、管理者ユーザーでも、Windowsにログインして作業している分には、普段は「管理者権限を持たないユーザー」として振る舞います。
　では「昇格できる」というのが何かというと、

　これです。これで「はい」を押すと、対象のアプリケーションのプロセス（この場合は「メモ帳」）が、管理者権限に昇格します。
　昇格する対象は「プロセス」なので、ほかに「メモ帳」のプロセスを開いていても、そちらは影響しませんし、あとから別の「メモ帳」を起動しても、そちらも影響しません。

　なんでわざわざこんな動作をするか、というと、「普段から管理者権限で作業してると危ないから、本当に必要なときだけ確認ダイアログ出して、管理者権限が使えるようにする（昇格する）」だと思ってください。

サービスの話

　サービスも、アプリケーションの一種というか、1つの形態です。つまりプロセスから起動されます。
　ただし、一般のアプリケーションの起動と違いがいくつかあります。

• サービス専用のユーザー権限で起動する（SYSTEMとかLOCAL SERVICEとかNETWORK SERVICEとか）
• SYSTEMアカウントは最初から管理者権限に昇格している（確認ダイアログとかいちいち出さない）
• LOCAL SERVICEやNETWORK SERVICEは一般ユーザー権限で動作する
• OS起動時に自動的に起動される設定が可能（ユーザーがログインしてなくても動作できる）

　おおよそこんな感じです。ちなみに、Windows標準でも、OSの機能の一部はサービスとして動作しています。たとえば電源の管理だったり、Bluetoothデバイス接続だったり、プリンタとの連携だったり。
　なお、RPAのクライアントソフトをインストールしたときのサービスは、だいたいSYSTEMになってるはずです。

　そして、 サービスのインストールやアンインストール、設定変更には管理者権限が必要です。 システムに影響与えるものなので仕方ないですね。

　細かい手法は省きますが、有名どころのRPAソフトでいうと、UiPathやAutomation Anywhereは、クライアントアプリは、「管理者権限が必要なかわりに、サービスとしてインストールする」方法と、「管理者権限が不要で、サービスとしてはインストールしない」方法があるはずです。Blue Prismは管理者権限必須っぽいです。（この辺、バージョンとかでも変わってくるはずなので、実情と違ってたらごめんなさい）

ユーザーセッションの話

　あまり普段は意識しませんが、Windowsを使用する上で、デスクトップ画面であれこれする前段階として、2つのステップがあります。

1. OSが起動する
2. ユーザーがログインする

　「めっちゃ当たり前やん」と思うかもしれませんし、実際そうなのですが、少しだけ補足します。
　「ユーザーがログインする」というのは、別に使用者を縛ってる、すなわち認証をしているだけではなくて、「ユーザーとOSが対話する場所（セッション）を作成している」という操作も含まれています。
　アプリケーションが画面に何か描画したり、ユーザーからの入力を受け取るには、ユーザーセッションが必要です。
　これは一般ユーザー向けのWindows（Windows10とかWindows11とか）を使っているときはあまり意識しない要素なのですが、サーバー用途のWindows（Windows Server）だと、ユーザセッションを複数同時に使用できます。
　具体的には、リモートデスクトップで、複数のユーザーが接続している場合です。あるいは「サーバー端末に1人がログインして使用し、別のユーザーがリモートデスクトップで接続している」なんかもですね。ちなみに、物理的に接続されているモニタやマウス、キーボードを使っての作業を「コンソールセッション」、リモートデスクトップで接続するのと「リモートデスクトップセッション（あるいは縮めて「リモートセッション」）なんて呼びます。

　普通にPCを使っているなら直感的に理解できる部分ですが、パソコン（や、サーバー）に、モニタやキーボード、マウスを2個ずつ繋げても、Windowsを2人で同時に使うことはできません。つまり、コンソールセッションは最大で1つです。誰もログインしていなければ0個です。

　リモートデスクトップセッションは、一般ユーザー向け（Windows10とか略）では1ユーザーに限定されます。コンソールセッションと同居も基本的にはできません。
　サーバー用では、スペック的に許される範囲で、何ユーザーでも接続できます……が、接続数に応じてCAL(Client Access License)というライセンスがOSのライセンスとは別に必要²になります。

サービスには（普通は）ユーザーセッションはありません

　この記事を順番に読んでれば気が付くと思いますが、サービスは「OSが起動時に勝手に起動する」とかそんな感じのモノです。OS起動時はユーザーはログインしてません。つまりサービスはユーザセッションはありません。
　ちなみにセキュリティ的な理由等もあって、サービス用のユーザー（SYSTEMとかLOCAL SERVICEとかNETWORK SERVICEとかいうやつ）ではWindowsにログインできません。つまり、サービス起動後に後付けであっても、ユーザーセッションを持つことはありません。

　まあ、サービスを、組み込みの専用ユーザーではなく、デスクトップにログイン可能な管理者ユーザーの権限で動作させることも可能といえば可能なのですが、セキュリティ的に色々危なっかしいだけなので、そんな運用は普通はしないことと思います。
　というか、そんな設定を意図的にする理由がない限り、やるべきじゃないです。「なんとなく」やってる人がいたら、手近なマサカリで、ｶﾞｯと優しく投げつけてあげてください。

本題

　で、RPAの「サービスモード」と「ユーザーモード」の違いって、どこからくるの？って話をまとめます。

インストール形態の違い

　前述したように、軸となる部分では、

• サービスモードは管理者権限が必要、OS起動と同時に起動
• ユーザーモードは管理者権限が不要、ユーザーがログインしてないと動作できない
  　の違いがあります。

Robot実行方法の違い

　ここまで来て「あれっ？」と思った方がいるかもしれません。サービスモードで動作してるRPAアプリのサービスって、ユーザーセッションがないからRPAできないのでは？と。
　はい。そうです。なのでサービスモードで動作しているRPAアプリは、別途、以下の方法で、実際に画面操作などを行う（いわゆるデスクトップオートメーションをする）プロセスを立ち上げます。この辺はだいたい、どのRPAツールもやってることは同じです。

1. ユーザーセッションがなければ作る（管理サーバー等に登録されている認証情報を使う）
   • ユーザーの権限でリモートデスクトップセッションを作る（自分が動作しているPCにリモートデスクトップ接続でログインする）
   • ユーザー権限でコンソールセッションを作る（端末に直接ログインするのと同じ動作）
   • ユーザーセッションが画面ロックされていれば解除する
2. ユーザーセッション側で動作するアプリに、RPA機能の起動をさせる

　言うまでもなく、上記の流れで「1.」のプロセスは、画面ロック解除以外は、サービスでないと不可能です。一般ユーザー権限で動作する場合、ユーザーセッションが作成される前に、そのユーザーが使用するアプリを起動する、というのは順番的にあり得ないからです。
　RPAソフトのマニュアルには、「UnAttendedなRobotを動かすにはサービスでインストール云々」と注意書きがされている^{3 4}ことが多いですが、根本的な理由はここにあります。

余談：RPAプラットフォームごとのサービス名やプロセス名（の例）

　これ見たほうが使ってる人はピンとくるかも。でもバージョンとかで違ってる可能性もあるので、あくまで例として見てください。

	UiPath	Automation Anywhere	Blue Prism
サービス	UiPath Robot	Automation Anywhere Bot Agent	Blue Prism Login Agent
ユーザーセッション	UiPath.Agent UiPath.Service.UserHost	Zulu Platform x64 Architecture5	Automate6

インストール先の違い

　これはWindowsの仕様にも起因しますが、一般的なアプリケーションのインストール先として用意されている、Program Files（あるいはProgram Files (x86)）なフォルダは、書き込みに管理者権限が必要です。
　なので、ユーザーモードのインストーラーではインストールできません。代替として、ユーザープロファイル配下（一般的にはC:\Users\ユーザー名\）のAppDataの下のどこかにインストールされます。
　具体的には、Windowsの作法として、AppData\Local配下に置くべきで、大抵のソフトはそうなってますね。

　当たり前なんですが、ユーザープロファイルにある以上、それはユーザーに紐付きます。なので、ユーザーモードでのインストールはユーザーごとに必要になるし、ユーザーモードのフォルダにある実行ファイルを、サービスとして登録するのはあまり一般的ではありません。
　技術的にできないわけではなくて、SYSTEMアカウントであれば管理者ユーザーなのでユーザーフォルダにアクセスできる（≒実行はできる）けど、そんなピーキーな使い方しないよ、です。
　LOCAL SERVICEやNETWORK SERVICEは管理者権限がないので、ユーザー自身と管理者以外はアクセスできないユーザーフォルダ内のファイルにはアクセスできません。つまりサービスとして起動できません。

　この辺は、巡り巡って「ユーザーモードではUnAttendedな起動ができない」という話に、再び戻ってくる感じです。

まとめ

　いーからサービスモードでインストールしなさい。ユーザーモードでインストールするメリット、ほとんどないのよ。

　ね？

1. Windowsに限らず、大抵のOSでは同じような概念で動いてますが、とりあえず用語的にややこしくなるので、この記事ではWindowsの話に絞ってます ↩

2. RPAをリモートデスクトップセッションで動作させる場合も同時セッション数だけ必要になるから気を付けてネ ↩

3. UiPathドキュメント: Robot サービス ↩

4. Automation Anywhereドキュメント: デバイスの登録と Bot エージェント のインストール めっちゃわかりにくい。 ↩

5. これ自体はOpen JDKの汎用プロセス名なので、ほかのアプリとかでも見かけるプロセス名なのですが…… ↩

6. Attended的な環境がないので差分が見れない……違ったらごめんなさい。 ↩