DeepSeek Harness とは？「すべてがプラグイン」のエージェント実行環境

DeepSeek Harness とは？

DeepSeek Harness（略して dsh）は、MIT ライセンスの DeepSeek AI 製 エージェントハーネスです。言語モデルと外界の間に位置し、ツール、セッション、サンドボックス、そしてタスクを前に進め続けるループを提供します。

DeepSeek の整理は「Agent = Model + Harness」です。モデルは推論と生成を担います。ハーネスは、その推論が実際のファイルシステムに作用し、毎回タスクを再説明しなくても継続できるようにする一切を担います。

これは DeepSeek Harness より前からあるプラグインフレームワーク Cordis 上で動作します。Cordis により、これらの部分を設定で独立して置き換えられます。この選択のコストについては後ほど触れます。

この前提を踏まえ、よくある誤解を 2 点述べます。

DeepSeek Harness は AI モデルではない

前述のとおり、モデルと実行環境は別レイヤーです。この分離により、ツールやセッション構成を変えずにプロバイダーを切り替えられます。同じ実行環境で DeepSeek、Anthropic、OpenAI、あるいは OpenAI 互換エンドポイントを使えます。

DeepSeek Harness は単なるコーディングアシスタント以上

Standard モードはコーディングアシスタント的な印象を与えますが、それは構成の一例に過ぎません。後述のとおり、Minimal や Creator モードはエージェントが使用できるものを変えます。新しい構成の構築には依然としてエンジニアリング作業が必要で、開発者は各部品にアクセスできます。

Cordis が DeepSeek Harness のプラグインをどう編成するか

前述のとおり、Cordis は DeepSeek Harness の下層にあるプラグインフレームワークです。各部が特定プロバイダーのコードに縛られずにサービスを要求できるようにします。

Cordis は Koishi チャットボットのエコシステムから生まれ、Shigma として知られる開発者が構築しました。DeepSeek はそれをベンダリングし拡張しています。設計は A Programming Paradigm for Spatiotemporal Composability という論文で説明されています。

この基礎から、プロジェクトの主要スローガンと Cordis の 2 つの用語が導かれます。名称は学術的ですが、挙動は比較的単純です。

「すべてがプラグイン」

DeepSeek のアーキテクチャドキュメントによれば、dshは他のプラグインの横にプラグインをマウントして拡張します。モデルアダプタ、ツール、セッション、サンドボックス、ストレージ、スケジューリング、エージェントループ、UI はすべてプラグインです。

文字どおりに受け取ると、このスローガンは誇張です。プラグインのさらに下には Cordis が存在します。Cordis はプラグインを読み込み・削除し、それらの必要条件を確認し、相互に通信するイベントを実行します。Cordis は必須であり、任意の一部品ではありません。

空間的合成性がプラグインの依存関係を管理

プラグインは、手書きの起動手順を要せずに必要なサービスを宣言します。必要なサービスが存在すると有効化され、必須サービスが消えると無効化されます。依存関係が、いつ実行できるかを決めます。

DeepSeek はこれを空間的合成性と呼びます。依存関係が Cordis にコンポーネントの位置づけを伝えるため、開発者は起動順序を手で並べる必要がありません。

時間的合成性がプラグインの効果を巻き戻す

Cordis は、イベントリスナー、プロンプトセクション、ツールスキーマなどの登録も追跡します。プラグインを削除すると、それらの効果も削除され、孤立したリスナーが残りません。これはシェルコマンドのような外部アクションを取り消すものではありません。可逆性は Cordis が追跡する効果にのみ適用されます。

DeepSeek Harness のアーキテクチャ：実行環境はどう組み上がるか

稼働中のインスタンスは、一定の順序で読み込まれた設定から構築されるプラグインツリーです。どの構成要素が有効かは、その設定で決まります。

Cordis は交換可能な実行環境プラグインをすべて接続します。画像：筆者作成。

Cordis のサービスがプラグイン同士を見つけさせる

