大東 信仁（ものくろ） 
Macの画面共有(Screen Sharing.app)でリモートのMacを操作しているときの、IME切り替え問題。
以前、「画面共有中は英数/かなキーがぜんぶリモートに送られてしまって、ローカルのIMEを切り替えられない」問題を、Karabiner-Elementsの select_input_source で解決する方法をこちらの記事に書きました。
ローカルの切り替えは単押し、リモートの切り替えはControl併用、という2系統の操作に分ける設計です。
で、ふと気づいたんですよね。
ローカルとリモートを、別々に操作する必要って、あるの?
英数/かなキーを押したら、ローカルとリモートを両方まとめて同じ状態にすればいいよね？と気づきました。
本当のストレスは「バラバラになる」ことだった
画面共有中にIMEで困る場面を思い返すと、こうです。
リモートで日本語を打っていた。ローカルに戻って打つと、ローカルは英数のまま。
「あれ?」
ローカルは「あ」、リモートは「A」。どっちがどっちだか、わからなくなる。
つまり、「切り替えられない」ことよりも、ローカルとリモートのIME状態がバラバラになることが、本当のストレスなんですよね。
だったら、答えはシンプル。押したら両方、揃えてしまえばいい。
英数/かなキーが「トグルではない」から成立する
この方式が成立するのは、英数/かなキーがトグルではなく確定動作だから。
英数キーを押せば、必ず英語入力になる。
かなキーを押せば、必ず日本語入力になる。
両側の状態がどんなにズレていても、1回押せば必ず同じ状態に収束する。「今どっちだっけ?」と考える必要が、なくなります。
仕組みは、1つのキーに2つのアクションを載せるだけ
Karabiner-Elementsには、性質のちがう2種類のアクションがある。
key_code でキーイベントを送ると、キーは前面アプリ(=画面共有)に渡って、リモートに届く。
select_input_source を呼ぶと、フォーカスアプリを経由せずに、macOSへ直接「ローカルの入力ソースを切り替えろ」と命令できる。
前回はこの2つを別のキー操作に割り当てていました。今回は、to_if_alone に両方併記します。
{
"description": "画面共有中: 左Cmd 単押し → ローカルとリモートを両方 英数 に同期",
"manipulators": [
{
"type": "basic",
"conditions": [
{
"type": "frontmost_application_if",
"bundle_identifiers": [
"^com\\.apple\\.ScreenSharingquot;,
"^com\\.apple\\.RemoteDesktopquot;
]
}
],
"from": {
"key_code": "left_command",
"modifiers": { "optional": ["any"] }
},
"to": [
{ "key_code": "left_command", "lazy": true }
],
"to_if_alone": [
{ "key_code": "japanese_eisuu" },
{
"select_input_source": [
{ "input_source_id": "com.apple.keylayout.ABC" }
]
}
]
}
]
}ポイントは to_if_alone の中身。
{ "key_code": "japanese_eisuu" } で、画面共有アプリ経由でリモートが英数に。
{ "select_input_source": ... } で、macOS直接命令でローカルがABCに。
左Cmdを単押しした瞬間、両方が同時に英数になる。かな側(右Cmd)も同じ構造で、japanese_kana と日本語の入力ソースIDを指定するだけです。
to の lazy: true も大事で、これのおかげで左Cmdは普段どおり修飾キーとして機能する。Cmd+WやCmd+Tabは壊れません。
この仕組みを Claude Fable5 で作りました。
ルールは全部で6つ
- 画面共有中: Control + 英数キー(=左Cmd) → リモートだけ英数
- 画面共有中: Control + 右Cmd → リモートだけかな
- 画面共有中: 左Cmd 単押し → 両方英数に同期
- 画面共有中: 右Cmd 単押し → 両方日本語に同期
- (JIS物理キー用) 画面共有中: 英数キー → 両方英数に同期
- (JIS物理キー用) 画面共有中: かなキー → 両方日本語に同期
5・6は、JISキーボードの物理的な英数/かなキーを直接押した場合のフォールバック。to に同じく key_code と select_input_source を併記する。
すべて frontmost_application_if で、画面共有アプリ(com.apple.ScreenSharing / com.apple.RemoteDesktop)が前面のときだけ発動するので、普段のIME切り替えには影響しません。
普段は単押しだけ。リモートだけ変えたい場面は、ほぼ無い。それでも念のため、Control併用のルール(1・2)も残してあります。
karabiner.json を編集する前に、必ずバックアップを行ってください。自己責任になります。
ハマりどころは、ルールの並び順
Karabinerはルールを上から順に処理する。並び順の制約は2つ。
まず、Controlルール(1・2)は、同期ルール(3〜6)より上に置く。同期ルールは optional: ["any"] なのでControl併用でも拾ってしまう。Control必須のルールを先に勝たせることで、「Control併用=リモートのみ」「素押し=両方同期」に振り分けられる。
そして、新しい6ルールは、既存の「Cmd単押し→英数/かな」系ルールより上に置く。逆だと、既存ルールが先にCommandを消費して、新ルールが永久に発火しない。
もうひとつ、simple_modifications にも注意です。
うちの環境では、simple_modifications で物理英数キー→ left_command に変換している。Karabinerは simple_modifications を complex_modifications より先に処理するので、英数キーは complex に届く時点で、すでに left_command になっている。Controlルールの from を japanese_eisuu で書くと、永久に発火しない。
自分の環境で、キーがどう変換されてから届くのか。ここは要確認です。
「二重に発火しない?」は、大丈夫
to_if_alone で生成した japanese_eisuu が、下にあるJIS用ルール(5・6)にまた拾われて二重発火しそうな気がします。
が、大丈夫。
Karabinerは、生成イベントを他のルールで再処理しない。各ルールが見るのは物理キーだけ。
実は、この性質は初版でハマった原因でもあって(物理キーがCmdのままだと、japanese_eisuu 受けのルールは永久に発火しない)、今回の設計では逆に味方になっています。
入力ソースIDの調べ方
select_input_source に渡すIDは環境によって違います。ターミナルで確認できます。
defaults read com.apple.HIToolbox AppleEnabledInputSourcesうちはmacOS標準のことえりで、英数が com.apple.keylayout.ABC、日本語が com.apple.inputmethod.Kotoeri.RomajiTyping.Japanese。Google 日本語入力なら com.google.inputmethod.Japanese.base になります。
動作確認
画面共有でリモートMacに接続して、ウィンドウにフォーカスした状態で試します。
左Cmd単押し。ローカルのメニューバーが「A」になって、同時に、リモート画面内のIME表示も英数になる。
右Cmd単押し。両方「あ」になる。
Cmd+W。ちゃんとウィンドウが閉じる(修飾キーは無事)。
画面共有を閉じた通常状態では、従来どおりローカルだけが切り替わる。
「ローカルのメニューバー」と「リモート画面の中のIME表示」が、同時に同じ状態になれば成功です。
なお、リモート側は日本語入力ソースを持つmacOSであることが前提。
英数/かなキーを受けてIMEを切り替えるのはリモート側のmacOSなので、リモートにKarabinerを入れる必要はありません。
まとめ
「切り替える」から「揃える」へ。
設定量はほぼ変わらないのに、体感はまるで違いました。
「今どっちの状態?」と考えることが、なくなった。これが一番大きい。
to_if_alone に key_code(リモート行き)と select_input_source(ローカル直接)を併記するだけです。
画面共有を常用している方は、試してみてください。
