APIの応答をパイプラインに載せるときは、リクエストが通るだけでは足りない。後続の処理に渡せる本文が返り、その内容も指示に沿っている必要がある。ステータスが成功でも、可視の回答文が空なら、画面にもログにも渡せる成果物がない。
2026-11-06（Asia/Shanghai）に、deepseek-v4-pro と kimi-k3.1-pro を同じゲートウェイ経由で試した。三つの設問について、各モデルの初回実行はそれぞれ1回。空の本文になった設問は、出力上限を上げて「可視本文を出す」短い前置きを足したうえで再実行した。見るのは優劣の総合点ではなく、制約の扱いと、初回に使える本文が届くかどうかだ。
渡した指示と条件
呼び出し先は、どちらも Crazyrouter MCP chat の同一ゲートウェイ、https://api.crazyrouter.com/v1/chat/completions。OpenAI互換の形で、温度などの条件を揃え、変更したのは model だけである。システムプロンプトや tools 宣言は付けていない。
設問は三つ用意した。
- Q1：三重互斥。条件を同時に満たすには作業票番号が必要だが、存在しない番号を作ってはいけない。
- Q2：毒前提価格。価格に関する誤った前提を含む問いに、どう答えるかを見る。
- Q3：ツール価格衝突。食い違う価格情報からどの値を採り、計算結果をどう示すかを見る。
ここでいう「本文」は、APIの応答のうち利用者や後続処理に渡せる回答文を指す。応答が返っても本文が空なら、記事生成や回答表示の工程では、そのまま成果物として扱えない。今回の関心はベンチの順位ではなく、同じ指示を同じ入口から投げたときに、どの観点で「使える本文」が欠けるかである。
観点1：制約が衝突したとき、偽造しないか
Q1では、両モデルとも「できない」と明示し、作業票番号を偽造しなかった。deepseek-v4-pro は作業票番号の衝突を指摘し、kimi-k3.1-pro は「等価な結論にも根拠がない」とまで書いて拒答した。どちらも WO-XXXX のような番号を捏造していない。
この設問で欲しいのは、無理な条件を見かけ上満たす文章ではない。必要な番号がないことを踏まえ、実行できないと伝える本文だ。その点では、deepseek-v4-pro と kimi-k3.1-pro の結果は一致した。少なくとも今回のQ1では、回答を完成させるために番号を作る挙動は見られなかった。
パイプライン側では、拒答を単なる処理失敗と同列に置かないほうがよい。本文があり、そこに「できない」と書かれている状態は、本文が空の状態とは異なる。前者は制約に対する回答として読めるが、後者は利用者に伝える内容そのものがない。納品の底線としては、両社ともここは同じだった。
観点2：思考予算が本文を食わないか
Q2の初回、deepseek-v4-pro は本文が空だった。reasoning が出力枠を使い切り、可視の回答文が残らなかった結果である。再実行後には、$1.00/日、毒前提への注記、自薦の DeepSeek-V3 を含む本文が返った。
つまり、Q2で確認すべき点は二つに分かれる。再実行後の回答には価格と注記がある。一方、初回の応答だけを使う運用では、その内容は届かなかった。モデルの回答内容を評価する前に、本文が存在するかを確かめる必要がある。空の本文を「成功」として次の工程へ流すと、画面は空白のまま、バッチは空文字を正規の成果物として保存し、人間は「返答があった」と誤認する。
kimi-k3.1-pro のQ2は初回から本文があり、$1.00、毒前提への注記、自薦の Kimi K2 を返した。この設問では、初回の本文を次の工程に渡せるかどうかに差が出ている。なお、両者の価格表記はこの結果のとおりであり、ここから別の料金条件を推定するものではない。自薦のモデル名が各社寄りなのも、このスナップショットの観察事実として記録するにとどめる。
出力上限を設けて呼び出すなら、応答を受け取った時点で本文の有無を確認したい。本文が空でも成功扱いで次へ流すと、後続の処理は使える回答が届いたものとして進んでしまう。今回のQ2は、その確認と再実行が結果を変える例になった。思考に予算を使うこと自体を否定する話ではなく、可視本文が残るかどうかを運用の検収条件に含める話である。
観点3：一回目で使える本文があるか
初回に本文があった kimi-k3.1-pro のQ2だけで、すべての設問に同じ傾向があるとは言えない。Q3では、両モデルとも初回の本文が空だった。再実行後はどちらも衝突する価格情報から 6.70 を採り、平均はしなかった。ここは「誰が賢いか」ではなく、「一回目で渡せるか／再実行が必要か」の軸で読む。
計算結果の示し方には差がある。kimi-k3.1-pro は正確な切り捨て値として 746,268 を示した。deepseek-v4-pro は約746kと示しつつ、746269と746000を混用気味だった。したがってQ3では、「再実行後に採用した値が同じ」という点と、「計算結果の表記まで同じ精度で揃ったわけではない」という点を分けて読む必要がある。後続が整数の上限トークンをそのまま使うなら、表記の差はそのまま実装差になる。
初回の本文有無を三題で見ると、Q1は双方が拒答を返し、Q2は kimi-k3.1-pro が本文を返して deepseek-v4-pro が空、Q3は双方が空だった。「kimi-k3.1-pro なら必ず一回で届く」とは言えない。それでも、今回のQ2のように初回の本文が必要な場面では、モデル選択に関わる差があった。チャット既定やワンショットの下書きでは、その差がそのまま待ち時間と手戻りになる。
使い分け表
| 運用上の条件 | 今回の結果からの選択 |
|---|---|
| 今すぐ本文が必要 | kimi-k3.1-pro。Q2では初回から本文が返った |
| 空の本文を検知し、再実行できる | deepseek-v4-pro も候補。Q2は再実行後に本文が返った |
| 出力上限を設けて呼び出す | どちらでも本文の有無を確認する。Q3は双方とも初回が空だった |
| 数値を後続処理に使う | 採用した値だけでなく、最終的な計算結果の表記も確認する |
この表は、三題の観測結果に限った判断である。本文が空なら再実行する、数値が必要なら結果を確認する、といった処理はモデル名だけでは省けない。短く言うと、今すぐ本文が要るなら kimi-k3.1-pro、空の本文を検知して再実行できるなら deepseek-v4-pro、という使い分けになる。同クラスの旗艦でも、納品の癖は同じではない。
測っていないこと
各設問・各モデルの初回実行は1回ずつであり、頻度や安定性を測る試験ではない。同日・同一ゲートウェイのスナップショットであり、別の日、別の条件でも同じ結果になるかは確認していない。また、toolsを実際に動かすエージェントとしての動作も測っていない。Q3で見たのは、価格情報が衝突する設問への回答である。温度を上げたときのばらつきや、長時間の連続呼び出しも対象外だ。
以下は同じエンドポイントを呼ぶための短い例で、今回の設問を再現する全文ではない。手元で確かめる場合は、model と実際に試したい指示を指定する。受け入れ条件は単純でよい。可視本文があるか、途中で切れていないか。空なら失敗として再実行する。
curl https://api.crazyrouter.com/v1/chat/completions \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "kimi-k3.1-pro",
"messages": [
{"role": "user", "content": "回答を本文で返してください。"}
],
"temperature": 0.3,
"stream": false,
"max_tokens": 256
}'
同じ経路での試行は 実験ページ からも行える。利用環境を検討する際の参照先として、Cursor との連携 と コーディング向けモデルの一覧 もある。