DeepSeek Harnessの4つのモード：標準、コード、ミニマル、クリエイターを解説

DeepSeek Harnessには4つのランタイムモードがあります。Standard、Code、Minimal、Creatorです。これらは4つの性能レベルではなく、異なるモードを選択しても、基盤となるDeepSeekモデル自体が本質的に賢くなったり弱くなったりするわけではありません。各モードは、モデルを取り巻く環境を変更します。利用できるツール、ツールのオーケストレーション方法、Harnessが提供する支援の程度、そしてエージェントが作業を行っているのか、評価されているのか、あるいはHarness自体を変更しているのかが変わります。

違いを覚える最も簡単な方法は次のとおりです。Standardは作業を実行するためのもの、Codeは作業をオーケストレーションするためのもの、Minimalはモデルを測定するためのもの、CreatorはHarnessを変更するためのものです。この違いが重要なのは、エージェントの性能がモデルの重みだけで決まるわけではないからです。ツールの範囲、実行ループ、メモリ、権限、計画システム、その他のHarnessコンポーネントはすべて、エージェントが達成できることに影響します。

DeepSeekを別の永続的なエージェント環境と比較している場合、DeepSeekエージェント向けHermesプラグインのガイドでは、別の方向から同じ原則を示しています。エージェントレイヤーを変更することで、基盤モデルを置き換えなくても、視覚機能、メモリ、プライベートデータへのアクセスなどの機能を追加できます。

なぜDeepSeek Harnessには4つの異なるモードが必要なのか？

DeepSeek Harnessは、エージェントとはコマンドラインを接続しただけの言語モデルではない、という考えを中心に構築されています。Harnessはモデルと環境の間に位置し、モデルが何を見られるか、どのツールを利用できるか、アクションをどのように実行するか、セッションをどのように記録するか、複数のステップにわたって何が起こるかを決定します。DeepSeekはこの関係を、エージェントはモデルとHarnessから構成されるものだと要約しています。

このアーキテクチャがあるからこそ、同じ基盤モデルを使用していても、DeepSeek Harnessの4つのランタイムモードは大きく異なる動作をします。Standardは、日常的なエージェント環境を完全に利用できます。Codeはその機能を維持しながら、モデルによるツールのオーケストレーション方法を変更します。Minimalは、Harnessによる支援の大部分を意図的に取り除きます。Creatorは、ランタイム自体を調査し、作り変える機能を追加します。

したがって、これらのモードを基礎から高度へと続く段階として解釈すべきではありません。MinimalはStandardより下位ではなく、Creatorも単に強化されたStandard Modeというわけではありません。各プリセットは異なる問いに最適化されています。エージェントはどのように動作すべきか。ツールをどのように連携させるべきか。結果のうち、どの程度をモデル自体が担うのか。それとも、エージェント環境をどのように再構築すべきか。

1. 標準モード — DeepSeekの完全なエージェント環境を標準で利用

単にDeepSeekに仕事を与えて完了させたい場合、標準モードが自然な出発点です。ファイル編集、シェルアクセス、ファイル検索とウェブ検索、スキル、計画、目標、サブエージェント、ワークフローを含む、完全なコーディングエージェント環境が備わっています。次のステップをすべて手動で決める必要はなく、モデルが環境を調査し、操作し、結果を確認して、作業を続けられます。

これにより、よくあるエージェントループが生まれます。リポジトリを調査し、関連ファイルを検索し、コードを読み、編集を行い、コマンドを実行し、エラーを確認して、結果を修正するという流れです。この一覧にある単一のツールが重要なのではありません。新しい情報が現れるたびに環境内で作業を進め続ける能力が重要です。DeepSeekのプラグインアーキテクチャは、エージェントを1つの固定アプリケーションとして扱うのではなく、これらの機能を組み合わせて利用できるようにします。リリースに関する報道では、これをプラグインで構成可能なエージェントランタイムと表現しています。

ほとんどのユーザーにとって、標準モードが適切なデフォルトです。DeepSeekにバグの調査、リポジトリの理解、機能の実装、複数ファイルの確認、通常の複数ステップのコーディング作業の調整をさせたい場合、ツールが問題を引き起こしていると分かる前に、意図的にツールを削除する理由はほとんどありません。

