WSUS配下のWindows Serverにオフライン言語パック（lp.cab）を展開すると、ほとんどは「ログオフで完了」なのに、一部だけ「再起動が必要」と表示されることがあります。原因の見分け方と、再起動を最小化する現実的な運用手順を整理します。
現象の整理：同じlp.cab導入なのに「ログオフ完了」と「再起動完了」に分かれる
複数台のWindows Server（2008/2008 R2/2012 R2/2016など）に対して、ISOや共有フォルダー上の言語パック（lp.cab）をオフラインで導入したところ、大半は「ログオフ（サインアウト）で完了」なのに、特定のサーバーだけ「再起動して完了」と促される――というケースがあります。Microsoft Q&Aでも、同様に約80台中15〜16台だけ再起動を求められ、共通点として「Windows UpdateをWSUSに向けるGPOが入っている」ことが挙がっています。
この状態は“言語パック自体の不具合”というより、サーバー側の更新状態（更新適用の途中・再起動保留など）に引きずられて、言語パックの適用処理が「最後は再起動で確定が必要」と判定されていることが多いのが実態です。
| 表示 | よくある内部状態 | 現場で起きがちなこと |
|---|---|---|
| ログオフで完了 | ユーザーセッションの切り替えで反映できる範囲に収まっている | RDPでサインアウト→サインインするとUI言語や一部表示が切り替わる |
| 再起動で完了 | OSコンポーネントの置換・コミットが“再起動待ち”になっている／すでに再起動保留が残っている | 再起動しない限り「適用済み/保留中」が解消されず、後続の更新や構成変更に影響が出やすい |
結論：原因の第一候補は「すでに再起動保留（pending reboot）が残っている」
Q&Aの回答でも、再起動を求められたサーバーについて「更新プログラムの適用などで“保留中の再起動”が残っていないか確認してほしい」という指摘がされています。WSUS配下の端末は更新検出・適用が回りやすい一方、運用上の理由で再起動だけ先送りされることがあり、結果として「再起動が必要」状態が残りやすい、という説明が自然に成り立ちます。
言語パック（lp.cab）の導入は、内部的にはWindowsのコンポーネント（CBS: Component-Based Servicing）に対するパッケージ追加と同種の“OSレベルの変更”です。すでに別の更新でファイル置換が待機している状態（＝再起動保留）だと、言語パック側も最終確定を「再起動が必要」と判断しやすくなります。
「再起動保留」とは何か：言語パック導入時に“再起動必須判定”を誘発する仕組み
Windowsは、更新やコンポーネント追加の途中で「次回再起動時に差し替える（削除する）ファイル」を予約したり、コンポーネントストア側で「再起動後にコミットする処理」を保留したりします。この状態が残っていると、別の変更（今回なら言語パック追加）を行った時点で「どうせ再起動が必要なので、ここでも再起動が必要」と判定されることがあります。
“再起動保留”の典型的な痕跡は、Microsoftのスクリプティングブログでも整理されており、代表例として次のレジストリが挙げられます。
| チェック箇所（代表） | 意味 | よくある発生源 | 言語パック導入への影響 |
|---|---|---|---|
| HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations | 再起動時に置換/削除するファイルが予約されている | 更新、ドライバー、ミドルウェア導入など | OSがファイル差し替えを保留しているため、追加の変更も再起動で確定させたくなる |
| HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired | Windows Updateが「再起動が必要」と判定している | WSUS/Windows Updateで更新適用後の再起動待ち | 言語パック側が単独ではログオフで済む場合でも、端末全体として再起動が必要になる |
| HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending | CBS（コンポーネント）処理が再起動待ち | 累積更新・機能追加・パッケージ導入 | CBSが“コミット待ち”のため、言語パックの最終反映も再起動を要求しやすい |
原因切り分けの基本：本当に「言語パックが再起動を要求している」のかをログで確認する
「再起動が必要」と出たときに重要なのは、“言語パックが原因で再起動が必要”なのか、既存の再起動保留が原因で結果としてそう見えているのかを分けることです。特にWSUS運用では、言語パック導入の直前に更新が走っていた／前回の更新後に再起動していなかった、というだけで判定が変わることがあります。
確認の優先順位は次の通りです。
- レジストリで再起動保留の痕跡があるか（上の3系統は最優先）
- イベントビューアー（Windows Logs → Setup / System、または Servicing 関連）で「再起動が必要」や言語パック/更新の記録を追う
- CBS.log/DISM.logで、言語パック処理やパッケージ適用の末尾に“reboot required”相当の記録がないかを確認する
| 見る場所 | パス/場所 | 見つかると嬉しい情報 | 読み解きのコツ |
|---|---|---|---|
| イベントビューアー（Setup） | イベント ビューアー → Windows Logs → Setup | 更新/機能追加/言語パック適用の履歴 | 導入実施時刻を起点にフィルターし、前後で「再起動要求」系がないか確認 |
| イベントビューアー（System） | イベント ビューアー → Windows Logs → System | 再起動履歴、再起動要求の出所 | 再起動の履歴確認にはEvent ID 12/13/6005/6009などが役立つ |
| CBSログ | C:\Windows\Logs\CBS\CBS.log | コンポーネント（CBS）の処理結果、再起動要求の理由 | ログは巨大になりがち。導入時刻周辺を抽出して読むと早い |
| DISMログ | C:\Windows\Logs\DISM\dism.log | DISMで導入した場合の詳細 | lp.cabをDISMで追加した場合、こちらのログも併せて確認 |
なお、再起動のイベントIDや「通常再起動/予期せぬ再起動」の切り分け方法はMicrosoft Learnにも整理があります。導入後の検証（本当に計画再起動が実施されたかの確認）に使うと便利です。
再起動保留（Pending Reboot）を素早く確認する方法
まずは「再起動保留が残っているか」を機械的に判定します。GUIで追うより、レジストリ/PowerShellで確認した方が速く、複数台にも展開しやすいです。
コマンドで個別サーバーを確認する（手作業の最短）
管理者権限のコマンドプロンプトで、次のようにキーの存在を確認します。存在すれば“何らかの再起動保留が残っている”可能性が高いです。
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v PendingFileRenameOperations
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"1行目は値（PendingFileRenameOperations）があるかどうか、2〜3行目はキーが存在するかどうかがポイントです。
PowerShellで“理由つき”に判定する（おすすめ）
次のスクリプトは、再起動保留の代表箇所をまとめてチェックし、どの系統のフラグが立っているかを返します。WSUS配下で大量展開する前に、対象サーバーへ事前実行して「今は言語パックを入れるべき状態か」をふるいにかける用途に向きます。
# Pending Reboot の簡易チェック（管理者で実行）
$results = [ordered]@{}
# 1) ファイル差し替え待ち（更新・ドライバー等でよく立つ）
$pendingFile = (Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' -Name PendingFileRenameOperations -ErrorAction SilentlyContinue).PendingFileRenameOperations
$results.PendingFileRenameOperations = [bool]($pendingFile)
# 2) Windows Update（WSUS含む）が再起動を要求している
$results.WindowsUpdateRebootRequired = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
# 3) CBS（Component Based Servicing）が再起動待ち
$results.CBSRebootPending = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
# まとめ
$results.IsPendingReboot = ($results.PendingFileRenameOperations -or $results.WindowsUpdateRebootRequired -or $results.CBSRebootPending)
[pscustomobject]$resultsどれか1つでもTrueなら、言語パックに限らず“OSのどこかが再起動を待っている”状態です。特にCBSRebootPendingがTrueの場合、OSコンポーネントのコミットが待機しているため、言語パックの導入でも再起動判定になりやすい傾向があります。
複数サーバーを一括で棚卸しする（展開前チェック）
サーバーが数十台〜数百台ある場合、1台ずつの確認は現実的ではありません。PowerShellリモーティングが使える環境なら、サーバー一覧に対して一括でPending Rebootを棚卸しできます。
# サーバー一覧（例）を読み込み
$servers = Get-Content .\servers.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
$pfr = (Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' -Name PendingFileRenameOperations -ErrorAction SilentlyContinue).PendingFileRenameOperations
$wu = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
$cbs = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
[pscustomobject]@{
ComputerName = $env:COMPUTERNAME
PendingFileRenameOperations = [bool]$pfr
WindowsUpdateRebootRequired = $wu
CBSRebootPending = $cbs
IsPendingReboot = ([bool]$pfr -or $wu -or $cbs)
}
} | Sort-Object IsPendingReboot -Descending | Format-Table -AutoSizeこの棚卸しでIsPendingReboot=Trueのサーバーだけを先に計画再起動できれば、「言語パック導入で再起動を求められるサーバーが混じる」問題はかなりの確率で減ります。
「再起動なしで完了」は可能？できるケース／難しいケースを切り分ける
まず前提として、Windowsの表示言語の切り替えは、ユーザーセッションに紐づく部分が大きいため、サインアウト→サインインで反映されるケースが確かに存在します。Microsoft Learnでも、表示言語を切り替える手順として「言語を選択し、サインアウトしてサインインする」ことが明示されています。
一方で、導入時点で「再起動が必要」と判定された場合は、置換待ちファイルやCBSのコミット待ちが残っている可能性が高く、“再起動せずに完全反映”を保証するのは基本的に難しいと考えるのが安全です。ここで無理に押し切ると、表示が中途半端になるだけでなく、後続の更新適用や機能追加が詰まる（永遠に再起動要求が消えない）など、運用リスクが上がります。
| ケース | 典型的な状況 | 現実的な対応 |
|---|---|---|
| ログオフで済む | Pending Rebootがなく、言語パック導入後の反映がユーザーセッション中心 | サインアウト→サインインで切り替え。RDSなら対象ユーザー全員のサインアウトが必要になる点に注意 |
| 再起動が必要と出る | 更新/コンポーネント導入の“再起動待ち”が残っている、または言語パック導入でOSファイル置換が発生 | 原則は計画再起動。どうしても無理なら「要求の抑止」＋後日再起動を前提にする |
| 再起動を避けたいが安全性も欲しい | サーバー用途上、即時再起動が難しい（24/365、メンテ枠が小さい等） | 事前に更新を揃えて再起動保留をゼロにしてから言語パックを入れる（後述） |
再起動を“不要にする”のではなく“要求を抑止する”：LPKSetupの/rを正しく使う
管理側の事情で「今この瞬間は再起動できない」という状況は現場ではよくあります。その場合に知っておきたいのが、LPKSetup（lpksetup.exe）の /r オプションです。
/r は、操作完了後の再起動要求を抑止します。ただしこれは「再起動が不要になる」わけではありません。Microsoft Learnのコマンド仕様にも「再起動要求を抑止し、再起動が必要である旨をイベントログに記録する」と説明されています。
# 例：ja-JPを、共有フォルダー（またはローカルフォルダー）からサイレント導入し、再起動要求だけ抑止
lpksetup.exe /i ja-JP /s /r /p \\fileserver\share\LangPacks
# 例：フォルダーに複数言語がある場合、ワイルドカードで全導入（テスト環境で検証してから）
lpksetup.exe /i * /s /r /p C:\LangPacks運用で重要なのは、/r を付けた時点で“再起動が不要”と解釈しないことです。抑止しただけで、サーバー内部では再起動待ちが残ります。後日、計画メンテナンスで必ず再起動して完了させる、という前提で使うのが安全です。
DISMで導入している場合のポイント：lp.cabはOSパッケージとして扱われる
GUIやLPKSetup以外に、DISMで言語パックを導入している環境もあります。DISMは.cab/.msuパッケージを扱うツールで、更新だけでなく言語パックも対象に含まれます。
# 例：lp.cabをオンライン（稼働中OS）へ追加
DISM /Online /Add-Package /PackagePath:C:\LangPacks\ja-jp\lp.cab
# 例：インストール済みパッケージの一覧（言語パックの追加状況確認に）
DISM /Online /Get-Packages /Format:TableDISM導入でも「再起動が必要」となる理屈は同じで、既存の再起動保留があったり、ファイル差し替えが必要だったりすると、最終コミットに再起動が求められます。ログの読み取りは C:\Windows\Logs\DISM\dism.log と C:\Windows\Logs\CBS\CBS.log をセットで行うと原因追跡が速いです。
運用上の回避策：再起動を最小化しつつ“確実に完了させる”ための現実解
「再起動しない」こと自体が目的になると、結果としてサーバーの健全性（更新適用、脆弱性対策、コンポーネント整合性）を損ねがちです。そこでおすすめは、言語パックの展開手順そのものを、再起動保留が残らない流れに組み替えることです。
| 狙い | 具体策 | 期待できる効果 | 注意点 |
|---|---|---|---|
| 言語パック導入時の“再起動判定”を減らす | 先にWSUS/Windows Updateの適用を揃えて、保留中の再起動を解消してから言語パックを入れる | 「一部だけ再起動要求」になりにくい | 更新適用には結局再起動が必要なことが多い。言語パックのためというより“更新の健全化”として説明すると通りやすい |
| どうしても今は再起動できない | LPKSetupの/rで要求を抑止し、後日計画再起動で完了させる | 作業ウィンドウ内の“再起動回避”はできる | 抑止しただけで完了ではない。再起動を忘れると別作業で詰む |
| サービスを止めずに再起動を実施したい | 冗長構成（クラスタ/負荷分散/複数台構成）があるならローリング再起動（順番にドレイン→再起動） | 利用者影響を最小化しながら“必要な再起動”を実施できる | 単体サーバーは不可。事前に依存関係（監視、ジョブ、バッチ）の整理が必要 |
おすすめの展開フロー（実務向け）
- 言語パック対象サーバーの棚卸し：OSバージョン、役割（RDS/AD/DNS等）、再起動許容度、冗長有無を整理
- 事前チェック：前述のPowerShellでPending Rebootを判定し、Trueのサーバーを抽出
- 更新の整流化：WSUS/Windows Updateで更新適用を揃え、計画再起動で保留をゼロにする（ここが肝）
- オフライン言語パック導入：lpksetupまたはDISMでlp.cabを導入。可能ならサイレント導入（/s）で手順を統一
- 反映確認：サインアウト→サインインで表示言語が切り替わるか、DISMのGet-Intl等で状態を確認
- 再起動要求が出たサーバーだけ計画再起動：どうしても不可なら/rで抑止し、必ず後日再起動を予約
このフローにすると、言語パック導入が“再起動の引き金”になるのではなく、更新運用を健全化するプロセスの一部として説明できます。管理層への説得材料としても使いやすいです。
WSUS GPOが入っているサーバーだけ再起動要求になりやすい理由
Q&Aの事例でも、「再起動を求められるサーバー群はWSUSを指定するGPOが適用されていた」という共通点が挙がっています。
ここから導ける“あるある”は次の通りです（環境差はありますが、筋としてはかなり強いです）。
- 更新は入るが再起動は入らない：セキュリティ更新は自動で入る一方、業務都合で再起動だけ先送りになり、結果的にRebootRequired/RebootPendingが残り続ける
- 適用タイミングがサーバーごとにズレる：夜間バッチ、バックアップ、監視抑止、メンテ枠などで更新適用の時刻がズレ、言語パック導入時点での“保留状態”がサーバーごとに異なる
- 役割・常駐プロセスの違いでファイルロック状況が違う：同じOSでも、役割（例：RDS/ファイルサーバー/アプリサーバー）や常駐ソフトで差し替え対象がロックされやすく、保留が残る確率が変わる
つまり「WSUSが悪い」というより、WSUS運用の結果として“再起動保留の端末が混じる”のが問題の本質で、言語パック導入はそれを可視化しているだけ、と捉えると整理しやすいです。
やってはいけない対処：再起動保留フラグを“消して見た目だけ直す”のは危険
ネット上には「RebootRequiredやRebootPendingのキーを削除すれば再起動不要になる」という情報が出回ることがあります。しかしこれは、“再起動が必要な理由”を解消せずに目印だけ消す行為になりがちです。
- 置換待ちのシステムファイルが残ったままになり、更新適用や機能追加が失敗する
- コンポーネントストア（CBS）が不整合を抱え、後から修復（DISM/SFC）が必要になる
- 「一時的に直ったように見える」ため、根本原因（再起動運用の欠落）が放置される
どうしても再起動が難しい環境ほど、ローリング再起動やメンテ枠の再設計といった運用側の手当てが最終的にコストを下げます。
導入後の確認：言語パックが入ったか／切り替わったかを確実に見る
「ログオフで完了」と出た場合でも、実際に切り替わっていなければ意味がありません。特にRDS（ターミナルサーバー）では、管理者だけがサインアウトしても利用者のセッションは残るため、反映が遅れて見えることがあります。
DISMで現在の言語情報を確認する
# 現在のUI言語/システムロケール等を確認
DISM /Online /Get-Intlパッケージとして追加されているか確認する
# 言語パック関連のパッケージ名が増えているか確認（出力が多いので検索しながら）
DISM /Online /Get-Packages /Format:Table表示言語の切り替えはサインアウトが前提
言語を追加しただけでは表示言語が切り替わらないことがあります。表示言語の切り替え操作を行ったら、サインアウトしてサインインし直すのが基本です。
よくある質問
再起動せずに“完全に”反映させる裏技はありますか？
「表示の切り替え」だけならサインアウトで足りることがありますが、“再起動が必要”と判定された状態を、再起動なしで完全解消する決定打は基本的にありません。/rで要求を抑止することはできますが、根本的には後日再起動が必要です。
再起動要求が出るサーバーと出ないサーバーが混在します。正常ですか？
混在自体は起こり得ます。同じ手順でも、導入時点の更新状態（再起動保留の有無）や、役割・常駐ソフトによるファイルロック状況がサーバーごとに違うためです。まずはPending Rebootの棚卸しを行い、差分を可視化するのが近道です。
言語パック導入後、更新が失敗する／再起動要求が消えない
この場合は「言語パックが原因」というより、もともとの更新処理が詰まっている可能性があります。CBS.logを確認しつつ、計画再起動で保留を解消した上で再評価してください。再起動後も改善しないときは、別途コンポーネント修復（DISM/SFC）を検討します（環境・バージョンにより手順が異なるため、まずはログ優先）。
まとめ：言語パック導入の“再起動要求”は、更新運用（WSUS）とセットで考えると解決が早い
- 同じlp.cabでも「ログオフで完了」と「再起動で完了」に分かれる最大要因は、導入前から残っている再起動保留であることが多い
- まずは PendingFileRenameOperations / RebootRequired / RebootPending をチェックして、再起動保留の有無を切り分ける
- どうしても当日再起動できない場合は、LPKSetup /rで要求を抑止しつつ、後日必ず計画再起動で完了させる
- 最もトラブルが少ないのは、更新適用→計画再起動で保留解消→言語パック展開の順に運用を整えること
「言語パックを入れたら一部だけ再起動が必要になった」という事象は、見方を変えると“再起動保留が残っているサーバーが混じっている”ことを教えてくれるサインでもあります。言語パック導入を機に、WSUS運用と再起動運用をセットで棚卸しすると、以後の更新トラブルも減らしやすくなります。
コメント