DeepSeek API の中継やプロキシは、「アドレスを変えるだけ」の小さな話と見なされがちです。しかし実際に選定するとき、本当に答えるべきは 4 つの問いです。お金はどう計算されるのか、ネットワークは安定しているか、問題が起きたとき誰が責任を負うのか、キーとデータの処理はコンプライアンスに沿っているか。

本記事では一般的な方案を比較し、移行と真正性確認のチェックリストを示します。具体的な価格、モデル名、可用性は、サイト内のモデル価格とサービス提供者の説明を基準にしてください。

注記：DeepSeek はその権利者の商標です。本記事は DeepSeek 公式とは提携・所属関係にありません。中継市場は変化が速いため、本記事は 2026 年 10 月時点で一般的な形を例にしており、いずれのサービス提供者への推薦や是認を示すものではありません。

一、まず定義：中継、プロキシ、ゲートウェイは同じではない

  • API 中継（relay）：リクエストを上流のモデルサービスへ転送し、課金、上限、ログを併せて提供する場合があります。市場には「中継」と称してキーを共有・転売しているだけのものもあり、安定性とコンプライアンスは運営者次第です。
  • ネットワークプロキシ：HTTP、SOCKS、リバースプロキシなどで、ネットワークの到達性だけを解決し、API の意味は変えません。キーは引き続き自分自身のものです。
  • 自社プロキシ：自分でサーバーにリバースプロキシやオープンソースのゲートウェイを配置し、キー、ログ、ルーティングを制御します。ただし上流アカウント、帯域、運用はすべて自己負担です。
  • 統合 AI ゲートウェイ：OpenAI 互換の入口で複数モデルを集約し、統一キー、請求、コンソールを提供します。商用ゲートウェイもオープンソースの自社構築もこの分類に入ります。

4 つの概念を混ぜると、ネットワークの問題をモデルの問題と誤認しやすくなります。契約前に、相手がどの層のサービスを提供し、キーは誰のものかを確認してください。

二、4 つの方案を 1 つの表にまとめる

観点 公式への直結 自社プロキシ 商用中継 統合 AI ゲートウェイ
課金の透明性 公式の請求で基準が明確 上流の請求に自社コストを加算 運営者次第で、照合が必要 サイト内の統一請求。計価規則を確認
ネットワーク安定性 ローカルの出口に影響される サーバーと回線次第 中継回線次第 ゲートウェイの回線と上流次第
レート制限と同時実行 公式アカウント単位の制限 自分で制御するが上流の制限は受ける 共有プールの場合があり、確認が必要 ゲートウェイの規則とプラン次第
モデルの範囲 DeepSeek のみ 接続する上流次第 比較的多いが、確認が必要 複数モデル。価格ページが基準
キーのリスク キーは自分の手元 キーは自分の手元 共有または転売のキーを使う場合がある 通常は専用キーを発行
運用とサポート 公式ドキュメント すべて自己負担 提供者の能力次第 コンソール、チケット、ドキュメント

すべてのチームに合う方案はありません。DeepSeek だけを使い、ネットワークと支払いが順調なら公式直結が最も直接的です。固定出口と監査が必要なら自社プロキシ、運用要員がいない場合は商用中継を評価し、複数モデルの統一請求が必要ならゲートウェイを見ます。

三、価格：「倍率」だけを見ない

中継では「公式価格 × 倍率」や「Token パッケージ」という見積もりがよくあります。倍率が低いからといって総コストが低いとは限りません。少なくとも次の 8 点を確認してください。

  1. 入力と出力を分けて計算するか、倍率は同じか。
  2. キャッシュヒットした入力は割引されるか、割引はどう計算するか。
  3. thinking が生成する推論 Token は出力に計上されるか。
  4. 失敗したリクエスト、再試行したリクエストは課金されるか。
  5. ストリーミングの usage は完全に返るか。
  6. チャージに最低金額、有効期限、返金規則はあるか。
  7. 請求書に対応するか、為替と決済通貨は何か。
  8. 使用量の統計と請求をプロジェクト、キー、モデルで分解できるか。