生産性ではなく評価がセッションの目的である場合、標準モードは適さなくなります。検索、計画、スキル、サブエージェント、その他のハーネスコンポーネントがモデルの弱点を補うことでモデルが成功した場合、最終結果から分かるのはエージェントシステムがどれだけうまく機能したかです。外部からの支援を最小限にした場合に、ベースモデルがどれだけうまく機能するかを明確に判断することはできません。

2. コードモード — DeepSeekにツールのオーケストレーションをプログラム化させる

Code Modeは、4つのモードの中で最も誤解されやすいものです。これは「Standard Modeだが、コーディングタスク専用」という意味ではありません。DeepSeekの現在の定義によると、Code ModeはStandard Modeのすべての機能を維持しています。変わるのは、ツールがモデルに公開される方法です。DeepSeekはCode Mode SDKを使用して、複数の操作をモデルが生成したTypeScriptプログラム内で組み合わせられます。

通常のエージェントループでは、複雑なタスクを実行するために、モデルと個々のツールとのやり取りを何度も繰り返す必要があります。エージェントは検索し、結果を受け取り、何を読むべきかを判断し、それを読み取り、その結果を処理し、別のツールを呼び出して処理を続けます。Code Mode SDKは、この制御フローの一部を実行可能なコードに移します。これにより、モデルはループ、フィルタリング、分岐、複数の依存するツール操作を、独立したツール呼び出しの長い連続ではなく、プログラムとして表現できます。

数百のファイルを検索し、パスで一致結果を絞り込み、一部だけを読み取り、値を抽出したうえで、それぞれの結果に対して同じチェックを実行する必要があるタスクを想像してください。Standard Modeでもこのワークフローは実行できますが、オーケストレーションの多くは、エージェントのターンを繰り返す形になります。オーケストレーション自体が小さなプログラムのようになり始める場合、Code Modeが魅力的になります。

ファイルを検索
→ 一致するパスを絞り込む
→ 結果をループ処理
→ 指定したファイルを読み取る
→ 返されたデータを処理
→ 後続の処理を実行

重要なのは「コーディング」ではなく、複雑さです。単純な編集が、Code Modeでその周囲にTypeScriptを生成できるからといって、自動的に良くなるわけではありません。関与するツールが少数だけなら、Standard Modeのほうが理解しやすい場合があります。Code Modeがより有用になるのは、繰り返し処理、構造化変換、条件分岐、ツール結果の処理などによって、通常ならモデル呼び出しの往復が何度も発生する場合です。

3. Minimal Mode — Harnessを取り除き、モデルをより深く見る

Minimal Modeは、低速なPCや小規模なホームサーバー向けの軽量な選択肢ではありません。意図的に制約されたエージェント環境です。DeepSeekは現在、これを永続的なbashと str_replace_editorこれにより、Standard Modeで利用できる広範な検索、スキル、サブエージェント、ワークフローの機能が取り除かれます。

その制限の理由は評価にあります。DeepSeek自身が、V4-Flashで報告された公開Code AgentベンチマークにDeepSeek HarnessのMinimal Modeを使用しました。この利用方法によって意図がより明確になります。Minimalは、研究者が少数の制御されたツールでモデルが何を達成できるかをより狭い範囲で評価したい場合に、周辺のエージェント機構を減らすよう設計されています。

この違いが重要なのは、現代のエージェントベンチマークがモデル以外の要素も測定し得るからです。優れたプランナー、より優れたコンテキストの組み立て、リポジトリ検索、専門スキル、リトライポリシー、サブエージェントへの委任は、いずれもタスクの成否を変える可能性があります。Harnessの評価に関する研究も同様に、能力はモデルの重みだけに自動的に帰属させるのではなく、モデルとHarnessの構成レベルで解釈すべきだと主張しています。

これにより、Minimal Modeの最適化目標はStandard Modeとは大きく異なります。Standard Modeが「このエージェントに有用な作業を完了させる最良の機会を与える環境は何か」と問うのに対し、Minimal Modeは「その環境の大部分を取り除き、より小さな実行サーフェスだけをモデルに残したら何が起こるか」と問います。

日常的な作業では、有用な機能を意図的に捨てることが逆効果になる場合があります。目標がリポジトリをできるだけ迅速かつ確実に修正することであれば、Minimal Modeは通常、解くべき問題を取り違えています。その価値が現れるのは、最大限のタスク完了率よりも、再現性、比較、デバッグ、またはモデルの生の挙動の理解が重要な場合です。

