ZedはVisual Studio Codeの代替になるか？AI時代のRust製エディタを現実目線で整理

Visual Studio Codeは便利です。便利なのですが、拡張機能を積みすぎると重くなり、設定は増え、気づけば「エディタを快適にするためにエディタを整備する」という、なかなか人類らしい本末転倒が発生します。

そこで候補に上がるのがZedです。Rustで作られた高速・軽量志向のコードエディタで、共同編集やAI機能も最初から強く意識されています。ただし、VS Codeを完全に置き換える万能エディタと見ると危険です。拡張機能の数、企業標準ツール、Dev Containers、Notebook、WordPress制作まわりの細かい支援など、まだVS Codeを残した方がよい場面もあります。

この記事では、2026年6月2日時点の公式情報を前提に、Zedの基本、インストール、VS Codeからの移行、AI機能、セキュリティ、Web制作・WordPress用途での実用度を整理します。Zedを過剰に持ち上げず、「日常編集用として使えるのか」「VS Codeと併用する価値があるのか」を判断できるようにまとめます。

>>>Amazonのお得な最新の情報はここ

サーバー管理者歴17年の筆者が選んだレンタルサーバーはここ

Zedとは何か：VS Codeに疲れた人が見るべきRust製エディタ

Zedは、高速性・共同編集・AI連携を重視したコードエディタです。公式には「AtomとTree-sitterの開発者による高性能なマルチプレイヤーコードエディタ」と説明されており、現在はmacOS、Linux、Windows向けに提供されています。VS Codeのように拡張機能で何でも足していく思想というより、軽快なネイティブ体験、共同編集、AI支援をエディタ本体の中心に置く設計です。(github.com)

Zedは単なるVS Code代替ではなく、Rust製の高速コードエディタ

Zedの大きな特徴は、Rustで作られたネイティブ志向のエディタである点です。公式サイトでも、Rustでゼロから書かれ、複数CPUコアとGPUを効率よく使うことを特徴として説明しています。(zed.dev)

VS CodeはElectronベースのため、拡張性やクロスプラットフォーム対応では非常に強い一方、拡張機能を増やすほど起動や操作が重くなりやすい傾向があります。もちろんPC性能や設定次第なので「VS Codeは必ず重い」とまでは言えません。ですが、拡張機能・設定・ワークスペース・AI補助を積み上げた結果、編集画面より周辺機能の存在感が大きくなることはあります。人間はなぜテキストを書くために小さな宇宙船を起動するのでしょうか。

Zedはこの逆を狙っています。まず編集体験を軽くし、その上でターミナル、LSP、共同編集、AI支援を統合する方向です。LSPはLanguage Server Protocolのことで、補完、定義ジャンプ、診断、リファクタリングなどをエディタと言語サーバーの間でやり取りする仕組みです。

AtomとTree-sitterの流れを汲む「マルチプレイヤーエディタ」

Zedは、AtomやTree-sitterの流れを汲むエディタです。Tree-sitterはコードを高速に構文解析する仕組みで、シンタックスハイライトやアウトライン表示などに関わります。Zedの公式ドキュメントでも、言語対応はTree-sitterによる構文解析とLSPによる補完・診断・定義ジャンプを組み合わせる形で説明されています。(zed.dev)

また、Zedは「マルチプレイヤーエディタ」と呼ばれることがあります。これは複数人で同じコードベースを見たり、編集したり、会話しながら作業する共同編集機能を重視しているためです。VS CodeでもLive Shareなどで共同編集は可能ですが、Zedでは共同編集が拡張機能ではなく中核機能として扱われています。(zed.dev)

一人で静かにコードを書きたい人には過剰に見えるかもしれません。ただ、ペアプロ、レビュー、教育、AIエージェントとの共同作業まで考えると、「人間だけがコードを書く前提」のエディタではなくなっている点は重要です。

2026年時点ではAI・共同編集・マルチOS対応まで進んでいる

2026年時点のZedは、単なる軽量エディタではありません。macOS、Linux、Windowsに対応し、SSHによるリモート開発、Dev Containers、AI Agent Panel、Inline Assistant、Edit Prediction、MCP連携などを備えています。リモート開発ではローカル側でUIを動かし、ソースコード・言語サーバー・ターミナル・タスクをリモート側で動かす構成です。(zed.dev)

