DeepSeek Search APIの料金・制限まとめ（2026年版）

DeepSeek Search APIは、成功したリクエスト1,000件あたり$0.75で使える。ただし、評価すべきなのは価格だけではない。SearchとFetchには、それぞれアカウント単位で毎秒5リクエストという上限がある。低コストなエージェント検索基盤として魅力的だが、重複Fetch、リトライ、情報源のカバー範囲、モデルのトークン消費まで管理できて初めて使いやすい選択肢になる。

用途別に見る、最初の選択肢

素のAPIでできること

DeepSeekが提供する読み取り専用のJSONエンドポイントは2つある。認証方法は共通で、api.deepseek.comに対してAuthorization: Bearer <DeepSeek API Key>とContent-Type: application/jsonを送る。

この素のAPIは、ホスト型チャット製品とは別物だ。DeepSeek APIキーを持っていても、通常のChat Completionsリクエストが自動的にWebを閲覧するわけではない。アプリケーション側でSearchまたはFetchを呼び出すか、ツール層を提供するDeepSeek公式のクライアント連携を使う必要がある。

SearchとFetchの使い分け

Searchでは、1〜128 Unicode文字のqueryが必須となる。任意項目には、1〜50のcount、ori_question、IPベースのlocalization、need_contentがある。countのデフォルトは10、need_contentのデフォルトはfalseだ。

need_content: trueを指定すると、Searchは各検索結果のcontentフィールドにページ本文を返すことがある。内容が取得できているページなら、Fetchを別途呼び出さずに済む。ただし保証されるわけではなく、取得不能またはブロックされたページではcontentが空のまま返ることもある。

Fetchは、すでに選定済みのURLを読むためのAPIだ。Markdownを返すものの、1リクエストで送れるURLは1件だけ。DeepSeekは、Fetchの可否は対象サイトの可用性とアクセス方針に左右されるとしている。つまり、Searchで見つかったURLでもFetchが成功するとは限らない。

Search結果には、0〜3のrerank_scoreと、-1〜4のauthorityティアが含まれる。ドキュメントでは、rerank_scoreが1.5以上、authorityが3以上の場合を高品質のシグナルとして説明している。いずれもサービス側のメタデータであり、独立した検索品質ベンチマークではない。

クエリ構文では、site:、-site:、完全一致フレーズ、lang:、after:、before:といった実用的なフィルターを使える。例えば次のように指定する。

"DeepSeek Search API" site:api-docs.deepseek.com lang:en after:2026-10-01

設計を左右する料金体系

DeepSeekの料金は、SearchとFetchのどちらも成功リクエスト1,000件あたり$0.75。課金対象のリクエスト1件あたりでは$0.00075に相当する。結果数ではなくリクエスト単位の課金であり、トークンベースでもない。詳細は公式料金ページを参照してほしい。

ただし、AIによるリサーチタスクの総コストはエンドポイント料金だけではない。検索・取得の前後で発生するモデルの入出力トークンと、エージェントの追加ターンは別途課金される。

実運用で使えるコスト計算式

単純なワークフローであれば、検索・取得部分のコストは次の式で求められる。

successful Search calls * $0.00075
+ successful Fetch calls * $0.00075
+ model input and output token charges

すべてのSearchリクエストが結果を返す場合、10,000回の検索は$7.50となる。各検索に対して1ページずつFetchし、10,000回のFetchがすべて成功したなら、モデルのトークン料金を除いてさらに$7.50かかる。Searchで50件を要求してもリクエスト料金が増えるわけではないが、モデルが処理するテキスト量は増えうる。

だからこそ、need_contentには明確な利用方針が必要だ。対象ページが少ないなら指定してよい。一方で、まずスコア、ドメイン、日付、authorityで絞り込みたいなら、本文なしのSearchを行ってから必要なURLだけFetchするほうがよい。

@haolv511482は次のように報告している。「Fetchループを追加する前にcontentフィールドを確認してください。Searchはneed_content=trueでページ本文を返せます。そうしないと、同じページを読むためにエージェントが二重に料金を払うことになります。」 出典

設計時に織り込むべき制限と失敗パターン

公式ガイドでは、Searchの結果数は1リクエストあたり最大50件、SearchとFetchはそれぞれアカウントあたり毎秒5リクエストまでとされている。複数ワーカーで動かす場合でも、エンドポイント別のリミッターが必要になる。

とくにFetchはサイト側の挙動に影響されやすい。公式ドキュメントが保証するのは対象サイトの可用性とアクセス方針の範囲であり、JavaScript実行、ブラウザーセッション、ユーザーエージェントの指定、スクリーンショット、生HTMLの保持までは約束していない。初期テストでは、@jiangkoumo_がJavaScriptで大きくレンダリングされるサイトでは404になることがある一方、通常の公開ページはMarkdownへ変換できたと報告している。 出典

