Brave Search API 2026年版: Search vs Answers、料金、最初に動くリクエスト

いま Brave Search API を使うなら、最初にやるべきことは Search と Answers のどちらから始めるかを決めることです。Search は、生の検索結果や LLM Context による grounding、あるいは Place Search のような専用 endpoint を使いながら、アプリ側のロジックをまだ自分で持ちたいときのデフォルトです。Answers は、Brave に根拠付きの最終回答を返してもらいたいとき、しかも接続面をできるだけ OpenAI 互換 の形で扱いたいときのデフォルトです。

Brave Search API はひとつの「万能 endpoint」ではありません。2026年のいまは、Search は検索基盤、Answers は完成回答、LLM Context は自前モデルを保ったまま Brave の grounding 層だけを使う道、Place Search は対象が Web ページではなく実世界の場所である場合の道、という小さなルートマップとして理解した方が正確です。

鮮度メモ: 2026年4月1日時点で Brave の公開ランディングページ、料金ページ、認証ドキュメント、Search ドキュメント、Answers ドキュメント、Place Search ドキュメント、そして 2026年2月12日の Brave 公式ブログ記事を再確認しています。

TL;DR

最短の安全な答えはこれです。

一番シンプルなルールは、モデル層を自分で持ちたいなら Search、完成回答まで Brave に任せたいなら Answers です。

いまの Brave Search API は何を指すのか

一番迷いやすいのは、Brave Search API を「ひとつの endpoint に機能がいっぱい付いているもの」として見てしまうことです。現在の Brave の公開契約はもっとはっきりしています。料金ページは、主要な道を Search と Answers の二つに分けています。

Search は基盤の plan です。agent、chatbot、検索プロダクト、retrieval システムが実際に必要とする検索データを出します。Web Search、LLM Context、News Search、Video Search、Image Search、そして新しい Place Search がここに含まれます。現在の公開価格は 1,000 requests あたり 5ドル、毎月 5ドル credits、デフォルト容量は 50 requests per second です。ランディングページもこれを「chatbots や agents が answer を生成するために必要なリアルタイム検索データ」と位置付けています。つまり、ここで得るのは検索層であり、アプリ全体ではありません。

Answers は完成回答の plan です。Brave の検索基盤の上に立ち、OpenAI 互換の形で grounded AI answers を返します。現在の公開価格は 1,000 queries あたり 4ドル に加えて、input tokens 100万あたり 5ドル、output tokens 100万あたり 5ドル、そして 毎月 5ドル credits、デフォルト容量は 2 requests per second です。この throughput が低いのは、Brave があなたの代わりにもう一段上の仕事まで担当しているからです。

ここで二つ、冒頭に置くべき事実があります。第一に、Summarizer Search はいま deprecated で、Brave は Answers を後継の標準ルートとして扱っています。ドキュメント上は discontinued された Pro AI plan のユーザー向けに残っていますが、それは互換性のためであって、新規ビルドの推奨ではありません。第二に、Brave Search API は Google や Bing の scraper ではありません。ランディングページでは 300億以上のページ を持つ独立インデックスで、1日1億以上のページ更新 があると説明しています。真面目に評価するなら、この独立インデックスの事実は多くの benchmark 文句よりも重要です。

ブランド名ではなく、まず契約を選ぶ

このテーマで一番大事なのは、最初から間違った層を選ばないことです。

古典的な検索 substrate が必要なら、/res/v1/web/search から始めるべきです。URL、snippet、pagination、search operators、result filter などを取り、自分のプロダクト側で次のロジックを持ちたいときに向いています。ここは本当に検索インフラとして振る舞います。検索結果を受け取り、その後に何をするかはあなたのシステムが決めます。

自分のモデルや agent への grounding が必要なら、/res/v1/llm/context から始めるのが自然です。2026年2月の再設計で、Brave は LLM Context を単なる補助機能ではなく対外公開の一等ルートにしました。Brave 自身はこれを data-first ranking と説明し、Web 上の関連チャンクをモデル向けに圧縮した形で返すとしています。つまり、単なる「別名の検索」ではありません。モデル層を自分で持ったまま、retrieval output だけを普通の Web Search よりモデルに優しい形でもらえるのが本当の価値です。

完成した grounded answer をすぐ欲しい なら、Answers から始めるのが良いです。自前で answer synthesis を持ちたくない、あるいは引用付き answer engine をできるだけ短い経路で試したいなら、こちらの方が綺麗です。ドキュメントはこの機能を OpenAI 互換の /res/v1/chat/completions で公開していて、model="brave" を使います。すでに OpenAI 系クライアントを使っているチームなら、この接続面はかなり短いです。

対象が 実世界の場所 なら、理由がない限り普通の Web Search に押し込まない方がよいです。Brave の Place Search は、店舗、landmark、hotel、museum、nearby discovery のために設計されています。公開ドキュメントはこれを 2億以上の場所 のインデックスと説明し、構造化された POI データ、地理を意識した検索、詳細取得のための endpoint 群を備えています。これは Web ページの ranking とは別物です。