ただし、「機能がある」と「VS Code並みに枯れている」は別です。Dev Containersは対応していますが、公式ドキュメント上でも開発中の機能とされ、ポートフォワーディングや拡張機能の扱いには制限があります。(zed.dev)

つまり、Zedはすでに実用段階に入っていますが、あらゆる開発現場でVS Codeを丸ごと置き換える存在ではありません。軽快な日常編集、Markdown、Web制作、CLI中心の作業、AIを使ったコード修正にはかなり向きます。一方で、企業標準の拡張機能や複雑なリモート環境に依存している場合は、まだVS Codeを残す判断が現実的です。

インストールと初回セットアップ：まず軽快さを体験する

Zedは、まず試して体感するタイプのエディタです。記事を10本読んで「なるほど高速らしい」と納得するより、実際にプロジェクトを開いて、ファイル検索、Command Palette、ターミナル、設定画面を触った方が早いです。エディタ比較で一番信用できるのは、だいたい自分の指です。困ったことに。

macOS・Linux・Windowsでの導入方法

Zedは公式ダウンロードページからインストールできます。macOSではHomebrewで brew install --cask zed、Windowsでは winget install -e --id ZedIndustries.Zed、Linuxでは公式インストールスクリプト curl -f https://zed.dev/install.sh | sh が案内されています。(zed.dev)

対応環境も確認しておきます。WindowsはWindows 11 version 22H2以降、またはWindows 10 version 1903以降が対象です。Linuxではx86_64とAArch64に対応し、Vulkan 1.3ドライバなどが必要です。macOSもIntelとApple Siliconに対応していますが、古いmacOSでは一部機能が制限されます。(zed.dev)

特にLinux環境ではGPU・Vulkanまわりで相性が出る可能性があります。ZedはGPU活用を前提にした設計なので、「軽量エディタだから古い環境でも何でも動く」と考えるのは雑です。軽量と無条件対応は別物です。

最初に見るべきCommand Palette、Settings、CLI

初回起動後に見るべき場所は、Command Palette、Settings、CLIです。Command Paletteは Cmd+Shift+P または Ctrl+Shift+P で開き、設定変更、コマンド実行、拡張機能、AI関連操作などの入口になります。

Settingsは通常の設定画面に加えて、JSONで直接編集できます。VS Codeに慣れている人なら、ここは比較的すぐ理解できます。ただし、設定項目名や構造はVS Codeとは違います。VS Codeの設定をそのまま貼り付けて「動かない」と言うのは、電卓に味噌汁を注いで故障扱いするようなものです。

CLIも便利です。ZedのCLIは、ターミナルからファイルやディレクトリを開くために使えます。macOSではCommand PaletteからCLIバイナリをインストールでき、Linuxではパッケージに含まれ、WindowsではZedのインストールディレクトリをPATHに追加する形が案内されています。(zed.dev)

zed .
zed index.html
zed ~/projects/my-site

このあたりまで触れば、Zedの軽快さと操作感はだいたい見えます。最初からAIやMCPまで設定しようとすると、エディタを試す前に設定の森で遭難します。

VS Codeキーマップと必要最低限の拡張から始める

VS Codeから移る場合は、キーマップをVS Code寄せにして始めるのが無難です。ZedのVS Code移行ガイドでも、オンボーディング時にVS Code keymapを選ぶと多くのショートカットが馴染みやすくなると説明されています。(zed.dev)

最初に入れる拡張は、必要最低限で十分です。Zedの拡張機能は、言語、テーマ、デバッガー、スニペット、MCPサーバーなどを提供できます。(zed.dev) ただし、VS Code Marketplaceのように大量の拡張で環境を作り込むエディタではありません。

Web制作なら、まず以下の確認で十分です。

• HTML、CSS、JavaScript、TypeScriptの補完と整形
• PHPを使う場合はPHP本体とPHP拡張
• PrettierやESLintなど外部ツールとの連携
• Markdown編集
• Git表示
• ターミナル操作
• SSHやDev Containersが必要か

WordPress制作では、PHP、JavaScript、CSS、SCSS、HTML、JSON、YAML、Markdownあたりが中心になります。ZedのPHP拡張はPHPがPATHにあることを前提にし、標準ではPhpactorを使う形が説明されています。Intelephenseなど別のPHP language serverも設定可能です。(zed.dev)

VS Codeから移行するときにできること・できないこと

