DeepSeek Harnessとは？アーキテクチャや使い方、他ハーネスとの違いを徹底解説

DeepSeek Harness（dsh）は、DeepSeekが2026年8月13日にMITライセンスの開発者プレビューとして公開したオープンソースのエージェントランタイムです。
コアメッセージは「Everything is a plugin」——モデル、ツール、セッション、サンドボックス、UIまで、エージェントを構成するあらゆる要素をプラグインとして差し替え可能にした設計が特徴です。

本記事では、アーキテクチャの中身、起動方法と使い方、対応モデルとReasoning Effort、Claude Code・OpenAI Codexなど他ハーネスとの違い、v0.1の制約と実務導入時の判断軸までを、2026年8月時点の一次情報で体系的に解説します。

DeepSeek Harnessとは？モデル・ツール・UIまで全部プラグインのエージェント基盤

DeepSeek Harness（略称dsh）とは、DeepSeekが2026年8月13日にMITライセンスの開発者プレビューとして公開した、オープンソースのAIエージェントランタイムです。

公式リポジトリはgithub.com/deepseek-ai/deepseek-harnessで提供されており、リリース当日時点でGitHubスター27,500・フォーク2,000（VentureBeat報告）から、公開翌日の2026年8月14日の画像撮影時点で58,000スター・5,000フォーク（Contributors 19）まで一気に伸びており、開発者コミュニティの関心が短期間で集中していることが分かります。

DeepSeek Harness 公式リポジトリのメタ情報。2026年8月14日の画像撮影時点でStars 58k・Forks 5k・Discussions 688・Contributors 19。数値はその後も伸び続けている（出典：deepseek-ai/deepseek-harness）

DSHのコアメッセージは「Everything is a plugin」で、エージェントを構成するあらゆる要素をプラグインとして差し替え可能にした設計が他の統合型コーディングエージェントとの根本的な違いになっています。

同社は同日発表のDeepSeek-V4-Pro-0813と組み合わせて、モデル層からエージェント基盤層まで垂直に押さえる戦略を明確に打ち出しました。本記事の各セクションで扱う論点は、この「モデル×ハーネス」時代における読者の判断材料として整理していきます。

DeepSeek Harnessのアーキテクチャ

ここからは、「Everything is a plugin」を実現しているDSHの内部構造を、Cordisメタフレームワーク・主要なコアプラグイン・4つの観点・append-only session logの4つの角度から整理します。

DSHは特権的な「コア」を持たず、すべての機能が同格のプラグインとしてコンテキストに乗る設計になっています。この設計思想が、後述する「モデル中立性」や「実行環境の差し替え可能性」の根源です。

Cordisメタフレームワーク——プラグイン依存関係を管理するカーネル

DSHの土台となっているのは、Cordiverseで開発されているCordisメタフレームワークです。DSHはこれをアップストリームからベンダー化・拡張して同梱しています（Vendored Packages）。基盤の考え方は「A Programming Paradigm for Spatiotemporal Composability」にまとめられています。

Cordisは、各プラグインが「サービス・型付きイベント・可逆エフェクト」を共有コンテキストに寄せ合う構造を提供し、公式ドキュメントは**「there is no privileged core to patch」**（パッチすべき特権的なコアは存在しない）と明記しています。

この設計の実務的な意味は、プラグインの追加・置換・削除を「本体を書き換えずに設定だけで実現できる」点にあります。

一般的なフレームワークでは、モデルアダプタやツール定義を差し替えるにも本体コードへの介入が必要になりますが、Cordisではプロファイル（プラグイン束の設定）を切り替えるだけで実行環境の姿を丸ごと変えられます。

主要なコアプラグイン——Session・Tools・Agent Loop・LLM等

DSHが提供している主要なコアパッケージは、公式アーキテクチャドキュメントで以下のように例示されています（他にも複数のパッケージが存在し、以下は例示リストです）。

これらのコアパッケージが揃うことで、DSHはエージェントとして動作します。主要機能は設定から差し替え可能で、Anthropic発のMCP（Model Context Protocol）互換のツールプラグインを差せばMCPエコシステム全体を、独自のAgent Loopを実装すれば自社ワークフローを、それぞれ持ち込めます。

