MAK と KMS の違い|認証の仕組みと 3 方式の選定基準

  • URLをコピーしました!
目次

はじめに

Windows Server やクライアント PC を企業環境で展開する際に検討が必要になるのが、ボリュームライセンス認証の方式選定です。ボリュームライセンスには MAK(Multiple Activation Key)と KMS(Key Management Service)という 2 つの代表的な認証方式があり、さらにドメイン環境では ADBA(Active Directory-Based Activation)という第 3 の選択肢も利用できます。

「自分の環境ではどの方式を選ぶべきか」「KMS の 180 日ルールとは何か」といった疑問に答えるため、本記事では各方式の仕組みの違いと選定基準を整理します。

この記事でわかること
  • MAK と KMS の仕組みの違いと選定基準
  • ADBA を含めた 3 方式の使い分けの考え方
  • KMS の 180 日ルールと認証の閾値(サーバー 5 台 / クライアント 25 台)
  • 見落としやすい KMS 運用の制約事項

先に結論をまとめると、台数が少ない独立環境や持ち出し端末が中心であれば MAK、閉域網や大規模展開であれば KMS が基本の選択肢となります。さらに、対象がドメイン参加済みの比較的新しい OS のみであれば、専用ホストが不要な ADBA が第一候補になります。

MAK 認証の仕組みと向いている環境

MAK は、各コンピューターが Microsoft の認証サービスと直接通信して認証を受ける方式です。個人向けのリテール版と同様に、インターネット経由(または電話)で認証を行い、一度認証されればハードウェア構成が変わらない限り再認証は不要です。社内に認証用のサーバーを用意する必要がなく、少数台の環境で最も手軽に導入できます。

参考: Plan for volume activation(Microsoft Learn)
“The MAK is used for one-time activation with the Microsoft online hosted activation services”
(MAK は、Microsoft がオンラインでホストする認証サービスによる 1 回限りの認証に使用されます)
https://learn.microsoft.com/en-us/windows/deployment/volume-activation/plan-for-volume-activation-client

MAK の認証回数には上限がある

MAK には、購入したライセンス数に基づいてあらかじめ認証可能回数が設定されています。OS の再インストールなどで同じキーを使い続けると認証回数を消費していくため、キッティングのやり直しが多い環境では残数の管理が必要です。認証回数は Microsoft へ連絡することで引き上げを依頼できます。残数の確認や複数台の一括管理には VAMT(Volume Activation Management Tool)が利用できます。

閉域網でも使える MAK プロキシ認証

「MAK はインターネット接続が前提」と思われがちですが、VAMT を使った MAK プロキシ認証という手段があります。インターネットに接続できる 1 台の管理端末が、閉域網内の複数コンピューターの認証要求を代理でまとめて Microsoft に送信する方式です。閉域網だが台数が KMS の閾値(後述)に満たない、という環境で選択肢になります。

MAK が向いている環境

  • インターネットに直接接続できる独立したサーバー
  • 台数が少ない小規模環境(数台〜十数台)
  • 社内ネットワークにほとんど接続しない持ち出し PC
  • 閉域網かつ台数が KMS の閾値に満たない環境(MAK プロキシ認証)

KMS 認証の仕組みと向いている環境

KMS は、社内に認証サーバー(KMS ホスト)を構築し、クライアントの認証を社内ネットワーク内で完結させる方式です。Microsoft と通信するのは KMS ホストの初回認証時のみで、各クライアントはインターネットに接続する必要がありません。

参考: Key Management Services (KMS) activation planning(Microsoft Learn)
“KMS clients connect to a KMS server, called the KMS host, for activation.”
(KMS クライアントは、KMS ホストと呼ばれる KMS サーバーに接続して認証を受けます)
https://learn.microsoft.com/en-us/windows-server/get-started/kms-activation-planning

