DeepSeekのAPIで、ツールの結果を返した直後に400エラーになるなら、結果の値だけでなく、その前のassistantメッセージをどう保存したかを確認します。画面へ表示する回答だけを会話履歴へ戻す実装では、次の要求に必要な情報を落とすことがあります。
この記事は、DeepSeekのChat Completion形式でthinkingモードとtoolsを使う処理を対象に、履歴の受け渡しを点検する手順です。公式資料を基に整理しており、実APIの呼び出しは行っていません。在庫照会と記録例は説明用の架空例です。
目次
まず、失敗する要求の条件をそろえる
最初の質問が通ることと、ツールを挟んだ会話が続くことは別です。失敗一件について、API形式、モデルID、thinkingの設定、toolsの有無、何回目の要求かを確認します。別の形式やモデルへ切り替えながら比較すると、履歴を直した効果が分かりません。
公式Thinking Modeは、toolsを含む要求では過去の各ターンのreasoning_contentを返送し、文脈へ含めると説明しています。ツール呼び出しをしなかったターンも対象で、正しく返送しないと400になるという注意があります。toolsを含まない要求では、この情報を戻す必要はなく、渡しても無視されるという区別です。DeepSeek：Thinking Mode（新しいタブで開く）
古いサンプルの「思考情報は次の質問で取り除く」という処理を、tools付きの処理へ一律に適用しないでください。一方、400の原因がすべてこの欠落だとも判断しません。実際のエラー本文と送信項目を照合します。
表示用の回答と、APIへ戻す履歴を分ける
利用者へ見せる文章だけをcontentから取り出す処理と、APIの会話履歴を保存する処理は分けます。公式例は、応答のassistantメッセージを履歴へ追加し、content、reasoning_content、tool_callsを保持しています。
実装を点検するときは、次の三か所を追います。
表は横にスクロールできます
| 箇所 | 確認するもの | 起こり得る欠落 |
|---|---|---|
| 応答を受け取った直後 | assistantメッセージ全体 | contentだけを新しい辞書へコピー |
| 保存・読み出し | 保存前後のフィールド | 保存スキーマにない項目を除去 |
| 次の要求を作る直前 | 実際に送るmessages | 共通の整形処理で追加項目を削除 |
受信直後に存在したことだけでは、次回送信時まで残った証拠になりません。中間ライブラリや永続化の変換を通るなら、その前後も確認します。フィールドの有無を調べるために、APIキーや業務本文、reasoning_content全文を共有ログへ出す必要はありません。
履歴からすでに失われた内容を、担当者がもっともらしく書き足して修復しないでください。保持された元応答が参照できるかを確認し、復元できなければ、その会話を継続できると見なさず再開方法を決めます。
ツールの結果は、呼び出しと対応させる
公式Tool Callsの例は、モデルが返したツール呼び出しをassistant履歴へ追加した後、roleがtoolのメッセージへtool_call_idと結果を入れ、次の要求へ渡します。関数そのものはアプリ側が実装・実行するもので、モデルが外部処理を済ませたという意味ではありません。DeepSeek：Tool Calls（新しいタブで開く）
次は在庫照会の対応を読むための架空例です。reasoning_contentの本文や、実際のAPI応答を掲載したものではありません。
assistantの呼び出しID: call_stock_01
呼び出し先: lookup_stock
引数: 商品 P001
アプリ側の照会結果: 在庫 3 個
戻すtoolメッセージのtool_call_id: call_stock_01
この例で確認するのは、商品P001の結果がcall_stock_01に結び付いていることです。「在庫3個」を新しいuserメッセージとして追記するだけでは、同じ履歴構造になりません。複数の呼び出しが返る処理なら、一件だけを前提にした保存や対応付けがないかも見ます。
なお、公式資料はChat Completion形式について、モデルが生成していないツール呼び出しを会話の途中へ挿入する使い方をサポートしないと説明しています。欠けた呼び出しを手作りして穴埋めする修正と、実際に返された履歴を保持する修正を混同しないようにします。
一回目の成功と、次の質問までの成功を分ける
点検用には、どの境界まで確認できたかを残します。次の表は試験の設計例であり、実行結果ではありません。
表は横にスクロールできます
| 確認点 | 見ること | これだけでは分からないこと |
|---|---|---|
| 最初の応答 | assistantの必要な項目を受け取れたか | 保存後も残るか |
| ツール結果を返す直前 | 元assistant履歴とtoolのID対応を保ったか | APIが受け付けるか |
| 結果を返した後 | 応答が完了したか、さらに呼び出しがあるか | 次の利用者質問も続くか |
| 次の利用者質問 | 過去ターンを含む履歴が維持されたか | 業務回答の正確さ |
tools付きの要求である限り、最終回答を得た後のターンを含めて保持方針を確認します。「ツールを呼んだ直前のメッセージだけ残す」実装では、公式の全過去ターンという条件を満たせるとは限りません。
接続が通った後は、在庫3個という照会結果が回答へ正しく反映されるか、結果にない納期を補っていないかを別に評価します。履歴形式が正しいことと、業務として採用できる回答であることを分けます。
再試行する前に、外部処理の状態を確認する
在庫の読み取り例と異なり、送信や更新をするツールを含む処理では、最終回答が400になっても、その前の外部操作は済んでいる可能性があります。エラー後に一連の処理を丸ごと繰り返す前に、実行済みかを照合してください。
引き継ぎには、利用形式とモデル、失敗した要求の位置、保持前後の項目、呼び出しIDと結果の対応、外部操作の実行状態、不足している記録を残します。必要な情報が欠ける場合は原因未確定とし、400という数値だけから認証情報の作り直しや制限変更へ進めません。
履歴の受け渡しを直すときは、表示用の文章、継続用のメッセージ、外部操作の実行記録を分けて確認します。これにより、回答が表示されない問題を調べながら、業務の二重実行も見落としにくくなります。
参考資料
公式資料の確認日：2026年10月23日。対応条件は利用するAPI形式・モデルの現行資料と照合してください。