2026.08.24 12 人が閲覧（直近 30 日） AI

Zed Deltaとは？DeltaDBによるエージェント併走の証跡設計と採用条件を解説

Zed IndustriesがDeltaをプライベートベータで公開したのは2026年8月12日です。エディタのZedとは別の単体アプリケーションで、人とエージェントが同じスレッドの中でコードを書き、その結果をレビューする場として設計された製品です。基盤にあるのはDeltaDBという記録の仕組みで、コミット間に起きた編集操作をひとつずつ拾い、それを生んだ会話と結びつけたまま保持します。この記事では、Deltaが解こうとしている課題、DeltaDBがデルタ単位で記録する構造、既存のGitとプルリクエストをどこまで残すのか、外部エージェントの接続経路、証跡と引き継ぎの設計までを実装目線で整理します。

まとめ：Zed Deltaを試す条件と、Gitの運用をそのまま残す判断の分かれ目

先に結論から示します。Deltaは「エージェントが書いたコードを、なぜそう書いたのかごとレビューしたいチーム」に効く道具です。逆に、人が主に書いていて変更の背景が課題になっていないチームでは、いま導入しても得られるものが薄くなります。判断の分かれ目は規模でも予算でもなく、レビュー時に「この修正はどの指示から出たのか」を追う作業が発生しているかどうかです。

構造面では、Deltaは既存のGitを置き換える提案ではありません。Zedの公式ブログは、GitとCIをチェックの実行と外部との接続という役割で残すと明示しました。導入判断は全社の基盤更改ではなく、一部チームでの併走から始められます。

ただし2026年8月時点ではプライベートベータで、招待が順次配られている段階です。本番の開発基盤としてレビュー工程を全面的に載せ替えるのは、まだ早いと判断しています。試すなら、実験的な機能開発1本をスレッドで進め、そこで生まれた記録が後から読み返されるかを測る範囲に絞ってください。

コミット間で失われる指示と会話をZed Deltaが拾い直す狙い

Deltaの設計意図は、製品紹介より先に課題設定を読むと掴めます。Zedがブログ記事のタイトルに置いた「Software Is Made Between Commits（ソフトウェアはコミットの間で作られる）」という一文が、そのまま出発点です。

Zed Deltaの定義と、マルチプレイヤー環境という位置づけの中身

Zedによる定義は「エージェントとコードを書き、エージェントが作ったものをレビューするためのマルチプレイヤー環境」です。ここでのマルチプレイヤーは、人間同士の同時編集だけを指していません。人とエージェントが同一のスレッドに同席し、そのスレッドの中で会話とワークツリーの両方がリアルタイムに複製される構造を指します。

スレッドという単位が中心に置かれているのが特徴です。仕様の議論、エージェントへの指示、返ってきた出力、実際のコード変更が別々の場所に散らず、ひとつのスレッドに時系列で並びます。Zedはこれを、コードとその成り立ちの文脈を保ったまま人とエージェントが協働できる状態、と説明しています。

2026年8月12日にプライベートベータが始まった提供段階の現在地

Deltaの発表は2026年8月12日、著者はZed創業者のNathan Sobo氏です。同日から最初の招待が配布され、以降数週間にわたって順次招待を広げると案内されました。基盤側のDeltaDBはそれより早く、2026年6月11日のブログ記事で公開されています。当時は「数週間後にベータ」という予告とウェイトリストの受付という段階でした。

6月に基盤の考え方を出し、8月にそれを載せたアプリケーションを出す順序です。招待を待つ側にとっては、DeltaDBの記録モデルが6月時点の記事で読めるぶん、自チームのレビュー工程がその記録モデルと噛み合うかを先に机上で判定できます。

Gitのコミット単位では残らない情報の具体例と、その影響範囲

Gitが保存するのは、コミットという時点のスナップショットです。そこに残らないものを具体的に挙げると、影響範囲が見えてきます。エージェントに与えた前提条件、途中で却下した実装案とその理由、レビュー中に口頭で決めた例外扱い、そして「この関数はこう書き換えてほしい」という指示の原文です。