4. Creator Mode — DeepSeek Harnessを使ってHarnessを変更する

Creator Modeでは、操作する対象そのものが変わります。Standard Modeは主にエージェント環境を利用しますが、Creator Modeはその環境の作成と実験を目的に設計されています。Standard Modeの機能を備えつつ、ランタイムの調査、メモリ内でのプラグイン実験、カスタムプリセット作成のガイダンスが追加されています。

これは、DSHの基盤にあるアーキテクチャから直接導かれます。DeepSeekは、モデル、ツール、スキル、セッション、サンドボックス、ストレージ、ループ、スケジューリング、さらにはUIまでも、選択、置換、再構成が可能なプラグインとして扱います。Cordisカーネルはプラグインのマウント、アンマウント、依存関係を管理するため、DSHの拡張に特権的なモノリシックエージェントコアの変更が必ずしも必要になるわけではありません。この幅広い設計があるからこそ、「すべてがプラグインである」というプロジェクトの主張は、4つのプリセットが存在すること自体よりも重要なのです。

ホームサーバーの管理に特化したエージェントが必要だとします。そのエージェントの有用な環境には、シェルアクセス、制限付きのファイルシステム権限、Docker操作、インフラストラクチャのドキュメント、監視ツール、いくつかの専門スキルなどが含まれるでしょう。この組み合わせは、汎用的なコーディングエージェントと同一ではありません。Creator Modeは、このような機能を試し、それらを再利用可能なエージェントプリセットに組み合わせることを目的に設計されています。

現在のランタイムを調査
→ プラグインを追加またはテスト
→ サービスと依存関係を確認
→ 構成を調整
→ 特化したプリセットを保存
→ その環境を再び起動する

このため、Creator ModeはStandard Modeより専門性が高くなりますが、日常的な利用において自動的に優れているわけではありません。DeepSeekに3つのファイルを変更してテストスイートを実行させたいだけなら、ランタイムの検査やプリセットの作成に大きな価値はありません。「エージェントはこのタスクを実行できるか？」という問いが「この種類のエージェントにはどのような機能が必要か？」に変わるとき、Creatorが役立ちます。

Standard vs Code vs Minimal vs Creator：実際に変わる点は？

最大の誤りは、4つのモードをMinimal → Standard → Code → Creatorのような進行として並べることです。そうすると、段階ごとに単純に能力が追加されるように見えます。実際の関係は多面的です。Standardは汎用的な実行を重視し、Codeはオーケストレーションを変更し、Minimalは意図的に支援を減らし、Creatorはハーネス自体を設定対象として公開します。

モードの比較は、機能数ではなく、同じ質問に対する答えとして評価すると明確になります。StandardとCodeはどちらも幅広いエージェント環境を維持していますが、Codeでは複数ステップのツール作業の表現方法が変わります。Minimalは意図的に逆方向へ進み、ツールの範囲を縮小します。CreatorはStandardを起点に、日常的な生産性ツールを単に追加するのではなく、ランタイムを構成する機能を加えます。

同じDeepSeekモデルを使った2つのテストでも、ハーネス設定が異なれば結果が変わる可能性があるのは、このためです。DSHの初期分析では、モデル名だけを比較するのではなく、モデルとハーネスの設定を記録する重要性がすでに指摘されています。ツールへのアクセス、権限、コンテキストの構築、エージェントループ、その他のランタイム上の選択によって、モデルがタスクを進める経路は変わり得ます。

実際に使うべきDeepSeek Harness Modeはどれですか？

ほとんどの通常作業では、まずStandard Modeから始めてください。DSHが連携するよう設計された幅広い機能を利用でき、より専門的なランタイムが本当に必要かどうかを見極められます。軽そうだからという理由だけでMinimalから始めると、エージェントを役立たせるまさにその機能が失われる可能性があります。

ツールのワークフロー自体が複雑になったら、Code Mode に切り替えます。繰り返し行う検索、多数のファイルに対するループ処理、ツール結果のフィルタリング、構造化変換、条件付きアクションなどは、タスクがソフトウェア開発に関係しているという事実よりも、Code Mode を使用する強い理由になります。

