DeepSeek API の中国国内アクセス：直結・ゲートウェイ・安定性（2026）

中国国内のチームが DeepSeek API を議論するとき、論点は「つながるかどうか」に単純化されがちです。しかし本番環境で本当に影響するのは 4 点です。ネットワークが安定しているか、支払いと請求書の流れが通るか、ピーク時のレート制限を許容できるか、障害時に代替経路があるか。どれか 1 つが欠けると、単に「つながる」ことに意味はありません。

本記事では、公式直結、自社プロキシ、国内 AI ゲートウェイという 3 つの一般的な経路を比較し、タイムアウト、再試行、フォールバック、検証方法を示します。具体的なモデル、価格、接続方法はモデル価格とサイト内の説明を基準にしてください。

注記：DeepSeek はその権利者の商標です。本記事は 2026 年 10 月時点の一般的な状況を例にしており、ネットワーク環境とサービス規約は変更される可能性があります。公式ドキュメントと現地の法令を基準にしてください。

一、3 つの経路を 1 つの表で比較

観点	公式直結	自社プロキシ	国内 AI ゲートウェイ
入口	DeepSeek 公式アドレス	自社サーバーで転送	統一された OpenAI 互換入口
支払い	公式が対応するチャネル	サーバーと帯域を先に負担	サイト内チャージ、規則はページ基準
モデル範囲	DeepSeek のみ	プロキシ設定次第	複数モデルを接続可能（開通状況次第）
安定性の責任	公式とローカルネットワーク	すべて自社	サービス提供者とローカルで分担
運用コスト	低い	高い	中程度
向くチーム	単一モデル、低頻度、ネットワークが安定	ネットワーク運用能力がある	複数モデル、請求書、統一請求が必要

どの経路もすべてのチームに適するわけではありません。判断順序は、業務が中断を許容できるか、複数モデルと請求書が必要か、最後に運用要員がいるかです。

二、公式直結：どこまでなら十分か

公式直結が向くのは、DeepSeek だけを呼び出し、呼び出し量が安定し、ローカルネットワークからのアクセスが正常で、公式のチャージを完了でき、ピーク時の速度低下を業務が許容できる場合です。接続手順は複雑ではありません。

DeepSeek オープンプラットフォームで API キーを作成し、プロジェクトごとに名前を付けます。
キーはサーバー側の環境変数に置き、フロントエンドやリポジトリには書きません。
curl で最小リクエストを通し、Base URL とモデル名を確認します。
SDK で接続タイムアウト、読み取りタイムアウト、再試行の上限を設定します。
各リクエストのモデル、Token、所要時間、エラー種別を記録します。

export DEEPSEEK_API_KEY="sk-あなたのキー"

curl "https://api.deepseek.com/chat/completions" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-chat",
    "messages": [{"role": "user", "content": "OK とだけ返してください"}],
    "max_tokens": 16
  }'

このコマンドがときどきタイムアウトするものの、別のネットワークでは正常になる場合、問題はキーではなくローカルの出口や DNS にある可能性が高いです。まずリクエスト時刻とエラー情報を残し、そのうえで回線を変えるべきか判断します。

三、自社プロキシ：出口は解決するが容量は解決しない

自社プロキシの一般的な方法は、公式 API に到達できるサーバーでリバースプロキシを立て、リクエストを DeepSeek に転送するものです。「ローカルネットワークからのアクセスが不安定」という問題の一部は解決しますが、新たな作業が発生します。

プロキシサーバー自体が単一障害点となり、停止するとすべてのリクエストが同時に失敗します。
TLS、認証、アクセス制御を扱い、プロキシの悪用を防ぐ必要があります。
ログ、レート制限、監視がないと、問題が起きたときに原因を特定できません。
転送が 1 段増えるため遅延が増え、ストリーミング出力の初回 Token 時間が長くなる可能性があります。
ネットワークとコンプライアンスの責任は依然としてチームにあります。

プロキシを継続的に保守する要員がいない場合、自社プロキシは「一時的な対策」から「長期的な負債」になりがちです。過渡期の手段としては使えますが、唯一の入口にはしないことをすすめます。

四、AI ゲートウェイ：複数モデルと不安定さを 1 つの入口に集約する

国内 AI ゲートウェイの価値は単なる「中継」ではなく、キー管理、チャージ、請求、モデル切り替え、障害対応を 1 か所にまとめることにあります。複数モデルを使うチームにとって最も直接的な変化は、業務コードが OpenAI 互換の入口を 1 つだけ認識し、モデル変更時にコードではなく設定を変えるだけで済むことです。

export ZSQH_API_KEY="sk-あなたのキー"

curl "https://ai.zhongshangqihang.com/v1/chat/completions" \
  -H "Authorization: Bearer $ZSQH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-chat",
    "messages": [{"role": "user", "content": "ゲートウェイの役割を 1 文で説明してください"}],
    "max_tokens": 128
  }'

