DeepSeek ProはMinimalモードで驚くほど優秀に見える。それこそが問題でもある

DeepSeek Proは8月13日に一般提供を開始したが、最も優れた挙動が報告されたのは、ユーザーが極めて特定のエージェント構成を再現した後だった。

その構成が、同社が新たに公開したツール利用AIエージェント向けランタイム「DeepSeek Harness」のMinimalプリセットである。コミュニティのテストでは、このプリセットにより、挙動にばらつきのあるコーディングモデルが、DeepSeekのベンチマークで示されたものにかなり近づくとされている。

この改善は、管理された多様なタスクセットを用いて独立に測定されたわけではない。それでも、最も劇的なデモが再現に失敗したとしても、この論争には意味がある。DeepSeek自身の資料は、エージェント性能を特定のプロンプト、ツール、推論設定、実行環境と結び付けている。

したがって本質的な問いは、DeepSeek-V4-Proが「良い」か「悪い」かよりも狭い。学習時に整合したハーネス内でのみ安定して現れる能力について、モデルに全面的な評価を与えるべきなのかという点だ。

Anthropic、OpenAI、その他のモデルベンダーも、自社モデルをClaude Code、Codex、あるいは別のエージェントランタイム経由で動作させる際には、同じ問題に直面する。DeepSeekは、この依存関係を異例なほど可視化したにすぎない。

DeepSeek ProのGAリリースは、エージェント性能をめぐる論争を伴った

8月13日のリリースで利用可能なモデルは変わったが、実際にどのシステムが評価されていたのかという問題は解決しなかった。

DeepSeekは2026年8月13日、V4-Proの一般提供版をアプリ、ウェブサイト、APIで正式に公開した。同社のGAリリースでは、エージェント機能の強化、3段階の推論努力レベル、OpenAIのResponses APIへのネイティブ対応が強調された。

低努力は単純なタスク向けだ。高努力は通常のエージェントワークフローを扱い、最大努力は複雑な作業により多くの推論を割り当てる。このリリースでは、V4-Pro APIのモデル名を変更せずに、Codex向けのセットアップ手順も追加された。

この発表に先立ち、4月24日にはより広範なV4ファミリーのプレビューが行われていた。DeepSeekはV4-Proを、総パラメータ数1.6兆、推論時に有効化されるパラメータ数490億のMixture-of-Expertsモデルとして説明している。

Mixture-of-Expertsモデルでは、各トークンをネットワーク全体ではなく一部だけに振り分ける。この設計により、すべてのリクエストで全パラメータを有効化せずに、総容量を増やせる。

このモデルは100万トークンのコンテキストウィンドウをサポートする。DeepSeekによると、3.2兆トークン以上で事前学習を行った後、教師あり学習、強化学習、オンポリシー蒸留を経ている。

この仕様自体が論争を招いたわけではない。摩擦が生じたのは、GA公開後に初期ユーザーがDeepSeekのエージェントベンチマーク上の主張と自身の結果を比較し始めてからだった。

一部のコミュニティ報告では、短い推論トレース、弱い計画性、一貫しないツール利用が指摘された。広く共有されたある報告はリリースを期待外れと評し、デプロイまたはサーバー側の設定問題がモデル本来の挙動を抑制している可能性を示唆した。

これらの観察は逸話的なものだった。使用されたプロンプト、アカウント、ツール、OS、リクエスト経路はそれぞれ異なる。一般的な性能水準を確立することはできない。

その後、第二波となる報告が現れた。ユーザーは、同じモデルをLinuxまたはWindows Subsystem for Linux上のDeepSeek Harness Minimalで実行すると、能力が大幅に向上したと述べた。

あるコミュニティテストでは、複数のユーザーが改善を再現したと主張された。それでも著者は、このモデルを主要な比較対象モデルより下と評価し、視覚的なセンスを批判した。

この留保は重要だ。主張は、Minimalモードがあらゆる弱点を解消したというものではない。多くの通常セッションでは見られなかった水準のコーディング挙動を、このプリセットが明らかにしたというものだった。

