見出し画像
Photo by kiyumoto_works

Windows、Ubuntuで操作ミスを避けるためにキーボードとマウスをDeskflowで共通化し、どうせならmacbookもと欲張ったら詰んでいる件

Mayu

昨日のnote投稿時に途中までubuntuで作って、後は慣れた方のWindowsでいいやと思ったら、下書きと間違ってubuntu上で投稿済みの記事を消すという操作ミスをしました💦 キーボードとマウスをLAN内で共有するDeskflowを入れてはいたけど、日本語変換が違うので微妙に使えない状態になっていたことが遠因です。また、macbook pro（m1）で何回かインストールに失敗して機能的に劣るBarrierしか動かない状態なので、今回まとめてGeminiのDeepResearchで調べさせました。

クライアントがBarrierとなった場合の問題は、キーを一度でも長押しするとマウスカーソルがサーバであるWindowsの画面中央に戻ってしまうという、よく知られてはいるけど、なぜか解決しない不便な現象のことです。

なお、以下の出力で述べられているのは高級なハードウェアKVMですが、プロンプトを書いていたときに想定していたのは、普通の2000円ほどのものですｗ

DeepResearchについて新たにわかった残念なこととして、夜、データセンターが混んでいる時間帯に実行しようとすると、とても長い時間待つことになって、最終的に計画段階か計画実施段階かにかかわらず、高頻度で失敗した扱いになり、それで１回分のDeepResearch枠を消費するということです……非常に重い処理なのはわかるけど、さっさと早い時間帯に使い切った者勝ちみたいなのは、ちょっと……こうなると、一応だけど課金しているDeepResearchは前倒しで使って、足りなくなった時だけ設定面倒だけどGPT Researcherなり、慣れてないけど他のAIを使う方がお得感が違いすぎると思いました🙇

Deskflowを中心としたマルチプラットフォーム・ソフトウェアKVMの技術的有効性と日本語入力環境における操作一貫性の構築

コンピュータ間の入力デバイス共有技術、いわゆるソフトウェアKVM（Keyboard, Video, Mouse）の領域において、Deskflowは長年断片化していたオープンソース・コミュニティの系譜を統合する次世代のアップストリームとして急速に台頭している［1］。かつてSynergyが担っていたオープンソースとしての役割は、BarrierやInput Leapといったフォークを経て、現在はSymless社による強力な支援を受けるDeskflowへと集約されつつある［2］。本報告書では、Windows、macOS、Ubuntu（Linux）が混在する現代のマルチプラットフォーム環境におけるDeskflowの操作的有効性を、既存のOSSとの比較を交えて詳述するとともに、特にApple Silicon（M1以降）環境特有の障害対応、ネットワーク遅延に起因するカーソル挙動の修正、および日本語配列キーボードにおける入力一貫性の確保に関する技術的考察を行う。

ソフトウェアKVMの歴史的変遷とDeskflowの立脚点

ソフトウェアKVMの歴史は、1996年にCosmo Software社（SGIの子会社）で開発された「CosmoSynergy」にまで遡ることができる［2］。Deskflowはこの歴史的な資産を現代のセキュリティ規格とOSのアーキテクチャに適応させるべく、2024年にSynergy v1.15をベースとして再定義されたプロジェクトである［2］。
［2］ https://github.com/deskflow/deskflow/wiki/Project-Forks 1996: Richard Lee and Adam Feder created a proprietary in-house tool called CosmoSynergy at Cosmo Software, Inc. (a subsidiary of SGI).... 2001: Chris Schoeneman began writing Synergy from scratch as a reimplementation of CosmoSynergy, featuring Linux support.... 2024: The Deskflow project was created as the community-driven upstream of Synergy.