質問の焦点が最大限の生産性ではなく、モデルそのものにある場合は、Minimal Mode を使用します。制御された比較、ベンチマークの再現、プロンプト実験、そして成功がモデルによるものか、それともより充実したハーネスによるものかを確認したい状況に適しています。

エージェント環境そのものを変更したい場合は、Creator Mode を使用します。プラグインの実験や特化型プリセットを想定したモードであり、DeepSeek Harness を単にデフォルトのエージェントとして操作するのではなく、新しいエージェントを構築するための基盤として扱う開発者向けです。

より広い目的が、DSH 自体を変更することではなく、プライベートデータを中心に再利用可能なエージェント機能を構築することであるなら、ローカルナレッジベース向け AI エージェントスキルのガイドで、セルフホストシステム上に再利用可能な検索、解析、根拠提示、ナレッジワークフローをスキルとしてまとめる方法を説明しています。

Plan Mode は DeepSeek Harness の5番目のランタイムモードではない

DSH には、用語を分かりにくくしている別の機能があります。それが Plan Mode です。Standard、Code、Minimal、Creator の隣に位置するもののように聞こえますが、DeepSeek の現在のアーキテクチャでは扱いが異なります。前述の4つのモードはランタイムプリセットまたはその組み合わせです。一方、Plan Mode はエージェントごとに任意で設定できる計画状態で、モデルに提供されるガイダンスを変更します。

DeepSeek のサブシステムドキュメントでは、Plan Mode はソフトなガイダンスであると明確に説明されています。Plan Mode が有効な間は、計画関連のプロンプトセクションがモデルへのリクエストに含まれます。サンドボックスモードと承認ポリシーはそれぞれ独立して制限を適用し、エージェントループ自体は Plan Mode に依存しません。

このように、2つの概念には異なる役割があります。Standard、Code、Minimal、Creatorはランタイム構成に関する問い、つまりどの能力が存在し、エージェントがどのように動作するかに答えます。一方、Plan Modeは行動に関する問い、つまり実行に進む前にエージェントを計画重視の協働状態にとどめるべきかどうかに答えます。

Standard / Code / Minimal / Creator
= ランタイム構成

Plan Mode
= 計画およびガイダンスの状態

したがって、DeepSeek Harnessに4つのモードがあるのか5つあるのかと尋ねられた場合、実用的な答えはこうです。DSHには現在、主要なランタイムモードが4つ用意されています。一方、Plan Modeは5つ目の同格ランタイムプリセットではなく、別個のオプションの計画メカニズムです。

4つのモードから見えてくる、DeepSeek Harnessが実際に構築しているもの

DSHで最も興味深いのは、ユーザーが選べるボタンを4つ用意していることではありません。各モードは、エージェントエンジニアリングにおける異なる4つの層を示しています。Standardは実行に重点を置き、Codeはオーケストレーション、Minimalは評価、Creatorは構成に重点を置きます。これらを合わせると、DeepSeekがハーネスをモデルの周囲にある見えない接着剤ではなく、エージェントの挙動に積極的に関与する要素として扱っていることが分かります。

これは、エージェントシステムの改善が、より大規模なモデルのトレーニングだけから生まれるわけではないため重要です。ツールの提示方法、コンテキスト管理、実行ポリシー、リトライ動作、スキル、メモリ、ランタイム構成を変更することで、同じモデルが達成できることは変わります。ランタイム全体を作り直すのではなく、そうした能力を拡張したい場合は、DeepSeekとHermesのプラグインスタックも、周辺のエージェントシステムがまったく新しい能力を追加できることを示す一例です。

つまり、4つのプリセットは普遍的な答えではなく、開始時の構成として捉えるべきです。ベンチマーク環境では、支援を少なくしたい場合があります。本番エージェントでは、より多くのツールと厳格な権限が必要になるかもしれません。複雑なツールワークフローでは、プログラムによるオーケストレーションが役立つでしょう。特化型のホームサーバーエージェントには、将来的に専用のプリセットがふさわしくなる可能性もあります。

DeepSeek Harnessは現在も開発者向けプレビュー段階にあり、DeepSeekはコアプラグインとAPIが今後も進化し続けると説明しています。そのため、具体的なプリセットやインターフェースは変更される可能性があります。しかし、アーキテクチャ上の区別はすでに有用です。エージェントの挙動が異なるときは、モデルだけに注目しないでください。そのモデルがどのように行動できるかを決めるハーネスにも目を向けましょう。