別のリポジトリ分析は、Minimalモードを8月10日のコミットと結び付けた。この分析によれば、そのコミットはプリセットを、強化学習中に使用されたエージェント構成に合わせたものだった。

この分析は、抑制されたシステムプロンプト、持続的なシェルアクセス、指定のファイルエディタ、特定のコンテキスト圧縮ポリシーから成る限定的な環境を記述している。また、システムプロンプトを汚染しかねない無関係なツール説明をプリセットが除外していたともしている。

この解釈は、公開コードとドキュメントに対するコミュニティの読み解きにとどまる。DeepSeekは、V4-ProがMinimalモード外では失敗すること、あるいは単一の公開プリセット向けに意図的に最適化されたことを証明する証拠を公表していない。

それでも、時系列は具体的だ。DeepSeekは8月13日にV4-Pro GAを公開し、開発者プレビューとしてハーネスを公開し、エージェント評価と密接に関連する環境を提供した。

緊張が生まれるのは、これらの要素がどう組み合わさるかにある。モデルが最高の挙動を示すためにその環境を必要とするなら、ユーザーが購入しているのは交換可能なモデルエンドポイントではなく、モデルとハーネスのシステムである。

DeepSeek Harnessがベンチマークの意味を変える理由

エージェントベンチマークは、リーダーボードにモデル名だけが表示されていても、モデル、プロンプト、ツール、メモリポリシー、ランタイムをまとめて測定している。

エージェントハーネスとは、言語モデルがファイルを調べ、コマンドを実行し、ツールを呼び出し、状態を保持し、次の処理を判断できるようにするソフトウェア層だ。これはテキスト予測を実行ループへと変える。

そのループは、多くの重要な選択を行う。システムプロンプトを整形し、ツールスキーマを定義し、エラーを返し、履歴を切り詰め、過去の作業を要約し、モデルに次のターンを与えるタイミングを決める。

小さな変更が大きな性能差を生むことがある。モデルがタスクを理解していても、ツールの説明が曖昧なために失敗するかもしれない。コンテキスト圧縮によって以前の制約が失われれば、誤ったファイルを編集する可能性もある。

また、ノイズの多いステータスメッセージを受け取った後に、推論予算を無駄にすることもある。別のハーネスなら、プロンプトを短く保ち、適切な状態を維持することで、同じ失敗を防げる。

DeepSeekの公式リポジトリは、DeepSeek Harnessを「すべてがプラグインである」オープンソースのエージェントランタイムとして説明している。このプロジェクトは開発者プレビュー段階であり、互換性を破る変更が発生することを警告している。

そのプラグインアーキテクチャは、ユーザーを単一の固定エージェント設計に縛り付けるのではなく、能力の交換や再構成を可能にする。この柔軟性はプロジェクトを有用にする一方で、「DeepSeek-V4-Proの性能」に関する主張を複雑にする。

どのプラグインが有効だったのか。どのプリセットがそれらを読み込んだのか。どのシステムプロンプトが使われたのか。会話履歴はどのように圧縮されたのか。シェルはターン間で生き続けたのか。

こうした詳細は実装上の些細な話ではない。各ステップでモデルが利用できる情報と行動を形作る。

DeepSeekのモデルドキュメントは、このシステム依存性を明確に示している。同社は、要求の厳しいエージェントタスクには最大推論を、同モードには少なくとも384,000トークンのコンテキストを推奨している。

同社のモデルカードも、推論設定間の大きな差を報告している。Terminal Bench 2.0では、DeepSeekはV4-Proについて、非思考モードで59.1、高努力で63.3、最大努力で67.9としている。

SWE-bench Verifiedでは、報告された推移は73.6、79.4、80.6だ。BrowseCompでは高努力と最大努力が80.4と83.4を記録し、非思考時の結果は掲載されていない。

これらはDeepSeek自身による評価であり、独立した再現結果ではない。しかし、推論構成が測定される能力を大きく変えるという同社の立場を示している。

