AI検索は垂直検索へ：2026年に特化型リトリーバルが勝つ理由
プロダクトマネージャーが汎用AI検索に「新しいオンボーディングのバグで止まっているユーザーは誰か」と聞く。返ってきた答えは流暢で、公開ドキュメントも2つ引用している。しかし社内ワークスペースにあるサポートチケット、変更履歴、feature flagのメモは見落としている。開発者がフレームワーク移行について聞くと、もっともらしい要約は返るが、メンテナーが例外ケースを説明したissueには届かない。SEO担当者がトラフィック低下後に競合が何を変えたか調べると、実際のSERPや製品ページではなく一般論が返ってくる。
ここにギャップがある。汎用回答エンジンは全体像をつかむには便利だが、多くの実務では、領域、コーパス、権限、関連性の定義を理解するリトリーバルが必要になる。だからAI検索は垂直検索へ向かっている。Exa、DanswerまたはOnyx、Devv、Lumona、Airweave が興味深いのは、同じことをしているからではなく、それぞれ検索問題を狭く定義しているからだ。
汎用回答エンジンは出発点であり、ワークフローではない
最初のAI検索は、リンク一覧ではなく回答を期待する体験を広めた。多くの質問では、引用付きの要約は10個のタブを開くより速い。しかしプロダクト運用、SEO、AI開発のチームはすぐに別の問いにぶつかる。何と比べて速いのか。
「ベクトルデータベースを説明して」なら汎用検索で十分だ。「価格ページ更新後にtrial-to-paidが落ちた理由を示す3つの文書を探して」なら不十分だ。答えは社内分析メモ、リリース履歴、実験ID、CMS編集履歴、顧客が実際に見た文言に依存する。広いモデルはウェブを要約できるが、リトリーバル層が正しい証拠を入れなければ、証拠の流れは推測できない。
これは AIコンテンツ運用 や カスタマーサポートのナレッジベース と同じ教訓だ。モデル品質は重要だが、信頼を決めるのはリトリーバル品質である。
垂直AI検索とは何か
垂直AI検索は、検索ボックスに業界名を付けただけのものではない。多くの場合、限定されたコーパス、領域固有のランキングシグナル、インフラとして使えるインターフェース、監査可能な出典を持つ。
ExaはAIアプリケーション向けのウェブ検索とリトリーバルに近い。Devvは開発者検索にフォーカスする。Danswer/OnyxとAirweaveは企業知識検索やエージェント向け知識取得に近い。Lumonaは製品発見と比較の文脈にある。境界は弱点ではなく、品質を上げるための機能だ。
ランキングシグナルも変わる。開発者検索では公式ドキュメント、GitHub issue、パッケージバージョン、変更履歴、メンテナーコメントの重み付けが重要になる。製品調査ではベンダー主張、価格、レビュー、アフィリエイトバイアスを分けて見る必要がある。社内検索では鮮度、アクセス権、正本性が欠かせない。
違うツールが同じ方向を示している
ExaはAIネイティブなウェブリトリーバルの例だ。研究エージェント、見込み客調査、コンテンツインテリジェンスでは、一般的なSERPスニペットより、関連性の高い最新ページを取得できる方が役に立つ。
Danswerは現在Onyxプロジェクトとして見かけることが多く、企業ナレッジ検索を代表する。問題は情報不足ではなく、ドキュメント、チャット、チケット、Wikiに分散していることだ。有用なアシスタントには、コネクタ、権限、鮮度、出典追跡が必要になる。
Devvは開発者検索に独自ロジックが必要な理由を示す。開発者が欲しいのは一般論ではなく、APIの挙動、エラーパターン、リリースノート、コードに近い説明だ。Lumonaは製品発見と比較の垂直領域を示す。Airweaveはリトリーバルをエージェント基盤として扱う点でAI開発者にとって興味深い。
これは エージェント運用ファネル や MCP SaaS統合戦略 ともつながる。エージェントが実ワークフローに触れた瞬間、リトリーバルは本番アーキテクチャの一部になる。
なぜ領域特化型が多くの業務で勝つのか
垂直検索の主張は、汎用AI検索が悪いということではない。関連性はローカルだということだ。
SEOチームにとって関連性とは、対象SERP、ページ種別、競合セット、変更日を反映する出典であること。helpful contentについての一般論より、順位を上げたページ、勝ったクエリ、実際の変更点を含む資料の方が価値がある。
プロダクト運用では、関連性はフィードバックをワークフローに結びつけることだ。Intercomの不満、失敗したオンボーディングイベント、ドキュメント編集、Slackスレッドが同じ問題を指すことがある。垂直リトリーバルはそれらをまとめるべきだ。汎用検索は分断された断片として扱うか、そもそもアクセスできない。
AI開発者にとっては、ツール選択の曖昧さを減らすことが関連性になる。エージェントがどこからでも取得できると、内部runbookではなく古いブログを選ぶかもしれない。垂直層は、ポリシーをチャットより上に、公式ドキュメントをフォーラムより上に、新しいチケットを古い要約より上に置ける。
導入の進め方
ツールカテゴリではなく、ワークフローから始める。サポート削減、競合コンテンツ調査、開発者issueのトリアージ、営業支援、プロダクトフィードバック分析など、検索の悪さで繰り返し困っている意思決定を選ぶ。そして熟練者が確認する情報源を書き出す。
次にリトリーバルマップを作る。各ソースを公開、非公開、正本、古くなりやすい、権限注意、弱いシグナルに分類する。SEOならSERP保存、Search Consoleエクスポート、競合ページ、CMS履歴、既存コンテンツ台帳。プロダクト運用ならチケット、リリースノート、ドキュメント、分析メモ、営業通話メモが入る。
そのうえで用途に合う垂直レイヤーを選ぶ。外部の最新ページが必要ならAPIファーストのウェブリトリーバル、社内知識ならエンタープライズ検索、コードとissueが中心なら開発者検索、出力が行動を起こすならエージェント知識基盤だ。
最初の1か月は自動化より出典レビューを優先する。「答えは良いか」ではなく「シニアメンバーならこの出典を選ぶか」を見る。出典が間違っていれば、答えはきれいなリスクになる。出典が正しければ、平凡な要約でも実務に使える。
無視できないトレードオフ
垂直検索には運用コストがある。コネクタ、重複排除、権限、正本の定義を管理しなければならない。小さなチームが全ての用途でこの複雑さを持つ必要はない。探索的な調査なら、汎用回答エンジンが最初の入口として適していることも多い。
ベンダー依存もある。コンテンツ分析が特定のリトリーバルAPIに依存したり、サポートが特定の企業検索インデックスに依存したりするなら、エクスポート、フォールバック、ログが必要だ。リトリーバルはブラウザタブではなくインフラとして扱うべきだ。
その見返りは信頼である。プロダクト運用は自分たちのシステムに根ざした出典で速く動ける。SEOは実ページとクエリに戻れる分析を公開できる。AI開発者は、失敗がより説明しやすいエージェントを作れる。AI検索は一つの万能回答箱にはならない。一般的な方向付け、垂直な専門性、エージェント向けリトリーバル基盤へ分かれていく。