KMS クライアントは、DNS の SRV レコード(_vlmcs._tcp)を通じて KMS ホストを自動的に検出するため、ボリュームライセンス版メディアからインストールした OS であれば、クライアント側の設定は原則不要です。通信には TCP 1688 ポートを使用します。

MAK と大きく異なるのは、認証が恒久ではなく、180 日ごとの更新を前提としている点です。また、一定台数以上のクライアントが存在しないと認証が成立しない「閾値」の仕組みもあり、これらの詳細は後述の「KMS 認証の 180 日ルールと認証の閾値」で解説します。

KMS が向いている環境

  • インターネットに接続できない閉域網のサーバー群
  • VDI や大量のクライアント PC など、閾値(サーバー 5 台 / クライアント 25 台)を安定して満たす規模の展開
  • OS の再展開が頻繁で、MAK の認証回数管理を避けたい環境

ADBA という第 3 の選択肢

ドメイン環境であれば、専用の認証サーバーを構築せずにライセンス認証を自動化できる ADBA(Active Directory-Based Activation)が利用できます。Windows Server 2012 / Windows 8 以降で導入された方式で、対象がドメイン参加済みの比較的新しい OS のみであれば、KMS よりも先に検討したい選択肢です。

仕組みとしては、ドメインコントローラーなどに「ボリュームライセンス認証サービス」の役割を追加し、KMS ホストキー(CSVLK)を Active Directory フォレスト内の「認証オブジェクト」として登録します。以降は、GVLK を持つクライアントがドメインに参加してドメインコントローラーと通信するだけで、自動的にライセンス認証が完了します。

参考: Activate using Active Directory-based activation(Microsoft Learn)
“Domain-joined computers stay activated as long as they remain members of the domain”
(ドメインに参加しているコンピューターは、ドメインのメンバーである限り認証状態が維持されます)
https://learn.microsoft.com/en-us/windows/deployment/volume-activation/activate-using-active-directory-based-activation-client

ADBA の特徴

認証の閾値がない

KMS のような「サーバー 5 台 / クライアント 25 台」の最低台数要件がなく、1 台目から認証されます。小規模なドメイン環境や検証環境でも導入しやすい点が KMS との大きな違いです。

専用ホストが不要

認証オブジェクトはフォレスト全体に複製されるため、どのドメインコントローラーでも認証を処理できます。KMS ホストの障害がライセンス認証に波及する、という単一障害点を排除できます。

DNS SRV レコードや TCP 1688 の考慮が不要

クライアントは既存のドメイン通信(LDAP)で認証オブジェクトを参照するため、KMS 用の追加のネットワーク設定が発生しません。

認証の有効期間は KMS と同様 180 日

クライアントはドメインコントローラーとの通信を通じて定期的に再認証します。

KMS との違いと共存可否

一方で、ADBA には以下の制約があります。

  • ドメイン参加が前提であり、ワークグループ端末は認証できません。
  • 対応するのは Windows 8 / Windows Server 2012 以降と Office 2013 以降のボリューム版に限られます。
  • Active Directory のスキーマが Windows Server 2012 以上に拡張されている必要があります。(ドメインコントローラー自体の OS アップグレードは不要)
  • 認証オブジェクトはフォレスト単位で機能するため、別フォレストの端末は認証できません。

なお、KMS と ADBA は共存可能です。クライアントは Active Directory から認証オブジェクトを取得できない場合、KMS 認証にフォールバックします。このため「ドメイン参加端末は ADBA、ワークグループ端末や古い OS は KMS / MAK で補完する」というハイブリッド構成が現実的な落としどころになります。

KMS 認証の 180 日ルールと認証の閾値

KMS は「一度認証したら終わり」という方式ではありません。KMS を選定・運用するうえで押さえておきたいのが、定期更新(180 日ルール)認証の閾値(Threshold)という 2 つの仕組みです。

180 日ルールと 7 日ごとの更新サイクル

