DeepSeek Harness（dsh）のセットアップと任意モデルの接続（2026）

DeepSeek は 2026-08-13 に自社製のエージェントハーネスを公開しました。最初の意外性は、それがターミナルではなくブラウザで開くことです。

得られるもの： あらゆる機能を差し替え可能なプラグインとして持つエージェントハーネス
所要時間：     コールドインストール約 2 分、ウォームな headless 実行は 1 回約 25 秒
必要なもの：   Node.js、API キー 1 つ、使い捨てのディレクトリ
インストール： npx @deepseek-ai/dsh web  →  http://127.0.0.1:3080
検証バージョン： 0.1.0-rc.6、macOS、Node 24.14.1、2026-08-14
ライセンス：   MIT、TypeScript、Cordis プラグインカーネル上に構築
ステータス：   developer preview、README で破壊的変更を明言
他モデル：     可能、カスタム provider または環境変数 2 つで

この名前が最初に登場したのは DeepSeek の 2026-07-31 の変更履歴でした。その脚注によれば、V4-Flash の Code Agent ベンチマークは「DeepSeek Harness minimal mode（近日公開）をフレームワークとして」測定されたものです。今日インストールできる rc がそのビルドそのものだと述べた公開情報はありませんが、そのプロジェクトが公の場に出てきたのは確かです。以下の内容はすべて 2026-08-14 にクリーンなマシンで実行した結果であり、README から書き写したものではありません。

セットアップ後にできること、できないこと

ブラウザ UI を備えたローカルエージェント、スクリプト可能な headless モード、そして HTTP で到達できる任意のモデルが手に入ります。 一方で、ターミナル UI、安定した API、今週から本番コードに向けられるようなものは手に入りません。

現時点で使えるもの：

• 127.0.0.1:3080 で動くローカル Web アプリ。セッション、ワークスペース、特権操作の前の承認プロンプトを備えます。
• dsh --profile headless "あなたのジョブ" による単発のスクリプト実行。最終回答を表示して終了します。
• OpenAI 互換、OpenAI-Responses、Anthropic-Messages のいずれかのエンドポイントをモデル供給元として利用可能。
• ランタイムを同梱した PyPI 上の Python SDK。呼び出し側のマシンに Node.js は不要です。
• モデル、ツール、スキル、セッション、サンドボックス、ストレージ、スケジューリング、UI 自体まで差し替え可能なプラグイン機構。

現時点で使えないもの：

• 対話的な TUI はありません。 ランチャーは CLI ですが、対話面はブラウザです。
• 安定したインターフェースはありません。 README は互換性を壊す変更があると大文字で警告しています。
• リリースもタグもありません（2026-08-14 時点）。つまり「最新」とは npx が解決したものを指します。
• GitHub issues がありません。 issue トラッカーは無効で、不具合報告は Discussions か Discord です。

今 DeepSeek Harness を入れるべきか？

プラグインアーキテクチャの上に何かを作りたいなら入れてください。今日仕事を片付けるエージェントが欲しいなら見送ってください。

向いている場合：

• エージェントのプラグインを書いている、あるいはハーネスのアーキテクチャを評価していて、Cordis の組み立て方こそが目的である。
• Code Agent のベンチマーク環境を再現するために、DeepSeek 自身のリファレンス実装が欲しい。
• ブラウザ前提あるいは共有サーバー構成でエージェントを動かしており、Web UI が妥協ではなく利点になる。

向いていない場合：

• SSH でリモートマシンを触って作業している。これはプロジェクト自身の discussions で最も大きな不満であり、それに応える TUI はありません。さらに UI を 0.0.0.0 で提供するなら trustedHosts の宣言も必要で、さもないと API 層は loopback 以外から届いたリクエストをすべて拒否します。
• 足元で壊れないハーネスが必要である。タグがなく rc が高速に回る developer preview はその正反対です。
• すでに信頼しているエージェントの中で DeepSeek モデルを使いたいだけである。その場合は既存のツールを DeepSeek API に向ければよく、この記事の内容は一切必要ありません。

