10 ポイント 投稿者 GN⁺ 2026-04-24 | 1件のコメント | WhatsAppで共有
  • 同じウィンドウ内で 複数の agent スレッド を同時に実行して調整できるようになり、新しい Threads Sidebar で各スレッドのフォルダー・リポジトリへのアクセス範囲を制御し、実行状態を一か所で確認できるようになった
  • スレッドごとに 異なる agent を選んで組み合わせることができ、1つのスレッドが複数のプロジェクトやリポジトリをまたいで読み書きでき、必要に応じて worktree 分離 もスレッド単位で適用できるようになった
  • デフォルトのレイアウトも Threads Sidebar 中心 に再配置され、Threads と Agent Panel は左側、Project Panel と Git Panel は右側に移動し、既存ユーザーはこのレイアウトを opt-in で利用できる
  • AI に完全に任せる、あるいは完全に排除するという両極端よりも、コードに直接関与する作業スタイル と AI ツールを組み合わせて、信頼できて設計の良いシステム を作ることに重点を置いている
  • 最新の Zed リリースですぐに利用でき、120 fps 環境、agent を選べる構成、オープンソース公開 とともに、大規模な agent 作業を1つのウィンドウで扱う流れを強化している

並列エージェント機能

  • Zed は同じウィンドウ内で 複数の agent を並列実行し、調整できるようになった
    • Parallel Agents 機能により、複数のスレッドを同時に運用できる
    • 新しい Threads Sidebar で、各スレッドがアクセスするフォルダーやリポジトリを正確に制御できる
    • 実行中のスレッドを一か所で監視できる
  • この機能は Zed の 120 fps 環境で動作し、使いたい agent を選択でき、全体が オープンソース として公開されている

多くのスレッド、1つのウィンドウ

  • Threads Sidebar はすべてのスレッドをプロジェクトごとにまとめて表示し、複数の agent 作業を同時に扱いやすくする
    • スレッドごとに異なる agent を組み合わせて使える
    • choose your agent 方式で、スレッド単位の選択が可能
  • 複数のプロジェクトをまたいで作業でき、1つの agent スレッドが複数のリポジトリにまたがって読み書きを行える
  • 必要なときは worktree 分離 を適用でき、適用するかどうかもスレッドごとに決められる
  • Sidebar からスレッドの停止、アーカイブ、新しいスレッドの開始といった共通操作をすぐに実行できる
  • 複数のプロジェクトで複数の agent が同時に動く複雑な流れでも、Sidebar によって作業を整理しやすい状態を保てる

新しいデフォルトレイアウト

  • プロジェクト探索の中心が Threads Sidebar に変わったことで、パネル配置も新しく調整された
    • Threads はデフォルトで左側にドッキングされ、Agent Panel の隣に配置される
    • Project Panel と Git Panel は右側に移動する
  • このレイアウトは agentic work により適するよう設計されており、スレッドを切り替えている間も agent スレッドを前面に置ける
  • 別の配置を望む場合は、下部バーのパネルアイコンを右クリックしてドッキング位置を変更でき、Settings Editor でも調整できる
  • 既存ユーザーはこの新しいレイアウトを opt-in で利用できる
  • 従来の配置に慣れていても、元に戻す前にまず新しいレイアウトを試してみると、より自然に感じられるかもしれない

Agent と Editor の結合

  • AI 活用の仕方は極端に振れがちだが、AI を使いながらもコードに直接関与するやり方 のほうが、高品質なソフトウェア制作により適している
  • ソフトウェアエンジニアの貢献は、生成されたコード行数ではなく、信頼でき、設計が良く、変更しやすいシステム によって測られるべきだ
  • 2025年に紹介された agentic engineering は、人間の craftsmanship と AI ツールを組み合わせて、より良いソフトウェアを作る営みとして位置づけられている
  • Zed の並列 agent はこの原則を中心に設計されており、大規模な agent 作業体験 をより良くすることに重点を置いている
  • システム上で数百のスレッドを走らせて数日間テストし、開発者が見落としかねない荒い部分まで磨き込むために、何度も UX の反復と長い社内議論を重ねた
  • 開発にはより多くの時間がかかり、過程も容易ではなかったが、その結果、より難しい作業まで agent で扱いながらも craft を犠牲にしない形にした