エージェントが書く比率が上がるほど、この欠落が効いてきます。人が書いたコードなら書いた本人に聞けば済みますが、エージェントの出力は、指示した本人ですら数日後には前提を思い出せません。差分だけが残り、判断の根拠が残らない。Deltaが埋めようとしているのはこの隙間です。

DeltaDBがデルタ単位で記録する仕組みと、既存Gitリポジトリとの併存

DeltaDBはDeltaの内部実装であると同時に、単体で説明されている記録モデルです。Zedはこれを、会話とエージェントが編集するワークツリーを共有される成果物へ変える単一の一貫した抽象、と表現しています。

操作ベースCRDTで編集操作ごとに安定した識別子を割り当てる構造

DeltaDBが採るのは操作ベースのCRDT（Conflict-free Replicated Data Type）です。CRDTはもともと共同テキスト編集のために設計された分散データ構造で、複数の書き手が同時に同じ場所を触っても、結果が一意に収束します。Zedはこれを「衝突しない複製ワークツリー」と呼び、複数の人とエージェントが別々のマシンから同じファイルを同時に編集できる根拠に置いています。

肝は、スナップショットではなく操作を単位にしている点です。コミット時点の全体像を撮るのではなく、その間の個々の操作を記録し、ひとつずつに安定した識別子を与えます。この識別子があるため、コードが変わり続けている最中でも、進化の途中にあるあの瞬間のコードを指し示せます。

行番号ではなくデルタにアンカーする参照が、改変後も壊れにくい理由

従来のレビューツールで参照が壊れる原因は、行番号に紐づけているからです。ファイルの上部に3行足されただけで、コメントが指していた場所は別の行に移ります。DeltaDBは参照先を行番号ではなくデルタそのものに固定します。

結果として、コメントはコードが変化していく過程を追いかけたまま残ります。Zedはこれを、過去の会話と現在のコード状態の間を行き来できる状態、と説明しており、Delta側の機能としても会話をまたいでコードの変化に追随するコメントとして実装されています。レビュー指摘が後続のリファクタリングで迷子になる問題への、構造からの回答です。

既存のGitリポジトリとCIをそのまま残したまま導入できる境界線

導入判断で最初に確認したいのが、この併存の条件です。Zedは、DeltaDBは既に持っているgitリポジトリと動作すること、これまで通りコミットしてプッシュでき、Deltaを一度も開かないチームメイトには普通のgitリポジトリに見えることを明記しています。

この設計は評価の敷居を大きく下げます。リポジトリの移行もCIの組み替えも不要で、Deltaを使う人だけが追加の記録層を持つ形になるためです。Gitホスティングそのものを置き換えにいく動きとは方向が異なり、たとえばCursorがGitホスティング「Origin」で狙っているGitHub代替の構図とは、触る層が別だと整理できます。移行コストの見積もりでは、この差が効きます。

スレッド上でエージェントとレビューを回す流れと、プルリクエストとの分担

記録の仕組みが分かったところで、実際のレビュー動線を見ます。ここがDeltaの評価を分ける部分です。

会話とコードが同じスレッドに載ることでレビュー時に省ける再構成の手間

従来のレビューでは、差分から意図を逆算する作業が発生します。なぜこの引数が追加されたのか、なぜこの分岐が消えたのか。Zedはこの状況を「差分から意図を再構成する」と表現し、Deltaではその必要がないと述べました。レビュアーはコードの隣に、それを生んだ会話をそのまま読めるからです。

実務での効きどころは、レビューの往復回数です。意図が読めない指摘は「これは何のため？」という質問から始まり、1往復増えます。指示の原文がその場にあれば、その1往復は発生しません。エージェントが1日に数十件の変更を出す体制では、この差が積み上がります。

差分だけを見るプルリクエストとの役割分担と、CIを残す線引き

Deltaを入れてもプルリクエストが不要になるわけではありません。役割が分かれます。整理すると次のようになります。