KMS 認証の有効期間は 180 日です。ただし、クライアントは期限ぎりぎりまで待つわけではなく、既定では 7 日ごとに KMS ホストへ更新を試行し、成功するたびに有効期間が 180 日にリセットされます。

  • 通常時: 7 日ごとに KMS ホストと通信し、有効期間を更新します。
  • 通信不能時: KMS ホストと通信できない状態が続くと、残りの有効日数が減っていきます。
  • 期限切れ: 180 日間一度も更新できなかった場合、ライセンス未認証の状態に戻ります。その後、KMS ホストと再度通信できた時点で認証は回復します。

言い換えると、クライアントが 180 日以内に一度でも社内ネットワーク(KMS ホスト)に接続できれば、認証状態は維持されます。持ち出しが中心で半年以上社内に接続しない端末は、KMS ではなく MAK の対象と考えるのが妥当です。

認証の閾値(サーバー 5 台 / クライアント 25 台)

KMS ホストは、自身にアクセスしてきたユニークなクライアント数(CMID 数)をカウントしており、このカウントが一定の「閾値」を超えるまでは認証を許可しません。

対象必要なカウント数(閾値)
Windows Server5 以上
Windows クライアント(10 / 11)25 以上
Office(ボリューム版)5 以上

参考: Find and use product keys for volume licensing(Microsoft Learn)
“must have at least five computers to activate servers that run Windows Server”
(Windows Server を実行するサーバーを認証するには、少なくとも 5 台のコンピューターが必要です)
https://learn.microsoft.com/en-us/microsoft-365/commerce/licenses/product-keys-for-vl

注意したいのが検証環境です。たとえばサーバー 2 台で KMS の動作確認を行っても、閾値の 5 台に達しないため認証は成功せず、エラー 0xC004F038 が発生し続けます。KMS の動作検証には、最低でも閾値以上の台数(仮想マシンでも可)を用意する必要があります。エラー 0xC004F038 の具体的な確認・対処手順は、関連記事『KMS サーバー構築手順|Windows Server 2025 対応と確認コマンド』で解説しています。

30 日・50 件のカウント制約

KMS ホストが保持するカウントには、さらに 2 つの制約があります。

  • カウント対象は過去 30 日間にアクセスのあったユニークなクライアントのみです。あるクライアントから 30 日間アクセスがない場合、そのクライアントはカウントから除外されます。
  • KMS ホストが記録するのは直近 50 件の接続までです。

つまり、「定期的に稼働しているマシンが常に閾値以上存在すること」が KMS 運用の前提条件となります。台数が閾値前後で変動する環境では、カウント低下により新規クライアントの認証が失敗する可能性があるため、ADBA や MAK への切り替えを検討する余地があります。

3 方式の比較表と選定基準

ここまで解説した MAK / KMS / ADBA の 3 方式を比較表で整理します。

MAK / KMS / ADBA 比較表

項目MAKKMSADBA
認証先Microsoft(直接)社内の KMS ホストドメインコントローラー
インターネット接続各端末で必要(プロキシ認証を除く)KMS ホストの初回認証時のみ認証オブジェクト作成時のみ
再認証不要(恒久)180 日ごとに更新180 日ごとに更新(ドメイン通信で自動)
認証の閾値なしサーバー 5 台 / クライアント 25 台なし
ドメイン参加不要不要必要
対応 OS制限なし制限なしWindows 8 / Server 2012 以降
必要なインフラなし(VAMT は任意)KMS ホスト+ DNS SRVAD DS(スキーマ 2012 以上)

環境別の選定フロー

比較表を選定の観点で言い換えると、判断の分岐は次の順序になります。

STEP
ドメイン環境か

ドメイン参加端末のみで、対象 OS が Windows 8 / Windows Server 2012 以降に収まるなら、閾値がなく専用ホストも不要な ADBA が第一候補です。

STEP
台数が閾値を満たすか

ワークグループ端末や別フォレストの端末が混在する場合、あるいは閉域網でドメインがない場合は KMS を検討します。ただし、稼働台数が閾値(サーバー 5 台 / クライアント 25 台)を安定して下回る環境では KMS は成立しません。