打ち切りの目安： コーディングエージェントで DeepSeek モデルを使いたいだけなら、下の環境変数の節まで読んだら止めて、元のツールに戻ってください。

インストール前に必要なものは？

Node.js、キー 1 つ、そして書き込まれても構わないディレクトリ。

始める前に 1 つ決めておくことがあります。起動したディレクトリが既定のワークスペースルートになります。大事なリポジトリではなく、使い捨てのチェックアウトから始めてください。

DeepSeek Harness のインストール手順

コマンド 1 つ、そして約 2 分の沈黙。

手順 1: web プロファイルを実行する

mkdir ~/dsh-scratch && cd ~/dsh-scratch
npx @deepseek-ai/dsh web

やがて出る想定の結果：

dsh web: http://127.0.0.1:3080

初回の成功時、コンソール出力は npm の非推奨警告 1 つを除けばこの 1 行だけです。今回の実行ではコマンドからポートが開くまで約 2 分かかり、その間プロセスは 1 コアを 100% 使い続け、何も出力しませんでした。進捗表示はありません。60 秒でハングしたと判断して止めたなら、60 秒早すぎたということです。

手順 2: 初回起動の告知を閉じる

アプリは内部テストの告知から始まり、DeepSeek Harness 0.1 は「Harness 開発者向けにテスト中」と書かれています。閉じて先へ進みます。

手順 3: DeepSeek キーを入れる、または飛ばす

オンボーディングは DeepSeek の API キーを求め、Configure later も用意されています。別の provider を使う予定なら後回しを選んでください。それが次の節の内容です。

手順 4: 何がどこに置かれたか確認する

ls ~/.dsh
# profiles  storages

$DSH_HOME の既定は ~/.dsh です：

何かを編集する前に合成順序を知っておく価値があります。まず各 bundle のパッチが dsh.profile.bundles の順に、次にプロファイルの cordis.patch.yml、続いて $DSH_HOME/cordis.patch.yml、最後に --patch のオーバーレイです。結果は推測せず --dump-config で確認してください。

カスタム provider の追加方法

Settings → Models → Add a custom provider。組み込みの DeepSeek ルートの向き先を変えるだけなら環境変数 2 つで済みます。

フォームで求められるのは 5 項目です：

続いて Fetch available models を押すと、フォームに入っている base URL とキーで問い合わせ、返ってきたものから選べます。検出は OpenAI 互換の GET /models を呼びます。そのエンドポイントを提供していない場合は ID を手入力してください。

どちらの方法で埋めるにせよ、この一覧がそのルートのすべてです。models の一覧はルートのカタログを拡張するのではなく置き換えます。ルートが設定していないモデルは、リクエストがマシンを出る前に UNKNOWN_MODEL で失敗します。カスタム provider に「とりあえず送ってみる」経路はありません。

Provider ID が変更不可である点がいちばん刺さります。リクエスト、保存済みセッション、モデルの既定値、資格情報の参照がすべてこれをキーにしているため、改名とは新しい provider を作って古い方を消すことであり、旧 ID で記録済みのセッションは旧 ID を指したままになります。

クリックしたくなければ、$DSH_HOME/settings.yaml でも同じことができます：

llm-pi-ai:
  providers:
    ofox:
      apiKeyEnv: OFOX_API_KEY
      api: openai-completions
      baseURL: https://api.ofox.io/v1
      models:
        - id: deepseek/deepseek-v4-pro
        - id: anthropic/claude-opus-5

手入力したモデルが画像を拒むのはなぜ？

手で入力したモデルは、別途宣言するまでテキスト専用として扱われ、フォームにその項目がないからです。

エンドポイントにどのモダリティを受け付けるか問い合わせる手段はないので、dsh は狭い方を仮定し、送信前に添付を拒否してモデル名を示します。修正は settings.yaml でのみ可能です：

llm-pi-ai:
  providers:
    ofox:
      models:
        - id: deepseek/deepseek-v4-pro
        - id: anthropic/claude-opus-5
          input: [text, image]

