DeepSeek HarnessとZed Delta解説 — エージェント開発環境の競争は「下」と「上」に割れた

はじめに

2026年8月11日から13日にかけて、コーディングエージェントを走らせる「入れ物」の側で3つの発表が続いた。11日に OpenAI が ChatGPT デスクトップアプリの Linux 版をプレビュー公開して Codex を同梱、12日に Zed チームの Delta がプライベートベータに入り、13日に DeepSeek が Harness を MIT ライセンスの開発者プレビューとして公開した。Harness は Hacker News で460ポイント超を集め、その日の最多得票になっている。

一見すると「Claude Code の対抗馬がまた増えた」という話に見える。だが Harness と Delta を並べて読むと、この2つはそもそも同じ席を争っていない。片方はハーネスを下に向かって分解し、もう片方はハーネスの上に別のレイヤーを積んでいる。 本記事では両者の設計を具体的に追いながら、エージェント実行環境の競争軸がどこに移ったのかを整理する。

「全部プラグイン」は何を分解したのか — DeepSeek Harness

DeepSeek Harness の設計方針は一行で言い切れる。エージェントを構成する要素をすべてプラグインにし、ハーネス本体はプラグインの合成結果でしかない、というものだ。公式ドキュメントが差し替え可能と名指ししている対象は、モデル、ツール、スキル、セッション、サンドボックス、ストレージ、ループ、スケジューリング、そして UI まで含む。プラグイン依存の解決は Cordis というカーネルが担当する。

ここで注目すべきは、リストに「ループ」と「セッション」が入っている点だ。多くのエージェントツールで、推論と行動を回すループ本体とセッション管理は手を出せない中核部分として固定されている。それを外部から差し替える対象として露出させるということは、エージェントの挙動を実験するための土台として自らを位置づけているに等しい。

この読みを裏づけるのが2つの機能だ。1つはセッションログで、システムプロンプト、推論、ツール呼び出しとその結果、サブエージェントのスケジューリング、あらゆるコンテキスト注入がすべて追記専用ログに記録される。同じイベントストリームから resume・fork・検索・リプレイができる。もう1つは4つのランタイムモードで、ファイル編集やシェルを備えた Standard、TypeScript プログラムとしてモデルに多段処理を組ませる Code、bash とエディタだけに削ぎ落としてベンチマーク用途に使う Minimal、そしてプラグインを実験するための Creator が用意されている。

Minimal モードの存在は特に示唆的だ。ハーネスの構成要素を引き算したときにスコアがどう動くかを測れるということであり、これは「ハーネスの設計こそがエージェント性能を決める」という近年の議論を、そのまま実験装置に落とし込んだものと言っていい。導入は npx @deepseek-ai/dsh web でローカルの 3080 番ポートに Web UI が立ち上がる。ただし互換性を壊す変更が入る前提のプレビュー版である点は明記されている。

「レビューが追いつかない」に賭けた上のレイヤー — Zed Delta

一方の Delta が出発点に置いた課題は、まったく違う場所にある。Zed の説明を要約すれば、エージェントはチームがレビューできる速度より速くコードを書く、というものだ。ここで問題視されているのはエージェントの実行性能ではなく、生成された変更を人間が理解して受け入れるまでの帯域である。

Delta の解法は、コードと会話を同じ空間に置くことだ。基盤となる DeltaDB は、会話スレッドとワークツリーの両方をリアルタイムに複製する。コメントの対象になるのは会話そのものか、ワークツリー上の任意の行だ。Zed はここで既存プラットフォームを名指しで批判している。曰く、コミットベースのプラットフォームではコメントがスナップショットに貼りつくため、コードが変わった瞬間に陳腐化する。Delta はコメントを固定されたコミットではなく、変化し続けるコードに追従させる。レビュアーが向き合うのは文脈の剥がれた diff ではなく、その変更に至ったプロンプトと判断の経緯が繋がったままのスレッドになる。差分に疑問があれば、その場でエージェントに説明させることも修正させることもできる。複数人が同じスレッドに第一級の参加者として入れて、後から誰かが続きを引き取れる。

