MacのWindows Appで ⌘+Space 日英切替を実現する【完全版】 — Unicodeモードの正体とWinキー漏れ対策(管理者権限あり/なし両対応)

Posted at 2026-07-07

1. この記事について

以前、「⌘+Space を押したあと、キーを離した瞬間に Escape を送る」という Karabiner-Elements の設定で、Windows App(旧 Microsoft Remote Desktop)上の日英切替問題を解決した記事を書きました。

その後、この問題をさらに深掘りする機会があり、そもそもなぜあの方法で動いていたのか、なぜ他の方法がことごとく失敗したのかという仕組みのレベルで全体像が解明できました。本記事は前回記事の書き直し・完全版です。

対象読者は前回と同じです。

macOS で ⌘+Space を Spotlight ではなく「日本語⇄英語」の入力ソース切替に使ってきた Mac ユーザー
Windows App のリモート先(Windows)でも、同じ ⌘+Space で日英を切り替えたい人

結論を先に言うと、最小構成は「共通設定3つ + スタートメニュー誤爆対策1つ」です。誤爆対策は管理者権限の有無や好みに応じて選べるよう、3案を検証結果つきで示します。

2. まず仕組みを理解する(ここが一番大事)

2-1. キーボードモード: Unicode と Scancode

Windows App には入力の送り方が2種類あり、メニューバーの接続(Connections) > キーボードモード(Keyboard Mode) で切り替えられます。ここがすべての分かれ道です。

モード	送られるもの	日本語を変換するのは	特徴
Unicode	ローカルで確定した「文字」	Mac側のIME	Macの操作感そのまま。ただし変換候補ウィンドウの位置がずれる、Qt系アプリ等で入力不可の場合あり
Scancode	キーの物理位置(打鍵情報)	Windows側のIME	リモートで完結するが、Windows側IMEの設定・連携(Emacsならtr-ime等)が必要

Macの日本語IMEをそのまま使いたい(=Macと同じ感覚にしたい)なら Unicode モード一択です。本記事の構成はこれを前提にします。

Unicode モードでは Windows 側の IME は文字生成に関与しません。リモート側 IME の「A/あ」をいくら切り替えても入力は変わらず、逆に Mac 側の入力ソースがすべてを決めます。ここを理解していないと、Windows 側 IME の設定変更という迷路に入り込みます(入り込みました)。

2-2. なぜスタートメニューが誤爆するのか

⌘+Space を押すと、macOS が入力ソースを切り替えてくれます。問題は、⌘(Command)キーの押下・解放イベントが Windows App にも流れ、リモート側で「Winキーが単独で押されて離された」と解釈されることです。Winキー単独押し = スタートメニューなので、切り替えるたびにメニューが開閉します。

Karabiner で ⌘+Space を握り潰そうとしても、Command 押下イベントは Space が押される前にすでにリモートへ漏れているため、完全には防げません。

2-3. なぜ Windows 側の Winキー無効化が効かないのか(重要な検証結果)

「Winキーをリモート側で無効化すればよいのでは」と考え、管理者権限で試しましたが、以下はいずれも失敗しました。理由も含めて記録します。

方法	権限	結果	理由
Scancode Map(レジストリでWinキー無効化)	管理者+再起動	失敗	Scancode Map はキーボードドライバ層で働くが、RDP はそれより後段の仮想キー入力として注入するため素通りする。物理キーボードのWinキーには効く
グループポリシー「Windowsキーホットキーをオフにする」	管理者	失敗	Win+E 等の組み合わせは止まるが、Winキー単独押しのスタートメニュー表示は対象外
IMEキー割り当て変更のみ	不要	失敗	Unicode モードでは Windows 側 IME は使われないため無関係

RDP経由のキー注入に効くのは、仮想キー入力より後段(低レベルキーボードフック)で動く PowerToys Keyboard Manager でした(後述の案B)。

3. 最低限やること(共通設定)

どの誤爆対策を選ぶ場合でも、以下の3つは共通です。

3-1. macOS: ⌘+Space を入力ソース切替に割り当てる

