Windowsのセッション分離をどう理解するか ── Session 0・RDP・複数ユーザー同時実行

「サービスから出したダイアログが誰にも見えない」「RDPで繋いだ途端、現地の画面がログイン画面に切り替わった」「多重起動防止のはずが、別ユーザーでログインしたら普通に2つ起動した」。業務アプリの相談では、こうした症状の裏に共通して「Windowsのセッション」という概念への理解不足があります。セッションは、サービスの設計にもリモートデスクトップ運用にも、名前付きオブジェクトの多重起動防止にも関わってくる横断的なテーマですが、体系的に説明された機会は少ないものです。

この記事では、Session 0分離がなぜ導入されたか、RDP接続時にセッションがどう振る舞うか、名前付きオブジェクトがセッションごとにどう分離されるか、そして共有PC・RDS(Remote Desktop Services)環境でよくある設計ミスを、実務目線で整理します。

1. まず結論

• サービスはSession 0という専用セッションで動き、ログオン中のユーザーの対話セッションとは分離されています。 サービスは直接ダイアログを表示できず、表示してもユーザーには届きません。¹
• UIが必要なサービスは、UIアプリを別プロセス(ユーザーのセッション側)に分離し、IPCで会話する構成が公式に案内されている解決策です。タスクスケジューラで対話ユーザーとして起動する方法も選択肢に入ります。²
• Windows Server(RDS)は複数の同時セッションを前提に作られていますが、Windows 10/11 Pro等のクライアントOSは基本的に単一セッションです。 Azure Virtual Desktop専用の「Enterprise マルチセッション」エディションを除き、通常のクライアントOSで同時に複数の対話セッションを持たせることは想定されていません。³
• 名前付きカーネルオブジェクト(Mutex、イベント、セマフォなど)にはセッションごとの名前空間があります。 マシン全体・セッションをまたいで1つに絞りたい場合は Global\ プレフィックスを明示しないと、思ったとおりに多重起動を防げません。名前付きパイプはこの仕組みの対象外で、既定でマシン全体から(サーバーサービス稼働時はリモートからも)アクセスし得る別の名前空間を使うため、セッションやユーザーで区別したい場合はパイプ名自体にセッションIDなどを含める必要があります。⁴⁵
• 現在のセッションの種別は SESSIONNAME 環境変数や GetSystemMetrics(SM_REMOTESESSION) で判定できます。ただしRemoteFX vGPU使用時など判定が本来の意図とずれるケースがあるため、過信は禁物です。⁶⁷
• 共有PC・RDS環境での動作を要件に含めるかどうかは、設計の初期段階で確認すべき事項です。 一時ファイルパスの衝突、AppDataの取り違え、デバイス・ドングルへの同時アクセスは、単独PC前提で作ったアプリがRDSに載った瞬間に噴出する典型的な事故です(第7章)。

2. Session 0分離とは何か ── なぜユーザーセッションと分けたのか

Windows Vista / Windows Server 2008より前は、サービスと最初にログオンしたユーザーが同じセッション0を共有していました。同じセッションのプロセス同士は、権限に関わらずウィンドウメッセージをやり取りできてしまいます。標準権限のプロセスが、SYSTEM権限で動くサービスの持つウィンドウへ細工したメッセージを送り込み、サービス側の処理を乗っ取って権限を昇格させる──ウィンドウメッセージ処理の欠陥を突くこの系統の権限昇格は、2000年代に繰り返し報告されており、実際にWindowsカーネルのウィンドウメッセージ処理(win32k.sys)の欠陥を突く権限昇格の脆弱性が何度も修正されています。⁸

Windows Vista以降はこの構図が変わりました。Session 0はサービスと、対話的なユーザーセッションに紐付かないアプリケーション専用になり、最初にログオンしたユーザーはセッション1、次のユーザーはセッション2……という形で、サービスとは別のセッションに割り当てられます。Session 0は対話操作をサポートせず、サービスからアプリへメッセージを送ることも、アプリからサービスへ送ることもできません。サービスがダイアログボックスなどのUI要素を直接表示することもできません。この変更により、標準権限のプロセスがサービスのウィンドウに直接メッセージを送り込むという経路そのものが構造的に塞がれました。¹

