KMSサーバーでWindows 10クライアントを認証したつもりなのに、イベントID 12290などの認証ログに端末が見当たらない――この症状は「認証されていない」よりも、まず「KMSを経由していない」ケースが多いです。ログの正しい確認場所、クライアントが使っている認証方式の見分け方、ADベース認証（ADBA）だとKMSログに残らない理由と対処を具体的に解説します。
KMSサーバーでライセンス認証ログを確認する場所
KMSホスト（KMSサーバー）側で「KMSとして受け付けた認証要求」が記録されるログは、主にイベントビューアー内の専用ログです。まずは「見ているログが違う」パターンを潰すのが最短ルートです。
イベントビューアーの確認手順
- KMSホストに管理者権限でログオンします。
- 「イベント ビューアー」を開きます。
- 左ツリーから次のいずれかを確認します（環境により表示階層が異なる場合があります）。
- ［アプリケーションとサービス ログ］→［Key Management Service］
- ［アプリケーションとサービス ログ］→［Microsoft］→［Windows］→［Key Management Service］
このログに、KMSによるクライアントの認証イベント（例：イベントID 12290など）が記録されます。ここに出ていない場合は、「その端末がKMSホストへ到達していない」か「そもそもKMS以外で認証されている」可能性が高いです。
まず押さえる：KMSログは“受け付けたKMS要求”しか残らない
KMSホスト側のログは、KMSホストが受信した要求に対して記録されます。つまり、クライアントが別の方式（ADベース認証、MAK、個人向けデジタルライセンス等）でライセンス状態が「ライセンス認証済み」になっていても、KMSホストを通っていなければKMSホストのログには残りません。
| 観点 | KMSホスト側にログが残る | KMSホスト側にログが残らない |
|---|---|---|
| クライアントがKMSホストへTCP 1688で要求 | ○（KMS要求として記録される） | ― |
| ADベース認証（ADBA）で認証 | ― | ○（KMSホストを経由しない） |
| MAK（複数認証キー）など別方式で認証 | ― | ○（KMS要求が発生しない） |
| 別のKMSホストへ向いている | ―（今見ているKMSホストには出ない） | ○ |
最重要：そのクライアントは本当にKMSで認証しているか
「クライアント側で slmgr /dlv を見る」のが最優先です。ここで、どの認証チャネルを使っているか、KMSホスト名が見えているか、が一気に分かります。
クライアント側で確認するコマンド
管理者としてコマンドプロンプトを開き、次を実行します。
slmgr /dlvあわせて、状態の確認として次も有効です。
slmgr /dli（概要表示）slmgr /xpr（有効期限の概況）
slmgr /dlvで見るべきポイント
表示される項目名はOSビルドや言語で多少差がありますが、判断の軸は同じです。
| 確認ポイント | KMSで認証している時の傾向 | ADベース認証（ADBA）の時の傾向 |
|---|---|---|
| チャネル/説明（Description / Channel） | ボリュームライセンス（KMSクライアント）系の表記が出る | Active Directoryベースの認証を示す表記や、KMSホスト名が出ない構成になりやすい |
| KMSホスト名（KMS machine name / Host name） | FQDNやDNSから取得したKMS名が表示されることが多い | 表示されない／KMSを指す情報が薄いことが多い |
| ライセンス状態 | ライセンス認証済み（Licensed） | ライセンス認証済み（Licensed） |
| “認証済み＝KMS”とは限らない | どの方式でも「ライセンス認証済み」になり得るため、方式の判定が重要 | |
クライアントのイベントログで「問い合わせ先」を補強する
KMSの場合、クライアントはKMSホストへ問い合わせを行い、その結果がクライアント側ログにも残ります。クライアント側で「どこへ問い合わせたか」を追うと、KMSホスト側ログに出ない理由が見えやすくなります。
- イベントビューアー → ［アプリケーションとサービス ログ］→［Microsoft］→［Windows］→［Security-SPP］
- イベントID（例：12289など）で成功・問い合わせの痕跡を確認
もしここで、KMSホストへの通信（ホスト名や到達）を示すログが薄い／別の挙動が見える場合は、KMS以外の方式（特にADベース認証）を疑うべきです。
KMSサーバーにログが出てこない“本命”原因：ADベース認証（ADBA）
ドメイン参加済みのWindowsでは、組織の構成によってはKMSではなくActive Directoryベースのライセンス認証（ADBA）で自動的にアクティブ化されることがあります。この場合、クライアントはKMSホストを経由しません。
そのため、次の現象が同時に起きます。
- クライアント側：
slmgr /dlvでは「ライセンス認証済み」になっている - KMSホスト側：イベントID 12290などのKMS関連ログに、そのクライアントが一切出てこない
これは矛盾ではなく、認証経路が違うだけです。KMSログに端末がいないからといって、直ちに「未認証」と判断しないのが運用上の重要ポイントです。
なぜADBAだとKMSログに残らないのか
KMSは「KMSホストに対して定期的に問い合わせる」方式です。一方、ADBAは「ドメイン参加していること（AD上の仕組み）を使って認証する」方式であり、KMSホストへの問い合わせが発生しません。したがって、KMSホストのKey Management Serviceログに記録される余地がありません。
KMSログに“その端末”を表示させたい場合の対応
監査や運用の都合で「KMSホスト側のログに端末を出したい」場合は、対象端末がKMSを使うように明示します。代表的なのが、slmgr /skmsでKMSホストを指定し、slmgr /atoで再認証する手順です。
手順：KMSホストを明示してKMSで再認証する
- KMSホストのFQDNを確認します（例：
kms01.example.local）。 - クライアントで管理者として次を実行します。
slmgr /skms kms01.example.local
slmgr /ato再認証が成功すると、KMSホスト側の「Key Management Service」ログに、その端末の要求が記録されるようになります（KMS要求として到達している場合）。
補足：DNS自動検出に戻したい場合
一時的な切り分けで/skmsを設定した場合、後で自動検出（DNSのSRVレコード参照）に戻したいことがあります。その場合は手動指定をクリアします。
slmgr /ckms
slmgr /atoこの状態でDNSに _vlmcs._tcp のSRVレコードが正しく登録されていれば、クライアントは自動的にKMSホストを見つけます。
“特定のクライアントだけKMSログに出ない”ときの原因チェックリスト
ADBA以外にも、「その端末だけ出ない」にはいくつか定番原因があります。下の表の順に確認すると、無駄な遠回りを避けられます。
| よくある原因 | 症状の特徴 | 確認ポイント | 対処の方向性 |
|---|---|---|---|
| ADベース認証（ADBA）で認証されている | クライアントは認証済みだがKMSホストに痕跡がない | slmgr /dlvで方式を確認 | KMSに統一するなら/skms→/ato |
| 別のKMSホストへ問い合わせている | 別ホストのログには出る／このKMSだけ出ない | slmgr /dlvでKMSホスト名、DNS SRVの参照先 | DNSのSRV、GPO、手動/skms設定を整理 |
| 手動でKMSホストが固定されている | いつまでも古いKMSへ向く | slmgr /dlv、過去の設定有無 | slmgr /ckmsで解除し、自動検出へ |
| ネットワーク/ファイアウォールでKMSへ到達できていない | /atoが成功しないのが通常だが、切替直後に顕在化することも | KMSは通常TCP 1688、疎通、名前解決 | FW例外、経路、名前解決、プロキシ影響を確認 |
| イベントログの保存容量が小さく、上書きされている | 端末は認証したがログがすぐ消える | ログの最大サイズ、保持設定、監査期間 | ログサイズ拡張、転送（WEF等）、SIEM連携 |
KMSホスト側で“見落とし”がちな確認ポイント
ログの場所が合っていても、運用設定のせいで「見えていない」ことがあります。KMSのトラブルシューティングでは、次の3点が効きます。
ログのフィルター条件をリセットする
イベントビューアーでフィルター（イベントID、キーワード、期間）が残ったままだと、存在するログが表示されません。特に「過去○日」や「特定IDのみ」で絞った状態で探し続けるケースが多いので、一度フィルターを解除してから再検索します。
ログの保持設定（最大ログサイズ）を見直す
KMSの要求が多い環境では、既定のログサイズだと上書きが速いことがあります。監査用途で「いつ・どの端末が認証したか」を追うなら、最低でも次を検討すると安全です。
- Key Management Serviceログの最大サイズを増やす
- 「必要に応じて上書き」ではなく、運用ルールに合わせた保持/アーカイブ
- Windowsイベント転送（WEF）やログ収集基盤への転送
KMSホスト自身の状態も把握する
KMSホスト側でも、状態把握のためにslmgrが使えます。ホストで実行すると、KMSホストとしての情報（設定状況、受付状況など）を確認できます。
slmgr /dlv「そもそもKMSホストとして正しく構成されているか」「想定外の変更が入っていないか」を、ログと合わせて確認すると切り分けが速くなります。
具体的な切り分け手順（迷ったらこの順番）
現場で再現性の高い順序に並べると、次のフローが最短です。ポイントは「KMSホストを探す」より先に「認証方式を確定」することです。
- クライアントで
slmgr /dlvを実行し、認証方式とKMSホスト情報の有無を確認する - クライアントのイベントログ（Security-SPP）で、KMS問い合わせや認証方式の痕跡を確認する
- KMSホストのKey Management ServiceログでイベントID 12290などの記録を検索する
- クライアントがADBAなら、KMSログに出ないのが正常であると判断し、運用方針（ADBA継続／KMS統一）を決める
- KMSに統一するなら、
slmgr /skms→slmgr /atoで明示的にKMS経由へ切り替え、KMSホスト側ログに記録されることを確認する
運用上のポイント：KMSとADBAを混在させるなら“監査の設計”が必要
ADBAはドメイン参加端末の運用を楽にしますが、「KMSホストのログを見れば全部追える」という前提は崩れます。混在環境で監査性を確保したい場合は、次のどちらかの設計が現実的です。
| 方針 | メリット | 注意点 |
|---|---|---|
| KMSに統一（KMSホストで一元的に監査） | KMSホストのログに要求が集約され、追跡しやすい | KMS到達性（NW/FW）とKMSホストの冗長化が重要 |
| ADBAを優先（運用簡素化）＋クライアントログ収集 | ドメイン参加端末の自動認証が安定しやすい | KMSホストログだけでは追えないため、端末側ログや資産管理の連携が必要 |
「KMSログに出ない端末がある＝異常」ではなく、どの方式で認証させるかを先に決め、その方式に合わせてログの取り方を設計するのが、現場でのトラブルを減らすコツです。
よくある質問
slmgr /atoを実行したのに、KMSサーバーにログが出ません。なぜですか？
/atoは「今の端末設定で有効化を試みる」動作です。環境がADBAを優先する構成だったり、端末がKMSホストを参照していなかったりすると、KMSホストに要求が飛ばず、結果としてKMSホストのログにも残りません。まずはslmgr /dlvで方式と参照先を確定してください。
KMSホスト側ログに端末名が見えません。IPだけですか？
ログに残る情報はイベントの種類や環境の設定に依存します。端末名が追いづらい場合は、クライアント側のSecurity-SPPログ（問い合わせ時刻、参照先）や、DHCP/DNSのログ、資産管理ツールと突合する運用が現実的です。監査で端末特定が必須なら、ログ保持・収集基盤（転送）の整備もセットで検討してください。
無理にKMSへ切り替えても問題ありませんか？
技術的には可能でも、組織のライセンス運用ポリシーや設計意図（ADBAを使う前提）がある場合があります。監査要件や管理要件を踏まえ、どの方式に統一するかを決めてから切り替えるのがおすすめです。実施は必ず正規のボリュームライセンス管理の範囲で行ってください。
まとめ
KMSサーバーでイベントID 12290などの認証ログが見つからないとき、最初に疑うべきは「未認証」ではなく認証方式がKMSではない可能性です。特にADベース認証（ADBA）でアクティブ化されている端末はKMSホストを経由しないため、KMSログに出ないのが正常です。クライアントのslmgr /dlvで方式と参照先を確定し、必要に応じてslmgr /skms→slmgr /atoでKMS経由へ切り替えることで、KMSホスト側に認証イベントを記録させられます。
コメント