Azure SQLの更新情報として「Generate Vector Embeddings with Azure OpenAI – Azure Database for PostgreSQL」を見かけ、「既存のAzure SQL環境で設定変更が必要なのか」「RAG基盤を移行すべきなのか」と迷う管理者もいるでしょう。
結論からいうと、この情報はAzure SQL DatabaseやAzure SQL Managed Instanceへの新機能追加ではありません。実際の対象は、Azure Database for PostgreSQL Flexible Serverです。
2026年6月24日付の更新情報として確認された内容を公式ページと公開リポジトリで照合すると、直近の差分はタイトルに「flexible server」を追加し、対象サービスを明確にしたものです。確認できる範囲では、関数仕様やSQL例、必須設定が変更されたわけではありません。そのため、今回の更新だけを理由とする緊急の設定変更や移行期限はありません。(GitHub)
ただし、実際にAzure OpenAIの埋め込みモデルとベクトル検索を利用している環境では、azure_ai拡張、認証方式、ベクトル次元、DiskANNのバージョン、モデルの廃止予定を確認する必要があります。
Azure SQLの新機能・変更点：「Generate Vector Embeddings with Azure OpenAI – Azure Database for PostgreSQL」で確認すべきポイント
今回の情報を実務向けに整理すると、次のようになります。
| 確認項目 | 結論 | 管理者への影響 |
|---|---|---|
| 対象サービス | Azure Database for PostgreSQL Flexible Server | Azure SQL DatabaseやManaged Instanceには直接適用しない |
| 直近の公開差分 | タイトルに「flexible server」を追加 | 対象範囲の明確化が中心 |
| 関数やSQL仕様 | 変更は確認できない | 既存コードの緊急修正は不要 |
| 必須の設定変更 | 今回の更新に伴う変更はない | 現在の設定を棚卸しすればよい |
| 移行期限 | 今回の更新には設定されていない | モデルや拡張機能のライフサイクルは別途確認 |
| 主な用途 | PostgreSQL内から埋め込みを生成し、RAGの検索処理に利用 | azure_ai、vector、必要に応じてpg_diskannを使用 |
公式リポジトリでは、2026年6月17日のコミットで該当ページのH1が「Azure Database for PostgreSQL」から「Azure Database for PostgreSQL flexible server」へ変更されています。このファイルに対する差分は1行の追加・削除で、本文の関数定義や設定例は変更されていません。(GitHub)
したがって、2026年6月24日という日付を、機能の提供開始日や破壊的変更の適用日として扱うのは適切ではありません。少なくとも公開差分から判断できる更新ポイントは、Flexible Server向けの機能であることを明確にした点です。
実際の対象はAzure Database for PostgreSQL Flexible Server
公式ページのサービスメタデータはazure-database-postgresqlで、ページタイトルにもAzure Database for PostgreSQL Flexible Serverが明記されています。Azure SQL DatabaseやAzure SQL Managed Instance向けの手順ではありません。(GitHub)
両者は同じAzure上のデータベースサービスですが、利用する拡張機能やSQL構文が異なります。
| 項目 | Azure Database for PostgreSQL Flexible Server | Azure SQL Database／Managed Instance |
|---|---|---|
| SQLの種類 | PostgreSQL SQL | Transact-SQL |
| 埋め込み生成 | azure_openai.create_embeddings | AI_GENERATE_EMBEDDINGSなど |
| モデル設定 | azure_ai拡張の設定 | 外部モデル定義やデータベース資格情報 |
| ベクトル格納 | vector拡張 | VECTOR型 |
| コサイン距離の例 | <=>演算子 | VECTOR_DISTANCE関数 |
| インデックスの例 | DiskANN、HNSW、IVFFlat | Azure SQL向けベクトルインデックス |
Azure SQLには、外部モデルを登録して埋め込みを生成するAI_GENERATE_EMBEDDINGSや、ネイティブのベクトル型・ベクトル関数が用意されています。対象製品や利用条件は異なるため、Azure SQL環境でPostgreSQL用のCREATE EXTENSIONやazure_ai.set_settingを実行してはいけません。(Microsoft Learn)
「Generate Vector Embeddings with Azure OpenAI」でできること
この機能では、Azure Database for PostgreSQL Flexible ServerからAzure OpenAIの埋め込みモデルを呼び出し、入力テキストを数値ベクトルへ変換できます。
基本的な処理の流れは次のとおりです。
- 文書や商品説明、FAQなどのテキストを適切な長さに分割する
azure_openai.create_embeddingsで埋め込みを生成する- 生成したベクトルを
vector型の列へ保存する - DiskANNなどのベクトルインデックスを作成する
- 質問文のベクトルと保存済みベクトルの距離を計算する
- 類似度が高い文書を取得し、生成AIへコンテキストとして渡す
公式例では、1,536次元のベクトル列に埋め込みを保存し、vector_cosine_opsを指定したDiskANNインデックスを作成しています。検索時には<=>演算子を使用してコサイン距離の小さいデータを取得します。(GitHub)
ただし、このページだけでRAGアプリケーション全体が完成するわけではありません。次の処理は、アプリケーション側または別のデータ処理基盤で設計する必要があります。
- 文書の分割方法
- 文書更新時の再埋め込み
- ユーザーやテナントごとのアクセス制御
- メタデータによる絞り込み
- 検索結果を含めたプロンプトの構築
- プロンプトインジェクション対策
- 回答への出典表示
- 最終的な生成モデルの呼び出し
データベース内から関数を呼べる点は便利ですが、入力テキストはAzure OpenAIのエンドポイントへ送信されます。「データベース内で実行するのでデータが外部へ出ない」という意味ではないため、データ分類やネットワーク経路も確認が必要です。
影響範囲を環境別に整理
| 利用環境 | 影響度 | 確認すべきこと |
|---|---|---|
Azure Database for PostgreSQL Flexible Serverでazure_aiを利用中 | 高 | 拡張機能、認証、モデル、ベクトル次元、エラー処理 |
| PostgreSQLでRAGを新規構築予定 | 高 | 拡張機能の許可、モデル配置、インデックス方式 |
| アプリケーション側で埋め込みを生成中 | 中 | データベース内生成へ変更するメリットがあるか |
| Azure SQL Databaseを利用中 | 低 | PostgreSQL用手順ではなくAzure SQL用機能を確認 |
| Azure SQL Managed Instanceを利用中 | 低 | 更新ポリシーやAI_GENERATE_EMBEDDINGSの条件を確認 |
| セルフホストのPostgreSQL | 対象外 | Azure固有のazure_ai拡張はそのまま適用できない |
外部バッチやアプリケーションで既に埋め込みを生成している場合、今回の更新を理由にデータベース内生成へ切り替える必要はありません。
データベース内生成が適するのは、SQLだけで処理をまとめたい場合や、データ更新と埋め込み生成を近い場所で管理したい場合です。一方、大量データの非同期処理、複雑な再試行制御、複数のベクトルストアへの配信が必要な場合は、外部ワーカーの方が管理しやすいことがあります。
今回の更新に伴う必須の設定変更はない
今回確認された差分によって、新しいサーバーパラメーターや認証設定を追加する必要はありません。
ただし、既に利用中の環境やこれから導入する環境では、次の設定を順番に確認してください。
管理者が確認すべき設定
azure_ai、vector、pg_diskannの有効化状況
azure_aiは、Azure OpenAIなどのAIサービスをPostgreSQLから呼び出すための拡張機能です。vectorはベクトルの格納と類似度計算に使用します。
公式例のDiskANNインデックスを使用する場合は、さらにpg_diskann拡張が必要です。
まず、サーバーの許可リストを確認します。
SHOW azure.extensions;続いて、現在接続しているデータベースにインストール済みの拡張機能を確認します。
SELECT extname, extversion
FROM pg_extension
WHERE extname IN ('azure_ai', 'vector', 'pg_diskann')
ORDER BY extname;未導入の場合は、サーバー側の許可リストへ追加したうえで、必要なデータベースごとに作成します。
CREATE EXTENSION IF NOT EXISTS azure_ai;
CREATE EXTENSION IF NOT EXISTS vector;
-- DiskANNを使用する場合のみ
CREATE EXTENSION IF NOT EXISTS pg_diskann;pgvectorはプロジェクト名として使われますが、PostgreSQLで指定する拡張機能名はvectorです。また、CREATE EXTENSIONはサーバー全体ではなくデータベース単位で実行するため、複数データベースで利用する場合はそれぞれに導入します。(Microsoft Learn)
利用可能なバージョンとインストール済みバージョンは、次のSQLで比較できます。
SELECT name, default_version, installed_version
FROM pg_available_extensions
WHERE name IN ('azure_ai', 'vector', 'pg_diskann')
ORDER BY name;azure_aiのバージョンは、拡張機能のインストール後に確認できます。
SELECT azure_ai.version();更新が必要な場合は、事前に検証環境で関数仕様と既存処理への影響を確認してから実施します。
ALTER EXTENSION azure_ai UPDATE;公式ドキュメントでも、azure_aiの利用可能な更新を確認したうえでALTER EXTENSIONを実行する手順が案内されています。(Microsoft Learn)
Azure OpenAIの認証方式
azure_aiでは、サブスクリプションキーとマネージドIDの認証方式を選択できます。
APIキーを使用する場合の設定例は次のとおりです。
SELECT azure_ai.set_setting(
'azure_openai.auth_type',
'subscription-key'
);
SELECT azure_ai.set_setting(
'azure_openai.endpoint',
'https://<resource-name>.openai.azure.com'
);
SELECT azure_ai.set_setting(
'azure_openai.subscription_key',
'<api-key>'
);本番環境では、可能であればシステム割り当てマネージドIDの利用を検討します。
SELECT azure_ai.set_setting(
'azure_openai.auth_type',
'managed-identity'
);
SELECT azure_ai.set_setting(
'azure_openai.endpoint',
'https://<resource-name>.openai.azure.com'
);マネージドIDを利用する場合は、PostgreSQL Flexible Serverのシステム割り当てIDを有効化し、Azure OpenAIリソース側で「Cognitive Services OpenAI User」ロールを割り当てます。これにより、データベース内にAPIキーを保存せずに認証できます。(Microsoft Learn)
設定後は、認証方式とエンドポイントを確認します。
SELECT azure_ai.get_setting('azure_openai.auth_type');
SELECT azure_ai.get_setting('azure_openai.endpoint');APIキーの値をget_settingで表示すると、SQLクライアントの履歴、監査ログ、画面共有などから漏えいする可能性があります。運用確認では、サブスクリプションキーそのものを不用意に取得しない方が安全です。
また、azure_aiの設定を読み書きできるazure_ai_settings_managerロールのメンバーを確認してください。Flexible Serverでは管理ロールのazure_pg_adminからもこの権限が付与されるため、管理者アカウントを必要以上に共有しないことが重要です。(Microsoft Learn)
モデル名ではなくデプロイ名を指定する
azure_openai.create_embeddingsの第1引数には、モデルIDではなくAzure OpenAI上のデプロイ名を指定します。
たとえば、text-embedding-3-smallをデプロイしていても、デプロイ名をcompany-search-embeddingにしている場合は次のように呼び出します。
SELECT azure_openai.create_embeddings(
'company-search-embedding',
'障害発生時の連絡先を確認したい'
);モデルIDをそのままデプロイ名にしている環境では見分けにくいため、構成管理では次の情報を分けて記録すると安全です。
- Azure OpenAIリソース名
- リージョン
- モデルID
- モデルバージョン
- デプロイ名
- 出力次元数
- 認証方式
- 利用するデータベースとテーブル
- インデックス方式
公式手順でも、モデルの作成後にデプロイ名を控え、create_embeddingsへ渡すよう案内されています。(GitHub)
埋め込みの次元数とvector列を一致させる
埋め込みモデルによって、既定の出力次元数が異なります。
| モデル | 既定の出力次元数 |
|---|---|
text-embedding-ada-002 | 1,536 |
text-embedding-3-small | 1,536 |
text-embedding-3-large | 3,072 |
vector(1536)の列へ3,072次元の埋め込みを格納しようとすると、次元数の不一致でエラーになります。
実際のデプロイから返される次元数は、少量のテストデータで確認できます。
SELECT array_length(
azure_openai.create_embeddings(
'<deployment-name>',
'embedding dimension health check'
),
1
) AS embedding_dimensions;第3世代の埋め込みモデルはdimensionsパラメーターによる次元削減に対応しています。azure_ai側での利用は、公式ページ上では拡張機能バージョン1.1.0以降とされています。(GitHub)
一方、公式ページでは関数シグネチャの表示部分にdimensionsが含まれていないものの、引数の説明には記載があります。環境によって利用可能な関数定義が異なる可能性があるため、実装前にインストール済みの定義を確認してください。
SELECT pg_get_function_arguments(p.oid)
FROM pg_proc AS p
JOIN pg_namespace AS n
ON n.oid = p.pronamespace
WHERE n.nspname = 'azure_openai'
AND p.proname = 'create_embeddings';ドキュメント上の最新構文だけを前提にせず、実環境の拡張機能バージョンと関数定義を確認することが、移行失敗を防ぐポイントです。
インデックス方式と次元数の上限を確認する
HNSWとIVFFlatでは、インデックスを作成できるベクトルが最大2,000次元に制限されています。そのため、既定で3,072次元を返すtext-embedding-3-largeは、そのままではHNSWやIVFFlatのインデックスを作成できません。(Microsoft Learn)
主な選択肢は次の3つです。
dimensionsを指定して2,000以下へ削減する- 1,536次元の
text-embedding-3-smallを使用する - 高次元に対応したDiskANNを使用する
pg_diskannバージョン0.6以降では、Product Quantizationを有効にすることで最大16,000次元のインデックスを扱えます。3,072次元のtext-embedding-3-largeを利用する場合は、有力な選択肢になります。(Microsoft Learn)
CREATE INDEX document_embedding_diskann_idx
ON document_embeddings
USING diskann (embedding vector_cosine_ops)
WITH (
product_quantized = true
);モデルを選ぶ際は、精度だけでなく次の要素を合わせて判断してください。
- 1件あたりのベクトル保存容量
- インデックス容量
- インデックス作成時間
- 検索レイテンシ
- 必要な再現率
- Azure OpenAIの利用コスト
- 再埋め込みに必要な時間
- 対象リージョンでのモデル提供状況
インデックスと検索演算子を一致させる
コサイン距離を使用する場合、インデックスにはvector_cosine_ops、検索には<=>を使用します。
CREATE INDEX document_embedding_diskann_idx
ON document_embeddings
USING diskann (embedding vector_cosine_ops);SELECT document_id, content
FROM document_embeddings
ORDER BY embedding <=> azure_openai.create_embeddings(
'<deployment-name>',
'パスワードをリセットする方法'
)::vector
LIMIT 10;距離方式の対応は次のとおりです。
| 距離方式 | インデックス演算子クラス | 検索演算子 |
|---|---|---|
| ユークリッド距離 | vector_l2_ops | <-> |
| コサイン距離 | vector_cosine_ops | <=> |
| 内積 | vector_ip_ops | <#> |
インデックスをコサイン距離で作成し、検索を別の距離方式で実行すると、期待した検索結果にならないだけでなく、インデックスが利用されないことがあります。(Microsoft Learn)
実行計画は次のように確認します。
EXPLAIN (ANALYZE, BUFFERS)
SELECT document_id
FROM document_embeddings
ORDER BY embedding <=> '<query-vector>'::vector
LIMIT 10;小規模なテーブルでは、インデックスよりシーケンシャルスキャンの方が低コストと判断されることがあります。enable_seqscanをサーバー全体で無効化するのではなく、インデックスの動作確認が必要な場合に限定して、トランザクション内で一時的に変更してください。
タイムアウト、再試行、トランザクションを見直す
azure_openai.create_embeddingsには、単一テキスト用と配列用の関数があります。公式ページに記載された主な既定値は次のとおりです。
| 引数 | 既定値 | 注意点 |
|---|---|---|
batch_size | 100 | 配列入力時の処理単位 |
timeout_ms | 3,600,000ミリ秒 | 1時間のため、業務要件に対して長すぎないか確認 |
throw_on_error | true | APIエラーで外側のトランザクションもロールバック |
max_attempts | 1 | 既定では実質的に再試行しない |
retry_delay_ms | 1,000ミリ秒 | 再試行間隔 |
throw_on_error=trueでは、Azure OpenAIの一時的なエラーでも、関数を含むトランザクション全体がロールバックされます。大量の文書を1つのトランザクションで処理すると、最後の1件の失敗によって、それ以前に生成した埋め込みまで取り消される可能性があります。(GitHub)
本番の一括生成では、次の設計が安全です。
- 数十件から数百件程度の単位に分割する
- 処理済みフラグやモデルバージョンを保存する
- 同じデータを再処理しても問題ない冪等性を持たせる
- HTTP 429や一時障害を想定した再試行を実装する
- 永続的なエラーと一時的なエラーを分離する
- 失敗行だけを再実行できるようにする
- 長時間トランザクションを避ける
- Azure OpenAIのクォータと呼び出し料金を監視する
導入・更新時に実施する手順
現在の構成を棚卸しする
最初に、次の情報を一覧化します。
- 利用しているAzureサービス
- PostgreSQLサーバーとデータベース
azure_ai、vector、pg_diskannのバージョン- Azure OpenAIのモデルとデプロイ
- 埋め込み列の次元数
- ベクトルインデックスの種類
- 距離方式
- 認証方式
- バックフィル方法
- モデル廃止時の担当者
Azure SQL DatabaseとPostgreSQL Flexible Serverが混在している組織では、構成台帳に「データベースエンジン」と「適用する公式手順」を明記すると、誤ったSQLの実行を防げます。
小さな疎通確認を行う
いきなり全データを処理せず、1件の埋め込み生成から確認します。
SELECT array_length(
azure_openai.create_embeddings(
'<deployment-name>',
'connection test'
),
1
) AS dimensions;ここで確認する項目は次のとおりです。
- 名前解決とネットワーク接続
- マネージドIDまたはAPIキーの認証
- Azure OpenAIのRBAC
- デプロイ名
- 出力次元数
- 関数の実行権限
- 応答時間
少量データで検索品質を評価する
10件程度のデータでSQLが動いたとしても、本番の検索品質を保証できません。
最低でも、実際の利用者が入力しそうな質問を50件から100件程度用意し、次の指標を確認します。
- 正解文書が上位何件に入るか
- テナントや権限の異なる文書が混入しないか
- キーワード検索だけの場合より改善しているか
- 日本語の略称や表記揺れを扱えるか
- 古い文書と新しい文書を区別できるか
- 類似文書が多い場合に正しい版を選べるか
ベクトル検索の速度だけでなく、正解文書が取得できる割合を確認することが重要です。
本番データを分割してバックフィルする
埋め込み生成は外部API呼び出しを伴うため、通常の列更新より失敗要因が多くなります。
本番では、次のような管理列を用意すると再実行しやすくなります。
ALTER TABLE documents
ADD COLUMN embedding vector(1536),
ADD COLUMN embedding_model text,
ADD COLUMN embedding_updated_at timestamptz,
ADD COLUMN embedding_status text,
ADD COLUMN embedding_error text;embedding_statusをpending、processing、completed、failedなどに分けておけば、失敗データだけを再処理できます。
データ投入後にインデックスを作成する
大量データを投入する場合、先に全件を登録してからインデックスを作成した方が、1件ずつインデックスを更新するより効率的なことがあります。
インデックス作成時には、CPU、メモリ、ストレージI/O、作成時間を監視してください。必要に応じて一時的なスケールアップも検討します。公式ドキュメントでも、初期データのロード後にインデックスを作成する方法が推奨されています。(Microsoft Learn)
移行期限とモデルのライフサイクル
今回のドキュメント更新そのものには、設定変更の期限や移行期限はありません。
一方、Azure OpenAIの埋め込みモデルには別のライフサイクルがあります。2026年7月時点の公式スケジュールでは、次のモデルの廃止日は2027年4月15日とされています。
text-embedding-3-largetext-embedding-3-smalltext-embedding-ada-002バージョン1text-embedding-ada-002バージョン2
これは今回のページ更新によって新設された期限ではありません。また、モデルの廃止予定は変更される可能性があるため、実際の移行計画では最新の公式スケジュールを再確認してください。(Microsoft Learn)
埋め込みモデルは単純に差し替えられない
埋め込みモデルを変更すると、同じテキストでも異なるベクトル空間へ変換されます。そのため、旧モデルで生成した文書ベクトルと、新モデルで生成した質問ベクトルを比較してはいけません。
Microsoftの公式情報でも、埋め込みモデル間をそのままアップグレードすることはできず、text-embedding-ada-002からtext-embedding-3-largeへ移る場合は埋め込みを再生成する必要があると説明されています。(Microsoft Learn)
安全な移行手順は次のとおりです。
- 新モデル用の列または別テーブルを作成する
- 本番データを分割して再埋め込みする
- 新しい次元数に対応したインデックスを作成する
- 同じ評価用質問で旧モデルと新モデルを比較する
- アプリケーションの検索先を新しい列へ切り替える
- 一定期間、旧ベクトルをロールバック用に保持する
- 問題がないことを確認して旧列と旧インデックスを削除する
たとえば、既存列を直接上書きするのではなく、次のように新しい列を追加します。
ALTER TABLE documents
ADD COLUMN embedding_v2 vector(1536);モデル名や次元数も保存しておくと、異なるモデルのベクトルが混在する事故を防げます。
ALTER TABLE documents
ADD COLUMN embedding_v2_model text;DiskANNのバージョン更新も確認する
既存のDiskANNインデックスを利用している場合は、モデルとは別にpg_diskannのバージョンも確認してください。
公式ドキュメントでは、pg_diskann 0.6系でインデックスメタデータ形式に破壊的変更があり、0.5系で作成したインデックスは0.6系での挿入処理と前方互換性がないとされています。該当する環境では、拡張機能の更新に合わせてREINDEXまたはインデックスの再作成が必要です。(Microsoft Learn)
REINDEX INDEX document_embedding_diskann_idx;または、サービスへの影響を抑えられる環境では次の方法を検討します。
REINDEX INDEX CONCURRENTLY document_embedding_diskann_idx;これは2026年6月24日のページ更新に伴う移行期限ではありませんが、既存環境の運用確認として優先度の高いポイントです。
グローバル展開で確認すべきポイント
リージョンごとのモデル提供状況
Azure OpenAIのモデル提供状況は、リージョンやデプロイ方式によって異なります。同じInfrastructure as Codeを複数リージョンへ適用しても、すべてのリージョンで同じ埋め込みモデルを配置できるとは限りません。(Microsoft Learn)
展開前に、リージョンごとに次の項目を確認します。
- 利用予定モデルの提供可否
- 標準デプロイまたはプロビジョンドデプロイの可否
- 必要なクォータ
- PostgreSQLからAzure OpenAIまでの通信遅延
- 障害時に利用する代替リージョン
- データ所在地に関する社内規定
- 国や地域ごとの規制
- デプロイ名の命名規則
公共クラウドとソブリンクラウドを分けて管理する
Azure Governmentなどでは、モデルのライフサイクル情報が別ページで管理されています。現時点では主要な埋め込みモデルに同じ2027年4月15日の廃止日が掲載されていますが、将来も公共クラウドと同じ日程になるとは限りません。(Microsoft Learn)
グローバル企業では、全リージョン共通の期限を1つだけ台帳に記録するのではなく、次の単位で管理すると安全です。
- クラウド環境
- リージョン
- モデル
- モデルバージョン
- デプロイ方式
- 廃止予定日
- 移行先
- 再埋め込み対象件数
- 移行責任者
設定値を環境ごとに分離する
エンドポイント、デプロイ名、認証方式をSQLファイルへ直接埋め込むと、開発環境の設定を本番へ適用する事故が起こりやすくなります。
最低でも次の値は、環境ごとの構成として管理してください。
- PostgreSQLサーバー名
- データベース名
- Azure OpenAIエンドポイント
- デプロイ名
- 認証方式
- ベクトル次元数
- バッチサイズ
- タイムアウト
- インデックス方式
APIキーを利用する場合は、ソースコード、CI/CDログ、SQL履歴へ出力しない運用が必要です。
失敗しやすいポイントと確認方法
| 症状 | 主な原因 | 確認方法 |
|---|---|---|
azure_aiを作成できない | サーバーの許可リストにない | SHOW azure.extensions;を確認 |
| 特定のDBで関数が存在しない | そのデータベースに拡張機能を作成していない | pg_extensionを確認 |
diskannアクセスメソッドが存在しない | pg_diskannが未導入 | CREATE EXTENSION pg_diskannを確認 |
| デプロイが見つからない | モデルIDとデプロイ名を混同 | Azure OpenAI上のデプロイ名を確認 |
| 401または403エラー | APIキー、認証方式、RBACの不備 | auth_typeとロール割り当てを確認 |
| ベクトル次元エラー | モデル出力とvector(n)が不一致 | array_lengthで実測 |
| HNSW／IVFFlatを作成できない | 2,000次元を超えている | モデルまたはdimensionsを見直す |
| インデックスが使われない | 距離方式の不一致、テーブルが小さい | EXPLAINで実行計画を確認 |
| 一括処理が全件ロールバック | throw_on_error=trueで大きなトランザクション | バッチを小さく分割 |
| 拡張機能更新後に挿入できない | 古いDiskANNインデックス形式 | REINDEXまたは再作成 |
| 検索結果が不安定 | 異なるモデルのベクトルが混在 | モデル名とバージョンを列に保存 |
| 海外リージョンだけ失敗する | モデル、クォータ、ネットワークの差異 | リージョン単位で疎通確認 |
管理者向けチェックリスト
- [ ] 対象環境がAzure Database for PostgreSQL Flexible Serverか確認した
- [ ] Azure SQL Database向けの更新と混同していない
- [ ]
azure_ai、vector、pg_diskannの有無とバージョンを確認した - [ ] 必要なすべてのデータベースに拡張機能を導入した
- [ ] Azure OpenAIのデプロイ名を確認した
- [ ] APIキーまたはマネージドIDの認証をテストした
- [ ]
azure_ai_settings_managerのメンバーを確認した - [ ] 埋め込みの出力次元数を実測した
- [ ]
vector(n)の次元数とモデル出力が一致している - [ ] インデックス方式がベクトル次元数に対応している
- [ ] インデックスと検索で同じ距離方式を使用している
- [ ] バッチサイズ、タイムアウト、再試行方針を決めた
- [ ] 大量処理を1つのトランザクションにまとめていない
- [ ] モデル名、バージョン、次元数をデータと一緒に記録している
- [ ] モデル廃止時の再埋め込み手順を用意した
- [ ] DiskANN更新時の
REINDEX要否を確認した - [ ] リージョンごとのモデル提供状況とクォータを確認した
- [ ] データがAzure OpenAIへ送信されることをセキュリティ部門と確認した
まとめ
2026年6月24日付の情報として確認された「Generate Vector Embeddings with Azure OpenAI – Azure Database for PostgreSQL」は、Azure SQL Databaseの新機能ではありません。対象はAzure Database for PostgreSQL Flexible Serverで、確認できる直近の変更はタイトルへ「flexible server」を追加した対象範囲の明確化です。
今回の更新だけを理由とする必須設定変更や移行期限はありません。まず、自社環境が本当に対象かを確認してください。
対象環境で既にRAGやベクトル検索を運用している場合は、次の順序で確認すると効率的です。
- 拡張機能とバージョンを確認する
- 認証方式と権限を確認する
- モデルのデプロイ名と次元数を確認する
- インデックス方式と距離演算子を確認する
- バッチ処理とエラー時のロールバック範囲を確認する
- モデル廃止と再埋め込みの計画を作成する
- DiskANNを利用している場合は、バージョン更新時の再インデックス要否を確認する
Azure SQL DatabaseまたはAzure SQL Managed Instanceを利用している場合は、PostgreSQL用のazure_ai手順ではなく、Azure SQL向けのAI_GENERATE_EMBEDDINGS、外部モデル、ネイティブベクトル型のドキュメントを基準に構成を見直しましょう。
コメント