つまりSession 0分離は、単なる「サービスは裏方だから画面がない」という運用上の制約ではなく、権限境界をまたいだウィンドウメッセージのやり取りを構造的に遮断するためのセキュリティ設計です。サービスが唯一UIを出す手段として残されているのが WTSSendMessage 関数で、これは別セッションに簡易的なメッセージボックスを表示させるAPIですが、複雑なダイアログや双方向のやり取りには使えません。¹

3. サービスはUIを出せない ── 実務上の制約と回避パターン

Session 0分離の実務上の帰結はシンプルです。サービス内で MessageBox.Show やフォーム表示を呼び出しても、ログオン中のユーザーの画面には何も表示されません。それどころか、誰も押せないOKボタンを待ち続けて処理全体がハングする、という古典的な事故の原因になります。古いコード(Windows XP時代に「対話型サービス」として動いていたようなもの)をサービスとして移植する際は、UI表示の呼び出しが残っていないかを必ず確認してください。

公式に案内されている解決策は2つあります。²

• UIアプリを別プロセス(対話ユーザーのセッション側)に分離し、IPCで会話する。 サービス側で処理を起こし、結果や入力要求をUIプロセスへ渡す。UIプロセスは通知領域アイコンやダイアログとしてユーザーに見せ、操作結果をサービスへ返す。名前付きパイプなどのIPCを使う場合、ネットワーク越しに公開されないようACLを適切に設計する必要があります。複数ユーザーが同居する環境では、パイプ名にセッションIDを含めるなどしてセッションごとに区別する設計が案内されています。² IPC手段の選び方は、同日公開の姉妹記事「プロセス間通信の判断表」を参照してください。サービス自体の作り方や、開始の種類・実行アカウント・回復オプションといった運用面の設計は「Windowsサービスの作り方」にまとめています。
• タスクスケジューラで対話ユーザーとして起動する。 サービスとして常駐させる代わりに、ログオン中のユーザーの権限・セッションでUIを持つプログラムを起動する構成です。ここで注意が必要なのは、「SYSTEM で登録したタスク」自体は UI を出す側にしてはいけないことです。SYSTEM アカウントには対話的なログオン権がなく、SYSTEM 権限で実行されるプログラムやタスクをユーザーが見る・操作することはできません。⁹ 昇格タスクモデルは本来、標準ユーザーが起動できるセキュリティ記述子を持つ SYSTEM タスクに管理者権限が必要な処理だけを担わせ、UI 自体はログオン中ユーザーの権限・セッションで動く別のプログラム(または同じ処理をユーザーアカウントのタスクとして登録したもの)に持たせる、という役割分担が前提です。¹⁰ SYSTEM タスクを「UI 非表示のブローカー」に徹させ、可視 UI は必ずユーザー自身のセッションで動くプロセスに担わせてください。

いずれの方式でも、「サービスは裏方、UIは別プロセス」という前提を最初から設計に組み込むのが要点です。あとから追加しようとすると、サービス側にUI依存のコードが染み付いていて分離コストが跳ね上がる、というのが実務でよく見る展開です。

4. RDP接続時のセッションの挙動 ── RDSとクライアントOSの違い

「サーバーとクライアントで同じRDPなのに挙動が違う」という混乱は、Remote Desktop Services(RDS)ロールの有無に起因します。

Windows Server + RDSロールは、1台のサーバーに複数ユーザーが同時にログオンし、それぞれ独立したセッションでデスクトップやアプリを使う、複数同時セッションを前提とした構成です。¹¹ RDSでは、通常のRDP管理接続(管理者用)は2セッションまでCALなしで使えますが、それを超える台数や一般ユーザーの同時利用には、RD Session Hostロールの導入と適切なRDS CAL(クライアントアクセスライセンス)が必要です。¹² CALには per device / per user の2方式があり、ライセンスモデルの詳細は環境ごとに確認が必要です。¹³

