企業が DeepSeek API を調達するとき、話は「いくらチャージするか、単価はいくらか」の 2 点に単純化されがちです。しかしこの API を長期的に使えるかを本当に決めるのは、別の事項です。アカウントは誰に帰属するのか、利用枠をどう配分するのか、データ条項が社内審査を通るのか、請求書を計上できるのか、コストを予測できるのか。
DeepSeek のインターフェースは OpenAI 互換に近い形で、移行コストは高くありません。そのため試用はすぐ始められますが、その速さゆえに調達手続きを飛ばし、個人アカウントで動かし始めるチームも少なくありません。そして業務が拡大してから、権限、契約、請求がかみ合っていないことに気づきます。本記事では実行可能な調達チェックリストを示し、アカウント、利用枠、コンプライアンス、コスト、契約の順に整理します。
注記：DeepSeek はその権利者の商標です。本記事は 2026 年 10 月時点の一般的なインターフェース形態を例にしており、モデル、価格、データ条項は公式ドキュメントとサイト内のモデル価格を基準とします。本文では単価を固定値で示しません。
一、調達チェックリストを 5 つに分ける
| モジュール | 確認すべき問題 | 提出資料 |
|---|---|---|
| アカウントと権限 | 契約主体は誰か、キーをプロジェクトごとにどう分けるか | アカウント台帳、キー一覧 |
| 利用枠とレート制限 | プリペイド残高、同時実行、失敗時の再試行 | 予算表、アラート設定 |
| コンプライアンスとデータ | データが保存されるか、学習に使われるか | 条項の控え、データ処理契約 |
| コスト | 入力・出力の構成、キャッシュヒット、再試行 | コストモデル、月次照合表 |
| 契約と請求書 | 契約主体、通貨、請求書の種類 | 契約書、請求書、振込控え |
5 つのうちどれか 1 つでも口頭確認だけに頼ると、後で手戻りが発生します。コンプライアンスと請求書は社内手続きが必要な場合が多いため、技術接続の前に並行して開始することをすすめます。
二、アカウントと権限：個人アカウントで企業業務を引き受けない
- 企業ドメインのメールで登録し、アカウントを会社の主体に紐づけ、担当者の退職後に復旧できなくなる事態を避けます。
- 管理者を少なくとも 2 名設定し、二要素認証を有効にし、重要な操作の記録を残します。
- 環境ごとにキーを分けます。本番、テスト、開発でそれぞれ 1 セットとし、共用しません。
- キーはサーバー側の環境変数またはシークレット管理サービスに置き、フロントエンド、コードリポジトリ、チャット履歴には入れません。
- 各キーに担当者、用途、作成日時を記録し、四半期ごとに棚卸しします。
- 外部委託やプロジェクト終了時には、契約精算を待たずにキーを即時失効させます。
コンソールでプロジェクトやアプリケーションごとにキーを管理する具体的な方法は、現在の画面を基準とします。画面が変わっても原則は同じです。1 つのキーは 1 つの環境だけに使う。そうすれば問題発生時に素早く特定し、被害を止められます。
三、利用枠とレート制限：プリペイドでも上限がないわけではない
DeepSeek API は通常、プリペイド残高と従量課金を組み合わせた方式で、残高を使い切るとリクエストが失敗します。調達時は「いくらチャージできるか」だけでなく、次の 4 つの制御項目を確認します。
| 制御項目 | 推奨する方法 | 目的 |
|---|---|---|
| 口座残高 | 1 か月の予想使用量の 1〜2 倍を維持 | 過大な滞留と途中の供給停止の両方を避ける |
| プロジェクト予算 | 業務ラインごとに分割し、個別に上限を設定 | 1 つの実験がチーム全体を圧迫するのを防ぐ |
| 同時実行と速度 | 平均値ではなくピークで負荷テスト | 待ち行列とタイムアウトを事前に発見 |
| アラート | 残高、エラー率、遅延の 3 段階 | ユーザーへの影響前に介入 |
レート制限と待ち行列の方針はモデル、アカウント、プラットフォームの負荷によって変わります。具体的な規則は公式ドキュメントを基準とします。エンジニアリングで必要なのは「無制限の経路を探すこと」ではなく、再試行、バックオフ、フォールバック、冪等性をコードに組み込むことです。429 や 5xx に遭遇したとき、すぐ再送すると混雑を増幅させるだけです。正しい方法は指数バックオフとランダムな揺らぎを使い、最大再試行回数を設定することです。
四、コンプライアンスとデータ：調達票に 6 つの質問を明記する
- 入力と出力は保存されるか。保存期間はどれくらいか。
- API のデータは既定でモデル学習に使われるか。企業利用では無効にできるか。
- データはどのリージョンに保存されるか。越境転送に該当するか。
- データ処理契約を締結でき、双方の責任を明確にできるか。
- 子処理業者はどこか。変更時に事前通知があるか。
- セキュリティインシデントの通知期限と対応手順を契約にどう書き込むか。
これらの質問は営業の口頭説明だけで済ませず、公式条項、プライバシーポリシー、データ処理契約、セキュリティ説明を保管し、法務とセキュリティチームの審査に出します。顧客契約、コード、個人情報、財務データを扱う場合は、先にマスキングするか構造化フィールドに置き換え、生データをそのままモデルに送らないでください。
五、コスト：単価が安いだけでは請求は管理できない
DeepSeek のコストは主に 4 つで構成されます。キャッシュ未命中の入力、キャッシュヒットした入力、出力、そして再試行による追加リクエストです。コンテキストキャッシュは通常、繰り返し現れるプレフィックスのコストを下げますが、ヒット率はリクエスト構造に依存します。毎回先頭にタイムスタンプ、ランダム ID、変化する内容を挿入すると、キャッシュはほとんど効きません。
コスト削減の順序は次のとおりです。
- まず入力を圧縮する。検索では関連する断片だけを取得し、履歴メッセージは要約する。
- 次にプレフィックスを安定させる。システムプロンプトとツール定義を固定し、キャッシュヒット率を高める。
- 出力を制限する。妥当な最大出力長を設定し、構造化結果を求める。
- モデルを分離する。単純な分類や抽出には軽量モデル、複雑な推論には推論モデルを使う。
- オフライン処理をまとめる。リアルタイム性が不要な要約やラベリングは低負荷帯に回す。
- 最後にベンダー変更を検討する。手前の無駄を解消していなければ、乗り換えても同じです。
export DEEPSEEK_API_KEY="あなたのキー"
# 公式へ直結：キーと利用可能なモデルを確認
curl "https://api.deepseek.com/models" \
-H "Authorization: Bearer $DEEPSEEK_API_KEY"
# ZSQH AI Gateway 経由：OpenAI 互換入口
curl "https://ai.zhongshangqihang.com/v1/chat/completions" \
-H "Authorization: Bearer $DEEPSEEK_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"<モデル名>","messages":[{"role":"user","content":"OK とだけ返してください"}]}'
モデル名はサイト内のモデル価格ページを基準とし、サンプル内のプレースホルダーをそのまま本番に載せないでください。初回呼び出しが成功したら、返された使用量フィールドを記録し、請求と一度照合します。
六、契約、支払い、請求書
| 項目 | 公式直結 | 国内 AI ゲートウェイ |
|---|---|---|
| 契約主体 | プラットフォームのオンライン条項または企業認証主体 | 国内企業との契約 |
| 決済通貨 | プラットフォーム基準 | 人民元 |
| 請求書 | プラットフォーム規則に従って申請 | 増値税普通発票または専用発票（プラットフォーム基準） |
| 支払い方法 | プラットフォームが対応する法人向けまたはオンライン決済 | 法人向け振込またはオンライン決済 |
| 向く対象 | プラットフォームの企業認証を完了したチーム | 複数モデルの請求を統合したいチーム |
企業の支払いは法人向けで行い、契約書、注文書、振込控え、請求書を保管することをすすめます。個人の振込が企業会計に混ざると、経費精算も照合も煩雑になります。ゲートウェイを選ぶ際は単価だけでなく、サービスレベル、返金規則、データ条項の 3 点を重点的に確認してください。
七、導入時の受け入れチェックリスト
- 企業アカウントと管理者 2 名の設定が完了している。
- 本番、テスト、開発のキーが分離され、担当者が決まっている。
- 残高アラートとプロジェクト予算が設定されている。
- 最小リクエストが本番ネットワーク環境で通っている。
- 429、5xx、タイムアウトの再試行とフォールバックが監視に接続されている。
- データ条項とコンプライアンス資料が保管されている。
- 契約書、請求書、振込控えが財務に提出されている。
- 予備モデルまたは予備経路を演習し、切り替えが業務に影響しないことを確認している。
よくある質問
DeepSeek API の企業調達では契約が常に必要ですか？
会社のデータ、法人向け経費精算、対外サービスが関わるなら、契約と法人向け支払いをすすめるます。個人の少額チャージは検証向きで、企業業務を長期に引き受けるのには向きません。
プリペイド残高を使い切れなかった場合、返金されますか？
プラットフォームの条項と契約を基準とします。未使用残高、贈与枠、消費済み部分で規則が異なるため、支払い前に明確にしておき、不要になってから尋ねるのではなく、事前に確認してください。
データは学習に使われますか？
API と消費者向け製品で条項が異なる場合があり、企業版、地域、時期によっても差があります。最終的には締結したデータ処理契約と公式条項を基準とし、機密データは先にコンプライアンス審査を行います。
公式直結とゲートウェイはどう選びますか？
プラットフォームの企業認証を完了し、DeepSeek のみが必要なら直結のほうが経路が短くなります。複数モデルを 1 つの管理画面にまとめ、人民元の請求と請求書を統一したいなら、ゲートウェイのほうが手間を減らせます。費用と為替はモデル価格を基準とします。
コストは主にどこで無駄になりますか？
多いのは重複したコンテキスト、キャッシュ未命中、長すぎる出力、上限のない再試行です。まずリクエストログを見て、入力構造、キャッシュヒット、再試行回数を分解してから、最適化の順序を決めます。
次のステップ
まず ZSQH AI Gateway でテスト用キーを作成し、実際のタスクで 1 週間動かして、使用量、失敗率、タスク単価を記録してから調達規模を決めてください。モデルの可用性と価格はモデル価格を基準とします。
関連記事：