追加したモデルすべてが画像を扱えるなら、ルート側に defaultInput: [text, image] を設定してください。これは上書きではなくフォールバックです。カタログ型の provider では、カタログが記述していないモデルにだけ効くので、もともと画像に対応しているモデルからその能力を奪うことはありません。

手入力したモデルは他に何を暗黙に仮定するのか？

既定値がもう 3 つあり、画像は派手に失敗する唯一のものにすぎません。 手で入力したモデルはメタデータを持たないため、ルートが推測します。その推測は文書化されてはいますが、UI からは分かりません。

最後の 1 つがゲートウェイ利用者にとって微妙な点です。thinking リクエストの通信形式はベンダーごとに異なり、下層のライブラリは URL からそれを推測します。プライベートなゲートウェイの URL は何も明かさないため、自社ドメインの背後にある DeepSeek 方言のエンドポイントは、明示しない限り OpenAI 方言で話しかけられます。compat の 2 つのスイッチは openai-completions にしか存在せず、他の 2 つのプロトコルは推論の形式をプロトコル自体が持っています。

コンテキストウィンドウの既定値は後から効いてくる種類のものです。262,144 は向ける先の多くのモデルより大きいので、長いセッションはエンドポイントが拒否または切り詰めるリクエストを組み立ててしまい、ハーネスにはそれを事前に警告する理由がありません。

設定ファイルを触らずに dsh をゲートウェイへ向けるには？

変数を 2 つエクスポートすれば、組み込みの DeepSeek ルートがそれに従います。 そのルートの apiKeyEnv の既定は DEEPSEEK_API_KEY で、base URL は公開 API より先に $DEEPSEEK_BASE_URL へフォールバックします。

export DEEPSEEK_API_KEY="your-gateway-key"
export DEEPSEEK_BASE_URL="https://api.ofox.io/v1"
npx @deepseek-ai/dsh --profile headless "Reply with exactly this and nothing else: dsh-ofox-ok"

これは 2026-08-14 の実際の実行で、dsh-ofox-ok を表示して終了コード 0、ウォームキャッシュで 24 秒でした。設定ファイルも UI も provider の登録も不要です。うまくいくのは、ゲートウェイが DeepSeek ルートの送るモデル ID をそのまま受け付けるからです。deepseek-v4-flash と名前空間付きの deepseek/deepseek-v4-flash の両方が同じエンドポイントで解決することを確認しました。

きちんと設定する前に「自分のエンドポイントはこれで動くのか」を確かめる最短の方法がこれです。

CLI や TUI はあるのか？

CLI ランチャーと headless 実行モードはあります。対話的な TUI はありません。

ランチャー自体のエントリーモード：

ランチャーのフラグが先で、認識できない最初のトークンからアプリ側の引数が始まります。したがって dsh --profile web --port 8080 は --port をランチャーではなく Web アプリへ渡します。

headless は知っておく価値のあるモードです。TUI がないという話の多くは、ターミナル経路自体が存在しないことを前提にしているからです。経路はあります。対話的でないだけです。CI、cron、スクリプトによる評価にはむしろこの形が適しています。

「ブラウザ以外のものをくれ」がプロジェクトの discussions で最も大きな声で、2026-08-14 時点でスレッドは 622 件まで増えていました。最多得票は 74 票で、スタンドアロンのクライアントと CLI と VS Code 拡張を求めるものです。TUI を名指しで求めるスレッドは 24 票で 2 位でした。エージェント本体に関する話題で、これが何の上で動くのかという問いを上回るものはありません。

これは DeepSeek 側の盲点でもありません。リポジトリにはターミナルの対話的拡張サービスに関する 2026-07-22 付の内部アーキテクチャノートがあり、下地は公開の 3 週間前からあったことになります。

プログラムから使える API はあるか？