これらの基準を比較表に書き、同じリクエスト群で実測して初めて、実際のコストを計算できます。具体的な価格と課金方式は、サイト内のモデル価格と相手の請求を基準にしてください。

四、安定性：宣伝ではなくデータで検証する

安定性では少なくとも 6 つの指標を見ます。成功率、P50/P95 遅延、最初の Token までの遅延、タイムアウト率、429 の比率、出力速度です。テストには実際の長さのプロンプトを使い、ストリーミング、長いコンテキスト、同時実行をカバーします。

import os
import statistics
import time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["RELAY_API_KEY"],
    base_url=os.environ["RELAY_BASE_URL"],
    max_retries=0,
    timeout=60,
)

prompt = "越境 EC の注文履行における主な工程を 200 文字程度で説明してください。"
latencies, errors, usage = [], 0, []

for i in range(20):
    start = time.perf_counter()
    try:
        resp = client.chat.completions.create(
            model=os.environ["RELAY_MODEL"],
            messages=[{"role": "user", "content": prompt}],
            max_tokens=512,
        )
        latencies.append((time.perf_counter() - start) * 1000)
        usage.append(resp.usage.total_tokens if resp.usage else 0)
        print(i, resp.model, resp.usage)
    except Exception as exc:
        errors += 1
        print(i, type(exc).__name__, exc)

if latencies:
    print("成功", len(latencies), "失敗", errors)
    print("P50", statistics.median(latencies), "ms")
    print("最大", max(latencies), "ms")
    print("平均 Token", sum(usage) / len(usage))

これは最小限の探針であり、負荷試験ではありません。本番前には 7 日間連続で観察し、ピーク時と低負荷時にそれぞれ 1 回ずつ実行して、結果を公式直結と比較することをおすすめします。商用中継では夜のピークと長いリクエストを、自社プロキシではサーバーの出口と上流のレート制限を重点的に見てください。

五、キーのリスクとコンプライアンス：価格より重要

中継で最も見落とされやすいのはキーの帰属です。共有キー、転売キー、出所の不明な割当には、次の 4 つの問題が伴う可能性があります。

  • 上流がアカウントを停止したり割当を調整した場合、業務が一緒に止まり、直接異議を申し立てられない。
  • 複数のテナントが 1 本のキーを共有し、レート制限と障害が互いに影響して原因を特定しにくい。
  • リクエスト内容が第三者を通り、ログ、キャッシュ、データ保持の方針が透明でない。
  • 利用規約が転売や共有を認めていない場合があり、紛争時に契約上の根拠を欠く。

サービス提供者を選ぶときは、少なくとも会社主体、利用規約、プライバシーポリシー、請求書の発行能力、障害時の連絡先を確認してください。個人情報、秘密鍵、契約書の原文を含むリクエストを、データの行き先を説明できない中継へ送ってはいけません。金融や医療など規制の強い場面では、公式直結、プライベートデプロイ、データ処理契約を締結できるサービスを優先して評価してください。

六、移行チェックリスト：直結から中継またはゲートウェイへ

  1. 現状を記録する。成功率、P50/P95 遅延、1,000 リクエストあたりの Token 使用量、請求。
  2. モデル名とパラメータを洗い出す。thinking、max_tokens、tools、JSON 出力、ストリーミング。
  3. テスト用キーと本番用キーを新規作成し、それぞれ予算とアラートを設定する。
  4. base_url と api_key だけを変更し、ステージング環境で最小リクエストを通す。
  5. 実プロンプトを再生し、出力品質、所要時間、usage の基準を比較する。
  6. 401、402、429、5xx、タイムアウトのマッピングを確認し、再試行が障害を増幅しないようにする。
  7. 流量の 5%〜10% を段階移行し、3〜7 日観察して、公式直結をロールバック先として残す。
  8. 全量切り替え後も 1 週間は照合を続け、請求と使用量の統計が一致することを確認する。

移行時にモデル、プロンプト、ゲートウェイを同時に変えないでください。原因を切り分けられなくなります。一度に動かす変数は 1 つだけです。

七、中継が信頼できるかを見極める方法

