MacからWindowsへRDP接続したときの日本語入力問題を調べた記録

目次

はじめに

私は普段、MacBookからWindows 10マシンへリモートデスクトップ接続して作業している。

主な用途は、Windows側での開発作業、PowerShell、Claude Code / Codex などのCLI操作、ブラウザ操作、ファイル操作である。
Microsoft Remote Desktop / Windows App を使えば、画質、クリップボード、安定性、レスポンスは概ね実用的であり、日常作業の基盤としてはかなり優秀だ。

ただし、以前から小さな不満があった。

それが、Macの「英数」キーと「かな」キーで、Windows側の日本語入力・英数入力をうまく切り替えられないことがあるという問題である。

特に困るのは、リモート先のターミナルやClaude Codeに戻った直後である。
英数字のコマンドを打つつもりで入力したら、日本語入力状態になっていて意図しない文字列になることがある。

この問題を解消できないか、いくつかの方法を試した。

目的

今回の目的は、単に「動けばよい」ではなく、次の条件を満たすことだった。

  • MacからWindowsへ安定して接続できる
  • 日本語入力と英数入力を、できるだけ確定的に切り替えられる
  • JIS記号キーが崩れない
  • Cmd / Option / Ctrl が開発作業で破綻しない
  • MacとWindows間のテキストクリップボードが双方向に使える
  • ターミナル、VS Code、ブラウザ、Claude Codeで文字が読める
  • 打鍵遅延が許容範囲に収まる

つまり、単にリモート画面が見えるだけでは足りない。
日常開発に使うには、入力まわりとクリップボードがかなり重要である。

最初に考えたこと

最初は、Microsoft Remote Desktop の代替アプリを探す方向で考えた。

理由は、IMEやキー入力の細かい調整に入り込むと、Karabiner、Windows IME、Google日本語入力、RDPのキーボードモード、AutoHotkeyなどが絡み、いわゆる「パッチ沼」になりそうだったからである。

そのため、次のような候補を考えた。

  • RustDesk
  • Parsec
  • NoMachine
  • Chrome Remote Desktop
  • Sunshine + Moonlight
  • 既存のMicrosoft Remote Desktop / Windows App継続

ただし、最終的には代替アプリへの移行ではなく、Microsoft Remote Desktopを継続し、運用で吸収するという結論になった。

以下、その経緯を書く。

Karabiner + Windows IME補正を試した

まず試したのは、Mac側のKarabiner-Elementsで英数/かなキーを別のキーに変換し、Windows側IMEに届ける方法である。

当初の考えは次のようなものだった。

  • Macの英数キーを Windows側の「無変換」相当に変換する
  • Macのかなキーを Windows側の「変換」または「ひらがな」相当に変換する
  • Windows側IMEで「無変換 = IME OFF」「変換/ひらがな = IME ON」に割り当てる

考え方としては自然だった。

しかし、実際にはうまくいかなかった。

Karabiner-EventViewerで確認すると、Macの英数/かなキーは lang2 / lang1 として見えていた。
そのため、japanese_eisuu / japanese_kana を元キーにした設定は発火していなかった可能性が高い。

さらに lang2 → a、lang1 → b のように、分かりやすい文字キーへ変換する診断も試したが、Mac側のTextEditでも期待通りには入力されなかった。

この時点で、Karabiner側のプロファイル、デバイス設定、権限、既存ルールとの干渉など、別の調査が必要になりそうだった。

ただ、今回避けたかったのはまさにこの種の環境依存デバッグである。
そのため、Karabinerルートは短時間検証では一旦打ち切った。

Windows側でキーが届いているか確認した

次に、RDP先Windowsで AutoHotkey の KeyHistory を使い、Macの英数/かなキーがWindows側にどう届いているかを確認した。

AutoHotkey v2 では、観測用に以下のような最小スクリプトを使った。

#Requires AutoHotkey v2.0
#SingleInstance Force

InstallKeybdHook()
KeyHistory(100)
Persistent

KeyHistoryで確認したところ、少なくともその時点の環境では、英数キーは期待する「無変換」や「英数」ではなく、別のキーとして見えていた。
かなキーは、場合によっては何も届いていないように見えた。

この結果から、Macの英数/かなキーをそのままWindows側IME制御に使うのは、かなり難しそうだと判断した。

RustDeskを試した

次に、Microsoft RDPの代替としてRustDeskを試した。

RustDeskはOSSのリモートデスクトップで、キーボードモードの切り替えなど、入力まわりに調整の余地がある。
そのため、代替候補の中では比較的有力だと考えた。

しかし、15分評価では、必須条件の一つである IME ON/OFFの確定的な制御 がうまくいかなかった。

今回の評価基準では、次のC2〜C6を必須条件とした。

  • C2: IME ON/OFFを確定的に制御できる
  • C3: JIS記号キーが刻印どおり入力できる
  • C4: Cmd / Option / Ctrl が開発作業で破綻しない
  • C5: Mac ↔ Windows の双方向テキストクリップボードが使える
  • C6: ターミナルやVS Codeの文字が読め、打鍵遅延が許容できる