Zedへの移行は、「完全移行」より「併用」から考えた方が失敗しにくいです。VS Codeは拡張機能の量、企業導入、チュートリアルの多さ、周辺ツールの対応で圧倒的です。Zedは軽快さと設計の新しさで魅力がありますが、VS Code互換エディタではありません。

VS Code設定はインポートできるが、拡張機能はそのまま移らない

ZedにはVS Code設定のインポート機能があります。フォント、タブ幅、ワードラップ、カーソル表示、ファイル関連、ターミナル関連、Git関連、Telemetry設定、AIやMCP関連の一部など、コアな設定をZed側の設定に変換できます。(zed.dev)

ただし、ZedはVS Codeの拡張機能やキーバインドをそのままインポートしません。公式ドキュメントでも、設定インポートはコアな編集体験を近づけるものであり、拡張機能とキーバインドは対象外とされています。(zed.dev)

ここは非常に重要です。VS Codeで以下のような拡張に強く依存している場合、Zedに移った瞬間に同じ作業ができるとは限りません。

• 特定フレームワーク専用の拡張
• CMSやWordPress専用の補助拡張
• Docker、Kubernetes、クラウド系拡張
• Notebook系の作業
• テストランナー統合
• 社内専用拡張
• 複雑なデバッグ設定

Zedの拡張カタログは成長中ですが、VS Codeの拡張機能数とは比較になりません。これは弱点である一方、拡張機能を増やしすぎて環境が重くなる問題から距離を取れる、という見方もできます。便利さと混沌は、だいたい同じ箱に入っています。

Dev Containers、Notebook、企業標準拡張ではVS Codeが残りやすい

Dev Containersは、Zedでも対応しています。.devcontainer/devcontainer.json があるプロジェクトをコンテナ内で開くことができ、タスク、ターミナル、言語サーバーがコンテナ環境で動作します。(zed.dev)

ただし、制限もあります。公式ドキュメントでは、ZedのDev Containers機能はまだ開発中であり、ホスト側の拡張機能がそのまま使われること、forwardPorts など高度なポートフォワーディングが未実装であること、devcontainer.json の変更後に自動リビルドやリロードが行われないことが示されています。(zed.dev)

このため、Dev Containersを本格運用しているチームでは、VS Codeを完全に外すのはまだ慎重に見た方がよいです。Notebook、AzureやAWS系の拡張、Remote Containers前提の社内標準などがある場合も同じです。

企業利用では「自分が快適か」だけでなく、監査、サポート、標準手順、教育コスト、セキュリティポリシーも絡みます。個人の快適さだけで会社の開発基盤を変えると、あとで会議という名の精神修行が始まります。

Web制作・Markdown・CLI中心の作業ではZedが刺さりやすい

一方で、Web制作やMarkdown中心の作業では、Zedはかなり使いやすい候補になります。HTML、CSS、JavaScript、TypeScript、PHP、Markdown、JSONなどを開き、ターミナルでビルドやGit操作を行う流れなら、VS Codeの巨大な拡張環境がなくても成立しやすいからです。

WordPress制作でも、テーマ編集、プラグインの軽い修正、CSS調整、テンプレート確認、wp-content/themes 配下の編集、Markdownでの記事下書きなどはZed向きです。PHP補完を強めたい場合は、PhpactorやIntelephenseなどのlanguage server設定を確認する必要があります。(zed.dev)

ただし、WordPress専用のスニペット、管理画面連携、FTP/SFTP拡張、DB操作、ローカル開発環境のGUI操作までVS Code拡張に頼っている場合は、Zedだけでは不足する可能性があります。

現実的には、次のような使い分けが自然です。

ZedのAI機能と外部エージェント連携の実力

Zedは、単なる「軽いエディタ」ではなく、AI時代の開発環境として作られています。Agent Panel、Inline Assistant、Edit Prediction、外部エージェント、MCPなどが統合されており、AIにコードを読ませ、編集させ、場合によってはツールを実行させる設計です。ただし、便利さが増えるほど、権限と外部送信の理解も必要になります。魔法の杖はだいたい利用規約つきです。

Agent Panel、Inline Assistant、Edit Predictionの位置づけ

