MicrosoftがBuild 2026（2026年6月2日）にて、エージェントAIワークロード向けに設計されたPostgreSQL互換データベース「Azure HorizonDB」のパブリックプレビューを正式に開始した。昨年12月のアナウンスから半年、開発者が実際に触れる段階にようやく到達した。

何が使えるようになったのか

リリース時点で利用可能なリージョンはAustralia East、Central US、Sweden Central、West US 2、West US 3の5か所。Japan East（東日本）、Korea Central、Canada Centralなどは「coming weeks（数週間以内）」での追加が予告されており、日本のユーザーも間もなく国内リージョンから利用できる見通しだ。

プロビジョニングはAzureポータル、REST API、VS Code PostgreSQL拡張機能の3経路から可能。料金体系はvCore単位のコンピュート課金とGiB/月のストレージ課金による従量制だが、具体的な料金は現時点で非公開。本番導入を検討するチームはGA前の価格発表を待ってからROI試算に入ることを強く勧める。

DiskANN Advanced Filtering：なぜ重要なのか

2026年のAIアプリ開発でベクター検索はもはや標準機能だ。pgvectorを搭載したマネージドPostgreSQLサービスは各社が出揃っている。HorizonDBが差別化を図るのがDiskANN（Disk-based Approximate Nearest Neighbor）の先進フィルタリング実装だ。

標準的なpgvector（HNSW）によるベクター検索は2パス構成を取る。①ベクター空間で近傍候補を取得、②WHERE句でフィルタリング。問題は、実際のエージェントクエリのほとんどが「特定ユーザーが過去7日間に生成した、価格に関連する上位10件のメモリ」のように多条件フィルタを伴う点にある。後処理フィルタでは「計算してから捨てる」という無駄が生じる。

DiskANNのAdvanced Filteringはグラフ探索とフィルタ評価を1パスで同時実行する。Microsoftが公表したベンチマークでは、フィルタの選択性によってはクエリレイテンシを最大3分の1に削減できるとしている。独立機関によるベンチマークはプレビュー段階のためまだ存在しないが、アルゴリズム的な根拠は妥当であり、単なるマーケティングトークではないと評価できる。

Microsoft Foundry経由のインデータベースAI推論

HorizonDBの特徴のひとつが、Microsoft FoundryとのネイティブSQL統合だ。エンベディング生成、生成AIモデルの呼び出し、リランキングをSQL内から直接実行でき、アプリケーション側にAPIキーもHTTPクライアントも不要になる。モデル費用はFoundryの標準レートで課金される。

RAGパイプラインやエージェントメモリ基盤を構築するチームにとっては、APIプロキシ・エンベディングサービス・モデルルーティングといったインフラレイヤーを丸ごと省略できる可能性がある。ただしプレビュー段階のデータベースをこの用途でプロダクション投入するかどうかは、チームのリスク許容度と照らし合わせて慎重に判断すべきだ。

VS Code PostgreSQL拡張機能がGA

HorizonDB関連の発表の中で見落とされがちだが、VS Code PostgreSQL拡張機能が50万インストールを突破しGAに到達した。GitHub Copilotとのスキーマコンテキスト統合により、スキーマを理解した補完候補とワンクリックパフォーマンスデバッグが可能になっている。

プレビューとして注目したいのがOracleマイグレーションツールだ。AIを活用してOracleスキーマをPostgreSQLへ変換し、複雑な構文は「Review Tasks」として人間のレビューに回す仕組みを採る。OracleのCPUライセンスコストに頭を抱えているエンタープライズ企業にとって、構文のsed置換ではなくスキーマを理解した自動変換ツールは現実的な選択肢になり得る。

正直な制約事項

HorizonDBはサーバーレスではない。コンピュートは手動設定が必要で、スループット需要に応じてレプリカを自分で追加・削除する運用が求められる。ストレージは自動スケールするがコンピュートはしない。Aurora Serverlessのような完全自動スケーリングに慣れたチームには運用負荷の増加となる点は正直に認識しておきたい。

実務への影響

日本のエンジニア・アーキテクト向けの実践的な観点を整理する。

  • Japan Eastリージョンの追加を待ってから評価開始が現実的。現時点でのサインアップはアーキテクチャの事前検討と割り切る
  • RAGパイプラインの再設計チャンス: 既存のエンベディングサービスをHorizonDBのインデータベース推論に移行できれば、インフラ構成がシンプルになる可能性がある
  • 料金情報が出るまで本番移行計画はペンディング: vCore単価とストレージ単価によっては、Flexible Serverと比較して割高になるケースもある
  • Oracle脱却プロジェクトで有望な候補: VS Code拡張のマイグレーションツールは、Oracle→PostgreSQL移行の検討段階から試用する価値がある
  • Microsoft Foundryとの組み合わせが前提設計: HorizonDBを最大活用するには、AI推論基盤としてFoundryをセットで検討する構成が自然な流れになる

筆者の見解

Azure HorizonDBが取り組んでいる問題設定は正しい。エージェントAIのワークロードは「多条件フィルタ付きベクター検索を高速に、かつAIモデル推論と密結合で」という要求を持っており、汎用PostgreSQLをそのまま使い続けることへの不満は確かに存在する。DiskANNのアーキテクチャは技術的に筋が通っており、独立ベンチマークが出揃えばより明確な評価が下せるだろう。

Microsoft Foundryとのネイティブ統合という方向性も、「Azure基盤の上で動かすAIを柔軟に選ぶ」というプラットフォーム戦略と一致している。エージェントが安全に動作するプラットフォームを提供するという競争でMicrosoftが優位にいる、という筆者の見立てに沿った動きでもある。

ただし、価格を非公開のまま「まず触ってみて」というアプローチはエンタープライズ向けには機能しづらい。 日本の大手企業では、概算コストが出ないと検証予算すら通らないケースが多い。GAまでに明確な料金体系を提示してほしいところだ。また、サーバーレス対応が見送られた点は、競合サービスと比較した際に弱点になる。コンピュートの自動スケールはGAまでのロードマップに入っているのか、Microsoftには是非明らかにしてもらいたい。

HorizonDBが目指している世界は正しい方向にある。あとはプレビューから本番グレードへの仕上げを、スピードを落とさずにやり切れるかだ。

出典: この記事は Azure HorizonDB Public Preview: What Developers Need Now の内容をもとに、筆者の見解を加えて独自に執筆したものです。