DeepSeek Harness 徹底評価：「すべてがプラグイン」が DeepSeek-V4 に出会うとき

一、それは何か

2026年8月13日、DeepSeek は GitHub 上に新しいリポジトリを作成した：deepseek-ai/deepseek-harness。十日後、Star は 186,694、Fork は 20,709、コミットは 13,147 に達した。これはまた一つの ChatBot フロントエンドではない——DeepSeek 公式が手がけた Agent Harness（エージェント実行フレームワーク）であり、コードネームは dsh だ。

Claude Code、OpenAI Codex、あるいは Cursor の Agent モードを使ったことがあるなら、「AI がコードを書く」ことにはすでに直感があるはずだ。dsh が解く問題は同種だが、発想はまったく違う。特定の IDE に縛られず、特定のフロントエンドにも縛られず、特定のモデルにすら縛られない——差し替え可能なエージェントランタイムであり、すべての能力（モデル適応、ツール登録、サンドボックス実行、セッション永続化、子エージェント編成）がプラグインで、設定ファイルで組み合わせる。

現在のバージョンは 0.1.1-rc.2、MIT ライセンス、明確に developer preview と記され、互換性は約束されていない。つまり今これを本番で使うなら破壊的アップグレードのリスクを負う——だがそれゆえに反復も極めて速い。直近30日で 4,253 コミット、コアチーム10人、主力コントリビューター Tianyi Cui 一人で 5,268 コミットを担っている。

二、アーキテクチャ：すべてがプラグイン

dsh の基盤フレームワークは Cordis——「時空コンポーザブルなプログラミングパラダイム」の実装だ。dsh は Cordis の ソースをリポジトリに vendor している（npm 依存ではない）。名前を @deepseek-ai/cordis に変え、フレームワーク層を完全に所有する——監査可能、パッチ可能、バージョンを pin 可能。つまり dsh は上流 Cordis のリリース周期に縛られず、いつでもフレームワークコードを変えられる。

プラグインツリー

dsh のランタイムは一本のプラグインツリーで、起動時に順序付きの層（layer）から組み立てられる。

• Profile：名前付きの組み合わせで、どの bundle を使うかを定義する。組み込みテンプレートは web（ブラウザ UI 付き）と headless（純 CLI の一回実行）の二つ。
• Bundle：Cordis 設定行と対応コードの配布形式。dsh-base はすべての profile の第一層で、モデルアダプタ、ツール、永続化、サンドボックス、承認ポリシー、設定、資格情報、テレメトリを含む。dsh-web-app がブラウザアプリを足し、dsh-headless がサービスなしの一回実行ランナーを足す。
• Patch：各層は下層の設定を上書きできる。profile の cordis.patch.yml → home 級 patch → --patch コマンドライン上書き。

dsh --profile web --dump-config で、実際に起動する完全なプラグインツリーが見える。どの一行も自分の patch で差し替えられる。

パッケージ規模

モノレポ全体で 229 個のサブパッケージがあり、すべて @deepseek-ai/dsh-* スコープ下にある。ソース（node_modules と .git を除く）は約 153MB、TypeScript の行数は約 46.8万行。小さなプロジェクトではない——極めて高いエンジニアリング成熟度を持つ大規模システムだ。

コアパッケージの責務分担：

中核の設計原則は 登録即効果（Registrations are effects）。各プラグインの貢献は ctx.effect() / ctx.on() で登録され、register() は disposer を返す——プラグインがアンロードされると、登録したものはすべて自動で取り消される。「フラグを立ててあちこちで検査する」のではなく、フレームワーク級のライフサイクル管理だ。

三、モデル能力

dsh の LLM 層は provider-neutral な抽象の縫い目（seam）で、DeepSeek アダプタがデフォルト実装だ。

DeepSeek-V4 系列

組み込みモデルは三つ：