Cordis は共有のサービスディレクトリを提供します。プラグインは ctx.tools、ctx.llm、ctx.sessions のような安定したキーを用い、特定プロバイダーのコードをインポートしません。ctx.llm を呼ぶツールは、その背後にどのモデルアダプタがあるかを知る必要がありません。

エージェントプリセットと実行プロファイルが異なる層を制御

すべてが交換可能であっても、ある実行で何をマウントするかは決めねばなりません。DeepSeek Harness は、混同しやすい 2 層でこれに答えます。

要点：プロファイルはプログラムの起動方法を、プリセットはエージェントができることを制御します。Web アプリだけを使う場合は、次の 2 節は読み飛ばして構いません。

実行プロファイル

実行プロファイル（web、headless、sdk、sdk-minimal、acp がテンプレートとして同梱）は、アプリの起動方法と、起動時に積み上げる Cordis プラグインの束を決定します。多くの読者は dsh web などのコマンドを実行する以外、この層に触れることはないでしょう。

エージェントプリセット

エージェントプリセット（Standard、PTC、Minimal、Creator）は、アクティブなセッションが使えるものを決めます。パッチファイルで Harness のソースに触れずにプリセットを変更できます。

エージェントループはターン、ステップ、ツール呼び出しを調整

DeepSeek はステップとターンを区別します。ステップは 1 回のモデル要求とそのツール呼び出しから成ります。ターンは 0 個以上のステップで、最初の入力が確保された時に開き、未処理がなくなると閉じます。多くのターンは、エージェントが回答できる前に複数のステップを実行しますが、拒否された入力はステップを消費せずにターンを閉じます。

1 つのターンに複数のステップが含まれ得ます。画像：筆者作成。

セッションは追記専用のイベントログを使用

ここが最重要だと考えます。セッションは追記専用の型付きイベントログであり、チャットメッセージ配列ではありません。Harness はそのログからモデルの履歴を構築し、セッションのドキュメントでは、モデルに送られるものはすべてログから再現可能である必要があると定めています。

再開、分岐、検索、再生、Trajectory ビューはすべて、そのイベントストリームの上に築かれています。

履歴の再導出は決定的な再実行ではありません。モデル出力や外部状態は異なり得ますが、ログは起きたことの検査可能な記録を提供します。

セッション履歴は追記専用ログです。画像：筆者作成。

DeepSeek Harness におけるツールとサンドボックスの制御

モデルはツールを名前で要求できますが、直接は実行できません。要求とファイルシステム変更の間には、2 つの独立した制御が挟まります。

ツール実行パイプライン

呼び出しはポリシーチェック、実行、結果処理を通過します。ツールを選ぶのはモデルですが、実行の可否と方法を決めるのは実行環境です。

ツールの実行方法を決めるのは実行環境です。画像：筆者作成。

サンドボックス化と承認の違い

• 承認は、ユーザーがアクションを確認すべきかどうかを問います。
• サンドボックス化は、どこでどのように実行されるかを制限します。

DeepSeek はこれらを分離していますが、権限プリセットは両方の制御を束ねます。これは、コンテナランタイムがプロセス権限と実行境界を分けるのに似ています。

先に注意喚起しておきます（制限事項の節で再訪）：システムプロンプトでモデルに「ファイルを読み取りのみ」と伝えても、それはモデルが従うかもしれない提案に過ぎず、OS レベルのサンドボックス制限のような強制境界ではありません。

DeepSeek Harness のモード：Standard、PTC、Minimal、Creator

DeepSeek Harness は 4 つのモードを提供します。どれか 1 つが上位というわけではありません。「このセッションに実行環境をどこまで公開するか」への 4 つの解であり、適切な選択はタスク次第です。アーキテクチャの節で示したように、各モードはエージェントが利用できるツール群を切り替えます。

4 つのモードは 1 つの実行基盤を共有します。画像：筆者作成。

Standard モード

汎用のベースライン：

• ファイル編集
• シェルアクセス
• ファイルとウェブ検索
• Skills
• 計画立案
• ゴール
• サブエージェント
• ワークフロー

通常のリポジトリ作業なら、まずはここから始めます。