Deskflowの誕生背景には、2018年にSynergyからフォークした「Barrier」のメンテナンス停滞と、その後継を目指した「Input Leap」の開発遅延がある［2］。Barrierは現在「死んだフォーク（dead fork）」とみなされており、その資産はDeskflowへと統合されている［1］。Deskflowは、Windows 10 v1809以上、macOS 12/13以上、そしてWayland対応の最新Linuxディストリビューションを公式にサポートしており、各OSのセキュリティモデル（macOSのアクセシビリティ権限やLinuxのPortals）に最適化された設計となっている［1］。

既存ソフトウェアKVMとの機能比較

Deskflowは、既存のOSS（Barrier, Input Leap）および商用版（Synergy v1/v3）と比較して、特に最新OSへの対応力と開発の持続性において優位性を持っている。以下の表は、各プロジェクトの技術的ステータスと特徴を比較したものである。

$$
\small \def\arraystretch{1.5}
\begin{array}{|l|l|l|l|l|} \hline
\textsf{\textbf{項目}} & \textsf{\textbf{Deskflow}} & \textsf{\textbf{Input Leap}} & \textsf{\textbf{Barrier}} & \textsf{\textbf{Synergy v3.x}} \\ \hline
\textsf{\textbf{開発状況}} & \textsf{活発（アップストリーム）［2］} & \textsf{準アクティブ［2］} & \textsf{停止（廃止）［2］} & \textsf{活発（商用）［5］} \\ \hline
\textsf{\textbf{ライセンス}} & \textsf{GPL-2.0［1］} & \textsf{GPL-2.0［2］} & \textsf{GPL-2.0［1］} & \textsf{プロプライエタリ［2］} \\ \hline
\textsf{\textbf{GUI基盤}} & \textsf{Qt 6.7+［1］} & \textsf{Qt 5/6［2］} & \textsf{Qt 5［2］} & \textsf{Electron［2］} \\ \hline
\textsf{\textbf{Wayland対応}} & \textsf{公式サポート［1］} & \textsf{開発中［6］} & \textsf{非推奨［3］} & \textsf{対応［3］} \\ \hline
\textsf{\textbf{ARM64 (Mac)}} & \textsf{ネイティブ対応［1］} & \textsf{対応［2］} & \textsf{不安定［7］} & \textsf{対応［5］} \\ \hline
\textsf{\textbf{互換性}} & \textsf{Barrier/Input Leap/Synergy 1［1］} & \textsf{Barrier互換［2］} & \textsf{Synergy 1互換［1］} & \textsf{Synergy独自［2］} \\ \hline
\end{array}
$$

［1］ https://github.com/deskflow/deskflow Deskflow has network compatibility with all forks: Requires Deskflow >= v1.17.0.96.... Deskflow will just work with Input Leap and Barrier (server or client). Connecting a Deskflow client to a Synergy 1 server will also just work.

Deskflowの技術的特徴として特筆すべきは、Linux環境におけるWaylandへの完全対応である。従来のX11ベースの入力エミュレーションとは異なり、libei（Input Emulation）およびlibportalを利用したセキュアな入力イベントの送受信を実現している［1］。

macOS Apple Silicon環境における導入と権限管理の障壁

M1/M2/M3チップを搭載したApple Silicon Mac、および最新のmacOS 15 Sequoia環境においてDeskflowを運用する場合、OSの強力なセキュリティ機構である「TCC (Transparency, Consent, and Control)」への適切な対応が不可欠となる。

初期導入時の隔離属性解除

DeskflowはAppleの公証（Notarization）を一部受けていないビルドが存在するため、ダウンロード後の初回起動がシステムによってブロックされる場合がある［1］。この場合、以下のターミナルコマンドを用いて隔離属性（Quarantine Attribute）を明示的に解除する必要がある。
［1］ https://github.com/deskflow/deskflow This occurs because we do not use an Apple certificate for notarization. Clear the quarantine attribute to run the app: xattr -c Deskflow.app.

アクセシビリティと入力監視の重層的権限設定