判断は一つで十分です。answer layer を誰が持つか を先に決めます。答えが「自分のアプリ」なら Search に残り、Web Search、LLM Context、Place Search から選びます。答えが「Brave」なら Answers です。

現在の料金、rate limit、そして誤読されやすい点

料金表は見つけやすいですが、接続判断には契約条件も一緒に読む必要があります。

重要なのは、どちらが「安い」か「高い」かではありません。重要なのは Answers の価格には Brave がアプリ層の仕事を多く引き受ける分が含まれている ということです。自分ですでに model stack、retrieval layer、synthesis pipeline を持っているなら、Search の方が自然な起点になることが多いです。逆に、search-to-answer のジャンプ自体を Brave に任せたいなら、token コストが増えても Answers の方が合理的です。

実務上の制約の一つは signup 契約です。Brave の現在の FAQ では、free plan に subscribe するには credit card が必要 で、これは anti-fraud のためだと説明されています。一方で、現在の pricing page は monthly credits 付きの有料 plan として記述しています。現実的な読み方は、monthly credits はあるが、完全な no-card sandbox ではない ということです。

さらに、本番で効く二つの条件があります。Brave の rate-limiting docs は、制限が 1秒 sliding window で実装されていて、レスポンスには X-RateLimit-* headers が入ると説明しています。本当に運用するなら、最初の 429 が出てから見るものではありません。もう一つは storage rights です。Brave は、結果の全部または一部を保存したい場合、特に LLM の training や tuning に使う場合、明示的に storage rights を含む plan が必要だと書いています。これはアーキテクチャを組んだ後に発見したくない条件です。

企業用途では、Brave の公開ページは SOC 2 Type II と Zero Data Retention への道も示しています。プライバシーや規制対応が調達条件に入るなら、これは意味のある差分です。まだ prototype 段階なら、「この契約は hobby 用だけではない」と理解しておけば十分です。

最初に動くリクエスト: 通常の検索か、モデル向けコンテキストか

まず Search 側を確かめたいなら、最短ルートは X-Subscription-Token header を付けた基本の Web Search リクエストです。

js
const query = new URLSearchParams({
  q: "best open source vector database for hybrid search",
  count: "10",
  country: "US",
  search_lang: "en",
  extra_snippets: "true",
});

const response = await fetch(
  `https://api.search.brave.com/res/v1/web/search?${query}`,
  {
    headers: {
      Accept: "application/json",
      "Accept-Encoding": "gzip",
      "X-Subscription-Token": process.env.BRAVE_API_KEY,
    },
  },
);

const data = await response.json();
console.log(data.web?.results?.[0]);
console.log(data.query?.more_results_available);

この基本リクエストを打つと、検索層がどんな形で返るかをそのまま確認できます。結果を受け取ったら、続きのページがあるかを見て、さらに取得するのか、自分の後続ロジックへ渡すのかを決められます。Brave の Web Search docs には、先に覚える価値が高いパラメータもいくつかあります。extra_snippets=true で 最大5本の追加抜粋が取れること、search operators は別パラメータではなく q に書くこと、そして pagination は無限ではないので more_results_available を見てから次ページを取りに行くべきだということです。

もし本当の workload が コンパクトな grounding を必要とするモデルや agent なら、Search 側の最初の検証としては LLM Context の方が良いことが多いです。

bash
curl -s --compressed \
  "https://api.search.brave.com/res/v1/llm/context?q=best+open+source+vector+database+for+hybrid+search" \
  -H "Accept: application/json" \
  -H "Accept-Encoding: gzip" \
  -H "X-Subscription-Token: $BRAVE_API_KEY"

違いは返ってくる形にあります。Web Search は URL と snippet 中心の検索結果 API です。LLM Context は grounding 用の返り値です。 次のステップが自分の model、coding agent、reasoning pipeline への入力なら、普通の Web Search より自然な出発点になりやすいです。Brave の 2026年2月の公開資料も、この役割分担で説明しています。

Brave Answers を OpenAI SDK 経由で試す

欲しいのが retrieval substrate ではなく 完成した grounded answer なら、最短の検証は OpenAI client 経由で Answers を叩くことです。

python
import asyncio
from openai import AsyncOpenAI

client = AsyncOpenAI(
    api_key="YOUR_BRAVE_SEARCH_API_KEY",
    base_url="https://api.search.brave.com/res/v1",
)

async def main():
    stream = await client.chat.completions.create(
        model="brave",
        stream=True,
        messages=[
            {
                "role": "user",
                "content": "Compare Brave Search API Search vs Answers for an internal research assistant",
            }
        ],
        extra_body={
            "country": "us",
            "language": "en",
            "enable_citations": True,
            "enable_research": False,
        },
    )

    async for chunk in stream:
        if chunk.choices and chunk.choices[0].delta.content:
            print(chunk.choices[0].delta.content, end="", flush=True)

