MENU

Intune Autopilotでオランダ語Windowsのキーボード配列がDutchになる問題を解決する方法（US-International対応）

Microsoft

Intune の Windows Autopilot（事前プロビジョニング）で「表示言語はオランダ語、でもキーボード配列は United States – International」を標準化したいのに、OOBE で自動的に「Dutch」配列になってしまい、メールアドレス入力の「@」でユーザーが詰む――。本記事では、この挙動が起きる理由と、ユーザーを困らせずに運用するための現実的な設定・手順をまとめます。

目次

現象：オランダ語 Windows にした途端、キーボードが「Dutch」になってしまう

Intune の Windows Autopilot 展開（事前プロビジョニング／Pre-provisioning）で新しい PC をセットアップする際、次のような方針を採っている組織は多いはずです。

  • Windows の表示言語：オランダ語（Dutch / nl-NL）
  • キーボード配列：United States – International（いわゆる “US-International”）

ところが、Windows Autopilot の展開プロファイル（Enrollment Profile / Deployment Profile）の OOBE 設定で 「Automatically configure keyboard（キーボードを自動構成）」を Yes にすると、言語に合わせて 「Dutch (Netherlands)」キーボード配列が自動選択されます。

オランダの現場では、物理キーボードが US 配列相当（US-International 前提）で運用されているケースが多く、配列がズレると入力が一気に難しくなります。特に厄介なのが、Autopilot の OOBE で Microsoft Entra ID（旧 Azure AD）サインインに必要な メールアドレスの「@」が期待どおりに入力できないケースです。

項目会社標準（理想）実際に起きること（問題）
表示言語Dutch（nl-NL）Dutch（nl-NL）
キーボード配列United States – InternationalDutch (Netherlands) が自動適用される
OOBE での配列変更不要（自動化したい）変更画面が出ず、ユーザーが詰みやすい
影響スムーズにサインインメールアドレス入力で停止／ヘルプデスク呼び出し

なぜ起きるのか：Autopilot の OOBE 設定は「言語＝キーボードの既定」を前提にしている

この問題を理解するうえで重要なのは、Autopilot 展開プロファイルの OOBE 設定が持つ思想です。ざっくり言うと、次の動きになります。

  • Language (Region) を指定すると、OOBE の表示言語／地域設定の基準が決まる
  • Automatically configure keyboard = Yes にすると、OOBE が キーボード選択画面をスキップし、言語に紐づく “既定のキーボード配列” を自動適用する
  • 結果として、言語を Dutch（nl-NL）にすると、キーボードも Dutch（Netherlands）に寄っていく

ここが落とし穴で、Autopilot のプロファイル設定には「言語は Dutch、ただし既定キーボードは US-International」といった “言語と異なる配列を直接指定するための独立した項目” が用意されていません。つまり、OOBE を静かに（質問を減らして）完走させようとするほど、言語とキーボードが強く結びついてしまいます。

さらに厄介：OOBE の入力で詰むと、Intune の後段対策が間に合わない

「じゃあ Intune の構成プロファイルや PowerShell スクリプトで直せばいい」と考えがちですが、ユーザーが OOBE のサインインで詰んだ時点では、後段の Intune ポリシーが届きません。つまり、OOBE のメールアドレス入力で止まってしまうと、管理側が用意した“自動修正”がそもそも走らないのです。

フェーズ画面イメージこの時点で効く設定効かない／間に合わない設定
OOBE（サインイン前）国/地域・キーボード・ネットワーク・サインインAutopilot 展開プロファイル（OOBE 設定）Intune 構成プロファイル、スクリプト、Remediation など
サインイン後（ESP 中）アプリ/ポリシー適用Intune の各種ポリシー、アプリ、スクリプトOOBE の入力画面に戻って配列を直すこと

結論：Automatically configure keyboard を Yes のまま、US-International を強制するのは難しい

現状の Autopilot 展開プロファイルの枠内では、次のように整理するのが現実的です。

  • 「Automatically configure keyboard = Yes」＋「Dutch 言語」 のまま、US-International を強制的に固定する運用は取りづらい
  • ユーザーが OOBE で詰まらないことを最優先にするなら、キーボード選択を出す設計に寄せるほうが安定する

つまり、完全自動化よりも「詰みポイントを潰す」ことが KPIになります。ゼロタッチの理想を追いすぎると、実際にはヘルプデスク対応が増えてトータルの工数が上がる、という逆転が起きがちです。

推奨：Autopilot プロファイルで「Automatically configure keyboard」を No にする

もっとも再現性が高く、ユーザーを確実に救える対策はこれです。

  • Automatically configure keyboard：No
  • （必要に応じて）Language (Region)：Dutch (Netherlands) または User select

これにより、OOBE の途中でキーボード配列の選択が表示され、ユーザーが United States – International を選べるようになります。

設定例（おすすめの落とし所）