重要なのは、Delta が git を置き換えないことだ。DeltaDB は既存の git リポジトリと並走し、コミットとコミットの間で失われる編集と議論を拾う。Delta を使っていないチームメイトからは、ただの普通の git リポジトリに見える。さらに Delta はサードパーティのエージェントハーネスに接続する設計で、その第一弾が Claude Code である。エージェントは慣れたターミナルで動いたまま、セッションが Delta のスレッドへライブで同期される。

つまり Delta は、ハーネスを自作せず、他社のハーネスを部品として受け入れる立場を最初から選んでいる。競争しているのは Claude Code ではなく、レビューと共同作業を担ってきた既存のプルリクエスト体験のほうだ。

エンジニアへの影響 — 選ぶべきは「層」であって製品ではない

この2つを並べると、実務上の意思決定が整理しやすくなる。

下のレイヤー（ハーネス本体）はコモディティ化が進んでいる。 モデル性能の差が縮まり、Claude Code、Codex、OpenCode、そして Harness が同じ役割を奪い合う状況では、ここを深く作り込んでも差別化は長続きしない。逆に言えば、乗り換えコストを下げておく設計が効く。MCP のような標準インターフェース越しにツールを持ち、プロンプトやスキルをハーネス固有の形式に閉じ込めないでおけば、選択は可逆になる。DeepSeek が自社ハーネスを MIT で丸ごと公開できたのも、そこが囲い込みの効く場所ではないと判断したからだと読める。

一方、上のレイヤー（レビューと協調）はまだ空いている。 エージェントが日に何本も変更を出すようになると、詰まるのは生成側ではなくレビュー側だ。Delta の賭けはここにあり、同種の課題は自作のエージェント運用でも普通に起きる。すぐ真似できる原則が2つある。ひとつは、変更と一緒にその判断根拠を必ず残すこと。もうひとつは、レビュー対象を diff ではなくスレッドにすることだ。エージェントに PLAN.md を書かせて変更と同じブランチに残すだけでも、レビュー時の復元コストは目に見えて下がる。

現実的な導入判断としては、Harness も Delta も本番投入は時期尚早である。Harness は互換性破壊を明言したプレビュー、Delta は招待制のプライベートベータだ。今やるべきは乗り換えではなく、自分のエージェント運用が下と上のどちらで詰まっているかを見極めることである。

まとめ

DeepSeek Harness はモデル・ツール・ループ・UI まで含めてすべてをプラグイン化し、追記専用のセッションログと Minimal モードによって、ハーネス設計そのものを実験可能にした（MIT、開発者プレビュー）
Zed Delta は「エージェントの生成速度にレビューが追いつかない」に照準を合わせ、DeltaDB で会話とコードを同期させる。git は置き換えず、Claude Code などのハーネスは部品として受け入れる（プライベートベータ）
両者は競合ではなく、ハーネスの下と上という別レイヤーへの賭けである
下は急速にコモディティ化しており、囲い込まれない構成にしておくのが実利的。上はまだ埋まっておらず、自作運用でも改善余地が大きい

同じ日、Hacker News では2015年の記事 Choose Boring Technology が再浮上していた。エージェント基盤が週単位で入れ替わる今、イノベーショントークンを下のレイヤーで使い切らない判断は、11年前より価値を増している。

今日のその他のニュース

同じRust製のBiomeとOxlintで、なぜ速度差が大きいのか — 実装言語が同じでも設計次第で性能差が生まれる、という当たり前だが軽視されがちな話を、両者のアーキテクチャの違いから分解した記事。Zenn

Androidのサイドロードに開発者認証が必須化 — Play Store 外の配布ルート（企業内配布、直 APK 配布）が実質的に閉じる方向。グローバル展開は2027年だが、ブラジル・インドネシア・シンガポール・タイの4カ国では2026年に先行して始まる点に注意。個人開発や受託案件の納品形態に直接影響する。ライフハッカー

anydoc — Word・Excel・PDFをMarkdownに変換するOSS — LLM への前処理として需要が明確なツール。Rust 製の MIT ライセンスで完全ローカル動作するため、機密文書を扱うケースでも使える。テクノエッジ