DeepSeek Search APIの料金：1,000回あたり$0.75は実際いくらかかるのか

DeepSeek Search APIの料金はいくらですか？

私はRamaで、eeselでインテグレーションとAPI周りの実装を担当しています。検索ツールをエージェントに組み込む作業をたくさんしてきましたが、パターンはいつも同じです。1回あたりの価格は小さく見えるのに、本当の請求額は別のところに現れます。そこで、計算を始める前にDeepSeekの公式ドキュメントを端から端まで読みました。

DeepSeekは2026年10月17日に、DeepSeek V4.1 Flash 1017と同じ日にSearchとFetchを公開しました。どちらもapi.deepseek.com上の独立したJSONエンドポイントで、モデルと同じAPIキーを使います。Models & Pricingページの料金表は次のとおりです。

1回あたりでは$0.00075です。1,000回の検索はコーヒー1杯より安く、100万回で$750です。

この2行にはピーク時とオフピーク時の区別がありません。DeepSeekモデルはピーク時間外にトークン価格が半額になりますが、SearchとFetchは1日のどの時間帯でもリクエストあたりの固定価格です。

Search & Fetchガイドによると、SearchはDeepSeek独自のエンジンで動いており、変更履歴ではそのエンジンが"hundreds of billions of web pages"をインデックスしていると説明されています。各結果には、タイトル、URL、短いスニペット、モデルが読む前提で書かれた長めのsummary、日付、0〜4のauthorityスコア、そして任意でページ本文全体が含まれます。

実際に何が課金されるのですか？

DeepSeek Search APIの料金のこの部分は見た目より太っ腹なので、ゆっくり読む価値があります。ガイドの課金セクションによると、リクエストが課金対象になるのは、HTTP 200を返し、実際に何かを返したときだけです。Searchなら空でないresults配列、Fetchならページコンテンツです。

実際のお金に関わる詳細が3つあります。

• 空の検索は無料です。 エージェントがsite:やafter:フィルター付きの絞り込んだクエリを投げて何も返ってこなくても、料金はかかりません。PerplexityのSearch APIは逆で、その料金ページには、結果が空でも成功したレスポンスは課金されると書かれています。
• countは価格を変えません。 50件の結果を求めても、1件のときと同じ$0.00075です。Exaは10件を超える結果ごとに1,000リクエストあたり$1を課金し、Firecrawlは10件につき2クレジットを課金します。
• need_content: trueは料金に含まれます。 有効にすると、追加料金なしで各検索結果の中にページ本文が返ります。コンテンツ付きの1回の検索で、検索と複数回のFetch呼び出しを置き換えられます。

失敗したFetch呼び出しも無料です。DeepSeekのセキュリティポリシーによる403、抽出可能なMarkdownがなかったことによる404、504タイムアウトは、どれも料金がかかりません。悪い呼び出しで料金を払うのは、技術的には成功したのに中身がゴミだった場合だけで、これはどのスクレイパーでも同じリスクです。

無料期間はいつ終わりますか？

簡単に言うと、2026年11月1日の北京時間0時、つまりUTCの10月31日16時です。

つまずきやすいのは、無料期間が何を対象にしているかという点です。DeepSeekの注記は料金ページとガイドにも繰り返されており、DeepSeek Harness、Claude Code、Codex経由でAPIを使う場合、"server-side tool calls already hit the Search and Fetch APIs. These calls are currently free of charge"とされています。無料の枠はこの3つのクライアントを名指ししています。自分のコードから/v1/tools/searchを直接呼ぶ場合は、開始時点から課金される独立したAPIです。

Claude CodeがDeepSeek上で動くときのサーバー側検索は、次のように表示されます。質問1つに対して検索が2回です。

11月1日以降、この2回の検索は$0.0015かかります。Claude Code連携ページは、検索料金が請求額のすべてではないとはっきり述べています。ツールを呼び出すと"generates additional LLM API requests to summarize the retrieved search content, additional model token costs will be incurred."とあります。

サーバー側で検索できるモデルも、使うサーフェスによって異なります。

つまり、エージェントがResponses API経由でFlashを動かしている場合、組み込みツールは何も言わずに無視されます。独立したSearch APIを自分で呼び出し、結果をツール出力として返すことになりますが、それはトークン面でもむしろ安上がりです。

エージェントのタスク1件は実際いくらかかりますか？

あるRedditユーザーが、私よりうまく本当の疑問を書いています。

"At $0.75 per 1000 requests, I want to know how many calls an agent makes in the background. Has anyone calculated the cost for typical research task?"

u/Glum-Guitar-5083, Reddit

そこで私の計算です。エージェントが20回検索し、10ページを開くリサーチ系のタスクを考えます。課金対象の呼び出しは30回で、料金は$0.0225です。