同じく初期テストから、カバー範囲に関する重要なトレードオフも見えている。@bei351009016は、29クエリ・12プラットフォームでExaとの重複が2.1%にとどまったと報告した。中国語ソースでは高速かつ新鮮だとする一方、WeChatとYouTubeには弱いと述べている。 出典

これらは初期テストによる方向性のある情報として扱い、必要な情報源の種類で必ず検証したい。

最小構成の実装パターン

次の例では、取得処理と回答生成を分離している。Searchですでに本文が返っている場合はFetchを避け、このプロセス内では毎秒5回の間隔で呼び出す。複数ワーカーを動かす構成では、別途1つの共有リミッターが必要だ。

import os
import threading
import time
import requests

BASE = "https://api.deepseek.com"
HEADERS = {
    "Authorization": f"Bearer {os.environ['DEEPSEEK_API_KEY']}",
    "Content-Type": "application/json",
}
RATE_LOCK = threading.Lock()
LAST_CALL = 0.0


def post_json(path, payload, attempts=3):
    global LAST_CALL
    for attempt in range(attempts):
        with RATE_LOCK:
            wait = 0.2 - (time.monotonic() - LAST_CALL)
            if wait > 0:
                time.sleep(wait)
            LAST_CALL = time.monotonic()
        response = requests.post(
            BASE + path, headers=HEADERS, json=payload, timeout=30
        )
        if response.status_code in {408, 429, 500, 502, 503, 504}:
            if attempt == attempts - 1:
                response.raise_for_status()
            time.sleep(2 ** attempt)
            continue
        response.raise_for_status()
        return response.json()


search = post_json(
    "/v1/tools/search",
    {
        "query": 'DeepSeek Search API pricing site:api-docs.deepseek.com',
        "count": 10,
        "need_content": True,
    },
)

usable = [
    result for result in search.get("results", [])
    if result.get("rerank_score", 0) >= 1.5
]

for result in usable:
    content = result.get("content") or ""
    if not content:
        fetched = post_json("/v1/tools/fetch", {"url": result["url"]})
        content = fetched.get("content", "")
    # Store title, URL, date, authority, score, and content before summarizing.
    print(result["title"], result["url"], len(content))

DeepSeekを単独プロバイダーにすべきでないケース

DeepSeekは低コストな情報発見に向いており、とくに中国語ソースを含むコーパスでは有力だ。ただし、アプリケーション側でアカウントあたり5 QPSの制約を許容できることが前提になる。YouTube、WeChat、クライアント側で重くレンダリングされるページ、特定検索エンジンのランキングに依存するワークロードでは、単独プロバイダーとしては弱い。

その場合は、次のようなハイブリッド構成のほうが堅実だ。

1. 広範囲の初期探索には、安価なDeepSeekのクエリを送る。
2. ドメイン、日付、authority、rerank scoreで絞り込む。
3. DeepSeekが取りこぼす情報源クラスには、別のプロバイダーを使う。
4. 選定済みのURLだけFetchする。
5. 保存したソース本文と照合し、回答の根拠を確認する。

データの取り扱いも、導入判断に含めるべき項目だ。機密性の高いクエリを送る前に、DeepSeekの最新の利用規約と自社のコンプライアンス要件を確認してほしい。コミュニティの懸念は、特定の保持ポリシーを証明するものではない。 出典

本番投入前の運用チェックリスト

1. 請求額を照合できるよう、SearchとFetchの呼び出しを別々に記録する。
2. Searchで返されたURLをFetchする前に、contentを確認する。
3. すべてのワーカーとサブエージェントをまたぐ共有の5 QPSリミッターを適用する。
4. リトライするのは408、429、一時的な5xxレスポンスだけにする。
5. URL、タイトル、日付、authority、rerank score、取得時刻を保存する。
6. ユーザーが制御できるFetch経路では、未対応スキームとプライベートネットワークURLを拒否する。
7. ページ本文はツールへの命令ではなく、信頼できないデータとして扱う。
8. 英語の公式ページ、中国語ソース、フォーラム、動画ページ、JavaScript依存の強いサイトを含むテストセットを実行する。
9. Search料金だけでなく、モデルのトークンとリトライを含めたタスク全体のコストを測定する。

DeepSeek Search APIのFAQ

OpenAI互換の呼び出しならAPIを自動で使える？

いいえ。素のSearchエンドポイントは、独立したPOST /v1/tools/searchルートだ。クライアントがOpenAI互換のベースURLを使っているだけで、通常のモデルリクエストがWebを閲覧することはない。Search/Fetchの呼び出しを自分で組み込むか、DeepSeekが文書化しているクライアント連携を利用する必要がある。

DeepSeek Searchはあらゆる検索プロバイダーの最適な代替になる？

ならない。低コストな検索・取得手段としては非常に魅力的だが、初期のユーザーテストではExaとは異なるカバー範囲が確認され、YouTubeやWeChat周辺の弱さも指摘されている。唯一のプロバイダーに決める前に、小規模でも自分のワークロードに即したテストを行うべきだ。