観点	プルリクエスト	Deltaのスレッド
記録の単位	コミットと差分	編集操作と会話
参照の固定先	行番号とコミット	デルタの識別子
主な読み手	組織全体・社外	スレッド参加者
自動チェック	CIが実行する	CI側に委ねる
残す判断	マージの承認記録	判断に至る過程

線引きの原則はZedの説明どおりです。CIと外部への公開はGit側に残し、Deltaは判断の過程を持つ。マージ承認の記録は監査対象になることが多く、これをベータ段階の新基盤へ移すのは避けます。プルリクエスト側の機能でどこまで届くかを先に測りたい場合は、Cursor 3.3が入れたPRレビューと並列エージェントの整理が比較材料になります。

エージェントに直接説明や修正を依頼できるレビュー動線の実際と限界

Deltaのスレッドにはエージェントが同席し続けます。レビュアーは指摘を書くだけでなく、その場でエージェントへ「この実装の狙いを説明して」「ここを直して」と投げられます。エージェントは同じスレッドの会話と決定を読んでいるため、レビュアーが前提を貼り直す手間がかかりません。

限界もあります。この動線が成立するのは指摘がスレッド内で完結する範囲に限られ、別リポジトリの仕様変更や設計会議で決まった制約など、スレッドの外にある情報は自動では入りません。レビュー観点そのものの設計は道具では代替できず、コードレビューで何を見るかという観点と運用の組み立ては従来通りチーム側の仕事として残ります。

Claude Codeなど外部エージェントの接続経路と、Zedエディタとの違い

どのエージェントが使えるのかは、導入検討で最初に出る質問です。ここはZedが既に持っている仕組みの延長線上にあります。

Agent Client Protocol経由で外部エージェントをつなぐ接続の形

Zedは外部エージェントの接続にAgent Client Protocol（ACP）を使っています。Apacheライセンスで公開されているJSON-RPC 2.0ベースのオープン標準で、エディタとコーディングエージェントの間の通信を1本のプロトコルへ揃える狙いのものです。公式ドキュメントによれば、ローカルのエージェントはエディタの子プロセスとして起動し、標準入出力上のJSON-RPCで通信します。Claude CodeやGemini CLIがZedで動いているのはこの経路です。

Delta側では、サードパーティのエージェントハーネス対応がClaude Codeから始まり、そのセッションがDeltaのスレッドへライブで同期されると案内されています。エージェントを梱包して配る側の仕様に踏み込むなら、Agent Plugins 1.0の梱包仕様とクライアント準拠要件が接続の前提として効いてきます。

DeltaとZedエディタで用途が分かれる点と、併用時の使い分け

混同しやすいので明確にしておきます。ZedはRust製のコードエディタ、Deltaは同じチームが作った別アプリケーションです。Zedがブログで示した表現を借りれば、Deltaは、コードを書くのに最良の場所を作り次にコードについて話すのに最良の場所にする、という計画の後半にあたります。

使い分けは、書く作業がエディタ、話す作業と見る作業がDeltaという分担になります。ただしDelta自体にも編集機能があるため、両方で書ける状態です。評価の初期は無理に統一せず、レビューと引き継ぎの局面だけDeltaへ寄せると、既存の作業手順を壊さずに済みます。

デスクトップ版とWebAssembly版の提供形態と、現時点の入手条件

提供形態は2系統あります。ひとつはRustで書かれたデスクトップアプリで、macOS・Linux・Windows向けにインストーラが用意されています。もうひとつがブラウザ版で、同じコードをWebAssemblyへコンパイルしWebGLで描画する構成です。インストールせずに閲覧や参加ができるため、レビューだけ参加するメンバーの敷居が下がります。

入手はプライベートベータの招待制です。zed.dev上のDeltaDBページで登録を受け付ける形が案内されており、2026年8月時点では招待が順次配布されている段階にあります。課金は、Zedの有料プラン利用者へDelta向けのクレジットが既存の請求に組み込まれる形が示されていますが、正式提供時の価格体系として確定した情報ではありません。費用の見積もりに数字を置くのは避けてください。

