家ではWindowsデスクトップをメインに使っている。でも外へ持ち出すのは、軽くてバッテリーも持つM1 MacBook Airだ。
そのMacBook Airを外出先で最低限困らない状態にしておきたい。ただ、家で設定するたびにキーボードとマウスを持ち替えるのは地味に面倒だった。そこでWindowsからMacを操作し、普段のWindowsに近いキー操作へ寄せることにした。
最初はBarrier、次にDeskflowを試し、最後はMac側のSunshineとWindows側のMoonlightで画面ごとリモートする構成に落ち着いた。さらにAutoHotkey v2とHammerspoonを組み合わせ、無変換・変換キー、Ctrl系ショートカット、スクロール速度も調整している。
この記事では、途中の試行錯誤は要点だけに絞り、現在使っている設定を中心にまとめる。
WindowsからMacを操作したかった理由
俺の作業環境は、家でどっぷり作業する時は基本的にWindowsだ。MacBook Airは外出時に軽く作業するための端末で、家でMacを長時間使うことはほとんどない。
今回やりたかったのも、リモート操作そのものを主役にすることではなかった。家のWindowsから横に置いたMacBook Airを触り、アプリや入力環境を外出前に整えることが目的だ。
最初に目指したのは、Windowsのキーボードとマウスをそのまま使い、カーソルを画面端へ動かすだけでMacへ移れる環境だった。ただ、実際に使うと「つながる」だけでは足りない。
無変換・変換キーで入力を切り替えたい。Ctrl+CやCtrl+Vをいつもの指使いで使いたい。ホイールもWindowsと同じくらい動いてほしい。こうした小さな違いの方が、短時間の調整作業では気になった。
今回の目的は、WindowsからMacを常用することではなく、外出用のMacBook Airを家で手早く整えられる状態にすること。
この目的を優先した結果、キーボードとマウスだけを共有する方法から、Macの画面ごとWindowsへ表示する方法へ変わっていった。
BarrierからDeskflowへ移行
最初はBarrierで、Windowsをサーバー、MacBook Airをクライアントにした。Windows画面の下へMacを配置し、カーソルを下端から抜くとMacへ移動する構成だ。
使い始めは便利だったが、Windows側のIPアドレスが変わって接続できなくなったり、SSLまわりで引っ掛かったりした。ChromeやEdgeがアクティブな時だけ画面境界でカーソルが止まり、細かく振動するような挙動も出た。
表示倍率やブラウザのGPUアクセラレーションを変えても改善しなかったため、後継候補のDeskflowへ移行した。
WindowsではVisual C++ Runtimeが必要だった
Windows版Deskflowのセットアップでは、Microsoft Visual C++ Redistributable v14.50以降が必要という警告が出て、インストールが止まった。
Microsoft Visual C++ v14 Redistributable x64 14.51.36247を入れてWindowsを再起動すると、Deskflowを起動できた。
Macでは「壊れているため開けません」が出た
M1 MacBook Airにはarm64版を入れたが、Applicationsへ移動して起動すると「Deskflowは壊れているため開けません」という警告が表示された。
今回は配布元を確認して入手したDeskflowに対し、ターミナルで次のコマンドを実行すると起動できた。
xattr -c /Applications/Deskflow.appこの操作は、出所を確認できたアプリに対して行っている。出所不明のアプリで警告を無条件に回避するためには使わない方がいい。
起動後はmacOSのアクセシビリティとローカルネットワークを許可し、TLS 1.3で接続できた。ただし、Deskflow経由のキーはKarabiner EventViewerに現れず、MacBook本体で使っていたキー変更をそのまま適用できなかった。
Deskflowの詳しい設定を詰め続けるより、今回の目的に合う別の土台へ移ることにした。
Sunshine＋MoonlightでMacをリモート操作
最終的には、Mac側へSunshine、Windows側へMoonlightを入れ、Macの画面ごとWindowsへ表示する構成にした。
接続直後は映像だけ表示され、マウスとキーボードが反応しなかった。Mac側でSunshineに必要な権限を許可すると、Windowsから操作できるようになった。
WinキーをMac側へ送る
初期状態ではWindowsキーボードのWinキーを押すと、リモート先ではなくWindows側のスタートメニューが開く。Moonlightの入力設定で「システムのキーボードショートカットをキャプチャ」をONにした。
これでWinキーもMac側へ届き、Moonlight越しのWin+CをMacのCommand+Cとして使える。Windows側へ操作を戻す時は、Ctrl+Alt+Shift+Zで入力キャプチャを解除できる。
逆方向の使い方になるが、MacBook Airから自宅WindowsをMoonlightで使うための仮想モニター切り替えは別記事にまとめている。
今回は家の中でWindowsからMacを調整する話なので、ここからは入力操作の合わせ込みへ戻る。
無変換・変換キーを英数・かなにする
Windowsでは、無変換を英数字、変換を日本語入力として使っている。Macでも同じ操作にしたかったが、Moonlight越しに押しても反応せず、Karabiner EventViewerにも表示されなかった。
そこでWindows側のAutoHotkey v2で、Moonlightがアクティブな時だけ無変換をF16、変換をF17へ置き換えて送る。
#Requires AutoHotkey v2.0
#HotIf WinActive("ahk_exe moonlight.exe")
vk1D::Send "{F16}" ; 無変換 → F16
vk1C::Send "{F17}" ; 変換 → F17
#HotIfF16とF17を選んだのは、普段のWindows操作と衝突しにくく、Moonlight越しでもMac側のHammerspoonが検出できたからだ。元の無変換・変換キーが見えなくても、いったん使っていないキーへ中継すればMac側で別の操作に変えられる。
#HotIf WinActive("ahk_exe moonlight.exe")を付けているので、通常のWindows操作には影響しない。Moonlightを操作している時だけ変換する。
HammerspoonでF16とF17を受け取る
Mac側ではHammerspoonを使う。キーボード操作を扱わせるため、最初にアクセシビリティ権限を許可する。
~/.hammerspoon/init.luaへ次を追加した。
hs.hotkey.bind({}, "F16", function()
hs.eventtap.keyStroke({}, "eisu")
end)
hs.hotkey.bind({}, "F17", function()
hs.eventtap.keyStroke({}, "kana")
end)Hammerspoon Consoleでは、F16とF17のホットキーが有効になったログと、Apple標準日本語入力のIDも確認できた。
ATOKでは、かなへ切り替わったように見えても入力開始時に英字へ戻ることがあった。Apple標準の日本語入力「あ」では安定したため、現在はこちらを使っている。
これでWindowsの無変換はMacの英数、変換はMacのかなとして使えるようになった。
Ctrl+C・Ctrl+VをWindowsと同じにする
MoonlightではWindowsの左CtrlがMacのControlとして届く。MacのコピーはCommand+Cなので、そのままでは普段のCtrl+Cが使えない。
Windows側のAHKで左CtrlをWinへ変える方法も試したが、Moonlightとの組み合わせでは安定しなかった。最終的にはMac側のHammerspoonで、左ControlそのものをCommandとして扱うようにした。
local leftCtrlDown = false
local ctrlToCmd = hs.eventtap.new({
hs.eventtap.event.types.flagsChanged,
hs.eventtap.event.types.keyDown,
hs.eventtap.event.types.keyUp
}, function(event)
local eventType = event:getType()
local keyCode = event:getKeyCode()
if eventType == hs.eventtap.event.types.flagsChanged
and keyCode == 59 then
local flags = event:getFlags()
if flags.ctrl then
leftCtrlDown = true
hs.eventtap.event.newKeyEvent({}, 55, true):post()
else
leftCtrlDown = false
hs.eventtap.event.newKeyEvent({}, 55, false):post()
end
return true
end
if leftCtrlDown and
(eventType == hs.eventtap.event.types.keyDown
or eventType == hs.eventtap.event.types.keyUp) then
local flags = event:getFlags()
flags.ctrl = nil
flags.cmd = true
event:setFlags(flags)
end
return false
end)
ctrlToCmd:start()これでCtrl+C、Ctrl+V、Ctrl+X、Ctrl+Z、Ctrl+A、Ctrl+SなどをWindowsと同じ指使いで使えるようになった。
Windows側で変換を増やしすぎず、Macへ届いた後の処理をHammerspoonへ任せる方が、今回の環境では安定した。
Moonlight中だけスクロールを速くする
WindowsからMacを操作すると、マウスホイールのスクロールがかなり遅く感じた。Mac側のスクロール速度を変えてSunshineも再起動したが、体感はほぼ変わらなかった。
そこでMoonlightがアクティブな間だけ、AHKでホイール入力を3回分送るようにした。
#HotIf WinActive("ahk_exe moonlight.exe")
WheelUp::Send "{WheelUp 3}"
WheelDown::Send "{WheelDown 3}"
#HotIf3倍は俺の環境で自然に感じた値だ。速すぎるなら2へ下げればいい。Moonlightだけを条件にしているため、通常のWindows側スクロールには影響しない。
無変換・変換キーの設定とまとめる場合、Windows側のAHKは次の形になる。
#Requires AutoHotkey v2.0
#HotIf WinActive("ahk_exe moonlight.exe")
vk1D::Send "{F16}"
vk1C::Send "{F17}"
WheelUp::Send "{WheelUp 3}"
WheelDown::Send "{WheelDown 3}"
#HotIfまとめ｜MacBook Airを外出用に整えるための調整
最終的に、WindowsからMacを調整する時によく使う操作はかなり揃った。
- 無変換 → 英数
- 変換 → かな
- Ctrl+C / Ctrl+V → コピー・貼り付け
- Ctrl+Z / Ctrl+A / Ctrl+S → 元に戻す・全選択・保存
- マウスホイール → Moonlight中だけ3倍
完全にWindowsと同じではない。それでも、日本語入力、Ctrl系ショートカット、スクロールという毎回触る部分の違和感はかなり減った。
家でどっぷり作業する時は基本的にWindows。MacBook Airは外出時に軽く作業するための端末。今回のリモート環境は、そのMacBook Airを家で調整し、外出先で最低限使える状態に仕上げるためのものだ。
つまり、リモート操作をメインの作業方法にしたいわけではない。家ではWindows、外ではMacBook Airという使い分けを崩さず、準備の時だけWindowsからMacへ手を伸ばせるようにしたかった。
Optionキー単押しのスクリーンショットやウインドウ移動など、まだ調整したい部分はある。ただ、調整だけに時間を取られて実際の作業が進まなくなるのも本末転倒だ。
外出先で最低限困らないところまでは整った。今は「これで十分」と区切り、必要になった時だけ続きを触るくらいがちょうどいいと思っている。
（その後SunshineとMoonlightを改造して快適にしようとして挫折したのはまた別の話・・・）
コメント