【ITニュース解説】SSH Tunnel Manager in Rust: CLI vs Native GUI Trade-offs

SSHトンネルは、外部ネットワークから直接アクセスできない内部のサーバーやデータベースに、安全な経路を確保して接続する際に利用される重要な技術である。例えば、開発中のデータベースや社内ネットワークにあるシステムに、自宅や外出先から安全に接続するために使われる。しかし、SSHトンネルを設定するためのコマンドは長く複雑で、覚えるのが難しいという課題があった。特に、複数のプロジェクトや環境で多数のSSHトンネルを管理する場合、どのコマンドがどの接続に対応しているのかを覚えておくのは非常に手間がかかり、誤って停止させてしまうなどの問題も発生しやすかった。

このような問題を解決するため、ある開発者が、macOS向けのGUI（グラフィカルユーザーインターフェース）アプリが提供するような手軽さでSSHトンネルを管理できるツールを、OSに依存しない形で開発しようと試みた。具体的には、プログラミング言語Rustを使い、コマンドラインから操作するCLI（コマンドラインインターフェース）版と、マウスで操作できるGUI版の二種類を作成し、それぞれの開発におけるメリットとデメリットを比較検討した。

この二つのツールは、基本的な仕組みを共有している。Rust言語には、SSHクライアントとして十分な機能を持つ公式のライブラリがまだ確立されていないため、どちらのバージョンも、システムに元々インストールされている「ssh」コマンドを「子プロセス」として起動し、そのプロセスをプログラムから管理するという方法をとっている。これにより、SSH接続の認証方法や鍵の設定といった複雑な部分はシステムのSSHコマンドに任せ、Rust製のツールはトンネルの開始、停止、状態確認といった管理に専念できる。これは、複雑なSSHコマンドの記述を回避しつつ、SSHの強力な機能を活用するための効率的なアプローチである。

最初に開発されたCLI版は、テキスト形式の設定ファイル（TOML形式）でSSHトンネルの接続情報を定義し、専用のコマンド（例えばtunlctl up <トンネル名>）を実行することでトンネルの開始や停止、状態確認などを行う。CLI版の大きな利点は、まずその「配布の容易さ」にある。作成したツールを他の開発者に使ってもらう際、特定のコマンドを実行するか、あるいは単一のプログラムファイルを渡すだけで利用開始できるため、特別なコード署名や公証といった手続き、App Storeのような審査を必要としない。また、「スクリプトとの連携」も得意である。コマンドラインツールであるため、他の自動化スクリプトやプログラムから簡単に呼び出して操作でき、例えばトンネルの状態をJSON形式で出力して他のツールに渡すといった柔軟な使い方が可能である。さらに、「永続化」についても、LinuxのsystemdやmacOSのlaunchdといったOS標準のサービス管理ツールと連携することで、CLIツールが終了してもバックグラウンドでトンネルを維持できる。

一方でCLI版には欠点もあった。トンネルが正常に稼働しているか、何らかの原因で停止してしまったかといった「視覚的な状態表示」がないため、ユーザーは定期的にコマンドを実行して状態を確認する必要がある。また、システムトレイに表示されるアイコンのように、クリック一つでトンネルを切り替えるような「直感的な操作性」も提供できないため、頻繁な操作には毎回コマンドを打つ手間がかかるという問題があった。

次に開発されたGUI版は、Tauriというフレームワークを用いて、RustのバックエンドとWeb技術（HTML/CSS）で作成されたフロントエンドを組み合わせた。このバージョンは、システムトレイにアイコンを表示し、そこからメニューを開いてトンネルのオンオフを切り替えるなどの操作を提供する。GUI版の大きな利点は、「視覚的な状態表示」である。システムトレイのアイコンがトンネルの状態に応じて色を変えるなど、一目で稼働状況がわかるため、ユーザーエクスペリエンス（UX）が大幅に向上する。これは、多くの人が日々の作業で頻繁に利用するツールにとって非常に重要な要素である。また、GUIアプリ自体が常に起動している長寿命なプロセスであるため、SSHトンネルの「プロセス寿命管理」が簡素化される。個別にバックグラウンドサービスを設定する手間がなく、アプリが起動していればトンネルも管理される。さらに、macOSのキーチェーンのようなOSの「ネイティブ機能との連携」も容易になり、SSHのパスワード管理などもより安全かつ便利に行えるようになった。

しかしGUI版には、CLI版にはなかったいくつかの大きなコストが伴った。最も顕著なのは「配布の複雑さ」である。GUIアプリをmacOSやWindowsで安全に配布するためには、開発者の身元を証明する「コード署名」や、Appleによるセキュリティチェックである「公証」といった、複雑で時間のかかる手続きが必要になる。これらを怠ると、ユーザーは未署名のアプリに対する警告（macOSのGatekeeperやWindowsのSmartScreen）に直面し、インストールが躊躇される可能性がある。また、「ビルドの複雑さ」も増加する。TauriはElectronよりも軽量だが、それでもWeb技術とRustを組み合わせるため、設定ファイルや、RustとJavaScript間のデータ通信（プロセス間通信、IPC）のデバッグなど、CLI版にはない複雑さが生じる。さらに、「クロスプラットフォームでのトレイアイコン挙動の不統一」も課題であった。Tauriはクロスプラットフォーム対応を謳っているが、Linuxの場合、利用しているデスクトップ環境によってトレイアイコンの表示がうまく機能しないケースがあるなど、完全に統一されたユーザー体験を提供するのは難しい側面があった。

結局、これらの比較から見えてくるのは、CLI版とGUI版の間の「根本的なトレードオフ」である。CLI版は「開発からリリースまでの時間」において優れており、迅速にツールを作成し、配布できる。一方、GUI版は「ユーザーが実際にツールを使う際の利便性」において優れており、特に技術に詳しくないユーザーでも直感的に操作できる。

最終的な解決策として、開発者はどちらか一方を選ぶのではなく、両方の良い点を組み合わせるアプローチを選択した。つまり、共通のSSHトンネル管理ロジックを持つ「コア部分」を開発し、その上にCLI版とGUI版という二つの「インターフェース」を構築したのである。CLI版は自動化やスクリプト連携に便利な「信頼できる情報源」として機能し、GUI版は視覚的な状態表示や直感的な操作を求めるユーザーのための「オプションのシェル」として提供される。これは、DockerがコマンドラインツールとDocker DesktopというGUIツールを両方提供しているのと同様の考え方であり、多様なユーザーのニーズに応えるための現実的なアプローチと言える。このプロジェクトは、ツールの目的やターゲットユーザーに応じて、開発における優先順位やコストのバランスをどのように取るべきかを示唆している。