DSHのSettings画面。Plugin listタブでは実装済みプラグイン159本が一覧表示され、include・timer・llm・session・typert-registry・api-gateway等をUIから直接Enabled/Disabled切り替えできる。モデルアダプタもツールもUIも同じ仕組みで管理される（出典：DeepSeek Harness）

Plugin listに並ぶ「llm」「session」「typert-registry」といった名前が、DSHを構成するプラグインの実装名です。「特権的なコアはない」という設計思想が、単なるドキュメント上の理念ではなく、Settingsから触れるオブジェクトとして実装されていることが分かります。

4つの観点——Model・Plugin System・Capability・Runtime Mode

公式LPの説明をもとに、本記事ではDSHの構成要素を4つの観点で整理します。

• モデル
  エージェントの推論を担う中核。DeepSeek V4-Pro/Flashを含む複数モデルを差し替えられる
  
  

• プラグインシステム
  Cordisカーネルが依存関係を管理し、プラグイン間の呼び出しを解決する
  
  

• キャパビリティ
  モデル、ツール、スキル、ストレージ、セッション、UIといった「エージェントができること」の集合
  
  

• ランタイムモード
  Standard・Code・Minimal・Creatorの4種類のプリセットで、用途別に有効化するキャパビリティを束ねる

4つの観点のうち、特に注目したいのがランタイムモードです。DeepSeekが同時発表したV4-Pro-0813のCode Agentベンチマークは「Harness minimal mode」で測定されており、モード切替は単なるUIプリセットではなく実行時の挙動そのものを変える運用ノブとして機能します。

append-only session log——モデルが見たものはすべて残る

DSHの再現性を担保しているのが、モデルが見る情報と主要な実行イベントを追記のみで記録するセッションログです。

公式ドキュメントは**「model-visible means logged」**（モデルが見たものはログにある）という不変条件を掲げており、システムプロンプト・推論・ツール呼び出しと結果・サブエージェントのスケジューリング等が後から再構築可能な形で残ります（Agentイベントの一部はライブイベント扱い）。

この設計は、fork・resume・トランスクリプト機能の実装基盤にもなっています。

保存済みセッションを再開する、途中から分岐して別モデルで実行する、監査用にトランスクリプトを吐き出す——こうした運用の基盤を、セッションログと永続化プラグインが提供します。

DSHのTrajectoryビュー。単一セッションログから、システムプロンプト・推論・ツール呼び出し・サブエージェント起動を含む完全な実行を再構築できる。右上には"Completed"ステータスと使用したツール一覧が表示され、下部の"Message the agent"欄から同セッションを続行できる（出典：DeepSeek Harness）

完了済みターンの安定した境界から子セッションを作れることが、公式のLive Session Fork APIに明記されています。必要に応じて、分岐後のセッションでモデルを切り替えて続きを試すこともできます。永続化したログは、CIで失敗した実行経路を開発者マシンで調査する材料にもできます。

DeepSeek Harnessの起動方法と使い方

ここからは、実際にDSHをローカルで動かすまでの手順を、npx経由の最短ルートとソースからのビルドの2つに分けて解説します。開発者プレビュー段階なので、まずは触ってみて挙動を掴むフェーズと割り切って進めるのが現実的です。

前提条件——Node.js 22.19+ もしくは 24+

DSHを動かすにはNode.jsの 22.19以上または 24系が必要です。npm経由での起動だけを試すならNode.jsとnpxがあれば済みますが、ソースからビルドする場合は追加でpnpmも必要になります。

手元の環境で試すなら、Node.jsのバージョンだけ先に確認しておくと詰まりにくくなります。

最短ルート：npx で Web UI を起動する

もっともシンプルな起動方法は、npm経由のワンライナーです。

npx @deepseek-ai/dsh web

このコマンドを実行すると、DSHのWeb UIがhttp://127.0.0.1:3080で立ち上がります。ブラウザからアクセスして、以下の初期設定を行えばそのまま使い始められます。

• Settings → Models でモデルAPIキー（DeepSeek/Anthropic/OpenAI等）を登録
• Choose workspace でエージェントの作業対象ディレクトリを指定
• セッションを開始し、プロンプトを送信

実務で使い始める前段として、npxで起動して手触りを確認できる設計になっているのは大きな利点です。

開発者向け：ソースからのビルドとプロファイル管理

プラグイン開発や独自プロファイル作成を行う場合は、リポジトリを直接クローンしてビルドします。

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

