DeepSeek Harness徹底解説｜「すべてがプラグイン」の実体を129行の構成ダンプと起動ゲートで測る

2026年8月13日、DeepSeek AIがDeepSeek Harness（dsh）をMITライセンスで公開した。GitHubの deepseek-ai/deepseek-harness は公開から3日で115,000スターを超え、Hacker Newsのスレッドも本稿執筆時点で729ポイントに達している。掲げられた設計思想はただ一つ、「Everything is a Plugin（すべてがプラグイン）」だ。

ただし、この手の標語は紹介記事で何度も繰り返されるうちに検証されないまま定着する。幸い「すべてがプラグイン」は数えられる主張である。本記事では宣伝文とREADMEをいったん脇に置き、npm公開版（@deepseek-ai/dsh 0.1.0-rc.6）を実際にインストールして、構成をダンプし、起動を止められ、サンドボックスの実装を1つずつ確かめた結果をまとめる。読者が自分の環境で再現できるコマンドも併記した。

エージェント基盤そのものの全体像や、他フレームワークとの位置づけを先に押さえたい方は、まずAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証を参照してほしい。本記事はその中で「ハーネス層」に相当するDeepSeek Harnessを、実測に絞って掘り下げる。

DeepSeek Harnessとは——モデルではなく「body」を配る

DeepSeekはこれまでモデル（V3、R1、V4系）で知られてきた。DeepSeek Harnessが配っているのはその逆側、モデルに手足を与える実行環境である。READMEの表現を借りれば、モデルが脳なら、ハーネスは身体であり、その身体のあらゆる部位がプラグインとして交換可能になっている。

対象になるのは以下だ。モデル接続、ツール（bash・ファイル編集・Web検索）、スキル、セッション永続化、サンドボックス、ファイルシステム、エージェントループ、サブエージェント、ワークフロー、そしてWeb UIそのもの。UIまでプラグインという点が、Claude CodeやCodex CLIのような「完成品のCLI」とは根本的に発想が違う。

この設計を可能にしているのが Cordis というメタフレームワークだ。READMEは「A Programming Paradigm for Spatiotemporal Composability（時空間的合成可能性のためのプログラミングパラダイム）」という論文を参照している。抽象的に聞こえるが、実装まで降りると意味は具体的で、後述するisolateレルムとホットリロードの2点に集約される。

押さえておきたい前提：これは開発者プレビューである

READMEは大文字で「互換性を壊す変更が入る」と警告している。実際、GitHubの公開リポジトリの最終コミットは2026年8月13日 13:00（UTC）で、リリースタグもGitHub Releasesも作られていない。バージョン管理はnpm側で行われており、本記事が測ったのは npm の 0.1.0-rc.6（2026年8月13日 12:35 UTC公開）である。

「すべてがプラグイン」を数える——構成ダンプ129行の内訳

dshには--dump-default-configという、主張をそのまま検証できるフラグが用意されている。ユーザー設定や--patchオーバーレイを除いた、そのプロファイル本来の構成ツリーを出力するものだ。

npx @deepseek-ai/dsh --profile web --dump-default-config

出力は490行のYAMLで、そのうちプラグイン行（name:）は129行あった。内訳は以下のとおりである。

数だけでなく、出力のコメントが出所を示している点が有用だ。各行の上に # == @deepseek-ai/dsh-base や # == @deepseek-ai/dsh-base, patched by @deepseek-ai/dsh-web-app という注記が付き、「この設定は誰が置き、誰が上書きしたか」がダンプを読むだけで追える。プラグイン数が3桁に達する構成で、これは実務上かなり効く。

既定で無効な25行が意味すること

無効化されている25行を並べると、この構成の設計が見えてくる。

dsh-tool-bash / dsh-tool-fs / dsh-tool-fs-search / dsh-tool-web / dsh-tool-todo / dsh-tool-goal / dsh-tool-workflow / dsh-tool-str-replace-editor / dsh-skill / dsh-skill-filesystem / dsh-compaction-basic ——つまりエージェントが使うツール類がほぼ全部、ホスト起動時点では無効なのだ。

これは欠陥ではなく分業である。ツールを有効にするのは後述するエージェント・プリセットの役割で、ホスト側の構成はレジストリ・サンドボックス・永続化・モデルルートといった「セッションが所有してはいけないもの」だけを持つ。同梱の構成ファイルはこれをホストプレーン／エージェントプレーンと呼び分けている。

