DeepSeekといえばLLM本体（DeepSeek-V3やDeepSeek-R1系）で知られていますが、2026年8月、そのDeepSeek AIが公式GitHub組織から新しいOSSを公開しました。エージェント基盤「DeepSeek Harness」（コマンド名は `dsh`）です（リポジトリ: https://github.com/deepseek-ai/deepseek-harness ）。npmパッケージ `@deepseek-ai/dsh` の初版が公開されたのは2026年8月10日で、この記事を書いている時点でもまだ1日単位でalpha/rc版が更新され続けている、かなり若いプロジェクトです。
この記事では公式リポジトリと公式ドキュメントを一次情報としつつ、実際にこのクラウド環境で `npx @deepseek-ai/dsh` を実行し、Web UIの起動、`--dump-default-config` によるプラグイン構成の確認、headless／ACP／SDKといった各プロファイルの挙動までを試した結果をまとめます。会話セッションを最後まで回すにはDeepSeek公式APIの認証情報が必要で、この検証環境にはAPIキーを用意していないため、そこから先はエラーメッセージとドキュメントの記述として区別して書いています。
- この記事でわかること：DeepSeek Harness（dsh）が何をするツールで、誰が作っているか。
- 実際にインストールして `dsh --version` `dsh --help` `dsh --dump-default-config` を動かした結果。
- 「すべてがプラグイン」を支える基盤フレームワーク「Cordis」の正体。
- `dsh web` でWeb UIを起動し、トークン付きURLでのアクセス制御を確認した記録。
- `web` 以外に用意されている `headless` `acp` `sdk` プロファイルの役割。
DeepSeek Harnessとは
公式READMEによれば、DeepSeek Harnessは「everything-is-a-plugin（すべてがプラグイン）」という設計思想で作られたエージェントフレームワークです。ライセンスはMIT。Web UI・headlessモード・ACP（Agent Client Protocol）サーバー・SDK向けJSON-RPCサーバーといった複数の“入口”を、同じプラグイン構成の上に積み重ねる形で提供しています。
npmのパッケージ情報を見ると、`@deepseek-ai/dsh` は0.0.1-rc.1（2026年8月10日）から始まり、この記事の執筆時点（2026年9月17日）で0.1.6-alpha.2まで、1〜数日おきにalpha/rc版が公開され続けています。READMEにも「developer preview（開発者プレビュー）であり、破壊的変更が続く」と明記されており、まだ枯れていない段階のプロジェクトだと分かります。
「すべてがプラグイン」を支える基盤：Cordis
DeepSeek HarnessのREADMEは、その基盤に「Cordis」というプラグイン実行系を使っていると説明しています。Cordis自体はDeepSeek Harnessの一部ではなく、`cordiverse` という別のGitHub組織が公開している独立プロジェクトです（https://github.com/cordiverse/cordis ）。設計の理論的な裏付けは、同組織が2026年8月末頃に公開した論文「A Programming Paradigm for Spatiotemporal Composability」にまとめられており、arXivで読めます（https://arxiv.org/abs/2608.25512 ）。
論文の要旨を読む限り、Cordisは「プラグインを外したときに副作用を完全に巻き戻せること（temporal composability）」と「コンポーネント間の依存関係を宣言的に管理し、変化に応じて自動で有効化・無効化できること（spatial composability）」の2つを核とした、プラグインシステム向けの形式的な枠組みです。DeepSeek Harnessは、このCordisの上に「LLM呼び出し」「セッション管理」「認証情報」「ストレージ」といった個々の機能をすべて別々のプラグインとして積み上げる構成になっています。
実際にインストールしてみる
公式README記載どおり、npxで直接実行できました。ローカルにインストール不要で試せる点はGoose（弊ブログでも過去に紹介）と同じ手軽さです。
- コマンド: `npx @deepseek-ai/dsh@0.1.5-rc.2 --version` → `0.1.5-rc.2` を返した
- `dsh --help` のトップレベルコマンドは `web`（Web UIプロファイルの起動）と `plugin`（プロファイルへのプラグイン追加・削除をpnpm経由で行う）の2つのみ
- `--profile <name>` オプションで任意のプロファイルを指定できる。`--dump-config` / `--dump-default-config` で合成後のプラグイン構成をYAMLとして確認できる
試しに存在しないプロファイル名 `tui` を指定すると、`dsh: profile "tui" does not exist; create it with 'dsh plugin --profile tui add <package>'` という明確なエラーが返りました。逆に言えば、`web` 以外の名前は自分で `dsh plugin --profile <name> add <package>` して初めて実体ができる、あくまでテンプレートからの合成物だという設計が、エラーメッセージからそのまま読み取れます。
--dump-default-configで見るプラグイン構成
`dsh --profile web --dump-default-config` を実行すると、`web` プロファイルが実際にどんなプラグインを積んで起動しているかがYAMLでそのまま出力されます。冒頭だけでも `timer` `hmr`（ホットモジュールリプレイス）`llm` `session` `session-log-deepseek` `typert-gateway` `session-title` `user-questions` `agent` `jobs` `credentials` `storage` `storage-json` など、機能ごとに細かく分割されたプラグインIDが並んでいました。
中でも目を引いたのが `agent-default-model` というプラグインの設定で、`provider: deepseek-official` `model: deepseek-flash` とデフォルト値が明示されていた点です。つまり素の状態では、対話の既定モデルはDeepSeek公式APIの `deepseek-flash` が選ばれる構成になっています。ただし別途調べたところ、プロバイダー周りは `llm-deepseek`（DeepSeek公式チャット補完のみを扱う）と `llm-pi-ai`（OpenAI・Anthropic・Bedrock・Vertex・Azureなど、OpenAI互換エンドポイントを横断的に扱うアダプター）の2系統に分かれており、後者を使えば他社プロバイダーやセルフホストのゲートウェイも設定だけで追加できる作りだと公式ドキュメントのプロバイダーガイド（`docs/user/guide/providers.md`）に書かれています。DeepSeek専用ツールではなく、既定値がDeepSeek公式に向いているツール、というのが実態に近い理解です。
Web UIを起動してみる
`dsh web --no-open --port 34567` を実行すると、`dsh web: http://127.0.0.1:34567/?token=...` という、ランダムなトークン付きのURLが標準出力に表示されてサーバーが起動しました。
- トークンなしで `http://127.0.0.1:34567/` にアクセス → `401 Unauthorized`
- 表示されたトークン付きURLでアクセス → `303`（おそらくCookie発行後のリダイレクト）
ローカルで動くツールだからといって無認証で開放するのではなく、起動のたびに一度きりのトークンをURLに埋め込み、それを知らないと開けない作りになっている点は、地味ですが安全側に倒された設計だと感じました。`--trusted-host` オプションでは、`/api` エンドポイントを叩けるブラウザ側のオリジンを追加で許可できるようになっており、リバースプロキシ越しに使う運用も想定されています。
web以外のプロファイル：headless・ACP・SDK
`dsh --help` には出てきませんが、公式ドキュメントとソースを見ると `--profile` に指定できる組み込みプロファイルとして `headless`（1タスクを実行して結果を返し終了する）、`acp`（Agent Client Protocolのstdioサーバーとして振る舞う）、`sdk` / `sdk-minimal`（SDK向けJSON-RPCサーバー）が用意されています。実際に `dsh --profile headless --help` `dsh --profile acp --help` `dsh --profile sdk --help` を叩くと、それぞれ専用のヘルプ文言が返り、`tui` のような未作成エラーにはなりませんでした。つまりこの4つは `web` と同じく最初から使える“標準プロファイル”という位置づけです。
ACPは弊ブログで以前取り上げたAgent Client Protocol（https://agentclientprotocol.com/ 相当のオープン仕様）そのもので、ZedのようなACP対応エディタから `dsh --profile acp` を直接呼び出せることを意味します。DeepSeek Harnessは独自プロトコルに閉じず、業界横断の共通規格に乗る形でエディタ統合を提供している、という位置づけが確認できました。
実際に `dsh --profile headless "こんにちは、自己紹介してください"` を実行してみたところ、`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` という具体的なエラーメッセージが返ってきました。この検証環境にはDeepSeek公式APIキーを用意していないため、実際の応答内容までは確認できていませんが、認証情報が無い場合の挙動と、必要な環境変数名（`DEEPSEEK_API_KEY`）、Web UIの「Models」ページからも設定できることは実機で確認できました。
まとめ
実際に動かしてみた範囲では、DeepSeek Harnessは単なる「DeepSeek公式のチャットCLI」ではなく、Cordisという外部の汎用プラグイン基盤の上に、Web UI・headless実行・ACP・SDK向けサーバーという複数の入口を同じプラグイン構成から生成する、やや珍しい設計のエージェント基盤でした。`--dump-default-config` で構成がそのまま覗ける透明さや、Web UIのトークン認証、エラーメッセージの丁寧さなど、developer preview を名乗る割には作り込みが感じられます。
一方で公開から1か月強とまだ新しく、破壊的変更が続くこと、実際の対話にはDeepSeek公式APIキー（またはOpenAI互換プロバイダーの個別設定）が前提になることは注意が必要です。プラグインアーキテクチャに興味がある人や、複数のCLIエージェントを比較検討している人にとっては、`npx @deepseek-ai/dsh web` の1コマンドで構成だけでも覗いてみる価値があるツールだと感じました。
参考リンク
- DeepSeek Harness 公式リポジトリ（README・ライセンス・ソースコード）
- https://github.com/deepseek-ai/deepseek-harness
- 公式ドキュメント
- https://deepseek-harness.github.io/deepseek-harness/
- プロバイダーガイド（llm-deepseek / llm-pi-aiの説明）
- https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/user/guide/providers.md
- npm パッケージページ（公開履歴・バージョン）
- https://www.npmjs.com/package/@deepseek-ai/dsh
- Cordis 公式リポジトリ
- https://github.com/cordiverse/cordis
- 論文「A Programming Paradigm for Spatiotemporal Composability」（arXiv）
- https://arxiv.org/abs/2608.25512
