SSHは30年間にわたりリモート端末アクセスのデファクトスタンダードであり続けています。安全で枯れた技術であり、外部サーバーへの接続には最も信頼できる選択肢です。しかし、接続先がリモートサーバーではなく「手元のMac」である場合、別の選択肢を知っておく大きな価値があります。
それが、ブラウザのビデオ通話などで使われるWebRTCです。WebRTCの接続アーキテクチャは、特定の環境下でターミナルを操作する用途に驚くほど適しています。両プロトコルの動作原理、違い、使い分けのポイントを解説します。
SSHの仕組み
SSH（Secure Shell）はTCP上でクライアントとサーバー（sshd）の間に暗号化された安全な通信チャネルを構築します。通常は公開鍵暗号方式で相互認証を行い、共通鍵（AESやChaCha20）を用いてセッション全体を暗号化します。
SSHは「サーバー側が安定的で外部から直接到達可能なアドレスを持っている」ことを前提としたデータセンター向けモデルです。そのため、固定IPを持つLinuxサーバーへの接続には完璧に機能しますが、家庭用ルーターのNAT背後にあるMacへの接続となると途端に脆弱になります。
SSH自体にはNAT越えの機能がありません。そのため、ルーターのポート開放（22番フォワーディング）やダイナミックDNSの設定が必須となり、セキュリティ面でのリスクと管理の手間が膨らみます。
WebRTCの仕組み
WebRTCは、双方がルーターやファイアウォールの背後（プライベートIP空間）にいても、事前のネットワーク設定なしでブラウザ同士をP2Pで直接接続するために設計されました。
その中核となる技術がICE（Interactive Connectivity Establishment）です:
- 両デバイスが自身の接続候補アドレス（ローカルIP、STUNで検出したパブリックIP、TURNリレー）を収集します。
- シグナリングサーバーを介して候補アドレス情報を交換します（通信内容自体はサーバーを通りません）。
- 最も通信条件の良い経路で直接P2P接続を確立します。ファイアウォールに阻まれた場合のみTURNサーバー経由のリレーに切り替わります。
接続確立後はDTLS-SRTPによって完全暗号化されます。WebRTCは主にUDP上で動作するため、映像だけでなくターミナルの文字データも同様に極めて低い遅延で転送できます。
主な違いの比較
NAT越えの自動化
SSHは単体ではNATを越えられず、ポート開放やVPNが必要です。WebRTCはプロトコル自体にSTUN/TURN/ICEが組み込まれており、ルーター設定なしで自動的に経路を拓きます。
トランスポート層（TCP vs UDP）
SSHはパケットの完全な順序配送を保証するTCPを使用します。パケットロスが起きると再送を待つため一時的なラグが発生します。WebRTCはUDPベースのため、電波の弱い環境でもパケット待ちのフリーズが起きにくく、より機敏に入力に追従します。
ネットワーク切り替え時の挙動
SSHはWi-Fiからモバイル回線に切り替わるとTCPセッションが切断され、再接続を余儀なくされます。WebRTCのICEエージェントはネットワーク変化を検知して自動で新経路へ切り替えるため、移動中でもセッションが維持されやすい特性があります。
SSHが勝るシーン
データセンターのLinuxサーバー、AWSやGCPなどのクラウド仮想マシン、固定IPを持つRaspberry Piなど、安定したアドレスを持つホストへ接続する場合はSSHが最適です。ProxyJumpや多重化、自動化スクリプトなど30年のエコシステムが整っています。
WebRTCが勝るシーン
自宅ルーターの配下にあるMacへiPhoneからアクセスする用途では、WebRTCが圧倒的に有利です。ポート22が塞がれたカフェや職場のWi-Fi、LTE/5Gの電波移動、ルーター設定の不可といった制約をすべて自動で解決します。
両者を組み合わせた賢い運用
最も実用的なワークフローは「iPhoneからMacへはWebRTC（Macky）で繋がり、Macから本番サーバーへは既存の鍵でSSH接続する」という形態です:
ssh deploy@production.example.comスマホに秘密鍵を保存することなく、WebRTCの手軽さとSSHのインフラ資産を両立できます。