この2プレーン分離は、実装上強制されている。プリセット側の構成でサービスを公開する行は、必ずisolateレルムを持つグループの中に置かなければならない。置かなければそのサービスはルートレルム（=プロセス全体で共有）に公開されてしまい、2つ目のセッションが同じプリセットを読み込んだ瞬間に1つ目と衝突する。

dsh-agent-presetsはこれをマウント時に検査し、違反していればマウント自体を拒否する。エラーメッセージは「プリセットのサービスはisolateレルムの背後に置くか、ホスト構成へ移せ」と具体的に指示する形になっている。加えて、プラグインが後からタイマーや非同期継続でサービスを公開した場合に備え、サービス登録が変化するたびに全マウントを再検査する仕組みまで用意されている。

これが「時空間的合成可能性」の空間側の正体だ。抽象論ではなく、マウント時に落とされる具体的な制約である。

4つのプリセット——CodeはStandardとの差分がプラグイン1枚しかない

エージェントの性格を決めるのがプリセットだ。UIのメニューには Standard / Code / Minimal / Creator の4つが並ぶ。ディスク上の実体はconfig/agent-presets/配下の4ディレクトリで、それぞれpreset.yml（表示名）とagent.cordis.yml（構成本体）を持つ。

なおディレクトリ名と表示名は一致しない。Creatorモードのディレクトリ名はcreatorではなく cordis である。

この表で最も情報量が多いのは行数だ。standardとcodeの構成ファイルをdiffすると、コメントを除いた実質的な差分はプラグイン1枚（YAMLでは4行）だけである。

- id: tool-presentation
  name: '@deepseek-ai/dsh-agent-tool-presentation'
  config:
    mode: code

「Code Mode」という独立したモードがあるのではなく、Standardに提示層プラグインを1枚重ねただけ。5回のツール往復になるはずの操作列が、TypeScriptプログラム1本にまとまる——この挙動の差が、構成ファイル上ではプラグイン1行の追加として表現されている。「すべてがプラグイン」という標語が、ここで実際に機能しているのが確認できる。

Minimalモードはホストのサンドボックスをわざと迂回する

Minimalプリセットの62行は短いぶん、設計の意図が読み取りやすい。ペルソナはYou are a helpful software engineer assistant.の一文だけで、complete: trueが指定されている。これはこの文字列がシステムプロンプトの全体であり、以降のどの仕組みもプロンプトを追記できないという宣言だ。ランタイム情報のスナップショットも抑止され、コンテキスト圧縮も入らない。ベンチマークで条件を固定するための構成としては筋が通っている。

一方で注意すべき記述もある。Minimalプリセットのファイルシステムはisolateされたグループの中でdsh-fs-local（素のローカルFS）を使い、同梱コメントはこのプリセットに限りホスト側のサンドボックス済みプロバイダを覆い隠すと明記している。ベンチマーク用途では妥当だが、日常の作業用として選ぶモードではない。

Creator（创造模式）は自らを「シェルアクセス相当」と宣言している

セキュリティ面で最も重要なのはCreatorモードだ。cordis/agent.cordis.ymlの冒頭コメントには、TRUSTという見出しで警告が書かれている。要点は2つある。

・cordis_mountはモデルが書いたJavaScriptを稼働中のランタイムに対して評価する
・このエージェントが書いた構成は、他のセッションがマウントするプリセットになる

そのうえで、このプリセットのセッションはシェルアクセスと同等に扱えと結論している。ベンダーが自ら「これは事実上のRCEである」と同梱ファイルに書いているケースは珍しく、評価に値する誠実さだ。ただし当然ながら、信頼できない入力を扱うタスクや共有環境での常用には向かない。用途はカスタムプリセットの作成に限定するのが設計意図に沿う。

なお、プリセットの信頼レベル（trust）はpreset.ymlに書いても効かない。実装上trustはそのプリセットが発見されたルートディレクトリから決まる設計で、表示メタデータのファイルからはname / description / orderしか読まれない。ローカルで作ったプリセットが「同梱プリセットである」と自称できないようにするための作りで、こうした細部の詰め方は全体的に丁寧である。

自作プリセットの作られ方——書き込み経路は「まるごとコピー」1本だけ

Creatorモードが書く先、つまりユーザーが自分でプリセットを作る仕組みにも、いくつか意図的な制限が入っている。実装を読むと次のようになっていた。

