Zedでリモートフォルダを開く方法｜SSH接続の設定手順まとめ

VPSや自宅サーバーのコードを、手元のZedからそのまま開いて編集できたら、開発の往復は大きく減ります。サーバー上のファイルをvimとscpで触るたびに、補完も検索も効かず不便を感じていませんか。この記事は、AI開発環境を自分で整えたい個人開発者に向けて、Zed標準のSSHリモート機能でリモートフォルダを開く手順を3つの方法に分けて解説します。

結論を先に言うと、単発の接続はダイアログ3手順で済みますが、毎日使う接続はsettings.jsonに登録して固定するのが再接続まで含めて最短です。

接続前に確認する準備と対応環境

準備で確認するのは「Zedのバージョン」「SSHの疎通」「リモート側のOS」の3点です。

仕組みを30秒で把握する（ローカルとリモートの分担）

最初に全体像だけ押さえておくと、つながらないときの切り分けが速くなります。

ローカルのZedとリモートのサーバーで役割が分かれます

結論から言うと、Zedのリモート開発は二層構成です。手元のZedが画面を描き、サーバー側では専用プログラムが動きます。

Zed公式の「Remote Development」ドキュメントは、この分担を次のように説明しています。

ローカルマシンではZedのUIが動き、コードの構文解析や未保存の変更の保持もローカル側で行われます。

一方で言語サーバー・タスク・ターミナルは、すべてリモートサーバー側で実行されます。

つまり重い処理はサーバーに任せつつ、編集の操作感は手元のZedそのままという設計です。回線が細くても入力が引っかかりにくいのはこのためです。

必要なのはZed本体だけ、拡張機能は不要です

よくある誤解として、VS CodeのRemote-SSHのような拡張機能を探してしまう人がいますが、Zedにその手順はありません。

リモート開発はZed本体に組み込まれた標準機能で、追加インストールは一切不要です。

SSHリモートの一般提供は公式ブログによると2024年10月30日に始まりました。初回接続時にはリモート側へ専用のサーバープログラムが自動でダウンロードされ、常駐プロセスとして起動します。手動で何かを入れる必要はありません。

バージョンと対応OSを確認する

接続に失敗する原因の一定数は、バージョンと対応OSの確認漏れです。

Zed本体はv0.159以上に更新してください

最初に確認すべきは手元のZedのバージョンです。公式ドキュメントはリモート開発にv0.159以上を必須としています。

コマンドパレットで「zed: about」を実行すると現在のバージョンが表示されます。v0.159より古い場合は、自動アップデートを待つか公式サイトから入れ直してください。

2024年10月以前の解説記事には「リモート開発は招待制」と書かれたものが残っています。現在は誰でも使えるので、古い手順を参照しないよう公開日を確認してください。

リモート側にできるのはmacOSとLinuxだけです

接続する側とされる側で対応が変わります。クライアントはmacOS・Linux・Windowsのいずれでも問題ありません。

一方でリモートサーバー側は公式ドキュメントの記載どおり、macOS Catalina以降またはLinux（x86_64/arm64）に限られます。32bitのLinuxと、サーバー側としてのWindowsは2026年6月時点で未対応です。

たとえば「会社のWindowsデスクトップに自宅から接続したい」という用途には使えません。この場合はWindows側にLinuxのVMやWSL環境を用意する構成を検討してください。

SSHで入れる状態を先に作っておく

Zedは手元のsshコマンドと~/.ssh/configをそのまま使います。だからSSHの準備が先です。

まずターミナルからssh接続を通します

まずやるべきことは、Zedを開く前にターミナルで「ssh ユーザー名@ホスト名」を実行して入れることの確認です。

ここが通らなければ、鍵の配置やポート番号などZed以前の問題だと切り分けられます。逆にここが通れば、以降のトラブルはZed固有の原因に絞れます。

失敗例として多いのは、初回からZedで接続を試してしまい、SSHの認証エラーなのかZedの問題なのか判断できなくなるパターンです。順番を守るだけで原因調査の時間が大きく減ります。

~/.ssh/configに接続情報をまとめておくと後が楽です

ポイントは、接続情報をコマンドの引数ではなく~/.ssh/configに書いておくことです。Zedはこの設定ファイルを継承します。

• Host: 接続時に使う短い別名（例: vps-main）
• HostName: サーバーのIPアドレスまたはドメイン
• User / Port: ログインユーザーと接続ポート
• IdentityFile: 秘密鍵のパス

この4項目を書いておけば、Zedの接続画面では「vps-main」と打つだけで済みます。鍵のパスを毎回指定する必要もなくなります。

Windowsで使う場合の対応関係を整理する

Windows版Zedの情報は変化が速く、古い記事と現状が食い違いやすい領域です。

WindowsのZedはクライアントとしてSSH接続できます

結論から言うと、Windows版Zedの安定版からSSHでリモートフォルダを開けます。公式のWindowsドキュメントがSSHとWSLの両対応を明記しています。

パスフレーズなどの認証は専用の入力ダイアログで聞かれます。挙動はmacOS・Linux版とほぼ同じです。