macOSにおいて、Deskflowがキーボードやマウスのイベントをキャプチャ（サーバー側）またはシミュレート（クライアント側）するためには、「アクセシビリティ」および「入力監視」の二重の許可が必要である［1］。特に重要なのは、GUIアプリケーションとしての「Deskflow.app」だけでなく、そのパッケージ内に含まれる実行バイナリ「deskflow」プロセスに対しても個別に権限を付与しなければならない点である［9］。

  1. 「システム設定」＞「プライバシーとセキュリティ」＞「アクセシビリティ」を開く。

  2. FinderでDeskflow.appを右クリックし、「パッケージの内容を表示」を選択する。

  3. Contents/MacOS/deskflow バイナリをアクセシビリティのリストにドラッグ＆ドロップする［9］。

  4. 同様の手順を「入力監視」セクションでも実施する［8］。

［9］ https://github.com/deskflow/deskflow/issues/7868 FYI this is not obvious how to "add the deskflow process" to the Privacy & security settings... Open Finder. Go to Applications, right-click on 'Deskflow' -> Show Package Content. Go to Contents -> MacOS. Drag & Drop the file deskflow into the Accessiblity settings windows.

さらに、macOS 15 Sequoia以降では、ローカルネットワーク上での他デバイスとの通信を許可するために、「ローカルネットワーク」設定の有効化も必須となっている［1］。

アップグレード時の権限不整合と解決策

Deskflowのバージョンを更新した際、設定画面上では権限が「オン」になっているにもかかわらず、実際には入力が反映されない「権限の不整合」が発生することが報告されている［10］。これはmacOSの権限データベースがバイナリのハッシュ値や署名の変更を検知し、古い権限を無効化するためである。この場合、単なるオン／オフの切り替えでは不十分であり、以下のクリーンリセット手順が推奨される。
［10］ https://github.com/deskflow/deskflow/issues/8762 I found that I had to FIRST delete the entry altogether for Deskflow within the Privacy & Security > Accessibility section (using the '-' button) and THEN reinstall... I then restarted the Deskflow app within /Applications, it prompted me to enable Accessibility again for Deskflow, and it worked!

このプロセスにおいて、既存のエントリを「－」ボタンで完全に削除した後、Macを一度再起動させることが、OS内部のTCCデータベースをリフレッシュする上で極めて有効である［10］。

マルチプラットフォーム混在時のカーソル挙動とネットワーク不具合への対策

Barrierが混在する環境や、特定のネットワーク条件下では、カーソルが画面の中央に引き戻される（ジャンプする）事象や、激しい遅延（ラグ）が発生することがある［7］。

1. 境界移動時のジャンプ現象（Barrier混在時）

サーバーがmacOS、クライアントがWindows（Barrier）の構成において、画面端へ移動しようとした際にカーソルが元の画面の中央に跳ね返る現象が頻発している［7］。これは入力イベントのパケットが境界通過の瞬間に正しく同期されないために発生する。

対策: サーバーの詳細設定（Advanced Server Settings）において「Switch after waiting」を有効にし、25ms〜200ms程度の遅延を設定することで、境界判定のチャタリングを抑制できる［7］。
［12］ https://github.com/debauchee/barrier/issues/300 enabling "Switch after waiting" in the Advanced Server settings area fixed this issue entirely for me. The minimum setting seems to be 25ms and is an almost entirely unnoticeable delay.

2. 高ポーリングレートマウスによる通信遅延

ゲーミングマウスなど、レポートレートが150Hzを超えるデバイスを使用している場合、Deskflowがネットワーク経由で送信するイベント数が過多となり、パケットの輻輳と処理の遅延が発生する［13］。
対策: マウス側のユーティリティを使用してレポートレートを125Hz程度に下げるか、Deskflow側で高レート入力のフィルタリング機能が実装されるのを待つ必要がある。現状ではポーリングレートを下げることが最も確実な回避策である［13］。
［13］ https://github.com/deskflow/deskflow/issues/8527 When a high report rate is set—specifically higher than 150—the mouse cursor on the receiving end of Deskflow experiences noticeable latency and drift, which is quite severe.