DSHは pnpm workspace として構成されており、apps/cli（CLIランチャー）とapps/web（Web UI）が独立したパッケージになっています。

dshコマンド自体はプロファイルのランチャーとして機能し、$DSH_HOME/profiles/<name>配下の順序付きプラグインバンドルをブートします。プロファイルごとに有効化するプラグインを切り替えることで、同じインストールから複数の実行環境を使い分けられます。

ヘッドレス実行——バッチ運用や CI 組み込み

Web UIを介さずに、CLIから直接タスクを実行するヘッドレスモードも用意されています。

dsh --profile headless "コマンド"

この形式であれば、CIパイプラインやバッチスクリプトからDSHを呼び出し、コード生成・リファクタリング・テスト生成といった処理を自動化できます。

ヘッドレスモードは監査ログの取り出しやfork/resumeとも組み合わせやすく、Session プラグインの append-only ログを CI アーティファクトとして保存する運用も現実的です。

DeepSeek Harnessが対応するモデルとReasoning Effort

DSHの最大の差別化ポイントは、「モデル中立ランタイム」として複数ベンダーのモデルを差し替え可能なことです。ここではその実装の中身と、同時発表されたDeepSeek V4-Pro-0813が持ち込んだReasoning Effort制御の使い方を整理します。

モデル中立ランタイム——DeepSeek専用ではない

DSHは名前にDeepSeekを冠していますが、VentureBeatの分析記事が指摘するとおり、「DeepSeek推論に縛られたハーネスではない」——モデルアダプタを差し替えれば、セッション・ツール・承認・UIの各層はそのまま流用できます。

現時点で、Providers Guideが案内する対応プロバイダと、DSHのモデルカタログで確認できる主なモデル例は以下のとおりです。

• DeepSeek
  DSH DeepSeekアダプタREADMEではV4-Pro／V4-Flashの既定登録が確認できます
  
  

• Anthropic
  Claudeシリーズ
  
  

• OpenAI
  GPTシリーズ
  
  

• カタログプロバイダ
  Bedrock・Vertex・Azureなど、各クラウドのネイティブ認証を使ってモデルカタログを扱うプロバイダ
  
  

• OpenAI互換エンドポイント
  自社推論サーバやローカルLLMランナー等、OpenAI互換APIを提供する任意のエンドポイント

複数系統のプロバイダを1つのハーネスで扱える設計は、マルチモデル運用や自社モデルの組み込みを前提とするチームには実務上の使いやすさに直結します。Codex CLI 側もカスタムモデルプロバイダ設定を公式サポートしているため「DSHだけが対応する」と誤解しないよう注意が必要ですが、標準機能としてカタログプロバイダとOpenAI互換の両方を最初から抱えている点はDSHの実装上の強みです。

Reasoning Effort——DSHアダプタは Off / High / Max の3段階

DSH の DeepSeek アダプタは、推論の深さを明示的にコントロールする Reasoning Effort をサポートします。DSHのDeepSeek LLMアダプタREADMEでは、以下の3段階が公開されています（DeepSeek API本体は none / low / high / max の4段階を案内しており、DSHアダプタ側はそのサブセットの扱いです）。

この3段階制御が実務的に効いてくるのは、エージェントが1つのタスク内で複数のステップを実行する場面です。

コードエージェントであれば、ファイル探索や簡単なツール呼び出しは off で走らせ、バグ診断や多段階の設計判断に入ったところで max に切り替える、といった運用でトークン消費を最適化できます。

同時発表V4-Pro-0813とAPI料金改定

DSH v0.1と同日発表されたV4-Pro-0813は、Agent性能を強化した公式版としてリリースされ、Responses APIとCodex統合をネイティブサポートするようになりました。周辺の動きとして、エージェントプラグインの標準化を目指すAgent Plugins Specification v1.0.0（Working Draft）も提示されており、ハーネス層の競争軸が急速に整備されつつあります。

一方で、DeepSeek APIは2026年8月16日 16:00 UTCから Peak/Off-peak二段料金制に移行し、Reutersによればモデル・時間帯・トークン種別によっては現行の50〜1,100%の値上げになります。

DSH経由でDeepSeekモデルを使う場合、Off-peak時間帯（01:00-04:00・06:00-10:00 UTC以外）に走らせるだけでコストが半減する構造になった点は押さえておくべきです。詳細は別記事「DeepSeek V4-Flash」で扱います。

