DeepSeek-V4-Pro、実行時推論制御の修正によりFable 5を上回る

DeepSeek V4 × J-Space 能力解放レポート © 2026 Tiger3807861189. 本著作はクリエイティブ・コモンズ 表示-禁止改変 4.0 国際ライセンス（CC BY-ND 4.0）の下でライセンスされています。帰属表示をすれば、本レポートを共有・引用できます。ただし、改変、翻案、またはそれらを基にした二次的著作物の配布は禁止されています。© 2026 Tiger3807861189. 本レポートは、知識共有-表示-禁止改変 4.0 国際ライセンス（CC BY-ND 4.0）を採用しています。帰属表示をすれば引用・転載が可能ですが、改変、翻案、またはそれらを基にした二次的著作物の配布は禁止されています。 J-Spaceは、Deepseekの性能を大幅に向上させることがベンチマークで検証されたプラグインです。Flashは基本性能でGLM5.3に匹敵し、ProはFable 5を上回ります。リポジトリはこちらです: https://github.com/Tiger3807861189/J-Space-Cognition-Suite-V3.6 はオープンソース化されており、皆様のご利用をお待ちしております。もし体験が良ければ、スターをいただけると幸いです。 要約 DeepSeek V4-Flash-0731とDeepSeek V4-Pro-0813は、いずれも強力な知識、推論、コード、およびAgent能力を示しています。複雑なタスクにおける両者の損失は、「モデル能力不足」と単純に説明することはできません。より正確なエンジニアリング診断は、モデル能力が推論モード、初回インターフェース、ツールスキーマ、アクティビティ表現、長距離状態、および検証メカニズムを経て、初めて提供可能な結果に変換されるというものです。いずれかの層で不一致が生じると、能力実現損失（capability-realization loss）が発生します。 コミュニティ実験は、DeepSeek V4の2つの重要な現象をさらに露呈させました。Agentの後処理は、公式のMinimal条件に対して明らかなインターフェース依存性を持っています。初回ペルソナ、ツールディレクトリ、および自動注入がわずかに変更されると、推論行動が常に滑らかに変化するのではなく、別の軌道に跳躍する可能性があります。本稿では、この観察可能な非連続的でパス依存的な現象を「思考連鎖ダイオード」（chain-of-thought diode）と呼びます。これはDeepSeek公式のアーキテクチャ名ではなく、ブラックボックスの挙動に対するエンジニアリング上の概括です。 J-Space Cognition Suite V3.6はモデルの重みを変更しません。ワークスペースのロード、選択的ルーティング、機能的な一人称、密な軌道、永続的な台帳、チェックポイント、経験的検証、および回復ループを通じて、モデルが「能力を持つ」状態から「安定してタスクを完了する」状態への損失を低減します。その価値は、弱いモデルを強いモデルとして包装することではなく、強いモデルが既に持つ能力をより確実に呼び出し、維持、調整、および検証することを支援することにあります。 データ説明：V4-Flash-0731 / V4-Pro-0813 + J-Space は、スイートの既存の単回実測結果です。deepseekのオリジナル成績および他のモデルの成績は、各ベンダーの公開結果に基づいています。 1. 結論を先行させる 本稿では、4つの主要な結論を得ました。 DeepSeek V4の基礎能力は既に非常に強力です。 V4-Proは総パラメータ数1.6兆、アクティブパラメータ数490億、V4-Flashは総パラメータ数2840億、アクティブパラメータ数130億です。両者とも1Mのコンテキスト長と複数の推論強度をサポートしています。基礎容量はAgentのパフォーマンス変動を説明する十分な理由ではありません。 DeepSeek V4には顕著な実行条件感応性があります。Minimalツールスキーマ、初回出力条件、および自動注入内容は、最初の推論軌道を変更する可能性があります。 J-Spaceは推論時の制御損失に対処します。速度のために思考予算を圧縮することに依存せず、思考連鎖を無制限に延長することを奨励するのではなく、タスクと段階に応じて「短い判断—行動—より深い推論—検証—回復」の交互構造を編成します。 J-Spaceのシステムカバレッジは単一点アンカーよりも広範ですが、無条件に他のソリューションを全面的に代替すると主張すべきではありません。DeepSeek Harnessの初回インターフェース復元においては、Anchored Standardがより直接的です。モデル固有の挙動に選択肢がある場合は、Routing Suiteがより専門的です。長距離状態、検証カバレッジ、回復、およびクロスプラットフォーム移行においては、J-Spaceがより包括的です。 2. DeepSeekはなぜ強力なのに、完全には発揮されていない可能性があるのか 2.1 モデル容量と実行パフォーマンスは同じ変数ではない DeepSeek V4の公式モデルカードによると、V4-ProとV4-Flashはどちらも百万トークンのコンテキスト長をサポートし、Non-think、Think High、Think Maxをサポートしています。V4-Proは知識容量と複雑なAgentの上限が高く、Flashはより少ないアクティブパラメータで同等の推論能力と高い効率を提供します。 これらの能力は、「モデルが何を表現し、計算できるか」という問題に対処しますが、以下のことを自動的に決定するわけではありません。 現在のどの制約をアクティブに保つべきか まず計画すべきか、それともすぐに実行すべきか ツールの返却後にどの診断を引き継ぐべきか いつさらに深く掘り下げ、いつ停止して検証するか 単に流暢な回答を生成するだけでなく、タスクが本当に完了したことをどのように確認するか したがって、長いコンテキスト長は有効なワーキングメモリを意味せず、Think Maxは安定した長距離制御を意味しません。 2.2 Minimalインターフェースへの過剰適合：後処理能力がインターフェースの指紋にバインドされている dsh-anchored-standardは、初回条件における変数の分離を明確にしています。公式のMinimalの実際の2つのツールスキーマは、デフォルトの大きな出力予算の下で安定してWe need…の軌道をアンカーできます。Standard系のツールスキーマは、Let me…のスタイルに安定して入ります。AGENTS/CLAUDEの要約と利用可能なSkillディレクトリのリマインダーは、Minimalアンカーを破壊する可能性があります。一度にStandardツールディレクトリ全体を開放すると、昇格後に後退する可能性もあるため、小型の常駐ディレクトリとオンデマンドでのロック解除が必要です。 この一連の結果は、DeepSeek V4のAgent戦略がインターフェースに依存しない汎用アルゴリズムに完全に抽象化されていないことを示しています。後処理で学習された一部の高品質な挙動は、具体的なペルソナ、ツールの構造、および初回コンテキストと共同でバインドされています。モデルは「働き方を知らない」のではなく、馴染みのあるインターフェース分布から外れたときに、常に同じ戦略を滑らかに呼び出すことができないのです。 強調すべきは、We needとLet meは観察可能な軌道プローブであり、単独で品質変化を引き起こす魔法の言葉ではないということです。実際に機能しているのは、それらの背後にある全体的な実行状態です。 2.3 思考連鎖ダイオード：非連続的でパス依存的な挙動の跳躍 dsh-routing-suiteとそのルーティングコンポーネントは、挙動をspec、mixed、react、weakの領域に分割します。最新の説明では、「公式が意図的に二重アトラクタを設計した」といった過度な帰因を放棄し、現象をネイティブな深いパスと後処理で十分に汎化されていないパスの間の断層として、より慎重に理解しています。 いわゆる「ダイオード」は主に以下の点で現れます。 ペルソナまたはツールの小さな変化が、比例的な変化ではなく、離散的な挙動の跳躍を引き起こす可能性があること。 中間混合領域が両端よりも不安定である可能性があること。 初回でパスのコミットメントが形成された後、後から追加されたペルソナは軌道を変更するのが難しいこと。 非常に短いパスは橋渡しや検証をスキップしやすく、非常に長いパスは行動せずに長時間推論を続ける可能性があること。 同じ軌道がすべてのタスクに適しているわけではありません。メンテナンスタスクとゼロから構築するタスクでは、異なる挙動形態が必要になる可能性があります。 したがって、問題は単純に「考えが足りない」または「考えすぎる」のではなく、安定したタスク—軌道マッチングと、軌道内部の深さと行動制御が欠けていることです。 2.4 ツール間の接続と長距離コンテキストが損失を増幅し続ける DeepSeek APIの複数回の説明では、API自体はステートレスであり、呼び出し側はコンテキストを正しく連結する必要があると指摘されています。思考モードの説明では、同じユーザーターン内でツール呼び出しが発生した場合、関連する推論内容はツールチェーンとともに正しく返される必要があると要求されています。 初回ルーティングが正しくても、長距離Agentは以下の問題により退化する可能性があります。 目標が機械的な実行段階で薄れる。 同じ名前、数値、または制約が異なるブランチで個別に再構築される。 ツールが失敗した後、診断を引き継がずに空白で再試行する。 古い計画がコンテキストを占有し続けるが、現在の行動の根拠ではなくなる。 モデルが完了度を過大評価し、目標や検証カバレッジを確認しない。 これらはJ-Spaceが主に処理する第二層の問題を構成します。 3. J-Spaceは既存の能力をどのように解放するか 3.1 機能的な I / we / we need / let's J-Spaceは一人称を明確に分担します。Iは知覚、判断、コミットメントに使用されます。we、we need、let'sはモデルとワークスペースが共同で操作を実行するために使用されます。後続のプロトコルは、これらの陳述を行動、チェック、または収束に具体化し、機能的なエコーを形成する必要があります。この構文は、高品質なplan-collective軌道と構造的に対応していますが、すべてのタスクを単一のweスタイルに強制するわけではありません。weを使用して共有目標とワークスペースの協調を維持し、Iを使用して局所的な選択と行動を担当することで、安定した協調軌道内で実行者の能力を保持しようとします。Let meやBut waitが時折出現しても自動的に失敗とはなりませんが、診断のない繰り返しの覆し、自己対話の膨張、および行動を生まない疑念のループは抑制する必要があります。 3.2 「短い」か「長い」かを選択するのではなく、推論構造を制御する J-Spaceは3段階のゲート割り当てによりコストを制御します。fast：一目で検証可能な単一ステップタスクで、追加メカニズムをロードしません。full：限定的な複数ステップタスクで、1つか2つの関連モジュールのみをロードします。loop：複数ファイル、複数ツール、複数ターン、または永続状態を必要とするタスクで、台帳、接続リフレッシュ、チェックポイント、および回復を有効にします。 複雑なタスク内部では、以下の制御シーケンスを形成します。局所的な短い判断 → 行動または証拠収集 → 必要な深い推論 → 明確な意思決定 → チェックポイント → 実行継続。 したがって、「長短の組み合わせ」は、不安定な2つのペルソナ間で頻繁に切り替えることではなく、安定したタスクアイデンティティ内で、各推論ブロックが実際に担当する必要のある深さのみを担当させることです。 3.3 ワークスペース、密な軌道、およびブロードキャスト J-Spaceはアクティブな作業セットを1つか2つの連続したプロジェクトに制限し、各プロジェクトはロード後に直ちに使用されることを要求します。共有名、制約、およびスタイルアンカーは一度だけ確立され、すべての依存ブランチにブロードキャストされます。長いチェーンは内部でロスなく展開可能な密な軌道を使用でき、自然言語での説明コストを削減します。ユーザーおよびタスクツールに対しては、明確な外部言語に完全に切り替えます。この「内部は密、オンデマンドデコード、外部は明確」なレジスタ分離は、深い計算を保持しつつ、圧縮シンボルが成果物に漏洩するのを防ぎます。 3.4 モニタリングから制御へ 通常のプロンプトは、モデルに「確認してください」と要求するだけです。J-Spaceは、各モニタリング信号が行動を変更することを要求します。信頼できる場合は継続します。診断可能な失敗の場合は診断を伴って再試行します。パスの競合の場合は独立したルートを採用し、整合性を取ります。推論が制約を生成しなくなった場合は、限定的な候補と差分テストに移行します。退化を発見した場合は、最新の検証状態に戻って再入力します。チェックポイントは、検証者とカバレッジを同時に記録する必要があり、局所的なテストの成功を全体的な完了と誤認するのを防ぎます。 3.5 永続状態とツール接続 Loop台帳は5種類のタスク状態のみを保持します：Goal / Core / Verified / Open / Next。その役割はモデルの求解を代行することではなく、モデルがツール呼び出し、ファイル切り替え、コンテキスト圧縮、および長時間のインターバルを経ても、同じタスク状態を回復できるようにすることです。これは、初回アンカーソリューションの境界を補完します。軌道に入った後も、継続的な維持、局所的な入出力、検証、および回復が必要です。 4. ベンチマーク結果 4.1 評価プロトコル DeepSeekの2つの対照群は、DeepSeek Harness Minimalの組み合わせ、reasoning_effort = max、temperature = 1.0、top_p = 0.95を使用しました。現在の公式APIは、思考モードでtemperatureとtop_pを無視する可能性があります。Harness設定の一貫性を保つため、これらのパラメータも提出し、再現ログにサーバー側の実際の動作を記録する必要があります。 ベースモデル、ベンチマーク実装、ツール条件、タスク入力、およびスコアリングルールは一貫しています。唯一の実験変数は、J-Spaceをロードするかどうかです。J-Spaceはユーザーが能動的にロードし、無関係なSkillディレクトリを同時に注入しません。モジュールはfast/full/loopのゲート制御で選択されます。すべての結果は単一実行で記録され、複数回の平均値や信頼区間は含まれません。 GLM-5.3、Kimi-K3、Opus-4.8、およびFable 5は、各ベンダーが公開した際の評価方法を維持しており、能力の位置参照としてのみ使用されます。すべてのモデルが同じHarnessで再テストされたわけではありません。各ベンチマークは独自のネイティブスコアを使用し、高いほど良いです。 4.2 完全なモデル比較 | Benchmark | V4-Flash-0731 | V4-Flash-0731 + J-Space | V4-Pro-0813 | V4-Pro-0813 + J-Space | GLM-5.3 | Kimi-K3 | Opus-4.8 | Fable 5 (w/ fallback) | |--------------------------|---------------|-------------------------|-------------|-----------------------|---------|---------|----------|---------------------| | HLE (no tool) | 37.8 | 45.5 | 42.7 | 48.0 | — | 43.5 | 49.8 | 53.3 | | HLE (with tool) | 51.5 | 60.6 | 60.0 | 67.7 | 62.5 | 56.0 | 57.9 | 63.0 | | Terminal Bench 2.1 | 82.7 | 87.1 | 87.9 | 90.1 | 88.2 | 88.3 | 85.0 | 88.0 | | NL2Repo | 54.2 | 70.2 | 61.5 | 73.4 | 58.0 | 58.0 | 69.7 | — | | CyberGym | 76.7 | 81.7 | 83.3 | 86.8 | 84.5 | 80.0 | 78.3 | 83.1 | | DeepSWE | 54.4 | 67.4 | 62.7 | 72.0 | 66.9 | 67.5 | 58.0 | 70.0 | | Toolathlon-Verified | 70.3 | 77.7 | 74.1 | 79.5 | 73.0 | 76.5 | 76.2 | 77.9 | | Agents' Last Exam | 25.2 | 30.1 | 25.7 | 30.3 | 28.5 | 27.6 | 25.7 | 23.8 | | AutomationBench (Public) | 25.1 | 31.7 | 31.8 | 38.2 | 48.2 | 30.8 | 27.2 | 29.1 | 太字は、その行の完全な対照表における公開値の最高値を示します。 4.3 なぜV4-ProのゲインがFlashに平準化されないのか V4-Proの単一点結果は、各タスクタイプにおける回復可能な損失に基づいて個別に説明されており、Flashのゲインに統一係数を掛けるものではありません。 | Benchmark タイプ | 主要な制限 | J-Spaceの主な役割 | 結果の形態 | |-------------------------|------------------------------------------|-------------------------------------------------|---------------------------------------------------------------------------| | HLE (no tool) | 知識境界、橋渡し、信頼性制御 | 結論前の橋渡し、モニタリングから制御へ、独立した再確認 | 改善は見られるが、モデルが持たない知識を生成すると仮定しない | | HLE (with tool) | 検索、証拠統合、検証カバレッジ | ツール接続、経験的検証、カバレッジチェックポイント | ツールがない条件よりもゲインが高い | | Terminal Bench | 高い基礎スコア、連続行動、部分的なフィードバック | Next、接続リフレッシュ、失敗診断 | 天井に制限され、ゲインが縮小する | | NL2Repo | 要求ブロードキャスト、クロスファイル一貫性、長距離状態 | ブロードキャストハブ、Core交換、Loop台帳 | 回復可能な空間を大きく維持する | | CyberGym | 未知の量、ツール証拠収集、行き止まりからの脱出 | 候補の限定化、差分テスト、偽証マーク | 高い基礎スコアの下で中程度のゲインを得る | | DeepSWE | 計画と実行の交互、反復検証 | 短長推論の組み合わせ、チェックポイント、完了チェック | 全プロセス制御に高度に依存する | | Toolathlon | マルチツールオーケストレーションと結果検証性 | 共有状態、接続監査、カバレッジチェック | オーケストレーションと検証の損失を主に回復する | | Agents' Last Exam | 異種タスクとモード選択 | 適応型パス、選択的モジュール、回復 | 単一ペルソナが普遍的に最適であると仮定しない | | AutomationBench | 永続的なワークフローと依存関係の推進 | Goal、安定したOpen、明確なNext、長間隔回復 | Loopとタスク構造に高度に適合する | V4-Proは、より大きなアクティブ容量とAgentの後処理により、Flashが露呈した損失の一部を回収しているため、ほとんどの項目でFlashの絶対的なゲインを複製すべきではありません。一方、Proは初回ツール面とペルソナにより敏感であり、正しくルーティングされた後の潜在能力も高いため、NL2Repo、DeepSWE、AutomationBenchでは依然として顕著な改善の余地があります。 4.4 公開参照モデルとの位置関係 完全な対照表によると、V4-Pro-0813 + J-Spaceは、HLE (with tool)、Terminal Bench 2.1、NL2Repo、CyberGym、DeepSWE、Agents' Last Exam、およびToolathlon-Verifiedの7項目で参照列の先頭に位置しています。HLE (no tool)は依然としてFable 5を下回り、AutomationBenchは依然としてGLM-5.3を下回ります。異なるベンダーはそれぞれのリリース時の評価方法を維持しているため、ここでは公開能力の位置を示しており、統一Harnessでの厳密な横断実験ではありません。参照データとソースはスイートに沿っています。 この結果セットが支持する結論は、DeepSeekがあらゆる次元で必然的にリードしているということではありません。むしろ、タスク損失が主にルーティング、状態、ツール接続、および検証制御に起因する場合、DeepSeekの潜在能力は強力なクローズドソースモデルの公開位置に達するか、それを超えるのに十分です。ボトルネックが知識境界や特定のワークフローの後処理に近い場合、J-Spaceはすべてのギャップを埋めることはできません。 4.5 効率結果 V4-Flashの既存のタスクレベル効率実験は、同じモデルとタスク条件を使用し、固定された統一係数でスケーリングしています。 | 指標 | Control | J-Space | 相対ゲイン | |--------------|---------|---------|------------| | スコア / 時間 | 0.43 | 1.09 | 2.53× | | スコア / トークン | 0.38 | 0.84 | 2.21× | ゲインは最終的な回答の圧縮によるものではなく、主に繰り返しエンコーディング、空白の再試行、長いチェーンの陥没、およびゼロからの回復の削減によるものです。統一スケーリング係数は相対比率を変更しません。 5. 2つの公開ソリューションとの関係 5.1 Anchored Standard：初回インターフェースの正確な復元 https://github.com/xiaobright/dsh-anchored-standard Anchored Standardの貢献は、初回条件が因果的に重要であることを証明し、「最初に正しい軌道に入る」ことと「後で完全なツール能力を得る」ことを分離したことです。その利点は以下の通りです。 変数の制御が明確で、Minimalツールスキーマを正確に再現します。 起動コストが低く、基本モードは追加のモデル呼び出しを増やしません。 永続的なイベントで昇格を決定し、resume/reload後の状態を失いません。 一度に完全なツールディレクトリをすべて傾倒するのを避けます。 その境界も明確です。公開された高スコアは特定のProject2タスクに由来しており、READMEはクロスモデル、クロスワークロードでの普遍的な改善を表明していません。DeepSeek Harnessの特定のバージョンとツール構成に依存します。ツールがない状態でのアンカーは、ツールを回復した後にLet me軌道に戻る可能性もあります。 5.2 Routing Suite：タスク認識型の外部モード選択 https://github.com/yjh051108/dsh-routing-suite Routing Suiteは単一点アンカーよりも一歩進んでいます。spec/react/mixed/weakの挙動領域を認識し、ProとFlashで異なるペルソナを使用し、近接誘導、レビュー、収束、反跑題、および意思決定クロージャを追加します。公開された要約レポートは、メンテナンスタスクと構築タスクのモードの違い、およびブラックホール推論が58Kから27Kに短縮され、同時に行動完了を維持した結果を報告しています。 これは、このソリューションが実質的な推論制御能力を備えており、単純なプロンプトとして分類できないことを示しています。しかし、それは主にDeepSeek Harnessの初回モードと外部分類子を中心に展開しています。ルーティングエラーは直接的に誤った挙動帯を選択し、mixed領域は積極的に回避する必要があります。その永続タスクモデル、クロスファイルブロードキャスト、検証カバレッジ、および経験的回復は、J-Spaceと同等に包括的な統一プロトコルを形成していません。 5.3 J-Space：継続的な軌道維持と全プロセス制御 J-Spaceの潜在的な利点は、weをより強く繰り返すことではなく、軌道制御をタスクのライフサイクル全体に拡張することにあります。 | 制御層 | Anchored Standard | Routing Suite | J-Space | |------------------|-------------------|---------------|---------------------------------------------| | 初回インターフェース復元 | 強 | 強 | 非DeepSeek専用 | | タスク挙動帯選択 | 固定偏向 Minimal | 強 | passと機能ロールを介して間接的に選択 | | 軌道継続維持 | 有限 | 近接誘導 | 機能的エコー + 接続監査 | | 推論深度調整 | 非重点 | 深度自適応 | fast/full/loop + 分割制御 | | アクティブ容量とブロードキャスト | 無包括的プロトコル | 非重点 | 明確なプロトコル | | 永続状態 | 段階的状態 | 会話ルーティング状態 | Goal/Core/Verified/Open/Next | | 検証カバレッジ | 非重点 | 意思決定クロージャ | verifier + coverage + done-check | | 失敗回復 | 非重点 | anti-runawayマーク、診断再試行 | 診断再試行 |