DeepSeek V4 Pro: ChatCompletions、Anthropic Messages、Responses API 3種のAPI形式を徹底比較

DeepSeek-V4-Pro-0813は2026年8月12日に一般提供を開始しました。これは、常に最新のdeepseek-v4-proモデルIDの下でhttps://api.deepseek.comから提供されており、より安価なdeepseek-v4-flashも利用可能です（Unite.AIが一般提供の発表を報道しました）。主な仕様は強力です。1Mトークンのコンテキストウィンドウ、最大384Kの出力、ツール呼び出し、構造化出力、およびモデルの推論トレースをreasoning_contentフィールドで表示する3つの思考モードを備えています。

珍しいのは仕様ではありません。1つのモデルが3つのAPI方言で応答することです。V4 Proは、OpenAI ChatCompletionsリクエスト、Anthropic Messagesリクエスト、およびDeepSeek独自のResponses APIへのリクエストを受け入れます。既存のOpenAI SDKコードをこれに向けたり、Claudeで構築されたエージェントをこれに向けたり、Codexスタイルのエージェントループに組み込んだりできます。同じ重みで、3つのワイヤーフォーマットです。

DeepSeek V4 Proの3つのAPIフォーマットを並べて説明したものはまだありませんでしたので、このガイドで説明します。実際に形式が異なるフォーマットごとの動作するリクエスト例、比較表、そして共有環境変数を持つ単一のApidogプロジェクトからこれら3つすべてをテストする方法を紹介します。アカウントの設定と最初の呼び出しのウォークスルーについては、DeepSeek V4 APIの使用方法から始めてください。

要約

• DeepSeek-V4-Pro-0813はhttps://api.deepseek.comでdeepseek-v4-proの背後でGAされており、deepseek-v4-flashはより低価格で同じインターフェースを共有しています。
• 3つのAPIフォーマットに対応しています：OpenAI ChatCompletions（base_urlを変更することで標準のopenai SDKで動作）、Anthropic Messages（Claude Codeを含むanthropic-SDK形式のリクエストのドロップイン）、そしてDeepSeek独自のResponses API（Codexスタイルのエージェントとステートフルなワークフロー向けに構築された最新のインターフェース）。
• 仕様：1Mコンテキスト、384K最大出力、ツール呼び出し、構造化出力、reasoning_contentを持つ3つの思考モード。
• 料金：入力トークン1Mあたり$0.435（キャッシュミス時）、キャッシュヒット時は1Mあたり$0.003625、出力1Mあたり$0.87。
• フォーマットは、システムプロンプトの配置、max_tokensの意味、ツールスキーマの形式、ストリーミングイベントの形式が異なります（詳細は以下）。
• 1つのApidogプロジェクトで{{DEEPSEEK_API_KEY}}とフォーマットごとのベースURL変数を設定することで、同じプロンプトを3つすべてに送信し、生の応答を比較できます。

なぜ1つのモデルが3つの方言を話すのか

これはエコシステム互換性戦略です。各APIフォーマットはDeepSeekが無料で利用できるツールセットの既成ベースを意味します。ChatCompletionsは共通語であり、何千ものSDKやフレームワークが1行のbase_url変更でV4 Proを呼び出すことができます。Anthropic MessagesフォーマットはClaudeを基盤として構築されたチームをターゲットにしています。エージェント、評価ハーネス、Claude Codeのようなツールは、コードを書き直すことなくV4 Proを指すことができます。そしてResponses APIはDeepSeekのエージェントに対する賭けです。deepseek-v4-flashは7月にCodexスタイルの互換性のためにこれを獲得し、V4 Proは一般提供開始時からこれを搭載しています。これはステートフルで多段階のワークフローを可能にします。

V4 Proはアグリゲーターにも掲載されています（deepseek-v4-pro-0813のOpenRouterページを参照）。しかし、3つのフォーマットという話は、この記事でテストするDeepSeekのファーストパーティAPIに適用されます。V4ファミリーのより広範な概要については、DeepSeek V4の使用方法を参照してください。

フォーマット1：OpenAI ChatCompletions

これはすでにおなじみの形式です。messages配列があり、システムプロンプトはrole: "system"として最初のメッセージに含められ、オプションで最大トークン数も指定できます。設定は3つのフォーマットすべてで同じなので、一度だけ説明します。DeepSeek APIキー、DeepSeekのベースURL、そしてmodelをdeepseek-v4-pro（またはdeepseek-v4-flash）に設定します。変更されるのはエンドポイントと本文の形式だけです。

標準のopenai SDKを介したPythonコード：

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_DEEPSEEK_API_KEY",
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {"role": "system", "content": "あなたは正確な技術文書作成者です。"},
        {"role": "user", "content": "冪等性キーを2つの文で説明してください。"}
    ],
)

print(response.choices[0].message.content)