STEP
少数・独立・持ち出し中心か

台数が少ない、インターネットに直接出られる、半年以上社内に接続しない端末が中心、といった環境では MAK が適しています。閉域網かつ少数台の場合は、VAMT による MAK プロキシ認証が選択肢になります。

なお、KMS と ADBA は共存できるため、「ドメイン端末は ADBA、それ以外は KMS または MAK」という組み合わせも設計として成立します。

KMS 運用の制約事項

KMS を選定する場合、閾値以外にも設計段階で押さえておきたい制約があります。導入後に気づくと手戻りになりやすいポイントです。

CSVLK のホスト認証上限

KMS ホスト自体の認証に使う CSVLK(KMS ホストキー)には、使用回数の上限があります。公式ドキュメントでは、最初の KMS ホストを認証した後、同じキーでネットワーク内にさらに 5 台(合計 6 台)までの KMS ホストを認証でき、同一ホストの再認証は 9 回までと記載されています。上限を超えるホスト数が必要な場合(多拠点それぞれにローカルホストを置きたい場合など)は、Microsoft のライセンス認証窓口への申請が必要です。

OS の再インストールや基盤リプレースのたびに KMS ホストを作り直す運用をしていると、この再認証回数を消費していく点に注意が必要です。

冗長化の考え方

KMS ホストは単一障害点になり得ますが、クライアント側は 180 日の有効期間内に一度更新できれば認証が維持されるため、数時間〜数日の停止が即座に業務影響につながるものではありません。一方、公式ドキュメントはクライアント数が多い環境でのホスト複数台構成を推奨しています。

参考: Create a KMS Activation Host(Microsoft Learn)
“we recommend that you have at least two KMS hosts”
(少なくとも 2 台の KMS ホストを用意することを推奨します)※クライアントが 50 台を超える場合
https://learn.microsoft.com/en-us/windows-server/get-started/kms-create-host

そのほかの制約

  • クライアント OS(Windows 10 / 11 など)上に構築した KMS ホストは、クライアント OS しか認証できません。サーバー OS も認証対象に含める場合は、KMS ホストを Windows Server 上に構築する必要があります。
  • 評価版(Evaluation)の Windows Server は KMS 認証の対象外です。フル版への変換が必要になります。
  • KMS ホストが認証できるのは、登録されている CSVLK が対応する世代までの OS です。Windows Server 2025 のような新しい OS を認証するには、対応するホストキーの登録と、ホスト側への更新プログラムの適用が必要になる場合があります。(手順の詳細は前述の関連記事『KMS サーバー構築手順|Windows Server 2025 対応と確認コマンド』で解説します)

まとめ

本記事では、Windows のボリュームライセンス認証における MAK と KMS の違いと、ADBA を含めた 3 方式の選定基準について解説しました。方式選定は「ドメイン環境か」「台数が閾値を満たすか」「端末が定期的に社内へ接続するか」の 3 点で判断するのが基本です。

  • MAK は Microsoft と直接通信する 1 回限りの恒久認証で、少数・独立環境向け
  • KMS は社内ホストによる代理認証で、閉域網や大規模環境向け
  • ドメイン参加端末のみで Windows 8 / Server 2012 以降なら ADBA が第一候補
  • KMS の認証は 180 日有効で、既定では 7 日ごとに自動更新される。
  • KMS の閾値はサーバー 5 台・クライアント 25 台で、検証環境でも例外なし
  • KMS のカウント対象は過去 30 日のユニーク接続で、記録は直近 50 件まで
  • CSVLK のホスト認証回数と MAK の認証回数には上限がある。

以上、最後までお読みいただきありがとうございました。

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ(ネットワーク・サーバ・クラウド・セキュリティ)の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus(取得から20年以上)/ VCAP-DCA / Azure Solutions Architect Expert

▶ 運営者プロフィール(詳細)

目次