Office LTSC Professional Plus 2024 を新しい Windows 11 PC で再アクティブ化しようとしたら「このプロダクトキーは上限に達しました」と表示されてしまうことがあります。古い端末ではきちんとアンインストールしたはずなのに、なぜ認証に失敗するのか。本記事では、原因となるボリュームライセンス（MAK）の仕組みから、具体的な確認コマンド、Microsoft への連絡方法、再発防止策までをまとめて解説します。
Office LTSC Professional Plus 2024 で「上限に達しました」が出る典型的な状況
まずは、どのようなときに「このプロダクトキーは上限に達しました」と表示されるのか、よくあるパターンを整理します。
- 古い PC から Office をアンインストールして、新しい PC に Office LTSC Professional Plus 2024 を再インストールした。
- OS を再インストールしたり、マザーボード交換などでハードウェア構成が変わった。
- 仮想マシン（VDI/仮想デスクトップ）を頻繁に作り直している。
- 展開用イメージを作る際に、すでにアクティブ化済みの状態でクローンしてしまった。
端末変更や再展開があった場合は、認証方式・該当キー・使用数の照合が必要です。これらの作業を行ったというだけで、すべてが上限エラーの原因だとは判断できません。特にMAKの認証回数と購入ライセンスの管理は分けて確認します。
- Office のアンインストールや PC の初期化を行っても、消費済みの回数は自動的には戻らない
- Microsoft アカウントに結びつく個人向け Office とは挙動がまったく違う
という点です。
先に確認すること：方式・エラーコード・契約側の使用数
- Word等の［ファイル］→［アカウント］で製品名を確認し、下のospp.vbsで対象製品・方式・キー末尾5文字を照合する。
- 「MAK」と表示されるだけで上限と断定しない。画面に出たエラーコードと説明を記録する。
- 契約担当者がMicrosoft 365管理センターのボリュームライセンスで該当キーの使用数を確認し、必要なら上限引き上げを申請する。
認証できたことと契約上の利用権は別です。Microsoftのボリュームキー資料は、MAKの認証可能回数が購入ライセンス数と常に一致するわけではなく、上限引き上げは例外として審査されると説明しています。キーの削除・再入力、Officeのアンインストールで上限を戻す手順ではありません。
Office LTSC Professional Plus 2024 のライセンス方式を理解する
トラブルを根本から理解するために、Office LTSC Professional Plus 2024 のライセンス方式を簡単に整理しておきます。
ボリュームライセンス（VL）専用の Office である
Office LTSC Professional Plus 2024 は、ボリュームライセンス（VL）契約専用のエディションです。一般の家電量販店や Microsoft ストアから購入できる「個人向け Office」とは仕組みが異なります。
| 項目 | Office LTSC Professional Plus 2024 | Microsoft 365 / 個人向け Office |
|---|---|---|
| ライセンス形態 | ボリュームライセンス（VL） | サブスクリプション / リテール |
| アクティベーション方式 | MAK / KMS / ADBA | 購入・組織契約に応じたアカウント認証 |
| 端末の入替時 | MAKの使用数と利用権を確認 | アカウント側で再インストール可 |
| 想定利用 | 企業・組織 / 管理者主導 | 製品・プランに応じた個人／組織利用 |
この違いを理解していないと、「古い PC からアンインストールしたのになぜ？」という疑問が生まれてしまいます。
MAK / KMS / ADBA の違い
| 方式 | 認証先と前提 | 上限エラーとの関係 |
|---|---|---|
| MAK | Microsoftの認証サービス。キーに所定の認証可能回数 | 対象のMAK使用数を契約側で確認 |
| KMS | 組織が構成したKMSホストとGVLK。定期的な更新が必要 | クライアントのMAK残数とは別。ホスト・到達性・必要な要求数を確認 |
| ADBA | AD DSの認証オブジェクト、ドメイン参加PCとGVLK | Microsoftアカウントへのサインインだけでは利用できない |
MAKの導入方法は公式MAK資料、ADBAの要件は公式Active Directoryベース認証資料で確認できます。自分のPCに複数製品やライセンスが入っている場合は、Office LTSC Professional Plus 2024に対応する出力を選んで調べます。
自分でできる切り分けと再試行手順
いきなりサポートに連絡する前に、管理者やユーザーが自力でできる切り分け・確認作業をステップ順に解説します。
ステップ 1：対象製品・方式・状態を読み取る
管理者としてコマンドプロンプトを開きます。公式ospp.vbs資料の現行パスは次のとおりです。まずその場所にospp.vbsが存在するか確認し、存在するフォルダーで実行します。
cd /d "C:\Program Files\Microsoft Office\root\Office16"
cscript ospp.vbs /dstatusall64bit Windowsに32bit Officeを入れた場合は、Program Files (x86)側です。旧版ではrootを含まないパスもあります。移動に失敗したまま別のフォルダーで実行せず、実際のインストール先を確認してください。
cd /d "C:\Program Files (x86)\Microsoft Office\root\Office16"
cscript ospp.vbs /dstatusall| 出力 | 確認する意味 |
|---|---|
| LICENSE NAME / DESCRIPTION | 対象が2024 Professional Plusか、MAKかKMS clientかを確認 |
| LICENSE STATUS | LICENSED等の現在の認証状態 |
| Last 5 characters | 契約側で確認するキーの末尾5文字と一致するか |
このスクリプトはMicrosoft 365 Appsのサブスクリプション認証用ではありません。また、クライアントの状態表示だけでMAKの契約側の残数は分かりません。MAK方式という事実と、上限到達という診断を分けてください。
ステップ 2：キーを消す前に、表示されたエラーを確認する
エラー帯・ダイアログのコードを控え、説明を表示します。以下の0xC004C020は例なので、実際に出たコードへ置き換えてください。説明を表示する操作であり、認証回数のリセットではありません。
cscript ospp.vbs /ddescr:0xC004C020過去のMAK／リテール認証失敗を確認する場合は、次の履歴表示が使えます。
cscript ospp.vbs /dhistoryacterrOfficeの公式切り分け資料では、画面のエラーコードと/ddescrを使う方法が案内されています。/unpkeyはキーを削除し、/inpkeyはキーを置き換える操作です。上限かどうかの確認のために有効なキーを削除する必要はありません。別キーへ変更する場合は管理者が契約と製品適合を確認して実施します。
ステップ 3：通信エラーならネットワークを確認する
エラー説明が通信に関する内容なら、組織のプロキシ・ファイアウォール・認証通信のログを管理者と確認します。公式資料は認証を要求するプロキシ経由のMAK認証に制約があると説明しています。保護機能を一括停止して確かめる方法にはしません。
- Windowsの日時・タイムゾーンが正しいかを確認する。
- MAKとKMSのどちらへ接続する処理かを先に確認する。
- ネットワーク設定を修正した後、管理者が必要な認証を再試行し、表示されたコードを比較する。
時刻や通信の確認が済んだことだけでは、MAK上限を証明できません。上限の説明が表示されている場合は、契約側の使用数を照合する手順へ進みます。
ステップ 4：KMS / ADBAは管理者の構成計画として検討する
再イメージや入替が多い組織では認証方式の見直しを検討できます。ただし、MAKのまま/sethstでホスト名を設定するだけではKMSへ移行しません。公式資料はMAKからKMSへ戻す場合、対象製品に合うKMSクライアントGVLKが必要と説明しています。
Office KMSの公式資料では、対応ホストが構成され、5件以上の要求に達することが認証開始の条件です。通常DNSでホストを探し、認証状態は180日間、標準では7日ごとに更新を試みます。ADBAはAD DSへのドメイン参加と認証オブジェクト等が必要です。個人PCで任意の外部KMSへ接続する対処には使いません。
ステップ 5：現行のProduct Activation Portalを確認する
Microsoftは2025年12月3日から、従来の電話による自動製品認証をオンラインのProduct Activation Portalへ移しました。オフライン端末向けの認証も引き続きサポートされます。古い解説の「オペレーターがその場で上限を解除する」という結果を前提にしないでください。
公式ページからポータルへ進み、CAPTCHAとサインイン後、製品の認証またはVolume License Key Managementの該当する項目を選びます。後者にはMAK／KMSの上限や例外に関する案内があります。ポータルのサインインアカウントは、製品ライセンスに紐づけるためではなくポータルへのアクセス確認用です。追加サポートの可否や上限引き上げは条件・審査によります。
「上限に達しました」メッセージの正体と MAK の仕組み
ここからは、少し踏み込んだ技術的な話になりますが、「上限に達しました」の意味をきちんと理解しておくと、今後の運用設計に大きく役立ちます。
MAKの認証回数と購入ライセンス数は同じとは限らない
MAKには所定の認証可能回数がありますが、単純に「購入50台＝50回」「認証を試すたび必ず1回」と計算して残数を判断しないでください。同じ端末の再認証や展開方法も含め、実際の使用状況を管理センターまたは対応VAMTで照合します。アンインストールを「契約ポータルの認証回数を戻す操作」として扱わないことが大切です。
- Microsoft 365管理センター→［課金］→［お使いの製品］→［ボリュームライセンス］を開く。
- ［製品とサービス］のダウンロードとキーを表示し、対象製品を選ぶ。
- ［キー］のLicense ID・Type・キー末尾を照合し、［Activations or Seats］の使用数と全体数を確認する。
表示には対象License IDのVL AdministratorまたはProduct keys reader等の権限が必要です。詳細は公式のキー表示・使用数確認手順を参照してください。個人のOfficeアカウント画面へキーが登録されることを前提に探すと、VLの確認先を取り違えます。
イメージ展開前に認証状態を整える
マスターを複製した台数だけで認証使用数を推定せず、展開記録と実際のキー使用数を照合します。公式のイメージ作成手順では、Office入りOSイメージをキャプチャする前にrearmが必要で、MAK利用時にも推奨されています。これは猶予期間やCMIDを整える展開用処理であり、MAKのサーバー側の上限を増やす処理ではありません。
管理者はOfficeアプリを閉じて公式手順に従い、成功を確認してからキャプチャします。その間にOfficeアプリやospp.vbsを実行すると猶予タイマーが開始するため、作業手順に含めないよう管理します。展開後の認証方法とライセンス利用権は別途確認してください。
よくあるエラーと確認先の対応表
| 表示・方式 | 先に確認すること | 次の対応 |
|---|---|---|
| MAK上限を示す説明 | 該当製品とキー末尾、契約側使用数 | 契約担当者が必要数と理由を添えて増枠を申請 |
| 通信できないという説明 | MAK/KMSの方式、プロキシ等のログ | 該当する認証経路を管理者が確認 |
| KMS clientで更新できない | ホスト構成・DNS・到達性・要求数 | KMSの条件を確認。MAK残数の申請と混同しない |
| 有効期限に関する表示 | ライセンス状態と方式 | KMSの更新失敗もあり得る。直ちに評価版と断定しない |
メッセージの要約だけで対処を選ばず、エラーコードと/ddescrの説明を添えて比較してください。
Microsoft ボリュームライセンスサポートへ連絡するときのポイント
エラーと該当MAKの使用数を確認したら、契約担当者がMicrosoft 365管理センターの［ヘルプとサポート］または公式のボリュームライセンス窓口へ相談します。旧VLSCだけを探し続けないでください。
事前に用意しておくとよい情報
- 組織名 / 部署名 / 担当者名 / 連絡先メールアドレス
- ボリュームライセンスの契約番号（Agreement Number / Enrollment Number 等）
- 問題が発生している MAK プロダクトキーの末尾 5 桁
- 現在の利用台数、今後の端末追加・入替の予定
- 「古い端末からは Office をアンインストール済み」などの運用状況の説明
公式の増枠申請には、契約／登録番号またはLicense ID、製品名・版・エディション、キー末尾5文字、必要な認証数、展開の業務上の理由が必要です。一律の「回数リセット」と考えず、該当契約に基づく追加認証の必要性を説明します。増枠は例外扱いであり、申請すれば必ず認められるものではありません。完全なキーは公開の掲示板や画面キャプチャへ載せないでください。
- MAK のアクティベーション回数が上限に達しているかどうかの確認
- 必要な追加認証数と展開理由を説明して増枠の可否を相談
について問い合わせます。契約に基づく利用権や例外の条件を確認するため、上限が必ず調整されると考えないでください。
認証操作と増枠申請を分ける
製品を認証する操作と、VL契約に基づいて認証可能回数を増やす申請は別です。Product Activation PortalでVolume License Key Managementを選ぶ場合も、契約情報と業務上の理由を準備します。管理センターに入れない場合は、公式資料にある窓口からアクセス権や問い合わせ先を確認してください。急いでいることだけで例外が認められるとは限りません。
再発防止のためのチェックリスト
最後に、認証の行き違いを減らすための運用チェックリストをまとめます。組織のルールとしてドキュメント化しておくのがおすすめです。
| 項目 | 内容 | ポイント |
|---|---|---|
| 展開用イメージの状態 | Officeを公式手順でrearmしてからキャプチャする | キャプチャ中はOfficeやospp.vbsを起動しない |
| MAK 残数の把握 | 定期的に MAK の使用状況・残数を記録 | 端末入替計画と照らし合わせて事前に増枠相談 |
| ライセンス方式の選定 | 再イメージ・入替が多い場合は KMS / ADBA を優先 | 小規模拠点のみ MAK のように使い分ける設計 |
| 退役端末の取り扱い | 初期化・廃棄は情報漏えい対策として必須 | ただし MAK 回数は戻らないことを周知 |
| ライセンス情報の保管 | 契約番号・キー情報・窓口情報を安全な場所へ | 担当者が変わってもすぐに連絡できるようにする |
WindowsとOfficeの認証を分けて記録する
Windows 11への移行では、PC入替・Windows更新・Officeの版変更を同時に行うことがあります。ospp.vbsが扱うOfficeのクライアント認証と、Windowsの認証は別です。Windowsが認証済みでも、Office LTSC 2024の利用権とキーの状態は別に確認してください。
TPM・Secure Boot・BitLockerを変更すると必ずOfficeのMAK回数を消費する、という切り分けにはしません。変更した製品・端末・認証方式・出たコードを記録し、実際の使用数と照合します。
- 現行のキー使用数とLicense ID
- 端末入替とOfficeの版変更を分けた計画
- 必要ならKMS／ADBAの前提を満たすかの管理者確認
管理者視点での運用ベストプラクティス
実務の現場目線で、Office LTSC Professional Plus 2024 を長期的に安定運用するためのベストプラクティスをいくつか紹介します。
1. ライセンス方式を「設計」として決めておく
単に「VL だから MAK キーをもらったので使っている」という状態ではなく、
- 本社・大規模拠点は KMS / ADBA
- ネットワークが独立している小規模拠点のみ MAK
- テスト用や PoC 用には別の MAK を割り当てる
というように、「どこでどの方式を使うか」をあらかじめ設計しておくことが重要です。これにより、MAK の消費状況を予測しやすくなり、サポートへの増枠依頼も計画的に行えます。
2. 展開プロセスをドキュメント化する
展開担当者やヘルプデスク担当者が変わっても運用がぶれないように、
- マスターイメージ作成時の手順（アクティベーションのタイミングを含む）
- 新規端末セットアップ時の手順
- 退役端末の処理フロー
をドキュメント化しておくと、人的ミスによる無駄な回数消費を減らすための確認に使えます。
3. ログと記録を残す
どの MAK をどの時期にどれだけ使ったかを把握していないと、「いつの間にか上限に達していた」という状況に陥りがちです。
- 導入台数・入替台数を Excel や管理ツールに記録する
- アクティベーション時の画面キャプチャやメモを残す
- サポートへの問い合わせ履歴（増枠履歴）を共有フォルダなどで管理
といった運用で、ライセンスの履歴を「見える化」しておくことをおすすめします。
まとめ：対象製品とエラーを確認し、必要なら契約担当者へ
Office LTSC Professional Plus 2024で上限の表示が出たら、対象製品・認証方式・キー末尾・エラー説明を確認します。MAKの表示だけで上限と断定せず、管理センターの使用数を契約担当者と照合してください。
- /dstatusallとエラー説明を記録し、有効なキーを確認のために削除しない。
- MAKの使用数・契約上の利用権・必要な追加認証数を分けて確認する。
- 必要な増枠は公式窓口へ理由を添えて申請する。認められるかは審査による。
- 展開イメージのrearm、使用数記録、適切なKMS／ADBA計画で運用を整える。
コメント