ARM版 Windows 11 や Surface Pro 11 に乗り換えた途端、「一部の検索ボックスでだけ自作キーボードレイアウトが効かない」という違和感に悩まされていませんか。スタートメニューや Microsoft Store では配列が米国標準に戻るのに、他のアプリではちゃんとドイツ語 Dvorak で入力できる――本記事では、この症状の正体と、MSKLC からの脱却を含む現実的な解決策・ワークアラウンドを詳しく解説します。
ARM版 Windows 11 で起きる「一部アプリだけ配列が戻る」問題
発生環境と状況整理
まずは、問題が発生している典型的な環境を整理します。
| 項目 | 内容 |
|---|---|
| 端末 | Surface Pro 11（ARM64版） |
| OS | Windows 11（ARM64、最新アップデート適用） |
| キーボードレイアウト | Microsoft Keyboard Layout Creator (MSKLC) で作成した「ドイツ語 Dvorak」自作レイアウト |
| 症状が出るアプリ | スタートメニュー検索バー、Microsoft Store 検索バー、WhatsApp デスクトップ版の「チャットを検索」、Drawboard PDF の検索ボックスなど UWP/XAML 系 UI |
| 症状が出ない環境 | x86 版 Surface Pro 8 など、従来の x64 / x86 Windows 11 環境 |
| 対照実験 | Windows 標準の公式レイアウト（英語 Dvorak など）は ARM でも問題なく動作 |
特徴的なのは、
- 同じユーザーアカウント・同じレイアウトであっても、アプリによって挙動が違う
- 問題が出るのは UWP / XAML ベースの検索フィールドに集中している
- 公式レイアウト（英語 Dvorak など）は正常で、自作レイアウトだけがおかしい
つまり「キーボード自体が壊れている」「IME が無効になっている」といった一般的なトラブルではなく、MSKLC 製のレイアウトと ARM64 版 Windows 11 の新しい入力スタックの相性問題と見るのが自然です。
具体的な症状例
ユーザー目線では、次のような現象として現れます。
- スタートメニューの検索ボックスにフォーカスすると、キーの位置が US 配列に変わったように感じる
- Microsoft Store でアプリ名を検索しようとすると、ドイツ語 Dvorak ではなく QWERTY US として解釈される
- WhatsApp デスクトップ版の「チャットを検索」に文字を打つと、期待する文字と違う文字が入力される
- Drawboard PDF の検索バーでも同様に、自作配列が無効になり US 配列にフォールバックしてしまう
一方で、同じ環境でも、
- エクスプローラーのパスバー
- Chrome / Edge のアドレスバー・フォーム
- VS Code や Word などのデスクトップアプリ
では、自作のドイツ語 Dvorak が正常に機能します。この「アプリによって効いたり効かなかったり」が混乱の元であり、生産性を大きく落とす要因になっています。
なぜ MSKLC 製レイアウトだけが ARM で不安定になるのか
MSKLC の前提アーキテクチャと限界
Microsoft Keyboard Layout Creator (MSKLC) はとても便利なツールですが、実は設計がかなり古い時代の Windows を前提にしています。
- 主なターゲット: Windows 2000 / XP / Vista 〜 7 頃
- 実装方式: キーボードレイアウト DLL（kbdxxx.dll）を生成し、レジストリに登録
- 前提アーキテクチャ: x86 / x64 のみ（ARM は想定外）
当時の Windows は「UI のほとんどが Win32 デスクトップアプリ」であり、入力経路も比較的シンプルでした。MSKLC はその前提の上に成り立っており、
- TSF（Text Services Framework）の高度な機能
- UWP / XAML のサンドボックス化された入力経路
- ARM64 特有のドライバーローディング制約
など、新しい要素をあまり考慮していません。そのため、x86/x64 環境では「たまたまうまく動いている」が、ARM64 環境＋UWP 系 UI という条件が揃うと、フォールバックとして US 配列を参照してしまうと考えられます。
Windows 11 / ARM64 の入力スタックの変化
Windows 11、特に ARM64 版では、性能改善やセキュリティの観点から、入力スタックの設計が微妙に変わっています。
- UWP / XAML アプリはサンドボックス内で動作し、利用できるドライバーや DLL に制限がある
- ARM64 ネイティブな IME / キーボードドライバーを優先的に使用する
- 互換性レイヤー（x64/x86 エミュレーション）を通しているアプリと、ネイティブ ARM アプリでは入力周りの経路が異なる
この結果、
- 古い仕様の MSKLC DLL が、ARM64 ネイティブな入力経路からはうまく参照されない
- あるいは安全側に倒して US 配列にフォールバックする
という挙動になっていると考えられます。対照的に、Microsoft 純正の「英語 Dvorak」などは ARM64 に最適化された実装になっており、すべての入力経路で安定して利用できるため、この差が「公式レイアウトは問題なし、自作だけおかしい」という現象として現れます。
x86 版 Surface Pro 8 では再現しない理由
同じレイアウト DLL でも、x86 版 Surface Pro 8 などでは問題が再現しないケースが多いのは、
- OS 自体が x64 / x86 ネイティブで、MSKLC が想定する世界に近い
- UWP アプリでも、下層のキーボード処理が MSKLC DLL を素直に参照できている
ためと考えられます。つまり、
「MSKLC 製レイアウトはまだ完全に壊れてはいないが、ARM64＋UWP という新しい条件では限界が見えてきている」
という状況です。
根本解決：MSKLC をやめて新世代ツールでレイアウトを再作成する
この問題を本質的に解決する最も確実な方法は、
「MSKLC で作ったレイアウトを卒業して、より新しいツールでレイアウトを再定義する」
ことです。ここでは実用性の高い候補として、
- EPKL (Portable Keyboard Layout)
- KbdEdit
の二つを取り上げます。
EPKL（Portable Keyboard Layout）の特徴
EPKL は、カスタムキーボードレイアウトの世界でよく使われているポータブルツールです。
- ライセンス: 無料・オープンソース
- 動作方式: 常駐型ソフトウェアとしてキー入力をフックし、レイアウトをエミュレーション
- カスタマイズ性: レイヤーやモディファイア、デッドキー、マルチレイアウトなど柔軟に定義可能
- ポータブル性: USB メモリから起動して使う、といった運用も可能
メリットとしては、
- DLL ベースではないため、ARM64 / UWP のドライバーロード制限に影響されにくい
- レイアウト定義がテキストファイルベースのため、Git などでバージョン管理しやすい
- キー単位ではなく「レイアウト」として扱えるので、Dvorak のような全面改造配列に向いている
一方で、
- 常駐ソフトである以上、わずかながらオーバーヘッド（CPU / メモリ消費）がある
- 一部の高権限アプリやゲームではフックが制限され、期待通り動かない場合がある
といった点には注意が必要です。それでも、MSKLC の「古い DLL に頼らない」という点で ARM 環境との相性は良く、現代的な選択肢と言えます。
KbdEdit の特徴
KbdEdit は有料ソフトですが、GUI が非常に充実しており、MSKLC ユーザーにとっては移行しやすいツールです。
- ライセンス: 有料（買い切り）
- 操作性: 直感的な GUI で、キーをクリックして割り当てを変更できる
- 互換性: 公式レイアウトのインポート・編集も可能
- 出力形式: キーボードレイアウト DLL やインストーラパッケージを生成できる
メリットとしては、
- MSKLC よりも新しい世代のツールであり、Windows 10/11 環境での利用を前提としている
- 署名付きインストーラの作成に対応しており、配布時の SmartScreen 警告を抑制しやすい
- GUI ベースなので、デッドキーや複合キーの定義も視覚的に確認しながら作業できる
ただし、KbdEdit も最終的には DLL ベースのレイアウトを生成するため、
- ARM64 版 Windows と 100% の相性保証があるわけではない
- UWP / XAML 系アプリの挙動は、バージョンや更新に依存する可能性がある
という点は押さえておきましょう。とはいえ、MSKLC よりもはるかに現代的な実装であるため、少なくとも「MSKLC 固有の不具合」からは解放される可能性が高いです。
EPKL と KbdEdit の比較
| 項目 | EPKL | KbdEdit |
|---|---|---|
| 価格 | 無料・オープンソース | 有料（買い切り） |
| 実装方式 | 常駐ソフトによるエミュレーション | DLL ベースのレイアウトドライバーを生成 |
| ARM64 との相性 | 良好（DLL 制約を受けにくい） | MSKLC よりは良いが DLL 制約の影響を受けうる |
| カスタマイズ性 | 非常に高い。レイヤー・モディファイア・多段配列など | GUI 経由で直感的に設定可能。一般的な配列には十分 |
| 配布のしやすさ | 設定ファイル＋実行ファイルを配布 | 署名付きインストーラを配布可能 |
| 向いているユーザー | 技術寄り・細かくチューニングしたい人 | GUI でサクッと作りたい人、チーム配布したい人 |
「まずは確実に ARM 上でも動いてほしい」「DLL の世界から離れたい」という場合は EPKL を、「これまでの MSKLC ライクな操作感を残したい」「組織内配布用インストーラが欲しい」という場合は KbdEdit を選ぶとよいでしょう。
暫定対応：すぐに試せる 3 つのワークアラウンド
とはいえ、すぐにレイアウトを作り直す余裕がない場合もあります。その場合は、次のような暫定対応を組み合わせることで、「とりあえず今日の作業を快適にする」ことができます。
PowerToys「Keyboard Manager」でキーを再割り当て
PowerToys の「Keyboard Manager」機能を使うと、
- 特定のキーを別のキーに再割り当てる
- ショートカット単位で別の入力に変換する
といった「軽量なリマップ」を行うことができます。これは MSKLC のような「完全なレイアウト」ではなく、
- Q を ‘（シングルクォート）にする
- Y と Z の位置を入れ替える
といった、部分的な修正に向いています。
メリット:
- UWP / XAML アプリを含め、かなり広範囲のアプリで有効
- インストールと設定が簡単で、即日導入可能
- ARM64 版 Windows 11 でも公式にサポートされている
デメリット:
- デッドキーや複雑なコンビネーションが多い配列を再現するには設定が煩雑
- 完全な Dvorak 配列を再構成しようとすると、管理すべきマッピングが膨大になる
そのため、「とりあえず UWP の検索ボックスでだけ最低限のキーを修正する」といった限定的な用途に向いています。
AutoHotkey スクリプトで配列をエミュレーション
AutoHotkey (AHK) は、キーボード入力の自動化やマクロで有名なツールですが、全体的なキーボード配列をエミュレートする用途にも使えます。
- 各キーに対して「押されたら別のキーコードを送る」スクリプトを書くことで、実質的なレイアウトを定義できる
- モディファイアキー（Shift、AltGr など）との組み合わせもある程度制御可能
メリット:
- UWP アプリでも比較的安定して動作する
- スクリプトで定義するため、配列の微調整がしやすい
- 条件分岐を使えば、「特定のアプリでは別配列」といった高度な使い方も可能
デメリット:
- 常駐型のため、多少のオーバーヘッドがある
- 一部のゲームや高権限アプリでは入力フックがブロックされる場合がある
- スクリプト記述にある程度の学習コストが必要
本格的なレイアウト移行までの「つなぎ」として、MSKLC で使っていた配列を AHK スクリプトにざっくり移植するというアプローチは現実的です。
上級者向け：Windows Insider / PowerShell でローカルレイアウトを追加
Windows 11 では、Insider ビルドや一部の先進機能として、XML ベースでキーボードレイアウトを登録する手段も用意されつつあります。これを使うと、
- MSKLC を経由せず、公式の形式でローカルレイアウトを定義する
- PowerShell からレイアウトをインポート・エクスポートする
といった高度な運用が可能です。
ただし現時点では、
- GUI が整っておらず、手作業で XML を編集する必要がある
- Insider ビルドやポリシー設定など、運用ハードルが高い
ため、Windows 上級者向けの選択肢と考えるのが妥当です。「将来的にはここに落ち着きたいが、今すぐは厳しい」という人が多いでしょう。
ワークアラウンドの比較
| 目的 | 方法 | メリット | デメリット |
|---|---|---|---|
| 根本解決 | EPKL / KbdEdit でレイアウトを再作成 | ARM64 / UWP を含む広範囲で安定して動作しやすい | 移行作業の工数がそれなりにかかる |
| 暫定対応① | PowerToys Keyboard Manager | 導入が簡単で、最低限のキーをすぐ調整できる | 複雑な配列再現には不向き |
| 暫定対応② | AutoHotkey スクリプト | 柔軟で、アプリごとの挙動分けも可能 | 常駐負荷とスクリプト作成の手間 |
| 公式寄りの代替案 | PowerShell / XML でローカルレイアウトを追加 | 公式のレイアウト定義形式に近く、将来性がある | 現状は上級者向けで手作業が多い |
実行ステップ例：ドイツ語 Dvorak を EPKL に移行する流れ
ここでは一例として、MSKLC で作った「ドイツ語 Dvorak」配列を EPKL に移行する際の大まかなステップを整理します。細かい画面操作は割愛しますが、作業のイメージをつかむのに役立つはずです。
ステップ 1：現行レイアウトの仕様を書き出す
- MSKLC プロジェクトファイル（.klc）を開き、
- 各キーの割り当て
- Shift / AltGr / Shift+AltGr レイヤー
- デッドキーとその組み合わせ
- 特に、ウムラウトや ß など、ドイツ語固有文字の入力方法を見落とさないようにする。
ステップ 2：EPKL をセットアップ
- EPKL をダウンロードして任意のフォルダに展開する。
- サンプルとして付属しているレイアウトファイルをコピーし、自分のレイアウト名にリネームする（例:
de-dvorak-e.pkl）。 - 設定ファイル（INI や YAML 形式の場合が多い）で、自分のレイアウトを既定のレイアウトとして指定する。
ステップ 3：基本配列を定義する
- EPKL のレイアウト定義ファイルをテキストエディタで開く。
- MSKLC から書き出した内容を参考に、
- ベースレイヤー（修飾なし）
- Shift レイヤー
- AltGr レイヤー
- この時点で EPKL を起動し、簡単なキー入力テストを行い、大枠を確認する。
ステップ 4：デッドキーと複合入力を再現する
- ウムラウト（ä、ö、ü）や ß、アクセント付き文字など、複合入力が必要な部分を洗い出す。
- EPKL のデッドキー設定セクションに、
- デッドキーのトリガーキー
- その後に続くキーとの組み合わせ（例:
"`" + "a" → "ä"）
- 定義が完了するたびに、実際にエディタ上で入力テストを行い、期待した文字が出るか確認する。
ステップ 5：ARM 環境の UWP アプリで動作確認
- Surface Pro 11 など ARM64 環境に EPKL 一式をコピーし、起動する。
- 次のような順でテストすると切り分けがしやすい。
- メモ帳などのクラシックアプリ
- Edge / Chrome のアドレスバー
- スタートメニュー検索バー
- Microsoft Store の検索バー
- WhatsApp / Drawboard PDF など問題が出ていたアプリ
- いずれの検索ボックスでも、ドイツ語 Dvorak の配列で正しく入力できるか確認する。
ステップ 6：問題なければ MSKLC 版レイアウトを削除
- EPKL が十分に安定して動作していることを確認したら、MSKLC 版のレイアウトを Windows から削除する。
- 設定 > 時刻と言語 > 言語と地域 > 使用言語 から、旧レイアウトを含むキーボードを削除する。
- 重複登録が残っていると、アプリによってどちらを参照するかが揺れ、再び混乱の原因になる。
レイアウト移行時の注意点とベストプラクティス
既存レイアウトの削除と優先順位の整理
新しいツールでレイアウトを作り直したあとに忘れがちなのが、古い MSKLC 版レイアウトの完全な削除です。Windows は、
- 同じ言語に複数のレイアウトが紐づいている場合
- アプリ起動時の状態や、最後に使ったレイアウト
によって、どのレイアウトを優先するかを決めます。MSKLC 版が残っていると、
- あるアプリでは新レイアウト、別のアプリでは旧レイアウトが有効になる
- 再起動やアップデートをきっかけに、突然優先順位が入れ替わる
といった現象を招きます。必ず、
- 該当言語（ドイツ語など）のキーボードレイアウト一覧を確認する
- 不要なレイアウトをすべて削除し、残すレイアウトを最小限に絞る
ことを徹底しましょう。
配布時の署名と SmartScreen 対策
自作レイアウトを他人に配布したい場合、ドライバー署名やインストーラ署名の有無が重要になります。署名がない場合、
- SmartScreen によって「不明なアプリ」として警告が表示される
- 組織内ポリシーでインストールがブロックされる
といった問題が発生します。KbdEdit のようなツールは、
- 署名付きインストーラパッケージを生成可能
- 配布先のユーザーに負担をかけずに導入できる
という点が大きなメリットです。個人利用であればそこまで気にしなくても構いませんが、チーム全体で「ドイツ語 Dvorak」を統一したい場合などは、
- 署名付きインストーラを採用する
- インストール手順書を用意する
といった運用まで含めて設計しておくとスムーズです。
ARM 特有の検証ポイント
ARM 版 Windows では、レイアウトのテストも x86 とは少し違う観点が必要です。具体的には、
- ARM ネイティブアプリと x64/x86 エミュレーションアプリの両方で挙動を確認する
- UWP / XAML アプリ（ストアアプリなど）を優先的にテストする
- バッテリー駆動時と AC 接続時で常駐ツールの挙動が変わらないかを確認する
といったポイントをチェックしましょう。特に常駐型の EPKL や AutoHotkey を使う場合、
- スリープ復帰後にレイアウトが無効化されていないか
- ユーザー切り替えやリモートデスクトップ接続時の挙動
も合わせて確認しておくと、後々のトラブルを減らせます。
公式ドイツ語 Dvorak を要望する
長期的な視点で言えば、最もシンプルな解決策は、Windows に公式の「German Dvorak」が搭載されることです。英語 Dvorak が公式に提供されているように、ドイツ語版 Dvorak 配列が標準レイアウトとして追加されれば、
- ARM 版 Windows でも完全サポートが期待できる
- MSKLC やサードパーティツールへの依存を減らせる
可能性が高まります。そのための一歩としては、
- フィードバック Hub から、
- 使用中の環境（Surface Pro 11 / ARM 版 Windows 11）
- MSKLC 製レイアウトが UWP 検索ボックスで効かない問題
- 公式「German Dvorak」レイアウト追加の要望
という地道なアクションが重要です。多くのユーザーから同様のフィードバックが集まれば、将来の Windows ビルドで対応が検討される可能性があります。
まとめ：ARM で自作配列を快適に使うために
本記事の内容を整理すると、ポイントは次の通りです。
- 問題の正体 ARM 版 Windows 11 ＋ UWP/XAML 系アプリの検索ボックスでは、MSKLC で作成した古い形式のキーボードレイアウト DLL がうまく参照されず、US 配列へフォールバックしてしまう現象が起きやすい。
- なぜ起きるのか MSKLC は 2000 年代の Win32 前提で設計されており、ARM64 や UWP の入力スタック、セキュリティ制約まで考慮されていない。一方、公式レイアウトは ARM 対応が進んでいるため、この差が「公式は正常・自作は不安定」という形で現れる。
- 最も確実な解決策 EPKL や KbdEdit といった現代的なツールで、ドイツ語 Dvorak を含む自作レイアウトを再定義し、MSKLC 版レイアウトは削除する。特に EPKL は DLL に依存しないため、ARM との相性が良い。
- すぐできる暫定対応 すぐに移行できない場合は、PowerToys「Keyboard Manager」や AutoHotkey によるキーリマップで、「少なくとも検索ボックスで混乱しない程度」に部分的な修正を行う。
- 運用上のベストプラクティス レイアウト移行後は、古いレイアウトを完全に削除し、ARM 環境上の複数種類のアプリで動作確認を行う。配布する場合は署名やインストーラ形式にも配慮する。
- 将来への布石 フィードバック Hub などを通じて「公式 German Dvorak」追加を要望し、長期的には公式サポートに近づけることが理想的なゴールとなる。
検索バーに文字を打つたびに、「今はどの配列で解釈されているんだっけ？」と頭の中で切り替えるのは、大きな認知負荷です。ARM 世代の Windows を本気で使い倒すなら、自作レイアウトの基盤もそろそろアップデートのタイミングに来ています。MSKLC から一歩踏み出して、新しいツールと運用で、ドイツ語 Dvorak を含む自作配列を快適かつ安定して使える環境を整えてみてください。
コメント