AIエージェントはウェブを検索する必要があります。クロールではありません。スクレイピングでもありません。検索——質問を投げかけ、出典付きの回答を得ること。
選択肢はいくつかあります。Google Programmable Search、Perplexity API、Bing Web Search、Tavily、Exa、AnyCap grounded search。それぞれ動作方式が異なり、検索品質・回答合成・引用処理・開発者体験の間で異なるトレードオフを行います。
エージェントにウェブアクセスを与える際に本当に重要なこと、そしてどのAPIがどのワークフローに適しているかを整理しました。
2つのアーキテクチャ：検索（retrieval）vs. グラウンデッドサーチ
すべてのウェブ検索APIは、次の2つのアーキテクチャのいずれかに分類されます。
検索専用（Retrieval-only）APIはリンクを返します。エージェントはURL、タイトル、スニペットを受け取り、各ページを訪問してコンテンツを抽出し、自ら回答を合成しなければなりません。Google Custom Search、Bing Web Search、Exaがこの方式で動作します。
検索専用フロー：
エージェント: search("query") → URL + スニペット
エージェント: 各URLをクロール → コンテンツ抽出
エージェント: コンテンツをLLMに渡す → 回答合成
エージェント: 引用リストを手動で作成
グラウンデッドサーチ（Grounded search）APIは回答を返します。エージェントはインライン引用付きの合成済み回答を受け取ります——検索、コンテンツ抽出、合成がすべて1回のAPIコールで完結します。Perplexity APIとAnyCap grounded searchがこの方式で動作します。
グラウンデッドフロー：
エージェント: search("query") → 回答 + 引用
エージェント: 回答をユーザーまたは次のステップに渡す
この違いは学術的なものではありません。検索専用APIはエージェントにリンクリストを渡します。グラウンデッドサーチAPIはエージェントに回答を渡します。その差が、自分で構築しなければならないインフラのすべてです。
API比較
AnyCap Grounded Search
アーキテクチャ： グラウンデッドサーチ（1回のコールで回答＋引用を返す）
アクセス方法： CLI — anycap search "query" --citations
動作方法： エージェントが単一のコマンドを実行します。AnyCap はリアルタイムウェブを検索し、上位の結果を取得。ソースページをクロールして完全なコンテンツを取得し、それらのソースを根拠とした回答を合成して、インライン引用とソースURLとともに返します。
主な特徴：
- リンクリストではなく合成済み回答を返す
- ソースURL付きインライン引用——すべての主張が追跡可能
- 構造化出力で、jqにパイプしてフィールド抽出が可能
- 1つのCLI。AnyCap の他のすべての機能と同じインターフェース
- 無料ティア：新規ユーザーに250クレジット
最適な用途： エージェントが調査プロジェクトではなく回答を必要とするワークフロー。検索が分析・生成・公開に直接つながるパイプライン——すべて1つのCLIで。
例：
anycap search "latest Go 1.25 changes" --citations | jq '.data.content'
Perplexity API（Sonar Pro）
アーキテクチャ： グラウンデッドサーチ（回答＋引用）
アクセス方法： SDKをサポートするREST API。検索対応モデルで POST /chat/completions。
動作方法： Perplexity APIはリアルタイムウェブ検索をLLMの回答に統合します。モデルが最新情報を取得し、インライン引用付きの回答を返します。
主な特徴：
- 高速——数秒で回答
- インラインソースリンク付きの優れた引用処理
- 構造化レスポンスでAPI使いやすい
- 複数モデル：Sonar（高速）、Sonar Pro（より深い）、Sonar Reasoning Pro
- リアルタイムウェブアクセス——最新情報や事実確認クエリに適切
制限：
- 検索強化型の回答であり、深いマルチソース調査ではない
- 大規模利用では比較的コストが高い
- 他の機能とは別のAPI——調査、画像生成、公開には別途の統合が必要
最適な用途： リアルタイムのファクトチェック、最新情報クエリ、迅速な情報取得。深さより速さが重要なチャットボットアプリ。
例：
import requests
response = requests.post(
"https://api.perplexity.ai/chat/completions",
headers={"Authorization": "Bearer $PERPLEXITY_API_KEY"},
json={
"model": "sonar-pro",
"messages": [{"role": "user", "content": "Latest Go 1.25 changes"}]
}
)
Google Programmable Search Engine
アーキテクチャ： 検索専用（リンク＋スニペット）
アクセス方法： REST API。以前は「Custom Search API」。Google Cloudプロジェクトのセットアップが必要。
動作方法： エージェントが設定済みの検索エンジンを通じてGoogleの検索インデックスをクエリします。URL、タイトル、テキストスニペットを返します。エージェントは各ページをクロールし、コンテンツを抽出して回答を合成する必要があります——3つの独立したステップです。
主な特徴：
- Googleの検索インデックス——利用可能な最高の検索品質
- 設定可能：特定サイトに限定するか全ウェブを検索するか
- 無料ティア：100クエリ/日
- 十分なドキュメントが整ったREST API
制限：
- リンクを返すのみで回答は返さない。コンテンツ抽出と合成のための別途パイプラインが必要。
- Custom Search Engineは、Site Searchを有料にしない限り10サイトに制限。
- AI合成なし——回答生成用のLLMは自分で用意する必要がある。
- 設定が複雑：GCPプロジェクト、API有効化、認証情報の管理。
最適な用途： Googleの検索インデックスが必須であり、コンテンツ抽出と合成を別途処理するインフラを持つワークフロー。
例：
# ステップ1：Googleからリンクを取得
results = google_search("latest Go 1.25 changes")
urls = [r['link'] for r in results['items']]
# ステップ2：各ページをクロール（別ツールまたはサービス）
contents = [crawl(url) for url in urls]
# ステップ3：回答を合成（別LLMコール）
answer = llm.generate(f"Summarize: {contents}", citations=urls)
Bing Web Search API
アーキテクチャ： 検索専用（リンク＋スニペット）
アクセス方法： Azure Cognitive Services経由のREST API。
動作方法： Microsoftの検索インデックス。ウェブページ、画像、動画、ニュース結果をスニペット付きで返します。多くのクエリでGoogleと同等の検索品質。
主な特徴：
- 優れた検索品質——Microsoftの検索インデックス
- マルチモーダル：1つのAPIでウェブ、画像、動画、ニュースの結果を取得
- 一部プランで月1,000クエリの寛大な無料ティア
- Azureとの統合ドキュメントが充実
制限：
- 検索専用——エージェントが合成を担当する。
- Azureサブスクリプションとリソースのセットアップが必要。
- Azure固有の認証フロー。
最適な用途： Microsoftエコシステムのチーム。ウェブ検索と並行して画像検索やニュース検索も必要なワークフロー。
Tavily
アーキテクチャ： ハイブリッド——検索＋軽量合成
アクセス方法： REST API。AIエージェント検索に特化して構築。
動作方法： Tavilyは複数のソースを検索し、関連コンテンツを抽出して、生の結果と合成済みサマリーの両方を返します。AIエージェントやRAGシステム向け検索APIとして特別に設計されています。
主な特徴：
- AIエージェント向けに構築——汎用検索APIよりすっきりしたAPI設計
- 生の結果と合成済み回答の両方を返す
- 検索の深さとドメインの包含/除外が設定可能
- 開発者に優しいドキュメント
制限：
- GoogleやBingより小さい検索インデックス
- クエリの複雑さによって合成品質が変わる
- 他の機能とは別個の統合
- クエリごとの課金は大規模になると積み重なる
最適な用途： GoogleやBingより優れた開発者体験を持つ専用検索APIが必要なAIアプリ。外部データが必要なRAGシステム。
Exa
アーキテクチャ： 意味的理解を持つ検索
アクセス方法： REST API。AI向けのコンテンツ重視型検索。
動作方法： Exaは意味的理解によるコンテンツ検索に特化——キーワードではなく意味でページを見つけます。スニペットではなく完全なページコンテンツをクリーンなテキスト抽出とともに返します。
主な特徴：
- セマンティック検索：キワードではなく意味でページを発見
- スニペットではなく完全なページコンテンツを返す
- 特定の種類のコンテンツ（企業ページ、ドキュメント、研究論文）の発見に適している
- コンテンツ重視：AI消費向けに設計
制限：
- 検索専用——合成はユーザーの責任。
- 意味的なフォーカスのため、キーワード特化クエリの結果は異なる場合がある。
- GoogleやBingより小さいインデックス。
最適な用途： 回答合成より適切なコンテンツの発見が重要なワークフロー。深い分析のために完全なページコンテンツが必要な調査。
比較マトリクス
| AnyCap GS | Perplexity | Google PSE | Bing | Tavily | Exa | |
|---|---|---|---|---|---|---|
| タイプ | グラウンデッド | グラウンデッド | 検索専用 | 検索専用 | ハイブリッド | 検索専用 |
| 返すもの | 回答＋引用 | 回答＋引用 | リンク＋スニペット | リンク＋スニペット | リンク＋サマリー | リンク＋コンテンツ |
| エージェントアクセス | CLI | REST API | REST API | REST API | REST API | REST API |
| 引用 | ✅ インライン | ✅ インライン | ❌ なし | ❌ なし | ⚠️ 部分的 | ❌ なし |
| セットアップ | コマンド1つ | APIキー＋SDK | GCPプロジェクト | Azureリソース | APIキー | APIキー |
| コンポーザビリティ | ✅ 完全 | ❌ 別個 | ❌ 別個 | ❌ 別個 | ❌ 別個 | ❌ 別個 |
| 無料ティア | 250クレジット | なし | 100/日 | 1,000/月 | 制限あり | 制限あり |
| 速度 | 数秒 | 数秒 | ミリ秒 | ミリ秒 | 数秒 | 数秒 |
| 合成品質 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | N/A（合成なし） | N/A（合成なし） | ⭐⭐⭐ | N/A（合成なし） |
何を選ぶべきか
エージェントが1回のコールで引用付き回答を必要とする場合： → AnyCap または Perplexity。エージェントがCLI環境で動作しコンポーザビリティが必要なら（検索→調査→生成→公開を1つのワークフローで）AnyCap。チャットベースのアプリを開発しているならPerplexity。
エージェントが最高の検索品質を必要とし、合成インフラがある場合： → Google PSE または Bing。最高のインデックス品質ならGoogle。Azureを使用しているならBing。
エージェントが合成ではなくクリーンなコンテンツ抽出を必要とする場合： → Exa または Tavily。セマンティックコンテンツ発見にはExa。軽量合成を含むバランスの取れたアプローチにはTavily。
エージェントが統合ワークフローの中で多くの機能の1つとして検索を必要とする場合： → AnyCap。価値は検索だけにあるのではありません——検索、ディープリサーチ、画像生成、公開がすべて1つのCLIと1つの認証の下に集約されているのが核心です。
フレームワーク：検索（retrieval）は基礎、合成（synthesis）が差別化要素
すべての検索APIはリンクを返します。違いはその後に何が起こるかです。
検索専用APIは「URLが10件あります」で止まります。エージェントが残りをすべてやらなければなりません。グラウンデッドサーチAPIは「回答はこれで、各情報の出典はここです」と言います。エージェントはそのまま渡せばよい。
エージェントが速度重視の大量ファクトチェックを行っており、検索から合成へのパイプラインを自分で構築したくないなら、グラウンデッドサーチが実用的な選択です。Googleの検索インデックスが具体的に必要で、残りを処理するインフラがあるなら、検索専用でも機能します——中間部分を自分で構築するだけです。
関連記事：
- AIエージェント向けAI検索：Grounded Search vs RAG — RAGがリアルタイムウェブアクセスの答えでない理由
- AIエージェントにウェブ検索機能を与える方法 — CLIチュートリアル（ステップバイステップ）
- 2026年AIエージェント向けベストCLIツール — エージェント向けCLIエコシステム