TL;DR
macOSに移行した後、WinSSHTermと同じくらい便利に日常のシナリオをカバーするSSHクライアントが見つかりませんでした。
絶え間ない妥協に疲れ果て、要件をまとめ、自分のクライアントを構築し、コードをオープンソースとして公開した。
コンテキスト
複数のサーバーを扱う場合、ほとんどどのSSHクライアントでも「まあまあ」使える。
毎日数十から数百のホストを扱う場合、スライド上の機能よりも、速度と予測可能性が重要になる。
どのくらい早く目的のホストを見つけるか;
接続までの操作の数;
環境構造を整理しておくのがどのくらい便利か;
アプリが1ヶ月の積極的な使用後にどのように動作するか。
Windowsでは、この点で長い間WinSSHTermに助けられていた。
macOSに移行した後、一晩で類似品を見つけられると思っていた。うまくいかなかった。
既存の解決策で何が不満だったのか
私は「理想」を探していたわけではない。仕事の妨げにならないツールを探していた。
問題はクライアントごとに繰り返されていた:
セッションに至るまでの道のりが長すぎる
主要なシナリオは迅速であるべきだが、しばしば不要なクリックに埋もれていた。大規模なホストプールの組織化が不十分
多くの環境やプロジェクトがあるとき、適切なグループ、タグ、検索がなければ、すべてが混乱に陥ります。過負荷なインターフェース
美しいパネルと「リッチなUI」は、アプリケーションを開く目的である接続と作業をしばしば損なっていました。設定の不便な移植性
保存、移植、バージョン管理が容易な透明な構成が望まれました。
数週間のテストの後、私は気づいた。ツールとの格闘に、課題解決よりも多くの時間を費やしていると。
なぜ自分で書くことにしたのか
理由は「周りの全てが悪い」からではない。
理由は、特定の日常業務に合わせた具体的な要件セットがあったからだ。
私は座って、何を必須と考えるかを形式化した：
起動と接続が最速;
名前/IP/タグでの検索;
環境やプロジェクトごとのグループ構造;
頻繁な操作のホットキー;
予測可能な設定保存;
視覚的ノイズ最小化;
多数ホスト時の安定動作。
この後、明らかになったのは、他人の妥協に際限なく適応するよりも、自分自身のツールを構築する方が簡単だということだ。
クライアントを構築する際の原則
1) Local-first
主要なシナリオは、迅速に動作し、ネットワーク依存がないこと。
ホストとセッションのデータはローカルで利用可能であり、リストを開くためにUIが「外部サービス」を待つことはない。
2) 接続への迅速化
すべての機能は、アクティブセッションへの道を加速させるかどうかという質問で評価される。
そうでなければ、バックログへ。
3) 予測可能性は「魔法」よりも重要
少し「自動的な賢さ」が少なくても、理解可能で制御可能なロジックの方が良い。
4) コンフィグを資産として
設定は次の条件を満たすべきである：
人間が読みやすいこと；
バックアップに適していること；
マシン間で移植可能;
Gitに便利。
アーキテクチャ（高レベル）
アプリケーションをいくつかの独立したレイヤーに分割しました:
UI Layer
ホスト一覧、検索、フィルター、セッションカード、クイックアクション。Session Layer
SSHセッションのライフサイクル: 起動、再接続、終了、ステータス。構成レイヤー
設定の読み取り/検証/移行（ホスト、グループ、タグ、プリセット）。ストレージレイヤー
サービスデータ用のローカルストレージ（例：最近/お気に入り/履歴）。統合レイヤー
システムSSHおよびmacOS環境との連携。
これにより、UIロジックと接続を混在させず、設定形式を変更してもすべてを壊さないようになりました。
実際に役立つデータモデル
最初は簡略化した「ホストリスト」モデルを試しました。
すぐに明らかになったのは、インフラストラクチャが成長するにつれて、適切な構造が必要になることです。
基本エンティティ：
ホスト
名前、アドレス、ポート、ユーザー、authパラメータ、メタデータ。グループ
論理グループ（例： prod、 staging、 clients/*）。タグ
横断的な切り口（k8s、 db、 critical、 legacy）。プロファイル
再利用可能な接続パラメータ。SessionPreset
セッション動作のプリセット。
まさに組み合わせ group + tags + search が実際に速度面で最大の効果をもたらしました。
最大の効果をもたらしたUXソリューション
デフォルトの検索に焦点
クライアントを開けば、すぐに入力とフィルタリングが可能。キーボードでのクイック操作
「キーボード／マウス」の切り替えが少なければ少ないほど、作業サイクルは速くなる。最近使用したホストとお気に入りホスト
頻繁に接続する相手は1アクションでアクセスできるべき。最小限のモーダルウィンドウ
モーダルは作業の流れを妨げる。やむを得ない場合にのみ使用している。安定した情報階層
同じ種類の情報は常に同じ場所にある。
セキュリティと運用
私は、よく後回しにされる基本的なことを別途組み込んだ：
プライベートキーをアプリケーション内に保存しない；
システムのSSHメカニズムを使用する；
接続先のホスト/環境を明示的に表示する；
危険なデフォルトを避ける；
診断に必要なものだけをログに記録し、機密データの漏洩を防止する。
これによりクライアントが「絶対に安全」になるわけではない（そんなことはありえない）が、「便利だがリスクがある」という典型的な間違いを排除する。
最も難しかったこと
余分な機能を削除すること
ボタンを追加するのは簡単だが、不要なものを取り除くのは難しい。シンプルさと柔軟性のバランスを保つ
「シンプルでありながら強力」をコンバインなしで実現するのは、反復的なプロセスであり、一度のデザインではない。細かい部分を使いやすく仕上げる
最も「目に見えない」もの（フォーカス、タブの順序、キーボードシナリオ）は、大きな機能よりも重要である。
最終的に得られたもの
主な変化は「もう一つのSSHクライアントが登場した」ことではない。
重要なのは、日常的な摩擦が消えたことだ：
目的のノードをより速く見つけられる；
環境を切り替える際のミスが減った；
インターフェースに気を取られない；
移行やバックアップ時に設定と格闘しなくて済む。
簡単に言えば、ツールは問題の一部ではなくなり、再び解決策の一部となった。
ロードマップ
プロジェクトの次のステップ：
大規模ホスト群向けのバルク操作の改善。
設定のインポート/エクスポートの拡張。
より柔軟なフィルターと保存されたビュー。
長期使用シナリオ（毎日数時間の作業）向けのUXの洗練。
デフォルト設定での追加セキュリティチェック。
同じような状況にある方へ
もしあなたもmacOSの既成の解決策に満足していないなら、コードではなく、日々の痛みのチェックリストから始めることをお勧めします。
要件を正直に明確にすると、さらに探すべきか、自分で書くべきかがはっきりします。
私の場合は、後者でした。