Azure HorizonDBのDiskANN vector searchに追加されたAdvanced filteringは、ベクトル類似検索とtenant_id、カテゴリ、日付範囲、価格などのメタデータ条件を、1つのSQLで組み合わせやすくするプレビュー機能です。特にRAG、AIエージェント、レコメンド、マルチテナント検索で「意味的に近い結果だけでなく、権限・カテゴリ・期間・価格条件にも合う結果を高速に返したい」ケースに効きます。
結論から言うと、Azure HorizonDBでDiskANNを使っている、またはこれからAI検索基盤を設計する開発者は確認すべきアップデートです。一方で、Public Preview段階の機能であるため、本番移行を急ぐのではなく、既存のベクトル検索クエリ、メタデータ設計、インデックス、リージョン、パフォーマンス検証手順を整理したうえで、検証環境から段階的に試すのが安全です。Microsoft Learnでも、DiskANNのAdvanced filteringはAzure HorizonDB上でプレビューとして説明されており、メタデータ述語をDiskANNインデックス側に押し込むことで、アプリケーション側の後処理や過剰取得を避けやすくなるとされています。(Microsoft Learn)
Azure HorizonDBのDiskANN advanced filteringとは
Azure HorizonDBは、Microsoft Azure上で提供されるPostgreSQL互換のクラウドデータベースサービスです。AI、ベクトル検索、トランザクションデータを同じ基盤で扱う用途が想定されており、Azure HorizonDBの製品ページでも、エージェントやレコメンデーションエンジンなどのAI対応アプリケーションを構築する用途が示されています。(Microsoft Azure)
今回の「Advanced filtering for DiskANN vector search in Azure HorizonDB」は、DiskANNによるベクトル類似検索に、通常のPostgreSQLのWHERE句によるメタデータ条件を組み合わせるための機能です。
たとえば、次のような検索を1つのSQLで扱いやすくなります。
- 特定テナントのデータだけを対象に、問い合わせ文に近いナレッジを探す
- 商品カテゴリと価格帯で絞り込んだうえで、意味的に近い商品を返す
- 過去30日以内に更新されたドキュメントだけを対象に、RAG用の候補を取得する
- 言語、ステータス、公開範囲などを条件に含めて、AI検索の候補を制御する
従来のベクトル検索では、「まずベクトル類似度で上位候補を取る」「その後にアプリケーション側やDB側でフィルターする」という構成になりがちでした。この方法では、フィルター条件が厳しい場合、最初に取得した候補の多くが捨てられ、必要な件数が揃わない、関連性が落ちる、追加取得や再ランキングが必要になる、といった問題が起きます。
DiskANNのAdvanced filteringでは、メタデータ条件をDiskANNインデックスの探索中に評価します。つまり、LIMITで指定した件数を満たすまで、WHERE条件に合う候補を探索し続ける動きになります。Microsoft Learnでは、IVFFlatやHNSWが候補取得後にフィルターするのに対し、DiskANNのAdvanced filteringはインデックス走査中に述語を評価すると説明されています。(Microsoft Learn)
何が変わるのか
今回の変更点は、単に「フィルター付き検索が書ける」という話ではありません。実務上の変化は、AI検索の設計をシンプルにしやすくなる点にあります。
| 観点 | 従来起きやすかった課題 | Advanced filteringで期待できる変化 |
|---|---|---|
| 検索精度 | フィルター後に候補が減り、関連性の高い結果が残らない | 条件に合う候補をインデックス探索中に探しやすい |
| アプリケーション実装 | 多めに候補を取得し、アプリ側で再フィルター・再ランキングする | 通常のSQLに近い形でWHEREとベクトル順序を併用できる |
| マルチテナント検索 | テナント条件で候補が大きく減り、検索品質が不安定になりやすい | tenant_idなどの条件を含めた検索を設計しやすい |
| 運用 | 外部ベクトルDBや検索サービスとの同期が複雑になる | HorizonDB内のリレーショナルデータとベクトルを近くに置ける |
| チューニング | 候補数、後処理、再取得ロジックの調整が増える | DiskANN側のパラメーターとSQL実行計画を中心に検証しやすい |
特に重要なのは、特別なSQL構文を覚える必要がないことです。Microsoft Learnでは、メタデータ列をテーブルに追加し、DiskANNインデックスを作成し、通常のSELECTでWHERE句とベクトル順序演算子を組み合わせればよいと説明されています。(Microsoft Learn)
対象になる管理者・開発者
このアップデートの影響を受けやすいのは、次のようなチームです。
| 対象者 | 確認すべきポイント |
|---|---|
| RAGアプリ開発者 | ドキュメントの公開範囲、部署、日付、言語などをフィルター条件に含めているか |
| SaaS開発者 | tenant_idや契約プランなど、マルチテナント条件付きの検索があるか |
| EC・レコメンド開発者 | カテゴリ、価格、在庫、地域、販売期間などで絞り込む検索があるか |
| DB管理者 | pg_diskann拡張機能、vector拡張機能、DiskANNインデックス、btreeインデックスの設計が必要か |
| クラウド管理者 | HorizonDBのプレビュー利用、リージョン、課金、ネットワーク、権限管理を確認できているか |
| AI基盤担当者 | 外部ベクトルDBとの使い分け、データ同期、検索精度の評価基準を整理できているか |
すでにAzure Database for PostgreSQLや別のベクトルDBでRAG基盤を作っている場合も、すぐに置き換えるというより、「HorizonDB内でトランザクションデータ、メタデータ、ベクトル検索をどこまでまとめられるか」を検証する材料になります。
Public Previewとして扱うべき理由
この機能はPublic Previewです。Azure Updatesでは、In previewの状態はすべてのAzure顧客が非本番用途とテスト用途で利用できる段階として説明されています。(Microsoft Azure)
そのため、管理者は次の前提で扱うべきです。
| 確認項目 | 実務上の判断 |
|---|---|
| 本番利用 | いきなり主要システムへ適用せず、検証環境・ステージング環境で評価する |
| SLA・サポート | 一般提供前の扱いを前提に、組織のクラウド利用ルールと照合する |
| リージョン | Azure HorizonDB自体がプレビュー中で、利用可能リージョンは限定される可能性がある |
| 仕様変更 | GAまでにパラメーターや制限事項が変わる可能性を考慮する |
| コスト | 検証時もコンピューティング、ストレージ、バックアップ、データ転送の費用を確認する |
Azure HorizonDBは現在プレビューとして提供され、利用可能リージョンも限られると案内されています。最新の対応リージョンや価格条件は、導入前に公式ドキュメントとAzureポータルで確認してください。(Microsoft Azure)
開発者が確認すべきSQLとインデックス設計
Advanced filteringは、特殊なAPIではなくPostgreSQLのSQLに近い形で扱えます。典型的には、ベクトル列とメタデータ列を同じテーブルに持たせ、ベクトル列にDiskANNインデックスを作成します。
CREATE TABLE documents (
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
tenant_id INT NOT NULL,
category TEXT NOT NULL,
published_at TIMESTAMPTZ NOT NULL,
status TEXT NOT NULL,
embedding public.vector(1536)
);
CREATE INDEX documents_embedding_diskann_idx
ON documents
USING diskann (embedding vector_cosine_ops);
CREATE INDEX documents_tenant_category_idx
ON documents (tenant_id, category);検索時は、通常のWHERE句とベクトル距離によるORDER BYを組み合わせます。
SELECT id, category, published_at
FROM documents
WHERE tenant_id = 42
AND category = 'manual'
AND status = 'published'
AND published_at >= now() - INTERVAL '90 days'
ORDER BY embedding <=> :query_embedding
LIMIT 10;ここでのポイントは、tenant_idやcategoryのように頻繁に絞り込む列には、DiskANNインデックスとは別にbtreeインデックスを検討することです。Microsoft Learnでも、よくフィルターする列にはbtreeインデックスを追加し、プランナーが両方のインデックスを組み合わせられるようにすることが推奨されています。(Microsoft Learn)
DiskANNを使う前に必要な設定
DiskANNを使うには、Azure HorizonDBインスタンスでpg_diskann拡張機能を利用できる状態にし、対象データベースで拡張機能を作成する必要があります。pg_diskannはvector拡張機能に依存しているため、vectorも含めて有効化する必要があります。(Microsoft Learn)
代表的な流れは次のとおりです。
| 手順 | 確認内容 |
|---|---|
| 拡張機能の許可 | HorizonDBインスタンス側でpg_diskannを利用可能にする |
| データベースへの作成 | 対象DBでCREATE EXTENSION IF NOT EXISTS pg_diskann;を実行する |
| 依存関係の確認 | vector拡張機能が必要。必要に応じてCASCADEを使う |
| ベクトル列の型 | 埋め込みモデルの次元数に合わせてpublic.vector(1536)などを定義する |
| 距離演算子 | コサイン距離、L2距離、内積など、モデルに合う演算子クラスを選ぶ |
| インデックス作成 | USING diskannでベクトル列にインデックスを作成する |
距離演算子とインデックスの演算子クラスは一致させる必要があります。たとえば、コサイン類似度を使う検索ではvector_cosine_opsと<=>の組み合わせを確認します。
IVFFlat・HNSWからDiskANNへ移行する時の判断基準
Azure HorizonDBでは、Flat、IVFFlat、HNSW、DiskANNといったベクトル検索の選択肢があります。Microsoft Learnの選択ガイドでは、DiskANNは大規模または増加し続けるデータ、高次元ベクトル、フィルター付きクエリに向く推奨デフォルトとして説明されています。(Microsoft Learn)
移行を検討すべき典型例は次のとおりです。
| 現状 | DiskANNを検討すべきサイン |
|---|---|
| IVFFlatを利用 | 新規データ追加後に検索品質が落ちる、定期的な再構築が負担になっている |
| HNSWを利用 | インデックスをRAMに収める前提が厳しくなっている |
| アプリ側で後処理 | 大量に候補を取得してからテナントやカテゴリで絞っている |
| 外部ベクトルDBを利用 | PostgreSQL側の業務データとの同期、整合性、権限管理が複雑になっている |
| 小規模データのみ | 10万件未満などで遅延が問題でない場合は、Flat検索で正解確認を優先してもよい |
移行時にアプリケーションSQLを大きく変えなくてよい点も利点です。Microsoft Learnでは、インデックス種別の変更はアプリケーションSQLではなくCREATE INDEX文の変更で対応でき、停止時間を避けるにはCREATE INDEX CONCURRENTLYで新しいインデックスを作成してから古いインデックスを削除する方法が示されています。(Microsoft Learn)
検証環境で見るべきパフォーマンス指標
Advanced filteringは便利ですが、すべてのクエリが自動的に速くなると考えるのは危険です。検証では、少なくとも次の指標を測るべきです。
| 指標 | 見る理由 |
|---|---|
| p50/p95/p99レイテンシ | 平均だけでなく、ユーザー体験に影響する遅いクエリを確認する |
| Recall | Flat検索などの基準結果と比較し、近い結果を取りこぼしていないか確認する |
| フィルター選択性 | tenant_idやカテゴリで絞った時に対象件数がどれだけ減るかを見る |
| LIMIT値 | LIMIT 5、LIMIT 10、LIMIT 50などで遅延と精度のバランスを見る |
| インデックスサイズ | メモリ、SSD、ストレージコストへの影響を確認する |
| 更新頻度 | 挿入・更新が多い場合の検索品質と書き込み負荷を確認する |
| 同時実行数 | RAGや検索APIのピーク時に遅延が悪化しないか確認する |
特にLIMITは重要です。Advanced filteringはLIMIT句に基づいて動作を調整し、フィルター条件が厳しい場合は必要件数を満たすためにより深くグラフを探索することがあります。その結果、精度を維持しやすい一方で、条件によってはレイテンシが増える可能性があります。(Microsoft Learn)
チューニングで触る可能性があるパラメーター
高度に選択的な条件で検証する場合、セッション単位でDiskANNの動作を調整できます。Microsoft Learnでは、diskann.enable_filter_hook、diskann.selectivity_min、diskann.selectivity_threshold、diskann.filtering_beta、diskann.l_value_isなどの設定例が示されています。(Microsoft Learn)
SET diskann.enable_filter_hook = 'true';
SET diskann.selectivity_min = '0.0';
SET diskann.selectivity_threshold = '1.0';
SET diskann.filtering_beta = 0.85;
SET diskann.l_value_is = 300;ただし、これらは「本番で常に大きくすればよい」設定ではありません。検索精度を上げるためにDiskANNが行う作業量が増えれば、レイテンシも増える可能性があります。まずは既定値で計測し、次に限定的なセッションやトランザクションで変更して比較するのが現実的です。
管理者が確認すべき展開上の注意点
管理者は、SQLだけでなくAzure環境全体の前提も確認する必要があります。
| 確認項目 | 具体的な確認内容 |
|---|---|
| プレビュー利用ポリシー | 組織としてPublic Preview機能をどの環境まで許可するか |
| リージョン | 利用予定リージョンでAzure HorizonDBと対象機能が使えるか |
| ネットワーク | Private Endpoint、接続元制限、監査要件に合うか |
| 認証・認可 | Microsoft Entra ID、DBロール、アプリ側認可をどう組み合わせるか |
| バックアップ・復旧 | HorizonDBのバックアップ条件と復旧手順を検証しているか |
| 監視 | クエリ遅延、CPU、メモリ、ストレージ、接続数、エラー率を見られるか |
| コスト | 検証環境の作りっぱなし、インデックス作成時の一時的なスケールアップを管理できるか |
Azure HorizonDBは、Private Endpoint、既定の暗号化、Microsoft Entra IDによる認証・認可の簡素化などの機能を備えると説明されていますが、検索クエリのtenant_id条件だけをアクセス制御として扱うのは避けるべきです。メタデータフィルターは検索品質と取得範囲を制御する仕組みであり、認可設計そのものではありません。(Microsoft Azure)
失敗しやすいポイント
フィルター条件を関数で包んでしまう
たとえば、日付列に対して毎回関数をかけるような書き方は、プランナーがインデックス側に条件を押し込みにくくなる場合があります。
避けたい例です。
WHERE date_trunc('day', published_at) = date_trunc('day', now())検討したい書き方です。
WHERE published_at >= date_trunc('day', now())
AND published_at < date_trunc('day', now()) + INTERVAL '1 day'Microsoft Learnでも、プランナーがインデックスに押し込めない述語はポストフィルターにフォールバックする可能性があると説明されています。(Microsoft Learn)
JOIN先の列で絞り込む設計にしてしまう
Advanced filteringの制限として、述語はインデックス付きベクトルと同じテーブルの列を参照する必要があります。JOINはベクトル検索の完了後に評価されます。(Microsoft Learn)
そのため、検索時に必ず使うtenant_id、category、status、language、published_atなどは、ベクトル列と同じ検索対象テーブルに持たせる設計を検討します。正規化を優先しすぎて毎回JOINが必要になると、Advanced filteringの効果を得にくくなる可能性があります。
本番データでいきなりインデックスを作る
大規模データに対するインデックス作成は時間とリソースを使います。Microsoft Learnでは、インデックス作成を速くする方法として、maintenance_work_memの調整や並列ワーカーの利用が説明されています。max_worker_processesなど一部パラメーターは反映に再起動が必要な場合もあるため、メンテナンス計画と合わせて確認してください。(Microsoft Learn)
Recallを測らずに「速い」だけで判断する
ANNインデックスは、正確性と速度のバランスを取る仕組みです。検索が速くても、必要な候補を取りこぼしているならRAGの回答品質やレコメンド精度は落ちます。
検証では、サンプルデータに対してFlat検索を基準にし、DiskANNの結果と比較する方法が有効です。Azure HorizonDBの選択ガイドでも、小規模データや正確性確認にはFlat検索が使えると説明されています。(Microsoft Learn)
Hybrid searchとの関係
Azure HorizonDBでは、ベクトル検索だけでなくBM25ベースの全文検索やHybrid searchも組み合わせられます。Hybrid searchは、ベクトル検索による意味的な近さと、BM25によるキーワード一致を組み合わせる方法です。Microsoft Learnでは、多くの本番検索アプリケーションでHybrid searchが推奨されるアプローチとして説明されています。(Microsoft Learn)
Advanced filteringは、このHybrid searchでも重要です。たとえば「ノイズキャンセリング 旅行用」のような自然文検索をしつつ、category = 'audio'で絞り込む場合、DiskANNのAdvanced filteringにより、メタデータ条件をベクトルインデックス側へ押し込めます。Microsoft LearnのHybrid searchドキュメントでも、DiskANNはAdvanced filteringをサポートするため、メタデータのWHERE句とベクトル類似検索を組み合わせてもRecallを失いにくいと説明されています。(Microsoft Learn)
実務では、次のような使い分けが現実的です。
| 検索タイプ | 向いているケース |
|---|---|
| ベクトル検索のみ | FAQ、意味検索、類義語や言い換えが多い検索 |
| BM25のみ | 型番、ログID、エラーコード、完全一致に近い検索 |
| Hybrid search | 自然文検索とキーワード検索が混ざる一般的な検索UI |
| Hybrid search + Advanced filtering | テナント、カテゴリ、公開範囲、日付などで絞る本番AI検索 |
導入前チェックリスト
検証を始める前に、次の項目を確認しておくと手戻りを減らせます。
| チェック項目 | 確認できたらやること |
|---|---|
| HorizonDBを利用できるリージョンか | Azureポータルと公式ドキュメントで確認する |
| Public Previewを使える社内ルールか | 本番・検証・PoCのどこまで許可されるか決める |
| 検索対象テーブルにメタデータ列があるか | tenant_id、category、status、published_atなどを整理する |
pg_diskannとvectorを使えるか | インスタンスとDBで拡張機能の有効化を確認する |
| 距離演算子が決まっているか | 埋め込みモデルに合わせてコサイン距離、L2距離、内積を選ぶ |
| よく使うフィルター列にインデックスがあるか | btreeインデックスを検討する |
| Recallの基準があるか | Flat検索や既存検索結果と比較する評価セットを作る |
| レイテンシ目標があるか | p95やp99の目標値を決めてから検証する |
| 移行計画があるか | 既存インデックスを残したまま並行検証する |
| 監視とロールバックがあるか | 遅延増加や検索品質低下時に戻せる状態にする |
まず何をすべきか
このアップデートで最初にやるべきことは、既存の検索クエリを棚卸しすることです。特に、ベクトル検索後にアプリケーション側でtenant_id、カテゴリ、日付、価格、公開範囲などを絞っている処理があれば、Advanced filteringの効果を検証する価値があります。
次に、検証環境で小さく試します。pg_diskannを有効化し、検索対象テーブルにDiskANNインデックスを作成し、実際のフィルター条件を含むSQLでEXPLAINと実行時間、Recallを確認します。IVFFlatやHNSWから移行する場合は、既存インデックスをすぐ削除せず、DiskANNインデックスを並行して作成し、同じクエリセットで比較するのが安全です。
Azure HorizonDBのDiskANN advanced filteringは、RAGやAI検索の実装を「外部サービスに分散した複雑な構成」から「PostgreSQL互換のSQL中心の構成」へ寄せる可能性があります。ただし、Public Preview段階では、機能の魅力だけで判断せず、リージョン、サポート条件、パフォーマンス、認可設計、コストを含めて評価することが重要です。
まずは、フィルター付きベクトル検索で困っている代表的なクエリを3〜5本選び、HorizonDB上のDiskANN advanced filteringで再現してみてください。その結果をもとに、既存の後処理ロジックを減らせるか、検索品質を改善できるか、本番採用までに何を待つべきかを判断すると、無理のない移行計画を立てられます。
コメント