DeepSeek V4.1 Flashの回答がクライアントによって違うのはなぜ？

二つの開発ツールに同じDeepSeek V4.1 Flashという表示があっても、同じリクエストが送られた証拠にはなりません。片方のクライアントでモデルの性能が落ちたと判断する前に、プロバイダー、実際のモデルID、プロトコル、推論設定、メッセージ、ツール定義を比較してください。本記事は、API呼び出しとコーディングエージェントを比較する開発者や、既存プロジェクトを別クライアントへ移す開発者向けです。

ここで示すのは、2026年9月14日に確認したプロバイダーの文書に基づく診断方法です。有料のモデル比較は行っておらず、以下の記録表にも実測スコアはありません。同じ入力でもモデルの回答は変わることがあります。リクエストを調べれば変数を切り分けられますが、毎回同じ出力になることを保証するものではありません。

実際に使われた接続先とモデルから確認する

DeepSeekのリリース告知は、APIのモデル名をdeepseek-flashとし、従来のdeepseek-v4-pro経路が9月14日に移行することを説明しています。保存済みのエイリアスが変わらなくても、その先のモデルが変わることがあります。観測日と、プロバイダーが公開している場合は応答に返されたモデル名を記録してください。

DeepSeekへの直接接続、集約サービス経由、サードパーティーの互換エンドポイントは別の経路です。モデル選択画面の表示から同等だと推測しないでください。接続手順はDeepSeek V4.1 API設定ガイドにあります。本記事は、接続が動いた後に挙動の違いを調べる段階を扱います。

スライダーの表示ではなく、有効な推論設定をそろえる

公式のthinkingモード文書は、対応する各インターフェースの推論制御を説明しています。Chat Completionsはthinkingとreasoning_effort、Responsesはreasoning.effortを使います。別のプロトコルのフィールドをコピーし、HTTP応答が成功したから適用されたと判断しないでください。

DeepSeekは現在の既定値を、thinking有効・high effortと説明しています。クライアントは既定値を上書きしたり、フィールドを省略したり、変換したりできます。thinkingモードでは、一部のサンプリング設定が無視される場合があります。そのためtemperatureを0にしても、有効な設定が一致する証拠にも、同一回答の保証にもなりません。

Anthropic互換の文書にも、thinking.budget_tokensやtop_kなど、無視される設定が列挙されています。クライアント画面に大きな予算が表示されても、プロバイダーに有効な大きな予算として渡るとは限りません。すべての設定をそのまま別のAPIでも使えると考えず、使用する経路の互換対応表を読んでください。

表示されないコンテキストも含めて、タスク全体を比較する

APIにプロンプトだけを渡す場合と、エージェントの会話を使う場合では実験条件が異なります。エージェントはリポジトリの指示、システムプロンプト、ファイルの抜粋、会話の要約、ツールスキーマを付けることがあります。読めるファイルや実行できるコマンドにも制限があるかもしれません。こうした差は、モデルの重みが変わらなくても回答に影響します。

小さなプロジェクトの使い捨てコピーで、新しい診断用の会話を始めます。同じ入力ファイルと、文章で定めた同じ合格条件を使ってください。要約を経た長い会話と、元のタスクをそのまま含む新しい会話を比較するのは避けます。履歴を切り詰めたりコンパクションしたりしたかを記録し、チャット画面に見えるものが送信内容のすべてだと思わないでください。

リクエストログを調べる場合はローカルに保管し、issueで共有する前に認証情報や非公開ファイルの内容を除去します。有用な報告に必要なのは構造と問題のフィールドであり、機密リポジトリ全体ではありません。

ツール実行も結果の一部として比較する

コーディングの回答は、ツールが実行されたか、何を返したかにも左右されます。あるクライアントはテストを実行し、別のクライアントは承認待ちで停止し、さらに別のクライアントは実行失敗を短いメッセージにまとめているかもしれません。ツール名、引数、返されたエラー、その結果をモデルが受け取ったかを比較します。

DeepSeekのthinkingを使うツール処理では、reasoning_contentの保持に関するプロバイダーの要件に従います。必要な履歴を削る互換レイヤーは、同条件のテストとはいえません。これはClaudeネイティブのthinking署名とは分けて考えてください。フィールドとルールが異なります。Codex接続ガイドとClaude Code接続ガイドは、それぞれの接続経路を扱います。

小さく、繰り返せる比較記録を作る

パーサーを変更して固定のローカルテストを通す、といった結果を観測できるタスクを一つ選びます。リポジトリのスナップショット、プロンプト、合格判定のテストを固定します。有料の推論を行うなら、一度の見栄えのよい回答で勝者を決めず、各経路で複数回試してください。

変数は一度に一つずつ変えます。まず経路、次に推論設定、その後に利用可能なコンテキストとツールをそろえます。複数の項目を同時に変えると、結果がよくなってもどの変更が効いたのか分かりません。経過時間にはクライアントやツールの処理も含まれるため、そのままモデルのレイテンシとはいえません。

結論を出せない比較もある

ゲートウェイが実際のモデルを公開しない、またはクライアントから有効なリクエストを出力できない場合は、その制約を記録します。利用体験全体は比較できますが、条件を統制したモデルベンチマークとは呼べません。同様に、トークン数が違うというだけでは、プロバイダーが量子化モデルへ差し替えた証拠になりません。

リクエストが一致しても結果が変わるなら、タスクを繰り返して成功・失敗の分布を調べます。一つのクライアントだけがツール呼び出し後に失敗する場合は、そのメッセージ列を残し、バージョンとリクエストIDを添えて該当クライアントまたはプロバイダーに報告します。モデルの能力が下げられたと決めつけず、範囲を絞った再現例を優先してください。

よくある質問

同じモデル名なら、同じ動作になりますか？

いいえ。経路、既定値、指示、履歴、ツールが異なる場合があります。同等のリクエストでも出力は変わり得ます。品質を比べる前に、実際に何が動いたかを確かめてください。

すぐにプロバイダーを変えるべきですか？

先に、問題がプロバイダー、リクエスト変換、クライアントの履歴のどこにあるかを調べます。経路変更は診断の変数であり、修正を保証するものではありません。料金やデータの扱いも変わる可能性があります。

古い保存済み会話と、新しいモデルエイリアスを比較できますか？

まずエイリアスの移行と会話履歴を記録します。古い表示名は、モデルのバージョンを固定する確実な方法ではありません。また、長い会話には新しい会話にはないコンテキストが含まれる場合があります。