Windows 10 Enterprise LTSC を使い続けてきたPCを、Windows 11 Enterprise LTSC 2024 へ移行したい。しかし「そのままアップグレードできるのか」「購入した“Windows 11 Enterprise 2024 アップグレード ライセンス”のキーで今の Windows 10 LTSC を直接認証できるのか」で判断に迷うケースは少なくありません。この記事では、LTSC特有の前提を整理し、インプレース／クリーンインストールそれぞれの実務手順と、ライセンス認証の考え方を具体的にまとめます。
最初に確認：あなたが目指しているのは「Windows 11 Enterprise」か「Windows 11 Enterprise LTSC 2024」か
まず最重要ポイントとして、Windows 11 には「通常の更新チャネル（一般提供チャネル）」の Enterprise と、「長期サービスチャネル（LTSC）」の Enterprise LTSC が別物として存在します。購入した“アップグレード ライセンス”の名称が似ているため、ここがズレると手順もライセンスも噛み合わなくなります。
| 項目 | Windows 11 Enterprise（通常） | Windows 11 Enterprise LTSC 2024 |
|---|---|---|
| 位置づけ | 一般的な業務PC向け（機能更新を継続） | 変更を最小化したい“特定用途”向け |
| 更新の考え方 | 機能更新（例：24H2 など）を追随 | 数年ごとの“新しいLTSCリリース”へ移行 |
| よくある誤解 | 「2024」と書いてあればLTSCだと思う | “LTSC 2024”は明記されている必要がある |
Microsoftの商用ライセンスの整理でも、Windows 11 Enterprise と Windows 11 Enterprise LTSC は別の提供枠として扱われています。請求書や契約明細、管理ポータル上の製品名が 「Enterprise LTSC」まで含んでいるか を最初に確認してください。
LTSCの基本：アップグレードは「頻繁な機能更新」ではなく「数年ごとのリリース移行」
LTSC（Long-Term Servicing Channel）は、一般的なWindowsのように新機能を頻繁に取り込む運用ではなく、月例の品質更新（セキュリティ／修正）を中心に、必要に応じて数年ごとに新しいLTSCへ移行する考え方です。Microsoft Learn でも、LTSCは数年ごとのリリースであり、必要ならインプレースアップグレードで導入したり、リリースをスキップする判断もできる旨が説明されています。
また、LTSC は原則として「ほとんどのPCに広く展開するためのエディション」ではなく、規制・認証・固定用途など、変更管理を厳密にしたい特殊用途向けという前提があります。社内標準PCの全面LTSC化は、アプリ互換や運用の面で別のリスクが出るため、移行の目的（何を守りたいのか）を言語化しておくと判断がブレません。
バージョン確認：今の Windows 10 LTSC が「2019/2021」どちらかで手順が変わる
Windows 10 Enterprise LTSC と一口に言っても、世代があります。まずは現在のLTSC世代を特定してください（例：LTSC 2019 / LTSC 2021）。
GUIで確認
- Win + R → winver → バージョン／OSビルドを確認
- 設定 → システム → 詳細情報 → Windowsの仕様
コマンドで確認（管理者 PowerShell）
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber参考として、Microsoft Learn の LTSC 概要には、LTSCと一般提供チャネル（GAチャネル）の対応関係が整理されています。
| LTSCリリース | 対応するGAチャネル相当 | 提供開始日 |
|---|---|---|
| Windows 11 Enterprise LTSC 2024 | Windows 11 Version 24H2 | 2024/10/01 |
| Windows 10 Enterprise LTSC 2021 | Windows 10 Version 21H2 | 2021/11/16 |
| Windows 10 Enterprise LTSC 2019 | Windows 10 Version 1809 | 2018/11/13 |
結論：移行パターンは「インプレース」か「クリーンインストール」の2択（現場では両方を検討）
Windows 10 Enterprise LTSC から Windows 11 Enterprise LTSC 2024 へ移行する際、現場の選択肢は次の2つです。
| 方式 | 向いているケース | メリット | デメリット／注意点 |
|---|---|---|---|
| インプレースアップグレード（上書き） | 現在が LTSC 2021 で、端末状態が健全・標準化されている | アプリ／ユーザーデータを保持しやすい（条件を満たす場合） | 互換性判定で「アプリを保持」が選べない／失敗時の切り戻しが必要 |
| クリーンインストール（再展開） | LTSC 2019以前、構成がバラバラ、不要ソフトが多い、刷新したい | 不具合を持ち越しにくい。運用を再標準化しやすい | アプリ再導入・設定復旧が必須。工数が増える |
なお、Windows 11 Enterprise LTSC 2024 は Windows 10 Enterprise LTSC 2021 をベースにした位置づけで、提供開始日やライフサイクル（Enterprise LTSCは5年、IoT Enterprise LTSCは10年）が明記されています。移行先が LTSC 2024 で本当に良いか（5年で再移行が必要になる想定か）も、ここで合わせて検討してください。
インプレースアップグレードが成立する条件チェック
インプレースアップグレードを「手順」として成立させるには、OSの種類が合っているだけでは足りません。現場で詰まりやすいポイントを先に潰します。
エディション／アーキテクチャ／言語の一致
- 同一アーキテクチャ（64bit→64bit）
- 同一言語（例：日本語OSに英語ISOだと“アプリ保持”が出ない原因になりやすい）
- 同系統のエディション（Enterprise LTSC を Enterprise LTSC へ）
Windows 11 のハードウェア要件を満たしているか
Windows 11 には明確な要件があります。特に企業端末で引っかかるのは TPM 2.0 と UEFI／セキュアブート です。
| 要件 | 確認方法（例） | 満たしていない場合の典型原因 |
|---|---|---|
| TPM 2.0 | tpm.msc で「仕様バージョン 2.0」確認 | BIOS/UEFIでTPMが無効、またはTPM 1.2 |
| UEFI／セキュアブート対応 | システム情報(msinfo32)でBIOSモード／セキュアブート状態 | Legacy/CSM起動、ディスクがMBR |
| メモリ／ストレージ | 設定→システム→詳細情報 | ストレージ逼迫でアップグレード失敗 |
TPM 2.0 は Windows 11 に必要であり、未有効の端末ではUEFI設定で有効化が必要になることがあります（Intel PTT / AMD fTPM など表記が異なる）。セキュアブートも同様に、UEFI設定側で切り替えるケースが多いです。
PowerShellで簡易確認（管理者）
# TPM
Get-Tpm
# Secure Boot（UEFI環境のみ）
Confirm-SecureBootUEFI手順：インプレースアップグレードで Windows 11 Enterprise LTSC 2024 へ移行する
ここでは「既存のWindows環境を残したまま」移行する流れを、現場の順序でまとめます（管理ツール配布でも、ローカル作業でも、やることの本質は同じです）。
作業前：バックアップと“戻れる状態”を作る
- ユーザーデータ（ドキュメント、デスクトップ、業務データ）の退避
- アプリ一覧の記録（インストール済みアプリ、ライセンス情報）
- BitLocker を使っている場合は回復キーの保全、必要に応じて一時停止
- 端末固有ドライバ（特にストレージ／ネットワーク）の入手経路を確保
作業前：インストールメディア（ISO）を用意する
Enterprise LTSC のメディアは、一般向けの「Media Creation Tool」から簡単に取れる類のものではありません。組織の入手経路（ボリュームライセンス／CSP／OEM等）で提供される正規の ISO を用意してください。
作業当日：ISOを“Windows上で”マウントして setup.exe を実行
- ISOを右クリック → マウント（仮想DVDとして表示）
- 仮想DVD内の setup.exe を起動（USB起動ではない）
- 更新プログラムの取得（Dynamic Update）は、社内ポリシーに合わせて選択
- 「引き継ぐ項目の選択」で 個人用ファイルとアプリを引き継ぐ を選択
- インストール開始 → 再起動を複数回実行 → 完了
“個人用ファイルとアプリを引き継ぐ”が選べないときのチェック項目
- ISOの言語が現在のOSと一致しているか
- ISOをUSB起動していないか（起動すると保持オプションが変わりやすい）
- 空き容量不足や互換性NGのアプリ（古いVPN/セキュリティ/仮想化系）がないか
- エディションがズレていないか（Enterprise LTSC → 別エディション等）
作業後：Windows Update、ドライバ、業務アプリの動作確認
- Windows Update を適用（品質更新）
- デバイスマネージャーで不明なデバイスがないか確認
- 社内エージェント（EDR、資産管理、VPN、証明書、プリンタ）動作確認
- ライセンス認証状態の確認
手順：クリーンインストールで Windows 11 Enterprise LTSC 2024 へ移行する
「確実性」を優先するならクリーンインストールが強い選択肢です。特に LTSC 2019 以前、構成が長年積み上がっている端末、トラブルを抱えがちな端末では、移行後の安定稼働までの総工数が結果的に小さくなることがあります。
作業前：移行設計（復元できないものを洗い出す）
- ユーザーデータの退避（OneDrive KFM等を使っている場合は同期状態も確認）
- ブラウザ証明書、VPN設定、RDP設定、業務アプリのライセンス情報を保全
- ドメイン参加／Entra ID参加の方式、MDM（Intune等）登録手順を確認
- BitLocker回復キーの保全
作業当日：UEFI設定と要件の最終確認
Windows 11 は UEFI とセキュアブート対応、TPM 2.0 が要件に含まれます。導入前にBIOS/UEFI側の設定を整えてください。
クリーンインストール実施（概要）
- Windows 11 Enterprise LTSC 2024 のインストールUSBを作成
- USB起動 → セットアップ開始
- 対象ディスクのパーティション設計（必要なら全削除して新規作成）
- インストール完了 → 初期設定
- ドライバ／更新適用 → 業務アプリ再導入 → データ復元
クリーンインストールは「何も残らない」代わりに、不要物も不具合も持ち越しません。導入後の標準化（ベースイメージ、プロビジョニング、ポリシー適用）ができている組織ほど、クリーンインストールの費用対効果が上がります。
質問の核心：購入した“Windows 11 Enterprise 2024 アップグレード ライセンス”のキーで、今の Windows 10 LTSC を直接アップグレード＆認証できる？
結論から言うと、プロダクトキーを入力するだけでWindows 10 LTSCがWindows 11 LTSCに「変身する」ことはありません。OSの世代（Windows 10 → Windows 11）を変えるには、必ずセットアップ（ISO/メディア）による置き換えが必要です。つまり「直接アップグレード」と言っても、実体は setup.exe によるインプレースアップグレード か クリーンインストール のどちらかになります。
一方で、購入したキーが “Windows 11 Enterprise LTSC 2024 を有効化できる種別（MAK等）” であれば、Windows 11 のインストール後に ライセンス認証へ使うことは一般的に可能です。ここで重要なのは、「ライセンス（権利）」と「認証（アクティベーション）」は別物 という点です。
| 区分 | 意味 | 現場で起きがちな勘違い |
|---|---|---|
| ライセンス（使用権） | そのWindowsを使ってよい“権利” | キーを買った＝どのエディションでも入れられる |
| 認証（アクティベーション） | インストール済みOSが正規であることの確認 | 認証できた＝ライセンス要件も満たしている |
Enterprise/LTSCの認証パターン：KMS/MAK/サブスク（E3/E5）で挙動が違う
Windows Enterprise は、組織の契約形態により、認証方式が変わります。代表例は次の3つです。
KMS（社内KMSホストで認証）
KMS環境では、クライアントは GVLK（汎用のKMSクライアントキー） を使って社内KMSホストへ到達し認証します。GVLK自体は“ライセンスキー”ではなく、KMSで認証するためのキーです（KMSホストや契約が前提）。
Microsoft Learn には、Windows 11/10 の Enterprise や Enterprise LTSC 2024/2021/2019 向けの GVLK が一覧で掲載されています（例：Enterprise は NPPR9-…、Enterprise LTSC 2024/2021/2019 は M7XTQ-…）。
確認コマンド
slmgr /dlvKMSクライアントキーの投入（必要な場合）
slmgr /ipk <GVLK or MAK>
slmgr /atoMAK（複数回認証可能な個別キー）
購入した「プロダクトキー」が MAK の場合、Windows 11 インストール後にそのキーで認証します。インプレースアップグレード中に入力を求められる場合もありますが、実務では “インストール完了後に設定画面で入力して認証” という流れでも問題なく処理できることが多いです（環境要件やポリシーにより異なります）。
サブスクリプション（Windows 11 Enterprise E3/E5）
Windows Enterprise E3/E5 は「Windows Pro を前提に Enterprise へステップアップする」性格が強く、要件として Windows Pro を必要とする旨が明記されています。E3/E5を買ったつもりでも、LTSCの権利が含まれる契約かどうか は別問題になり得ます。
そのため、購入した“Windows 11 Enterprise 2024 アップグレード ライセンス”が、Windows 11 Enterprise LTSC 2024 を対象にしたもの なのか、Windows 11 Enterprise（通常チャネル）を対象にしたもの なのかは、製品名（明細）で確実に合わせてください。
もし「Windows 11 Enterprise（通常チャネル）」へ上げたいだけなら：LTSC→通常版は“条件付きで”インプレース可能
質問では「LTSC→LTSC」が主題ですが、現場では「本当はLTSCにこだわっていない（Enterprise通常でよい）」ケースもあります。この場合、Microsoft Learn には LTSC から GAチャネル（一般提供チャネル）へのアップグレードは、同等または新しいビルドへのアップグレードであればインプレースアップグレードでサポート と明記されています。さらに、アプリ保持のために /pkey スイッチを使う手順例も記載されています。
setup.exe /pkey xxxxx-xxxxx-xxxxx-xxxxx-xxxxxここで入力するのは GAチャネル側のプロダクトキーで、KMS利用例（EnterpriseのGVLK）も示されています。ただし、GAチャネルからLTSCへのインプレースアップグレードはサポートされない 点も同ページで明記されているため、方向を間違えないように注意してください。
実務の落とし穴：LTSC移行で失敗しやすいポイント
- “LTSC 2024”のつもりが“Enterprise（通常）”だった：製品名とISOをセットで確認する
- 要件は満たしているのにアップグレードが通らない：TPM/セキュアブートが“搭載”ではなく“有効”になっているかが重要
- 保持オプションが出ない：言語不一致、USB起動、互換性NGアプリ、容量不足が典型
- 認証できない：KMS/MAK/サブスクの前提がズレている（GVLKは“キーを入れたら終わり”ではない）
移行チェックリスト（コピペして使える形）
| タイミング | チェック項目 | 確認メモ |
|---|---|---|
| 事前 | 現在のLTSC世代（2019/2021）を特定 | winver / Get-ComputerInfo |
| 事前 | 移行先が Enterprise か Enterprise LTSC 2024 か確定 | 明細／管理ポータルの製品名 |
| 事前 | TPM 2.0／UEFI／セキュアブートの有効化 | tpm.msc / msinfo32 |
| 事前 | バックアップ（データ、証明書、回復キー、アプリ情報） | 復元できないものを優先 |
| 作業中 | インプレースは setup.exe をWindows上で実行 | USB起動しない |
| 作業後 | Windows Update／ドライバ／業務アプリ動作確認 | VPN/EDR/資産管理は必須 |
| 作業後 | 認証状態確認（KMS/MAK） | 設定→ライセンス認証 / slmgr |
まとめ：質問への最短回答（実務目線）
- Windows 10 Enterprise LTSC → Windows 11 Enterprise LTSC 2024 への移行は、インプレースアップグレード か クリーンインストール のいずれか。現場では端末状態と世代（特にLTSC 2021かどうか）で判断する。
- 購入した「Windows 11 Enterprise 2024 アップグレード ライセンス」のキーは、それ単体でWindows 10 LTSCを直接“変える”ものではない。Windows 11 のセットアップ（ISO/メディア）を実行したうえで、インストール後に認証 するのが基本。
- Enterprise/LTSCの認証は KMS/MAK/サブスクで前提が変わる。特にKMSのGVLKは“ライセンスキー”ではなく、KMSホスト前提のキーである点を押さえる。
コメント