【Azure AI Search】サーバーレスで検索サービスをさくっとデプロイして試してみた

専用モデル と サーバーレスモデル、何が違うのか

Azure AI Search には、2つの価格モデルがあります。

ポイントは、機能面の差ではなく、価格設定とスケーリングの挙動の違いだという点です。サーバーレスモデルでも、専用モデルと同じコア検索機能・APIが使えるため、基本的にはコードを書き換えずに検証を進められます。

専用モデルでは、レプリカ（クエリスループットと可用性）とパーティション（ストレージとインデックス作成容量）を自分で組み合わせて検索ユニット（SU）を決める必要がありますが、サーバーレスではこれらを一切構成しません。クエリ量やインデックス作成のアクティビティに応じて、サービス側が容量を動的に管理してくれます。

なお、公式ドキュメントでも念押しされていますが、専用モデルのSUベースの料金試算をサーバーレスのCUにそのまま当てはめることはできません。ワークロードが違えば見積もりの前提も変わるため、料金試算はサーバーレス側の専用ガイダンスを参照する必要があります。具体的には、「事前に机上で計算する」のではなく、実際に動かしてみて、かかったコストを後から測定するという方式です。代表的なサンプルデータでインデックスを作り、想定される検索・更新の操作を実行してみると、Azure AI Search側がリクエストごとに「このリクエストにどれだけ計算コストがかかったか」という値を返してくれます。この値を記録・積み上げていくことで、本番相当のトラフィックが来た場合のコストを推定する、という流れになっています。

サーバーレス（プレビュー）の現状と制限事項

触ってみる前に、現時点（2026年8月）でのサーバーレスの立ち位置を整理しておきます。

• 提供リージョンは限定的：現在、米国中西部・スイス北部・東日本の3リージョンのみで利用できます。日本国内で試す場合は東日本を選ぶ形になります。
• SLAなし・現時点での請求は保留：本番ワークロードは非推奨とされています。使用量の見積もりコストはポータルやテレメトリで確認できますが、この期間は無料で使用できます。課金開始の少なくとも30日前に通知される予定です。
• 専用モデルへの後からの切り替えができない：サーバーレスで作った検索サービスを、後から「専用モデルのBasic」や「専用モデルのStandard」といった別のプランに変更することはできません（逆方向も同様です）。切り替えたい場合は、新しく検索サービスを作り直す必要があります。

つまり、「本番投入前にコンセプトをさくっと検証したい」「検証用途で立てたり消したりを繰り返したい」といったシナリオに向いた位置づけと言えそうです。ただ、実際に検証してみると、使えない機能は限定的で、大半の機能はそのまま使えることがわかりました。次のセクションから、それぞれ詳しく見ていきます。

実践：サーバーレスで検索サービスをデプロイする

それでは実際にAzureポータルからサーバーレスの検索サービスを作成してみます。

• サブスクリプション／リソースグループ：任意のものを選択（新規作成でも可）
• サービス名：グローバルで一意な名前
• 場所（リージョン）：サーバーレスのプレビューに対応した「(Asia Pacific) Japan East」（東日本）を選択

サーバーレスで使えない機能

まず、サーバーレスで公式に非対応とされている機能を先に押さえておきます。「価格モデルとサービス レベルを選択する」ページに一覧が載っているので、それぞれ何のための機能か、簡単に補足します。

裏を返せば、この5つ以外の機能は基本的に使える、ということでもあります。次のセクションで、実際に確認できた「使える機能」を見ていきます。

サーバーレスでも使える機能

前のセクションで挙げた5つ以外は、実際に触ってみると通常の検索機能はほぼそのまま使えました。代表的なところでは、次の機能が専用モデルと同様に動作することを確認しています。

• 基本的な検索機能：インデックスの作成、全文検索、ベクター検索、ハイブリッド検索など、コアとなる検索機能はそのまま使えます。
• セマンティック ランカー：検索結果を意味的な関連性で再ランク付けする機能も、専用モデルと同様に有効化できます。
• エージェント検索（ナレッジ ベース経由）：ナレッジ ソース（ファイル ナレッジ ソース以外）・ナレッジ ベースを作成し、取得アクションやチャット プレイグラウンドから検索できます。

このうちエージェント検索について、実際にBlobナレッジ ソース＋ナレッジ ベースを作って試してみました。以下の手順で試しています。

Blobナレッジ ソース＋ナレッジ ベースでエージェント検索を試す

前のセクションで、ファイル ナレッジ ソースがサーバーレスで非対応であることを確認しましたが、Blobナレッジ ソースについては、サーバーレスでも作成・利用できることを確認しました。

1. Blob Storageにコンテナーを用意し、検索対象のドキュメントをアップロードしておきます。

2.サーバーレスの検索サービスで「エージェント取得 > ナレッジ ソース」から、「ナレッジソースの追加」をクリックし、「Azure Blob（インデックス付き）」を選択します。


