ConfigMgr（SCCM）でWindows 10→Windows 11のインプレースアップグレード（IPU）を配布した後、既存端末に入っていたfr-frなどの言語機能が不足・未適用になり、再ダウンロードを求められるケースがあります。Microsoft StoreやWindows Updateを遮断している環境でも、ローカルソース（SCCMパッケージ／共有）から確実に同じ言語環境を復元するための実装パターンと運用のコツを整理します。
Windows 11 IPUで「言語パックを入れ直したい」問題が起きる背景
Windows 11の言語は、単純に「言語パックCABを1つ入れれば終わり」ではなく、複数の部品（言語機能、追加機能、場合によってはストア配布の要素）で構成されます。IPU（インプレースアップグレード）はユーザーデータや多くの設定を引き継ぐ一方で、言語周りは環境依存で引き継ぎが不完全になりやすく、アップグレード後に次のような症状が出がちです。
- 表示言語は残っているのに、手書き・OCR・音声などが消えている
- 言語の追加・修復をすると「ダウンロードが必要」と言われるが、Store/WUが遮断されていて失敗する
- 一部の言語機能だけが「Not Present」になり、アプリや入力が不安定になる
特に「社内ポリシーでMicrosoft Storeブロック」「Windows Updateを直接叩けない」「プロキシ・FWで外向き通信制限」などがあると、OS側が必要部品を取りに行けず、復旧が詰みやすいのが実態です。
前提整理：Windows 11の言語は何でできているか
ローカルから復元を安定させるには、まず「何を用意して、何を入れ直すのか」を分解して理解しておくと事故が減ります。
| 要素 | 例 | 役割 | オンライン依存 | ローカル導入の現実解 |
|---|---|---|---|---|
| 言語機能（Capabilities / FOD） | Language.Basic / OCR / Speech など | 基本入力、手書き、OCR、音声、TTSなどの機能 | 既定ではWU等から取得されがち | FODソースをパッケージ化し、DISM/PowerShellで/Source指定 |
| 表示言語（UIリソース） | fr-FRのUI表示 | OS UIの翻訳・表示 | 環境によりストア/オンライン取得が絡む場合あり | 基本はLanguage.Basicを確実に入れる。戻らない場合は追加要素も検討 |
| 地域・形式 | 日付/通貨形式、地域設定 | 表示形式のローカライズ | 基本はオンライン不要 | 必要ならPowerShellで再適用（Set-Culture等） |
| キーボード/入力方式 | AZERTY、英仏切替 | 入力レイアウト | 基本はオンライン不要 | 必要ならユーザー言語リストを再適用（運用設計が重要） |
今回の「Storeに頼らずローカルから復元したい」の中心は、言語機能（Capabilities / Features on Demand）をローカルソースから確実に追加することです。ここが固まると、IPU後に足りなくなりがちな部品をかなりの確率で復元できます。
結論：IPUタスク シーケンス内で「IPU後に言語機能を追加する」手順を組むのが現実解
ConfigMgr（SCCM / MECM）のIPUは、標準機能だけで「端末ごとの言語構成を自動復元」まで面倒を見てくれるわけではありません。そのため、タスク シーケンス側で次の流れを明示的に作るのが最も安定します。
| フェーズ | やること | 目的 | ポイント |
|---|---|---|---|
| IPU前（Windows 10側） | 言語構成を控える（任意） | 端末ごとの言語差分に追従 | 複数言語端末が混在するなら有効 |
| IPU前（Windows 10側） | 言語/FODソースをローカルへコピー | アップグレード後にネットワーク不安定でも作業可能に | 「後で取りに行かない」設計が強い |
| IPU実行 | Windows 10→11へアップグレード | OS更新 | ここでは言語復元を無理に完結させない |
| IPU後（Windows 11起動後） | DISM/PowerShellで言語機能を追加 | Language.Basic等をローカルソースから復元 | /Source指定＋必要なら/LimitAccess |
| IPU後 | 再起動・検証・後片付け | 言語機能の反映、ディスク節約 | 3010（再起動要求）を成功扱いに |
準備：Windows 11のバージョンに合った言語/FODソースを用意する
オフライン導入で最も多い失敗原因は「ソースがOSと合っていない」ことです。言語機能（FOD）のCABは、同じfr-frでもWindows 11のバージョンがズレると失敗しやすくなります。運用としては次の方針が堅いです。
- Windows 11の対象バージョンごとに、言語/FODソースをセットで管理する（例：対象が23H2なら23H2用、対象が24H2なら24H2用）
- x64/ARM64などアーキテクチャが混在する場合は、パッケージも分ける
- 「全部入りISO」をそのまま配るとサイズが大きいので、必要なCABだけを抜いて軽量化する（可能なら）
現場での実装としては、次のいずれかが多いです。
- 方式A：言語/FODのCAB群をそのままSCCMパッケージ化して配布（手堅いがサイズ大）
- 方式B：必要言語（例：fr-fr）に必要なCABだけ抽出してパッケージ化（サイズ小、更新作業は増える）
まずは方式Aで確実に動かし、運用が回ったら方式Bに寄せるのが、移行プロジェクトでは事故が少ない傾向です。
fr-frで「どれを入れるべきか」目安
要件次第で削れますが、よく使われるセットは次のとおりです。
| Capability | 用途 | 必須度 | 備考 |
|---|---|---|---|
| Language.Basic | 基本表示・基本入力 | 高 | まずこれが入らないと話が進まない |
| Language.Handwriting | 手書き認識 | 要件次第 | タブレット運用で必要になりがち |
| Language.OCR | OCR機能 | 要件次第 | スキャンや検索で効く |
| Language.Speech | 音声認識 | 要件次第 | 音声入力を使うなら |
| Language.TextToSpeech | 音声合成 | 要件次第 | 読み上げ用途で必要 |
実装例：IPU後にDISMのCapability追加でfr-frをローカルから入れる
質問で挙がっているとおり、IPU完了後（Windows 11起動後）にDISMで言語機能を追加するのが、いちばん再現性が高い実装です。ポイントは「/Sourceでローカルフォルダを指定すること」です。
例：あらかじめCAB群をC:\LocalFolderへコピーしておき、Windows 11起動後に追加します。
dism /Online /Add-Capability /CapabilityName:Language.Basic~~~fr-fr~0.0.1.0 /Source:C:\LocalFolder
dism /Online /Add-Capability /CapabilityName:Language.Handwriting~~~fr-fr~0.0.1.0 /Source:C:\LocalFolder
dism /Online /Add-Capability /CapabilityName:Language.OCR~~~fr-fr~0.0.1.0 /Source:C:\LocalFolder
dism /Online /Add-Capability /CapabilityName:Language.Speech~~~fr-fr~0.0.1.0 /Source:C:\LocalFolder
dism /Online /Add-Capability /CapabilityName:Language.TextToSpeech~~~fr-fr~0.0.1.0 /Source:C:\LocalFolder社内でWindows Update経路を遮断している場合、環境によっては外部に取りに行こうとして待ち続けたり、エラーになったりすることがあります。その場合は「外に取りに行かない」動きを明示すると安定します。
dism /Online /Add-Capability /CapabilityName:Language.Basic~~~fr-fr~0.0.1.0 /Source:C:\LocalFolder /LimitAccess「基本（Language.Basic）」以外は要件次第で省略可能です。ただし音声、OCR、手書きなどが業務要件なら、最初からセットで入れておくと、アップグレード後の問い合わせが激減します。
インストール後の確認コマンド
「本当に入ったか」を確認する習慣をタスク シーケンスに組み込むと、後からの切り分けが楽になります。
dism /Online /Get-Capabilities | findstr /i "Language.*fr"PowerShellなら、状態（Installed/Not Present）が見やすいです。
Get-WindowsCapability -Online | Where-Object { $_.Name -like "Language.*~~~fr-*" } | Select-Object Name, State汎用化：端末に入っていた言語を検出して、同じものを復元する
fr-fr固定でよいなら前章のDISM直打ちで完結します。一方で、拠点や部署で言語が混在（fr-fr、de-de、es-esなど）している場合、端末ごとに「入っていた言語」を検出して、同じものを復元する方が運用が回ります。
おすすめの考え方は「アップグレード前にインストール済みのLanguage.* capabilitiesを控える → アップグレード後に同じ能力を/Source指定で入れ直す」です。言語コードだけでなく、OCRやSpeechの有無も含めて復元できるのが利点です。
アップグレード前：インストール済みLanguage capabilitiesを控える例
IPU前（Windows 10側）で、Systemコンテキスト実行でも問題が起きにくい形でファイルへ控えます。
powershell.exe -ExecutionPolicy Bypass -NoProfile -Command ^
"$outDir='C:\_LangBackup'; New-Item -Path $outDir -ItemType Directory -Force | Out-Null; ^
$caps=Get-WindowsCapability -Online | Where-Object { $_.Name -like 'Language.*~~~*' -and $_.State -eq 'Installed' } | Select-Object -ExpandProperty Name; ^
$caps | Sort-Object -Unique | Set-Content -Encoding UTF8 -Path (Join-Path $outDir 'InstalledLanguageCapabilities.txt'); ^
(Get-Date).ToString('s') | Set-Content -Encoding UTF8 -Path (Join-Path $outDir 'CapturedAt.txt')" この方式の良い点は、端末ごとに「Basicだけ」「Speechも入っている」などの差分があっても、そのまま追従できることです。
アップグレード後：控えたリストをローカルソースから復元する例
Windows 11起動後（IPU後）に、C:\LocalFolderにCABが揃っている前提で復元します。PowerShellのAdd-WindowsCapabilityを使うと、/Sourceや/LimitAccessも素直に指定できます（内部的にはDISMを呼びます）。
powershell.exe -ExecutionPolicy Bypass -NoProfile -Command ^
"$src='C:\LocalFolder'; ^
$listPath='C:\_LangBackup\InstalledLanguageCapabilities.txt'; ^
if (!(Test-Path $listPath)) { Write-Host 'No backup list. Skip.'; exit 0 } ^
$caps=Get-Content -Path $listPath -Encoding UTF8 | Where-Object { $_ -and $_ -match '^Language\.' } | Sort-Object -Unique; ^
foreach($cap in $caps){ ^
Write-Host ('Installing: ' + $cap); ^
try { Add-WindowsCapability -Online -Name $cap -Source $src -LimitAccess -ErrorAction Stop | Out-Null } ^
catch { Write-Warning ('Failed: ' + $cap + ' / ' + $_.Exception.Message) } ^
}" 実務上は、Language.Basicを「必須」、その他（Handwriting/OCR/Speech/TTS）を「任意」に分け、必須が失敗したらタスク シーケンスを失敗扱いにする設計が堅いです（任意は警告ログを残して継続など）。
ConfigMgrタスク シーケンス設計のコツ
IPUで言語復元を安定させるには、コマンドだけでなく「どのタイミングで」「どこから実行するか」が重要です。おすすめの配置例をまとめます。
| 順序 | TSステップ（例） | 内容 | 狙い |
|---|---|---|---|
| アップグレード前 | （任意）言語構成のバックアップ | InstalledLanguageCapabilities.txtを作成 | 端末差分に追従 |
| アップグレード前 | 言語/FODパッケージをローカルへコピー | C:\LocalFolderへCAB群を配置 | IPU後のネットワーク不安定対策 |
| アップグレード | Upgrade Operating System | Windows 10→11 IPU | 標準のIPU処理 |
| アップグレード後 | 言語機能の復元（Run PowerShell Script / Run Command Line） | DISMまたはAdd-WindowsCapabilityで追加 | Store/WU不要の復元 |
| アップグレード後 | 再起動 | 再起動要求（3010）を吸収 | 反映の安定化 |
| アップグレード後 | クリーンアップ | C:\LocalFolder等を削除 | ディスク節約、情報残置回避 |
「コピーをアップグレード前にやる」理由
IPU直後は、ドライバ更新・ネットワーク初期化・VPN自動接続などの影響で、一時的にコンテンツ取得が不安定になることがあります。言語のCAB群はサイズも大きく、途中で転送が切れると復旧が面倒です。アップグレード前の正常稼働状態でローカルへ置いておく設計は、現場での成功率が上がりやすいです。
コピー方法の例（robocopy）
パッケージ内のCAB群をC:\LocalFolderへ置く例です（パッケージはDPからローカルへ展開された上で実行される想定）。
cmd.exe /c ^
if not exist C:\LocalFolder mkdir C:\LocalFolder && ^
robocopy "%~dp0" "C:\LocalFolder" *.cab /E /R:2 /W:2 /NPPowerShellなら、スクリプトの配置場所（$PSScriptRoot）を使えるので、パス事故が減ります。
powershell.exe -ExecutionPolicy Bypass -NoProfile -Command ^
"$dst='C:\LocalFolder'; New-Item -Path $dst -ItemType Directory -Force | Out-Null; ^
Copy-Item -Path (Join-Path $PSScriptRoot '*.cab') -Destination $dst -Force"運用でハマりやすい注意点
ソースは「Windows 11のバージョン一致」が最重要
言語機能（FOD）は、同じLanguage.BasicでもOSのバージョン差でCABが合わないと失敗しがちです。移行案件では、次の運用にするとブレが減ります。
- OS展開（IPU対象）のバージョンを固定し、そのバージョンに合わせたFODソースを用意する
- 対象バージョンが複数あるなら、TSでOSバージョンを判定してソースパッケージを分岐する
- パッケージ更新のタイミング（OS更新と同じリリース波）を決めておく
DISMは時間がかかる前提で、タイムアウトと再起動を設計する
言語機能の追加は、端末性能やストレージ、どの能力を入れるかで想像以上に時間が伸びます。タスク シーケンスでは以下を意識すると事故りにくいです。
- 言語追加ステップのタイムアウト（既定が短いと途中で失敗扱いになる）
- 3010（再起動が必要）を「成功」として扱う運用
- 再起動ステップを明示し、反映を確実にする
よくあるエラーと切り分け（現場で使う表）
IPU後の言語復元で遭遇しやすいエラーを、原因と対処の観点で整理します。
| 症状/コード（例） | よくある原因 | 対処 | 確認ポイント |
|---|---|---|---|
| 0x800f081f（source files could not be found） | /Sourceに必要CABが存在しない、またはOSと不一致 | ソースを見直す（対象OSバージョン一致、CAB揃っているか） | C:\Windows\Logs\DISM\dism.log |
| 0x800f0954 | WU/WSUS設定の影響で取得経路が詰まる | /Source＋/LimitAccessを試す。必要ならポリシーを見直す | GPOの「オプション機能の取得」系設定 |
| 0x802400xx系（ダウンロード失敗） | オンライン取得に行って失敗している | /LimitAccessを付け、必ずローカルのみで解決する | プロキシ/FW/Storeブロック |
| 再起動要求（3010） | 言語機能追加後の反映に再起動が必要 | TSで再起動ステップを入れる、3010を成功扱いにする | 追加直後は反映が揺れることがある |
ログを見る場所
- DISM：C:\Windows\Logs\DISM\dism.log
- コンポーネント（CBS）：C:\Windows\Logs\CBS\CBS.log
- ConfigMgrタスク シーケンス：SMSTS.log（実行フェーズで保存場所が変わる）
「同じ言語環境」をより確実に再現するための実務ポイント
言語機能を入れるだけで「足りない問題」はかなり解決しますが、運用要件によっては「表示言語」「キーボード」「地域形式」まで含めて整えたい場面があります。ここは環境差が出るので、やりすぎない範囲で現実的な選択肢を提示します。
端末の標準言語を固定運用している場合
例えば「フランス拠点端末は常にfr-FR」と決まっているなら、IPU後に追加で設定を寄せるのは簡単です。必要に応じて、言語機能追加後に次のような設定を入れると、ユーザーからの“表示が戻らない”問い合わせが減ります。
powershell.exe -ExecutionPolicy Bypass -NoProfile -Command ^
"Set-WinSystemLocale fr-FR; ^
Set-Culture fr-FR; ^
Set-WinHomeLocation -GeoId 84" ただし、ユーザーごとの表示言語や入力レイアウトまで厳密に揃える場合は、ユーザーコンテキストでの適用や既存ユーザーへの反映方法が絡みます。まずは「機能をローカルから入れられる状態」にして、必要性が出たら段階的に強化するのがおすすめです。
複数言語が混在する環境
混在環境では「端末の実態に合わせて復元」する方が運用が楽です。前述の「インストール済みLanguage capabilitiesを控えて復元」方式は、まさにこの用途で強いです。
- 導入前に端末の状態を拾うので、拠点差をスクリプトで吸収できる
- OCRやSpeechなど、ユーザーが使っていた機能まで含めて再現しやすい
- Store/WUブロック環境でも、ローカルソースで完結させられる
チェックリスト：本番投入前にここだけは押さえる
| 項目 | 確認内容 | 合格ライン |
|---|---|---|
| ソース整合 | Windows 11の対象バージョン・アーキテクチャとFODソースが一致 | パイロット端末で全能力が/Source指定で入る |
| 実行タイミング | IPU後（Windows 11起動後）に言語追加が走る | SMSTS.logで順序が追える |
| ネットワーク依存排除 | ローカル（C:\LocalFolder等）にCABを置いてから実行 | ネットワーク遮断状態でも成功する |
| 再起動設計 | 3010を吸収し、最後に再起動 | アップグレード後の言語が安定 |
| 後片付け | 不要になったCABを削除 | ディスク逼迫を起こさない |
まとめ：IPU後の言語復元は「ローカルソース＋Postステップ」が勝ち筋
ConfigMgr（SCCM）のWindows 10→Windows 11 IPUで、Store/WUブロック環境でも言語（fr-frなど）を確実に復元するには、タスク シーケンスにカスタム手順を組み込み、Windows 11起動後にDISM（/Add-Capability）またはAdd-WindowsCapabilityでローカルソースから追加するのが最も現実的です。
まずはLanguage.Basicを確実に入れ、要件に応じてHandwriting/OCR/Speech/TextToSpeechを追加し、必要なら/LimitAccessでオンライン依存を断ちます。さらに端末ごとの言語混在がある場合は、アップグレード前にインストール済みLanguage capabilitiesを控えて、アップグレード後に同じものを復元する方式にすると、運用負荷と問い合わせの両方を抑えやすくなります。
コメント