LLM の弱点は学習時点以降の情報を知らないことだ。Brave Search MCP Server は、その穴を Web 検索で埋めるための MCP サーバーで、Claude などのエージェントに「調べる能力」を後付けする。
2 種類の検索
brave_web_search による一般的な Web 検索に加えて、brave_local_search で地域・周辺情報の検索もできる。エージェントが最新ニュースを参照したり、現在のドキュメントを確認したりする際の情報源として機能する。動作には Brave Search API キーの連携が必要になる。
コストの構造
MCP サーバー自体は OSS で無料。実際に検索を実行する Brave Search API 側に無料枠があり、それを超えると従量で課金される。つまり「MCP は無料だが、検索の実体には API 利用料がかかりうる」という二層構造を理解しておきたい。注意したいのは、エージェントは一つの質問に答えるために複数回検索を投げることがある点だ。人間の検索回数の感覚でコストを見積もると、無料枠の消費が想定より速いことがある。
使い方の現実
検索結果をそのまま信用させるのではなく、エージェント側に「複数ソースを照合する」「日付を確認する」といったプロンプト上の指示を入れておくと、誤情報をそのまま回答に反映するリスクを下げられる。検索能力を付けることと、検索結果を正しく扱わせることは別の設計課題だと捉えたい。
設定でつまずきやすい点
導入は API キーを取得して MCP クライアントの設定ファイルに登録するだけで、手順自体は短い。つまずきやすいのはむしろ API キーの管理で、設定ファイルに平文で書く形になるため、リポジトリへの誤コミットや共有端末での漏洩に注意したい。利用枠を超えると検索が静かに失敗することもあるので、想定する検索回数に対して枠が足りているかは事前に見ておきたい。
選定上の注意
検索エンジンが Brave である点は割り切りが要る。Google の検索結果やインデックスに依存したい、あるいは Google 特有の検索演算子を前提にした処理を組みたい場合には合わない。プライバシー志向の検索結果で十分、エージェントに最新情報へのアクセスを与えたい、という用途ならシンプルに導入できる選択肢だ。
日本語の情報を探す用途では、事前に実力を測っておく
日本人開発者にとって最も効いてくる判断材料はここになる。Brave は自前のインデックスを 持つ独立系の検索エンジンで、その規模は大手より小さい。英語圏の技術情報では十分に 戦えるが、日本語のニッチな情報になるほど取りこぼしが増える傾向がある。 公式ドキュメントに書かれる類の話ではないので、採用前に自分が実際に投げる想定の クエリをいくつか試し、期待する結果が返るかを確かめておきたい。
国内サービスの仕様、日本語の技術ブログ、法令や制度の情報などを探させたいとき、 ここで結果が薄いと、エージェントは「情報が見つからなかった」ではなく **「見つかった少数の情報だけで断定する」**という失敗の仕方をする。検索能力を 付けたことで、かえって自信のある誤答が増える形になる。
検索 API が返すのはタイトルと短い抜粋です。エージェントがそれだけで結論を出すと、本文を読めば分かる条件や例外を落とします。正確さが要る調査をさせるなら、検索でページを見つけた後に本文を取得する手段（フェッチ系のサーバー）を併せて用意し、「抜粋だけで答えない」ことをプロンプトで明示してください。
検索を挟むと応答は確実に遅くなる
外部への問い合わせが入るぶん、応答までの時間は伸びる。エージェントが 1 つの質問に 複数回検索を投げる前提を踏まえると、対話型の UI では待ち時間が体感に響く。 検索を常時有効にするのか、必要なときだけ使わせるのかは、コストだけでなく 体験の面でも設計判断になる。