3. Apple AWDL (Wi-Fi) 干渉への対応

macOSをクライアントとして利用する場合、Wi-Fi環境下でカーソルが周期的にカクつく「Stuttering」が発生することがある。これは、AppleのAirDropやAirPlayで使用されるプロトコル「AWDL」が、Wi-Fiチップを定期的にスキャンするために発生するパケットロスが原因である［8］。
対策: 以下のコマンドでAWDLインターフェースを無効化することで、通信の安定性が向上する［8］。 sudo ifconfig awdl0 down

日本語入力環境における不整合の解消と一貫性設定

Windowsサーバー、macOS/Ubuntuクライアントの構成において、日本語キーボード（JIS配列）特有のキーコード変換ミスや、IME（日本語入力）の状態同期不足が、実用上の最大のボトルネックとなる。

1. キーレイアウトの誤認と「ja」設定のパラドックス

Deskflowの設定でサーバー側を「ja（日本語）」レイアウトに固定している場合、Macクライアント側でキー入力を全く受け付けない事象が報告されている［14］。これは、OS間の文字合成ロジックにおいて、物理的なキーコードとOSが期待するシンボルのマッピングが衝突するためである。
［14］ https://github.com/deskflow/deskflow/issues/8899 When the Linux server is set to ja and the Mac only has the Japanese layout configured... none of the keys typed on the server work on the Mac. Logs indicate "DEBUG1: key 0061 is not on keyboard"... If the Linux server layout is set to English US (en), the physical Japanese keyboard types correctly on the Mac client.

皮肉なことに、サーバー側の入力言語を「English US (en)」に設定した上で、物理的なJISキーボードで入力を行うと、クライアント側で正しく記号が入力されるという「マッピングのパラドックス」が存在する［14］。これを回避するためには、Macクライアント側の「Use server's keyboard language on this computer」オプションを「無効」にし、各OSに独立した入力レイアウトを管理させることが一貫性維持の第一歩となる［8］。

2. 修飾キー（Modifier Keys）の最適マッピング

Windowsの「Ctrl/Win/Alt」とMacの「Control/Option/Command」は物理的な配置が異なるため、指の筋肉記憶に合わせたリマッピングが必要となる。DeskflowのGUIでは制限があるため、設定ファイル（.conf）をエクスポートし、手動でマッピングを書き換える手法が最も柔軟である［16］。

$$
\small \def\arraystretch{1.5}
\begin{array}{|l|l|l|} \hline
\textsf{\textbf{Windows物理キー}} & \textsf{\textbf{Mac側の挙動（推奨設定）}} & \textsf{\textbf{設定ファイル記述例}} \\ \hline
\textsf{\textbf{Ctrl}} & \textsf{\textbf{Command (⌘)}} & \textsf{ctrl = meta［17］} \\ \hline
\textsf{\textbf{Windowsキー}} & \textsf{\textbf{Alt/Option (⌥)}} & \textsf{super = alt［17］} \\ \hline
\textsf{\textbf{Alt}} & \textsf{\textbf{Control (⌃)}} & \textsf{alt = ctrl［17］} \\ \hline
\end{array}
$$

［17］ https://superuser.com/questions/90223/synergy-key-mapping I've switched ctrl and commmand keys so that ctrl-c copies regardless of machine. This is done in the synergy gui by double clicking the client and setting: ctrl: Meta meta: ctrl.

3. JIS特有キー（無変換・変換・AltGr）の処理

日本語配列キーボード特有の「無変換（英数）」「変換（かな）」キーや、ヨーロッパ言語併用時に使用される「AltGr」キーは、デフォルトではクライアントに送信されない、あるいは誤変換される傾向がある［8］。これについても、設定ファイルの section: screens に以下のオプションを追記することで、部分的な改善が見込める。

  • alt = altgr: AltキーをAltGrとして送信する［8］。

  • altgr = shift: 近年のバージョンで報告されている、AltGrの代替変換オプション［8］。