PTC モード

PTC モードは Standard のツール群をほぼ維持しつつ、モデルがそれに到達する方法を変えます。（バージョン 0.1.2 以降、Web の PTC モードは汎用の workflow ツールを既定では公開しません。）

複数のモデルステップにまたがって個別ツールを要求する代わりに、モデルは生成された SDK に対してプログラムを書きます。そのプログラムは run_code を通じて複数のツールを呼び出せます。各呼び出しは同じポリシーチェックを通過するため、PTC はモデルの計画表現を変えるだけで、許可範囲自体は変えません。

製品ページは依然として「Code モード」という表記を使いますが、新しい公式リリースでは名称を PTC モードに改めつつ、既存の会話記録はそのまま読めるようにしています。本記事では一貫して PTC モードと呼びます。略称の意味は FAQ で触れます。

Minimal モード

Minimal モードは環境を 2 つのツールにまで絞ります：永続シェルと文字列置換型のファイルエディタ。DeepSeek はこれをモデルのベンチマークに使います。テスト結果はモデルの重みだけでなく、ハーネスにも一部依存するためです。

Creator モード

Creator モードは、開発者が実行環境を検査し、Cordis プラグインをメモリ上でテストできるようにします。これはプリセットを構築するためのもので、「自己改善」と呼べるような深い意味は持ちません。

DeepSeek Harness を他のエージェントフレームワークと分けるもの

DeepSeek Harness は、多くのエージェントフレームワークと異なり、実行環境の下層部分を置き換え可能にしています。アーキテクチャの節に含めようかとも思いましたが、この違いは見落としがちです。Cordis は 1 つのプラグインシステムでそれらの変更を扱います。

呼び出せるツールだけでなく、エージェントの動作様式自体を変えられます。イベントログにより、実行結果をチャットの書き起こしではなく、開発者が検査できるランとして残せます。Minimal と Creator の各モードにより、実行環境を両極からテストできます。

DeepSeek Harness vs. Claude Code、Codex、OpenCode

機能のチェックリストでは本質を外します。どの競合も拡張をサポートしています。重要なのは、開発者がどの部分を変更できるかです。この違いは小さく見えて、実は大きいものです。Harness と Claude Code の比較記事では、両者で同じモデルを使い、セットアップ、ログ、コストを扱っています。

DeepSeek Harness と Claude Code の比較

Claude Code はプロジェクト指示、Skills、フック、MCP、サブエージェント、Agent SDK をサポートし、組み込みのループは固定です。DeepSeek Harness は、設定を通じてループ、モデルアダプタ、ストレージ層を置き換えられます。

DeepSeek Harness と Codex の比較

Codex は CLI と App Server もオープンソースであるため、より丁寧な比較が必要です。Codex はドキュメント化されたエントリポイントを通じて拡張するエージェントハーネスを提供します。DeepSeek Harness は実行環境そのものの変更を中心に据えています。制御レベルが異なります。

DeepSeek Harness と OpenCode の比較

OpenCode はすでにオープンソースで、複数のモデルプロバイダーに対応し、クライアント・サーバー型のアーキテクチャを採用しています。ツール、権限、セッション、プロバイダーを構成できます。OpenCode のプラグインは固定のサーバー中核を拡張する一方、DeepSeek はループとセッションストアも置き換え可能にしています。

DeepSeek Harness を使うべきとき

実行環境の部品を置き換えること自体は目的ではありません。追加の制御は、既に抱えている課題の解決に資する場合にのみ意味を持ちます。

• 実行環境そのものがプロジェクトの一部である場合。 モデルアダプタ、エージェントループ、ストレージ、セッション動作を手直ししているなら、単にエージェントの上に構築するよりも適合します。
• 管理された環境でモデルを比較する場合。 同じ実行環境を使うと、モデルを入れ替えてもテストの固定部分が増えます（ただし、ツール使用や推論スタイルはモデルごとに異なり得ます）。
• 複雑なランのデバッグが重要な場合。 セッションのイベントログと Trajectory ビューにより、モデルが何を見てどのツールが走ったかを復元しやすくなります。
• エージェント内部のテストが目的の場合。 Creator モードと Cordis は、アプリコードの生成だけを必要とする人というより、エージェントの構成を研究する開発者向けです。

