個人的にはLakebase Searchの発展に期待（オートスケールのコントロールが容易だから）
はじめに
Databricksでは非構造データ（PDF、Wordドキュメント、テキストなど）を検索して回答に使うエージェントを作ることができますが、最近複数のアプローチが提供されるようになってきました。
そこで今回は、2026年9月時点で利用可能な以下の3つの検索機能を比較してみます。
- AI Search（旧 Vector Search）
- Lakebase Search
- コンテンツ検索（Content search for Unity Catalog volumes）
各機能の提供状況やスペックは2026年9月時点の情報です。Lakebase Searchとコンテンツ検索はBeta機能のため、今後変更される可能性があります。
それぞれの機能を整理する
AI Search（旧 Databricks Vector Search）とは
Databricksプラットフォームに組み込まれた検索ソリューションで、RAGシステムやレコメンデーションなどのAIアプリケーション向けに設計されています。
Databricksで最もスタンダードなエージェント向けの検索サービスです。
主な特徴は以下の通りです：
- ハイブリッド検索: セマンティック検索（ベクトル類似度）とキーワード検索（BM25）を組み合わせ可能
- Delta Tableとの自動同期: ソースのDelta Tableが更新されると、インデックスも自動で同期
- Databricksマネージドの埋め込み生成: 埋め込みモデルを指定すれば、Databricks側でベクトル化してくれる
- フィルタリング・リランキング対応: メタデータフィルタやリランカーで検索精度を向上
- Unity Catalog統合: ACLによるアクセス制御
- MCP Server対応: エージェントからMCP経由で直接クエリ可能
インデックスの種類：
| インデックスタイプ | 埋め込み管理 | 同期 | 用途 |
| Delta Sync（Databricksマネージド） | Databricksが自動生成 | 自動 | 最も手軽。テキストデータを渡すだけ |
| Delta Sync（セルフマネージド） | 自分で事前計算 | 自動 | 独自の埋め込みモデルを使いたい場合 |
| Direct Vector Access | 自分で管理 | 手動（REST API） | 完全にカスタムしたい場合 |
| Full-text Search（Beta） | 不要 | トリガー | キーワード検索専用。ベクトル不要 |
エンドポイントの種類：
| エンドポイント | 容量 | レイテンシ | 特徴 |
| Standard | 最大3.2億ベクトル（768次元） | 低い | High QPS対応。本番向け |
| Storage-optimized | 最大10億ベクトル（768次元） | やや高い（約250ms） | 大規模データ向け。インデックス構築が10-20倍速い |
Lakebase Searchとは
Lakebase（DatabricksのマネージドPostgresデータベース）に追加されたハイブリッド検索機能です。Postgres拡張として提供されます。
以下に記載するように、Lakebaseの高いパフォーマンスを活かした検索処理を提供します。
Lakebase Searchは現在Beta機能です。
主な特徴は以下の通りです：
-
Postgres拡張ベース:
lakebase_vector（ANN検索）とlakebase_text（BM25全文検索）の2つの拡張 - pgvector互換: 既存のpgvectorのクエリ構文がそのまま使える
- 高速インデックス構築: IVFパーティショニング + RaBitQ量子化で、HNSWの50-100倍速い構築
- 10億ベクトル対応: 単一インデックスで10億ベクトルをサポート
- Scale-to-zero対応: ストレージバックドなのでウォームアップ不要
- ハイブリッド検索: RRF（Reciprocal Rank Fusion）でベクトル検索とキーワード検索を統合
- 標準SQL: PostgreSQLのSQLでクエリを書ける
拡張の構成：
| 拡張 | 目的 | インデックスタイプ |
lakebase_vector |
ANN ベクトル検索（pgvector互換） | lakebase_ann |
lakebase_text |
BM25 全文検索（FTS互換） | lakebase_bm25 |
コンテンツ検索（Content search for Unity Catalog volumes）とは
Unity Catalogのボリュームに格納されたファイル（PDF、Word、画像など）を自動でパース・インデックス化し、Genie Agentなどから検索可能にする機能です。
コンテンツ検索は現在Beta機能です。
主な特徴は以下の通りです：
- ノーコード: Catalog ExplorerからワンクリックでON/OFFできる
- 自動パース: PDF、Word、PowerPoint、画像ファイルを自動で解析・インデックス化
- Genie Agent連携: ボリュームをGenie Agentにアタッチすると、ファイルの内容に基づいて回答してくれる
- Unity Catalog統合: ボリュームの権限管理がそのまま適用される
対応ファイル形式： PDF, JPG, JPEG, PNG, TIFF, TIF, DOC, DOCX, PPT, PPTX
制限事項：
| 項目 | 制限 |
| 対象ボリューム | Unity Catalogマネージドボリュームのみ |
| ワークスペースあたりの有効化数 | 最大100ボリューム |
| ボリュームあたりのファイル数 | 最大10,000ファイル |
| ファイルサイズ上限 | 50 MB |
| 同期 | 手動（Sync now） |
3つの機能を比較する
| 観点 | AI Search | Lakebase Search | コンテンツ検索 |
| ステータス | GA（一部Beta） | Beta | Beta |
| 検索方式 | ベクトル / キーワード / ハイブリッド | ベクトル / キーワード / ハイブリッド | 内部的にインデックス化（詳細非公開） |
| データソース | Delta Table | Lakebase（Postgres）テーブル | Unity Catalog ボリューム内のファイル |
| 埋め込み管理 | Databricksマネージド or セルフ | セルフ（外部モデルで生成） | 自動（ユーザー操作不要） |
| セットアップ難易度 | 中（インデックス作成・エンドポイント設定が必要） | 高（Lakebaseプロジェクト＋拡張インストール＋SQL） | 低（UIからワンクリック） |
| スケール | 最大10億ベクトル | 最大10億ベクトル（単一インデックス） | 最大10,000ファイル/ボリューム |
| エージェント連携 | MCP Server / AI Bridge / UC Function | PostgreSQLクライアント経由（カスタム実装） | Genie Agent（ボリュームアタッチ） |
| 同期 | 自動（Continuous / Triggered） | リアルタイム（INSERT/UPDATE即反映） | 手動（Sync now） |
| カスタマイズ性 | 高（チャンキング、埋め込みモデル、フィルタ、リランカー） | 高（SQL、インデックスチューニング、RRFパラメータ） | 低（ブラックボックス） |
| コスト構造 | エンドポイント＋インデックス課金 | Lakebaseコンピュート課金 | パース・インデックス化の処理コスト |
| 対応データ形式 | テキスト（Delta Table内） | テキスト（Postgresカラム内） | PDF, Word, PPT, 画像 |
ユースケース別の選び方
必ずしも以下の通りではないと思いますが、概ねこういう方向かと思います。
AI Searchが向いているケース
- 大規模なドキュメントコーパスに対するRAGを構築したい
- Delta Lakeにデータパイプラインが既にある
- 埋め込みの管理をDatabricksに任せたい
- MCP経由でエージェントから直接クエリしたい
- 本番環境で安定した検索性能が必要
Lakebase Searchが向いているケース
- エージェントのメモリやステート管理と検索を同じDBで完結させたい
- PostgreSQL互換のエコシステム（LangGraph、OpenAI Agents SDKなど）を活用したい
- リアルタイムにデータが更新される環境で即座に検索に反映したい
- OLTPワークロードと検索を統合したい
コンテンツ検索が向いているケース
- とにかく手軽にファイルの中身を検索したい（ノーコード）
- Genie Agentでドキュメントに基づくQ&Aを作りたい
- ファイル数が少なめ（数千件以下）で、カスタマイズ不要
- パイプライン構築やインデックス設計をしたくない
まとめ
Databricksでエージェント向けに非構造データを検索する3つの機能を比較してみました。
本格的なRAGを構築するならAI Searchが最も成熟していて安心感がある（というかGAなのがこれしかない）と思います。が、エンドポイントを常時起動させておく必要があるため、お財布を考えると悩ましいところが多いです。せめて停止機能が欲しい。
Lakebase SearchはPostgres互換という強みがあり、エージェントのステート管理と検索を同じDBで完結できるのが魅力的です。また、ゼロスケールも可能であり、Lakebaseのポテンシャルがめちゃめちゃ高いので、個人的にはこちらの発展を期待しています。とはいえBetaですし、本番適用に向けてはまだ正式サービス待ちという状態。
コンテンツ検索は「ボリュームにファイル置いてスイッチON」で使えるお手軽さが最大の武器です。現状Genieエージェントからの利用に限定されてそうですが、内部はLakebase Searchを利用しているっぽいのでこちらも期待しています。ただしこちらもまだBetaなので、Public Preview/GAが待たれます。
今後LTAPの登場によって、またいろいろ変わってくる可能性がありますが、エージェントとデータの連携の重要性は高まる一方ですのでより良いものへの機能統合や使い勝手の向上、お財布に優しいサービスが出てくることを期待しています。