技術レポートは、評価環境についてさらに詳しく説明している。コードエージェントタスクでは、DeepSeekはシェルアクセスとファイル編集を含む最小限のツール群を使用した。

検索エージェントタスクでは、同社は社内ハーネスを使用した。つまり、報告されたエージェントスコアは、単独のプロンプトに回答する素のモデルを表したものではなかった。

それ自体に不適切な点はない。エージェントモデルにはツールが必要であり、ベンチマークには何らかのランタイムが必要だ。どのベンダーも一つを選ぶ。

問題が始まるのは、ハーネス固有のスコアが、製品横断でのモデルの一般的な能力を表す略称になるときだ。持続的なシェルと学習時に整合した圧縮を用いて得られた結果が、別のエディタ拡張機能に自動的に移転するとは限らない。

Anthropic互換クライアントを使う開発者は、異なる構造のツール結果を送る可能性がある。企業向けプラットフォームは、セキュリティ指示、監査メッセージ、検索結果、承認ゲートを注入するかもしれない。

こうした追加要素は、本番環境では必要な場合がある。同時に、プロンプトを強化学習で使用された環境から大きく遠ざけることもある。

したがってMinimalモードは、単にデモを改善するものではない。モデルスコアの背後にどれほど多くの隠れたインフラが存在するかを明らかにする。

これが、DeepSeek Proをめぐる論争が一つのリリースにとどまらず重要である理由だ。モデルカードにはDeepSeek-V4-Proと記されているが、エージェントタスクにおける実際の単位は、DeepSeek-V4-Proとハーネス構成の組み合わせである。

この区別が明示されるなら、リーダーボードは両方を報告する必要がある。

学習時の整合は自動的に過学習を意味しない

公開されている証拠は構成への感度を支持しているが、DeepSeek-V4-Proが単一のハーネスに過学習したことは、まだ証明していない。

過学習には厳密な意味がある。システムが学習分布では良好に機能するパターンを学んでも、意味のある形で異なる入力に一般化できない場合、そのシステムは過学習している。

この場合、疑われる学習分布にはコーディング問題以上のものが含まれる。エージェントのプロンプト構造、ツール名、応答形式、シェルの挙動、コンテキスト管理ポリシーも含まれていた可能性がある。

強化学習が一つの構成内での成功を繰り返し報酬として与えたなら、モデルがその構成に適応するのは合理的だ。一貫したツールセマンティクスは不確実性を減らし、報酬信号を学びやすくする。

この適応は有益になり得る。人間も、慣れ親しんだインターフェース、信頼できるツール、安定したワークフローでより良い成果を出す。

予測可能なファイルエディタを使うよう学習したモデルは、文書化されていないエディタの挙動を推測せざるを得ないモデルより優れた性能を示すはずだ。そうした向上をすべて「過学習」と呼べば、この用語はほとんど役に立たなくなる。

より強い非難を行うには、より広範な失敗パターンが必要だ。V4-Proが、基礎となるタスクが同等であるにもかかわらず、無関係な環境詳細の変更によって異例なほど急激に性能低下することを示す必要がある。

たとえば研究者は、説明と挙動を維持したままツール名を変更できる。ツールスキーマの順序を変え、無害な表現を変化させ、エディタを同等のインターフェースに置き換え、必要な事実を削除せずに圧縮方法を変更できる。

汎用的なエージェントであれば、こうした変更の多くに耐えられるはずだ。ハーネスに縛られたモデルは、同じ実用的な能力を受け取っているにもかかわらず、大幅に性能を落とすだろう。

十分な数のタスクとランダム試行にわたって、そのパターンを確立した公開研究はまだない。スクリーンショット、動画、個人的なコーディングセッションは研究課題を示すことはできるが、一般化を測定することはできない。

「Minimalが本来のモデルを解放する」という主張には、別の説明もいくつかある。

第一に、Minimalモードはプロンプトの雑然さを取り除いている可能性がある。長いツールマニュアルや重複する指示は、特に長時間のセッションではエージェントの挙動を悪化させがちだ。