エージェント併走の証跡をDeltaへ寄せる範囲と、既存基盤に残す範囲の設計

Deltaを入れると記録は増えますが、増えた記録の全部が資産になるわけではありません。寄せる範囲を設計しないと、読まれないログが積み上がるだけです。

監査対応で提出する証跡と、日々の作業ログを切り分けるときの基準

切り分けの基準は「第三者に提出する可能性があるか」の一点で引きます。提出しうるもの、つまり誰がいつ何を承認したかという記録は、Git側のコミットとプルリクエストの承認に残します。ベータ段階の新基盤に監査証跡を置くのは、可用性とデータ移行の両面でリスクが釣り合いません。

一方、日々の作業ログ、つまり指示・却下した案・修正の経緯はDeltaのスレッドへ寄せます。この層は提出物ではなく、次に同じ箇所を触る人が読むための材料だからです。両者を混ぜると、監査で出せない情報が証跡に混入するか、逆に読み返す価値のある文脈が承認記録の中に埋もれます。

担当交代と引き継ぎでスレッド履歴を再利用するための運用ルール

引き継ぎでスレッドを資産にするには、ルールを2つだけ決めておきます。ひとつは、スレッドの粒度を機能単位に固定すること。プロジェクト単位の巨大なスレッドは、後から読む人にとって検索対象が広すぎて機能しません。もうひとつは、方針転換が起きた時点でスレッド内に決定文を1行書き残すことです。

この2つが無いと、履歴は残っていても引き継ぎに使えません。エージェントとの会話は分量が多く、そのまま渡されても読み切れないからです。スレッドを閉じるときに決定文だけを設計文書へ転記する運用まで組んでおくと、担当交代のコストが下がります。

会話ログに機密情報が載る前提で決めておく共有範囲と保持期間の扱い

スレッドには顧客名、未公開の仕様、障害の詳細が載ります。Deltaはスレッド単位でメンバーを招待できる作りのため、招待の粒度が実質的なアクセス制御です。ここを緩くすると、リポジトリ権限では見えないはずの情報がスレッド経由で広がります。

決めておく項目は3つです。顧客名や本番データを含む議論をスレッドに書いてよいかの可否、外部の協力会社を招待する際の承認者、そして案件終了後にスレッドを保持するか削除するかの期限。プライベートベータの段階では、データの保持仕様や削除の挙動について公開情報が限られるため、機密度の高い案件は対象から外して評価するのが安全側の判断になります。

Zed Deltaを採用できるチーム条件と、現時点で見送るべき場面の線引き

Deltaは全チームがいつか使う基盤ではなく、条件が揃ったチームから効く道具です。

先に試す価値があるチームの条件を4点に絞って言い切る判断基準

次の4点のうち3点以上に当てはまるなら、評価に着手する価値があります。

コード変更の半分以上をエージェントが書いており、レビュー側が意図を追えなくなっている
1つの機能に複数人と複数エージェントが同時に触る場面が、週に何度も発生している
レビュー指摘が後続の変更で位置を見失い、指摘の取りこぼしが実際に起きている
担当交代が頻繁で、引き継ぎ時に「なぜこう実装したのか」の説明工数が積み上がっている

逆に、当てはまるのが1点以下なら急ぐ理由はありません。とくにエージェント併走がまだ試験段階のチームでは、Deltaが解く問題そのものがまだ発生していないためです。この場合、先に手を付けるのはレビュー基準の言語化であって、道具の入れ替えではありません。

プライベートベータの段階で本番の開発基盤に載せない判断の条件

採用を見送るべき場面も具体的に挙げます。第一に、監査や認証で開発工程の証跡提出を求められる案件。証跡の置き場をベータ製品へ移すと、提出できる形式や保持期間について説明責任を果たせません。第二に、リリース間隔が週次以下で止まると事業影響が出るプロダクトの主系統です。招待制の段階では、障害時の復旧見込みを自社で見積もれません。

