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

DeepSeek Harnessには、Standard、Code、Minimal、Creatorの4つのランタイムモードがあります。これらは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_editorStandard Modeで利用できる、より広範な検索、スキル、サブエージェント、ワークフローの機能を取り除きます。

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

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

これにより、ミニマルモードは標準モードとは大きく異なる最適化目標を持つことになります。標準モードが「このエージェントに有用な作業を完了させる最良の可能性を与える環境は何か」と問うのに対し、ミニマルモードは「その環境の多くを取り除き、より小さな実行サーフェスをモデルに残したとき、何が起こるか」と問います。

日常の作業では、便利な機能を意図的に捨てることが逆効果になる場合があります。できるだけ迅速かつ確実にリポジトリを修正することが目的なら、ミニマルモードは通常、間違った問題を解決しています。その価値が現れるのは、タスクの最大限の完了度よりも、再現性、比較、デバッグ、またはモデルの生の挙動の理解が重要になる場合です。

4. クリエーターモード — DeepSeek HarnessでHarnessを変える

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

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

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

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

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

標準 vs コード vs ミニマル vs クリエーター：実際に何が変わる？

4つのモードを、ミニマル → 標準 → コード → クリエーターのような段階として並べるのが最大の誤りです。そうすると、段階を進むたびに単純に性能が高まるように見えます。実際の関係は多次元的です。標準モードは汎用的な実行を重視し、コードモードはオーケストレーションを変え、ミニマルモードは意図的に支援を減らし、クリエーターモードは設定対象としてハーネス自体を公開します。

機能数ではなく、同じ質問に対して各モードを評価すると、比較はより明確になります。標準モードとコードモードはいずれも幅広いエージェント環境を維持していますが、コードモードでは複数ステップのツール作業を表現する方法が変わります。ミニマルモードは意図的に逆方向へ進み、ツールの範囲を縮小します。クリエーターモードは標準モードを起点に、日常的な生産性ツールを単に追加するのではなく、ランタイムを構成するための機能を追加します。

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

実際に使うべきDeepSeekハーネスモードはどれ？

通常の作業のほとんどでは、まず標準モードから始めてください。DSHが連携するために設計された幅広い機能を利用でき、より特化したランタイムが本当に必要かどうかを見極められます。軽そうだからという理由だけでミニマルモードを選ぶと、エージェントを役立たせるまさにその機能が失われる可能性があります。

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

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

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

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

Plan ModeはDeepSeek Harnessの5番目のランタイムモードではありません

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

DeepSeekのサブシステムドキュメントでは、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が今後も進化し続けると述べています。そのため、具体的なプリセットやインターフェースは変更される可能性があります。しかし、このアーキテクチャ上の区別はすでに有用です。エージェントの挙動が異なるときは、モデルだけに目を向けないでください。そのモデルがどのように行動できるかを決めるハーネスにも注目しましょう。