Windows Server 2025 環境で、セキュリティグループごとに「同時にログインできる人数」を変えたい――。実は Active Directory（AD）単体には、この要件を満たす“同時ログイン数の上限”パラメータがありません。ではどう設計すべきか。RDS/VDI など“入口側”で破綻なく制御する考え方と実装例を、運用の落とし穴まで含めてまとめます。
まず整理：「同時ログイン数」はどのログインを数えるのか
「同時ログインを 35 人まで」などの要件は、一見シンプルに見えますが、Windows の世界では“ログイン経路”が複数あります。どの経路を対象にするかで、実現手段が大きく変わります。最初にここを定義しておかないと、設計も運用も破綻しがちです。
| ログインの例 | 利用者から見た状態 | 制御しやすい場所 | ポイント |
|---|---|---|---|
| RDS（RDP）でサーバーに接続 | リモートデスクトップで作業 | RDS 基盤（セッションホスト/コレクション） | 入口が集約できるため、同時セッション制御と相性が良い |
| VDI で仮想デスクトップに接続 | 専用/共有デスクトップを利用 | VDI コントローラー/ブローカー | 製品の割り当て・ポリシーで「同時利用」を表現しやすい |
| ドメイン参加 PC への対話ログオン | 各自の PC にサインイン | 端末側（GPO/エージェント） | “全端末横断の同時数”を AD だけで数えるのは困難 |
| VPN 接続やアプリの認証 | 社内リソース/アプリにアクセス | VPN/アプリ側の認証基盤 | 「ログオン＝OS サインイン」ではないケースが混ざりやすい |
この記事では、質問で挙がっている「Windows Server 2025 上でユーザーがログインして作業する」ケースを中心に、“セキュリティグループ単位で同時利用数を上限化する”現実解を掘り下げます。
結論：Active Directory だけで「同時ログイン数」を制限することはできない
結論から言うと、AD（Active Directory）単体には、ユーザー/グループ単位で“同時ログイン数”を直接制限する標準機能はありません。理由はシンプルで、AD は「アカウントや属性を管理するディレクトリ」であり、全サーバー/全端末の“現在のセッション数”を一元的に保持して制御する仕組みではないためです。
「AD なら何でも制御できそう」と思われがちですが、実際に AD で標準提供されている“ログオン制限”は、主に次のような方向性です。
| AD/GPO でできること（代表例） | できないこと（今回の論点） | 補足 |
|---|---|---|
| ログオン可能時間（Logon Hours） | 同時にログオンできる人数の上限 | 時間帯制御はできても、人数を数えて止める機能はない |
| ログオン可能端末（Log on to / workstation 制限） | グループ別の同時ログオン数 | 端末の範囲は絞れても、同時数のカウントはできない |
| 「ローカルにログオンを拒否」などの権限（GPO） | 35 人までなどの“枠”管理 | 許可/拒否はできるが、上限枠の概念がない |
| アカウントロックアウト（失敗回数） | 成功ログオンの同時数制限 | セキュリティ対策であり、同時利用制御とは別物 |
つまり、同時ログインを“人数枠”として運用したい場合は、AD ではなくログインの入口（セッション基盤）側で設計するのが王道です。
設計の基本方針：「入口を一つに集約し、そこで数える」
同時ログイン数の制限が難しくなる最大の原因は、ログイン入口が分散していることです。たとえば、各ユーザーが自由に多数の PC/サーバーへ直接ログオンできる環境では、「今、誰が、どこに、何セッション居るか」を完全に追い切るのがほぼ不可能になります。
逆に言えば、入口を一つ（または少数）に寄せれば、同時数の制御は現実的になります。代表例が RDS/VDI/アプリ配信です。
- RDS：RDP 接続を RDS コレクションに集約し、セッションホスト側で上限を作る
- VDI：ブローカー経由で仮想デスクトップへ誘導し、プール/割り当て数で上限を作る
- アプリ配信：アプリ入口で認可し、同時起動/同時セッションを制御する
この方針は「技術的にできる/できない」だけでなく、監査・問い合わせ対応・運用コストにも直結します。入口がバラバラなほど、運用の手数が爆発します。
現実的な解決策：RDS で「グループ別の同時セッション枠」を作る
質問の要件が「Windows Server にログインして作業する（RDP）」であれば、Remote Desktop Services（RDS）での制御が最も筋が良い選択肢です。ポイントは、“セキュリティグループ＝接続先プールの割り当て”に変換してしまうことです。
考え方：グループごとに「接続先（プール）」を分け、物理的に枠を作る
RDS には「このグループは同時 35 セッションまで」という 1 パラメータがあるわけではありません。代わりに、次の 2 つの掛け算で上限枠を“設計として”作ります。
- 各 RD セッションホストに設定する「同時接続数の上限」
- そのグループ（またはプラン）に割り当てるセッションホスト台数
たとえば「同時 35」なら、1 台あたり最大 20 セッション × 2 台＝最大 40のように枠を作り、余裕分（5）を“バッファ”として扱う設計が現実的です。完全に 35 ピッタリを狙うほど、運用が難しくなります（障害時・メンテ時に一気に枠が不足するため）。
RDS での実装イメージ（全体像）
構成要素を分解すると、次のようになります。RDS は要素が多く見えますが、要件を満たすための“制御点”は意外とシンプルです。
| 役割 | コンポーネント例 | この要件に効くポイント |
|---|---|---|
| 入口（ポータル） | RD Web Access / RemoteApp | 利用者の導線を統一し、接続先をブレさせない |
| 接続の振り分け | RD Connection Broker | 「どのホストへ入れるか」を制御し、プール運用を成立させる |
| セッション実行 | RD Session Host | ホスト側の「最大接続数」設定で物理的な上限を作る |
| 外部公開（必要時） | RD Gateway | インターネットからの入口を一本化し、監査/制御点を作る |
| ライセンス | RD Licensing | 同時数制限の機能ではないが、RDS 利用の前提として整える |
数百グループに効く運用術：「プラン化」と「入れ子グループ」
数百のセキュリティグループをすべて個別にコレクション分割すると、構築はできても運用がすぐ破綻します。ここでおすすめなのが、「上限値が近いものをプラン化して束ねる」やり方です。
さらに AD 側は、グループを直接コレクションに割り当てるのではなく、プラン専用の集約グループを用意し、そこへ各部門グループを“入れ子（ネスト）”で収容すると管理が楽になります。
- 例：RDS-Plan-35-Users（プラン集約）← 部門Aグループ、部門Bグループ…を追加
- 例：RDS-Plan-50-Users（プラン集約）← 大規模部門のグループを追加
これにより、RDS 側の設定（コレクションの許可グループ）はプラン単位で固定でき、日々の増減は AD グループのメンバー管理に寄せられます。WordPress などで検索されやすい言い方をすると、「Windows Server 2025 の同時ログイン制限を、AD ではなく RDS 側で“プラン運用”する」イメージです。
具体例：プランで運用し、上限を“ホスト構成”で担保する
上限の段階（S/M/L…）を作り、各セキュリティグループはどれか 1 つのプランに属するようにします。
| プラン名（例） | 目標同時数 | 集約グループ（例） | RDS コレクション（例） | セッションホスト構成例 |
|---|---|---|---|---|
| Plan-35 | 35 | RDS-Plan-35-Users | RDS-COL-35 | 2 台 × 20 セッション上限（最大 40） |
| Plan-50 | 50 | RDS-Plan-50-Users | RDS-COL-50 | 3 台 × 20 セッション上限（最大 60） |
| Plan-80 | 80 | RDS-Plan-80-Users | RDS-COL-80 | 4 台 × 25 セッション上限（最大 100） |
この方式なら「数百グループ」を「数プラン」へ畳み込めるため、コレクション数・GPO・監視対象を現実的な規模にできます。上限を細かく刻みたい欲求は出ますが、運用コストとトレードオフです。
RDS で押さえる設定ポイント：GPO で“枠が溶ける原因”を潰す
上限枠の運用は「数える」よりも「枠を食い潰す原因（放置/切断/多重）を潰す」ほうが効きます。RDS セッションホスト向けの代表的なポリシーを、目的別に整理します。
| 目的 | 代表的な設定（例） | 効きどころ |
|---|---|---|
| ホストの最大同時接続を固定する | 「接続数を制限する（Limit number of connections）」 | ホスト単位の上限が確定し、プール全体の枠を設計できる |
| 同一ユーザーの多重ログインを防ぐ | 「ユーザーを 1 セッションに制限する」 | “二重起動”で枠が溶けるのを防止 |
| 放置セッションを片付ける | 「アイドル セッションの制限」「切断セッションの制限」 | 誰も使っていないのに枠が戻らない事故を減らす |
| 時間切れ時の動作を統一する | 「時間制限到達時にセッションを終了する」 | 部門ごとに挙動が違う“謎仕様”をなくす |
なお、実際の値（何分で落とすか）は業務によって正解が違います。大事なのは全社で標準を決め、例外を増やさないことです。
タイムアウト設計のおすすめ（枠を守るための現場寄り設定）
運用で揉めやすいのは「席を外しただけなのに落とされた」「切断したのに枠が戻らない」のバランスです。用途別に推奨値を決め、例外を最小化すると安定します。
| 項目 | 例（事務作業中心） | 例（開発/長時間処理） | 狙い |
|---|---|---|---|
| アイドル セッション制限 | 60〜90 分 | 120〜240 分 | 放置セッションで枠が枯れないようにする |
| 切断セッション制限 | 15〜30 分 | 60 分 | 切断しっぱなしを防ぎ、枠の回復を早める |
| ログオフ時刻（強制ログオフ） | 業務終了+α | 原則なし（要監視） | 夜間の“幽霊セッション”を掃除する |
| 1 ユーザー 1 セッション制限 | 有効推奨 | 要件次第 | 同一ユーザーの多重セッションで枠が溶けるのを防ぐ |
「枠が埋まった」時に起きる問い合わせを減らす工夫
同時ログイン数を制限すると、ピーク時に「ログインできない」問い合わせが必ず発生します。ここは技術ではなく、運用設計で差が出ます。
- 入口を RD Web に寄せる：利用者が“直接サーバー名に RDP”し始めると制御が崩れます
- 代替導線を用意する：軽作業は別プラン、緊急時は一時プールなど
- 見える化する：今の空き状況をヘルプデスクが答えられるだけで混乱が減ります
RDS であれば、管理者向けには quser や RDS のセッション一覧で現状確認ができます。自動化するなら、監視ツールやスクリプトで「現在のアクティブ/切断セッション数」を定期集計し、レポート化しておくと便利です。
RDS だけで足りないとき：サードパーティ（Citrix など）を検討する判断軸
RDS は Windows 標準で構築できる反面、要件が複雑化すると設計で吸収する部分が増えます。たとえば次のような要件が強いなら、Citrix を含むサードパーティ基盤や VDI を検討する価値があります。
- 利用者のネットワークが多様で、最適化（遅延対策/帯域制御）が重要
- アプリ公開のポータル/認証/多要素認証/監査を統合したい
- “部署・役割ごと”の割り当てや、きめ細かいポリシーが必要
- 複数拠点/DR を含む大規模で、可用性要件が高い
ただし注意点として、製品によって「同時利用数の制限」がポリシー機能として提供される場合もあれば、結果的に「プールの規模で上限を表現する」形になる場合もあります。比較の際は“グループ別の上限をどのレイヤーで実現するのか”を確認し、運用の手数（誰が日々調整するか）まで含めて評価すると失敗しにくいです。
カスタム実装でやる場合：できるが「運用が壊れやすい」ことを理解する
「どうしても AD グループ単位で、OS へのログオンそのものを人数で止めたい」「RDS 以外のログオンも含めて数えたい」という場合、技術的にはカスタム実装で近づけることはできます。典型は次の 3 パターンです。
パターンA：ログオンイベントを集計し、超過時にログオフ/拒否する
- 監査ログ（ログオン/ログオフ）を収集し、グループ別のアクティブ人数を算出
- 超過していればログオン直後にサインアウトさせる、または接続を切る
パターンB：RDS ならログオン前後のスクリプト/フックでチェックする
- ログオンスクリプト/タスクでセッション数をチェックし、超過時はメッセージを出して切断
- より堅牢にするなら、認証/接続の手前（例：Gateway/NPS 側）で判定する構成もある
パターンC：端末/サーバーにエージェントを常駐させて中央で枠管理する
- 中央の台帳（DB/Redis など）に「入室/退室」を登録し、枠を確保してからログオン継続
- ハートビートが途切れたら枠を解放する
いずれも可能ですが、現場では次の“落とし穴”が頻発します。
| 落とし穴 | 起きること | 対策の方向性 |
|---|---|---|
| 同時ログオンの競合 | 同時に 2 人が入って枠を超える（レースコンディション） | ロック機構/トランザクションを持つ中央台帳が必要 |
| “切断”の取り扱い | 切断セッションが枠を占有し続ける | 切断タイムアウトの標準化、強制解放の運用 |
| ネットワーク断/PC 強制終了 | 退室が記録されず、枠が戻らない | ハートビート方式や TTL（期限）で自動解放する |
| 例外ユーザーの増殖 | 管理者/役員/夜間バッチなど例外が増え、ルールが崩れる | 例外は“別プラン”に分離し、個別対応を最小化 |
| トラブル時の切り分け難易度 | 「ログインできない」が多発し、原因調査に時間が溶ける | 判定ログ・可観測性（いつ誰が何枠で弾かれたか）を最初から作る |
カスタム実装は「作る」よりも「壊れない運用にする」のほうが難しい領域です。RDS/VDI のように入口が集約できるなら、まずは標準基盤で枠を作るほうが総コストは下がりがちです。
「ドメイン参加 PC への対話ログオン」まで同時数で縛りたい場合の現実解
要件が「各自の PC へのサインイン」まで含む場合、AD だけではなく、RDS でも十分に制御できません。なぜなら、PC は拠点/在宅/オフラインなど状態が分散しやすく、ログオンの入口が統一できないからです。
この場合の現実解は、次のどれかに寄せることです。
- 業務アプリを RDS/VDI 側へ寄せる：PC にはログインできても「業務環境へは枠の中でしか入れない」形にする
- 入口を VPN/ゼロトラストの認証へ寄せる：社内リソースに入る段階で枠を作る（OS ログオンではなくアクセスで管理）
- どうしても OS ログオンで縛るならエージェント型：ただし設計/監視/例外運用が重くなる覚悟が必要
「何を守りたいのか（サーバー資源、アプリ同時利用、ライセンス、予算）」を言語化し、制御点を OS ログオンに固定しないほうが成功確率は上がります。
よくある誤解：CAL やライセンスで“同時ログイン数”は制御できない
「予算に応じて同時ログイン数を変えたい」という文脈では、Windows Server CAL や RDS CAL を“同時ライセンス”のように捉えてしまうケースがあります。しかし、CAL は基本的にアクセス権（ユーザー/デバイスの権利）の話であり、製品側が“同時何人まで”を自動で枠管理してくれる仕組みとは別です。
そのため、予算・用途に応じて上限を作るなら、ライセンスの話とは切り分けて、技術的な入口制御（RDS/VDI/アプリ配信）で実現するのが安全です。
運用を安定させるためのチェックリスト
最後に、グループ別の同時ログイン枠を「作っただけ」で終わらせず、運用で事故らないためのチェックポイントをまとめます。
| チェック項目 | 具体例 | 意図 |
|---|---|---|
| “同時ログイン”の定義 | Active のみ数えるのか、Disconnected も含むのか | 利用部門との認識ずれを防ぐ |
| 枠が埋まった時の挙動 | 新規ログイン拒否、待機案内、別プール誘導 | 問い合わせ対応を減らす |
| 切断/放置セッション対策 | 切断 30 分でログオフ、アイドル 90 分でログオフ | “幽霊セッション”で枠が溶けるのを防ぐ |
| プラン設計の単純化 | Plan-35 / Plan-50 / Plan-80 の 3 段階 | 数百グループでも運用できる規模に畳み込む |
| 監視とレポート | 上限到達回数、ピーク時間帯、拒否回数 | 増強/見直しの判断材料を作る |
| 例外の扱い | 管理者は別プール、緊急用の“バースト枠”を用意 | 例外増殖でルールが崩れるのを防ぐ |
まとめ：AD に求めず、セッション基盤で「枠」を作るのが最短ルート
Windows Server 2025 でセキュリティグループ別に同時ログイン数を制限したい場合、AD だけで完結する設定パラメータは存在しません。要件を満たす現実的な方法は、ログインの入口（RDS/VDI/アプリ配信）を集約し、そこでグループ割り当てと枠（上限）を設計することです。
まずは「同時ログイン＝どの入口を対象にするか」を決め、プラン化（段階化）で運用を単純化し、タイムアウトと監視をセットで整備してください。これだけで、数百グループでも“予算に応じた上限”を現場で回せる形に落とし込みやすくなります。
コメント