📝 2026-10-12 更新：DeepSeek 公式 API はすでに deepseek-flash（DeepSeek-V4.1-Flash、画像入力対応）を Flash モデル名として使う。旧名 deepseek-v4-flash と deepseek-v4-flash-vision-exp も呼べるが、対応モデルは提供終了済みで、リクエストは V4.1-Flash が処理する。deepseek-v4-pro は現在 DeepSeek-V4-Pro-0813 に対応。詳細は DeepSeek 公式価格ページ。また dsh は 2026-10-09 時点で dsh-v0.2.1-alpha.2 まで出ており、本評価は 0.1.1-rc.2 に基づく。

100万 Token のコンテキスト窓——これは現在公開利用できる最大級のコンテキストの一つだ。中規模プロジェクトの全ソースをコンテキストに詰め込み、モデルにコードベース全体の範囲で推論させられることを意味する。

デフォルト設定は thinking enabled + reasoning effort max：毎回のリクエストで深い思考を有効にし、推論強度を最大にする。これは DeepSeek が自社モデル能力に自信を持つ証——そして「われわれは DeepSeek だ、推論の演算能力はコスト制約ではない」という姿勢の表れだ。テスト方針には白黒はっきり書かれている。「We are DeepSeek — do not ration real-API tests.」

アダプタの特性

• 統一画像パイプライン：master と Files API のリクエストパイプラインは統合済み。read_image ツールは縮小後の寸法と座標比率を報告し、添付の格納は決定論的な正規エンコーディングを使う
• リトライ方針：provider にルーティングされた LLM リクエストの再試行（llm-retry パッケージ）、provider ごとに異なるリトライ戦略
• Token 計量：再生を意識した token 計測サービス（token-meter）、compaction 判断を支える
• pi-ai アダプタ：llm-pi-ai は llm-deepseek の設計検証用ツインで、pi-ai バックエンドでアダプタインタフェースの正しさを検証する

四、ツール生態

dsh のツールはハードコードされた数個の function call ではない——各ツールが一つのプラグインパッケージで、ctx.tools 経由で登録され、モデルは system prompt 内の JSON Schema でツールの存在を知る。ツールカタログはコード生成器が自動維持し（pnpm run gen-tool-catalog）、完全性ガードが新ツールのドキュメント漏れを防ぐ。

Shell 実行

• bash：ローカル子プロセス実装 + サンドボックス消費実装（各コマンドは ctx.sandbox の制約を通る）
• PowerShell：ローカル + サンドボックスの二系統、Windows 対応
• 永続ターミナル：tool-bash-persistent と tool-pwsh-persistent。モデル向けの owner スコープ永続ターミナルで、PTY サービスが支える

ファイルシステム

• fs-local：ローカルファイルシステム実装
• fs-sandbox：サンドボックス消費実装
• fs-observation-policy：ファイルシステム観察ポリシー
• tool-fs：モデル向けのファイル読み書きツール
• tool-fs-search：ファイル検索ツール（ripgrep 風）
• tool-str-replace-editor：文字列置換エディタ（sed に似るがより安全、あいまい一致付き）

Web 能力

検索エンジンは三つから選べる：

加えて web-fetch-http がウェブ取得を担う。

コードランタイム

• code-runtime：抽象的なコード実行の縫い目
• code-runtime-python：CPython 子プロセス実装
• code-runtime-worker-thread：Worker スレッド実装
• e2b：E2B クラウドサンドボックスの POC。FS と subprocess アダプタを含む

その他のツール

• LSP：言語サーバプロトコル対応（lsp-stdio）。モデルは補完、定義ジャンプ、診断を取得できる
• MCP クライアント：外部 MCP Server に接続し、そのツールを自動で ctx.tools に登録
• Skill システム：Agent スキル提供者の登録表。ファイルシステムからの読み込みに対応
• Todo：タスク管理ツール
• Plan Mode：ユーザー審査による退出機構付きの計画モード
• Goal：イベントソースの同一セッション目標状態とライフサイクルサービス
• Workflow：JavaScript オーケストレーションスクリプトのランタイム。ctx.workflowEngine 経由で実行
• Schedule：Agent スコープの永続化タイマー（after / at / fixed-rate）
• Session Query：セッション履歴クエリツール。SQLite バックエンド対応

