
Zedの人たちが出した「Delta」を触ってみた。レビューボタンは「承認」じゃなくて「解説」だった
Zedの開発元が出したDeltaをLinuxに入れて、小さなPythonのプログラムで「頼む→読む→レビュー→取り込む」まで通してみた。AIが承認してくれるボタンだと思ったら、人間がレビューする前のコード解説だった。
目次
Zedの開発元が出したDeltaをLinuxに入れて、小さなPythonのプログラムで「頼む→読む→レビュー→取り込む」まで通してみた。AIが承認してくれるボタンだと思ったら、人間がレビューする前のコード解説だった。
Deltaってなんだ? DeltaDBって見えたけど、ZedかAIかのセッションログとかをいい感じに保存しとけるDBとか?
まあ読むよりちょちょっと使ってみるか、と思って使ってみた。

入れるのはtar.gzとinstall.shだけ。ただしコードはZed側に保存される
Linuxは公式サイトからtar.gzを落として、中に入ってる install.sh を叩くだけ。sudoもいらなくて、ホームの下に入る。
Installed Delta to ~/.local/delta.app.
Linked CLI at ~/.local/bin/delta.起動するとGitHubでサインインして、ベータの規約に同意したら使えるようになる。
その同意画面にさらっと書いてあるのがこれ。
Data storage differs from the Zed Editor. Delta stores project data, including code, repository metadata, and thread contents.
DeltaはコードもスレッドのなかみもZed側に保存する。Zedエディタとは扱いが違うよ、ってこと。学習には使わないとも書いてある。なので今回は、中身のない見本のリポジトリで試した。

中身はAIセッションのアプリだった
そもそもDelta全体はAIセッションのアプリって感じだった。Claude CodeのGUIとか、ChatGPTアプリとか、あんちぐらびてぃV2とかみたいな、こんな感じのやつ。

基本はよくある流れで、プロジェクトとしてローカルのリポジトリのクローンを選んで作成して、そこでタスクを指示するって流れ。
Claude CodeがComing Soonだったのが悲しいけど、Codexも使ってるからそっちで試してみた。
コードを追いながら進めたい人には読みやすい
適当なPythonの1モジュールのTODOプログラムに変更指示してやらせた。頼んだのはこれだけ。
済みになったやることをまとめて消す clear を足して、テストも書いてコードを追いながらセッション進めたい人には読みやすい感じで変更が書かれていった。もうセッションで会話しながらレビューできるくらいのみやすさだったから、そこはめっちゃ良かった。

このへんは人によると思う。
私の周りの開発者には、もはやコードは完全ノールックで、ユーザ視点のモンキーいじいじして大丈夫そうならマージか、もっとあれだとノールック本番デプロイしてクレームきたら直す、みたいな人もかなりいるから、そういう環境の人には「おせーよ」って思うかもしれない。
けど私とかは完全に掌握できていないと、というかタスク指示時点で脳内コードとして存在するものと違うとやだよん、って人にはすごいいいとおもう。
レビュースタートボタンは「承認」じゃなくて「解説」だった
それからそのままレビュースタートボタンでレビューを始められた。
ボタンを押すまえは、AIがApproveか指摘かをしてくれるもんだと思って押したけど、そうじゃなかった。どちらかというと、人間がレビューする前段階のコード解説って感じだった。

これも触ってみたらめっちゃよかった。
よく考えれば、AI以前の開発といえば、まず触るコード周辺の機能のキャッチアップから始まって、ある程度の理解度になってからコードを書く、レビュワーはその部分に熟知している人、って感じだった。
けど昨今の開発は、なにもコードベースを理解していない状態で要求レベルのことをぽいっと投げて、要求を満たしてるふうだったらマージ、って人も多分増えてると思う。
私自身、個人リポジトリは逆に好きに作ってるから掌握してるけど、ものによってはしっちゃかめっちゃかに異常な速度でマージされまくるから、もう把握なんて諦めてし〜らねっておもってるのも正直あるw
とくにClaude 4くらいまでは、コード理解もAIにサポートしてもらいながら自分でレビューをしてたけど、それも間に合わなくなって、4以降くらいからはどんどんノールックに近くなっていた。
基本に立ち返った人間のレビューがしやすくなる感じで良かった。
読んで、聞いて、動かさせる、がそのまま続く
流れとしても、Start Reviewで変更範囲の案内、ここでなにしてるとか、どういう処理になってるとかを書いてくれる。
その上から、コードにフォーカスしてキー入力すると、その行に対して指摘、質問ができる。変更全体に対して「こういうデータが与えられたらどうなるのか実行しろ」みたいなことを言いながらレビューもできる。
たとえばこう聞いた。
全部が済みのときに clear したら何が表示される? 実際に動かして見せてそしたらその場で動かして、「空行を1行だけ表示します。『やることはありません』などのメッセージは出ません」って返ってきた。

そういうことをやりたいと思ったら、非常にシームレスでいい体験だった。
ちなみに解説してくれるのは、実装したのと同じモデルだった。これはむしろ今回の用途ならいいと思う。実装した人がレビュワー(俺!)に提出するに当たって説明してくれる、っていうシチュエーションだと思ったら、同じなのはただしい。
最後は自分でApproveかRequest Changesを選ぶ。判定を出すのは人間。

landは先に用意しとくのがよさそう
その後の流れ的には、landっていうスキルを用意する流れになっているみたいで、landスキルが要はその人のマージルールみたいなもんだった。
これは作らずにやると「ないから作る?」って聞かれるけど、うまくいかなかった。

何回かGUIの中だけでなんとかしようとしたけど。
起きてたのはこういうこと。Land Changesを押すたびに、新しい取り込み用のスレッドが元のスレッドから分かれて立つ。作ってもらったlandスキルは、ひとつ前のスレッドの作業コピーの中に置かれる。だから次に立ったスレッドからは見えなくて、また「ないから作る?」になる。

結局、元のスレッドでこう頼んで、ローカルのリポジトリにブランチとして送ってもらった。そのあとは普通にgitでマージ。
いまの変更を1つのコミットにまとめて、git push local HEAD:add-clear で元のリポジトリに枝として送って
多分これは、手書きかなんかで事前にスキル定義しとくのが一番いいと思う。公式のドキュメントだと、置き場所はリポジトリの中の .agents/skills/land/SKILL.md で、頭に delta-action: land って書いとくとLandボタンが拾ってくれる、とのこと。
ほかに引っかかったとこ
エージェントが終わったあとにChangesを開いたら「No changes」ってでた。比べる相手が「Since Branch」になってて、エージェントがまだコミットしてないから差分ゼロって言ってただけ。ここを「Last Commit」に変えると出る、と公式には書いてある。

あとShareを押したら、リモートがないとShareできない的なメッセージが出た。手元だけのリポジトリは共有できない。共有とブラウザ版は今回は試せてない。

試した環境
- ・Ubuntu 26.04、Delta(Linux x64版)、2026年10月1日
- ・モデルはCodex経由の「6 Astra」、強さはMedium
- ・見本はPythonのファイル1つとテスト2本のTODOプログラム。変更は3ファイル・49行の追加で、取り込んだあともテスト7本が通った

Backend Engineer / AWS / Django / Go