asyncio.run(main())

ここで多くの二次記事が落としているけれど大事なのは、citations、entities、research mode はすべて streaming が前提 だという点です。これは小さな注意書きではありません。Answers は普通の chat completion より豊かなデータを返せるからです。Brave docs は <citation>、<enum_item>、<usage> という特殊タグまで説明しています。きれいな UX と信頼できる monitoring を作りたいなら、ここは本当にパースした方がいいです。

research mode も、何となくで default にしない方がいい機能です。Brave は single-search mode を速度向けに最適化していて、通常は 4.5秒未満 で streaming を始めると説明しています。一方 research mode は複数回検索し、難しい質問では 数分 かかりえます。つまり、これは background task 向けであって、何でも「上位版」ではありません。対話レイテンシを重視するなら、必要性を説明できるまで default のままにしておくべきです。

Brave が「ただの検索 wrapper」より面白い理由

Brave は、単なる検索ボックスとしてではなく、自分で steering できる search infrastructure として見たときに面白くなります。

最初の差分はインデックスです。Brave の公開資料は一貫して、これは 独立インデックス であり、Google や Bing の scrape-and-repackage 層ではないと説明しています。この主張は、それによって作れるものが変わる場合にだけ意味があります。そして実際に変わります。Brave は独立インデックスの上に、Goggles による reranking / filtering、結果ごとの追加文脈としての extra snippets、構造化結果向けの schema-enriched results を重ねています。これらは抽象的な marketing bullet ではなく、agent や検索 workflow が同じ retrieval blind spot に何度もぶつかる時に効く制御手段です。

二つ目の差分は、Brave が今は substrate layer と answer layer を両方公開していることです。検索系プロダクトの多くは、そのどちらかしか選ばせません。Brave は raw search results、圧縮された model-ready context、finished grounded answer の間を自分で選べます。だから本当の比較軸は「Brave の answer が X より強いか」よりも、「自分のシステムは answer layer をどこまで持つべきか」です。

三つ目の差分はエコシステムです。Brave の公式 tools page には MCP Server が公開されていて、LangChain、LlamaIndex、Dify、Flowise、Postman などの統合も並んでいます。もし最速の検証が「今日中に agent tool に search をつなぐ」ことなら、これはかなり効きます。もし次に、Brave の native endpoints の上にさらに relay / gateway 層を置きたいと考えるなら、私たちの OpenClaw API ガイド が扱っているのはその別の設計判断です。

最後にもう一度 Place Search です。今でも Brave を「Web search + AI answers」だけで語る記事は多いですが、いまは本当に使える local-discovery の道があります。対象が「座標の近くのコーヒー店」「パリの museum」など、場所そのものなら、/local/place_search は脚注ではなく一級のプロダクト判断 です。

最初の一週間を無駄にしやすいミス

Brave Search API の初期のつまずきは、珍しい feature が足りないからではなく、最初の前提を一つ間違えることから起きる場合が多いです。

• 新規プロジェクトなのに Summarizer Search から始める。 Brave はすでに deprecated と明記し、Answers への移行を示しています。古い記事が残っていても、それを新規の標準にしてはいけません。
• grounding substrate だけ欲しいのに Answers へ飛ぶ。 すでに自分のモデル層があるなら、Answers は必要以上に高価で制御しづらい契約になることがあります。
• Answers の rich output と streaming の関係を無視する。 citations、entities、research mode が必要なら、最初から streaming 前提で組むべきです。
• monthly credits を friction のない public sandbox と考える。 公式ページは、credits があっても signup/card friction があることを示しています。使えないという意味ではなく、導入コストを正直に見積もるべきということです。
• rate-limit と storage-rights を後回しにする。 X-RateLimit-* headers と storage-rights の制約は、最初の integration checklist に入れるべきです。
• local discovery を普通の Web Search に押し込む。 対象が business、landmark、nearby place なら、最初に Place Search を疑う方が自然です。

一番短くて安全な始め方

まだどこから始めるか迷っているなら、このルールを先に覚えておけば十分です。制御したいなら Search、完成まで欲しいなら Answers。

多くのエンジニアリングチームにとって、最初の評価として一番安全なのは Search plan の Web Search か LLM Context です。この二つはアーキテクチャを正直に保ってくれます。まず retrieval layer を見て、その後で Brave を substrate に留めるのか、answer layer 側まで上げるのかを決められます。もしプロダクトの本質が最初から「できるだけ少ない統合で grounded answer を返すこと」なら、遠回りせず Answers から始めるべきです。

避けるべきなのは、古い記事や価格だけを並べた要約に判断を委ねることです。Brave の現在の公開契約は、いまは十分に明確です。ただしそれを「単一 endpoint の名前」として読むのではなく、「ルートマップ」として読めたときに限ります。