あります。Node のパッケージではないため見落としやすいだけです。pip install deepseek-harness-sdk（0.1.0rc6、Python 3.10 以上）はハーネスのランタイムを同梱するので、実行するマシンにシステムの Node.js はまったく不要です。リポジトリにはワークスペース、セッションディレクトリ、プロンプトを受け取る実行可能な JSON-RPC のサンプルもあります。DEEPSEEK_API_KEY と DEEPSEEK_BASE_URL をランチャーと同じように読むので、上の変数 2 つのゲートウェイの手法はこちらでも使えます。対応プラットフォームは CLI より狭く、Linux x64、Linux arm64、macOS 14 以上の arm64 です。

実際に差し替えられるのはどこか？

プロファイルの package.json にある bundle の一覧です。「あらゆる機能がプラグイン」がスローガンでなくなるのがここです。

プロファイルは順序付きの bundle 一覧を指定し、標準で付いてくる 3 つは npm 上で個別に公開されています：

4 列目は豆知識ではなく落とし穴です。ランチャーは 3 つとも ^0.1.0-rc.6 に依存しているので、npx 経由ならバージョンの揃ったツリーが手に入ります。しかし npm 上では bundle の latest タグが今も 0.0.1-rc.1 を指しています。これはリポジトリ公開の 3 日前、2026-08-10 に公開されたものです。現行のビルドは next タグの下にあります。npm i @deepseek-ai/dsh-base と手で入れると、何も告げられないまま公開前のビルドが入ります。

サードパーティのプラグインの追加は、自分でパッケージマネージャを叩くのではなくランチャー経由です。ランチャーのドキュメントによれば、dsh plugin --profile <name> はそれ以降のすべてをプロファイルのディレクトリ内の pnpm へ転送するので、既に知っている pnpm の文法がそのまま通ります：

dsh plugin --profile web add <package-name>

プラグインはそのプロファイル自身の node_modules に入り、標準の bundle の後に解決されます。

エコシステムはソフトウェアの安定より速く立ち上がりました。GitHub の dsh-plugin トピックは 2026-08-14 時点で 775 リポジトリ、リポジトリ公開からおよそ 14 時間後の数字で、この記事を書いている数時間のあいだに 337 から倍以上に増えました。品質はまちまちで、公式のものはなく、star 目的でトピックを付けただけのものも多いので、推薦リストではなくディレクトリとして扱ってください。

人々が最初に作ったものは今も示唆的です。最も star を集めた実際のプラグインはテキスト専用モデル向けの視覚ブリッジで 760 star、2 つ目の視覚ツールキットが 569 star です。これはまさに、テキスト専用という既定がカスタム provider 経由でテキストモデルを使う人に生む空白そのものです。ランキングのもう一方の端はやはりインターフェースへの不満で、Web UI のプラグインとスキンの詰め合わせが 650 star、コミュニティ製の TUI は 292 star から並びます。

セットアップ中に壊れる箇所とその直し方

知っておく価値のある失敗が 6 つ。4 つは自分たちが踏んだもの、2 つは公開初日に他者が報告したものです。

API キーの欄は、それがどの provider のものか決めてから埋めてください。キーは $DSH_HOME/.credentials.yaml に入り、ページにはマスクされた記述子しか返りません。良い設計ですが、UI から読み戻して確認することはできないという意味でもあります。

チームで dsh の設定を共有するには？

共有するのはプロファイルであって、資格情報ではありません。 プロファイルとは、bundle を指定する package.json と上書きを収める cordis.patch.yml を持つディレクトリで、どちらにも秘密は含まれません。

preview 段階のツールにおける現実的な分担は次の通りです：

• プロファイルのディレクトリをコミットする。bundle 一覧、プラグインの依存、モデルのルートと権限の既定値を含むパッチ層。
• $DSH_HOME/.credentials.yaml は決してコミットしない。settings.yaml で apiKeyEnv を使い、各開発者が環境から自分のキーを与える。
• 何も固定せず、変動を前提にする。 固定できるタグがないので、検証した rc のバージョンを自分たちの README に記録し、更新のたびに再確認する。
• 全員を 1 つのエンドポイントに向ける。 そうすればモデル一覧、支出、レート制限が開発者ごとではなく共有になります。

