DeepSeek V4 PreviewとV3.2の違い：1Mコンテキスト、Pro/Flash、API移行の注意点

1. いちばん大きく見える差分は100万トークンのコンテキスト

V4 Previewで最も分かりやすい新要素は、100万トークンのコンテキストです。 ここでいうコンテキストは、1回のリクエストでモデルが参照できる入力や履歴の大きさを指します。実務では、リポジトリ内の多数のファイル、長い技術文書、システムログ、長期の会話履歴、複数ステップにまたがるエージェント処理を一度に扱いたい場面で効いてきます。

ただし、長文対応の流れがV4で突然始まったわけではありません。先行するDeepSeek-V3.2-Expは、長いコンテキストでの学習と推論をより効率的にするDeepSeek Sparse Attentionを導入した実験モデルとして説明されていました。 つまり、V3.2-Expは長文コンテキスト方向の重要な実験で、V4 Previewはそれを新世代モデルの中心的な特徴として打ち出した、と見るのが自然です。

2. V4-ProとV4-Flashで、品質重視と効率重視を分けて試せる

V3.2世代では、変更履歴にDeepSeek-V3.2とDeepSeek-V3.2-Specialeが並んでいました。 V4 Previewでは、モデルラインがDeepSeek-V4-ProとDeepSeek-V4-Flashに整理されています。

V4 Previewページによると、V4-Proは総パラメータ1.6T、アクティブパラメータ49B、V4-Flashは総パラメータ284B、アクティブパラメータ13Bです。 これにより、難しい推論や複雑なコード理解ではV4-Proを、リクエスト数が多くレイテンシやコスト、スループットも重い制約になる用途ではV4-Flashを、という形で検証計画を立てやすくなります。

ただし、モデル名だけで選ぶのは禁物です。同じプロンプト、同じ評価データ、同じ出力トークン上限、同じ採点基準で、V3.2、V4-Flash、V4-Proを横並びに測ってから、デフォルトモデルを決めるべきです。

3. エージェント型コーディングがより前面に出た

DeepSeek V3.2は、エージェント用途にとってすでに重要なリリースでした。V3.2のリリースは、thinkingとtool-useを組み合わせる方向を強調しているためです。 つまりV3.2は、単発の回答だけでなく、推論し、ツールを呼び、結果を読み、次の処理へ進むワークフローを意識したモデルとして位置づけられていました。

V4 Previewはその延長線上にありますが、より明確にエージェント型コーディング、つまりコードの文脈を読み、計画し、編集し、複数ステップをまたいで進めるワークフローを打ち出しています。

したがって、差分は「V3.2はエージェント不可、V4で初めて可能になった」という話ではありません。より正確には、V3.2がreasoningとtool-useの土台を示し、V4がそれを長文コンテキストとコーディングエージェントの方向へ広げようとしている、という整理です。

4. ベンチマークは「参考信号」であって、性能保証ではない

DeepSeekは、V3.2 ReleaseとV4 Preview Releaseの双方でベンチマークや性能面の位置づけを公表しています。 また、Sebastian Raschkaによる外部の技術解説も、V3.2について性能面とopen-weightとして入手できる点を注目点として取り上げています。

ただし、ここで参照できる情報の中心は、公式リリースノート、API文書、公開情報に基づく技術分析です。アップグレードの方向性をつかむには有用ですが、自社・自チームの実ワークロードでの内部ベンチマークを置き換えるものではありません。

本番環境で問うべきなのは、一般論としてどちらが強いかではなく、自分たちのプロンプト、自分たちのデータ、トークン予算、応答時間のSLA、品質評価基準でどちらが良いかです。そこを測っていない段階では、V4は有力な検証候補であっても、即座に標準モデルへ置き換える前提にはしないほうが安全です。

5. APIのエイリアス変更は、モデル性能以上に見落としやすい

V4 Previewに伴い、API利用者が必ず確認すべき変更があります。DeepSeekは、deepseek-chatとdeepseek-reasonerが現在deepseek-v4-flashのnon-thinking/thinkingにルーティングされており、2026年7月24日15:59（UTC）後に完全停止してアクセスできなくなると告知しています。

これは重要です。以前のAPI文書では、deepseek-chatとdeepseek-reasonerはDeepSeek-V3.2に対応すると説明されていたからです。 本番システムが具体的なモデルIDではなくエイリアスを呼んでいる場合、開発者が意図しないタイミングでモデルの挙動が変わる可能性があります。

統合面では、DeepSeek APIはOpenAI互換のAPI形式を採用しており、エンドポイント設定を変更すればOpenAI SDKやOpenAI API互換ソフトウェアから利用できると説明されています。 さらにDeepSeekはAnthropic API互換の文書も用意しており、max_tokens、stream、system、temperature、thinkingなどのフィールドについて対応状況を示しています。

移行チェックリストは、少なくとも次のように組むとよいでしょう。

1. コードベース、設定ファイル、環境変数、シークレットを確認し、deepseek-chat、deepseek-reasoner、または明示的なモデルIDのどれを呼んでいるかを洗い出す。
2. reasoningを使うワークフローでは、thinkingとnon-thinkingの両方でプロンプトを再テストする。
3. 実データで、レイテンシ、コスト、エラー率、タイムアウト率、回答品質を測り直す。
4. 2026年7月24日15:59（UTC）の停止期限より前に、旧エイリアスから移行する。
5. OpenAI互換レイヤーやAnthropic互換レイヤーを使っている場合は、利用中のAPIフィールドが想定どおり処理されるか確認する。

DeepSeek V3.2からV4へ移行すべきか

V4を試す価値が高いのは、非常に長いコンテキストが必要な場合、コーディングエージェントを構築している場合、難しいタスクでV4-Proを評価したい場合、または大量リクエストのワークロードでV4-Flashのバランスを測りたい場合です。

一方で、現在のパイプラインが安定しており、100万トークン級のコンテキストを必要としていない、あるいは本番環境の切り替え前に社内ベンチマークを整えたい段階なら、V3.2を一時的なベースラインとして残す判断も合理的です。

短く言えば、V3.2はreasoningとtool-useの前進、V4 Previewは長文コンテキスト、V4-Pro/V4-Flash、エージェント型コーディングへの次の一歩です。 開発チームにとっては、モデル品質そのものだけでなく、旧APIエイリアスから期限内に移行する計画まで含めて評価する必要があります。