ZedのAgent Panelは、AIエージェントと対話する中心機能です。公式ドキュメントでは、コード生成、リファクタリング、デバッグ、ドキュメント作成、一般的な質問に使える場所として説明されています。エージェントはプロジェクト内のコードを読み、書き、場合によっては実行できます。(zed.dev)

Inline Assistantは、選択範囲に対してAIによる変換や編集を行う機能です。たとえば、関数の整理、コメント追加、冗長なコードの短縮、命名の修正など、エディタ内で小さな編集を依頼する使い方に向きます。(zed.dev)

Edit Predictionは、AIによるコード補完機能です。公式ドキュメントでは、入力ごとに補完プロバイダーへリクエストを送り、単一行または複数行の提案を返す仕組みとして説明されています。デフォルトはZedが開発するZetaで、GitHub Copilot、Mercury Coder、Codestralなども利用できるとされています。(zed.dev)

この3つは役割が違います。

AI機能を全部オンにすれば賢くなる、という話ではありません。補完がうるさい場合、外部送信が気になる場合、社内コードを扱う場合は、必要な機能だけ使う方が安全です。

Claude、Gemini、Codex、GitHub Copilotなどとの連携

Zedは、Zedホストのモデル、自分のAPIキー、外部エージェントを使い分けられます。公式ドキュメントでは、Zedのホストモデル、ユーザー自身のAPIキー、Claude Agentなどの外部エージェントを設定できると説明されています。AIを完全に無効化する disable_ai 設定も用意されています。(zed.dev)

外部エージェント連携では、Gemini CLI、Claude Agent、Codex、GitHub Copilotなどが扱われています。ZedはAgent Client Protocol、略してACPを使い、外部エージェントと通信します。Gemini CLIやClaude AgentはZedのAgent Panelから起動でき、認証や課金はそれぞれのサービス側で扱われます。(zed.dev)

ここで重要なのは、Zedがすべてを一元管理するわけではない点です。外部エージェントを使う場合、そのエージェントの設定、認証、課金、データ利用条件が別に存在します。Zedの画面の中で動いているからといって、Zedのプライバシー条件だけ見て安心するのは危険です。便利な統合UIは、責任境界まで統合してくれるわけではありません。

MCPや外部エージェントは便利だが、設定と権限の理解が前提

MCPはModel Context Protocolの略で、AIアプリケーションが外部ツールやデータソースへ接続するための標準的な仕組みです。ZedはMCPのToolsとPromptsに対応し、MCPサーバーを拡張機能またはカスタム設定として追加できます。(zed.dev)

たとえば、GitHub、Figma、検索、ドキュメント参照、社内ツールなどをMCP経由でAIに使わせる構成が考えられます。うまく使えば、エディタ内で「コードを読んで、Issueを確認して、修正案を出して」といった流れを作れます。

ただし、MCPは権限管理が非常に重要です。ZedのAgent Panelでは、ツール実行について確認、許可、拒否を設定できます。デフォルトでは確認が入る設計になっており、MCPツールごとに権限を細かく設定することもできます。(zed.dev)

特に以下のような操作は慎重に扱うべきです。

• ファイル作成・編集・削除
• ターミナル実行
• GitHub IssueやPull Request操作
• 外部APIへの送信
• 認証トークンを使うMCPサーバー
• 本番環境や顧客データに触れるツール

AIエージェントは便利ですが、プロジェクト全体を読める、ファイルを書ける、外部ツールを叩ける、という時点で普通に強い権限を持ちます。「AIだから安全」ではなく、「AIにも権限を渡している」と考える方が正確です。

セキュリティとプライバシー：Zedでも確認すべきリスク

ZedはVS Codeと違う設計思想を持っていますが、「Zedなら絶対安全」という話ではありません。VS Codeの拡張機能リスクは確かに大きな論点ですが、ZedにもTelemetry、AIデータ、外部エージェント、MCP、リモート開発、拡張機能のリスクがあります。安全神話は便利ですが、だいたい後で請求書が来ます。

VS Code拡張機能の巨大な攻撃面をどう見るか

VS Codeの強みは拡張機能です。そして、その強みはそのまま攻撃面にもなります。Microsoftの公式ドキュメントでも、VS Code拡張機能はVS Code本体と同じ権限で動き、ファイルの読み書き、ネットワークリクエスト、外部プロセスの実行、ワークスペース設定の変更などが可能だと説明されています。(code.visualstudio.com)