五、子エージェントとオーケストレーション

ここが dsh のもっとも野心的な部分だ——四種の子エージェントバックエンドがあり、タスクを異なる AI Agent ランタイムに振り分けられる。

つまり dsh はメタオーケストレータ（meta-orchestrator）になれる。DeepSeek-V4 を主制御にし、具体的なコーディングを Claude Code に、推論タスクを別の dsh インスタンスに振り分ける。各バックエンドには対応する hook ブリッジプラグイン（hooks-claude-code、hooks-codex）があり、dsh のインターセプト縫い目上でそれらの hook 設定を走らせられる。

最近追加された Agent Teams（experimental/agent-team）は、永続的なマルチ Agent チームランタイムを提供する——一回限りの振り分けではなく、長期協働の Agent 編成だ。

六、サンドボックスとセキュリティ

dsh のサンドボックスは「Docker で走らせれば終わり」ではない——四プラットフォームのネイティブサンドボックス体系だ。

landlock-run は独立した npm 三パッケージ族（entry + プラットフォームパッケージ）で、独自の CI ビルドと公開フローを持つ。システムコマンドを呼ぶのではなく、Linux Landlock サンドボックス用に Node ネイティブプラグインを書いた——エンジニアリングの深さがうかがえる。

サンドボックスポリシー（sandbox-policy）は複数モードを支える。

• workspace-write：デフォルト。workspace 内の書き込みに制限
• danger-full-access：完全アクセス（CI／テスト用）
• 各セッションはモードと workspace root を独立に設定できる

権限承認（user-approval）はもう一層だ。danger 以外のモードでは、危険操作はユーザー確認を ask する。資格情報管理（credentials）は起動時の pre-release ドキュメント自動アップグレードや、永続化した資格情報記録に対応する。

七、永続化とセッション

dsh のセッションはイベントソース（event-sourced）だ。すべての状態変更は不変イベントとしてログに追記される。これにより時間旅行と再生が自然に手に入る。

ストレージバックエンド

• SQLite：主ストレージ。最近永続化レイアウトが最適化された
• JSONL：JSON Lines 形式。ACP とテスト fixture 用
• 両バックエンドとも zstd 圧縮に対応

セッション能力

• 投影（Projection）：イベントログからビューを派生。キャッシュ付き
• チェックポイント方針：session-checkpoint-policy
• テレメトリ：OpenTelemetry 統合（session-telemetry-otel）
• タイトル生成：LLM 駆動のセッションタイトル（先頭 prompt または全 prompt の二戦略）
• 統計：セッション級の統計データ
• ログエクスポート：セッションログの書き出しツール

Compaction

コンテキスト窓が限界に近づくと、compaction システムが介入する。

• compaction-basic：token-meter 駆動の圧縮方針と LLM 要約バックエンド
• compaction-tool-result-pruner：ツール結果の剪定
• command-compact：ユーザーが手動で起動できる /compact コマンド

八、開発者体験

三つの入口

1. Web UI：dsh web 起動後、デフォルトでブラウザを自動オープン（http://127.0.0.1:3080）。完全な対話 UI、モデル選択、設定パネル、プラグイン在庫、子エージェント管理を提供
2. CLI：dsh --profile headless "あなたのタスク" の一回実行。スクリプト化に向く
3. ACP：Agent Client Protocol。JSON-RPC over stdio。IDE 統合用——dsh を「埋め込まれる部品」として使うインタフェース

Python SDK

dsh は完全な Python SDK（python/ ディレクトリ）を提供する。改行区切りの JSON-RPC over stdio で bundled runtime と通信し、Python から関数のように dsh を駆動できる。