RustDeskは C2 がNGだったため、深追いせずNo-Goとした。

Parsecも試した

次にParsecも試した。

Parsecは低遅延で有名で、ゲームやGUI操作には強い印象がある。
ただし、今回の用途はゲームではなく、MacからWindowsを日常開発用に操作することである。

Parsecも接続自体はできたが、やはりC2、つまりIME ON/OFFの確定制御がうまくいかなかった。
さらに、フルスクリーン接続から抜ける操作も少し分かりにくく、最終的には Command + Option + Esc で強制終了した。

Parsecも今回の用途ではNo-Goと判断した。

NoMachineは保留

NoMachineも候補に入れていたが、試すにはPC再起動が必要だったため、その場では保留した。

ただ、RustDeskとParsecがいずれもC2で落ちたことから、NoMachineにも過度な期待はしない方がよいと感じた。

Google日本語入力のキー設定も試した

次に、RDPで確実に届く別のキーを使って、Google日本語入力側でIME ON/OFFを割り当てる方法を試した。

AutoHotkey KeyHistoryで確認したところ、たとえば以下のキーはWindows側に届いていた。

  • Ctrl + ;
  • Ctrl + :

そこで、Google日本語入力のキー設定で、以下のような割り当てを試した。

Ctrl + ;  → IMEを有効化
Ctrl + :  → IMEを無効化

また、無効化ではなく、

  • 半角英数に入力切替
  • 直接入力に入力切替

なども試した。

結果として、IME有効化や無効化のコマンド自体は反応しているように見えたが、期待する「半角英数入力」にはならず、実用的ではなかった。

この段階で、Google日本語入力のキー設定だけで綺麗に解くのも難しそうだと判断した。

重要な発見: 直接入力状態を起点にすれば期待通り動く

ここで、重要なことが分かった。

Windows側IMEを 直接入力の状態 にしておくと、Macのキー操作が期待に近い動きをする。

具体的には、次のようになる。

Macの英数キー → 英数入力になる
Macのかなキー → 日本語入力・変換ができる

しかも、JIS記号キー、Cmd / Option / Ctrl、クリップボード、文字の鮮明さや遅延も実用上問題なかった。

つまり、当初は「タスクバーのIME表示が変わらない」ことを問題視していたが、実際には、表示が変わらなくても入力結果は期待通り切り替わっていた。

これはかなり重要だった。

今回の評価では、最終的に「タスクバーの表示」ではなく「実際の入力結果」を基準にすべきだと分かった。

残る問題

完全解決ではない。

唯一気になるのは、Mac側からRDPのWindows画面へ戻った直後である。

RDP先にフォーカスを戻した直後は、日本語入力寄りの状態になっていることがあり、そのままPowerShellやClaude Codeに英数字を打つと、意図しない日本語入力になってしまう。

これを避けるには、RDPに戻った直後に Macの英数キーを1回押す 必要がある。

つまり、運用ルールはこうなる。

RDPに戻る
→ 最初に英数キーを1回押す
→ ターミナルやClaude Codeへ入力開始

完全ではないが、これで実用上かなり安定する。

最終結論

今回の結論は次の通り。

Microsoft Remote Desktop / Windows App を継続利用する。
代替リモートデスクトップへの乗り換えは不要。
Karabiner、AutoHotkey、レジストリ変更などの補正パッチも当面不要。
Windows側IMEを直接入力状態にしておき、RDPへ戻った直後は英数キーを1回押す運用で吸収する。

当初は、RDP代替アプリを探す方向も考えた。
しかし、RustDeskやParsecを試しても、IME ON/OFFの問題は自然には解決しなかった。

結果として、Microsoft RDPはやはり総合力が高い。

  • 画質が良い
  • 文字が読みやすい
  • クリップボードが強い
  • Windowsとの統合が自然
  • 開発作業に耐える
  • C3〜C6は問題ない

残る不満は、RDP復帰直後に英数キーを1回押す必要があることだけである。

この程度なら、代替アプリへの移行や補正パッチを重ねるよりも、運用で吸収する方が合理的だと判断した。

今回の教訓

今回の調査で得た教訓は次の通り。

  1. IME問題は、表示ではなく実入力で判断すべき
  2. タスクバーのIME表示が変わらなくても、実入力が期待通りなら実用上はOK
  3. Mac英数/かなキーをWindows側IMEに完全対応させようとすると、環境依存のパッチ沼になりやすい
  4. 代替リモートデスクトップも、IME問題を必ず解決してくれるわけではない
  5. Microsoft RDPは、多少の不満はあっても総合力が高い
  6. 完全解決より、低コストで安定する運用ルールを決める方が実用的な場合がある

当面の運用

今後は、次のルールで運用する。

RDP接続後、またはMac側からRDPへ戻った直後:
  まず英数キーを1回押す

日本語を入力したい時:
  かなキーを押す

英数字・コマンドを入力したい時:
  英数キーを押す

完全ではないが、これが現時点での妥協点である。
少なくとも、代替アプリ探索やIME補正の深追いより、はるかに現実的な解決だった。

プログラム開発,その他

Posted by iwadjp