目的Language (Region)Automatically configure keyboardOOBE の体験向いている組織
「表示言語は Dutch を固定」＋「キーボードだけ選ばせる」Dutch (Netherlands)No表示は Dutch で進む／キーボード選択が出るユーザーの迷いを最小化したい
「地域・キーボードをユーザーに選ばせる」User selectNo地域選択・キーボード選択が出る配布先が複数国／拠点で混在している
「OOBE の質問を極限まで減らす」Dutch (Netherlands)Yesキーボード選択が出ない（ただし配列が Dutch になりがち）今回の課題では非推奨

Intune 管理センターでの変更手順（例）

テナントの画面構成により表記やメニュー名は多少揺れますが、基本的な流れは同じです。

  1. Microsoft Intune 管理センターで Windows Autopilot の展開プロファイル（Deployment profile）を開く
  2. OOBE（Out-of-box experience）設定で、Language (Region) を Dutch（nl-NL）に設定する
  3. Automatically configure keyboard を No に変更する
  4. 割り当て（Assignments）を確認し、対象デバイス（または対象グループ）に適用する
  5. 検証用デバイスで Autopilot をやり直し、OOBE 中に キーボード選択画面が出ること を確認する

ポイントは、「キーボード選択画面が出ること」自体が成功条件だという点です。言語やアプリの自動展開が正しくても、メールアドレス入力で詰めば現場は回りません。

ユーザーが迷わないようにする運用のコツ

Automatically configure keyboard を No にすると「ユーザーが選ぶ一手間」が発生します。ここを雑にすると “選び間違い” が次のトラブルになります。逆に言えば、案内を 1 枚整えるだけでヘルプデスク工数が激減します。

最小の案内（これだけで事故が減る）

  • キーボード選択画面が出たら、「United States – International」 を選ぶ
  • 「Dutch」や「Dutch (Netherlands)」は選ばない
  • 2つ目のキーボード追加を聞かれたら、基本は 追加しない（運用方針次第）

配布時に添える “一枚カード” のテンプレ案

紙でも PDF でもよいので、箱の中に 1 枚入れておくと効果が大きいです。

  • 画面に「キーボード」を選ぶ項目が出たら：United States – International を選択
  • メールアドレス入力で @ が出ない場合：慌てずに戻ってキーボードを確認（または下記の緊急回避策）
  • 困ったら：社内ヘルプデスク（内線/Teams）へ連絡

緊急回避策：OOBE で「@」がどうしても入力できないとき

“ユーザーが詰んだ瞬間” に効く手段を用意しておくと、リモート支援が一気にやりやすくなります。

状況起きやすい原因その場の回避策
Shift+2 を押しても @ にならないキーボード配列が US ではないOOBE の戻れる画面ならキーボード選択を見直す
キーボード選択画面が出ていないAutomatically configure keyboard が Yes展開プロファイル側を No に修正して再実施（根本対応）
今すぐ 1 回だけ @ を入れたいユーザーが操作に慣れていないアクセシビリティからスクリーンキーボードを使い、画面上で @ を選ぶ

ここで重要なのは、「ユーザーのスキルに依存するショートカットを前提にしない」ことです。スクリーンキーボードは最終手段として強いですが、根本解決にはなりません。根本対策は OOBE で配列選択を出すことです。

ログオン後に “US-International を既定化” してブレをなくす（Intune スクリプト運用）

OOBE でユーザーに選ばせたあとでも、次のような「あとから地味に困る」問題が残ることがあります。

  • いつの間にかキーボードが複数になっている（言語バーで切り替わる）
  • ショートカット操作で配列が切り替わり、突然 @ が打てなくなる
  • 部署・拠点によって “選ぶべき配列” が揺れ、標準化できない

そこでおすすめなのが、ログオン後に Intune で “US-International を既定に固定” するアプローチです。OOBE の詰みを回避しつつ、最終的には IT が望む状態に寄せられます。

設計の考え方（失敗しないポイント）

  • OOBE は「ユーザーが進められること」を最優先（選択画面を出す）
  • OS 初期化直後は状態が揺れやすいので、ユーザーサインイン後に固定化する
  • キーボード設定は “ユーザー単位” の要素が多いため、スクリプトは ユーザーコンテキストで実行するほうが安定しやすい

例：nl-NL（表示言語）＋ US-International（配列）に揃える PowerShell

以下は「Dutch（nl-NL）だけを残し、入力方式（InputMethodTips）を US-International に寄せる」例です。環境で要件が異なるため、まずは検証用デバイスで十分にテストしてください。

$ErrorActionPreference = 'Stop'

# 目標
$desiredLanguageTag = 'nl-NL'
# 0413 = Dutch (Netherlands), 00020409 = United States-International
$desiredInputTip    = '0413:00020409'

# 現在のユーザー言語リストを取得
$langList = Get-WinUserLanguageList

# nl-NL が無ければ作成（単一言語にしたい場合のベース）
if (-not ($langList | Where-Object { $_.LanguageTag -eq $desiredLanguageTag })) {
    $langList = New-WinUserLanguageList $desiredLanguageTag
}

# nl-NL のエントリを取り出し
$nl = $langList | Where-Object { $_.LanguageTag -eq $desiredLanguageTag } | Select-Object -First 1