ソフトウェアKVMとハードウェアKVMの補完的運用と耐障害性

Deskflowのようなソフトウェアベースのソリューションは利便性が高い反面、ネットワークやOSの状態に依存する脆弱性を持つ。プロフェッショナルな環境では、ハードウェアKVM（特にKVM-over-IP）との併用が推奨される［18］。

1. ソフトウェアKVM (Deskflow) のメリットと限界

  • メリット: 追加コスト不要、配線なし、高解像度マルチモニター対応、クリップボード共有［20］。

  • 限界: BIOS/OSインストーラでの操作不可、ネットワーク遅延の影響を受ける、セキュリティ上の攻撃対象領域（Surface Area）の拡大［18］。

2. ハードウェアKVM (KVM-over-IP) の有効性

  • OS非依存: ドライバ不要で、OS起動前のBIOS画面や故障時のトラブルシューティングに対応可能［19］。

  • 安定性: 本番ネットワーク（In-band）とは別のアウトオブバンド（Out-of-band）で動作するため、システムのクラッシュ時でもアクセスを維持できる［18］。

$$
\small \def\arraystretch{1.5}
\begin{array}{|l|l|l|} \hline
\textsf{\textbf{比較項目}} & \textsf{\textbf{ソフトウェアKVM (Deskflow)}} & \textsf{\textbf{ハードウェアKVM (TinyPilot等)}} \\ \hline
\textsf{\textbf{初期コスト}} & \textsf{無料［20］} & \textsf{高価（ハードウェア購入が必要）［19］} \\ \hline
\textsf{\textbf{BIOS操作}} & \textsf{不可［18］} & \textsf{可能［19］} \\ \hline
\textsf{\textbf{遅延}} & \textsf{極めて低い（LAN環境）［19］} & \textsf{わずかに高い (100-140ms)［19］} \\ \hline
\textsf{\textbf{セキュリティ}} & \textsf{OS権限に依存［18］} & \textsf{物理的・ネットワーク的隔離が可能［18］} \\ \hline
\end{array}
$$

［19］ https://tinypilotkvm.com/blogs/insights/kvm-over-ip-vs-software-remote-control Software solutions offer attractive benefits... Works across different platforms (Windows, macOS, Linux)... However, they can fall short when you need more control or if you're managing critical systems where downtime isn't an option.... Hardware-based solutions like KVM over IP are perfect for situations where security and complete control are non-negotiable.

結論と推奨運用プロトコル

Deskflowは、その柔軟なアーキテクチャと活発な開発体制により、Windows、macOS、Ubuntuが混在する高度なマルチプラットフォーム環境において、最も信頼に足る操作共有ツールであると言える［1］。Apple Silicon Mac環境での初期導入障壁や、日本語キーボードにおけるマッピングの不整合といった課題は、OSのセキュリティ仕様や各国のキー配列に起因するものであり、Deskflowの提供する詳細なカスタマイズ機能（設定ファイル編集や権限リセット手順）を適用することで、十分に実用レベルの安定性を確保できる。

特に、M1以降のMac環境においては、アクセシビリティ権限のバイナリ直接付与とOS再起動を組み合わせたクリーンセットアップが安定稼働の鍵となる［9］。また、日本語入力に関しては、サーバー・クライアント間のレイアウト自動同期を避け、手動で修飾キーをリマッピングすることが、OSを意識させないシームレスな操作体験（One Keyboard, Multiple OS）を実現するための最適解である［14］。

将来的には、LinuxにおけるWayland Portalsの成熟に伴い、さらにセキュアかつ低遅延な入力共有が期待される［4］。Deskflowをインフラの核としつつ、必要に応じてBIOSレベルの操作を支えるハードウェアKVMをバックアップに備えることで、マルチプラットフォーム環境における究極の生産性と耐障害性の両立が可能となる。