もちろん、Marketplace側にもマルウェアスキャン、悪意ある拡張の削除、ブロックなどの対策はあります。Microsoftは、悪意あるVS Code拡張をMarketplaceから削除し、必要に応じてVS Code側でブロックして既存インストールの削除や今後のインストール防止を行うと説明しています。(developer.microsoft.com)

しかし、拡張機能を大量に入れるほど、信頼する開発者、更新経路、依存関係、外部通信が増えます。特にAI系、クラウド系、GitHub連携、Docker連携、認証トークンを扱う拡張は、便利な分だけ影響範囲も大きくなります。

Zedは拡張機能の数がVS Codeほど多くありません。これは不便でもありますが、拡張機能を積み上げすぎるリスクを抑えやすいという意味では利点にもなります。ただし、Zedにも拡張機能はあり、MCPサーバーを拡張として提供できるため、拡張リスクがゼロになるわけではありません。(zed.dev)

ZedのWorktree Trustは何を防ぎ、何を防がないのか

ZedにはWorktree Trustという考え方があります。Zedにおけるworktreeは、Gitのworktreeだけではなく、Zedがプロジェクトとして開くディレクトリや単一ファイルのルートを指します。zed some/path で開いた場合や、ファイル・ディレクトリをドラッグした場合にも適用されます。(zed.dev)

これはVS CodeのWorkspace Trustに近い考え方です。VS CodeのWorkspace Trustは、未知のコードをRestricted Modeで開き、自動コード実行を防ぐための追加レイヤーです。Restricted Modeでは、AI agents、terminal、tasks、debugging、workspace settings、extensionsなどが無効化または制限されます。(code.visualstudio.com)

ZedのWorktree Trustも、未知のプロジェクトを開くときのリスクを減らすための仕組みです。ただし、信頼設定は万能のサンドボックスではありません。ユーザーが信頼済みにしたプロジェクトで、外部エージェントやMCP、ターミナル実行、language server、フォーマッターなどを動かすなら、それぞれの権限と動作を理解する必要があります。

特に、以下はWorktree Trustだけで片付く話ではありません。

• 悪意ある依存パッケージ
• 危険なビルドスクリプト
• 外部エージェントによるファイル編集
• MCP経由の外部API操作
• language serverやformatterの実行
• ターミナルでのコマンド実行
• .env や秘密鍵の読み取り

Worktree Trustは「知らないコードをいきなり全力で信用しない」ためのブレーキです。ブレーキがあるからといって、崖に向かってアクセルを踏んでよいわけではありません。

Telemetry、AIデータ、外部エージェント、SOC2の注意点

ZedのTelemetryは、公式ドキュメント上でクライアント側とサーバー側に分けて説明されています。クライアント側の利用指標やクラッシュレポートは設定で無効化できます。一方、AIやCollaborationなどホスト型サービスを使う場合のサーバー側Telemetryは、その機能提供に必要とされています。(zed.dev)

AIデータについては、Zedはデフォルトではプロンプトやコードコンテキストを保存せず、選択したAIプロバイダーに送信して応答生成後に破棄すると説明しています。また、AI改善のためのデータ共有はオプトインで、評価を送った場合などに会話内容が共有される仕組みです。(zed.dev)

Zed Businessでは、組織メンバーが個別にプロンプト共有や学習データ共有へオプトインできないようにする保護がデフォルトで適用されます。ただし、ZedホストのAIモデルを使う場合、推論のためにプロンプトやコードコンテキストは該当プロバイダーへ送信されます。(zed.dev)

ここで整理すると、確認すべきポイントは次の通りです。

Zedはかなり明確にプライバシー説明を出しています。そこは好印象です。ただし、説明があることと、自分のプロジェクトで安全に使えることは別です。特に顧客コード、未公開プロダクト、個人情報、APIキー、本番環境情報を扱う場合は、AI・MCP・Telemetryの設定を先に確認すべきです。

Zedは誰に向くか：強み・弱点・併用前提の結論

結論として、ZedはVS Codeに疲れた開発者やWeb制作者にとって、かなり有力な併用先です。特に「普段の編集を軽くしたい」「拡張機能を減らしたい」「AIエージェントをエディタ内で自然に使いたい」「MarkdownやWeb制作を軽快に進めたい」という人には試す価値があります。一方、VS Codeの巨大な拡張エコシステムに深く依存している人にとっては、完全移行はまだ慎重に見た方がよいです。