第二に、状態をより効果的に保持している可能性がある。持続的なシェルにより、モデルは作業ディレクトリ、環境状態、実行中のプロセスを、毎回再構築することなく維持できる。

第三に、このプリセットはポストトレーニングで使用されたツールインターフェースを公開している可能性がある。これにより分布整合は生まれるが、必ずしもベンチマークの記憶を意味するわけではない。

第四に、GA初期のリクエストはデプロイのばらつきに遭遇した可能性がある。コミュニティでは、推論が異常に短いことやルーティング変更の可能性が報告されたが、DeepSeekは緊急ロールバックを確認していない。

第五に、ユーザーは最も印象的な成功例を選んで拡散する可能性がある。好意的なデモは素早く広がる一方、再現に失敗したケースは注目されにくい。

逆のバイアスも存在する。特に期待を高めるベンチマークの主張を読んだ後では、失望したユーザーが一度の壊れたセッションから一般化してしまうことがある。

DeepSeekの公式結果にも、懐疑的に見る余地はある。同社は、V4-Pro MaxがSWE-bench Verifiedの80.6％を解決し、Terminal Bench 2.0で67.9を記録したと報告している。

また、Codeforcesレーティングは3206、LiveCodeBenchの通過率は93.5％だとしている。これらの数値は、明示された評価設定のもとで、このモデルをハイエンドのコーディングシステムとして示している。

より有用な基準点となるのは、独立評価だ。米国政府のAI標準・イノベーションセンターは、開発者推奨の設定を用いてプレビューモデルを評価した。

この独立評価で、CAISIはH200およびB200 GPU上でDeepSeek V4を提供した。内部推論を保持し、コンテキスト、サンプリング、システムプロンプト、最大思考量には推奨値を使用した。

CAISIはDeepSeekの自己報告によるGPQA-Diamondの結果も再現しており、このベンチマークで基本的な推論設定ミスがあった可能性を低減している。ただしエージェントテストでは、DeepSeek Harness Minimalではなく、Inspectに組み込まれたReActエージェントを使用した。

この違いこそ、今後の分析で検討すべき点である。モデルは静的な推論ベンチマークに一致する一方で、それを取り巻くエージェントループには非常に敏感であり得る。

したがって、現時点で得られる証拠は慎重な結論を支持している。DeepSeek-V4-Proは環境に敏感であり、DeepSeekは既知の構成を中心にエージェントワークフローを最適化している。

この証拠は、DeepSeekが公開ベンチマークのタスクを記憶していたことを立証するものではない。また、意図的な操作を証明するものでもない。

現時点でこのモデルを過学習だと呼ぶのは、データの示す範囲を超えている。ハーネスは無関係だとするのも、DeepSeekのドキュメントとコミュニティテストの双方が示す内容を見落としている。

本当の競争は、トレーニング整合型エージェントとポータブルなモデルの間にある

DeepSeekにとって当面の課題は、ある競合モデルを上回ることではない。能力が好みのランタイムの外でも維持されることを証明することだ。

モデルベンダーは、完成されたエージェントシステム全体をますます最適化している。モデル自体は依然重要だが、その推論が有用な成果物を生むかどうかはオーケストレーションが左右する。

OpenAIはモデルをCodexと組み合わせている。AnthropicはClaude Codeと並行してモデルを開発している。GoogleはGeminiのコーディング製品内でモデルの挙動を管理し、独立系ランタイムは独自のプロンプトやツールを追加している。

DeepSeekにも現在、同じ戦略的選択肢がある。V4-ProをDeepSeek Harnessと共同設計し、失敗をエンドツーエンドで測定し、そのトレースを強化学習に利用できる。

このアプローチは、APIを孤立したテキスト生成器として扱うよりも、優れた実世界の結果を生み出せる可能性がある。また、企業がインタラクションの両側を管理するため、デバッグも加速できる。