# 入力方式（キーボード等）を入れ替え
$nl.InputMethodTips.Clear()
$nl.InputMethodTips.Add($desiredInputTip) | Out-Null

# 言語は nl-NL のみに統一（必要に応じて要調整）
$langList = @($nl)

# 適用
Set-WinUserLanguageList $langList -Force

# 既定の入力方式を上書き（ユーザー単位）
Set-WinDefaultInputMethodOverride -InputTip $desiredInputTip

Write-Output "Applied: $desiredLanguageTag with InputTip $desiredInputTip"

Intune への配布の例（運用イメージ）

  • 対象：オランダ拠点（nl-NL）向けデバイスグループ
  • 実行タイミング：ユーザー初回サインイン後（もしくは毎回ログオン時に Remediation）
  • 実行コンテキスト：可能ならユーザーで実行（言語リストはユーザー単位の影響が大きいため）
  • 期待効果：OOBE ではユーザーに選ばせて詰みを防止／ログオン後に標準状態へ収束

この “二段構え” は、現場の不確実性（ユーザーが間違える、OEM イメージが微妙に違う、OS ビルドで挙動が変わる）に強いのが利点です。

代替案：OOBE ではキーボード重視、表示言語は後から Dutch に寄せる

「どうしても OOBE の質問を減らしたい」「ユーザーにキーボードを選ばせたくない」という事情が強い場合は、設計の優先順位を変える手もあります。

考え方はシンプルで、OOBE ではキーボードが崩れない状態を優先し、ログオン後に表示言語を Dutch に切り替えるというものです。

設計パターンメリットデメリット向くケース
OOBE で Dutch 固定＋キーボード選択（推奨）初回から表示が Dutch／入力詰みを防ぎやすいユーザーに 1 回だけ選択が必要ユーザー体験を重視／現場の混乱を最小化
OOBE は OS 既定（英語など）＋後から Dutch 化サインイン入力が安定しやすい／OOBE の質問を減らせる初回の画面が Dutch にならない／後段スクリプトが必須どうしても OOBE を短くしたい／ユーザーに選択させたくない

ただしこの代替案は、後段スクリプト（言語パック導入、既定 UI 言語の設定、場合によっては再起動）が絡むため、ESP と合わせた検証が必須です。特に “事前プロビジョニングでどこまで入るか” と “ユーザーフェーズで確実に収束するか” を分けてテストしてください。

どうしても「OOBE から完全自動で固定」したい場合に知っておくべきこと

「表示言語＝Dutch、キーボード＝US-International」を OOBE の最初から完全自動で固定したい、という要件は理解できます。ただ、Autopilot は基本的に OEM イメージを前提にした “ゼロタッチ展開” であり、OS 展開（イメージング）のように 応答ファイル（unattend.xml）で InputLocale を細かく指定する設計ではありません。

もしこのレベルの強制が絶対条件なら、次のような選択肢が検討対象になります。

  • OS 展開（イメージ配布／応答ファイル）で InputLocale を指定してから配布する
  • Autopilot “だけ” にこだわらず、調達・キッティング工程を含めた設計（標準イメージ、ベンダーキッティング）に寄せる

Autopilot の強みは「管理と配布のコストを下げる」ことです。ここを超えて “OOBE の細部まで完全固定” を求めると、設計の中心が Autopilot から OS 展開寄りに変わっていきます。要件とコストのバランスを見て、どこまでをゼロタッチの範囲に置くか決めるのが現実的です。

検証用チェックリスト（トラブルを再発させない）

設定変更後は、1台の成功だけで判断せず、少なくとも複数のハードウェア（メーカーやモデル違い）で再現性を確認するのが安全です。

チェック項目期待値NG の典型見直すポイント
OOBE にキーボード選択が出る表示される出ずにスキップされるAutomatically configure keyboard が Yes のまま
ユーザーが @ を入力できるメールアドレス入力が滞りなく進む@ で停止ユーザー案内不足／配列選択ミス
初回サインイン後の配列が安定US-International が既定複数配列が残る／勝手に切替ログオン後固定スクリプトの導入
事前プロビジョニングでも同様に動くユーザーフェーズで詰まない事前プロビジョニング後のユーザーフェーズで詰むOOBE 設計がユーザーフェーズ前提になっていない

まとめ：ユーザーが詰むポイントを OOBE で確実に潰し、ログオン後に標準へ収束させる

オランダ語 Windows を標準にしつつ、実運用に合う US-International キーボードを使いたい場合、最優先は「OOBE のサインインで詰ませない」ことです。

  • Autopilot の「Automatically configure keyboard」を Yes のまま、言語と異なる配列（US-International）を OOBE で強制するのは難しい
  • 現実解は、Automatically configure keyboard を No にして OOBE に配列選択を出す
  • さらに安定させるなら、ログオン後に Intune スクリプトで US-International を既定化し、配列のブレを無くす

「ゼロタッチ」にこだわりすぎず、ユーザーが確実に完走できる設計に落とすことが、結果的に運用コストを下げる近道です。

Microsoft
Intune キーボード配列 Windows Autopilot US-International オランダ語

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次