Zedをおすすめしやすい人

Zedをおすすめしやすいのは、まずVS Codeの重さや拡張機能疲れを感じている人です。起動、ファイル検索、タブ移動、コード編集の軽快さを重視するなら、Zedの設計思想はかなり合います。

特に相性がよいのは、以下のような人です。

• Markdown、HTML、CSS、JavaScript、TypeScriptをよく編集する
• WordPressテーマや小規模プラグインを触る
• CLI中心で作業する
• エディタに入れる拡張機能を減らしたい
• Git操作やターミナルをエディタ内で使いたい
• AI補完やAIエージェントを試したい
• VS Codeは残しつつ、軽い日常編集用エディタがほしい
• Rust製・GPU活用・ネイティブUIという設計に魅力を感じる

Web制作では、Zedを「制作ファイルを軽快に編集する場所」として使うと相性がよいです。HTML/CSS/JS、PHP、Markdown、JSON、設定ファイルなどを編集し、ビルドやGitはターミナルで行う。こういう素朴な流れでは、Zedの軽さが効きます。

WordPressでも、テーマ編集、テンプレート修正、CSS調整、ブロックテーマのJSON編集、Markdown下書きには使いやすいです。ただし、WordPress専用の高度な補完や管理画面連携まで期待すると、VS Code拡張の方が便利な場面は残ります。

慎重に見た方がいい人

慎重に見た方がいいのは、VS Codeの拡張機能を前提に仕事の流れが固まっている人です。特に、企業やチームの標準環境としてVS Codeが指定されている場合、個人判断でZedへ移ると手順書、レビュー、デバッグ、サポートでズレが出ます。

以下に当てはまる場合は、完全移行を急がない方がよいです。

• Dev Containersを高度に使っている
• Notebook作業が多い
• Docker、Kubernetes、クラウド拡張に依存している
• 社内専用VS Code拡張がある
• テスト、デバッグ、プロファイリングをVS Code拡張で統合している
• WordPress専用スニペットやSFTP拡張に依存している
• 企業のセキュリティ審査で未承認ツールを使えない
• AIやTelemetryの外部送信に厳しい制約がある

ZedにはSSHリモート開発もあり、WindowsではSSHやWSL経由のリモート開発もサポートされています。(zed.dev) ただし、リモート開発やDev Containersを中心にした複雑な現場では、VS Codeの実績と周辺情報の多さがまだ強いです。

また、ZedのAI機能を使う場合は、どのモデルを使うのか、どのプロバイダーへコードが送られるのか、外部エージェントの認証や課金がどうなるのかを確認する必要があります。AI統合が強いことは魅力ですが、セキュリティ確認を飛ばす理由にはなりません。

完全移行より、日常編集用として併用するのが現実的

現時点でのおすすめは、ZedをVS Codeの完全代替ではなく、日常編集用の併用エディタとして使うことです。

たとえば、次のような使い分けが現実的です。

Zedの魅力は、VS Codeを否定することではありません。VS Codeが便利すぎるあまり肥大化した環境に対して、「もっと軽い編集面を取り戻す」選択肢になることです。

特に、VS Codeで拡張機能を大量に入れ、AI補完、Git連携、Docker、Markdown、テーマ、Lint、Formatter、REST Client、クラウド拡張、謎の便利拡張まで抱え込んでいる人は、一度Zedを素の状態で触る価値があります。エディタは本来、設定ファイルを育てる盆栽ではなく、コードや文章を書く道具です。

Zedは、軽快さ、AI連携、共同編集、Rust製ネイティブ設計という強みを持つ一方、拡張機能の少なさ、VS Code互換ではない点、Dev Containersなど一部機能の成熟度、AI・MCP利用時の権限管理という課題もあります。

したがって結論はこうです。

Zedは、VS Codeに疲れた人が試す価値のあるエディタです。 ただし、VS Codeを今すぐ捨てる必要はありません。 まずは日常編集、Markdown、Web制作、WordPressテーマ編集、AI補助の軽い作業から併用するのが現実的です。

VS Codeをメインの総合開発環境として残し、Zedを高速な編集・AI支援・軽作業の場として使う。この距離感が、2026年時点では一番無理がありません。便利さに溺れた開発環境から少しだけ荷物を降ろす、という意味で、Zedはかなりよい逃げ道です。