DeepSeekでCodexを動かす──OpenAI Responses APIへのネイティブ対応、互換表を全項目確認する

OpenAIのCodexをDeepSeekのモデルで動かしたい、という需要に対してDeepSeek自身が用意した回答が「Responses APIへのネイティブ対応」だ。公式チェンジログを確認すると、この対応は2026年8月13日のV4-Pro GA発表が最初ではなく、実は2026年7月31日のV4-Flash公開時点ですでに導入されていた。互換性ガイドの全項目を一次ソースから確認する。

3行まとめ

• DeepSeek APIはbase_urlをhttps://api.deepseek.comのまま、OpenAI SDKのclient.responses.create()呼び出し形式をそのまま受け付ける。対応は2026年7月31日のV4-Flash公開時から、2026年8月13日のV4-Pro GAで正式版にも拡張された
• apply_patchというCodex専用のカスタムツール呼び出しに対応している一方、previous_response_id・conversation・store・background・prompt_cache_keyなど、状態を保持する系のパラメータは軒並み非対応（ステートレスAPIとして実装されている）
• 未対応パラメータは「エラーにはならず黙って無視される」設計になっており、公式ドキュメントは「既存のResponses APIクライアントは無改造で接続できる」とその意図を明記している

対応は7月31日のV4-Flashが最初

DeepSeekの公式チェンジログ（api-docs.deepseek.com/updates）を確認すると、Responses API対応は2026年8月13日のV4-Pro GA発表で唐突に登場したものではなく、その2週間前、2026年7月31日のV4-Flash公開の時点ですでに導入されていたことが分かる。当時のチェンジログにはこう書かれている。

The official V4-Flash natively supports the Responses API format and is specifically adapted for Codex. For the specific configuration, please refer to the documentation.

（公式のV4-FlashはResponses APIフォーマットをネイティブにサポートし、Codex向けに特別に調整されている。具体的な設定については公式ドキュメントを参照のこと）

その後、8月13日のV4-Pro GA版チェンジログでも改めて「Native support for the Responses API」という項目が立てられ、同じ機能がV4-Proにも及んだ形になる。同じ日のチェンジログには、V4-Pro/V4-Flashの思考モードにlow/high/maxの3段階を導入したこと、ピーク/オフピーク課金の導入（2026年8月16日16:00 UTC施行）も並んで記載されている。既報のオフピーク課金の記事では触れていなかった、同日のもう一つの変更点がこのResponses API対応だった。

使い方はOpenAI SDKそのまま

ガイドページ（api-docs.deepseek.com/guides/responses_api）本文の書き出しはこうだ。

To meet the demand for Codex, our API now supports the Responses API format, with the base_url being https://api.deepseek.com. With a simple configuration, you can use DeepSeek models in Codex.

（Codexの需要に応えるため、当社のAPIはResponses APIフォーマットに対応した。base_urlはhttps://api.deepseek.comのままだ。簡単な設定で、CodexでDeepSeekモデルを使える）

コード例もOpenAI公式SDKをそのまま使う形になっている。

from openai import OpenAI
client = OpenAI(api_key="<your DeepSeek API Key>", base_url="https://api.deepseek.com")
response = client.responses.create(
    model="deepseek-v4-flash",
    instructions="You are a helpful assistant.",
    input="Hi, how are you?",
)
print(response.output_text)

ストリーミングにも対応しており、response.output_text.deltaなどのイベントがsequence_numberとともに順番に流れ、最後はresponse.completed/response.incomplete/response.failedのいずれかで終わる（従来のChat Completions APIにあったdata: [DONE]メッセージは存在しない）とドキュメントは明記している。

対応・非対応の線引き──ステートレスAPIという制約

ガイド本文にはパラメータごとの対応状況を示す詳細な互換表があり、DeepSeek APIがOpenAI公式のResponses API仕様のどこまでを実装しているかが分かる。主なポイントを抜き出す。

対応しているもの: model（deepseek-v4-flash/deepseek-v4-pro/deepseek-v4-flash-vision-exp）、input、instructions、stream、temperature（思考モードでは無効）、top_p（同）、max_output_tokens、top_logprobs、toolsのうちfunction/web_search、tool_choice、reasoning.effort（reasoning.summaryは受け付けるが実際には要約を生成しない）、text.format（text.verbosityは受け付けるが効果なし）、user。

非対応のもの: previous_response_id・conversation（いずれも「ステートレスAPI」であることを理由に非対応）、store（レスポンスは常にstore: falseを返す）、background、metadata、include、prompt、truncation（コンテキストウィンドウを超えるリクエストは400エラー）、service_tier、safety_identifier、prompt_cache_key/prompt_cache_retention（コンテキストキャッシュは自動管理のため不要）、context_management、stream_options。

ドキュメントはこの非対応パラメータの扱いについて、こう明記している。

Unsupported parameters are silently ignored and do not cause errors, so existing Responses API clients can connect without modification.