・書き込み操作はディレクトリのまるごとコピーだけ。構成テキストそのものをAPI越しに渡す経路が無い。コピー元は既存プリセットのIDで指定するため、コピーによって新しい権限が生まれることがない
・プリセットIDは^[a-z0-9][a-z0-9-]*$に限定される。IDがそのままディレクトリ名になるため、これはスタイル規約ではなく..やパス区切りでルート外へ出るのを防ぐ封じ込め境界として書かれている
・コピー先はuserルート（$DSH_HOME/.agent-presets）のみ。同梱プリセットは「デプロイの一部」として扱われ、上書きも削除もできない
・コピー後にパーミッションを絞る。同梱プリセットはワールドリーダブルなことがあるため、コピー後にディレクトリ0700・ファイル0600へ落とし直す
・コピーは決して上書きしない。既存IDと衝突した場合はエラーになり、途中で失敗したらコピー先を消してから例外を投げる

同じプリセットを複数のセッションが使う場合、構成はプリセットごとに1回だけマウントされて共有される（standing mount）。ファイルを編集した場合は更新時刻とサイズの組で変更が検知され、それ以降に作られたセッションから新しい世代に切り替わる。すでに走っているセッションはマウント時の世代のまま動き続けるため、作業中に構成を書き換えても進行中のセッションの挙動が突然変わることはない。

細かい話に見えるが、「エージェントがエージェントの設定を書く」という構図では、こうした境界の置き方がそのままリスクの大きさを決める。DeepSeek Harnessはここを能力を増やさない方向に倒している。

起動しない時のために——2段の起動ゲートを特定した

ここからは実用寄りの話をする。npx @deepseek-ai/dsh webが動かないという報告は公開直後から出ているが、原因は大きく2つに分かれる。実測で境界を特定した。

第1のゲート：Node 22.15.0未満は起動しない

dshのセッション永続化プラグインdsh-session-persistence-jsonlは、node:zlibからcreateZstdDecompressをインポートする。この関数はNode 22系では22.15.0で追加されたものだ。それ未満のNodeでは、プラグイン読み込みの段階でSyntaxErrorになり、ハーネスは何も表示せずに落ちる。

公式tarballで3つのマイナー版を並べ、同じコマンドを実行した結果が以下である。

厄介なのは、@deepseek-ai/dshのpackage.jsonにenginesフィールドが無いことだ。そのためnpmもpnpmも「Nodeのバージョンが足りない」という警告を出さない。ユーザーが最初に見るのは、node_modulesの奥深くを指す読みにくいスタックトレースになる。

（余談だが、依存として入る@earendil-works/pi-aiはnode: >=22.19.0を宣言しているため、こちらはEBADENGINE警告が出る。宣言しているパッケージとしていないパッケージが混在している状態だ。）

# 起動する前にこれだけ確認しておく
node -v   # v22.15.0 以上であること

第2のゲート：APIキー

Nodeを22.15.0以上にすると、今度は明快なメッセージで止まる。

dsh: MISSING_CREDENTIAL: llm-deepseek: no API key for provider route
"deepseek-official"; store DEEPSEEK_API_KEY through the credentials service
(the web Models page writes it), or export DEEPSEEK_API_KEY in the launching
environment

第1のゲートと違い、こちらは何をすればよいかがそのまま書いてある。既定のモデルルートはdeepseek-official、既定モデルはdeepseek-v4-flashである。

ここで実務上有用な挙動が一つある。Web UI（dsh web）はAPIキーが無くても起動する。ブラウザでは初回に「Add an API key to get started」というダイアログが出るが、「Configure later」で閉じれば、UIの探索・プリセットの確認・設定画面の閲覧まではキー無しで行える。本記事冒頭のスクリーンショットは、まさにその状態で撮影したものだ。触ってみるだけならキーの用意は後回しでよい。

サンドボックスは3OSで別実装——そして「効かない時は止まる」

エージェント基盤を評価するとき、当サイトが最も重視するのはツール実行の封じ込めである。DeepSeek Harnessのdsh-sandbox-localは、OSごとに別のランナーを選ぶ設計になっている。

重要なのは、実装コメントが明言する次の一点だ。封じ込めが存在しない、または使えない場合、元のargvをそのまま返すのではなく失敗する（fail-closed）。効かないなら素通しではなく止まる、という側に倒してある。