最後の点は、このハーネスに限らずどのハーネスでも多くのチームが取りこぼすところです。

dsh と他のエージェントで同じキーを使うには？

エージェントハーネスはどれもモデルアクセスを個別に設定させます。Claude Code は独自の環境変数、Codex CLI は config.toml の provider ブロック、Cline は独自の設定画面、そして dsh はカスタム provider か DEEPSEEK_BASE_URL です。ツールが 4 つ、キーを回す場所が 4 か所、同期を保つべきモデルカタログが 4 種類。

4 つとも OpenAI 互換または Anthropic 互換のエンドポイントに対して HTTP で話すので、解決策はどれでも同じです。base URL とキーを 1 つずつ与え、違うのはモデル文字列だけにする。集約ゲートウェイはそのためにあり、dsh のカスタム provider フォームがちょうどあの項目構成である理由でもあります。

ofox ではエンドポイントが https://api.ofox.io/v1、プロトコルは openai-completions で、2026-08-14 時点で同じキーから 129 モデルに届きます。DeepSeek V4 Pro、DeepSeek V4 Flash、Claude Opus 5、Kimi K3 などが含まれます。他の 3 つのツールでの同等の設定は、Codex CLI のカスタム provider ガイドと Cursor、Claude Code、Cline の設定手順を参照してください。

本物のリポジトリに向ける前に知っておくべきことは？

これは preview であり、公開初日にコミュニティが権限境界の不具合を見つけているということです。

プロジェクトの discussions には公開から 24 時間以内に、ファイルサンドボックスと権限モデルに関する独立した複数の報告が上がりました。workspace-write の境界、パス処理の競合、承認フローに関わるものです。ここではそのいずれも再現しません。作者自身が developer preview と明示し破壊的変更を予告しているソフトウェアとしては、驚くべきことでもありません。

実務的な読み方は「このツールは危険だ」ではなく「このツールの権限モデルはまだ揉まれていない」です。そこから習慣が 2 つ導かれます：

• 使い捨てのディレクトリから起動する。呼び出し元のディレクトリがワークスペースルートになるため。
• 権限モードは既定のままにし、承認プロンプトをクリックで流さずに読む。

どちらも安上がりです。代わりの道は、大事なリポジトリの上で境界を発見することです。

すでに使っているハーネスとの比較は？

形は違い、仕事は同じ、走行距離は圧倒的に短い。 Claude Code と Codex CLI はターミナル優先で数か月の実戦を経ていますが、dsh はブラウザ優先で公開 1 日、しかも気に入らない部分を fork ではなく差し替えられるように作られています。

真の差別化要素はプラグインアーキテクチャで、これは本物です。モデル層、ツール層、サンドボックス、ストレージ、UI がすべてローダーによって組み立てられる bundle であり、だからこそゲートウェイの差し込みがパッチではなくフォーム入力で済みます。その組み立てやすさが安定した API との衝突を生き延びるかどうかは未解決の問いで、今は誰にも答えられません。

成熟した選択肢の中から選ぶなら、その比較は AI コーディングエージェントハーネス総まとめで行っており、ターミナル系エージェントに絞った比較は Claude Code vs Codex CLI vs Cursor にあります。最終的に選ぶハーネスに載せる DeepSeek モデルを決めるのが主目的なら、V4 Pro と V4 Flash がそのトレードオフを直接扱っています。

参考情報源

• DeepSeek Harness リポジトリ
• dsh ランチャーのリファレンス
• モデル provider ガイド
• dsh-llm-pi-ai アダプターのリファレンス
• プラグイン設定カタログ
• Python SDK ガイド
• PyPI の deepseek-harness-sdk
• DeepSeek Harness 公式サイト
• Cordis プラグインカーネル
• @deepseek-ai/dsh の registry メタデータ
• DeepSeek API 変更履歴
• プロジェクトの discussions