ゲートウェイを選ぶ際は 5 点を確認します。使いたいモデルに対応しているか、課金とチャージの規則が明確か、利用明細が提供されるか、障害時にどう通知されるか、データ条項が自社のコンプライアンス要件を満たすか。「呼び出せるかどうか」だけを見てはいけません。

五、安定性は自前で作る：タイムアウト、再試行、フォールバック

どの経路を選んでも、クライアント側の保護が必要です。次の順序で設定することをすすめます。

接続タイムアウトと読み取りタイムアウトを分ける：接続は短め、読み取りは長めにし、長文や推論タスクは別設定にします。
再試行はバックオフ付きで：429、5xx、タイムアウトのみ再試行し、指数バックオフとランダムな揺らぎを加え、最大回数を設定します。
同時実行数を制御する：バッチ処理はキューでピークを平準化し、正時に一斉に集中させません。
フォールバックモデルを用意する：基幹業務は予備モデルや予備経路への切り替えを許容しますが、出力差は受け入れる必要があります。
サーキットブレーカーを入れる：連続失敗がしきい値に達したらリクエストを一時停止し、再試行の嵐を防ぎます。
冪等性を確保する：副作用のある業務は状態を確認してから再送し、むやみに再試行しません。

import httpx
from openai import OpenAI

client = OpenAI(
    api_key="sk-あなたのキー",
    base_url="https://ai.zhongshangqihang.com/v1",
    timeout=httpx.Timeout(connect=5.0, read=120.0, write=30.0, pool=10.0),
    max_retries=2,
)

タイムアウトの数値に統一基準はなく、業務の許容度とタスクの長さに合わせて調整します。重要なのは、リクエストを無限に待たせないこと、失敗直後に並列で一斉再送しないことです。

六、1 週間で 1 本の経路を検証する

指標	記録方法	注目点
成功率	非 200 応答の割合を集計	ピーク時間帯に集中していないか
遅延	p50、p95、初回 Token 時間を記録	テール遅延が体験に影響していないか
レート制限	429 の回数と発生時刻を集計	クォータの問題かトラフィックの急増か
ネットワークエラー	DNS、TLS、接続タイムアウトを記録	ローカル出口の問題か
品質	固定タスクセットを人手で抽査	経路変更後に出力が一致するか

検証では少なくとも平日のピークと夜間の低負荷帯をカバーします。毎日同じ時間帯に同じリクエスト群を 7 日間連続で実行するほうが、1 回の負荷テストより参考になります。

七、支払い、請求書、コンプライアンス

法人向けの支払いと請求書が必要なチームは、サービス提供者の請求規則と着金時期を事前に確認します。
顧客データを扱う場合は、データ条項を先に読み、入力が保存されたりサービス改善に使われたりしないか確認します。
キーは環境ごとに分け、本番キーはフロントエンドにも公開リポジトリにも入れません。
呼び出しログと請求記録を保管し、財務照合とセキュリティ監査に備えます。
越境転送と業界規制の要件は、現地法令と社内のコンプライアンス手順に従って確認します。

よくある質問

中国国内からの直接接続は安定していますか？

ローカルネットワーク、時間帯、公式側の負荷に依存し、一律の答えはありません。本番環境では単一経路に依存せず、少なくともタイムアウト、再試行、予備経路を用意してください。

ゲートウェイを使うと遅くなりますか？

転送が 1 段増えることで若干の遅延が加わる可能性はありますが、ゲートウェイは一般により安定した入口と障害時の切り替えを提供できます。同じリクエスト群で直結とゲートウェイをそれぞれ測定し、1 回のリクエストではなく p95 と成功率を比較してください。

自社プロキシはすべてのチームに向きますか？

向きません。継続的なネットワーク運用、セキュリティ設定、監視が必要です。専任の保守がいない場合、プロキシ自体が新たな障害点になります。

1 つのキーで複数モデルを呼び出せますか？

ゲートウェイ方式では通常可能で、モデルはリクエスト内で指定します。具体的な範囲はサイト内の価格ページとコンソールを基準にしてください。公式直結のキーは、公式が公開しているモデルだけを呼び出せます。

問題がローカルと上流のどちらにあるか判断するには？

まず最小リクエストで試し、次にネットワーク、キー、入口をそれぞれ変えて検証します。リクエスト時刻とエラー情報を残せば、DNS、TLS、認証、レート制限、上流障害を素早く切り分けられます。

次のステップ

まず ZSQH AI Gateway でテスト用キーを作成し、同じリクエスト群で直結とゲートウェイの成功率と遅延を比較してから、本番経路を決めてください。モデルと価格はモデル価格を基準とします。