一方、Windows 10/11 Pro・Enterprise等の通常のクライアントOSは、RDSロールを持たず、基本的に単一セッションを前提としています。「Windows Enterprise マルチセッション」という、複数の対話セッションを同時に持てるクライアントOS向けの特別なエディションも存在しますが、これはAzure Virtual Desktop専用として提供されるものであり、通常のオンプレミス配布のクライアントOSでは複数ユーザーの同時セッションは想定されていません。³ 実務上は、「RDPで社内の担当者のPCに繋いだら、現地の画面がロック画面に切り替わった」という体感どおり、クライアントOSではコンソール(現地の物理操作)とリモート接続が同時に共存する構成は基本的に成立しない、と理解しておくのが安全です。

業務アプリの設計で押さえておくべき違いをまとめます。

この違いを踏まえずに「開発機のクライアントOSで動いたから、共有サーバーのRDS環境でも同じように動くはず」と判断すると、第7章で挙げる複数ユーザー同時実行特有の不具合を見落とします。逆に、クライアントOS上での単一セッション運用しか想定しないなら、共有PC対応の設計コストを最初からかける必要はありません。この判断は要件定義の早い段階でしておくべきです(第8章)。

5. カレントセッションを判定する

自分のプロセスが今どのセッションで動いているかを知りたい場面は多くあります。バックグラウンド処理での重い描画エフェクトを抑制したい、リモートセッションでは帯域を使う機能を無効化したい、といった場合です。判定手段はいくつかあります。

• SESSIONNAME 環境変数: コンソールセッションでは Console、RDP接続では RDP-Tcp# から始まる名前が設定されます。qwinsta コマンドで一覧表示される SESSIONNAME 列と同じ情報です。¹⁴ 簡易的な判定に使えますが、公式APIではないため過度に依存しないほうが安全です。
• GetSystemMetrics(SM_REMOTESESSION): リモートセッションかどうかを判定するWin32 APIです。呼び出しプロセスがTerminal Servicesクライアントセッションに紐付いていれば非0を返します。ただしWindows 8/Server 2012以降、RemoteFX vGPUを使ったリモートセッションでは、この関数がリモートセッションをローカルセッションと誤認するという制約があります。その場合はレジストリの GlassSessionId と現在のセッションIDを比較する代替手段が案内されています。⁶⁷
• .NET(WPF)の SystemParameters.IsRemoteSession: GetSystemMetrics(SM_REMOTESESSION) を呼び出すのと同じ判定を、WPFアプリからプロパティとして取得できます。¹⁵ WinFormsやコンソールアプリではP/Invokeで直接呼ぶ形になります。
• WTSGetActiveConsoleSessionId: 物理コンソールに接続されているセッションIDを取得するAPIです。自分のセッションIDと比較すれば「自分は物理コンソールで動いているか」を判定できます。物理コンソールに誰も接続していない状態(遷移中)では 0xFFFFFFFF が返る点に注意してください。¹⁶

このWTSGetActiveConsoleSessionIdをRDS環境でのセッション特定に使ってはいけません。 名前のとおり返るのは「物理コンソールに接続されたセッション」だけで、RDP経由でログオンしているユーザーのセッションは対象外です。¹⁶ サービスが「対話ユーザーの companion UI をどのセッションに出すべきか」を知りたい場合、コンソール接続のユーザーだけを想定するならこの API で十分ですが、RDS で複数の RDP ユーザーが同時ログオンする環境では、WTSEnumerateSessions で稼働中のセッションを列挙するか¹⁷、セッション変更通知(WM_WTSSESSION_CHANGE)が渡してくるセッションIDをそのまま使うべきです。この取り違えは、RDP経由のユーザーにだけ通知UIが出ない・誤ったセッションに出る、という発見しにくい不具合の典型的な原因になります。第3章のIPC構成でUIプロセスをどのセッションに起動するかを決める際は、この区別を必ず意識してください。

6. 名前付きオブジェクトのセッション分離

