DeepSeek Harness は、また別のアップデートをリリースしました。
8月20日、プロジェクトは v0.1.0-rc.8 を公開しました。前回のリリース候補からわずか2日後です。今回のアップデートでは、マルチモーダル対応の強化、サブエージェント対応の改善、Windows ターミナルの修正、ツール呼び出しの高速化、そして複数のパフォーマンス変更がもたらされています。
一見すると、かなり普通のリリースに見えます。
しかし DeepSeek Harness は、より大きな理由によって開発者の注目を集めつつあります。それは、人々が 「モデルの周りにあるハーネスは、モデル本体と同じくらい重要なのではないか」 と問い始めていることです。
そのため rc.8 は、もう少し注意深く見る価値があります。
プロジェクトを初めて知る方は、公式の DeepSeek Harness 導入 も確認できます。
DeepSeek Harness はコーディングUI以上の存在
DeepSeek は、このプロジェクトをシンプルな発想で説明しています。
Agent = Model + Harness
モデルが推論と生成を担います。ハーネスは、それ以外のすべてを担当します。ツール、ターミナル、計画、権限、セッション、ストレージ、サブエージェント、そしてタスク実行などです。
もうひとつの中核原則が 「すべてがプラグイン」 です。
つまり DeepSeek Harness は、固定されたコーディングアシスタントというより、モジュール化されたエージェント実行環境として設計されています。
開発者が Claude Code、Codex、OpenCode、そして同種のツールと比較し続けるのも、ここが理由です。
問いはもう「どのモデルが優れているか」だけではありません。
それもまた：
どの環境が、モデルの力をより引き出すのか？
DeepSeek のモデルをめぐる初期のコミュニティ議論でも、同じモデルでも、周りにあるハーネスによって体感がかなり変わり得ることがすでに示されています。
マルチモーダル対応がより良く
rc.8 の最大級の変更のひとつが、マルチモーダル対応の改善です。
DeepSeek モデルアダプタは、ネイティブな画像リクエスト用に設定できるようになりました。/goal や /plan といったコマンドは、テキストと画像の入力に対応し、@ メニューはファイルやセッションをより扱いやすく参照できるようになります。
また、このアップデートでは、大きすぎる画像や、長い会話で蓄積しすぎた画像データが原因で起きる失敗も修正されています。
これにより、スクリーンショット、図解、UIモック、そしてその他の視覚入力を含むワークフローに対して Harness はより万全に備えられるようになりました。
ただし重要な点があります。
これで DeepSeek V4 自体が突然ネイティブのビジョンモデルになった、という意味ではありません。
DeepSeek の公開 API ドキュメントでは、チャット補完（chat-completions）のルートは依然としてテキストのみだと説明されています。rc.8 の変更は、特にユーザーが画像入力に対応するモデルやプロバイダを接続したときに、Harness 内部のマルチモーダル・パイプラインを改善する ものだと理解するのが正確です。
この区別は重要です。なぜなら DeepSeek Harness は DeepSeek モデルだけで動くわけではないからです。OpenAI、Anthropic、そして互換性のあるサードパーティのエンドポイントにも対応しています。
つまり、下にあるモデルがどれであっても、Harness はマルチモーダルになっていくのです。
Claude Code と Codex がサブエージェントとして動作可能に
もうひとつ面白い変更が、DeepSeek Harness が他のコーディングエージェントをどのように扱うようになったかです。
Claude Code と Codex は、Profile Bundles としてインストールできるようになり、サブエージェントとして使用できるようになりました。
Codex には、非対話型の権限モードと、複数の名前付きインスタンスのサポートも追加されます。
これにより、ひとつのメインエージェントがタスクを管理し、複数の専門化されたサブエージェントがリポジトリの異なる部分を並行して担当するようなワークフローを想像しやすくなります。
新しい reportDelivery の振る舞いが、さらにこれを後押しします。サブエージェントは、親に対して状況確認を繰り返させる代わりに、完了した時点で結果を親タスクへ報告できます。
これは重要な転換です。
Claude Code と Codex は、必ずしも DeepSeek Harness の競合に限りません。より大きなオーケストレーション層の部品として組み込まれる存在にもなり得ます。
とはいえ、初期のユーザーからのフィードバックでは、マルチエージェントのワークフローは今もプロダクトの中で比較的粗い領域のひとつであるようです。アーキテクチャは有望ですが、DeepSeek Harness はまだ公式には開発者向けプレビューです。
開発者はトークンコストを綿密に見ている
海外の議論で頻繁に出てくる話題のひとつが、トークン使用量とキャッシュヒット率 です。
エージェント型のコーディングは、大量のコンテキストを消費しがちです。エージェントは、リポジトリのファイル、ツール定義、過去のメッセージ、計画、そしてツール出力を何度も読み取ることがあります。
つまり、ハーネスの効率はコストに直結します。
一部の初期の DeepSeek Harness ユーザーは、長時間のコーディングセッションでキャッシュヒット率が非常に高い、場合によっては 90% を超えることがあると報告しています。これらは統制されたベンチマークというより逸話ですが、重要なポイントを浮き彫りにしています。
DeepSeek Harness を Claude Code、Codex、OpenCode、あるいは別の環境と比較する場合、単にモデルの価格だけを比べても十分ではありません。
より有用なテストは、次を同じ条件で比較することです。
- 入力トークンの総数
- キャッシュあり／なしのトークン
- 出力トークン
- 完了までの時間
- 最終タスクの品質
同じリポジトリ、同じモデル、同じタスクで。
周辺のエージェントが不要なコンテキストを繰り返し送ってしまうと、より安いモデルでも高くつくことがあります。
DeepSeek Harness は Claude Code や Codex より優れている？
まだ、普遍的な意味では「そう」とは言えません。
コミュニティのフィードバックは依然として割れています。
DeepSeek モデルでは、公式の Harness がより安定した結果を出すと考えるユーザーもいます。一方で、コーディングのワークフローがより成熟していて予測可能だと感じるため、Claude Code や Codex を今も好む人もいます。
おそらく今の市場を捉えるには、それが適切でしょう。
Claude Code と Codex は、主に洗練されたコーディング製品です。
DeepSeek Harness は、より広いものになろうとしています。つまり、モデル、ツール、サブエージェント、権限、そしてワークフローをすべて差し替えたり拡張したりできる プログラマブルなエージェント実行環境 です。
開発者により多くの柔軟性を提供する一方で、柔軟性は設定の増加と、壊れる可能性の増加も招きます。
Windows ユーザーに役立つアップグレード
rc.8 では Windows 対応も改善されています。
DeepSeek Harness は永続的な PowerShell セッションをサポートするようになり、Minimal プリセットでは既定で有効になっています。
以前は、コマンド間でシェル状態を失うことで Windows のワークフローが煩わしくなることがありました。開発者は、作業ディレクトリ、環境変数、仮想環境、ローカルサービスを毎回復元する必要が出るかもしれません。
永続セッションにより、そうしたワークフローが通常のターミナルを使う感覚にずっと近づきます。
ただし、コミュニティの議論では Windows 関連のエッジケースもまだ登場しているため、これは Windows サポートが完全に完了したサインというより、改善のひとつと考えるのが妥当です。
日常使いで効いてくる小さな修正
rc.8 には、いくつかの使い勝手向上も含まれています。
ユーザーがストリーミング応答をキャンセルした場合、すでに生成された部分は、その後の質問や分岐セッションのためのコンテキストとして利用できるようになりました。
OpenAI 互換のゲートウェイ対応も改善されており、カスタムのモデルプロバイダや社内ゲートウェイを使う開発者に役立つはずです。
web_search ツールは、同時クエリをサポートするようになり、複数のキーワード調査に必要な時間を短縮できます。
また、ローカルで dsh web を実行するとブラウザを自動で開けるようになり、小さいながらも繰り返し発生するセットアップ手順が不要になります。
これらはいずれも単体では大きな変化ではありませんが、まとめて見ると、より長いエージェントセッションがスムーズになります。
アップグレード前にバックアップを
rc.8 の変更のうち、特に注意すべきひとつがあります。
DeepSeek は SQLite のバックエンドを最適化し、読み書きのパフォーマンスを改善し、ストレージサイズを削減し、セッションのフォークを高速化しました。
しかし、更新されたストレージ形式は以前のバージョンと互換性がありません。
アップグレード後に既存のインデックスは作り直されますが、古いワークスペースデータがうまく移行できない可能性があります。
すでに DeepSeek Harness を実のある作業に使っている場合は、アップグレード前に重要なセッションやワークスペースデータをバックアップしておくのがよいでしょう。
また、このプロジェクトが今も 開発者向けプレビュー であることを再確認する意味もあります。破壊的変更が起こり得ます。
DeepSeek は Harness を別の製品として扱っている
DeepSeek は、このプロジェクトに関するより明確なブランドルールも公開しています。
開発者は、製品を「DeepSeek Harness を基に構築した」または「DeepSeek Harness と互換性がある」と説明できますが、無許可のプロジェクトは製品名に商標全体を使うべきではありません。
DeepSeek は、エコシステム向けプロジェクトの命名には略称 DSH を使うことを推奨しています。
これは些細に聞こえるかもしれませんが、法的な細部であると同時に、DeepSeek の野心を示しています。
Harness は、DeepSeek モデルに付属するサイドプロジェクト以上のものとして、徐々に位置付けが進んでいます。
それは、独自のプラットフォームになろうとしているのです。
なぜ rc.8 が重要なのか
rc.8 のいちばん面白い部分は、PowerShell の更新でも、画像対応でも、サブエージェントでもありません。
それが示している方向性です。
DeepSeek は、モデル周辺のランタイムを第一級の製品として扱っているように見えます。
モデルは差し替えられます。ツールは追加できます。他のコーディングエージェントはサブエージェントになり得ます。視覚入力は同じワークフローの中で扱えるようになります。セッションはフォークされ、リプレイされ、別々に管理できます。
それでも互換性、マルチエージェントの信頼性、トークン使用量、そしてプレビュー版のアップグレード周りには、まだまだ粗い部分がたくさんあります。
そのため DeepSeek Harness は、今日すべての開発者がワークフロー全体を移すべきものではないかもしれません。
ですが、ますますテストする価値が高まっています。
というのも、エージェントシステムがより複雑になるにつれて、最も重要な問いが単に 「どのモデルを使っているか？」 で終わらなくなるかもしれないからです。
次は 「そのモデルの周りで何が動いているのか？」 になるのです。