Delta

Deltaを選ぶ理由

コード生成より、変更の理解、レビュー、調整が難しくなったときに特徴が生きます。スレッドを作業単位とし、会話、変化するファイル、コメント、ツール活動、レビュー状態をつなげます。最終差分と別々の会話履歴だけを見るより、変更の経緯を追いやすくなります。

複数タスクを並行するチームで特に役立ちます。指示、途中の編集、端末出力、レビューが分散する問題に対し、同期された同じ記録へまとめます。ただし導入は、補完やチャット拡張の追加ではなく、スレッド中心の作業への移行になります。

基本的な作業の流れ

Gitリポジトリと範囲を絞ったタスクのスレッドから始めます。既定ではエージェントが隔離された管理用チェックアウトで動き、通常の作業ツリーには直接触れません。指示、同じ環境のターミナル、会話やコードへのコメントをスレッド内で扱います。

レビューでは最終差分だけでなく、その変更を生んだ会話を確認できます。同じスレッドで修正を求めたり、専用レビュースレッドへ移ったりでき、承認後はローカルのGitリモートや共有origin・PR経由で通常のリポジトリへ戻します。

スレッド自体を共有でき、画像や会話のコピーで引き継ぐ必要はありません。参加者に同期したチェックアウトが渡り、同じ会話、コード履歴、コメント、活動を追えます。モデル利用量は依頼を送った人に帰属し、特定の人の認証情報に依存しにくくなります。

活用例

長いリファクタリング、バグ調査、依存更新、多数のファイルとレビューを伴う開発に向いています。変更理由をスレッドに残し、コミット文への圧縮やエージェント記録の中への埋没を避けられます。

同じプロジェクトの隔離コピーで並行実験でき、エージェント同士の上書きを減らせます。実装用と承認・修正依頼用のスレッドを分けながら、元の作業との関係を保てます。

コードと会話が同期するため、別の開発者が参加し、PR説明から文脈を再構築せずに経緯を確認できます。途中で担当が変わる場合や、独特な実装の理由をレビュアーが知りたい場合に役立ちます。

他のツールとの比較

Cursor、Windsurf、Trae、Void、Zedは編集画面が中心で、AIがそこへ組み込まれます。Deltaは逆にスレッドを中心とし、ファイル、差分、ターミナル、コメント、エージェント実行をその作業に結び付けます。

速い補完や慣れたエディター内の助手だけが欲しい場合には、魅力が小さいかもしれません。エージェントやレビュアーが複数いる、変更の経緯を何度も説明する、といった状況では、履歴と共同作業の仕組みが重要になります。

同じチームのZedが近い比較対象ですが、用途は異なります。Zedはエージェントも使えるエディター、Deltaは会話と共同作業の独立アプリです。詳しく編集したいときは、管理されたチェックアウトをZedで開くこともできます。

おすすめの構成

通常はエージェントを隔離環境で動かし、現在の作業ツリーへ直接変更する意図がある、小さく管理された仕事だけをその場で実行します。試行と採用済みの変更を分け、完成したブランチをローカルへ戻せます。

モデルは用途別に選びます。安価なモデルで調査・要約、バランス型で実装、高性能モデルで計画・難しいレビューを行えます。ホスト型は月額上限を設定し、BYOKの認証情報はリポジトリではなく、対応する環境設定やDelta設定に置きます。

組織全体への公開を意図しない限り、既定のスレッドは非公開にします。CIを確認するならGitHubを連携し、開発サーバー、監視、長いテストはバックグラウンド端末で動かします。初期化が決まっているリポジトリでは、実行可能な.agents/prepareで環境をそろえられます。

移行時の注意点

VS Codeの設定一式や拡張の置き換えではありません。Gitを使い、独立したworktreeを持つ継続スレッドで作業する前提です。まず特定のリポジトリで範囲の狭いタスクを試し、すべてを一度に移さない方がよいでしょう。

コミット、ブランチ、リモート、PRはそのままで、間の細かな履歴が加わります。リモートなしでもローカル利用はできますが、共有には参加者がアクセスできるリモートが必要です。Jujutsu対応は初期段階で不完全なため、Gitと同等とは考えないでください。

大きな判断は技術より運用です。共有スレッドへ置く作業、レビュー方法、通常のブランチとPRへ戻す時点を決めます。この境界が明確なほど効果を得られます。