通常の検索 API は人間が読む UI 向けに作られているため、結果を LLM に渡すには HTML の除去や本文抽出という前処理が必要になる。Tavily はその前処理を済ませた状態で結果を返す、AI エージェント／RAG 専用に設計された Web 検索 API だ。
何が省けるか
検索結果が、本文の抽出・要約まで含んだ構造化フォーマットで返ってくる。つまり「検索 → スクレイピング → クレンジング → LLM 投入」という多段パイプラインのうち、中間の重い部分が API 側に寄せられている。LangChain や LlamaIndex とのインテグレーションが用意されているので、エージェントの検索ツールとして組み込む工数も小さい。スクレイピング基盤を自前で持つと、サイトごとの構造差異やボット対策への対応が恒常的な保守コストになるが、その負担を API のレイヤーへ追い出せるのが実質的な利点だ。
料金と向き不向き
無料枠は月間 1,000 回程度の検索リクエストで、有料はリクエスト数ベースの従量課金。エージェントが頻繁に検索を叩く設計だと枠の消費が早いため、検索回数を抑えるキャッシュ戦略を最初から考えておきたい。特に自律エージェントは一つの質問に対して内部で何度も検索を再試行することがあり、想定よりリクエストが膨らみやすい。同じクエリを短時間で繰り返さないようにする、検索の深さに上限を設ける、といった制御をエージェント側に入れておくと枠を守りやすい。
一方で、一般ユーザーに見せる検索 UI を作るなら Google Custom Search のような汎用 API のほうが適している。Tavily の価値は「LLM に食わせる」という一点に最適化されている部分にあり、その用途から外れると割高に感じられる。検索結果を人間がそのまま読む画面に出すなら、要約済みのフォーマットはむしろ過剰加工になる点も覚えておきたい。
結果の鮮度と網羅性
Tavily が返すのは検索エンジン経由で到達できる公開ページの情報であり、ログインの先にあるコンテンツや、インデックスされていない新しいページは拾えない。最新ニュースのように鮮度が要る用途では、取得したページの公開日時を確認したうえで LLM に渡すかどうかを判断するロジックを挟むと、古い情報を根拠にした回答を防げる。RAG の情報源として組み込む際は、Tavily の結果を唯一の真実として扱わず、社内ドキュメントなど信頼できるソースと組み合わせる前提で設計しておくと堅牢だ。