はじめる

  • Parallel Agents は最新の Zed リリースで利用できる
  • Threads Sidebar は左下のアイコンから開ける
  • キーバインドでも開くことができ、macOS では option-cmd-j、Linux と Windows では ctrl-option-j を使う

1件のコメント

 
GN⁺ 2026-04-24
Hacker Newsのコメント
  • このワークフローは使えば使うほど気に入っている。本当のゲームチェンジャーは、(a) worktreeごとに並列スレッドを回せることと、(b) VMを立ち上げるように扱えるだけのライフサイクルフックが十分にあることだ
    自分の場合、worktreeを作るとローカルのconfigファイルをコピーし、Postgresがdev/test DBを複製して分離されたテストをできるようにしてくれる。worktreeを閉じるとそのDBも一緒に削除する
    今のところConductorが一番良かったが、会社ではCopilotしか使えず、バックエンドもClaude/Codexに固定されているので使えない。Arborは似ているが開発があまり活発ではなく荒い部分が多いし、Opencode GUIにはcreate hookはあってもteardownがない
    Zedがこの部分までつなぎ込みつつ、優れたエディタとしてのアイデンティティを保てるなら、確実に流れを変えられると思う

    • うれしい。Conductorを作った者だけど、こういうユースケースは本当に助かる
      さらに多くのエージェントをつなぐ作業を進めていて、CopilotとOpenCode harnessのサポート要望が特に多い
      最近は回避策も作った。Settings → Experimental → Big Terminal Modeを有効にすると中央パネルに新しいターミナルを作れて(⌘⇧T)、CopilotやOpenCodeなど好きなエージェントを使える。まだ通知などは不足していて完成された体験ではないが、正式なUIが出るまでは好きなharnessを使えるようにしている
      フィードバックはいつでも charlie@conductor.build に送ってほしい
    • 何か誤解していなければ、これは外部ツールなしでも補助シェルスクリプトをいくつか書けば十分作れそうに見える
      新しいgit worktreeを作り、ローカルの.envやほかのconfigファイルをコピーしてから、worktreeごとに衝突しないポートと変数を埋め込めばよい。localhostの衝突回避用で、Dockerでも解決できる
      mainにマージした後でworktreeを片付けるteardownスクリプトも一緒に置けばいいし、自動テスト用にはChrome debug portと一時的なuser data dirもworktreeごとに変えている
      なので、なぜわざわざ別のライブラリやツールが必要なのかはよくわからない
    • 特定のエージェントに縛られないJJ workspacesベースのマルチエージェントワークフローを自作した。CodexでもClaudeでも何でも動かせる
      https://www.visualjj.com/learn/parallel-ai-agents
    • VSCodeでは同じ用途で https://github.com/jackiotyu/git-worktree-manager を使っている
      この拡張にはbefore create / before destroy hookがあって、やりたい処理を何でも入れられる。自分のところではmain checkoutのworkspaceファイルをシンボリックリンクし、パッケージをインストールし、いくつかのファイルもコピーするようにしてある。かなり便利だ
    • Ouijitも見る価値がある。自分は仕事でよく使っていて、欲しい環境そのものに焦点を当て、その中でどんなツールでも使えるシェルを提供してくれる
      必要ならworktreeごとのVM分離もできる
      https://github.com/ouijit/ouijit
  • もう皆が並列エージェントとworktreeの方向へ向かっているのは明らかだが、Zedがこれを出したのは意外だった。もともとはエディタ中心で、AIは徹底してオプションという色が強かったからだ
    Zedの強みは、エージェントを問わないこと、リポジトリごとにworktreeを自動作成して1つのエージェントで複数リポジトリを扱えること、そしてCLIを包んだだけではなく独自のエージェントUIの品質が高いことだ。自分の知る限り、この組み合わせを全部備えた最初のメジャーツールだと思う

    • その通りではあるが、ClaudeのMCP integrationのような機能はかなり欠けている
      これをlogfireにつないでテレメトリを見ているが、最適化やバグ診断のときの体感差はかなり大きい。pluginsやskillsもまだない
      それでもproviderを簡単に差し替えられるのは良い
  • 新しいデフォルトレイアウトは、自分が望む方向と正反対だ
    自分としてはproject tree | text editor | agent view | threadsの順であるべきだ
    たいていのノートPCではパネルは2枚程度しかまともに見えず、4パネルのワークフローを強調するのではなく、パネル管理とビュー切り替えを簡単にする方向にもっと注力すべきだ。ウルトラワイドでないなら、Agentsはむしろ別ウィンドウの方がよい
    Zedはかなり使っていて設定で変えられる細かな部分ではあるが、かなり象徴的な設計判断に感じられて気になる。このまま編集そのものは重要度が低いと判断して、VI mode対応まで後回しにされるのではと心配になる

    • 自分もまず最初に全部の位置を元に戻した。押し付けられた自動レイアウト変更が本当に嫌だった
      changelogを見ても、最近はエージェント側にほとんどの労力が注がれているようで心配だ。自分がZedを好きなのは、良いエディタでありつつエージェントを少しわかっている程度だからであって、どんどん深くエージェント管理中心にピボットしてほしいわけではない
    • VI対応を外されたら、コントリビューターとしてもユーザーとしてもすぐ離れる。それがそもそもZedを使い始めた理由だった
      ただ、今すぐなくすとは思わない
    • 編集が重要でないと判断してVI対応まで切るだろうと見るのは、あまりに飛躍しすぎ
  • 自分は意図的に並列エージェントを避ける方だ。認知負債が大きすぎるし、作業の途中で構造的に筋の通る方向へエージェントを継続的に舵取りしなければならないことが多いからだ

    • 同意する。単純な作業には向いているが、そういう作業は順番にやってももともと速い
      複雑な作業ではたいていthinking出力を開いて途中で止めたりガイドを入れたりする必要がある。それをしないと成果物がひどいことが多く、直すのも大変だが、並列プロセスまで一緒に見ているとさらに難しくなる
    • 自分も同じだ。レビュー負荷も大きくなるし、コードレビューまで必要ならマルチタスクは生産性をほぼ全部殺してしまう
      最近は一度に1つの変更だけ処理し、完全に自信を持ってマージできるまでその流れを維持している
    • 完全に同意する。エージェントをたくさん立ち上げるほどvibe codingに流れ、guide codingは減っていく
      ある瞬間、頭の中でそのままコミットして進めようという信号が出るが、その誘惑を無理やり抑えている
  • デフォルトレイアウトがコードとファイルツリーを押しのけてAIツールの場所を作るのはあまり好きではない
    Zedは本当に好きで毎日使っているが、最初にインストールしたときにこのレイアウトを見ていたら、真剣には検討しなかったと思う
    新規ユーザーの一部は確実に遠ざけると思う

    • むしろ失うより多くのユーザーを引きつける気がする
      似たことをする他のツールはたいてい重くて、バグも多く、Electronベースだからだ
    • 幸い変えるのはとても簡単だ。ただ、新規ユーザーには少し直感的ではない
      下部バーの小さなパネルアイコンを右クリックしてドッキング位置を選べばよく、左クリックはパネル表示のトグルだ
    • 今ではエディタに4Kモニターがあると良い、というレベルではなく、ほぼ必須条件になりつつある
      今でもagent、editor、files/gitのようなものを同時に出しているのに、そこへ4枚目のパネルまで追加すると低解像度では窮屈すぎる。自分は4Kモニターを持っているが、もともと片側にエディタ、片側にブラウザのような別ウィンドウを置いて使っていたので、エディタをフルスクリーンで使う流れは今でも少し引っかかる
      もちろんこれはデフォルトレイアウトにすぎず、Zedにもおそらく変える方法はあるはずだ。JetBrains IDEのように左上/左下/右下/右上という形でパネルを配置し、一括で隠したり表示したりできるなら、たとえばファイルは左上、エージェントは左下に置いて中央は引き続きエディタ中心に保てる
    • むしろより多くのユーザーを呼び込むかもしれない。自分はコードを見たくない
      複数のプロジェクトを1か所に詰め込み、延々とコンテキストスイッチしやすいcodexスタイルのアプリの方が好みだ
    • 自分も最初はそう感じたが、実際の変更は主に各パネルを左/右どちらにドックするかを変え、AIパネルを少し調整した程度に見える
      macOSでは今でも ⌘B が左dockのトグル、⌘R が右dockのトグルだ
      新しいレイアウトを有効にすると、もともと左にあったパネルが右へ移るような形なので、従来型のコーディング用途でも一度試してみようと思っている。設定画面で各パネルのドッキング位置は変更できる
  • 自分にとって並列エージェントは標準ではなく、むしろ例外に近い。もしかすると自分の方に問題があるのかもしれないが、そうした例外的な状況でもターミナルをいくつか余分に開けば十分だと感じる
    これが本当に主要なワークフローになるべきかはよくわからない。自分の頭は1つの問題を深く掘る方が向いている

    • 自分もまったく同じタイプだが、今回のアップデートはかなり楽しみだ
      並列実行そのものよりも、スレッド間を簡単に行き来できることの方が重要だ。メインの編集コンテキストを乱さずに、隣のスレッドで雑多な調査作業を掘り下げられるようになる
    • 以前はほとんど使わなかったが、今は試してみたい。どんな作業でもspin up / tear downを分離して処理できるからだ
      たとえば編集に入る前に変更のたたき台を先に作るとか、レビュー前にブランチをcheckoutしてコードをセットアップするといった作業だ
  • Zedを使ってみて、十分メインエディタとして使えると感じたが、拡張不足は惜しかった。TODO highlightやTabOutのようなものや細かなQoLが足りず、行番号ジャンプもVSCodeほど簡単ではなく、別コメントで言われていたタブフィルタも惜しかった
    それにgit commit messageエディタでフォントサイズを設定できないのは奇妙だった
    最近追加されたものでは、dev container integrationは本当に良かった
    Zedを応援している

    • 参考までに、今はTODOハイライト拡張がある。今はマシンの前にいないが、名前はたしかcomments highlighterのようなものだった
    • 足りないZed拡張はzed agentsで自分で作ればいい
  • Zedのagent UIは、自分が見た中で最も混乱するUIだ。アイコンは小さく曖昧で、xを押したときに、ある時はエディタが閉じ、ある時はエージェントが閉じ、またある時はパネルが閉じるので、結果を予測しづらい
    新機能のせいでもう一度使ってみようと思ったが、この予測不能な挙動のせいで結局アンインストールした。しかも自分が契約しているopencode Goもサポートしていない

  • Warpも1週間ほど前に似たものを出していたが、自分にはZedの実装の方がより筋が通っているように見える
    久しぶりにまたZedを試してみようと思う。毎月一度くらいやってくる「今度はこのターミナル/IDEを使ってみようかな」という itch が来ているところだ

    • Warpも好きだが、どこか不透明で混乱しやすい感じがある
      まだ学習曲線をちゃんと越えられていないだけかもしれないし、単にまだアルファ段階に近くて頻繁に変わっているからかもしれない
  • Parallel agents機能はgit worktreeやローカルプロジェクト中心で設計されているように見えるが、ローカルプロジェクトモードはむしろ本質をぼかしていると感じる
    自分の日常の開発フローはすでにjj workspacesへ完全に移っているので、Zedがjjをサポートするまではこの機能を使うことはない
    しかも今回の変更でレイアウトまで予想外に崩れたのに、今は元に戻す方法もよくわからない