3. 「Azure BLOB（インデックス付き）」の設定画面で、Blobコンテナー情報やその他の項目（テキストのベクトル化、イメージの言語化）は任意設定で「作成」ボタンをクリックします。


4. ナレッジソースが作成できると、一覧に表示されます。


5. 続けてナレッジベースを作成します。「エージェント取得 > ナレッジ ベース」から、「ナレッジ ベースを追加する」をクリックします。


6. ナレッジソース欄で「既存のものを追加」をクリックし、先ほど作成したナレッジソースを選択します。


7. 「ナレッジ ベースを作成する」で必要な項目を設定します。ここでは、推論作業を「低」としているため、チャット補完モデルも指定しています。


8. ナレッジベースが作成できると、チャットUIの検索テストができます。応答の合成モードとしているため、チャットでの質問が自然言語での回答として生成されます。
今回は、Blobコンテナーに「Azure利用ガイド」を投入しましたので、Azureに関する回答が得られることを確認できました。

エージェント検索の一連の流れが、サーバーレスでもそのまま動くことを確認できました。「検証用にサーバーレスでサービスを立てて、そのままエージェント検索まで試せる」というのは、コスト面でも手軽さの面でもメリットが大きいと感じました。

プライベートエンドポイントも使える

前のセクションの「使えない機能」に「共有プライベートリンク」がありましたが、これはインデクサーが外部リソースにつなぎに行く際の話です。一方、検索サービス自体に対して外部（クライアントやユーザー）からつないでくる方向を制限するプライベートエンドポイントは別物で、この一覧には載っていません。載っていないということは使えるはずですが、念のため検証してみました。

実際に検証したところ、サーバーレスの検索サービスに対しても、プライベートエンドポイントを構成できることを確認しました。

整理すると、「自分（検索サービス）を非公開にする」ことはできるが、「非公開設定になっている接続先に、検索サービスからつなぎに行く」ことはできないという、非対称な状態になっています。データソース側をプライベートエンドポイント限定にしている場合は要注意です。

本番運用は本当にダメなのか？限定用途での現実的な落としどころ

公式ドキュメントでは「SLAがなく、本番ワークロードには非推奨」とされていますが、これは裏を返せば「稀に発生するダウンタイムや性能のばらつきを許容できるワークロードであれば、選択肢から完全に外す必要はない」ということでもあります。（本機能に限らず、プレビュー機能全般に言えることです）

例えば、次のようなユースケースであれば、多少のリスクを受け入れつつ本番運用に乗せることも現実的な検討対象になりそうです（推奨するという意味ではなく、「条件付きであれば選択肢になり得る」という温度感です）。

• 社内向けツール：利用者が限定されており、一時的に検索できなくても業務が止まらないもの
• 部門限定・小規模利用：アクセス頻度が低く、バースト性のあるワークロード（サーバーレスの本来の得意分野でもあります）
• お試し・PoC段階のアプリ：そもそも本番相当のSLAを求めていない、検証中のプロダクト

逆に、次のようなケースでは専用モデルを選ぶべきです。

• 顧客向け・売上に直結するなど、可用性がビジネス上重要なワークロード
• アクセス頻度が高く、常時安定した応答速度が求められるワークロード
• SLAが契約上・社内規定上必須になっているワークロード

「本番＝一律ダメ」ではなく、「求められる可用性のレベルに応じて選ぶ」という、ごく普通のリスク判断の話に落ち着く印象です。もちろん、プレビュー段階である以上、正式リリース前提の判断は禁物ですが、社内の小規模プロジェクトであれば試してみる価値は十分にあると思います。

よくある質問（FAQ）

まとめ

今回は、Azure AI Search に追加された「サーバーレス（プレビュー）」の価格モデルについて、専用モデルとの違いの整理、実際のデプロイ手順、そしてエージェント検索やプライベートエンドポイントを含む機能面の検証結果までを紹介しました。

• 容量設計を考えずに検索サービスを立てられる：レプリカ・パーティションの構成なしで、使用量に応じて自動スケーリングします。
• 機能面はほぼ専用モデルと同等：Blobナレッジ ソースを使ったエージェント検索やプライベートエンドポイントも問題なく使えました。明確に使えないのはファイル ナレッジ ソースなど一部の機能に限られます。
• 「本番＝一律NG」ではない：SLAなしという前提を理解した上で、社内向け・部門限定・PoCなど、多少のダウンを許容できる用途であれば、本番運用の選択肢としても検討の余地があります。

専用モデルのキャパシティ設計に悩む前に、まずはサーバーレスでコンセプトを確かめてみる、という選択肢は検証フェーズにおいて有効そうです。今後の正式リリースやリージョン拡大の動向も追いかけていきたいと思います。