まずレスポンスの model フィールドを見ますが、このフィールドだけを信じてはいけません。書き換えられる可能性があるからです。より確実なのは組み合わせた検証です。

検証項目 方法 異常な兆候
遅延 同じプロンプトを連続して送り、P50/P95 を比較 変動が極端、または直結より明らかに遅い状態が続く
エラー率 429、5xx、タイムアウトの比率を集計 ピーク時に集中して失敗する
使用量 レスポンスの usage と管理画面の請求を比較 一致しない、ストリーミングの usage がない
モデルの同一性 固定のテストセットで能力の境界と出力の傾向を比較 能力が明らかに低下、コンテキストが短くなる
キーの分離 専用キーか、ローテーションできるかを確認 キーの出所を説明しない
契約とサポート 主体、規約、請求書、チケットの応答を確認 個人の連絡先しかなく、利用規約がない

危険信号には、価格が長期間にわたって公式より極端に安い、無停止を約束する、使用量の明細を出さない、公式キーの提出を求める、データの保存場所を説明できない、といったものがあります。これらに当てはまる場合は、まず小流量で検証し、本番を一度に移さないでください。

八、自社プロキシがより適するのはどんなときか

自社プロキシは、固定の出口 IP、統一した監査、複数上流へのルーティング、キーを自分の手元に置くことを必要とする、エンジニアリング能力のあるチームに向きます。一般的な構成は、リバースプロキシにキー管理、レート制限、ログ、アラートを組み合わせ、上流は引き続き公式アカウントまたはコンプライアンスを満たす提供者を使う形です。

代償も計算してください。サーバー、帯域、証明書、更新、脆弱性修正、当番はすべてコストです。呼び出しが少なく、運用要員がいない場合、自社構築は商用方案より高くつくことがよくあります。自社構築でも上流のレート制限と利用規約は回避できません。

九、選択の指針：制約で並べる

  1. まずネットワークと支払いを見る。公式入口に安定してアクセスでき、チャージも問題なくできるなら、公式直結を優先する。
  2. 次に制御力を見る。固定出口、監査ログ、専用キーが必要なら自社プロキシを評価する。
  3. さらにモデルの範囲を見る。1 つの入口で複数モデルを呼ぶなら統合ゲートウェイを見る。
  4. 最後にサービス能力を見る。主体、規約、請求書、チケット、データポリシーを明確に説明できるか。

複数モデルの統一入口が必要な場合は、ZSQH AI Gateway でテストキーを作成し、通してから移行してください。具体的な価格と利用可能なモデルはモデル価格に記載されています。「安い」ことだけを基準にせず、移行と障害のコストも計算してください。

関連記事：

よくある質問

中継とプロキシの違いは何ですか？

プロキシは通常ネットワーク層の転送を指し、到達性だけを解決します。中継はさらにアカウント、課金、キーの配布を含みます。2 つの言葉はよく混用されるため、契約前にサービスの範囲を確認してください。

中継の価格が公式より安い場合、信じてよいですか？

一括購入、回線補助、割当の転売に由来する場合もあれば、共有キー、レート制限、不安定なサービスを伴う場合もあります。まず課金の基準、使用量の明細、契約条件を確認し、そのうえで小流量で実測してください。

中継がモデルをすり替えていないか、どう判断しますか？

レスポンスの model フィールドだけでは判断できません。固定のテストセットで能力の境界、コンテキスト長、出力の傾向、usage の構造を比較し、公式直結を対照として残します。能力の明らかな低下が見られたら、まず流量を止めて調査してください。

ゲートウェイへの移行でコードはどれだけ変わりますか？

多くの OpenAI SDK プロジェクトは base_url と api_key を変えるだけで済み、モデル名はゲートウェイの価格ページに合わせて調整します。thinking、tools、特定のレスポンスフィールドを使っている場合は、追加の互換テストが必要です。

企業ユーザーが最も注意すべき点は何ですか？

キーの帰属、データ処理契約、請求書と契約主体、障害時の応答、退出の仕組みです。価格も重要ですが、業務の継続性とコンプライアンス責任のほうがより重要です。