ただしWindows版にはDirectX 11互換GPUが必要という動作要件があります。仮想マシン上のWindowsでは描画性能が落ちる場合がある点も押さえておいてください。

WSLの中のフォルダはSSHなしで直接開けます

意外と見落とされがちなのが、WSLの扱いです。WSL内のプロジェクトを開くのにSSHサーバーを立てる必要はありません。

ZedはWSLディストリビューションをリモート接続先として直接選択でき、Ubuntu内のフォルダをそのまま開けます。SSH接続はあくまで別マシンに対して使うものと整理してください。

リモートフォルダを開く3つの方法

開き方は「ダイアログ」「ssh://コマンド」「settings.json登録」の3通りで、初回はダイアログから試すのが確実です。

方法1：Remote Projectsダイアログから開く

初めての接続はこの方法を使ってください。画面の案内に沿って進むだけです。

Connect New Serverに接続情報を入力します

手順は5ステップです。所要時間は、初回のサーバープログラム取得を含めて2〜3分が目安です（筆者調べ・回線速度により変わります）。

1. ショートカットでRemote Projectsダイアログを開く（macOS: ctrl-cmd-shift-o ／ Windows・Linux: ctrl-alt-shift-o）
2. 「Connect New Server」を選ぶ
3. 普段のssh接続と同じ形式で入力する（例: dev@203.0.113.10 -p 2222）
4. 鍵のパスフレーズなど認証に答える
5. 接続成功後、開きたいフォルダのパスを選ぶ

~/.ssh/configにHostを登録済みなら、手順3は別名（例: vps-main）を入力するだけです。

接続後は「Open Folder」でフォルダを指定します

接続に成功すると、ダイアログに接続先サーバーの項目が追加されます。そこから「Open Folder」を選び、開きたいディレクトリを指定してください。

接続直後のどこからフォルダを開くのか迷ったという声もあります。Windows 11からFedoraへ接続した検証記事でも、接続後のUIの分かりにくさが指摘されています。

一度開いたフォルダは履歴に残ります。次回からはダイアログを開いてプロジェクト名を選ぶだけで再接続できます。

方法2：zed ssh://コマンドで一発で開く

ターミナル中心で作業する人は、URL形式で直接開くのが速いです。

URL形式はユーザー・ホスト・ポート・パスの4要素です

書式はzed ssh://ユーザー名@ホスト名:ポート/パスです。たとえばzed ssh://dev@203.0.113.10:2222/home/dev/blogのように指定します。

パスは~始まりのホーム相対でも、/始まりの絶対パスでも書けます。書式の正本は公式ドキュメントを参照してください。

毎回パスを打つ手間と打ち間違いには注意してください

この方法の弱点は入力ミスです。存在しないパスを指定すると意図しない場所を開いてしまい、ファイルが見当たらないと混乱するケースがあります。

一方でスクリプトやランチャーから起動できるのは、この方法だけの強みです。プロジェクト切り替えを自動化したい人には最有力ではないでしょうか。

手で打つのは初回だけにして、2回目以降はダイアログの履歴か、次に説明する設定ファイル登録に寄せるのが現実的です。

方法3：settings.jsonに接続先を登録して固定する

毎日つなぐサーバーがあるなら、この方法が本命です。接続情報を設定ファイルで管理できます。

ssh_connectionsにホスト・ユーザー・鍵・別名を書きます

Zedのsettings.jsonにssh_connectionsという配列を追加し、接続先を記述します。書き方は次のとおりです。

{
  "ssh_connections": [
    {
      "host": "203.0.113.10",
      "username": "dev",
      "args": ["-i", "~/.ssh/id_ed25519"],
      "nickname": "vps-main",
      "projects": [{ "paths": ["~/apps/blog"] }]
    }
  ]
}

鍵はargsに-iオプションで指定し、nicknameはダイアログでの表示名になります。利用できる項目の一覧は公式ドキュメントに掲載されています。

projectsまで書けば再接続は1選択で終わります

ここで重要なのは、projectsにフォルダのパスまで書いておくことです。ダイアログに「接続先＋フォルダ」のセットが常に表示され、選ぶだけで作業を再開できます。

毎日つなぐサーバーはssh_connectionsに登録しておくのが、再接続まで含めて最短です。

settings.jsonはdotfilesとして管理すれば、PCを買い替えても接続環境を数分で復元できます。なお、エディタごと接続するのではなくAIエージェントだけを外から操作したい場合は、Claude Code Remoteの使い方で別の構成を解説しています。

つながらない時の確認手順と応用設定

接続トラブルは「リモート側の環境」「ネットワーク経路」「Zedの制限」の順で切り分けるのが最短です。

「connecting」のまま進まない時の確認手順

SSH自体は通るのにZedだけ止まる場合、リモート側の環境不足が典型例です。

最小構成のサーバーは必須コマンド不足で止まります

意外と見落とされがちなのが、リモート側に入っている基本コマンドの不足です。最小構成のDebianやコンテナで起きやすい症状です。

