SSH を超えて：AI コーディングエージェントに WebSocket が優れる理由

「Claude Code を電話から操作する」と聞くと、自然な反応は「SSH で Mac に繋げばいいのでは？」です。

もっともな疑問です。SSH は実績があり、安全で、開発者なら誰でも知っています。しかし AI コーディングエージェントは対話型シェルセッションとは根本的に異なる操作パターンを持ち、SSH で無理に合わせると体験が悪化します。

操作モデルの不一致

SSH は1995年に設計されました。人間がターミナルでコマンドを打ち、出力を読み、次のコマンドを打つ — 対話的かつ同期的なモデルです。

AI コーディングエージェントはこのモデルを逆転させます:

最後の行が問題です。Claude Code がタスクを完了したり危険な操作の承認を求めたとき、SSH ではそれを伝える手段がありません。

問題 1: プッシュ通知がない

AI コーディングエージェントで最も価値あるワークフロー:

1. タスクを送信
2. 電話をしまう
3. Claude が完了または入力を必要としたら通知を受ける
4. レビューして続行

SSH はステップ3ができません。SSH プロトコルにはモバイルデバイスへのプッシュ通知機構がありません。

WebSocket アプローチ: サーバーが Claude Code の出力と hook イベントを監視。完了や承認要求を検出すると、接続中のクライアントに構造化イベントをプッシュ。iOS アプリがネイティブプッシュ通知に変換します。

問題 2: iOS のバックグラウンド動作

iOS はフォアグラウンドにないアプリのネットワーク接続を約30秒で停止します。

• SSH: 接続が切断。再開すると「broken pipe」エラー。スクロール位置とバックグラウンド中の出力は失われる。
• Mosh: UDP のため再開は可能。ただし一時停止中の出力は見逃し、通知問題も未解決。

WebSocket アプローチ: サーバーがクライアント接続状態に関わらずターミナル出力をバッファ。アプリ復帰時に自動再接続し、多段階の状態復元（0.2秒、0.7秒、1.5秒）を実行。重要イベントはアプリ一時停止中もプッシュ通知で配信。

問題 3: セッション状態管理

SSH では複数の並列タスクの管理が手動です:

1. Mac に SSH 接続
2. tmux attach -t session-a で手動アタッチ
3. 状態確認、デタッチ、次のセッションにアタッチ

WebSocket アプローチ: サーバーがセッション管理を構造化コマンドとして公開。iOS アプリにアクティブセッションの一覧が表示され、タップで切り替え可能。

問題 4: エージェントイベントのセマンティクス

SSH は生のバイトを転送するだけで、ターミナル内で何が起きているか理解しません。Claude Code の hook システムが特定のイベントでシェルスクリプトを実行します。

SSH の制限: hook イベントを SSH セッション経由でルーティングする簡潔な方法がありません。

WebSocket アプローチ: サーバーが Claude Code の hook スクリプトから HTTP POST でイベントを受信し、パース・重複排除（3秒ウィンドウ）して、ターミナルデータと同じ WebSocket 接続で iOS アプリにプッシュ。1つの接続で複数のデータタイプを扱えます。

問題 5: 認証とアクセス制御

SSH 認証はモバイル利用には複雑です（iOS での鍵管理、sshd の設定、NAT 越えのポート転送など）。

WebSocket アプローチ: Tactic Remote は WebSocket 上の API キー認証を使用。LAN 接続では API キーはオプション、Cloudflare Tunnel では必須。Mac アプリが32文字のランダムキーを生成し QR コードで転送。sshd 設定不要。

SSH が依然として優れるケース

• 多数のサーバー管理 — SSH は標準プロトコル
• ファイル転送 — SFTP/SCP が内蔵
• Claude 以外のツール — SSH はエージェント非依存
• ポート転送 — SSH トンネルは実績あり
• コンプライアンス要件で SSH が必須

実際のアーキテクチャ

iPhone App                    Mac Server                    Claude Code
    │                             │                              │
    │  WebSocket (ws:// or wss://)│                              │
    │◄───────────────────────────►│  tmux send-keys              │
    │  • Terminal I/O             │─────────────────────────────►│
    │  • Session commands         │  tmux capture-pane           │
    │  • Event stream             │◄─────────────────────────────│
    │                             │                              │
    │  Push notification          │  HTTP POST /hook             │
    │◄────────────────────────────│◄─────────────────────────────│
    │  (via WebSocket event)      │  (Claude Code hook scripts)  │
    │                             │                              │

サーバーが電話と Claude Code の間に位置し、イベントセマンティクス、セッション管理、再接続耐性、通知ルーティングを追加します。SSH では生のターミナル接続しか得られません。

Mosh について

Mosh は UDP を使うため、ネットワーク切り替えと接続永続性が改善されます。しかし根本的な問題は未解決です:

• プッシュ通知なし
• エージェントイベント認識なし
• 構造化されたセッション管理なし
• iOS のバックグラウンド一時停止の影響（ただし復帰は速い）

結論

問題は「SSH か WebSocket か」という抽象的なプロトコル比較ではありません。「ワークフローにどの操作モデルが必要か」です。

サーバー管理と対話的コマンド実行なら、SSH が正解です。自律的に動作し、断続的に注意を要し、プッシュ通知と構造化イベント処理の恩恵を受ける AI エージェントを操作するなら、専用の WebSocket アーキテクチャが SSH では解決できない問題を解決します。