Mutex、イベント、セマフォ、待機可能タイマー、ファイルマッピングオブジェクトといった名前付きカーネルオブジェクトには、セッションごとに独立した名前空間があります。あるセッションで MyAppMutex という名前のMutexを作成しても、別セッションから同じ名前で開こうとすると、それは別物として新規作成されます。サービスなど主にセッション0で動くプロセス、あるいは複数セッションをまたいでオブジェクトを共有したいクライアント/サーバー構成のために、Global\ を名前の先頭に付けることでグローバル名前空間に明示的に配置できます。逆に Local\ を付けると、明示的に自分のセッション名前空間に配置されます。⁴

これが実務で効いてくるのが、多重起動防止のためのMutexです。

• 「同じユーザーが同じセッション内でアプリを2つ起動できないようにしたい」だけなら、既定の(プレフィックスなしの)Mutex名で十分です。セッションごとの名前空間が自動的に効くため、別ユーザーのセッションでは別のMutexとして扱われます。
• 「RDS環境で複数ユーザーが同時にログオンしていても、マシン全体でアプリのインスタンスを1つに絞りたい」場合は、Global\ を明示しないと目的を達成できません。既定のままだとユーザーごとに1つずつ起動できてしまい、「多重起動防止のはずが複数起動した」という不具合になります。

なお、非session-0のプロセスがファイルマッピングオブジェクトやシンボリックリンクオブジェクトをグローバル名前空間に新規作成するには SeCreateGlobalPrivilege 権限が必要です(既存オブジェクトを開くだけなら不要)。この権限チェックはファイルマッピング・シンボリックリンクに限った話で、Mutexやイベントの作成には課されませんが、共有メモリ(メモリマップトファイル)をグローバル名前空間で使う設計では覚えておく必要があります。⁴

また、クライアント/サーバー型のアプリ全般に対する原則として、「1台のマシンからの接続」を「1つのユーザーセッション」と同一視しないことが案内されています。同じマシンから複数セッション(複数ユーザーのRDP接続)が同時に張られる可能性を踏まえ、サーバー側は ProcessIdToSessionId などでセッションを識別し、セッションごとに別の通信チャネルを用意する設計が推奨されています。¹⁸

7. 共有PC・RDS環境でありがちな設計ミス

単独PCのコンソール利用だけを想定して作られたアプリが、共有PCやRDS環境に載った途端に噴出する不具合には、いくつかの定番パターンがあります。

• 一時ファイルパスの衝突。 RDSは既定で、セッションごとに個別の一時フォルダー(ユーザーのプロファイル配下、セッションIDを名前に含む)を作成します。¹⁹ つまり %TEMP% 環境変数を素直に使っていれば、この分離の恩恵をそのまま受けられます。事故が起きるのは、%TEMP% を使わずに C:\Work\temp のような固定パスをアプリが決め打ちしている場合です。同じユーザーアカウントの複数セッション、あるいは複数ユーザーが同じ固定パスに同時書き込みすれば、当然ファイルの取り合いになります。
• AppDataの取り違え。 ユーザー設定・キャッシュ・ログをどこに保存するかは、Windowsのユーザープロファイルの仕組み(ローカル/ローミング、%LOCALAPPDATA% と %APPDATA% の使い分け)を理解したうえで決める必要があります。共有PCではこの設計の甘さが「他人の設定で自分の画面が変わる」「ログが上書きされる」という形で露見しやすくなります。詳細は「Windowsユーザープロファイル入門」を参照してください。
• デバイス・ドングル・シリアルポートへの同時アクセス前提。 RDSセッションからクライアント側のローカルデバイスやシリアルポートにアクセスするには、リダイレクション機構を経由します。物理USBドングルやシリアル通信の装置を使うアプリを、複数セッションから同時に使わせようとすると、そもそもハードウェア側が同時アクセスに対応していない、あるいはリダイレクトの設定次第で見えたり見えなかったりする、という問題に直面します。クライアント側にアタッチされたデバイスがサーバー側のセッションからどう見えるかは、リダイレクションの構成に依存するため、設計段階で確認が必須です。²⁰
• プリンター・ドライブの決め打ち。 既定のプリンター名やドライブレターをアプリ内にハードコードすると、ユーザーごとにリダイレクトされる既定プリンターやマップされたドライブが異なる共有PC環境では簡単に破綻します。プリンター名は実行時に取得し、ドライブは可能な限りUNCパスで扱うのが安全です。
• HKCU・ユーザーレジストリの読み違え。 HKEY_CURRENT_USER はセッションではなくログオンユーザーに紐付く点にも注意が必要です。同一ユーザーが複数セッションを持つ構成(RDSで同一アカウントを共有している等)では、HKCUの値は全セッションで共有されるため、「セッションごとに独立させたいランタイム状態」をHKCUに置くと、意図せず他セッションに影響します。セッションごとの分離が必要な情報は、第6章のセッション名前空間や、セッションIDを組み込んだファイルパスで扱うべきです。

