Windows Server 2019で、作業中のセッションを残したまま別ユーザーでログオンしたい――そんなときにrunasを試しても、起動できるのはアプリ単位で「デスクトップ全体」は切り替わりません。本記事では“できない理由”と、現場で使える代替手段を整理します。
「サインアウトせずに別ユーザーへ切り替えたい」の正体
まず前提として、ここで言う「切り替え」にはいくつか種類があります。Windows Server 2019で困りやすいのは、次のようなケースです。
- いまログオンしているユーザーの作業（エディタ、ブラウザ、管理ツール、開発環境など）を閉じたくない
- しかし別ユーザー（例：管理用アカウント、別ドメイン、別権限）として同じサーバーで操作したい
- できればコマンドプロンプトから実現したい
runasは「アプリを別ユーザーで起動」できるが、OS全体（Explorer、デスクトップ、スタートメニュー）まで入れ替わらない
結論から言うと、「同じログオンセッションのまま、ユーザーだけを入れ替える」ことはできません。できるのは、別セッションとして別ユーザーでログオンするか、アプリ単位で別ユーザーとして起動するか、どちらかです。
結論：同じセッションを“別ユーザーに変換”する方法はない
Windowsのログオンは「ユーザー＋セッション（ログオンセッション）」として管理されます。ログオンすると、そのユーザー用の次の要素が一式そろい、以後はその枠組みの中でプロセスが動きます。
- ログオンセッション（セッションID）
- ユーザープロファイル（例：
C:\Users\ユーザー名） - ユーザーごとのレジストリハイブ（HKCU）
- アクセス・トークン（権限、所属グループ、資格情報、整合性レベルなど）
- デスクトップ/ウィンドウステーション、Explorer（シェル）
ここで重要なのは、Explorerやデスクトップ環境は「そのユーザーのプロファイルとトークン」を前提に起動されることです。途中からユーザーだけを差し替えると、権限もプロファイルもレジストリも“入れ替え途中”になり、整合性が保てません。だからWindowsには「いまのセッションを別ユーザーへ変換する」公式コマンドが存在しません。
一方で、Windows Serverはもともと複数ユーザーの同時ログオン（複数セッション）を前提に設計されています。つまり「切り替える」のではなく、別セッションを追加して使い分けるのが正攻法です。
目的別に最適解を選ぶ（最短で迷わないための整理）
同じ「切り替えたい」でも、目的によって最適解が変わります。まずは要件を分類すると判断が早くなります。
| やりたいこと | おすすめの方法 | 向いている場面 | 注意点 |
|---|---|---|---|
| いまの作業を残したまま、別ユーザーでログオンしたい | セッション切断（tsdiscon）→ログオン画面で別ユーザー | 同一サーバーで「ユーザーAの作業を残しつつ、ユーザーBで作業」したい | セッションが残り続けるため、メモリ消費やロック中のファイルに注意 |
| 別ユーザーで“別のデスクトップ”を開きたい | RDPで別ユーザー接続（別セッション） | 管理用アカウントを分けたい、複数人で管理したい | 既定は管理目的の同時接続に上限がある（後述） |
| 特定の管理ツールだけ別ユーザーで動けば十分 | runasでアプリを別ユーザー起動 | MMC、PowerShell、管理コンソールだけ別権限で動かしたい | Explorerやデスクトップ全体は切り替わらない |
| 不要になったセッションを整理したい | query session / logoff で確認・終了 | 切断セッションが溜まって接続できない、リソースが苦しい | logoffは強制終了なので、対象ユーザーの作業が消える |
代替策：サインアウトせずに「切断」してログオン画面へ戻す（tsdiscon）
「サインアウトはしたくないが、別ユーザーにログオンしたい」という要件に最も近いのが、セッションを切断（Disconnect）してログオン画面に戻す方法です。切断はログオフではないので、アプリや作業状態が残ります。
ロック・切断・サインアウトの違い
| 操作 | セッション | アプリ/作業 | よく使う場面 |
|---|---|---|---|
| ロック（例：Win+L） | 維持（同一セッションがロック状態） | 残る | 席を外す、同じユーザーで戻る前提 |
切断（tsdiscon） | 維持（切断状態） | 残る | 作業を残したまま別ユーザーでログオンしたい |
| サインアウト（ログオフ） | 終了 | 終了（保存していなければ失う） | 作業を終えた、セッションを解放したい |
自分のセッションを切断する（もっともシンプル）
いま操作しているセッションで、コマンドプロンプト（または管理者権限のコマンドプロンプト）を開き、次を実行します。
tsdisconこれでサインアウトせずにセッションが切断され、ログオン画面に戻ります。そこから別ユーザーでログオンすれば、別セッションが開始されます。
サーバー上のセッション一覧を確認する（query session / qwinsta）
切断を管理的に扱いたいときは、まずセッション状態を把握します。標準コマンドで確認できます。
query session
qwinsta出力例（環境により表示は異なります）
SESSIONNAME USERNAME ID STATE TYPE DEVICE
services 0 Disc
console userA 1 Active
rdp-tcp#3 adminB 3 DiscSTATEがDiscになっていれば、そのユーザーはサインアウトせず切断状態で残っています。サーバーの負荷が高い、接続枠が足りないといったときは、この切断セッションが溜まっていないか確認するのが定番です。
特定のセッションIDを切断する（管理者向け）
自分のセッションではなく、特定のセッションを切断したい場合は、IDを指定します。
tsdiscon 3ただし、他人のセッションを切断すると「操作していた人は強制的にログオン画面へ戻る」ことになります。作業が止まる可能性もあるため、運用ルール（連絡、メンテ時間、管理手順）を決めてから使うのが安全です。
切断したセッションに戻るには？
「切断」はログオフではないので、同じユーザーでログオンすれば、通常はそのユーザーの切断セッションへ再接続されます（同一ユーザーで同一サーバーに再ログオンすると、既存セッションに再接続される挙動が一般的です）。
- ローカルコンソール：ログオン画面で同じユーザーを選んでログオン
- RDP：同じユーザーで同じサーバーへ接続
ただし、ポリシー設定やRDS構成によって挙動が変わることがあります。運用環境で「同一ユーザーの再接続が既存セッションに戻るか」は事前に確認しておくと安心です。
代替策：別セッションとして別ユーザーでログオンする（RDPが基本）
「OS全体（デスクトップ環境ごと）を別ユーザーで使いたい」なら、答えはシンプルで、別ユーザーでログオン＝別セッションです。Windows Serverでは、1台のサーバー上に複数の対話型セッションを並行して持てます。
RDSなし（既定状態）の同時接続は“管理目的の範囲”
Windows Serverを素の状態で使う場合、リモートデスクトップは管理目的（Remote Administration）として提供されます。一般的な運用では、同時に使える管理者用セッションは基本的に2つという理解で問題ありません。ここを超えて「複数ユーザーが同時に常用する」用途にする場合は、後述のRDSを検討します。
RDP接続の基本（GUIからでもコマンドからでも）
接続元PCで「リモートデスクトップ接続（mstsc）」を起動し、サーバー名/アドレスを指定して接続します。コマンドで起動するなら次のとおりです。
mstsc管理用途として接続したい場合、状況により/adminオプションを使うことがあります。
mstsc /admin/adminは「管理用セッションで接続したい」という意図で使われることが多いオプションです。ただし運用やポリシーによって扱いが変わるため、チーム内で「いつ使うか」を決めておくと混乱しません。
「接続できない」よくある原因と対処
別ユーザーで接続しようとして弾かれるときは、原因がだいたい決まっています。
- 同時接続枠が埋まっている（切断セッションが残っている、別の管理者が利用中）
- リモートデスクトップが無効、またはWindowsファイアウォール/ネットワークで遮断されている
- ログオンを許可されていない（「リモートデスクトップユーザー」グループ未参加、ローカルセキュリティポリシー/グループポリシー）
まずはサーバー側でセッションを確認します。
query session不要な切断セッションが溜まっている場合、最終手段としてlogoffで終了させます。
logoff 3注意：logoffは対象ユーザーの作業を強制終了します。事前連絡ができない状況（障害対応など）でも、できるだけ影響範囲を把握してから実行してください。
RDS（Remote Desktop Services）が必要になるライン
「管理目的の2セッション」では足りず、複数ユーザーが日常的にログオンして使う、あるいはアプリ提供のためにセッションホストとして使う場合は、RDS（Remote Desktop Services）の役割追加と、環境に応じたRDS CAL（クライアントアクセスライセンス）が必要になります。
ここは構成やライセンス形態によって要件が変わるため、最終的にはMicrosoftのライセンスガイドや販売店・担当者と確認するのが確実です。記事としては「管理目的の範囲を超えて常用するならRDSが必要になる」という判断軸を押さえておけば、実務上の誤解を避けられます。
| 使い方 | 想定 | 必要になりやすいもの | 例 |
|---|---|---|---|
| サーバー管理（障害対応、設定変更、ログ確認） | 少人数の管理者が短時間利用 | 既定の管理用RDPで足りることが多い | 運用担当が交代で入る |
| 業務端末のように日常利用 | 複数ユーザーが長時間ログオン | RDS役割＋RDS CAL | アプリ配信、VDI的な運用 |
| アプリを公開して複数人が利用 | リモートアプリ/セッションホスト | RDS（RD Session Host等）＋CAL | 会計ソフトをサーバーで実行 |
代替策：アプリだけ別ユーザーで起動する（runasの正しい使いどころ）
「別ユーザーでデスクトップ全体を使いたい」場合はセッションを分けるのが正解ですが、実際の運用では「管理ツールだけ別権限で動けばいい」ことも多いです。そのときに有効なのがrunasです。
runasでできること・できないこと
- できる：指定したプログラムを、別ユーザーの資格情報で起動する
- できない：いまのデスクトップ環境（Explorer）を別ユーザーに“切り替える”
代表的な使い方は次のとおりです。
runas /user:DOMAIN\adminUser "mmc.exe compmgmt.msc"
runas /user:DOMAIN\adminUser "powershell.exe -NoProfile"
runas /user:SERVER\localAdmin "cmd.exe"入力するユーザー名は、ドメイン環境ならDOMAIN\user、ローカルならSERVER\userや.\user（環境により）を使うのが定番です。実行するとパスワード入力が求められます。
ネットワーク先だけ別資格情報で使いたいなら /netonly
ローカルの実行権限はそのままで、ネットワークアクセスに使う資格情報だけを変えたい場面では/netonlyが役に立つことがあります。
runas /netonly /user:DOMAIN\adminUser "cmd.exe"ただし挙動は用途により直感とズレやすいので、「どのアクセスがどの資格情報で行われているか」を理解した上で使うのが安全です。
/savecredは便利だが運用には注意
runas /savecredはパスワード入力を省略できて便利に見えますが、資格情報の扱いはセキュリティに直結します。共用サーバーや複数管理者が触る環境では、安易に常用しないほうが無難です。どうしても必要なら、利用範囲・端末・アカウント・監査方針まで含めてルール化しましょう。
| オプション | 意味 | 使いどころ | 注意点 |
|---|---|---|---|
/user: | 別ユーザーを指定して起動 | 管理ツールを管理者アカウントで開く | Explorer全体は切り替わらない |
/netonly | ネットワーク認証だけ別資格情報 | 別ドメイン/別アカウントで共有へアクセス | ローカル権限は変わらない |
/savecred | 資格情報を保存して以後省略 | 限定的に許可された運用 | セキュリティ設計が必要 |
「切り替えできない」と感じる原因になりがちなポイント
runasでExplorerを起動すれば“ユーザー切り替え”になる？
なりません。Explorerは単なるファイルマネージャではなく、タスクバーやスタートメニュー、デスクトップなどを司るシェルです。既存のシェルが動いている状態で別ユーザーとしてExplorerを起動しても、思ったようにデスクトップ全体が入れ替わるわけではありません。仮にそれっぽく見えても、実態は「既存セッション上で別トークンのプロセスを混在させている」だけなので、運用上の事故につながりやすいです。
切断セッションが増えると何が困る？
切断は便利ですが、残り続ける以上コストがあります。
- メモリやCPUなどのリソースを消費し続ける（アプリ次第では顕著）
- ファイルやDB、管理ツールのロックが残る
- 同時接続枠が埋まり、緊急時に管理者が入れない
「作業を残すための切断」は、必ず「作業が落ち着いたらログオフして解放する」までセットで運用するとトラブルが減ります。
“切断しても戻れない”ときに確認すること
基本は同一ユーザーで再接続すれば戻れますが、戻れない場合は次を疑います。
- 別の管理者が
logoffでセッションを終了した - ポリシーで「切断セッションのタイムアウト」が設定され、自動ログオフされた
- サーバー再起動や更新でセッションが消えた
- 同一ユーザーの複数セッションを許可する設定になっており、新規セッションが作られた
特にグループポリシーで「切断後○分でログオフ」などが設定されていると、想定より早くセッションが消えることがあります。セキュリティ要件と利便性のバランスを見て設定しましょう。
現場でおすすめの運用パターン
「切り替えできない」を根本から楽にするには、アカウントと作業の分離を意識すると効果的です。
パターンA：普段用アカウント＋管理用アカウントを分ける
普段の作業（ログ閲覧、軽い調査、資料作成）と、管理権限が必要な作業（サービス再起動、設定変更、インストール）を同じアカウントでやると、どうしても「切り替えたい」場面が増えます。
- 普段は権限を絞ったアカウントでログオン
- 必要なときだけ
runasで管理ツールを別ユーザー起動 - セッションを分ける必要があるときは、RDPで管理用アカウントで別セッション
この形にすると、最小限の“切り替え”で済み、監査や事故対応でも追跡しやすくなります。
パターンB：障害対応時だけtsdisconで作業を保全する
障害対応では「いま見ているログ」「開いている監視ダッシュボード」「調査中のメモ」を残したまま、別ユーザーで別の操作をしたいことがあります。こういうときにtsdisconは強力です。
- 状況を残したまま切断して退避
- 別ユーザーでログオンして必要な復旧作業
- 落ち着いたら元セッションに戻り、記録をまとめてからログオフ
切断を常用しすぎるとセッションが溜まるので、「非常時の保全手段」として位置付けると運用が崩れにくいです。
パターンC：同時利用が前提なら最初からRDSを設計に入れる
そもそも複数ユーザーが同時にログオンして使う設計なら、「管理用2セッション」の枠で無理に運用しないほうが安全です。RDSの役割やCAL、セッション制御（タイムアウト、再接続、プロファイル管理）まで含めて設計すると、ユーザー切り替えの悩みが根本から減ります。
よくある質問
コマンドだけで“Windowsのユーザー切り替え画面”を出せますか？
切断してログオン画面に戻すという意味なら、tsdisconが最も近い手段です。ロック画面を出したいだけなら、環境によってはロックコマンド（例：rundll32.exe user32.dll,LockWorkStation）も使えますが、「別ユーザーで新規ログオンする」目的なら切断のほうが分かりやすいでしょう。
「別ユーザーでログオンしたいだけ」なら、切断とRDPのどちらが良い？
同じマシンの画面（コンソール）を使う前提なら切断が手軽です。一方、管理者が別端末から作業する、複数人で並行作業するならRDPで別セッションが基本です。
切断したセッションを放置すると危険ですか？
アカウントがロックされていれば即危険とは限りませんが、リソースや運用面のリスクは確実に増えます。特に共有サーバーでは「切断セッションの棚卸し」と「不要セッションのログオフ」を運用に組み込むのがおすすめです。
まとめ：Windows Server 2019での“現実的な切り替え方”
- 同じログオンセッションのままユーザーだけを入れ替えることはできない
- 作業を残したいなら、
tsdisconで切断→ログオン画面から別ユーザーが最短 - デスクトップごと別ユーザーで使うなら、別セッションとしてRDPログオンが正攻法
- アプリだけ別権限なら、
runasでアプリ単位の別ユーザー起動が扱いやすい - 同時利用が常態なら、RDSとCALを含めた設計で無理のない運用にする
「切り替えたい」の裏にある目的を一段分解して、tsdiscon（切断）／RDP（別セッション）／runas（アプリ単位）のどれを使うか決めると、Windows Server 2019でもストレスなく使い分けられます。
コメント