Windows Server 2008で稼働しているドメインコントローラーをWindows Server 2019へ更改する際、「AD DSとDNSだけならCALは不要？」「2008 CALは2019でも使える？」と迷うケースは少なくありません。ここでは“ドメイン参加・認証・GPO・名前解決のみ”を前提に、必要なライセンスの考え方と確認ポイントを整理します。
結論：AD DS/DNSだけの構成でもWindows Server CALは必要
ドメインコントローラーが提供する認証やポリシー適用、DNSによる名前解決は「Windows Serverのサービスへのアクセス」に該当します。ファイル共有や印刷、RDS（リモートデスクトップサービス）を使わない構成でも、クライアントPCやユーザーがドメイン参加してログオンし、グループポリシーを受け取り、DNSを引ける時点で「サーバーソフトウェアへアクセスしている」扱いになるため、原則としてCAL（Client Access License）が必要です。
また、Windows Server 2008 CALはWindows Server 2019へのアクセス権としては不足します。CAL/EC（External Connector）は「同一バージョン、またはそれ以前のバージョン」へのアクセスを許可するため、2008 CALで2019へ“前方互換”はできません。したがって、更改後に2019のドメインコントローラーへアクセスするユーザー/デバイス分のWindows Server 2019（またはそれ以降）CALを用意する必要があります。
| 確認したいこと | 結論 | 要点 |
|---|---|---|
| DCを2019へ更改するだけでCALは必要？ | 必要 | 認証・GPO・DNSはWindows Serverサービスへのアクセス |
| Windows Server 2008 CALを2019で流用できる？ | できない | CALは同一/過去バージョンのみ。古いCALは新しいサーバーに使えない |
| コストを抑える方法は？ | 契約形態次第 | Software Assurance（SA）やCALスイートの保有状況を確認 |
そもそもCALとは：サーバー本体ライセンスと別に“アクセス権”が必要
Windows Serverのライセンスは大きく分けて「サーバー側のライセンス（コアライセンス等）」と「アクセスする側のライセンス（CAL/EC）」に分かれます。サーバーOSをインストールして起動できても、ユーザーや端末がそのサーバーのサービスを利用するには別途CAL（または外部向けならEC）が必要、という考え方です。
| 区分 | 何をカバーする？ | 更改（2008→2019）での注意点 |
|---|---|---|
| サーバー側ライセンス（Windows Server） | Windows Serverを“動かす権利”（コア単位など） | 2019へ更改するなら、当然サーバー側も2019として適切にライセンス |
| Windows Server CAL（Base CAL） | ユーザー/デバイスがWindows Serverの基本機能へアクセスする権利 | 2019 DCへアクセスするなら2019（以上）のCALが必要 |
| Additive CAL（例：RDS等） | 高度/追加機能にアクセスする追加の権利 | RDSを使わないなら基本は不要（ただし導入機能により要確認） |
| External Connector（EC） | “外部ユーザー”がサーバーへアクセスする場合の代替ライセンス | 取引先/顧客など外部アクセスがある場合に検討 |
ドメインコントローラー更改でCALが必要になる“実務上の理由”
「ファイルサーバーを立てない＝CAL不要」と誤解されがちですが、ドメインコントローラーは社内ITの“入口”です。クライアントは普段意識しなくても、次のようなタイミングで常にDCへアクセスしています。
- ドメイン参加（コンピューターアカウント作成、セキュアチャネル確立）
- ユーザーログオン/認証（Kerberos/NTLM、チケット発行）
- グループポリシー適用（GPOの取得、セキュリティ設定・スクリプト等）
- DNS名前解決（ドメインコントローラー自身がDNSを兼ねる場合も、DNSサーバーへ問い合わせる）
- パスワード変更、ロックアウト解除などのディレクトリ操作
- LDAP/LDAPS検索（メールアドレス帳、アプリの認証基盤、プリンタの認証など）
これらはすべて「Windows Server上で動くサーバーソフトウェア（AD DS/DNS等）のサービス」を利用している状態であり、Standard/DatacenterではアクセスするユーザーまたはデバイスごとにCALが必要という整理になります。
なお、Webサイトのように完全な匿名アクセスであればCAL不要とされるケースがありますが、ドメイン参加・認証は本質的に“認証あり”のアクセスです。DC更改はほぼ確実にCAL要件に該当すると考えるのが安全です。
「2008 CALは2019で使える？」を一発で理解する互換ルール
Windows ServerのCAL/ECは、同一バージョン、またはそれ以前のWindows Serverへアクセスする権利として定義されています。言い換えると、新しいCALは古いサーバーに使える（後方互換）が、古いCALは新しいサーバーに使えない（前方互換なし）というルールです。
| 手元のCAL | アクセスできるWindows Server | 更改での扱い |
|---|---|---|
| Windows Server 2008 CAL | Windows Server 2008（およびそれ以前） | 2019 DCには不足。2019（以上）への更新が必要 |
| Windows Server 2019 CAL | Windows Server 2019、2016、2012 R2、2008… | 2019 DC/ファイルサーバー等へアクセス可能（後方互換） |
| Windows Server 2022/2025 CAL | 2022/2025、2019、2016… | 将来のサーバー更改まで見越すなら“上位版”を採用する手もある |
「買い替え前提」になりやすい理由と、例外になり得るパターン
更改時に“2008 CAL→2019 CAL”の差額だけで済ませたい…となりがちですが、基本的にCALはバージョンごとに用意するライセンスです。そのため、過去に購入した2008 CALをそのまま2019のアクセス権に読み替えることはできず、新規に2019（以上）CALを手当てする整理になります。
一方で、コストを抑えられる可能性がある“例外パターン”もあります。代表例がSoftware Assurance（SA）です。SAの代表的なベネフィットであるNew Version Rights（新バージョン利用権）により、SAが有効なライセンスは最新バージョンへアップグレードできる、と説明されています。CALを含め、具体的な適用可否は契約/購入経路で変わるため、保守契約・EA/OV等の契約書面と合わせて確認しましょう。
また、MicrosoftのProduct Termsでは、CALスイート等が“CAL Equivalent License”として扱える条件（購入時期やSA有無など）も定義されています。社内でMicrosoft 365や各種CALスイートを包括契約している場合は、既にWindows Server CAL相当を満たしている可能性があります。
ユーザーCALとデバイスCAL：どちらを選ぶべきかの実務判断
Windows Server CALには一般にユーザーCALとデバイスCALがあります。ユーザーCALは「1人のユーザーが複数端末からアクセスする」形に強く、デバイスCALは「1台の端末を複数人で使う」形に強い、という考え方です。
| 現場の状況 | 向きやすいCAL | 理由（典型例） |
|---|---|---|
| 1人がPC＋ノート＋スマホ等、複数端末を使う | ユーザーCAL | ユーザー単位で権利を持つため、端末が増えてもCALが増えにくい |
| シフト制で共有PC/共有端末が多い | デバイスCAL | 端末単位で権利を持つため、利用者が多くても端末数で抑えられる |
| BYODが多く、端末数を正確に把握しづらい | ユーザーCAL | ユーザーを数えた方が運用が楽（監査対応も説明しやすい） |
| 倉庫・製造ラインなど、固定端末を不特定多数が利用 | デバイスCAL | 端末が固定ならデバイス単位が合理的 |
DC更改プロジェクトで見落としがちなのが、PC以外の“ADに触る機器”です。たとえば、複合機がLDAPでアドレス帳検索をする、NASがドメイン参加する、業務アプライアンスがドメイン認証を使うといった場合、それらも「アクセスするデバイス」としてカウント対象になり得ます。棚卸しの際は「人とPC」だけでなく、サーバーサービスへ認証・照会を行う機器も洗い出すと、後から足りない事態を避けられます。
外部ユーザーがいる場合：CALで数えるか、External Connectorでまとめるか
取引先や顧客など外部ユーザーがWindows Serverへアクセスする可能性がある場合、基本は「外部ユーザー分のCAL」か「サーバーに割り当てるExternal Connector（EC）」のどちらかを選ぶ整理になります。MicrosoftはECについて、外部ユーザーがアクセスするサーバーごとに割り当てることで多数の外部ユーザーアクセスをカバーできる、と説明しています。
| 外部アクセスの形 | 選択肢 | 向いているケース |
|---|---|---|
| 外部ユーザーが少数で固定 | 外部ユーザー分のCAL | 人数が読める、ユーザー管理ができる |
| 外部ユーザーが多い/増減する | External Connector（サーバー単位） | 外部ユーザー数が読めない、繁忙期だけ増える |
なお「外部ユーザー」の定義は契約上の定義があります。たとえばProduct TermsのGlossaryでは、外部ユーザーは“従業員ではない”だけでなく、常時オンサイトで働く請負者などは外部扱いにならない旨が定義されています。委託先が“実質社内メンバー”として常駐している場合は、外部扱いでECに逃がせないケースもあるため注意が必要です。
「DCだけならRDS CALも不要？」など、追加CALの誤解をほどく
今回の前提は「AD DS と DNS のみ」で、RDS（RD Session Host等）やファイル共有を使わない構成です。この場合、基本はWindows Server CAL（Base CAL）の話になります。RDSを提供する場合はWindows Server CALとは別にRDS CALが必要、という整理です。
また、契約形態によっては「管理目的のみで2名までCALなしでアクセスできる」という規定（Administrative and Support Rights）が示されています。これは“運用担当者がサーバーを管理するだけ”のような限定ケースで意味を持ちますが、ドメインコントローラーの場合は一般ユーザー/端末が認証に使うため、結局は必要CAL数の主因になりません。例外の有無は、適用される契約条項（Product Terms等）で必ず確認してください。
間にサーバーやアプリが入ってもCALは減らない：Multiplexingの考え方
「クライアントが直接DCに繋がるのではなく、アプリサーバーが認証を代行しているから、CALはアプリサーバー分だけで良いのでは？」という相談もあります。しかしMicrosoftは、Multiplexing（接続の集約/中継）で必要ライセンス数は減らないとし、Windows Serverも“直接でも間接でもアクセスにはCALが必要”と明確にしています。AD認証をどこかのミドルウェアが中継していても、最終的にその恩恵を受けるユーザー/デバイス分のCALを用意する、という発想で考えるのが安全です。
CALが不要になり得る例外を知っておく（ただしDC更改ではほぼ該当しない）
MicrosoftのライセンスFAQでは、CAL/ECが不要になる例外として「別のライセンス済みサーバーからのアクセス」「Web WorkloadやHPC Workloadとしての利用」「仮想環境をホスト/管理するためだけに使う物理OSEへのアクセス」などが挙げられています。
さらに、ボリュームライセンスの共通条項では管理目的のみで2名までCALなしでアクセスできるという“Administrative and Support Rights”も示されています。
| 例外の種類 | 概要 | DC更改（AD DS/DNS）への影響 |
|---|---|---|
| サーバー間アクセスの例外 | 別の“ライセンス済みサーバー”からのアクセスはCAL/EC不要とされるケースがある | ユーザーが認証の恩恵を受ける以上、最終的なユーザー/端末のCAL要件は消えない（Multiplexingに注意） |
| Web/HPC Workloadの例外 | Web WorkloadやHPC Workloadとしての利用ではCAL/EC不要とされるケースがある | ドメイン認証・GPOはWeb Workloadとは性質が異なり、通常は該当しにくい |
| 仮想基盤ホストの例外 | 仮想OSEのホスト/管理に限定された物理OSEへのアクセス | DC用途（AD DS/DNS）には当てはまりにくい |
| 管理目的2名まで（契約条件あり） | 運用・保守のための管理アクセスのみを想定した例外 | 一般ユーザー/端末がDCを利用するため、要件の中心は結局“利用者数”になる |
更改前にやっておくと安全な「CAL棚卸し」チェックリスト
- 利用者（ユーザー）数：正社員・契約社員・派遣・常駐ベンダーを含めた“認証を受ける人”を洗い出す
- 利用端末（デバイス）数：PCだけでなく、共有端末・タブレット・VDI端末・業務機器も確認
- ADに触る非PC機器：NAS、複合機、業務アプライアンス、LinuxサーバーのLDAP連携など
- 外部ユーザーの有無：取引先アクセスがあるならCALかECか、どちらが現実的かを検討
- 既存CALの購入形態：OEM/リテール/ボリューム、SA有無、CALスイート契約の有無を確認
- 将来計画：2022/2025など次期更改時期が見えるなら、上位バージョンCALを選ぶ判断材料にする
CALは「OSのプロダクトキーのように自動で足りないことを教えてくれる」ものではありません。更改プロジェクトの中で棚卸しと根拠資料の整理（購入証跡、割当方針）まで行うと、後々の監査・更新時に迷いが減ります。
よくある質問
サブドメインが複数あるフォレストでも、CALはドメイン単位で増えますか？
CALは“ドメイン数”ではなくアクセスするユーザー/デバイス数で数えるのが基本です。ドメインやドメインコントローラーが増えても、それ自体でCALが倍々に増えるわけではありません（ただし、アクセスする人/端末が増えれば必要数は増えます）。
DCを冗長化して2台、3台と増やすとCALも増えますか？
一般にWindows Server CALは“アクセスする権利”であり、サーバー台数そのものに比例して増える性質ではありません。必要数の軸はあくまでユーザー/デバイスです。
更改期間中に2008 DCと2019 DCが混在する場合、いつから2019 CALが必要ですか？
クライアントが2019のドメインコントローラー（または2019のWindows Server）へアクセスする時点で、アクセスするユーザー/デバイスには2019（以上）のCALが求められる、という整理になります。混在期間だから古いCALで良い、とはならないため、移行計画と合わせて早めに手当てしておくのが無難です。
最終的に誰に確認すべきですか？
Windows Serverのライセンスは、購入経路（OEM/ボリューム等）、SAの有無、CALスイート契約、外部ユーザーの定義などで例外が出ます。最終判断は、販売店（ライセンス担当）またはMicrosoftのライセンス窓口に、現状の契約情報を添えて確認するのが最も安全です。
コメント