企業支給のMacやWindowsマシンにLogitech Options+を入れようとして、情シスに止められた経験はないでしょうか。
あるいは、自分でインストールしてみたものの「なんかこのアプリ、ちょっと信用できないな」と感じてアンインストールした、という人もいると思います。
そのモヤモヤには、ちゃんと言語化できる理由があります。
OSSの代替ツール OpenLogi を実際に試した記録として、インストールから設定ファイルの記述・動作確認まで追えるようにまとめました。
動かなかった部分も正直に書くので、読み終わったあとに自分の環境へ導入するかどうかを判断できるはずです。
Logitech Options+が企業PCで嫌われる理由
Options+の最大の問題は、アカウント登録が前提の設計 になっていることです。
マウスのDPIを変えたいだけなのに、Logicoolアカウントを作ってサインインしないと設定が保存できない。
「ローカルで完結してほしい」と感じるエンジニアは多いはずです。
インストール時の挙動も気になります。
macOSにOptions+を入れると、ログイン項目にバックグラウンドプロセスが自動追加されます。
Logitech公式のトラブルシューティングドキュメントには「このプロセスを無効にするとOptions+がローディング画面で止まる」と明記されており、常駐を切ることは事実上できません。
さらに Input Monitoring の権限を要求してきます。
キー入力を監視できる権限をサードパーティのアプリに渡すことに、セキュリティ担当者が難色を示すのは当然です。
ネットワーク通信の実態も不透明です。
Options+はクラウドで設定を管理する設計になっており、バックグラウンドで通信が発生します。
EDR（エンドポイント検知・対応）ツールを導入している環境では、この通信がアラートを引き起こすことがあります。
プロキシ経由でしかインターネットに出られない環境では、そもそも正常に動作しないケースもあります。
「なんとなく嫌」という感覚の正体は、だいたいこのあたりです。
アカウント必須・常駐プロセス・Input Monitoring権限・不透明なネットワーク通信。
上司や情シスに説明するときは、この4点を挙げれば話が通りやすくなります。
HID++をローカルで直接叩くとはどういうことか
Logicoolのマウスは、USB・Bluetooth・Unifyingレシーバーを通じて HID++ というプロトコルで通信しています。
HIDはHuman Interface Deviceの略で、マウスやキーボードをOSに認識させるための標準規格です。
HID++はそこにLogicool独自の拡張を乗せたもので、DPIの変更やボタンのリマップといった「デバイス固有の設定」をソフトウェアから制御するために使われます。
Options+はこのHID++を使ってデバイスと通信していますが、設定の保存・同期をクラウド経由で行う設計になっています。
つまり「デバイスと話す部分」と「設定を管理する部分」が分離していて、後者がアカウントとクラウドに依存しているわけです。
OpenLogiはここを切り離しています。
HID++でデバイスと直接やり取りする部分だけをRustで実装し、設定はローカルのTOMLファイルに書く。
クラウドもアカウントも、そもそも経路に存在しません。
OpenLogiのREADMEには「デバイス画像のフェッチ以外に自動的なネットワーク通信は発生しない」と明記されています。
アップデートの確認やダウンロードも、ユーザーが明示的に操作したときだけ動く設計です。
「なぜローカル完結できるのか」という疑問への答えは、 HID++自体はもともとローカルで完結できる仕様 だから、ということになります。
Options+がクラウドを使っているのはLogicoolのビジネス上の選択であって、プロトコルの制約ではないのです。
OpenLogiのインストールと対応デバイスの確認
リポジトリは AprilNEA/OpenLogi です。
GitHub上のスター数は執筆時点で8,800を超えており、mouse-remappingトピックでも注目を集めているプロジェクトです。
macOSならHomebrewのcaskが一番手軽です。
brew install --cask open-logi
これだけでメニューバーエージェントが動き始め、接続中のLogicoolマウスを検出します。
WindowsとLinuxのバイナリはGitHubのReleasesページから取得できます。
cargo installでのインストールについてはREADMEを参照してください（crate名の確認が必要です）。
READMEには「WindowsはWindows 11で動作確認済みだが、macOS・Linuxビルドよりも荒削りな部分が残っている」と書かれています。
実際に試した感触でも、macOSが一番安定していました。
Linuxで使う場合は、一般ユーザーがHIDデバイスに直接アクセスするためのudevルールを追加する必要があります。
リポジトリにudevルールファイルが含まれているので、インストール後にリポジトリのドキュメントを確認して配置してください。
この設定をしないと、デバイスへのアクセスにsudo権限が必要になります。
管理者権限が使えない環境では情シスに相談するしかありませんが、「このudevルールファイルを置いてほしい」と具体的に依頼できるのは交渉のしやすさとして地味に助かります。
自分のデバイスが対応しているかどうかは、アプリを起動してマウスを接続すれば分かります。
対応デバイスであれば、インタラクティブなマウス図が表示されてボタンを選択できる状態になります。
対応外の場合は検出されないか、機能が制限された状態で表示されます。
TOMLで設定を書く：ボタンリマップ・DPI・SmartShift
設定ファイルの場所はOSによって異なります。
macOSとLinuxは ~/.config/openlogi/config.toml です。
Windowsのパスについてはリポジトリの CONFIGURATION.md を参照してください（検索結果では途中で切れており、正確なパスを断定できないため）。
GUIとバックグラウンドエージェントは同じファイルを読みに行くので、テキストエディタで直接編集してもGUIから操作しても結果は同じです。
このファイルがプレーンテキストのTOMLであることは、実務上かなり便利です。
Gitで管理できますし、新しいマシンにセットアップするときはファイルをコピーするだけで設定が再現されます。
CONFIGURATION.mdに記載されているフィールド構成をもとに、設定の概念を示す擬似的な例を示します。
実際のアクション名やデバイスキーの書式は、リポジトリのドキュメントおよびGUIで確認してください。
# デバイスキーの書式はリポジトリのドキュメントを参照
[devices."<your-device-key>"]
enabled = true
# DPIプリセットの定義（複数指定可）
dpi_presets = [800, 1200, 2400]
dpi = 1200
# SmartShiftの設定（ホイールの慣性スクロール切り替え）
[devices."<your-device-key>".smartshift]
enabled = true
threshold = 20
# ボタンリマップ（アクション名はドキュメント・GUIで確認）
[devices."<your-device-key>".bindings]
# 例: 各ボタンに対応するアクション文字列を指定する
# アプリごとのバインディング上書き
# macOS: bundle id / Linux: アプリID / Windows: 実行ファイルの小文字パス
[devices."<your-device-key>".per_app_bindings]
# "com.apple.Terminal" = { back = "<action>" }
フィールド名（bindings・smartshift・dpi_presets・per_app_bindings）はCONFIGURATION.mdで確認できます。
ただし、各ボタンに割り当てるアクション文字列の具体的な値はGUIを操作するか、リポジトリのドキュメントやIssuesで確認するのが確実です。
GUIでボタンをクリックして設定すると、その内容がTOMLに書き出されるので、まずGUIで動かしてから生成されたTOMLを読む、という進め方が一番迷いません。
per_app_bindings は地味に便利な機能で、アプリごとにボタンの動作を変えられます。
ターミナルでは別のショートカット、ブラウザでは戻るボタンのまま、という使い分けができます。
SmartShiftはMX Masterシリーズ特有のホイール機能で、ゆっくり回すとラチェット（カチカチ）モード、速く回すとフリースピン（慣性）モードに自動で切り替わります。
thresholdの値が小さいほど、少しの速度でフリースピンに切り替わります。
実機で試してわかったこと：動いた機能と限界
手元のMX Master 3（macOS環境）で試した結果を正直に書きます。
DPIの変更とプリセット切り替え はすんなり動きました。
GUIでプリセットを選ぶと即座に反映され、TOMLを直接書き換えた場合も次回エージェント起動時に設定が読み込まれます（自動検知の挙動については実機で細かく検証しきれていないため、確実を期すならエージェントの再起動を挟むのが無難です）。
ボタンリマップ も基本的な操作は問題なく動きます。
サムボタンや戻る・進むボタンへの割り当ては安定していました。
per_app_bindingsも試しましたが、アプリ切り替えのタイミングで少し遅延を感じる場面がありました。
体感的なものなので個人差があると思いますが、気になる人は気になるかもしれません。
SmartShift の設定変更はデバイスに書き込まれ、閾値の調整も反映されました。
Options+と比べて設定できる項目は少ないですが、よく使う部分はカバーされています。
一方で、うまくいかなかった部分もあります。
Windowsで試したところ、デバイスの検出に時間がかかる場面があり、READMEに書かれている「荒削り」という表現は正直な評価だと感じました。
安定して使いたいなら、現時点ではmacOSかLinuxが無難です。
また、対応デバイス外のマウスを接続したときは、アプリには表示されるものの設定の書き込みができませんでした。
自分のデバイスが対応リストに入っているかどうかは、リポジトリのREADMEかIssuesで確認するのが確実です。
Linuxでの代替としては Solaar が長く使われており、対応デバイスの幅が広いです。
OpenLogiはまだ若いプロジェクトで、Solaarほど対応デバイスが多くありません。
Linux環境でデバイスが対応外だった場合は、Solaarを試してみる価値があります。
macOSでMX Masterシリーズを使っていて、Options+のアカウント要求やバックグラウンド常駐を避けたいなら、現時点でも十分実用的な選択肢です。
Windowsメインの環境や、対応デバイスが不明な場合は、まずリポジトリのIssuesを確認してから判断するのがいいと思います。
プロジェクト自体は活発に開発が続いており、ロードマップに記載された機能が順次追加されています。
今すぐOptions+の完全な代替にはならなくても、追いかける価値はあるツールです。
株式会社ホコサキは、山口県宇部を拠点にWeb制作・業務システム開発・AI活用支援を手がけているIT企業です。
「企業PCのセキュリティポリシーと開発者体験をどう両立するか」といった現場の悩みについて、要件の整理から具体的な手段の選定まで実務の視点でお手伝いできます。
ご相談は お問い合わせページ からどうぞ。