DeepSeek Harness は何を変えたか？AI Agent Framework から次世代 Coding Agent インフラへ

先に要点

層	一言	あなたが保守するもの
Agent Framework	アプリコードで prompt・ツール・ステップを編成する	Python/TS の呼び出しグラフ
Agent Harness	ツール・FS・サンドボックス・ループをプラグインとして載せるランタイム	Profile / Bundle / SessionEvent
DeepSeek Harness	Cordis 上の MIT オープンソース dsh：すべてがプラグイン	ctx.* サービス + JSON ツール Schema

切り分けを覚える：Framework は chain を届け、Harness は差し替え可能なホストを届ける。モデルは変わる；seam と JSON 契約は残すべきだ。

DeepSeek Harness とは何か？

DeepSeek Harness（dsh） は、LLM をファイルシステム・ターミナル・ブラウザ・その他のコーディングツールに繋ぐオープンソースの Agent ランタイムだ。モデルの重みではなく、Coding Agent が環境の中で動き続けるためのホストである。

最初に押さえる三点：

• Everything is a Plugin：ツール、FS、サンドボックス、モデルアダプタは Cordis にマウント／アンマウントできる。
• 新 DeepSeek モデルではない：モデルは魂、harness は環境・ツール・ループを担う身体。
• Coding Agent 向け：Agent Loop、Session Log、Capability Seam が第一級の概念になる。

まだ Agent を「長い prompt」だと思っているなら、先に AI Agent とは何か でホストと契約の境界を押さえてから戻るとよい。dsh が変えるのはそのホスト側だ。

Agent Framework から Agent Harness へ

従来の Agent Framework は、しばしば一つのクラスに Agent Loop を埋め込む。ツール登録、チャット履歴、サンドボックス、再試行が同じ呼び出しグラフに固まり、差し替えコストが高い。

Harness はループ・ツール・セッションを差し替え可能なランタイム部品にする。四つの差：

• 特権カーネル vs プラグイン：コアに全部書くのではなく、能力をマウントする。
• チャット履歴 vs Session Log：モデルが見た入力をイベント列として再現できる。
• ハードコードされたサンドボックス vs Capability Seam：bash や編集器はサービス境界で差し替える。
• prompt が製品 vs 設定の合成：Profile / Bundle / 設定ツリーが製品の形になる。

フレームワークは「どう鎖を書くか」を教え、harness は「どのホストに載せるか」を教える。Coding Agent の寿命は後者に寄る。

Everything is a Plugin：Cordis 上の dsh

dsh は Cordis プラグインホスト上に載る。マウントとアンマウントは可逆だ。モデルアダプタ、ツール、FS、サンドボックスは同じ仕組みで足し引きできる。

典型的には cordis.yml（または patch）でプラグインを宣言する。製品コードを書き換えずにモデルアダプタを差し替える例：

# cordis.patch.yml — swap model + add a tool
plugins:
  - name: llm/deepseek
    config:
      model: deepseek-v4-pro
  - name: tools/my-repo-search
    config:
      root: ./src

ここが Framework との実務差だ。新ツールはフォーク全体ではなくプラグインとして載せる。製品境界は「どのプラグイン集合を Bundle するか」に移る。

Capability Seam：定義・Provider・Consumer

Capability Seam は能力の契約面だ。三役に分かれる：

1. Service Definition：名前と入出力の形（多くは JSON Schema / inputSchema）。
2. Provider：実際に bash、編集器、検索などを実装するプラグイン。
3. Consumer：Agent Loop や他プラグインが ctx.* 経由で呼ぶ側。

例：bash は「シェルを実行する」seam の Provider だ。ループは Provider の内部実装ではなく、定義されたインターフェースだけを見る。

ツールはモデル側では Function Calling の tool_calls として見え、ホスト側では検証可能な JSON 契約になる。典型的なツール Schema：

{
  "name": "str_replace_editor",
  "description": "Edit a file by exact string replacement",
  "inputSchema": {
    "type": "object",
    "properties": {
      "path": { "type": "string" },
      "old_str": { "type": "string" },
      "new_str": { "type": "string" }
    },
    "required": ["path", "old_str", "new_str"],
    "additionalProperties": false
  }
}

この境界は MCP のツール供給や API 側の Function Calling と同じ問題を解く。層の分け方は MCP Tool Schema vs Function Calling、Schema をランタイムゲートにする理由は AI はなぜ JSON Schema が必要か。

Session Log：モデルが見たものを再現する

チャット UI の吹き出しだけでは足りない。Session Log はモデルに見えた入力・tool_calls・ツール結果・エージェントイベントを時系列で残す。