システム設定 > キーボード > キーボードショートカット

Spotlight の「検索を表示」を OFF
入力ソースの「前の入力ソースを選択」に ⌘+Space を割り当てる

3-2. Windows App: キーボードモードを Unicode にする

リモート接続中に、メニューバーの接続(Connections) > キーボードモード(Keyboard Mode) > Unicode を選択。

3-3. Karabiner-Elements: ⌘+Tab でリモートのウィンドウ切替(推奨)

Windows App は ⌘+Option+Tab をリモートへの Alt+Tab として扱うので、Mac の操作感でリモートのウィンドウを切り替えられるようにします。

{
    "description": "Command+Tab → Command+Option+Tab (Windows App only)",
    "manipulators": [
        {
            "conditions": [
                {
                    "bundle_identifiers": ["^com\\.microsoft\\.rdc\\.macos$"],
                    "type": "frontmost_application_if"
                }
            ],
            "from": {
                "key_code": "tab",
                "modifiers": { "mandatory": ["command"] }
            },
            "to": [
                {
                    "key_code": "tab",
                    "modifiers": ["left_command", "left_option"]
                }
            ],
            "type": "basic"
        }
    ]
}

4. スタートメニュー誤爆対策(3案から選ぶ)

案A: Escape ルール(権限不要・Mac側だけで完結・前回記事の方法)

⌘+Space を素通しし、キーを離した瞬間に Escape を送ってスタートメニューを即閉じします。リモート側に一切手を入れないので、権限のない共用サーバーでも使える最も導入コストの低い方法です。

{
    "description": "When using Microsoft Remote Desktop, after pressing ⌘+Space, on key-up send Escape",
    "manipulators": [
        {
            "type": "basic",
            "conditions": [
                {
                    "type": "frontmost_application_if",
                    "bundle_identifiers": ["^com\\.microsoft\\.rdc\\.macos$"]
                }
            ],
            "from": {
                "key_code": "spacebar",
                "modifiers": {
                    "mandatory": ["left_command"],
                    "optional": ["any"]
                }
            },
            "to": [
                { "key_code": "spacebar", "modifiers": ["left_command"] }
            ],
            "to_after_key_up": [
                { "key_code": "escape" }
            ]
        }
    ]
}

弱点は、スタートメニューが「一瞬開いてから閉じる」対症療法であること、そして Escape が文脈次第で別のもの(開いていたメニューやダイアログ等)を閉じてしまう可能性があることです。実用上はほぼ問題になりませんが、気になる場合は案Bへ。

案B: PowerToys Keyboard Manager で Winキーを無効化(確実・推奨)

Winキーの誤爆を根元から断つ方法です。PowerToys の Keyboard Manager は低レベルキーボードフックで動くため、Scancode Map では素通りされる RDP 経由の注入キーも捕まえられます。設定はユーザーごとに独立しており、共用マシンでも他ユーザーの Winキーには影響しません。

手順:

