KMSホストでライセンス認証は成功しているのに、slmgr /dlv の「Partial Product Key（末尾5文字）」がホストとクライアントで違って不安になることがあります。本記事ではCSVLKとGVLKの違い、確認すべきポイント、トラブル時の切り分けを具体例つきで解説します。
症状：KMSで認証は通るのにPartial Product Keyが一致しない
Windowsのボリュームライセンス環境でKMS（Key Management Service）を運用していると、次のような状況に遭遇します。
- KMSホストは「Volume:CSVLK（KMSホストキー）」で稼働している
- クライアント／サーバーは、そのKMSホストで問題なくライセンス認証できている（状態が Licensed）
- しかし、
slmgr /dlvやslmgr /dliの出力を見ると、ホストとクライアントの Partial Product Key（末尾5文字）が一致しない
この「末尾5文字が違う＝どこか設定が間違っているのでは？」という不安はとてもよくある相談です。結論から言うと、一致しないのが正常です。
結論：一致しないのが普通（正常動作）
Partial Product Keyは、その端末にインストールされているプロダクトキーの一部（末尾5文字など）を表示しているだけです。KMSでは、ホストとクライアントで「入っているキーの種類」がそもそも別物なので、末尾が一致しないのは当然です。
| 観点 | KMSホスト | KMSクライアント |
|---|---|---|
| 入れるキーの種類 | CSVLK（KMS Host Key / KMSホストキー） | GVLK（KMS Client Setup Key / KMSクライアント設定キー） |
| キーの入手元 | VLSC等で組織向けに払い出されるホスト用キー | 製品・エディションごとに公開されている汎用のKMSクライアント用キー |
| キーの役割 | ホスト自身をMicrosoftに対して有効化し、KMSサービスを提供する | KMSホストへ問い合わせて認証を受ける「KMSクライアント状態」にする |
| slmgrに出るPartial Product Key | CSVLKの末尾 | GVLKの末尾 |
| ホストとクライアントで一致する？ | 通常は一致しない（一致させる必要もない） | |
「認証が通っているのに末尾が違う」のは、ホスト（CSVLK）とクライアント（GVLK）が違うキーを使っていることの裏返しです。むしろ一致していたら、クライアント側にホストキーを入れてしまっているなど、運用上の問題を疑うべきケースがあります。
Partial Product Keyとは何か（どこまで信用してよい情報か）
Partial Product Keyは、プロダクトキー全体を表示すると情報漏えいになるため、Windowsが「識別用に一部だけ」表示する仕組みです。よく末尾5文字が表示されます。
ここで重要なのは、Partial Product Keyは次の用途には向いていないという点です。
- ホストとクライアントの「紐付け確認」
- 「同じライセンスを使っているか」の証明
- 「正しいKMSホストに向いているか」の判定
あくまで「そのマシンに何の種類のキーが入っているか」を追うためのヒントの1つです。KMS運用で見るべき本丸は、Partial Product Keyではなく キーのチャネル（Volume:CSVLK / Volume:GVLKなど）と、ライセンス状態（Licensed）です。
KMSの仕組み：なぜホストとクライアントでキーが別物なのか
KMSは「組織内に立てたKMSホストが、クライアントの認証要求に応答する」仕組みです。ポイントは次の2段階に分かれることです。
KMSホストの有効化（CSVLK）
KMSホストは、まず CSVLK（KMSホストキー）をインストールし、ホスト自身をMicrosoftへ有効化します。これによってホストはKMSサービスを提供できる状態になります。
この段階でホストが持つキーは「KMSホストとしての資格」を得るためのものであり、クライアントに配るためのものではありません。
KMSクライアントの設定（GVLK）
一方クライアントは、GVLK（KMSクライアント設定キー）を入れることで「私はKMSで認証します」という状態になります。GVLKは製品・バージョン・エディションごとに異なり、入れ間違えると認証できません。
つまり、ホストのCSVLKと、クライアントのGVLKは用途も中身も違うので、Partial Product Keyが一致する理由がありません。
認証が成功しているなら、末尾一致は気にしなくてよい
KMS認証が成功しているかどうかは、クライアント側で slmgr /dlv を実行し、License Status: Licensed になっていること、そして必要に応じて slmgr /xpr で有効期限（KMSの場合は期限表示が出ることがあります）を確認するのが確実です。
slmgr /dlvで「本当に見るべき項目」
末尾5文字に目が行きがちですが、運用・切り分けで見るべき項目は次の通りです。
| 見る項目 | ホストでの見方 | クライアントでの見方 | 意味 |
|---|---|---|---|
| Description / Product Key Channel | Volume:CSVLK になっているか | Volume:GVLK になっているか | どの「ライセンスチャネル」で動いているかの判定材料 |
| License Status | Licensed（ホスト自身） | Licensed（クライアント） | 現時点で認証が成立しているか |
| KMS machine name / KMS host | 表示されない／意味が薄いことが多い | 意図したKMSホストの名前になっているか | クライアントがどのKMSホストを参照しているか |
| Current count | カウントが増えているか | 通常は表示されない | KMSホストが受けた認証要求のカウント（環境の健全性確認に有効） |
| Partial Product Key | CSVLKの末尾 | GVLKの末尾 | 端末に入っているキーの一部。一致しなくて正常 |
特にクライアント側は、Volume:GVLK と Licensed が揃っていれば、Partial Product Keyが何であれ「KMSクライアントとして正常に認証できている」状態です。
KMSホスト側：確認チェックリスト（実運用向け）
「末尾が違うのは理解した。でも本当にKMSとして正しく動いているか確認したい」という場合は、ホスト側を次の観点で見ます。
ホスト自身が有効化されているか
まず、KMSホストがMicrosoftに対して有効化済みであることが前提です。ホスト上で次を実行します。
slmgr /dlv
slmgr /dli
slmgr /ato/ato はオンラインでの有効化を試みます（プロキシ環境などでは通信経路も要確認）。/dlv の License Status が Licensed であることを確認します。
1688/TCPで待ち受けているか（既定ポート）
既定ではKMSは TCP 1688 を使用します。ホストで待ち受けを確認します。
netstat -an | find "1688"ファイアウォール製品やWindows Defender ファイアウォールで遮断されると、クライアントはKMSホストに到達できません。ネットワーク機器のACLやセキュリティ製品も含めて「クライアント→ホスト間で1688/TCPが通るか」を確認します。
DNSの自動検出を使うならSRVレコードを確認
多くの環境では、クライアントはDNSのSRVレコード（_vlmcs._tcp）を参照してKMSホストを自動検出します。クライアントから次を確認します。
nslookup -type=SRV _vlmcs._tcpここで意図したFQDNやポートが返るかが重要です。DNSの分割管理や複数ドメイン構成では、SRVレコードが別ゾーンに登録されていたり、想定外のホストが応答してしまうことがあります。
カウント（Current count）が伸びているか
KMSには「認証要求が一定数に達するまで本格的に認証を返さない」という閾値（しきい値）があります。小規模環境や検証環境だと、ここが原因で「たまに認証できない／すぐ切れる」などの誤解が起きます。
- WindowsクライアントOS（例：Windows 10/11）：一般的に25台以上
- Windows Server：一般的に5台以上
ホスト側の slmgr /dlv に出る Current count を見て、カウントが増えているかも確認しましょう（環境により表示項目が多少異なります）。
クライアント側：確認チェックリスト（ここを押さえれば不安が消える）
「Volume:GVLK」になっているかを最優先で確認
クライアントで slmgr /dlv を実行し、Product Key Channel（またはDescription）に Volume:GVLK が表示されているかを確認します。
もし次のような表示になっている場合、KMS運用の前提が崩れている可能性があります。
- Volume:MAK：MAKで個別認証している（KMSではない）
- Retail：小売り（パッケージ）キーで認証している
- OEM：メーカー出荷時のOEM認証が優先されている
「KMSで認証したつもり」でも、イメージ展開や既存のキー、GPO、MDT/SCCMの設定などで別チャネルのままになっていることがあります。Partial Product Keyがどうこう以前に、まずチャネルを揃えるのが大切です。
KMSホストの向き先を確認・固定する（必要な場合のみ）
DNSの自動検出が使えない／別ネットワークで検証しているなどの場合、クライアントにKMSホストを明示します。
slmgr /skms kms-host.example.local:1688
slmgr /ato設定をクリアしたい場合は次です。
slmgr /ckmsDNS自動検出に戻したいのに /skms の設定が残っていて、古いホストを見続ける…という事故もあるため、切り分けでは「今どこを見に行っているか」を必ず把握します。
認証状態の再確認（Licensedと期限）
slmgr /dlv
slmgr /xprLicensedであれば基本的にOKです。KMSのライセンスは定期的に更新される仕組みで、通信できていれば自動的に延長されます。逆に言えば、期限が迫る・切れる場合は「KMSホストに到達できていない」「DNSが想定外」「ネットワーク境界で遮断」など運用の問題を疑います。
やってはいけない：クライアントにCSVLK（KMSホストキー）を入れて一致させようとする
Partial Product Keyが一致しないことを気にして、クライアントにCSVLKを入れてしまうのはおすすめできません。理由はシンプルで、CSVLKはKMSホストのためのキーであり、クライアント用ではないからです。
- 運用上、CSVLKは「ホスト機にのみ」保管すべき情報（漏えいリスク）
- クライアントに入れると、ライセンスチャネルが想定外になり切り分けが難しくなる
- 環境によっては、意図せずホスト化や認証挙動の変化を招く
「一致していること」よりも、「正しいチャネルでLicensedになっていること」を重視してください。
トラブルシューティング：認証が失敗する場合の代表的な原因
末尾不一致は正常ですが、もし Licensedにならない 場合は別の問題です。よくある原因をまとめます。
| 症状・メッセージ例 | ありがちな原因 | まずやること |
|---|---|---|
| 0xC004F074（KMSに接続できない） | DNS（_vlmcs._tcp）が不正、1688/TCP遮断、KMSホスト名誤り | nslookup -type=SRV _vlmcs._tcp、Test-NetConnection -ComputerName kms-host -Port 1688 |
| 0xC004F038（閾値未達） | 検証環境で台数が少ない、カウントが増えていない | KMSホストのCurrent count確認、台数・構成の見直し |
| 0xC004F050（キーが無効） | エディションに合わないGVLK、誤ったキー入力 | OSエディション確認→正しいGVLKを適用（手順や展開設定も確認） |
| Licensedだが想定と違う（MAK/Retail/OEM） | KMS以外のチャネルで認証している | slmgr /dlv のチャネル確認、展開イメージ／GPO／タスクシーケンスを確認 |
ネットワーク疎通の確認は、PowerShellが使えるなら次が便利です。
Test-NetConnection -ComputerName kms-host.example.local -Port 1688成功すれば、TCP 1688が到達できています。失敗する場合は、DNS解決・ルーティング・ファイアウォール・セキュリティ製品を順に疑います。
（補足）OfficeのKMSでも「末尾不一致」は同じ話
Windowsだけでなく、OfficeをKMSで認証している場合も考え方は同じです。
- Office KMSホスト：Office用のKMSホストキーでホストを有効化
- Officeクライアント：OfficeのGVLKに相当するキーでKMSへ問い合わせ
Officeの場合は ospp.vbs を使うことが多く、ここでも「Last 5 characters of installed product key」が表示されます。ホストとクライアントで一致しなくて正常です。
よくある質問（FAQ）
認証が通っているのに、なぜPartial Product Keyを表示するの？
監査・運用のためです。例えば「この端末はKMS向けのキー（GVLK）が入っているのか」「別チャネル（MAKやRetail）に変わっていないか」を、フルキーを晒さずに判断できます。ホストと一致させるための情報ではありません。
KMSホストを複数台置いたら、クライアントのPartial Product Keyは変わる？
基本的に変わりません。クライアント側のPartial Product Keyは「クライアントに入っているGVLK」の末尾なので、参照先のKMSホストを変えても末尾は同じです（ただし、エディション変更などでGVLKを入れ替えれば末尾は変わります）。
「一致している」端末を見つけた。問題？
状況次第ですが、少なくとも「KMSの想定とは違うキーが入っている」可能性があります。たとえばクライアントにCSVLKを入れてしまっている、展開イメージにホストキーが混入している、などです。slmgr /dlv のチャネルが Volume:GVLK かどうかを必ず確認してください。
Partial Product Keyは社外に共有しても安全？
フルキーではないため直ちに悪用されにくい情報ですが、組織のライセンス形態や運用状況の推測材料になります。サポートベンダーやMicrosoftサポートへ提示する場合でも、社内の情報管理ルールに従い、必要最小限の範囲で共有するのが無難です。
まとめ：末尾不一致は「異常」ではなく「KMSの仕様」
KMSホストとクライアントでPartial Product Keyが一致しないのは、ホストはCSVLK、クライアントはGVLKという別種のキーを使うからです。末尾一致にこだわる必要はありません。
不安になったら、次の順で確認すると最短で安心できます。
- クライアントの Product Key Channel が Volume:GVLK か
- License Status が Licensed か
- クライアントが参照するKMSホスト（DNS/SRVや
/skms設定）が意図通りか - ホストが有効化済みで、1688/TCPで待ち受けているか
この4点が揃っていれば、Partial Product Keyの末尾が違っていても、KMS運用としては問題ありません。
コメント