これらはいずれも「単独PCなら気づかない」「複数ユーザーが同時に使って初めて発覚する」性質の不具合であり、テスト環境が単独PCの開発機だけだと本番の共有PC・RDS環境で初めて再現する、という展開になりがちです。

8. 判断表 ── 「共有PC/RDS対応」を要件に含めるべきか

共有PC・RDS環境での動作を要件に含めるかどうかは、実装が進む前の要件定義の段階で確認しておくべき事項です。含めると決めたら、次の観点をチェックリストとして使ってください。

判断の軸はシンプルです。「このアプリは、担当者1人のPCで完結して動けばよいか、それとも共有端末やRDS環境で複数の担当者が同時に使う可能性があるか」を、開発の初期段階で発注側と合意しておく。これを曖昧にしたまま実装を進めると、上記の観点をすべて作り直す羽目になります。

9. 実装例 ── セッション判定と名前空間の使い分け

第5章・第6章で紹介した判定方法とMutex命名の使い分けを、.NETのコードにまとめます。

using System.Runtime.InteropServices;

internal static class SessionInfo
{
    [DllImport("user32.dll")]
    private static extern int GetSystemMetrics(int nIndex);

    private const int SM_REMOTESESSION = 0x1000;

    // WPFアプリなら System.Windows.SystemParameters.IsRemoteSession が同じ判定を返す
    public static bool IsRemoteSession() => GetSystemMetrics(SM_REMOTESESSION) != 0;

    // 簡易判定。公式APIではないため、重要な分岐には使わずログ・診断情報向けに留める
    public static string? SessionName() =>
        Environment.GetEnvironmentVariable("SESSIONNAME");
}

多重起動防止のMutexは、「マシン全体で1つ」「セッションごとに1つ」「同じユーザーの複数セッションをまとめて1つ」の3通りを区別して名前空間を分けます。3つ目(ユーザー単位・セッション横断)は既定のGlobal\だけでは実現できず、名前にユーザーSIDを含める必要がある点は「Windowsアプリの多重起動防止」で詳しく扱っています。

// using System.Security.AccessControl; と using System.Security.Principal; が必要
// (NuGetパッケージ System.Threading.AccessControl も必要)

// 意図: RDS/共有PCで複数ユーザーが同時ログオンしていても、マシン全体でインスタンスは1つ。
// .NETのMutex/MutexAcl.Createは、既存のMutexを開く場合でも内部的にSYNCHRONIZE・
// MUTEX_MODIFY_STATEに加えDELETE/READ_CONTROL/WRITE_DAC/WRITE_OWNERまで要求する。
// そのため「認証済みユーザー」にはFullControl相当を許可しないと、作成者以外の
// 正規ユーザーがcreatedNew判定の時点でUnauthorizedAccessExceptionになってしまう。
// (代償として、認証済みの誰もが後からACLを書き換えられる状態にはなる。それも
// 許容できない場合はMutexクラスを使わず、P/InvokeでCreateMutexExを直接呼んで
// 必要最小限のアクセス権だけを要求する設計に切り替える)
//
// 注意: このACLは自分が先にMutexを作成できた場合にのみ適用される。固定名の
// Global\ Mutexは他ユーザーに先回りして作成(名前スクワッティング)される
// リスクがあり、その場合はcreatedGlobalがfalseになる、あるいは相手のACL次第で
// UnauthorizedAccessExceptionになる。真に締め出したいなら推測困難な名前や
// 別の排他制御と組み合わせること(詳細は姉妹記事の第5章を参照)
var globalMutexSecurity = new MutexSecurity();
globalMutexSecurity.AddAccessRule(new MutexAccessRule(
    new SecurityIdentifier(WellKnownSidType.AuthenticatedUserSid, domainSid: null),
    MutexRights.FullControl,
    AccessControlType.Allow));