WindowsクライアントからDebianサーバーへの接続が止まったZennの検証記事では、原因と解決が次のように報告されています。

サーバー側のログには「error reading message on stdin」というエラーが記録されていた。

ssh・netbase・curl・treeを導入したところ、接続が最後まで通るようになった。

同じ症状が出たら、まずリモート側でcurlとtreeの有無を確認し、無ければパッケージマネージャーで導入してください。

Zed側のログで原因を特定します

次に確認すべきはZedのログです。コマンドパレットで「zed: open log」を実行すると、接続処理のどこで止まったかが読めます。

見るポイントは3つです。ホスト名の解決に失敗しているか、認証で止まっているか、サーバープログラムのダウンロードで止まっているかを順に確認します。

ログで判断がつかない場合は、ターミナルから「ssh -v ホスト名」を実行してSSH側の詳細ログと突き合わせると、Zedの問題かSSHの問題かを確定できます。

リモートが外部に出られない環境での対処

社内サーバーなど外向き通信が制限された環境では、初回のサーバープログラム取得で失敗します。

upload_binary_over_sshでローカル経由に切り替えます

既定の動作では、リモートサーバーがzed.devから直接サーバープログラムをダウンロードします。外に出られないサーバーではここで止まります。

対処は、ssh_connectionsの該当エントリに"upload_binary_over_ssh": trueを追加することです。手元のPCでダウンロードしたバイナリを、SSH経由でサーバーへ転送する動作に変わります。

プロキシ必須の社内ネットワークや、外向き通信を絞ったVPSではこの設定を最初から入れておくとつまずきません。

手動配置はバージョンの完全一致が必要です

SSH転送も使えない環境では、サーバープログラムを手動で配置する方法が残されています。配置先は「~/.zed_server」ディレクトリです。

注意点は、ファイル名に含まれるリリースチャンネルとバージョンを、手元のZedと完全に一致させる必要があることです。1つでもずれると認識されません。

さらにZedを更新するたびにバイナリの差し替えが発生します。運用負荷が高いので、upload_binary_over_sshが使えるならそちらを優先してください。

port_forwardsでリモートの開発サーバーを手元で見る

リモートで起動したlocalhost:3000は、そのままでは手元のブラウザから見えません。

local_portとremote_portを指定するだけです

ssh_connectionsの接続エントリにport_forwardsを追加します。たとえば{"local_port": 8080, "remote_port": 3000}と書くと、手元のlocalhost:8080がリモートの3000番へ転送されます。

リモートでWebアプリの開発サーバーを動かし、手元のブラウザで表示を確認する流れがこれで完結します。設定項目の正確な仕様は公式ドキュメントで確認してください。

転送はZedの接続が生きている間だけ有効です。ブラウザで見えなくなったら、まず接続状態を確認してください。

つながらない時はバインド先と競合を確認します

転送がうまくいかない場合と、別の端末から見たい場合で対応が変わります。前者はローカル側のポートの競合を確認してください。

後者はlocal_hostに0.0.0.0を指定すると、同じLAN内の他端末（スマホの実機確認など）からもアクセスできるようになります。

知っておくべき制限と切断時の挙動

最後に、使い始めてからハマりやすい制限を2つ押さえておきます。

リモートターミナルからzedコマンドは使えません

Zed内で開いたリモートのターミナルから「zed ファイル名」で別ファイルを開く操作は、公式ドキュメントが未対応と明記しています。ファイルはエディタ側のファイルツリーから開いてください。

また10万ファイルを超える巨大ディレクトリの扱いは最適化の途上とされています。ルート（/）やホーム全体を開くと動作が重くなります。

ホームディレクトリ全体ではなく、プロジェクトのフォルダ単位で開くのが安定運用のコツです。

切断されても未保存の変更は手元に残ります

よくある誤解として、回線が切れると編集中の内容が消えると思われがちですが、未保存の変更はローカル側に保持されます。再接続すればそのまま続きから作業できます。

接続はプロジェクトごとに1本のSSH接続へ多重化されており、新しいターミナルを開くたびに再認証を求められることもありません。切断時には自動で再接続が試みられます。

補足すると、リモートのターミナルで動かしていたプロセス自体は切断で終了します。学習ジョブや長時間のビルドはtmuxなどの上で動かしておくと安全です。

導入チェックリストと公式情報の確認先

最後に、この記事の手順を1分で再確認できるチェックリストと、一次情報の確認先をまとめます。

公式情報の確認先と更新履歴

Zedはリリースの間隔が短く、仕様の追加・変更が早いエディタです。迷ったら一次情報を確認してください。

確認に使った一次情報と更新履歴

本記事の機能仕様は、次の公式情報に基づいています。仕様の最新の正解は、常に公式ドキュメントの現行版です。

• Zed公式: Remote Development（仕組み・設定項目・制限）
• Zed公式ブログ: SSH Remoting一般提供の発表（2024年10月30日）
• Zed公式: Windows版ドキュメント（SSH・WSL対応）

各ページの最終確認日は2026年6月10日です。更新履歴: 2026-06-10 初版公開。