引用文献

  1. deskflow/deskflow: Share a single keyboard and mouse between multiple computers. - GitHub, 2月 15, 2026にアクセス、 https://github.com/deskflow/deskflow

  2. Project Forks · deskflow/deskflow Wiki · GitHub, 2月 15, 2026にアクセス、 https://github.com/deskflow/deskflow/wiki/Project-Forks

  3. Synergy, Deskflow, Input Leap, Barrier... what's the difference? : r/linux - Reddit, 2月 15, 2026にアクセス、 https://www.reddit.com/r/linux/comments/1g6atbf/synergy_deskflow_input_leap_barrier_whats_the/

  4. Wayland support: Known bugs · deskflow deskflow · Discussion #7499 - GitHub, 2月 15, 2026にアクセス、 https://github.com/deskflow/deskflow/discussions/7499

  5. Deskflow - ArchWiki - Arch Linux, 2月 15, 2026にアクセス、 https://wiki.archlinux.org/title/Deskflow

  6. synergy vs input-leap - compare differences and reviews? - LibHunt, 2月 15, 2026にアクセス、 https://www.libhunt.com/compare-synergy-vs-input-leap

  7. Cursor jumps to the exact middle of primary display on macOS #1043 - GitHub, 2月 15, 2026にアクセス、 https://github.com/debauchee/barrier/issues/1043

  8. Workarounds · deskflow/deskflow Wiki · GitHub, 2月 15, 2026にアクセス、 https://github.com/deskflow/deskflow/wiki/Workarounds

  9. assistive devices does not trust this process · Issue #7868 - GitHub, 2月 15, 2026にアクセス、 https://github.com/deskflow/deskflow/issues/7868

  10. macOS: Not working after upgrade · Issue #8762 · deskflow/deskflow - GitHub, 2月 15, 2026にアクセス、 https://github.com/deskflow/deskflow/issues/8762

  11. macos always ask me to allow Deskflow to control my computer · Issue #8028 - GitHub, 2月 15, 2026にアクセス、 https://github.com/deskflow/deskflow/issues/8028

  12. [Bug] Mouse is jumping · Issue #300 · debauchee/barrier - GitHub, 2月 15, 2026にアクセス、 https://github.com/debauchee/barrier/issues/300

  13. High report rate mouse cause drift in client · Issue #8527 - GitHub, 2月 15, 2026にアクセス、 https://github.com/deskflow/deskflow/issues/8527

  14. Incorrect keyboard layout conversion · Issue #8899 · deskflow ..., 2月 15, 2026にアクセス、 https://github.com/deskflow/deskflow/issues/8899

  15. Keyboard layout on client changes unexpectedly · Issue #8083 · deskflow/deskflow - GitHub, 2月 15, 2026にアクセス、 https://github.com/deskflow/deskflow/issues/8083

  16. Command Line · deskflow/deskflow Wiki - GitHub, 2月 15, 2026にアクセス、 https://github.com/deskflow/deskflow/wiki/Command-Line

  17. Synergy Key Mapping - Super User, 2月 15, 2026にアクセス、 https://superuser.com/questions/90223/synergy-key-mapping

  18. KVM Switching vs. Hardware Virtualization - Black Box, 2月 15, 2026にアクセス、 https://www.blackbox.com/insights/blackbox-explains/inner/detail/kvm-switches-and-extenders/kvm-switching/kvm-switching-vs-hardware-virtualization

  19. KVM over IP vs. Software Remote Control - TinyPilot, 2月 15, 2026にアクセス、 https://tinypilotkvm.com/blogs/insights/kvm-over-ip-vs-software-remote-control

  20. Software KVM vs Hardware KVM Switch - ShareMouse, 2月 15, 2026にアクセス、 https://www.sharemouse.com/kvm-software-vs-hardware-kvm/

  21. 10 Reasons KVM Is Better Than Software - Black Box, 2月 15, 2026にアクセス、 https://www.blackbox.com/en-sa/insights/blogs/tps/2019/12/19/10-reasons-kvm-is-better-than-software

いいなと思ったら応援しよう！