新しいSDKも、新しい認証方式もありません。ツール呼び出しは、おなじみのネストされたfunction形式を使用し、ストリーミングはchat.completion.chunkデルタとして到着し、data: [DONE]で終了します。これはOpenAIの仕様と一致します。V4固有の注意点として、思考モードがアクティブな場合、推論トレースはcontentとは別のreasoning_contentフィールドで到着するため、パーサーはこの追加フィールドを許容する必要があります。

いつこれを使うべきか：既存のOpenAIツール、LangChainスタイルのフレームワーク、またはすでにChatCompletionsに対応している社内ライブラリがある場合。これは最も摩擦の少ないパスであり、検証も最も簡単です。リクエストの構造はApidogでChatGPT APIをテストする方法で説明されているものと同一で、ホストとモデルだけが入れ替わります。

フォーマット2：Anthropic Messages

Messagesフォーマットは一見似ていますが、単純な翻訳では破綻するような違いがあります。Anthropicの仕様から継承された3つの違いが最も重要です。

1. システムプロンプトは配列から外されます。これはトップレベルのsystemパラメーターであり、messages配列にはuserとassistantの交互のターンのみが含まれます。
2. max_tokensはオプションではなく必須です。すべてのリクエストで明示的な出力バジェットを宣言する必要があります。V4 Proの最大出力384Kは非常に寛大ですが、それを明記する必要があります。
3. ツール定義はフラットです。各ツールはトップレベルでname、description、およびinput_schemaを保持し、ネストされたfunctionラッパーはありません。ツール呼び出しはtool_useコンテンツブロックとして返され、結果はユーザーメッセージ内のtool_resultブロックとして返します。

anthropic SDKを介したPythonコード、Messagesリクエスト：

import os
import anthropic

client = anthropic.Anthropic(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com/anthropic", # Anthropic互換ベース; DeepSeekのドキュメントで現在のパスを確認
)

message = client.messages.create(
    model="deepseek-v4-pro",
    max_tokens=8192,
    system="あなたは正確な技術文書作成者です。",
    messages=[
        {"role": "user", "content": "冪等性キーを2つの文で説明してください。"}
    ],
)

print(message.content[0].text)

応答は単一の文字列ではなくコンテンツブロックのリストとして返され、ストリーミングは均一なチャンクではなく、message_start、content_block_delta、message_stopといった型付きSSEイベントを使用します。認証は、ベアラートークンではなくAnthropicの仕様のヘッダー規則に従います。DeepSeek APIドキュメントには、互換性のあるインターフェースの現在の詳細が記載されています。

実用的な利点はエージェントにあります。Claude Codeのようなツールは環境変数からエンドポイントを読み取るため、Claudeで構築されたエージェントをコードに手を加えることなくDeepSeekに向けることができます。

export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_AUTH_TOKEN=$DEEPSEEK_API_KEY
export ANTHROPIC_MODEL=deepseek-v4-pro

いつこれを使うべきか：ツールがClaude向けに構築されている場合。チームがすでにAnthropicモデルにMessages形式のリクエストを送信している場合（Claude Opus 5 APIガイドで説明されているものと同じ構造）、このフォーマットを使用すると、同じハーネス内で、同じリクエストボディとストリーミングハンドラーでDeepSeekとClaudeをA/Bテストできます。

フォーマット3：DeepSeekのResponses API

Responses APIはDeepSeekの最新のインターフェースであり、その存在理由はエージェントにあります。V4 Flashは7月にCodexスタイルのエージェントがDeepSeekモデルを駆動できるようにこれを採用し、V4 Proは提供開始初日からこれを搭載しています。リクエストの形式はOpenAI Responsesの仕様に従います。単一のメッセージ配列ではなく、input（文字列または型付きアイテムのリスト）とトップレベルのinstructionsを送信します。

curl、Responses APIリクエスト：

curl https://api.deepseek.com/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -d '{
    "model": "deepseek-v4-pro",
    "instructions": "あなたはAPIレビューエージェントです。簡潔にしてください。",
    "input": "このOpenAPIの差分をレビューし、破壊的変更をすべてリストしてください：[ここに差分]",
    "stream": false
  }'

このフォーマットを他の2つと区別する3つの点があり、これらはすべてResponsesの仕様に従っています。

• ステートはサーバーサイドで管理できます。会話全体を毎回再送信する代わりに、後続のリクエストは前の応答をIDで参照できます（仕様ではprevious_response_id）。これにより、多段階エージェントループのオーケストレーションが安価になります。
• 出力は単一のメッセージではなく、型付きアイテムのリストです。推論アイテム、テキストアイテム、ツール呼び出しアイテムが個別のエントリとして到着するため、各アイテムタイプに対して異なる動作をするエージェントに適しています。
• ストリーミングは意味論的です。生のテキストデルタではなく、ストリームは名前付きイベント（response.output_text.delta、response.completedなど）を発行するため、エージェントは正規表現でチャンクを解析することなく、ライフサイクル変更に反応できます。

ここでもツール呼び出しは存在し、ツール定義とfunction_call/function_call_outputアイテムは、どちらの古いフォーマットとも異なり、Responsesの仕様に従って整形されます。DeepSeekの実装詳細が仕様を超える場合は、api-docs.deepseek.comを真の情報源として扱ってください。