Landlockランチャ（@deepseek-ai/node-addon-landlock-run）単体でも同じ思想が徹底されている。ランチャ自身にLandlockのルールセットを適用してから対象コマンドをexecし、ルールセットはexecveをまたいで継承されるためプロセスツリー全体が拘束される。許可していないものはすべて拒否され、ランチャの失敗は終了コード125でコマンドを実行しないまま終わる。C言語のソース（src/main.c）も監査用にtarballへ同梱されている。

実際にmacOSで確認した結果は以下のとおりだった。

platform: darwin arm64
launcherPath(): .../node-addon-landlock-run-darwin-arm64/bin/landlock-run
probe(): unusable

darwin-arm64というプラットフォームパッケージは公開されていないため、launcherPath()は存在しないパスを決定的に返し、probe()はunusableを返す。インストール時にソースからコンパイルするフォールバックは意図的に用意されていない。ここだけ見ると「macOSでは丸腰なのか」と読みたくなるが、そうではない。macOSではSeatbeltのランナーが選ばれるため、封じ込め自体は機能する。Landlockはあくまでもうひとつの選択肢という位置づけだ。

隔離の粒度をVMレベルまで上げたい場合の設計思想については、AgentENV：Firecracker microVMでAIエージェントを丸ごと隔離するで扱ったアプローチと読み比べると輪郭がはっきりする。DeepSeek Harnessが選んだのはOSネイティブの機構を積み上げる方向で、microVMより軽い代わりに、実装がOSごとに分かれる。

テレメトリは既定で無効、送信先はハードコード

構成ダンプにはテレメトリの行も含まれている。

・プラグイン：@deepseek-ai/dsh-session-telemetry-otel
・モード：process.env.DSH_TELEMETRY_MODE || 'DISABLED' ——既定は無効
・送信先：process.env.DSH_TELEMETRY_OTLP_URL ?? 'https://harness-telemetry.deepseeksvc.com/v1/logs'（gzip圧縮）

つまり環境変数で明示的に有効化しない限り送信は行われない。エンドポイントのURLは構成に直接書かれているが、環境変数で差し替えられる。また、npmインストール時には@deepseek-ai/dsh-anonymous-user-idという匿名IDを扱うパッケージも同時に入る。テレメトリを有効化する運用を検討するなら、この2つをセットで確認しておくのが妥当だ。既定のまま使う限り、送信経路は無効である。

モデル非依存はどこまで本当か

「model-agnostic」は公開時のアナウンスで強調された点だ。ここは数え方で印象が変わるため、測った事実だけを分けて書く。

・プロバイダー実装の層：モデル接続に使われる@earendil-works/pi-aiには、dist/providers配下に43個のプロバイダーモジュールが同梱されている（Anthropic、OpenAI、Amazon Bedrock、Google Vertex、Azure、Groq、Mistral、xAI、OpenRouter、Moonshot、MiniMax、Qwen、Cerebras、Fireworks、Together、NVIDIA、GitHub Copilot ほか）
・プロトコルの層：DeepSeek側のアダプタdsh-llm-pi-aiが名前として持つ文字列はdeepseek / openai / openai-completions / openai-responses / anthropic-messages / openrouter の6種
・既定のルート：deepseek-official＋deepseek-v4-flash

この6という数は「対応プロバイダーが6社」という意味ではない。プロトコルの種類であり、OpenAI互換エンドポイントやAnthropic Messages互換のエンドポイントを持つサービスは、この6種のいずれかに載って接続される。したがってBedrockやVertexが使えないという結論にはならない。プロバイダー層とプロトコル層は別の数え方だ、というのが正確な整理である。

いずれにせよ、モデル接続がプラグインとして差し替え可能であること自体は構成ダンプで確認できる。dsh-llm（インターフェース）、dsh-llm-deepseek、dsh-llm-pi-ai、dsh-llm-retryがそれぞれ独立した行として並んでおり、他のベンダー用アダプタを足す余地は構造的に開いている。

日本語UIは無い——ja-JPのフォールバック先は英語ではなく中国語

日本語話者にとって実務的に効く発見をひとつ。同梱ロケールはenとzhの2つだけである。dsh-client-localeのコードに現れるロケール識別子もこの2つに限られる。

問題はフォールバック先だ。ブラウザのAccept-Languageを変えて実測した結果は次のようになった。

つまり、日本語環境のブラウザでそのまま開くと、英語ではなく中国語のUIが出る。初回の「内测声明（クローズドベータの告知）」ダイアログも中国語で表示される。