PowerToys をインストールする。GitHub のリリースページ( https://github.com/microsoft/PowerToys/releases )から、Per user 版の PowerToysUserSetup-～-x64.exe を選ぶ。Per user 版は原則ユーザー権限で入るが、組織管理下のPCではUAC昇格を求められる場合がある
Keyboard Manager 初回起動時に「Windows App Runtime 2.x が必要」と言われたら、Windows App SDK のダウンロードページ( https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/downloads )から 2.x 系最新の Installer (x64) を入手して実行する。リモートがオフラインの場合は、Mac でダウンロードしてクリップボード経由で転送すればよい
PowerToys を起動 > Keyboard Manager を有効化 > キーの再マップ
物理キー: Win(左Windows)、マップ先: Disable を設定して保存
PowerToys 設定(全般)で「スタートアップ時に起動」がオンであることを確認する(オフだと次回サインイン後に無効化が効かない)

これで Command キーが漏れても Windows 側では何も起きなくなり、Karabiner 側は共通設定の ⌘+Tab ルールだけで済みます(案Aのルールは不要)。

注意: Win+V(クリップボード履歴)等の Winキー系ショートカットも使えなくなります。必要になったら PowerToys の画面からいつでもオン・オフできます。

案C: 管理者権限がある場合の追加選択肢(と、やっても無駄なこと)

管理者権限があっても、結論は変わらず案Bが最適です。検証の結果、管理者権限でしかできない以下の方法は今回の問題には効きませんでした。

Scancode Map(HKLM のレジストリ、要再起動): RDP注入キーには素通りされる。物理キーボードのWinキーを併せて殺したい場合にのみ意味がある
gpedit.msc の「Windowsキーホットキーをオフにする」(ユーザーの構成 > 管理用テンプレート > Windows コンポーネント > エクスプローラー): Win+E 等は止まるがスタートメニュー単独押しは止まらない

管理者権限の使いどころがあるとすれば、PowerToys の Machine wide 版を全ユーザー向けに入れる場合と、Windows App Runtime のインストールで昇格が必要な場合くらいです。

5. ハマりどころ集(転ばぬ先の杖)

実際にハマった落とし穴を列挙します。同じ道を歩む人の時間節約になれば。

Windows側IMEの設定変更は Unicode モードでは無意味。A/あの表示だけ切り替わり、入力は変わらない(2-1参照)
Karabiner で F12 を送ってはいけない。macOS が音量キーとして消費し、リモートに届かない(音量アイコンが点灯したらこれ)
Ctrl+Space を Windows 側 IME のトグルに割り当ててはいけない。Emacs の set-mark-command(リージョン選択)と衝突する
Option+` 系のキーを Karabiner から送ってはいけない。macOS がアクセント合成(死にキー)として文字に変換してしまい、キーストロークとして届かない
リモート側の言語構成は 1言語(日本語IMEのみ、タスクバーが A/あ表示)がシンプル。英語+日本語の2言語構成(ENG/JPN 表示)だと Win+Space の言語切替が絡んで挙動が予測しにくい。英語入力は日本語IMEオフ状態で普通にできるので、ENGキーボードは通常不要
ハードウェアキーボードレイアウト(101/102 ⇔ 106/109)の変更はマシン全体に効き、再起動が必要。共用サーバーでは他ユーザーへの影響を確認してから。また、RAID再構築など走行中の処理がないことを確認してから再起動すること
Unicode モードの既知の弱点: 変換候補ウィンドウが入力位置から離れて表示されることがある。Qt 製アプリ(RStudio 等)や Hyper-V VMConnect など、Unicode 入力を受け付けないアプリが存在する
Emacs について: Unicode モードなら tr-ime は不要。Mac 側 IME が確定した文字を流し込むだけなので、素の Emacs で日本語が入り、モードラインにも余計な表示は出ない。Scancode モードに切り替えて Windows 側 IME で入力する構成にする場合のみ、tr-ime による IME 同期が必要になる

6. まとめ

構成	権限	リモート側の変更	誤爆	おすすめ度
案A: Escapeルール	不要	なし	一瞬開いて閉じる	手軽さ重視なら◎
案B: PowerToys	原則不要(環境による)	PowerToysインストール	完全に出ない	完成度重視なら◎
案C: レジストリ/GPO	管理者	あり	止まらない	×(検証済み)

土台の理解が9割: Windows App のキーボードモードが Unicode か Scancode かで、日本語入力の主体(Mac側IMEかWindows側IMEか)が決まる
Mac の操作感を保つなら Unicode モード + Mac側IME。⌘+Space は macOS の入力ソース切替に任せる
残る問題は Command キーの Winキー漏れだけ。Escape で閉じる(案A)か、PowerToys で Winキー自体を無効化する(案B)
Windows 側のレジストリやグループポリシーでの Winキー対策は、RDP のキー注入経路には効かない(案Cの検証結果)

前回は「豆腐をチェーンソーで切るような大げささ」から Escape 1発のシンプルさに帰着しましたが、今回はなぜ豆腐にチェーンソーが効かなかったのかまで分かりました。仕組みが分かっていれば、今後 Windows App の挙動が変わっても対応できるはずです。

ご意見・改善案があればコメントでお知らせください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up