【要対応】DeepSeek旧API廃止は7月24日|EC開発の移行5手順

投稿日: カテゴリー EC×AI活用

DeepSeek旧API廃止とは、旧モデル名が7月24日に使えなくなることです。

2026年4月24日、DeepSeek APIのChange Logに「deepseek-chatとdeepseek-reasonerの2つのモデル名を2026年7月24日15時59分(UTC)で廃止する」という告知が載りました。日本時間に直すと7月25日の午前0時59分、この記事を公開する7月19日から数えて残り5日です。商品説明の自動生成やレビュー分析のバッチにこの2つのモデル名を直書きしているEC事業者は、期限を過ぎるとAPI呼び出しが全件エラーで止まります。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル(うるチカラ運営)の現場知見にもとづき、廃止までに済ませるべき移行5手順と、作業を支援するプロンプト3本をまとめました。

7月24日15時59分(UTC)に何が止まるのか

止まるのは「deepseek-chat」「deepseek-reasoner」という2つのモデル名であって、DeepSeek APIそのものではありません。公式のModels & Pricingページには、この2つの名前が互換維持のためのエイリアス(別名)であり、現在はそれぞれdeepseek-v4-flashの非思考モードと思考モードを指している、と明記されています。2026年7月24日15時59分(UTC)を過ぎると、この別名でのリクエストは受け付けられなくなります。新しいモデルID、つまりdeepseek-v4-flashまたはdeepseek-v4-proへ書き換えたコードはそのまま動き続けます。

経緯を整理すると、DeepSeekは2026年4月24日にDeepSeek-V4系(V4-ProとV4-Flash)をAPIに投入し、その時点で「旧モデル名は3か月後に廃止する」と予告していました。deepseek-chatという名前は2024年から使われてきたもので、中身はV2.5、V3、V3.1、V3.2と入れ替わりながら、呼び出し側は同じ名前のままアップグレードの恩恵を受けられる仕組みでした。名前ごと廃止されるのは今回が初めてです。2年以上「書き換え不要」で動いてきた歴史があるだけに、「今回も放っておけば動くだろう」という油断が生まれやすい構図になっています。

日本のEC現場でDeepSeek APIが使われているのは、商品説明文の量産、レビューの要約と返信下書き、問い合わせメールの一次分類といった、1件あたりの単価を極限まで下げたいバッチ処理が中心です。理由は料金で、deepseek-v4-flashは入力100万トークンあたり0.14ドル(キャッシュミス時)、出力100万トークンあたり0.28ドルという水準にあります。GPT系フラッグシップとの単価差がどの程度あるかはDeepSeek V4とGPT-5.5のコスト比較記事で試算していますが、桁が1つ以上違う場面が珍しくありません。安いからこそ「作って忘れる」タイプの自動化に組み込まれやすく、それが今回の廃止で一斉に露見するリスクになっています。

現場で繰り返し見るのは、2年前に外注で構築したレビュー要約スクリプトが「動いているから」という理由で誰にも見直されていないケースです。担当者が異動し、どのサーバのcronで何時に何が走っているか、社内の誰も正確に説明できない。この状態で7月24日を迎えると、翌朝にレビュー返信の下書きが1件も生成されていないことに気づき、そこから原因調査が始まります。今回の廃止は面倒な作業である一方、社内に散らばった「無人運転のAIバッチ」を棚卸しする機会と捉えるのが建設的です。

EC開発の移行5手順(棚卸しからロールバックまで)

移行の作業自体は難しくありません。手順は5つで、対象が数本のバッチスクリプトに収まっていれば半日、複数システムやノーコードツールに散らばっている場合でも2〜3営業日が目安です(オルセルの支援現場での実測ベースの目安であり、環境により前後します)。順番に進めます。

手順1:旧モデル名が書かれている場所を全部洗い出す

最初にやるべきは修正ではなく捜索です。リポジトリに対して次のような検索をかけ、旧モデル名の出現箇所を一覧にします。