deepseek-harness-sdk    # 高水準 turns API + 低水準 JSON-RPC client
deepseek-harness-runtime-bin  # bundled runtime バイナリとデフォルト設定

設定体系

dsh の設定は宣言的な cordis.yml だ。典型的な設定は次のような形になる。

- id: llm-deepseek
  name: '@deepseek-ai/dsh-llm-deepseek'
  config:
    thinking: enabled
    reasoningEffort: max
    models:
      - id: deepseek-v4-pro
      - id: deepseek-v4-flash-vision-exp
        inputModalities: [text, image]

- id: sandbox
  name: '@deepseek-ai/dsh-sandbox-local'

- id: bash
  name: '@deepseek-ai/dsh-bash-sandbox'
  config:
    timeoutMs: 60000

設定は !!js 式（plugin config と entry disabled フィールド下）に対応し、条件付き組み合わせができる——たとえば環境変数でサンドボックスモードを切り替える。HMR（ホットモジュール置換）により、開発中にコードを変えても再起動不要だ。

テスト

dsh のテスト方針は、私が見たオープンソースの中でもっとも厳格な部類だ。

• ユニットテスト：vitest。各 registry に HMR 安全テスト（dispose 後に掃除をアサート）
• カバレッジゲート：per-file 100% on packages/*/*/src——全体 100% ではなく、ファイルごと 100%
• 実 API e2e：本物の DeepSeek API を打つテスト。key があれば走り、なければ自らスキップ
• スナップショットテスト：keyless。録画したセッション再生で JSON-RPC 出力を diff
• Web ブラウザスナップショット：Chromium で再生ブラウザ出力を比較。CI は強制的に読み取り専用 replay

per-file 100% カバレッジという要求は極めて攻撃的だ——テストで実行されていない一行があれば PR を block する。文書にはこうある。「An uncovered line is often dead code the gate is correctly flagging for deletion, not a missing test to bolt on.」

九、実戦体験

私はこの Linux マシン上で、ソースから dsh をビルドして動かした。

ビルド

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build

ビルドは順調で、最終的に 200 個の client artifact を出した。Node は比較的新しい版が必要（実測 v26.5.1 で可）、pnpm 11.7.0。

起動

node apps/cli/lib/bin.js web
# → 127.0.0.1:3080 を待ち受け、HTTP 200

起動後 Web UI は利用可能だった。モデル選択には V4-Flash、V4-Pro、Vision の三つ。UI はダークテーマで、サイドバーにセッション一覧、モデル選択、設定パネルがある。

実使用

dsh が本当に Agent ループを回すには DeepSeek API Key が必要なので、主に検証したのは次だ。

• ビルドと起動フローが順調か ✅
• Web UI が正常に描画されるか ✅
• 設定体系が合理的か ✅
• プラグインツリー dump が読めるか ✅

十、横断比較

dsh の独自の位置づけは、プラットフォーム級の Agent ランタイムフレームワークであって、エンドユーザー向けツールではないことだ。Claude Code と Codex は「すぐ使える」CLI、dsh は「すぐ変えられる」フレームワークだ。229 パッケージと 100% カバレッジゲートは、対象がコントリビューターと統合者であり、エンドユーザーではないことを示す。

十一、不足とリスク

1. Pre-release、破壊的変更

README には大文字太字でこうある。「THERE WILL BE COMPATIBILITY-BREAKING CHANGES.」バージョンは 0.1.1-rc.2、SQLite は単調増加の SCHEMA_VERSION、session 形式バージョンは 0 で互換は約束されない。いま dsh で本番システムを組むなら、いつでもアップグレードの落とし穴に備える必要がある。

2. メッセージ基盤アダプタがない