他ハーネス（Claude Code / OpenAI Codex）との違い

DSHの位置づけを実務目線で見るには、Anthropic Claude CodeとOpenAI Codexとの機能差を並べて理解するのが早道です。ここではVentureBeatが公開した比較をベースに、実務判断で重要な軸に絞って整理します。

機能比較——基本のエージェント能力は3者とも共通

まず全体像として、コーディングエージェントとしての基本能力は3者に大きな差はありません。以下の表で主要機能を比較しました。

この比較から浮かび上がるのは、基本能力は同格でも、周辺エコシステムと本番運用向け機能の成熟度で明確な差がついているという現実です。

Claude CodeとCodexは既にGitHub PR自動化やホスト型バックグラウンド実行を含む「開発チーム全体の日常運用基盤」として使える段階にあり、DSHはまだ「エージェントのコアループを持ち出せる基盤」の段階にあります。

DSHが優位に立つポイント——モデル中立性と全部差替え可能な拡張性

とはいえ、DSHが競合に対して明確に優位な軸もあります。

• モデル中立性
  Claude CodeがClaude系中心、CodexがOpenAI中心の設計であるのに対し、DSHは最初から複数ベンダーのモデルをフラットに扱える設計。マルチモデル運用中のチームや、自社モデルの組み込みを想定する企業には第一候補になります
  
  

• 全部差替え可能な拡張性
  Session、Agent Loop、Tools、UIまですべてがプラグインで置換可能。既存の統合型プロダクトでは実現しにくい「独自ワークフロー・独自承認フロー・独自監査ログ」の実装が現実的
  
  

• MITライセンスによるOSS提供
  本体はMITライセンス、依存パッケージはThird-Party Noticesで開示されている。著作権表示・許諾表示の保持と第三者依存関係のライセンス条件を確認したうえで、社内基盤への組み込みや改変が可能

実務の選定軸としては、**「モデルとハーネスの両方を自社でコントロールしたいか、それとも成熟したベンダー提供の統合体験を優先するか」**が最大の分岐点になります。

現時点で見劣りするポイント——本番運用向け機能の未文書化

一方、Claude Code・Codexに追いついていない領域も率直に整理しておきます。

• ホスト型バックグラウンドエージェントに相当するサービスが公式には文書化されていない。Claude Code/Codexが提供する「クラウド側で長時間タスクを走らせる仕組み」を必要とする場合、DSH単体では代替が難しい
• GitHub PR ネイティブ統合が公式には文書化されていない。issue-to-PR や自動レビューを標準機能として使うなら、現時点ではClaude Code/Codexに分がある
• 開発者プレビュー段階で、破壊的変更が予告されている（後述）

Claude Code・Codexは既に開発チーム全体の日常運用に組み込まれており、DSHは「コア機能はあるが周辺運用機能はこれから」の段階と理解するのが正確です。

v0.1の制約と実務での導入判断

DSHは技術的には強力ですが、開発者プレビュー段階特有の制約があります。ここでは、本番環境への導入を検討するチームが押さえるべき論点を、公式が明示している注意事項と第三者観察の両面から整理します。

破壊的変更が予告されている開発者プレビュー段階

まず最も重要なのが、公式リポジトリのREADMEに明記された注意書きです。

DSH v0.1は「THERE WILL BE COMPATIBILITY-BREAKING CHANGES」と大文字で警告されており、APIやプラグインインターフェースは今後のバージョンで変わる前提で捉える必要があります。

この段階で本番環境の主力基盤として採用するのは、明らかにリスクが高い判断です。

現実的な運用としては、依存バージョンをリポジトリのコミットハッシュで固定し、DSHの変更差分を自分たちで追跡できる体制がある場合に限って導入を検討する、というスタンスになります。

未文書化機能——ホスト型バックグラウンドエージェントとGitHub PRネイティブ統合

本節の比較表でも触れたとおり、DSHには本番運用で欲しくなる以下の機能が現時点で公式ドキュメント化されていません。

特にGitHub連携は、Claude Code/Codexが「開発チーム全体の日常運用」として使える水準まで来ているのに対し、DSHはまだ「エージェントのコアを持ち出せる基盤」の段階です。

実務での導入判断——3つのケース別推奨

ここまでの整理を踏まえ、AI総合研究所のAIエージェント導入支援経験から、ケース別の推奨ラインを示します。