grep -rn \
  --include="*.py" --include="*.js" --include="*.ts" \
  --include="*.php" --include="*.env*" --include="*.yml" --include="*.json" \
  -e "deepseek-chat" -e "deepseek-reasoner" .

コードだけで済まないのがこの手順の注意点です。環境変数、CI/CDの設定、サーバ上の.envファイル、Difyやn8n、Zapierのようなツールのモデル設定画面、さらに楽天RMSやAmazonのレポートと連携している中間システムの設定ファイルまで確認範囲に含めます。ある食品ジャンルの中規模店舗の事例では、コード上は1か所だった一方、ノーコードツール側の設定に2か所、外注業者管理のサーバに1か所と、計4か所から旧モデル名が見つかりました。棚卸しの抜けが1つでもあると、その1つだけが7月25日に止まります。

手順2:モデルIDを書き換え、thinkingモードを明示する

対応表は単純です。deepseek-chat相当の挙動が欲しければ「deepseek-v4-flash+非思考モードの明示指定」、deepseek-reasoner相当なら「deepseek-v4-flash(思考モードはデフォルトで有効)」に置き換えます。より高精度が必要な処理はdeepseek-v4-proという選択肢もあります。base_url(https://api.deepseek.com )とAPIキーは変更不要で、OpenAI形式のSDKもそのまま使えます。

ここで見落としやすいのが思考モードのデフォルト値です。公式のThinking Modeガイドによると、V4系モデルは思考モードがデフォルトで有効です。deepseek-chatは非思考モードのエイリアスだったので、モデルIDだけをdeepseek-v4-flashに書き換えると、挙動が「思考あり」に変わってしまいます。旧deepseek-chat互換にするには、次のように無効化を明示します。

# 変更前(deepseek-chat 直書き)
response = client.chat.completions.create(
    model="deepseek-chat",
    messages=messages,
    temperature=1.3,
)

# 変更後(deepseek-v4-flash + 非思考モードを明示 + モデル名を環境変数化)
import os
response = client.chat.completions.create(
    model=os.environ.get("DEEPSEEK_MODEL", "deepseek-v4-flash"),
    messages=messages,
    temperature=1.3,
    extra_body={"thinking": {"type": "disabled"}},
)

あわせて、モデル名は直書きせず環境変数に逃がしておくのが定石です。次にモデル名の変更イベントが来たとき、コード修正なしで切り替えられます。

手順3:パラメータと応答フィールドの互換性を確認する

書き換えたコードが「エラーなく動く」ことと「同じ挙動をする」ことは別問題です。公式ドキュメントによると、思考モードではtemperature、top_p、presence_penalty、frequency_penaltyの4パラメータが機能しません。しかもエラーにならず、黙って無視されます。deepseek-chatでtemperatureを調整して商品説明のトーンを作り込んでいた場合、思考モードのまま移行するとその調整が全部効かなくなる、という事態が静かに起きます。非思考モードを明示していれば従来どおりです。

ツール呼び出し(Function Calling)を使っているエージェント型の処理には、もう1つ確認点があります。思考モードでツール呼び出しを行うターンでは、応答に含まれるreasoning_content(思考の中身)を次のリクエストで必ずAPIに返す必要があり、返し忘れると400エラーになります。公式サンプルのとおり、応答のmessageオブジェクトをそのままmessages配列にappendする実装にしておけば安全です。

手順4:新旧の出力を並べて差分検証する

同一のプロンプト20〜30件を新旧両方のモデル指定で実行し、出力を比較します。商品説明の生成なら、文字数レンジ、薬機法・景表法に触れる表現(「最高」「No.1」「即効」など)の混入有無、敬体・常体の乱れが比較の軸です。レビュー返信の下書きなら、謝罪と感謝のバランスが崩れていないかを人の目で見ます。usage欄のトークン数も必ず記録してください。思考モードが有効なままだと出力トークンが増え、レイテンシも延びるため、ここで気づけます。検証サンプルは売れ筋だけで揃えず、型番商品、ギフト対応品、セール対象品のような条件分岐の多い商品を意図的に混ぜると、新旧の差分が表に出やすくなります。検証項目の設計は後述のプロンプト3をClaudeやChatGPTに投げると速く進みます。

手順5:本番切り替えとロールバック先の設計

環境変数でモデルIDを切り替えられる状態にしてから本番反映し、直後24時間はエラー率とトークン消費を監視します。注意すべきはロールバックの考え方です。7月24日までは「旧モデル名に戻す」ことが緊急退避として成立しますが、期限後はその選択肢自体が消滅します。ロールバック先は旧モデル名ではなく、「新モデルID+切り替え前のプロンプト・パラメータ一式」と定義し直してください。切り替え前のプロンプトと設定はタグを付けてバージョン管理に残しておきます。

移行を支援するプロンプト3本

棚卸し・コードレビュー・テスト設計の3工程は、生成AIに下働きさせると所要時間を大きく削れます。ChatGPT(GPT-5.6系)、Claude(Sonnet 5)、Geminiのいずれでも使える形で3本用意しました。中括弧の変数を自社の状況に書き換えて使ってください。

1本目は、手順1の棚卸しを網羅的にするためのチェックリスト生成です。自社では思いつかない設置場所(CI設定やノーコードツール)を先回りで挙げさせます。

プロンプト1:旧API依存箇所の棚卸しチェックリスト生成

あなたはECシステムの保守運用に詳しいエンジニアです。
DeepSeek APIの旧モデル名(deepseek-chat / deepseek-reasoner)が
2026年7月24日に廃止されるため、社内の依存箇所を漏れなく洗い出したいです。

前提:
- 事業形態:{楽天・Amazon・自社ECなどの運営形態}
- 使っている自動化:{商品説明生成/レビュー要約/問い合わせ分類 など}
- 技術構成:{言語、サーバ、ノーコードツール、外注の有無}

依頼:
1. 旧モデル名が潜んでいそうな場所を、コード・設定・外部ツール・
   外注管理領域の4分類で、確認手順つきのチェックリストにしてください
2. 各項目に「確認コマンドまたは確認画面の場所」を添えてください
3. 見落としやすい順に並べ替えてください

2本目は、手順2〜3で書き換えたコードのレビューです。thinkingモードのデフォルト値やパラメータ無効化のような「エラーが出ない非互換」を重点的に見させます。

プロンプト2:移行コードの差分レビュー

あなたはLLM APIの移行経験が豊富なコードレビュアーです。
以下はDeepSeek旧API(deepseek-chat / deepseek-reasoner)から
deepseek-v4-flash / deepseek-v4-pro への移行差分です。

{ここに変更前後のコード差分を貼る}

次の観点でレビューし、問題点を重要度順に指摘してください:
1. 思考モードのデフォルト有効化による挙動変化の見落とし
2. temperature等、思考モードで無視されるパラメータへの依存
3. ツール呼び出し時のreasoning_content返送漏れ(400エラー要因)
4. モデル名の直書き残り、環境変数化の抜け
5. リトライ・タイムアウト設定が新モデルのレイテンシに合っているか

3本目は、手順4の差分検証をテストとして定型化するものです。EC特有の観点(薬機法・景表法、モール規約)を検証項目に織り込みます。

プロンプト3:EC業務向け回帰テストケースの設計

あなたはEC事業者のAI活用を支援するQAエンジニアです。
DeepSeek APIのモデル移行(旧: deepseek-chat → 新: deepseek-v4-flash)で、
出力品質が変わっていないか確認する回帰テストを設計してください。

対象業務:{商品説明生成/レビュー返信下書き など}
商品ジャンル:{食品ギフト/アパレル/化粧品 など}

依頼:
1. テストケースを20件、入力プロンプトの要約つきで列挙してください
2. 各ケースの合否判定基準を定量的に書いてください
   (文字数レンジ、NGワードゼロ、敬体維持、出力トークン数の上限など)
3. 薬機法・景表法・モール規約に触れる表現の検出項目を必ず含めてください
4. 新旧の出力を比較する際の記録フォーマットを提案してください

移行でつまずく3つの失敗例と回避策

1つ目の失敗は、モデルIDだけ書き換えてリリースするパターンです。思考モードがデフォルトで有効なため、非思考前提だったバッチの出力トークンが膨らみ、処理時間も延びます。深夜2時に終わるはずの商品説明生成が朝までかかり、翌日の価格更新バッチと衝突した、という形で表面化しがちです。回避策は手順2のとおりthinking無効化を明示することと、切り替え後最初の実行でusageのトークン数を前回実績と突き合わせることです。

2つ目は、temperatureが効かなくなったことに気づかないままトーンが変わるパターンです。思考モードではtemperature等が黙って無視されるため、エラーは一切出ません。化粧品やサプリのジャンルでは、トーンの変化と同時に「肌質が改善」のような薬機法に触れかねない表現が混ざる方向にぶれると実害が出ます。回避策は、非思考モードで使うことに加え、生成後のNGワードチェックをコード側に常設し、モデル移行と無関係に守りを固定することです。

3つ目は、ツール呼び出しを使うエージェント処理でreasoning_contentの返送を実装しておらず、本番だけ400エラーが出るパターンです。検証環境では単発呼び出しのテストしかしておらず、複数ターンのツール呼び出しが走る本番データで初めて踏む、という順序で起きます。回避策は、応答messageをそのままappendする公式サンプル準拠の実装に寄せることと、手順4の検証にツール呼び出しを含む実データケースを最低5件入れることです。

KPI設計と費用・工数の目安

費用の基準値を押さえます。公式料金ページ(2026年7月19日時点)によると、deepseek-v4-flashは100万トークンあたり入力0.14ドル(キャッシュヒット時0.0028ドル)・出力0.28ドル、deepseek-v4-proは入力0.435ドル(同0.003625ドル)・出力0.87ドルです。コンテキスト長は両モデルとも100万トークン、最大出力は38万4,000トークンまで拡張されています。試算すると、商品説明1万件を1件あたり入力2,000トークン・出力1,000トークンで回した場合、flashなら合計6ドル前後という桁感です(キャッシュ状況で変動する概算)。移行によって単価自体が上がるわけではありません。

一方で、時間帯別の課金には注意が要ります。South China Morning Postは、DeepSeekがピーク時間帯(北京時間9〜12時・14〜18時、日本時間では10〜13時・15〜19時に相当)に約2倍の料金を課す方針だと報じました。2026年7月19日時点の公式料金ページには時間帯別の記載がなく、適用時期と対象は要確認の状態です。詳細な試算と夜間バッチへの寄せ方はDeepSeek V4のピーク時間課金とECコストの記事にまとめてあります。移行作業のついでに、バッチの実行時刻を日本時間の深夜〜早朝へ寄せておくと、報道どおりに導入された場合の影響をほぼ回避できます。

工数の目安は、棚卸しに2〜3時間、書き換えと互換確認に2〜4時間、差分検証に半日、切り替えと監視に半日で、単一システムなら合計1〜2人日です。移行後に追いかけるKPIは4つに絞るのが実務的です。API呼び出しのエラー率(切り替え前後で同水準か)、1件あたり出力トークン数(思考モード混入の検知)、平均レイテンシ、そしてNGワード検出率です。この4つを切り替え後1週間並べれば、移行の成否は数字で判定できます。

今後の展望と独自考察

今回の廃止が示しているのは、「同じ名前で中身だけ良くなっていく」エイリアス運用の時代が終わりつつあることです。OpenAIもAnthropicもバージョンを含むモデルIDでの指定が基本で、DeepSeekのdeepseek-v4-flashという命名も同じ路線に入りました。呼び出す側から見ると、中身が予告なく変わらない分だけ出力の再現性は上がります。引き換えに、モデルの世代交代のたびに今回のような移行イベントが発生する前提で、システムを設計しておく必要が出てきました。モデルIDの環境変数化と回帰テストの常備は、DeepSeekに限らない標準装備と考えるのが妥当です。

使い分けの観点では、2026年7月時点のフラッグシップはOpenAIが7月9日に公開したGPT-5.6 Sol(Axiosの報道)、Anthropicが6月30日に公開したClaude Sonnet 5という状況です。単価勝負の大量バッチはDeepSeek、判断や分析の質が売上に直結する処理は上位モデル、という住み分けは移行後も変わりません。DeepSeek側の上位構成で何がどこまでできるかはDeepSeek V4 Pro MaxをEC分析に使う記事で検証しています。

もう1つ先を見ると、この種の移行作業自体がAIエージェントの仕事になっていきます。Claude CodeのようなコーディングエージェントはDeepSeek公式もエージェント統合の対象として明記しており、「リポジトリを走査して旧モデル名を検出し、差分を作り、テストを回す」という今回の5手順は、エージェントへの委任と相性の良いタスクです。ただし手順1の「ノーコードツールや外注管理領域の棚卸し」だけは、エージェントの視界の外にあるため人の仕事として残ります。移行のたびに人が全部やる体制から、人は棚卸しと最終判断だけを持つ体制へ寄せていくのが、次の廃止イベントへの備えになります。

よくある質問

7月24日を過ぎるとどうなりますか

期限後は、deepseek-chatとdeepseek-reasonerを指定したAPIリクエストが受け付けられなくなります。公式Change Logは2026年7月24日15時59分(UTC)、日本時間で7月25日0時59分を期限と告知しています。APIキーやアカウントは無効になりません。モデルIDを書き換えれば同じキーのまま使えます。

deepseek-chatと完全に同じ挙動にする移行先はどれですか

deepseek-v4-flashを指定し、リクエストでthinkingを「disabled」に明示する構成です。旧deepseek-chatは現在deepseek-v4-flashの非思考モードのエイリアスなので、この指定が実質的な同等品になります。V4系は思考モードがデフォルト有効のため、無効化の明示を省くと挙動が変わります。

料金は移行で上がりますか

いいえ、モデルIDの書き換え自体で単価は変わりません。旧モデル名はすでにdeepseek-v4-flashを指しており、課金も同モデルの料金体系です。別途、ピーク時間帯の割増料金が報道されていますが、公式料金ページには2026年7月19日時点で記載がなく要確認です。夜間バッチ中心の運用なら報道どおりでも影響は小さくなります。

base_urlやSDKの変更は必要ですか

いいえ、必要ありません。base_urlはhttps://api.deepseek.com のまま変わらず、OpenAI互換SDKも従来どおり使えます。Anthropic形式のインターフェース(https://api.deepseek.com/anthropic )を使っている場合も同様で、変更するのはmodelパラメータの値と、必要に応じてthinking指定だけです。

deepseek-reasonerを使っていた処理はどう移行しますか

deepseek-v4-flashへの書き換えだけで、ほぼ同等の挙動になります。旧deepseek-reasonerは同モデルの思考モードのエイリアスで、V4系は思考モードがデフォルト有効だからです。推論の深さはreasoning_effortパラメータ(highまたはmax)で調整でき、精度が足りない処理はdeepseek-v4-proへ切り替える手があります。移行後は出力トークン数と処理時間を旧実績と比較してください。

エンジニアが社内にいない店舗はどうすればよいですか

外注先または利用中のツール提供元に「deepseek-chatとdeepseek-reasonerの利用有無」を今週中に確認するのが最短です。DifyやZapierのようなツール経由の利用なら、管理画面のモデル選択を切り替えるだけで済むケースが大半です。確認依頼の文面はプロンプト1をそのまま流用できます。

移行にどのくらいの工数を見込むべきですか

単一のバッチスクリプトなら半日、複数システムに散らばる構成でも1〜2人日が目安です(オルセルの支援現場での実測ベース、環境により変動)。作業時間の大半はコード修正ではなく、棚卸しと出力の差分検証に使われます。残り5日の時点であれば、棚卸しだけでも今日中に着手する価値があります。

参考文献


著者:齋藤竹紘(株式会社オルセル 編集長/5,000社以上のEC支援実績/書籍3冊)


※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/


【監修】齋藤竹紘(株式会社オルセル代表 / 19年・5,000社のEC支援実績)


投稿者: 齋藤竹紘

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。

お問い合わせ