単純なモデル呼び出しや、内部に触れずに使える出来合いのコーディングエージェントを望むチームには不要かもしれません。置き換える部品が増えるほど工数も増えるため、その制御が実際の課題解決に資する場合にだけ価値があります。

DeepSeek Harness の制約：開発者プレビューとセキュリティリスク

以上のアーキテクチャは、現時点の弱点を明確に把握してこそ意味があります。

依然として開発者向けプレビュー

DeepSeek のリポジトリは、破壊的変更があるとはっきり述べています。これは既に起きています：Code から PTC への改名では、セッション API の変更や任意の SQLite ストレージオプションの削除が伴いました。バージョンを固定してください。固定せずに安定を期待するのは計画とは言えません。

制御が増えれば複雑さも増える

実行環境の置換可能範囲を広げると、開発者が学ぶべきことも増えます：プラグインの依存関係、設定、プロバイダーごとの差異、バージョン互換性。これは利便性と制御の常なるトレードオフです。

DeepSeek Harness はローカル動作？

DeepSeek Harness は既定で、セッション内容、ツールの記録、設定をローカルに保存すると データ処理に関する記載で述べています。設定やプロジェクト一覧に関する匿名レポートは無効化できます。

ただし、外部のモデルプロバイダー、ウェブツール、MCP サーバー、プラグインは、それぞれのポリシーに基づき、マシン外へデータを送る可能性があります。「ローカルファースト」は接続するすべてのサービスを包含しません。

エージェントの実行にはセキュリティリスクが伴う

ファイルを編集し、コマンドを実行し、サードパーティプラグインを読み込める実行環境は、実害を引き起こし得ます。DeepSeek の安全性に関する注意では、プロジェクトがセキュリティ監査を受けていないと明記されています。サンドボックス化、承認、権限制御はリスクを下げますが、完全な隔離を保証するものではありません。

自分のマシンで動かすことはリスクを除去しません。信頼できない作業には限定的な権限と使い捨て環境を用い、隠れた指示を含む可能性のあるコンテンツには注意してください。

エージェントの挙動はモデル以上の要因に依存する理由

エージェントの挙動はモデルだけでなく、実行環境にも依存します。これは「Agent = Model + Harness」に立ち返る話であり、同じ分離は DeepSeek 以外のLLM エージェントにも当てはまります。

モデルが生成できるものは重みに依存します。エージェントが実際に何をするかは、モデルに届くコンテキスト、許可されたアクション、実行の拘束の強さにも依存します。これらは重みには含まれません。

DeepSeek Harness は、その周辺層を開発者が置き換え可能な名付けられた部品に分割することで示します。Minimal モードは、これが DeepSeek を超えて重要である理由を示します：ベンチマークのスコアは、モデルだけでなく、テストに使われるハーネスも一部反映します。ハーネスはモデルを賢くするものではありません。モデルが働く環境設定を変えるのです。

結論

冒頭の一文が肝要です：推論するのはモデルですが、その推論が届き、実行できる範囲を決めるのは実行環境です。DeepSeek Harness は、モデルアダプタやツールからセッションストア、エージェントループに至るまで、その実行環境を編集可能にします。

その制御はコストも生みます。実行環境を多く置き換えるほど、セットアップ、バージョン変更、セキュリティ境界の責任が増します。シェルアクセスを持つ開発者プレビューは、入れて放置してよい類ではありません。

私見は単純です：実行環境そのものが作業の一部であるときに DeepSeek Harness を使ってください。リポジトリの編集だけが必要なら、既製のコーディングエージェントの方が負担が少ないでしょう。

セットアップはDeepSeek Harness チュートリアルで解説しています。Claude Code の代替ガイドでは他のコーディングエージェントも比較し、Introduction to AI Agents では本記事が前提とする基本を学べます。