第三に、機密度の高い顧客データを議論に含む案件があります。会話ログが記録の中心に置かれる設計である以上、書ける内容の線引きが決まっていない状態で入れると、後から削除の可否を問われて詰まります。この3つに該当するなら、正式提供と価格体系の公開を待つ判断が妥当です。

外注や受託の体制でDeltaを使うときに先に詰めておく契約面の論点

発注側と受託側が同じスレッドに入る構成では、成果物の範囲が論点になります。従来はリポジトリのコードが成果物でしたが、Deltaでは指示・却下案・判断過程がスレッドに蓄積されていきます。この蓄積を成果物に含めるのか、含めるなら案件終了時にどう引き渡すのかは、着手前に決める項目です。

もうひとつが、エージェントへの指示文の扱いです。指示文には発注側の業務知識が入るため、実質的にノウハウの記録になります。契約書の成果物条項がコードしか想定していない場合、ここで解釈が割れかねません。エージェント併走を前提にした開発体制の作り方から相談したい段階であれば、生成AI開発・AI受託開発で扱う範囲に入ります。決めずに走り出すと、案件終了時にスレッドの扱いで交渉が発生します。

Zed DeltaとDeltaDBの検討で挙がるよくある質問と実装目線での回答

発表直後に多く出ている質問と、公開されている一次情報の範囲での答えをまとめます。

Zed DeltaはZedエディタの機能として使えますか？

いいえ、Deltaはエディタの機能ではなく単体のアプリケーションです。Zed Industriesという同じチームが開発していますが配布物が分かれており、Delta側はmacOS・Linux・Windows向けのデスクトップアプリと、WebAssemblyへコンパイルしたブラウザ版の2系統で提供されます。Zedエディタを入れているだけでは使えず、プライベートベータの招待が必要です。エディタで書き、Deltaで話してレビューする併用が想定された構成です。

Zed Deltaを使うとGitは不要になりますか？

不要にはなりません。Zedは公式ブログで、DeltaDBは既存のgitリポジトリと動作すること、これまで通りコミットしてプッシュでき、Deltaを開かないチームメイトには普通のgitリポジトリに見えることを明記しています。GitとCIはチェックの実行と外部との接続という役割で残る位置づけです。DeltaDBが担うのはGitが記録していない編集操作と会話の層になります。既存の運用を壊さずに追加できる設計だと理解してください。

Zed Deltaは今すぐ使えますか？料金はかかりますか？

2026年8月24日時点ではプライベートベータで、招待制です。発表当日から最初の招待が配布され、以降数週間かけて対象を広げると案内されました。登録はzed.dev上のDeltaDBのページで受け付けます。料金は、Zedの有料プラン利用者にDelta向けのクレジットが既存の請求へ組み込まれる形が示されていますが、正式提供時の価格体系は公開されていません。導入費用の見積もりに金額を置ける段階ではないと考えてください。

Zed DeltaはClaude Code以外のエージェントにも対応しますか？

Delta側のサードパーティ製エージェントハーネス対応は、Claude Codeから始まると案内されています。他のエージェントへの拡大は明示されていませんが、Zedエディタ側では既にAgent Client Protocol（ACP）という共通規格で外部エージェントを接続しており、Claude CodeとGemini CLIがこの経路で動いています。ACPはApacheライセンスのJSON-RPC 2.0ベースのオープン標準で、この規格に沿ったエージェントが増えるほど接続先の選択肢は広がる構造です。現時点で確約されているのはClaude Codeのみと押さえてください。

DeltaDBとGitのブランチやマージはどう違いますか？

記録の単位が違います。Gitはコミット時点のスナップショットを保存し、ブランチはその系列を分けたうえでマージ時に衝突を人が解決する仕組みです。DeltaDBは操作ベースのCRDTを使い、個々の編集操作へ安定した識別子を与えます。CRDTは複数の書き手が同時に同じ箇所を編集しても結果が一意に収束する構造のため、同時共同編集の局面で手動の衝突解決が発生しません。ただしこれはコミット間の層の話であり、コミットとマージそのものはGit側に残ります。