いつこれを使うべきか：エージェント型およびCodexスタイルの統合、長い多段階ワークフロー、またはサーバー管理の会話ステートと型付き出力アイテムがオーケストレーションコードを簡素化するあらゆるシステム。単なるチャット補完の場合は、必要な以上の仕組みです。

3つのフォーマットの比較

同じモデル、同じ料金体系、3つの契約。違いは完全にワイヤーレベルにあり、これは記憶に頼るのではなく、経験的に検証するのが最も簡単な種類の違いです。

1つのApidogプロジェクトで3つすべてをテストする

同じプロンプトが3つの異なる形式の応答を生成するのを見ることで、比較表では捉えきれない実装の詳細を把握できます。再現可能なセットアップは以下の通りです。

1. 1つのプロジェクトを作成し、3つのフォルダ（chat-completions、anthropic-messages、responses）を用意し、それぞれにシナリオごと（通常の補完、ツール呼び出し、ストリーミング）の保存済みリクエストを1つずつ入れます。
2. 環境変数を通じて認証情報を共有します。{{DEEPSEEK_API_KEY}}、{{BASE_URL}}、{{ANTHROPIC_BASE}}を一度定義すれば、キーのローテーションやdeepseek-v4-flashへの切り替えは1フィールドの変更で済みます。
3. 各フォーマットで同一のプロンプトを送信し、生のボディを比較します：choices[0].message.contentとコンテンツブロックリスト、型付き出力アイテムとの違い。
4. stream: trueでストリームを検査します。組み込みのSSEビューにより、匿名で[DONE]で終了するチャンク、名前付きのMessagesイベント、Responsesのライフサイクルイベントといった違いが鮮明になります。SSEデバッグが初めての場合は、SSEでAPIレスポンスをストリーミングする方法で仕組みが説明されています。
5. 統合が実際に読み取るフィールド（コンテンツパス、ツール呼び出しIDの場所、終了理由）にアサーションを追加し、DeepSeekがスナップショット更新をリリースするたびにコレクションを再実行します。

この3つのフォルダを持つプロジェクトは、生きたドキュメントとしても機能します。「Messagesのツールスキーマはどんな形だっけ？」という疑問も、実際のキャプチャされた応答を含む保存済みリクエストを見れば解決します。

移行に関する注意点

既存のコードをV4 Proに移行するのは意図的に退屈な作業であり、それがポイントです。

OpenAIから：3つの値を変更します。base_urlをhttps://api.deepseek.comに、APIキーを、モデルをdeepseek-v4-proに。メッセージの構築、ツール定義、ストリーミングハンドラーはそのままです。デプロイ前に2つのチェック：コア仕様以外のパラメーターが期待通りに動作することを確認し（推測するのではなく、テストコレクションで実行します）、応答解析がcontentの隣に表示されるreasoning_contentを許容することを確認します。

Anthropicから：ベースURLをAnthropic互換パスに、キーを、モデルを入れ替えます。Messages形式が引き継がれるため、必須のmax_tokens、コンテンツブロック、型付きストリームイベントなど、仕様準拠のクライアントはロジック変更なしで動作します。環境変数を読み込むエージェントの場合、移行は前述の3つのexport行だけで済みます。

Responses APIへの移行：これは構成変更ではなく、リクエストレイヤーの書き換えになります。どちらの古いフォーマットも機械的に変換できないためです。このAPIが提供する独自の機能、つまりサーバーサイドの状態管理と型付き出力アイテムが必要な場合に採用すべきであり、単に最新だからという理由ではありません。

どの方向への移行でもアドバイスは同じです。設定を移行し、信頼する前に回帰テストコレクションを再実行してください。この価格であれば、検証トラフィックに費やす午後数時間は、その間に飲むコーヒーよりも安く済みます。

FAQ

新しいプロジェクトはどのフォーマットを選択すべきですか？最も広範なツールサポートのためにChatCompletionsをデフォルトにしてください。スタックがClaudeネイティブの場合はMessagesを選択してください。多段階エージェントを構築しており、サーバー管理のステートが必要な場合はResponses APIを選択してください。

Claude CodeをDeepSeek V4 Proに向けることはできますか？はい、できます。ANTHROPIC_BASE_URLをDeepSeekのAnthropic互換エンドポイントに設定し、DeepSeekキーを認証トークンとして使用し、モデルをdeepseek-v4-proに設定します。これがMessages形式サポートの実用的な利点です。

ツール呼び出しと構造化出力はすべてのフォーマットで動作しますか？モデルは両方をサポートしており、各方言は独自の仕様の形式、つまりネストされた関数オブジェクト、input_schemaツール、またはResponsesスタイルのアイテムでツール呼び出しを公開します。デプロイ前にテストコレクションで各インターフェースに対する特定のスキーマを検証してください。スキーマ形式のエッジケースは、互換性のある実装が分岐するまさにその場所です。