デバッグの基準は「モデルは何を見たか」をログから再構成できることだ。ツール結果のイベントはだいたいこうなる：

{
  "type": "tool/result",
  "tool_call_id": "call_7f2a",
  "name": "bash",
  "ok": true,
  "content": {
    "stdout": "passed 12",
    "exit_code": 0
  },
  "ts": "2026-09-11T06:12:04.221Z"
}

ログの JSON が崩れたらローカルで 整形と構文チェック し、前回成功セッションと JSON Diff する。秘密やユーザーデータを公開サイトへ貼らない。

Profile、Bundle、ターンとステップ

ランタイムの組み立てはだいたい四層に分かれる：

• Profile：web か headless かなど、起動形態と既定能力セット。
• Bundle：プラグイン集合の積み上げ。同じコアに別 Bundle を載せて製品差を出す。
• Turn vs Step：ユーザー／エージェントのターンと、その中のツールステップを分ける。
• agent/* イベント：ループ状態を Session Log に落とす観測面。

製品差分は「別の巨大クラス」ではなく Profile + Bundle の組み合わせで表す。ループ本体は差し替え可能なまま残す。

四つの Mode：Standard / Code / Minimal / Creation

dsh は用途ごとに Mode を切り替える。名前は英語のまま覚える：

Mode は「モデルの性格」ではなく載せるプラグインと権限の束だ。本番では Minimal / Standard から始め、Creation は信頼できる環境に限る。

次世代 Coding Agent インフラとは何か

「インフラ」という言葉がここで意味するのは、次の四点だ：

• Capability Seam：能力を契約として差し替えられる。
• Fail-closed なセキュリティ：未検証のツール引数は通さない。
• JSON 契約：ツール定義・呼び出し・結果が Schema で揃う。
• 再生可能なセッション：Session Log から失敗を再現できる。

長い prompt を資産にする時代から、Schema・seam・設定ツリーを資産にする時代へ移る。構造化ワークフローへの接続は JSON Schema と Agent ワークフロー。

Framework と Harness を並べて見る

同じ「Agent を動かす」でも、保守の単位が違う：

Framework は捨てろという意味ではない。鎖の上に、差し替え可能なホスト層が必要だ、という話だ。

よくある誤り

• dsh を新モデルだと思う。 ベンチの主役はモデル、運用の主役は harness。
• ツール追加のためにリポジトリ全体をフォークする。 まずプラグインと seam を書く。
• Schema 検証を飛ばす。 inputSchema なしの tool_calls は本番事故の入口。
• Session Log を無視する。 「モデルがおかしい」の大半は、見えたコンテキストの再現不足。
• 信頼できない環境で Creation Mode を開く。 自己参照的な Cordis は権限が広い。

FAQ

Claude Code のような製品と何が違うか？

Claude Code は完成した Coding Agent 製品に近い。dsh は差し替え可能な harness／インフラ層で、同じ思想を自前ホストに落とすためのオープンソース基盤だ。

DeepSeek モデルだけでしか使えないのか？

いいえ。モデルはアダプタ経由で載せる。DeepSeek の公式デモは自社モデル向けだが、設計上 harness はモデル差し替えを前提にする。

Cordis は必須か？

上流の dsh 実装は Cordis プラグインホストに載る。思想（seam・プラグイン・セッション）は移植できるが、公式ツリーを追うなら Cordis の設定モデルを学ぶ必要がある。

JSON はどの役割か？

ツールの inputSchema、呼び出し引数、ツール結果、SessionEvent のペイロードを運ぶ。harness では prose より JSON 契約が製品境界になる。

本番で使ってよいか？

現時点は developer preview に近い。破壊的変更があり得る。内部実験やステージングから始め、seam と Schema を先に固定してから広げる。

まとめ

DeepSeek Harness が変えたのはモデルカードではなく、Coding Agent のインフラの切り方だ。ループ・ツール・セッションをプラグインと JSON 契約にし、ホストを差し替え可能にした。

今日から Schema と Capability Seam を先に書け。prompt を長くするな。モデルは変わり、harness の契約は残る。

関連記事

• AI Agent とは？Tool Calling と JSON ホストと契約の境界から押さえる
• AI はなぜ JSON Schema が必要か Structured Output と Function Calling の契約
• MCP Tool Schema vs Function Calling ツール JSON のプロトコル境界
• AI Agent が JSON Schema を必要とし始めた理由 Tool Calling から構造化ワークフローへ
• JSONSort ローカルツール箱 整形、検証、Diff
• すべての記事 JSON と AI 開発のノート

更新履歴： 2026-09-11 初回公開