Entra IDのみへ移行し、オンプレAD（Active Directory Domain Services）を持たない運用にしても、社内の証明書発行基盤（PKI）だけは残したい――そのとき迷うのが、スタンドアロンCA（Active Directory Certificate Services：AD CS）のライセンスとCALです。必要なライセンスの考え方、CALが発生する境界、将来コストが増えるポイントを整理します。
結論：スタンドアロンCA運用で押さえるべきライセンスの最小セット
まず、議論が混ざりやすいので整理します。オンプレミスに「AD CSのスタンドアロンCAサーバー」を1台だけ残す場合でも、ライセンスは大きく「サーバーを動かす権利」と「そのサーバーへアクセスする権利」に分かれます。Windows Serverは「コアライセンス（サーバー側）」＋「CAL（アクセス側）」という前提で考えるのが基本です。
| 論点 | 結論 | よくある勘違い | 実務での落とし穴 |
|---|---|---|---|
| サーバー本体のライセンス | スタンドアロンCAを構築するWindows Serverには、通常どおりサーバーライセンスが必要 | 「CAは機能だからライセンス不要」 | オフラインRoot CAも“使う”ならサーバーライセンスの整理が必要（VM／物理の扱いも含む） |
| CAL（クライアントアクセスライセンス） | 社内ユーザー／デバイスがWindows Serverへアクセスするなら、原則Windows Server CALが必要 | 「AD CSに専用CALがない＝CALゼロ」 | 証明書の取得・更新・失効情報取得など、どこまでを“アクセス”とみなすかを曖昧にしない |
| AD CSの“専用CAL” | AD CS専用の追加CALを買う、という発想は基本的に不要 | 「AD CSはRDSみたいに追加CALが要るのでは？」 | 追加CALが不要でも、ベースCAL（Windows Server CAL）の論点は残る |
このため、実務上の答えは次の形になります。
- AD CSのスタンドアロンCAはWindows Serverのロールとして提供されるため、“CAだから追加のサーバー製品ライセンスが増える”という話にはなりにくい
- 一方で、Windows Serverの利用は「サーバーを起動する権利」と「アクセスする権利」が別管理のため、社内ユーザー／デバイスがCAサーバーを利用するならCALの検討は避けられない
前提知識：AD CS（Active Directory 証明書サービス）とスタンドアロンCAとは
AD CSは、Windows Serverに搭載できる証明書基盤（PKI）のロールで、証明書の発行・管理を行います。TLS/SSL、VPN、無線LAN（802.1X）、S/MIME、端末・ユーザー認証など、社内システムの“暗号化と本人性”を支える用途で使われます。
AD CSで中心になるのが「認証局（CA）」です。CAは利用者（ユーザー、端末、サーバー、アプリ）に対してデジタル証明書を発行し、必要に応じて失効（取り消し）や更新も管理します。Windows ServerにAD CSのCAロールサービスを入れることで、Windows Server自体をCAとして動かせます。
CAには大きくエンタープライズCAとスタンドアロンCAがあります。エンタープライズCAはAD DSと統合され、証明書テンプレートや自動承認・自動登録（オートエンロールメント）など“企業向けの自動化”を使えます。一方、スタンドアロンCAはAD DSを必須とせず、テンプレートも使わないため、申請内容をリクエスト側が明示し、運用も手動寄りになります。
Windows Serverライセンスの基本：サーバーライセンスとCALを分けて考える
Microsoftのサーバー製品は、同じ“ライセンス”という言葉でも中身が異なります。まずはここを分けて捉えると、AD CSの話が一気に整理できます。
サーバーライセンス：Windows Serverをインストールして動かす権利
Windows Server Standard／Datacenterは、基本的にコアベースでライセンスされ、アクセスにはCALが必要というモデルです。公式のライセンスガイダンスでも、サーバーソフトウェアへのアクセスにはアクセスライセンス（CALやExternal Connector）が必要であること、内部ユーザーはCALが前提であることが示されています。
「CA機能だから特別なサーバーライセンスが増えるのか？」という点は、AD CSがWindows Serverのロールである以上、通常は“Windows Serverを動かすためのサーバーライセンス”が軸になります。
CAL：Windows Serverのサービスにアクセスする権利
CAL（Client Access License）は“ソフトウェアそのもの”ではなく、「ユーザー／デバイスがサーバーソフトウェアのサービスへアクセスする権利」を表す考え方です。Microsoftのライセンス解説でも、ネットワークでサーバーソフトウェアを利用する場合、サービスにアクセスするためにCALが必要になることがある、と説明されています。
Windows Server 2025のライセンスガイダンスでは、サーバーソフトウェアへアクセスする場合はアクセスライセンスが必要であり、各ユーザー／デバイスがベースCAL（Windows Server CAL）を要する旨が明記されています。さらに、RDSなどの高度機能には“ベースCALに追加して”Additive CALが必要になる、という構造です。
| ライセンスの種類 | 対象 | イメージ | AD CS（CA）との関係 |
|---|---|---|---|
| サーバーライセンス | Windows Serverを実行するサーバー（物理／VM） | OSを“置いて動かす”ための権利 | CAサーバーのOSとして必要 |
| Windows Server CAL（ベースCAL） | ユーザーまたはデバイス | Windows Serverのサービスへ“アクセスする”権利 | 証明書取得・更新などでCAへアクセスするなら論点になる |
| Additive CAL（追加CAL） | ユーザーまたはデバイス | RDS等の“高度機能”へアクセスする追加の権利 | CA単体では通常該当しない（RDS等を同居させると別） |
| External Connector（EC） | サーバー（1台ごと） | “外部ユーザー”が多数アクセスする場合の代替 | 社外ユーザーに証明書サービスを提供する設計なら検討対象 |
ユーザーCALとデバイスCALの選び方
Windows Server CALには、ユーザー単位で買う「ユーザーCAL」と、端末単位で買う「デバイスCAL」があります。Microsoftの解説では、複数デバイスでアクセスする働き方ならユーザーCAL、複数人で端末を共有するならデバイスCALが合理的、という考え方が示されています。
| 状況 | 向きやすい選択 | CA運用での具体例 |
|---|---|---|
| 一人がPC＋スマホ＋VDIなど複数端末を使う | ユーザーCAL | 同一ユーザーが複数端末でVPN証明書を更新する |
| 現場端末をシフトで共有し、利用者が多い | デバイスCAL | 共用端末がWi-Fi証明書を更新する（利用者が入れ替わる） |
| 社外の利用者が多い（取引先・顧客など） | EC（External Connector）も比較 | 取引先向けポータルのクライアント証明書を発行する |
「AD CSにCALは不要？」が混乱しやすい理由
検索すると「AD CS自体にはCALは不要」という趣旨の回答を見かけます。たとえばMicrosoft Q&Aでも、スタンドアロンCAに関する質問に対し「AD CS自体は一般にCALを要求しない」といった説明があり、質問者が納得しているケースがあります。
ただし、ここで注意したいのは“専用CALが不要”と“Windows Server CALが不要”は同義ではない点です。Windows Serverのライセンスガイダンスでは、サーバーソフトウェアへアクセスする場合はアクセスライセンス（CAL/EC）が必要であり、内部ユーザーはベースCALが前提、と整理されています。
実務での着地点としては、次のように言い換えると誤解が減ります。
- AD CSのために追加で“AD CS専用CAL”を買う必要は通常ない
- 一方で、社内ユーザー／デバイスがWindows Server上のCAサービスを利用するなら、Windows Server CAL（ベースCAL）の整理は必要
スタンドアロンCAでCALが論点になる“アクセス”の具体例
CALの要否は「サーバーにアクセスしているか」を軸に整理すると理解しやすくなります。Windows Serverのライセンスガイダンスでは、サーバーソフトウェアへのアクセスはアクセスライセンスが必要、と明確に整理されています。
証明書サービスでは、目に見えるログオンだけがアクセスではありません。次のような行為が“CAサーバー（あるいは同居するAD CS関連ロール）に対する通信”として発生します。
| 行為（よくある通信） | 誰が行うか | 何のためか | ライセンス検討の観点 |
|---|---|---|---|
| 証明書の申請・取得（発行/更新） | ユーザー端末／サーバー／ネットワーク機器 | クライアント証明書、サーバー証明書など | CAに対する明確な利用。内部ユーザー/デバイスならベースCALを前提に整理 |
| 失効情報の取得（CRLダウンロード） | 証明書を検証するクライアント全般 | 証明書が失効していないか確認 | CRL配布先がCAサーバー自身か、別のWebサーバーかで通信先が変わる |
| OCSP応答（Online Responder） | クライアント全般 | 失効状態をオンラインで確認 | Online ResponderもAD CSのロールサービスの一つとして提供される |
| Web Enrollment（certsrv） | ブラウザ利用者 | 証明書の申請・回収・CRL取得など | Web EnrollmentはAD CSの機能として説明されている |
| 非ドメイン参加端末のポリシーベース登録（CEP/CES） | ドメイン外の端末 | 証明書登録ポリシーの取得と登録 | 「ドメイン非参加でもポリシーベース登録を可能にする」機能として提供 |
上の表のうち、Web Enrollment、Online Responder、NDES、CEP/CESなどは、AD CSが提供する主要機能としてMicrosoft Learnでも列挙されています。Entra IDのみで端末がドメイン参加しないケースでは、CEP/CESのような“ドメイン外でも登録できる”仕組みが設計上の選択肢になります。
CALが不要になり得る例外と、誤用しやすいポイント
Windows Serverのライセンスガイダンスには、アクセスライセンスが不要になり得る例外も整理されています。たとえば、別のライセンス済みサーバーからのアクセス、公開Webサイト（Web Workload）としてのアクセス、HPC用途、仮想環境管理専用の物理OSEなどが例示されています。
ただし、例外を無理に当てはめようとすると運用やセキュリティの設計が歪みます。特に社内向けPKI（内部ネットワークで使う証明書発行・失効情報配布）は、“公開Webサイト”とは前提が異なることが多いので、安易に「公開すればCAL不要」と短絡しない方が安全です。公開範囲を広げること自体がセキュリティリスクになるケースもあります。
スタンドアロンCAとエンタープライズCA：技術差がそのまま運用コストに効く
「オンプレADなし（Entra IDのみ）」という条件では、CAの種類が運用に直結します。Microsoft Learnでは、エンタープライズCAはAD DSと統合されテンプレートを利用する一方、スタンドアロンCAはAD DSを必要とせずテンプレートも使わず、既定では申請が保留キューに入り管理者承認が必要、と整理されています。
| 比較項目 | スタンドアロンCA | エンタープライズCA | ライセンス/コスト面の見え方 |
|---|---|---|---|
| AD DS（オンプレAD）依存 | 不要 | 必須（統合） | エンタープライズCAを選ぶと、ドメインコントローラー等の前提が生まれ、結果としてオンプレ側の“サーバー運用”が増えやすい |
| 証明書テンプレート | 使わない | 使う | テンプレートが必要な自動化（大量配布）をしたいほど、AD DSの要素が増えやすい |
| 自動承認・自動登録 | 基本は手動寄り | 自動化しやすい | 自動化のために追加ロールや周辺サーバーを増やすと、結果としてCAL対象のアクセスも増えやすい |
| 向いている用途 | サーバー証明書や限定的な発行、手動運用が許容できるPKI | ユーザー/端末証明書を大規模に配布、スマートカードログオン等 | 要件が“少量・限定用途”ならスタンドアロンCAで機能とコストを絞りやすい |
「Entra IDのみ」で端末もドメイン参加しない設計に寄せるほど、エンタープライズCA前提の自動化（GPOによる自動登録など）は使えなくなります。結果として、スタンドアロンCAを選ぶのは技術的にも自然ですが、その分“手動運用”の作業コストが増えます。ここはライセンスの話と同じくらい、現場負荷に直結します。
「CAだけ残す」なら、サーバーを専用化したほうが安全で分かりやすい
スタンドアロンCAサーバーは、できる限りCA専用として運用するのがおすすめです。理由はシンプルで、セキュリティ（攻撃面の削減）とライセンス/棚卸し（何にアクセスしているかの明確化）の両面でメリットがあるためです。
| 同居させがちな役割 | メリット | デメリット | CAL観点の注意 |
|---|---|---|---|
| ファイルサーバー | 運用台数が減る | アクセスが増え、侵害時の影響が大きい | ファイル共有の利用者が明確に“Windows Serverへアクセス”するため、CAL整理が難しくなる |
| プリントサーバー | 管理が一元化 | スプーラ等の脆弱性リスク | 利用者・端末数が多いほど、CALの数え上げも増える |
| DHCP/DNS | 小規模だと便利 | ネットワーク基盤の単一障害点になる | “誰がアクセスしているか”の範囲が広がり、把握しづらい |
| IIS（Web Enrollment等のため） | 証明書申請/回収がしやすい | 公開範囲の設計を誤るとリスク | Webで利用者が増えるほど、アクセスライセンス整理が重要になる |
Entra IDのみ環境で現実的な運用モデル
“Entra IDのみ”の組織が、オンプレにCAだけ残す理由はだいたい次のどれかです。
- 社内サーバー／機器のTLS（社内Web、プロキシ、監視、バックアップ、内部API）を内部CAで発行したい
- 無線LAN（802.1X）やVPNで端末証明書を使いたい
- 閉域ネットワークでパブリックCAが使いづらい
- 機器（ルータ、スイッチ、複合機等）に内部証明書を配りたい
このとき、運用モデルを大きく二つに分けて考えると、ライセンスも設計も整理しやすくなります。
モデルA：少量発行・手動運用（スタンドアロンCAの王道）
- オフラインRoot CA（必要時のみ起動）＋オンライン発行CA（スタンドアロン）
- 申請はサーバー管理者がまとめて実施（MMC/PowerShell/certreq 等）
- 失効情報（CRL）の配布先を明確にし、監視も最小構成にする
このモデルは“CAサーバーにアクセスする主体”を限定しやすいため、CALの数え上げも現実的になります。特にサーバー証明書中心で、申請者が少数の管理者に限られる場合、棚卸しが簡単です。
モデルB：端末/ユーザーへ配布を自動化したい（要件が増えやすい）
- Web Enrollment、Online Responder、NDES、CEP/CESなど、AD CSの周辺ロールを追加しがち
- 端末台数が増えるほど、証明書の更新・失効・監査の運用も増える
- 自動化の要件が強い場合、エンタープライズCAや別製品（マネージドPKI）を検討した方がトータルで安定することもある
AD CSにはドメイン非参加端末でもポリシーベースの登録を可能にする仕組み（CEP/CES）なども用意されていますが、構成が増えるほど“どのサーバーへ誰がアクセスするか”の範囲も増えます。結果としてCALの整理も、セキュリティ設計も難しくなります。
間接アクセス（コネクタ経由）でもCALは消えない点に注意
Entra IDのみ環境では、「証明書配布はコネクタ（中継サーバー）にまとめれば、端末は直接Windows Serverにアクセスしていないのでは？」と考えたくなります。しかし、Microsoftのライセンスガイダンスでは、間接アクセス（いわゆるMultiplexing/Indirect Access）についても別途参照が示されており、単純に“中継したから不要”とは言い切れません。設計でCALを消せるかのように扱うのは危険です。
チェックリスト：あなたのCA計画でCALをどう数えるか
最後に、判断を間違えにくいチェックリストを置いておきます。ここを埋めると、リセラーや契約担当へ相談するときも話が早くなります。
| チェック項目 | 確認の仕方 | 判断の目安 |
|---|---|---|
| CAサーバーにアクセスするのは内部ユーザーか、外部ユーザーか | 申請/更新/失効情報取得の主体を列挙する | 内部（社員・オンサイト委託等）ならCAL、外部ならCALまたはECを検討 |
| アクセス主体は“ユーザー”で管理すべきか、“端末”で管理すべきか | 1人あたり端末数、共有端末の有無を確認 | 複数端末ならユーザーCAL、共有端末ならデバイスCALが分かりやすい |
| CAサーバーに同居させるロールは何か | CA以外の役割（ファイル/プリント/IIS等）を洗い出す | 同居が増えるほどアクセス範囲が広がり、CAL整理も難しくなる |
| 将来的にオンプレへ戻す可能性がある機能は何か | ファイル共有、アプリ、VDI、印刷などの復活可能性を確認 | “今はCAだけ”でも、将来の追加でCAL要件が増える前提で設計すると安全 |
最終確認：必ず「Product Terms」と契約形態で確定させる
Microsoftのライセンスは、製品ドキュメントだけで完結せず、最終的には契約（ボリュームライセンス、SPLA、CSP、OEM、Retailなど）とProduct Termsが基準になります。Windows Serverのライセンスガイダンスも“情報提供であり、Product Terms等が優先”である旨が明記されています。
記事の内容を踏まえたうえで、社内の契約形態に沿って次を確認すると、ほぼ迷いが消えます。
- オンプレに残すWindows Serverの台数・エディション・仮想化形態
- CAサーバーへアクセスする内部ユーザー／デバイスの範囲
- 外部ユーザーがアクセスする可能性（あるならECも比較）
- CA以外のロールを同居させない運用ルール
- 将来増える可能性があるオンプレ機能（そのときCALが増える前提で見積もる）
スタンドアロンCAは、Entra IDのみの環境でも成立しやすい一方、“自動化しにくい”という現実があります。ライセンスだけでなく、運用（申請・更新・失効・監査・バックアップ）まで含めて、最小で回る構成を作ることが結果的にコスト最適化につながります。
コメント