dsh には Telegram、Discord、Feishu、WeChatなどのメッセージ基盤アダプタが内蔵されていない。対外インタフェースは Web UI、ACP（IDE 向け）、API Gateway（プログラム呼び出し向け）だ。メッセージ基盤経由で dsh を使いたいなら、自分で中間層を書くか、別の Agent フレームワーク（たとえば Hermes）で橋渡しする必要がある。

3. ドキュメント密度が高く、入門の敷居が急

ドキュメントディレクトリには 30+ 本の記事があり、アーキテクチャ、Cordis primer、イベント生産者／消費者、防御的パターン、postmortem などを含む。質は高いが、読者に Cordis パラダイム、プラグイン効果システム、スコープ付きイベント配信の理解を求める——「5分で始められる」プロジェクトではない。

4. Node バージョン要求が新しい

実測では Node v26.5.1 が使えた。.nvmrc や .node-version の pin はないが、engines フィールドは node ^22.19 || >=24 を要求する。LTS Node 20 の環境では追加設定が必要になりうる。

5. 独立サンドボックスのない競合との比較

dsh のサンドボックス体系は充実しているが、Claude Code と Codex が依拠するのは OS 級の権限制御（ユーザー承認、作業ディレクトリ制約）で、大半の開発者にはそれで足りる。dsh の Landlock／Seatbelt／ACL サンドボックスは高セキュリティ要求の配備に向く——だが理解と設定のコストも増える。

6. モデル生態が閉じている

デフォルトでは DeepSeek-V4 系列アダプタしかない。LLM 層は provider-neutral な抽象だが、実装はいま一つのみ（llm-deepseek）に検証用ツイン（llm-pi-ai）が加わる程度だ。Claude や GPT を繋ぐには自分でアダプタを書く必要がある——subagent-claude-code と subagent-codex で子エージェントにはできるが、主制御モデルは依然 DeepSeek だ。

十二、まとめ

dsh はエンジニアリングの深さに驚くべきプロジェクトだ。Cordis フレームワークの vendor 戦略、四プラットフォームネイティブサンドボックス、100% per-file カバレッジゲート、四種の子エージェントバックエンド、イベントソースのセッション永続化——CLI ツールを作っているのではなく、Agent ランタイム基盤を作っている。

強みは次のとおりだ。

• 組み合わせ可能性：すべてがプラグインで、すべて差し替え可能。DeepSeek モデルを使いたくない？アダプタを書けばよい。ローカル bash が嫌なら E2B クラウドサンドボックスに換えられる。SQLite 永続化が嫌なら JSONL に換えられる。
• エンジニアリングの厳密さ：100% カバレッジ、実 API e2e、スナップショットテスト、Web ブラウザ e2e、ドキュメント生成ガード——「先に出して後で直す」プロジェクトではない。
• DeepSeek ネイティブ：100万コンテキスト、thinking モード、vision モデル——DeepSeek 自社のモデル能力は dsh では一等市民で、第三者アダプタを待つ必要がない。

リスクは次のとおりだ。

• 新しすぎる。10日のリポジトリ、pre-release、破壊的変更はいつでも起きる。
• 重すぎる。229 パッケージ、46万行。ただ「AI にコードを書いてほしい」エンドユーザーには、Claude Code や Codex の方が敷居がはるかに低い。
• DeepSeek すぎる。モデル生態は閉じ、メッセージ基盤は欠け、汎用 Agent フレームワークとしては生態を揃える時間がまだ要る。

誰に向くか：DeepSeek モデル生態の上で深くカスタムしたいチーム、高セキュリティサンドボックスが要る Agent 配備、プラグイン化 Agent アーキテクチャの最良実践を研究したいエンジニア。ただ AI にコードを書いてほしいだけなら、Claude Code の方が依然として実務的な選択だ——だが「理想的な Agent ランタイムはどう設計すべきか」を知りたいなら、dsh は丁寧に読む価値がある。

プロジェクト：github.com/deepseek-ai/deepseek-harness バージョン：0.1.1-rc.2 | ライセンス：MIT | 評価日時：2026-08-23