次に読み込みコストです。ガイドでは各summaryは"typically 600 to 800 characters"、約200トークンとされているので、10件の結果で1回の検索あたり約2,000トークンです。取得した1ページあたりは5,000トークンと仮定しました。合計すると入力トークンは約90,000になります。DeepSeekのオフピーク時のキャッシュミス料金、Flashは100万トークンあたり$0.15、V4 Proは$0.66で計算すると次のようになります。

ここが持ち帰る価値のある逆転です。多くの検索ツールでは、1回あたりの料金は小さな部分で、モデルのトークンが支配的です。Flashではこれが逆転します。Flashの入力トークンがとても安いため、検索料金がタスクのリサーチコストの約60%を占めます。V4 Proでは再びトークンが優位になります。ピーク時間（平日のUTC 01:00〜04:00と06:00〜10:00）には、トークン側が2倍になり、料金側は変わりません。

出力トークンとモデル自身の推論は、この数字に含まれておらず、エージェントの作業ではそれが最大の項目になることも多くあります。その側面は私のDeepSeek V4.1 Flash料金の解説で扱っています。

Claude Codeに頼らず自分でエージェントのループを作る場合は、私のDeepSeek V4 Flash APIガイドがツール呼び出しとResponses APIの設定を扱っており、Claude CodeのMCPツールがエージェントに検索ツールを渡すもう一つの一般的な方法です。

他の検索APIと比べるとどうですか？

下の価格はすべて、同じ日に各ベンダー自身の料金ページから取りました。課金単位が異なるため、「1,000回あたり」の列は各社のデフォルトの検索の値です。

月に100,000回検索するプロダクトに当てはめると、差は無視できなくなります。

Braveの数値は月$5のクレジットを差し引いたもの、Geminiの数値は5,000回の無料検索を差し引いたものです。それでもDeepSeekはBraveの約1/7、Geminiの約1/18です。公開時のスレッドでは、すでに利用しているツールと並べて比較するコメントが出ていました。

"For comparison that's $5 with Brave Search API and $12 with Kagi API"

thombles, Hacker News

すでに自前の検索スタックを作っていた別の開発者は、モデルベンダーの組み込みツールとの差を次のように表現しています。

"About a year ago I built my own search and fetch MCP tools for agents based on third-party scraping providers. It is about 15-20x more cost-effective than what OpenAI and Anthropic is offering with their integrated web search and fetch tools. Very impressive that DeepSeek has such a competitive offering today."

suncemoje, Hacker News

価格が安くても勝てない点もあります。

• スループット。 5 QPSはこの一覧で記載されている中で最も低い上限です。Braveは毎秒50、Exaは従量課金で最大25、Tavilyは本番キーで毎分1,000を許可しています。
• データの扱い。 Braveはゼロデータ保持をアーキテクチャの一部として提供し、ExaとFirecrawlはEnterpriseで提供しています。DeepSeekのSearchドキュメントにはデータ保持への言及がなく、プライバシーポリシーには個人データが中華人民共和国に保存される可能性があると書かれています。規制対象のデータを扱う場合は、組み込む前にこれを読んでください。
• プロトタイプ用の無料枠。 Tavily、Exa、Brave、Firecrawlはいずれも、カード不要で毎月の無料枠があります。DeepSeekは最初の成功した呼び出しから有料ですが、1ドル分のクレジットで約1,333回の検索ができます。

1社に絞りたくない場合は、Cloudflareのウェブ検索APIが価格差の大きい複数のプロバイダーにルーティングします。スタックのスクレイピング側については、Firecrawlの代替とPerplexityの代替も見ておくとよいでしょう。

自分の請求額を見積もる

月間の利用量と、組み合わせるモデルを入力してください。初期値は上の計算例と同じで、検索1回の読み込みに2,000トークン、取得したページ1件の読み込みに5,000トークンです。

比較の列は検索料金のみを示しています。他社のフェッチやコンテンツの料金体系は異なるためです（Exaはページ単位でContentsを課金し、Anthropicのweb fetchには料金がなく、TavilyはExtractをクレジットで課金します）。

レート制限はどこで足かせになりますか？

毎秒5クエリは、掛け算をするまでは十分に聞こえます。1アカウントで1日432,000回の検索、トラフィックが完全に平坦なら月に約1,300万回になります。支出面では、1アカウントのSearchが1日約$324で頭打ちになります。

ガイドには、制限の仕組みが具体的に書かれています。

• 制限はAPIキーごとではなくアカウントごとなので、キーを増やしても意味がありません。
• SearchとFetchはそれぞれ別の5 QPSの枠を持ち、片方のトラフィックがもう片方を消費することはありません。
• Fetchにはドメインごとの追加の上限があるため、1つのサイトを叩き続けるエージェントは、アカウント上限より先にHTTP 429になります。
• 検索の制限は、モデルの同時実行数（Flashは2,500、V4 Proは500）とは別です。