安定したハーネスは、トレーニングチームに再現可能な環境を与える。正しいコマンド使用を報酬化し、ファイル変更を検証し、未完了の作業にペナルティを与え、長時間のセッションをテストできる。

トレードオフはポータビリティだ。企業がモデルをベンダーの手つかずの参照環境内にそのままデプロイすることは、ほとんどない。

企業は権限チェック、プライベート検索、ログ記録、ポリシーフィルター、人間による承認、組織固有のツールを追加する。開発者は既存のエディター、コマンドラインエージェント、オートメーションフレームワークを持ち込む。

こうした追加要素はそれぞれ、インタラクションの分布を変える。1つの簡素なシステムプロンプトに依存するモデルは、企業のセキュリティポリシーが数千トークン追加されると性能が後退する可能性がある。

あるファイル編集プロトコルを前提にトレーニングされたモデルは、別のプロトコルのエラーメッセージを適切に扱えないかもしれない。コーディングでは有効なコンパクション戦略が、法務や分析タスクで必要な証拠を捨ててしまう可能性もある。

ポータブルな能力とは、こうした変化をまたいで性能を維持することを意味する。どこでも同一のスコアを求めるものではないが、緩やかに性能が低下することを求める。

トレーニング整合型の能力は、異なる約束を提供する。ベンダーは既知の設定による推奨システムを提供し、ユーザーはスタック全体を採用することで公称性能を得られる。

どちらのアプローチも、普遍的に優れているわけではない。緊密に統合されたシステムは、その環境を標準化する意思のあるチームにより良い成果をもたらし得る。

ポータブルなモデルは、プラットフォーム構築者により大きな自由を与える。また、ランタイムをまたいだベンチマーク結果の比較もしやすくなる。

DeepSeekの現在のメッセージングは、両方の利点を主張しようとしている。V4-ProはいくつかのAPI形式で利用でき、主要なエージェント製品と互換性があるとされている。

同時に、最も強力と報告される挙動は、最大推論と特殊なハーネス構成に密接に結びついているように見える。この隔たりは、ポータビリティの主張に圧力をかける。

公式のプレビュー発表では、DeepSeekはV4をClaude Code、OpenClaw、OpenCodeなどのエージェント製品向けに最適化したとしている。また、同社がエージェント型コーディングのために社内でV4を利用しているとも述べた。

これらの発言は、単一のMinimalプリセットより広範な適応を示唆している。DeepSeekは、条件をそろえた予算のもとで複数の独立ランタイムにわたる結果を公開することで、これらを裏付けられる。

比較では、最終スコア以上の要素を管理しなければならない。研究者はトークン使用量、実行時間、完了率、ツールエラー、リトライ、失敗カテゴリを報告すべきである。

また、モデルの失敗とハーネスの失敗を分けるべきだ。エディターが形式不正なパッチを拒否した場合、スキーマ、パーサー、モデルのいずれが欠陥を引き起こしたのかをトレースで示す必要がある。

この水準の報告は、エージェント市場全体を改善するだろう。現在のリーダーボードは、複雑なシステムを、1つのモデル名の横に置かれた1つの割合へと圧縮しがちだ。

こうした表示は、購入者にオーケストレーションを無視してモデルエンドポイントを比較するよう促す。また、ベンダーが結果の感度を示さずに有利なハーネスを選ぶことも可能にする。

DeepSeek Harnessは、同社がプラグイン設計を用いて制御されたアブレーションを行えば、この問題の解決に役立つ可能性がある。チームは一度に1つのコンポーネントを入れ替え、結果として生じるスコア変化を公開できる。

アブレーションテストとは、1つの要素を削除または変更し、その寄与を測定する手法だ。ここでは、永続的なシェル状態、コンパクションポリシー、ツール名、システムプロンプトの長さの価値を定量化できる。

Minimalモードが無関係な指示を除くことで勝つなら、他のハーネス開発者もその教訓を取り入れられる。モデルがトレーニング時の正確なトークンを期待するために勝つなら、ポータビリティへの懸念はより強まる。