英語UIで使いたい場合は、ブラウザの言語設定で英語を優先にすればよい。プリセット名も标准模式→Standard mode、PTC 模式→Code modeのように切り替わる。ちなみに中国語ではPTC 模式、英語ではCode modeと、同じプリセットが言語によって別の名前で提示される点も実測で確認できた事実として書き添えておく。

土台のCordisはどこから来たのか

最後に、この構成を支えるCordisについて触れておく。DeepSeek Harnessは@deepseek-ai/cordisに依存しているが、これはcordiverse/cordisをそのまま参照しているのではない。リポジトリのvendor/配下に取り込んだうえで、@deepseek-aiスコープで再公開したものだ。

vendor/に置かれているのは9つのパッケージである。cordis / cosmokit / schemastery / group / hmr / include / loader / logger-console / timer。いずれもCordis（元をたどればチャットボットフレームワークKoishiのエコシステム）由来で、package.jsonのauthorには原作者の名前がそのまま残っている。ソースコードは公開リポジトリに含まれており、隠されてはいない。

興味深いのはバージョンだ。

・上流 cordis（npm）：4.0.0-rc.8（リリース候補）
・@deepseek-ai/cordis：4.0.1（安定版）

つまりDeepSeekは、上流がまだリリース候補の段階にあるメタフレームワークについて、自社スコープで先に安定版を出した格好になる。ハーネス本体の互換性を自分たちのリリースサイクルで管理するための判断と読める。ライセンスはいずれもMITで、この取り込み方自体に問題はない。

なお、ホットリロード用のcordis-plugin-hmrは構成ダンプ上ではdisabled: trueだった。「時空間的合成可能性」の時間側——プロセスを再起動せずにプラグインを差し替える能力——は、開発時に有効化して使う位置づけである。

DeepSeek Harnessと既存エージェント基盤の違い

当サイトではこれまでも複数のハーネスを扱ってきた。位置づけの違いを整理しておく。

Claude Codeの構造をOSSとして再現するアプローチについてはOpenHarness徹底解説：Claude Codeの仕組みをOSS化したエージェント基盤で詳しく扱った。DeepSeek Harnessが違うのは、「完成品のエージェントを配る」のではなく「エージェントを組み立てる規約を配る」点にある。129行の構成ダンプも、4つのプリセットも、その規約の実例として読むのが正しい。

そもそもエージェントとハーネスの関係自体を整理したい場合は、AIエージェントとは何か——2026年の実装水準で理解するが入口になる。

まとめ——標語は数えられた

「Everything is a Plugin」は、この規模のプロジェクトにしては珍しく、額面どおりだったというのが実測の結論である。

・標準プロファイルは129行のプラグイン行で構成され、そのうち25行は既定で無効。ツール類をホストが持たず、プリセットが有効化する分業が実装されている
・Code ModeはStandardとの差分がプラグイン1枚（YAML 4行）だけ。モードの違いがプラグイン1枚で表現されている
・プリセットのサービスはisolateレルムに入れなければマウント時に拒否される。合成可能性が規約でなく検査として存在する
・サンドボックスはOSごとに別実装で、効かない場合は素通しでなく失敗する側に倒してある
・Creatorモードは自らシェルアクセス相当と宣言している。誠実だが、使いどころは限定される

一方で、開発者プレビューらしい粗さも実測で出た。engines未宣言のままNode 22.15.0以上を要求する起動失敗、日本語ロケールで中国語UIが出るフォールバック、GitHubのタグ不在といった点である。いずれも致命的ではないが、「動かない」と報告する前にnode -vを見るだけで解決する問題が含まれているのはもったいない。

DeepSeek Harnessは、モデルの会社が「モデル以外」を本気で配り始めたという意味で、2026年後半のエージェント基盤の議論に確実に影響する。まずはnode -vを確認してから、キー無しでUIを立ち上げてみるところから始めるとよい。

参照ソース

・deepseek-ai/deepseek-harness — GitHub公式リポジトリ（README、vendor/、config/agent-presets/。MITライセンス）
・DeepSeek Harness developer preview — Hacker News（2026年8月14日投稿、本稿執筆時点729ポイント）
・DeepSeek Harness 公式ページ
・@deepseek-ai/dsh — npm（0.1.0-rc.6、本記事の実測対象）
・cordiverse/cordis — 上流のCordis