• 自社エージェント基盤をゼロから設計中のチーム
  DSHは第一候補。プラグイン設計の柔軟性・MITライセンスの自由度・モデル中立性が、独自要件を持つ内製基盤の設計自由度を最大化する
  
  

• 既存Claude Code/Codexで運用中のチーム
  併走試験フェーズが現実的。まずヘッドレスモードでV4-Pro-0813をベンチマーク的に使いつつ、GitHub連携やホスト型実行が公式提供・文書化されるまで併走試験を続ける判断が安全
  
  

• マルチモデル運用中の企業（DeepSeek・Anthropic・OpenAIを併用）
  DSHのモデル中立性が最も効くケース。統合UIとセッションログを1つに寄せられるメリットが大きく、既存ハーネスからの部分置換を検討する価値がある

共通して重要なのは、「モデル層とハーネス層を分けて考える」視点です。V4-Pro-0813を使うためにDSHを使う必要はなく（Claude Code/Codexからも呼べる）、DSHを使うためにDeepSeekモデルを使う必要もありません。

自社の要件が「モデル」側にあるのか「ハーネス」側にあるのかを切り分けて考えると、DSHが解いてくれる問題と、まだ解けていない問題の境界が見えやすくなります。

エージェントハーネス選定と業務組み込みで詰まる論点を、実装事例から逆算して整理する

DSH・Claude Code・Codexなど複数のエージェントランタイムを検討する現場では、DSH v0.1の破壊的変更前提でどこまで自社基盤に組み込むか、ホスト型バックグラウンドエージェント・GitHub PRネイティブ統合の未文書化領域をどう代替するか、モデル層（V4-Pro・Fable 5・GPT-5.5）とハーネス層（DSH・Claude Code・Codex）をどう組み合わせるか、既存Claude Code／Codex運用中のチームでDSHをどのタスク粒度で併走試験するかといった、公式ドキュメントだけでは決めきれない論点が並びます。

ハーネス選定・モデル選定・独自プラグイン設計・監査ログ／セッションログ運用まで含めてエージェント基盤の実装可能性を棚卸ししたいなら、単体機能の解説記事ではなく、実装事例と組み合わせて話せる相手と一度整理するのが早道です。

AI Agent Hubは、DSHのようなOSSランタイムを含む複数ハーネス・複数モデルを業務Agent単位で統合管理するエンタープライズAI基盤で、ハーネス選定・モデル選定・独自プラグイン設計・監査ログ運用のいずれの入口からでも、実装から逆算した論点整理をご相談いただけます。

ハーネス選定の論点を実装事例から逆算

DSH・Claude Code・Codexと複数モデルの組み合わせ

DSH導入は、v0.1の破壊的変更対応・ホスト型バックグラウンド実行の代替・モデル層とハーネス層の分離設計・既存Claude Code／Codexとの併走試験が絡み合います。AI Agent Hubのサービスページで、複数ハーネス・複数モデルを業務プロセスに載せる実装例をご確認ください。

▶ ▶ AI Agent Hubの詳細を見る

まとめ

本記事では、2026年8月13日にMITライセンスで公開されたDeepSeek Harness v0.1について、アーキテクチャ・起動方法・対応モデル・Claude Code/Codexとの違い・v0.1の制約と導入判断までを2026年8月時点の一次情報で整理してきました。

2026年時点で押さえておくべきポイントは次の3つです。

• 「Everything is a plugin」設計のOSSエージェントランタイムで、DeepSeekがハーネス層にも競争軸を広げた戦略製品、npx @deepseek-ai/dsh webの1コマンドで即起動
• Anthropic・OpenAI・OpenAI互換を差し替えられるモデル中立ランタイムが差別化軸、基本能力はClaude Code・Codexと同格でホスト型BG実行・GitHub PR native統合は未文書化
• 「モデル層とハーネス層を分けて考える」ことが導入判断の原則、ゼロベース内製基盤には第一候補、既存ユーザーは併走試験フェーズが現実的
  
  

「モデル×ハーネス」という2軸で競争が展開される時代に、DSHは「モデル中立ランタイム」という第三の選択肢を明確に立ち上げました。まずはnpx @deepseek-ai/dsh webで手元で動かし、自社の要件に合うかを短いサイクルで検証するところから始めるのが、この段階では最も現実的な進め方です。