どちらの結果も、別のショーケース実行より有益だ。この論争に必要なのは、熱狂的なクリップと不満の投稿の競争ではなく、測定である。

DeepSeek Proへの懸念を裏付ける、または弱めるもの

Minimalモードが妥当な参照設定なのか、それとも性能依存なのかは、観測可能な3つのシグナルによって判断できる。

第1のシグナルは、0813モデルに対する制御されたクロスハーネス評価だ。同一のタスクを、DeepSeek Harness Minimal、標準プリセット、少なくとも2つの独立したエージェントランタイムで実行すべきである。

各構成では、推論レベル、トークン予算、サンプリングポリシー、ツール能力、リトライ許容量を同一にする必要がある。エージェントの結果は実行ごとに変動するため、評価者は複数回の試行を行うべきだ。

Minimalの優位性が大きければ、構成依存への懸念は強まる。同等のランタイム間で結果が似通えば、過学習説は弱まり、初期の失敗が設定またはデプロイ上の問題によるものだったことを示唆する。

第2のシグナルは、無害なインターフェース変更に対する堅牢性だ。評価者はツール名の変更、スキーマの並べ替え、指示の言い換え、機能的に同等なエディターへの置換を行うべきである。

情報と利用可能なアクションが変わらない限り、性能は概ね安定しているべきだ。急激な低下は、モデルが一般的なツール理解ではなく表層的な特徴に依存していることを示す。

このテストは、あるベンダーのハーネスを別のベンダーのハーネスと比較するより重要だ。異なる製品は一度に多くの変数を導入するため、スコア変化の原因を切り分けにくくなる。

第3のシグナルは、DeepSeek自身による開示だ。同社は、各主要ベンチマークの背後にある正確なエージェント構成を、プロンプト、ツールスキーマ、コンパクション規則、推論設定を含めて公開すべきである。

また、プレビューモデルと8月13日のGAチェックポイントを区別すべきだ。バージョンごとの結果がなければ、ユーザーは古いスコアが呼び出しているエンドポイントへ移転可能か判断できない。

DeepSeekがこの透明性を提供するために、非公開のトレーニングデータを明かす必要はない。再現可能な評価スクリプトと完全なランタイム構成があれば、中心的な疑問に答えられる。

そうすれば独立研究者は、主張される改善が別のリポジトリ、言語、タスク長、セキュリティ制約でも維持されるかを検証できる。企業の購入者は、参照ハーネスの採用が自社システムに適合するか判断できる。

開発者にとって、実践的な教訓はすでに明確だ。1つのチャットウィンドウだけでDeepSeek proを評価してはならず、1回のMinimalモードでの成功を普遍的な結果として信じてもならない。

本番環境に入る正確なモデルとハーネスの組み合わせをテストすること。最終的な文章だけで判断せず、推論設定、コンテキストポリシー、ツール定義、リトライ、タスク完了を記録すること。

ベンチマークの公開者は、構成を第一級のエントリーとして報告すべきだ。「DeepSeek-V4-Pro」だけの行よりも、「DeepSeek-V4-Pro with DSH Minimal」の方が正直である。

DeepSeekにとって、この機会は1つのリリースを守ることより大きい。同社はこの論争を、エージェントシステムを評価するためのより明確な標準へと変えられる。

最も望ましい結果は、MinimalモードがV4-Proを例外的に見せるという証明ではない。実際の組織がMinimalを自らの複雑な環境に置き換えても、モデルが有用であり続けるという証拠だ。

その結果が得られるまで、「過学習」は証明されていない診断にとどまる。確立された懸念は構成依存であり、それだけでも十分に重大だ。

0813リリースをテストするなら、同じリポジトリのタスクを少なくとも2つのハーネスで実行し、それぞれを繰り返すこと。トレースを保存し、予算を正規化し、成功例とともに失敗例も公開する。その証拠が、DeepSeek proが移植可能なエージェント挙動を学んだのか、それとも異常に馴染み深い1つのワークフローを学んだのかを教えてくれる。