（非対応のパラメータは黙って無視され、エラーにはならない。そのため、既存のResponses APIクライアントは無改造で接続できる）

apply_patch──Codex互換のためだけに用意されたカスタムツール

ツール対応の表では、functionとweb_search/web_search_2025_08_26（サーバー側で実行、自動継続は最大10ラウンドまで）に加えて、customタイプのツールが1種類だけサポートされている。

Only {"type": "custom", "name": "apply_patch"} is supported (for Codex compatibility); other names return a 400 error.

（{"type": "custom", "name": "apply_patch"}のみサポートされる（Codexとの互換性のため）。それ以外の名前は400エラーを返す）

apply_patchはCodexがファイル編集に使う独自のツール形式で、これを名指しでサポートしていること自体が「Codexで動かすこと」を強く意識した実装であることを示している。file_search・code_interpreter・computer_use・mcpなど、その他の組み込みツールタイプはすべて無視される。

画像入力についてはdeepseek-v4-flash-vision-expモデルでのみinput_imageパーツが実際の画像として処理され、それ以外のモデルではプレースホルダーテキストに置き換えられるとドキュメントは説明する。画像はuser/developerメッセージ内、またはfunction_call_output/custom_tool_call_outputの出力内でのみ許可され、system/assistantメッセージ内に画像を含めると400エラーになる。

対応・非対応の一覧表

散らばっていたパラメータの対応状況を整理すると、次のようになる。

ワンクリック設定スクリプトの中身を実際に確認する

「一键配置脚本（ワンクリック設定スクリプト）」の実体はcdn.deepseek.com/api-docs/codex-deepseek-setup-en.shというシェルスクリプトで、実際に取得すると1,149行、スクリプトバージョンは1.2.0だった。Agent Integrations配下の専用ページ(quick_start/agent_integrations/codex)によれば、実行すると次の3ステップが行われるという。

1. 既存設定のバックアップ:~/.codex/config.tomlを~/.codex/backup-deepseek/へバックアップし、いつでも復元可能にする
2. モデルカタログ~/.codex/models.jsonの書き込み:コンテキストウィンドウのサイズ・対応するreasoning effortのレベル・ツール呼び出しのフォーマットなど、DeepSeekモデルのメタデータをCodexに宣言し、組み込みモデルと同じように使えるようにする
3. ~/.codex/config.tomlの変更:必要なフィールドのみを書き換える

このスクリプトはCodex CLI・ChatGPTデスクトップアプリ・VS Code用Codex拡張機能の3つが共有する設定ファイルを一度に書き換える設計になっており、どれか1つで設定すれば残り2つにも反映されるという。メニューの選択肢9番を実行すると、DeepSeek関連の設定を削除してCodexのデフォルト設定に戻せる。

同じAgent Integrationsのセクションには、Codex以外にも「DeepSeek Harness」「Claude Code」「OpenCode」「OpenClaw」「Hermes」「Reasonix」「WorkBuddy/CodeBuddy」という項目が並んでいた。DeepSeekがResponses API対応をCodexだけに向けたものではなく、複数のコーディングエージェント/ハーネスとの接続を個別に文書化する方針を取っていることがうかがえる。

「無改造で接続できる」という設計判断

対応・非対応の線引きを全体として眺めると、DeepSeekが目指したのは「Responses APIの全機能を再現すること」ではなく、「Codexが実際に使う経路だけを動くようにし、それ以外は安全に無視する」という現実的な割り切りだったように見える。previous_response_idやconversationのような、サーバー側に会話状態を保持する機能を一貫して非対応にしている点は、DeepSeek APIがステートレスな設計を保ったまま、Responses APIという別のインターフェース層だけを被せた実装であることを示している。

Codexで実際に接続して動かす検証はしていない

この記事はDeepSeek公式APIドキュメント（Responses APIガイド、Change Log、Codex向けAgent Integrationsページ）と、設定スクリプト本体のテキストを一次ソースとしている。ただし、実際にCodexの設定をDeepSeek向けに変更し、コーディングタスクを実行して動作を確認する検証は行っていない。設定スクリプト(1,149行)自体もテキストとして目視で確認した範囲にとどまり、実際にbash <(curl ...)で実行してCodex環境に適用する検証はしていない。「Claude Code」「OpenCode」「Hermes」「Reasonix」「WorkBuddy/CodeBuddy」といった、Codex以外のAgent Integrationsページの中身についても、この記事では開いていない。Zenn検索では該当する記事は0件（2026年8月27日実測)。DeepSeek V4-Pro全体としては既存記事でZenn 6件のカバーがあるが、Responses API/Codex対応という機能単体を扱った記事は見当たらなかった。

関連記事: DeepSeekが「値上げを予告」してからピーク課金制に / DeepSeekがAPIの画像入力に初対応 / 20万スターのDeepSeek Harnessを支える『Cordis』は、4年前からあった別プロジェクトだった

感想・指摘はコメント欄へ。