using var globalMutex = MutexAcl.Create(
    initiallyOwned: false,
    name: @"Global\KomuraSoft.MyApp.SingleInstance",
    createdNew: out bool createdGlobal,
    mutexSecurity: globalMutexSecurity);

// 意図: セッションごとに1つあればよい(同じユーザーの複数セッションはそれぞれ別扱いでよい)。
// 既定のセッション名前空間のままでよい
using var perSessionMutex = new Mutex(
    initiallyOwned: false,
    name: "KomuraSoft.MyApp.SingleInstance",
    createdNew: out bool createdPerSession);

if (!createdGlobal)
{
    // 他のセッションを含め、マシン上のどこかで既に起動している
    return;
}

Global\ を付けたMutexの作成自体には特別な権限は不要です(前述のとおり、権限チェックが課されるのはファイルマッピングオブジェクトとシンボリックリンクオブジェクトの新規作成に限られます)。⁴ 「ユーザーごとに1つ」を意図して既定のセッション名前空間のまま使うのは誤りです。同じユーザーが切断済みRDPセッションと新しいコンソール/RDPセッションを両方持つ状況は珍しくなく、その場合セッションごとに別のMutexとして扱われるため、既定のままでは同じユーザーが2つ目のインスタンスを起動できてしまいます。「マシン全体で1つ」「セッションごとに1つ」「ユーザーごとに1つ(セッション横断)」のどれが要件として正しいかは、アプリの性質によって決まるので、命名の前にまず要件を確認してください。

10. まとめ

Windowsの「セッション」は、サービス設計・リモートデスクトップ運用・名前付きオブジェクトの多重起動防止という一見バラバラな話題に共通して顔を出す概念です。押さえるべき骨格は3点に集約できます。サービスはSession 0という隔離された特別なセッションで動き、UIを直接出せないこと。RDSは複数同時セッションを前提に作られている一方、通常のクライアントOSは単一セッションが基本であること。そして名前付きオブジェクトにはセッションごとの名前空間があり、意図に応じて Global\ の要否を判断する必要があること。

共有PC・RDS環境での動作を要件に含めるかどうかは、実装の後半で気づくと手戻りが大きいテーマです。要件定義の段階で「このアプリは誰が、どの端末で、何人同時に使うか」を確認しておくことを強くおすすめします。既存アプリを共有PC・RDS環境へ展開する計画がある、あるいは「複数ユーザーで使うと様子がおかしい」という不具合の原因調査が必要な場合は、実際の構成を見ながら切り分けたほうが早いことが多いので、ご相談ください。

関連記事

• Windowsサービスの作り方 ── Worker Serviceガイド
• Windowsのプロセス間通信をどう選ぶか ── 判断表
• Windowsアプリの多重起動防止 ── 名前付きMutexと二重起動時のアクティブ化
• Windowsユーザープロファイル入門 - AppDataとNTUSER.DAT
• Windowsアプリで「管理者権限が必要な処理だけ」を分離する具体的な書き方

関連する相談領域

合同会社小村ソフトでは、共有PC・RDS環境への展開を見据えたWindowsアプリの設計レビュー、サービス化・IPC分離の設計、複数ユーザー同時利用時特有の不具合の原因調査を扱っています。

• 技術相談・設計レビュー
• Windowsアプリ開発
• 既存Windowsソフトの改修・保守
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。