開発者1人やバッチ処理なら、5 QPSで十分です。組み合わせる他の低コストモデルAPIを検討しているなら、Kimi K3の料金とQwen 3.8 Maxの料金が最も近い競合です。30人が同じ秒に質問するような顧客向けプロダクトでは、最初にぶつかる壁になります。トラフィックは突発的なので、平均ではなくピークに合わせて計画してください。429で再試行するキューが最低限必要です。ドキュメントでは、408、429、5xxでは待って再試行し、それ以外の4xxエラーはリクエストを変更せずに再試行しないよう書かれています。

請求額を抑えるにはどうすればよいですか？

DeepSeekは結果やトークンではなく成功した呼び出しごとに課金するため、よくある節約の方法も形が変わります。私ならこうします。

1. 結果を多めに、頻度は少なく。 絞り込んだ検索を3回実行する代わりに、最初の検索でcountを20か50にします。価格は同じで、呼び出しは減ります。
2. Fetchに頼る前にneed_contentを使う。 検索のコンテンツで足りるなら、$0.00075のFetchと2回目の往復を省けます。
3. クエリ演算子を活用する。 site:、-site:、lang:、after:、完全一致のフレーズはそのまま渡ります。何も返さない的確なクエリは無料で、ゴミを返す曖昧なクエリは課金されます。
4. モデルが読む前にrerank_scoreとauthorityで絞り込む。 DeepSeekはrerank_scoreが1.5以上を高品質、authorityが3以上を権威性が高いとしています。弱い結果をモデルに渡す前に落とせば、請求のトークン側が減ります。
5. ori_questionを送る。 ユーザーの元の質問を渡してクエリの理解を高めるため、エージェントが追加の検索を行う回数が減ります。
6. バッチ処理はオフピークに実行する。 検索料金は変わりませんが、結果を読み込むモデルはピーク時間外には半額になります。

Claude CodeをDeepSeek経由で使う場合は、モデルの選択も確認し、DeepSeekの請求は通常のClaude Codeの料金に上乗せされるのではなく、それに置き換わることを覚えておいてください。DeepSeekはclaude-opusのモデル名をV4 Proに、claude-sonnetとclaude-haikuをFlashに割り当てるため、設定が送るモデル名によって、同じ検索でも読み込みコストが約4倍変わることがあります。

サポートやRAGでも使う価値はありますか？

リサーチやコーディング向けの優れたAIエージェントを作る開発者なら、使う価値はあります。この価格なら、ウェブ検索は節約する費目ではなくなり、DeepSeek HarnessやDeepSeek上のCodexは、GPT-5.6上の同じループより安く動かせます。Flashと組み合わせれば、典型的なリサーチのタスクは数セントで済みます。

カスタマーサポートの場合は、組み込む前に一度立ち止まります。私の経験では、サポートの質問の多くは、公開ウェブではなく自社のヘルプセンター、マクロ、過去のチケットで答えが出ます。ウェブ検索APIは「この運送会社の追跡ステータスはどういう意味か」には適したツールですが、「うちの返金ポリシーは何か」には不向きです。後者は自社コンテンツに対する検索（リトリーバル）の領域で、サポートボットが実際に間違えるのもそこです。安い検索呼び出しでは、実際のポリシーではなくブログ記事を自信満々に引っ張ってくるエージェントは直りません。だからこそ、ここではウェブへの到達範囲よりも、自社ドキュメントに対するハイブリッド検索のほうが重要です。

コストの大部分もそこにあります。サポートボットのAPI料金は、リトリーバルパイプラインの構築、ヘルプデスクAPIの接続、エスカレーションルールの作成、顧客に見せる前のテストにかかる時間に比べれば小さなものです。そのお金がどこに使われるかは、AIカスタマーサービスのコストで詳しく書きました。

検索パイプラインではなく、サポートのチームメイトを

DeepSeek Search APIはインフラであり、とてもコストパフォーマンスの高いものです。eeselは従業員にあたります。そのAIヘルプデスクチームメイトは、Zendesk、Freshdesk、Gorgiasなどに接続し、ヘルプセンターと過去のチケットから学び、普段使っているキューの中で返信を下書きしたり送信したりします。実際のチケットに触れる前に、過去のチケットに対して実行し、何と返信したかを確認できます。自信満々のボットが本物のキューで誤った回答をするのを見てきた私としては、このステップは絶対に省きません。

API料金ページを趣味で読むようなチームなら、eesel CLIは馴染みやすいはずです。同じチームメイトをターミナルに持ち込みます。eesel init chat-bubble --site https://your-site.comでサイトを読み始めるエージェントを作成し、eesel files uploadでポリシー文書を追加し、eesel integrations connect zendeskでヘルプデスクを接続し、eesel approvalsで人の確認待ちになっているアクションを一覧できます。すべてのコマンドはJSONを出力するため、Claude CodeやCodexにセットアップ全体を任せられますし、すべてのワークスペースはMCPサーバーでもあります。ターミナルで設定した内容は、同じエージェントなのでダッシュボードにも表示されます。

eeselはカードなしで試せます。本当に必要なのが検索パイプラインではなく、対応済みのチケットであるなら、こちらのほうが近道です。