DeepSeekが、Search APIとFetch APIをまとめて案内する開発者向けドキュメントを公開しました。どちらも、エージェントやRAGアプリケーションが「いま見つかるWebの内容」にアクセスするための道具です。検索で候補ページを拾い、必要なら個別ページをMarkdownとして取り込む、という役割分担がはっきりしています。単なる機能追加というより、DeepSeekのAPIを使う開発者にとって、モデル単体では埋めにくい“最新情報を取り込む層”を用意した、という話として読むのが自然です。
元記事が説明しているのは、DeepSeek APIに新しく加わったSearch APIとFetch APIの使い方です。Search APIは、入力したクエリに合うWebページを探し、構造化された結果を返します。検索エンジンはDeepSeekの自社実装で、単にURLを返すだけではなく、title、url、snippet、summary、content、site_name、date、authority といった項目をまとめて返せます。Fetch APIは、単一のページを指定して取得し、その内容をMarkdownとして返します。つまり前者は「探す」ため、後者は「読む」ためのAPIです。
どちらも raw JSON API で、認証はDeepSeek APIと同じ bearer authentication を使います。ベースURLは https://api.deepseek.com で、Searchは POST /v1/tools/search、Fetchは POST /v1/tools/fetch に投げます。Searchのリクエストでは、query が必須で、1〜128文字のUnicode文字列である必要があります。count は1〜50の範囲で、指定しなければ10件です。ori_question は検索を呼び出した元の質問を渡すための項目で、検索意図の理解を助けるために使われます。localization はIPアドレスを使った地域寄せ、need_content は結果にページ本文を含めるかどうかを決めます。未知のフィールドは無視されると書かれています。
Searchでは、クエリに検索演算子を含められるのが特徴です。site: でサイトを絞り、-site: で除外し、-"..." で特定フレーズを消せます。"..." で完全一致、lang: で言語指定、after: と before: で公開日による絞り込みも可能です。たとえば DeepSeek site:github.com OR site:huggingface.co lang:en after:2025 のように、複数条件を組み合わせられます。レスポンスはHTTP 200なら results 配列を返し、検索結果がないだけなら空配列になります。各結果には関連度の目安として rerank_score が入り、1.5以上は高品質とみなされると説明されています。authority は0〜4のページ権威レベルで、3以上が高い権威を示します。
Fetch APIは、url だけを受け取り、そのページの title と Markdown化された content を返します。URLは最大8192文字、HTTPまたはHTTPSでホストを含み、ユーザー名やパスワードを含めてはいけません。Fetchの結果は、対象サイトの可用性やアクセス方針に左右されます。エラーもかなり具体的で、400はリクエスト不正、401はAPIキー不備、402は残高不足、403はセキュリティポリシーで拒否、404は取得できる本文がなかった場合、408は読み取りタイムアウト、413はボディが大きすぎる、429はQPS超過、500と504はサーバー側や下流の失敗です。SearchとFetchは読み取り専用で、408・429・5xxでは再試行し、それ以外の4xxはリクエストを直さない限り繰り返さないよう案内しています。
料金は少し変わった形で、トークン課金ではなく「成功したリクエストごと」です。SearchもFetchも1,000回あたり0.75ドルで、Searchは空結果だと課金対象になりません。Fetchもページ内容が取れて初めて課金されます。count を増やしても価格は変わらない、と明記されています。さらに、DeepSeek Harness、Claude Code、Codex経由のサーバーサイドtool callsは、現時点では無料で、個別課金は2026年11月1日北京時間0:00から始まるとされています。レート制限はSearchとFetchで独立しており、どちらもアカウント単位でQPS 5です。Fetchにはドメイン単位の制限も別にあります。
まず印象的なのは、「検索」と「本文取得」をきれいに分離していることです。これは当たり前に見えて、実際にはかなり実務寄りの設計だと思います。検索だけなら軽く広く当たりを付けられるし、Fetchを呼ぶのは本当に読む必要があるページだけに絞れる。RAGやエージェントは、無駄にページ本文を大量取得するとすぐ遅くなるので、この二段構えは理にかなっています。しかもSearch結果に summary や authority が入るので、モデル側で「どの候補を深掘りするか」を判断しやすい。単なるWeb検索のラッパーではなく、エージェントの判断材料を返す道具として作られている感じがあります。
1,000回あたり0.75ドルという値付け自体は、極端に高いわけではありません。ただ、トークン課金ではなく成功リクエスト課金にしたことで、使う側は「何回呼ぶか」をより直接的に意識するはずです。特にSearchは空結果が課金されないので、探索フェーズで気軽に使える一方、Fetchはページを取れたときだけ課金されます。ここはうまい線引きだと思います。逆に言うと、RAGの設計を雑にして大量Fetchを回す実装は、そのままコストにも跳ね返る。DeepSeekは、このAPIを“便利な付属機能”ではなく、きちんと運用前提で使う層として置いているのだと思います。
ori_question と検索演算子は、検索の質を上げるための地味な工夫Searchの引数で目を引くのが ori_question です。検索語だけでは意図が曖昧なときに、元の質問を渡せる。これ、地味ですがかなり効く場面が多いと思います。たとえばユーザーが「DeepSeekの新機能って何？」と聞いたとき、検索クエリは要約されて短くなる一方で、元質問には「新機能」「比較」「最新」などの意図が残る。検索エンジンがそれを補助情報として使えるなら、結果のぶれは減りそうです。さらに site: や after:、lang: まで使えるので、開発者は検索対象をかなり細かく制御できます。これは一般向けの検索UIというより、AIアプリの内部部品としての検索だと見るべきでしょう。
ここは少し冷静に見たいところです。SearchもFetchも、結局は外部サイトの状態に依存します。Fetchの注意書きには、サイトの可用性やアクセス方針次第で失敗するとありますし、404の扱いも「ページがない」だけでなく「本文を抽出できない」場合を含んでいます。つまり、返ってきたMarkdownは便利でも、それが完全な正本だとは限らない。RAGで使うなら、取得した情報に出典URLや取得時刻を持たせる設計が大事になります。DeepSeekは date や site_name、authority を返していますが、最終的に何を信用するかはアプリ側の責任です。ここを雑にすると、便利さの代わりに幻覚の土台を広げることになりかねません。
この発表は、単独の新機能というより、LLM周辺の実装が「モデル本体＋外部情報取得」に寄ってきた流れの一部に見えます。特にClaude CodeやCodexでもサーバーサイドtool callsがすでにSearch/Fetch APIに触れている、と書かれているのは示唆的です。つまりDeepSeekは、自社モデルの利用者だけでなく、他のエージェント系ツールからも使われる前提で、この基盤を整えている可能性があります。SearchとFetchを分け、課金単位を成功リクエストにし、QPSも明示する。派手さはないですが、開発者が実際に組み込むときに困る点を先回りして潰している印象です。こういうAPIは、機能の見た目より、運用のしやすさで差がつくのだと思います。