Azure AI Foundryで社内文書検索、RAG、Copilot系アプリを構築している場合、今回の「Serverless indexers in Azure AI Search」は、検索結果そのものよりも「データ取り込みの運用」を大きく変える更新です。結論から言うと、Azure AI Searchのネイティブインデクサーをサーバーレスで実行できるようになり、取り込み処理用のコンピューティングを事前に確保・管理する負担を減らせます。Microsoftの公式更新では、この機能はパブリックプレビューとして案内されています。(Microsoft Azure)
ただし、「サーバーレスだから何も考えなくてよい」という機能ではありません。プレビュー中は本番利用に向かない制約があり、1日あたりの実行時間クォータ、APIバージョン、ネットワーク接続、スキルセット課金、監視方法を事前に確認する必要があります。特に、Azure AI FoundryのエージェントやナレッジベースでAzure AI Searchを使っている管理者・開発者は、移行判断の前に現在のインデクサー実行時間と接続方式を棚卸しすることが重要です。
Azure AI FoundryのAI/Copilot更新で何が変わるのか
今回の変更は、Azure AI Foundryのチャット画面やモデルそのものが変わる更新ではありません。実際に影響を受けるのは、Azure AI FoundryやCopilot系アプリが参照するナレッジ基盤としてAzure AI Searchを使っている構成です。
Azure AI Searchのインデクサーは、Azure Blob Storageなどのデータソースからテキストを抽出し、フィールドマッピングを使って検索インデックスへ取り込む「プル型」の仕組みです。OCR、テキスト分割、埋め込み生成などのスキルセット実行にも関わります。(Microsoft Learn)
つまり、Serverless indexers in Azure AI Searchの主な価値は次の3点です。
| 変更点 | 期待できる効果 | 注意点 |
|---|---|---|
| インデクサー実行基盤をMicrosoft側が管理 | 取り込み用コンピューティングの事前見積もりや管理が軽くなる | 実行時間クォータは残る |
| ワークロード需要に応じて実行がスケール | 断続的な取り込みや検証環境で使いやすい | 無制限に高速化されるわけではない |
| サーバーレス課金モデルと組み合わせやすい | アイドル時間の無駄を抑えやすい | スキル、インデックス書き込み、外部サービス呼び出しは別途確認が必要 |
Azure AI Foundryでは、Foundry IQやエージェントのナレッジ層としてAzure AI Searchのagentic retrievalが使われる場面があります。Microsoft Learnでは、agentic retrievalがFoundry IQの基盤であり、カスタムのエージェント型ソリューションにも使えると説明されています。(Microsoft Learn)
そのため、今回の更新は「回答生成の精度を直接上げる新モデル」ではなく、「回答の根拠となる検索インデックスを、より運用しやすく取り込むための変更」と捉えると分かりやすいです。
Serverless indexers in Azure AI Searchとは
Serverless indexers in Azure AI Searchは、Azure AI Searchのインデクサー実行をサーバーレスで扱うプレビュー機能です。これまで専用のキャパシティやサービス階層の性質を考慮していた取り込み処理について、サーバーレス検索サービス上で、インフラ管理を意識せずに実行しやすくなります。
Microsoft Learnでは、ServerlessおよびStandard 3 High Density、つまりS3 HDのインデクサー実行モデルについて、サービスレベルの日次実行時間クォータが適用されると説明されています。Serverless indexer supportには2026-05-01-preview REST API以降が必要です。(Microsoft Learn)
既存定義はそのまま使えるが、移行作業が不要とは限らない
公式ドキュメントでは、既存のインデクサー定義、データソース、スキルセット、ナレッジソースはServerlessおよびS3 HDの両方で変更なしに動作するとされています。(Microsoft Learn)
ただし、これは「既存のDedicatedサービスをワンクリックでServerlessへ変更できる」という意味ではありません。Serverless Developer tierはプレビュー中で、他の価格階層との移行をサポートしていないと説明されています。(Microsoft Learn)
実務では、既存サービスをそのまま切り替えるのではなく、別サービスとして検証環境を作り、インデックス定義・データソース・インデクサー・スキルセットを再現して動作確認する進め方が安全です。
利用者への影響：検索画面は変わらないが、データ鮮度に影響する
エンドユーザーから見ると、今回の更新でAzure AI FoundryのチャットUIやCopilotの操作方法が大きく変わるわけではありません。影響が出るとすれば、検索インデックスへデータを取り込む速度、安定性、コスト設計です。
たとえば、社内規程、製品マニュアル、FAQ、議事録をAzure AI Searchへ取り込み、Azure AI Foundryのエージェントがそれを参照して回答している構成では、インデクサーの実行が遅れると「更新したはずの文書が回答に反映されない」状態になります。
特に注意したいのは、サーバーレス化してもリアルタイム同期になるわけではない点です。Azure AI Searchのインデクサーはオンデマンド実行またはスケジュール実行で動かせますが、より高頻度な同期が必要な場合は、アプリ側から検索インデックスへ直接投入するプッシュ型の設計が必要になります。(Microsoft Learn)
管理者が確認すべき設定と制約
Serverless indexersは便利ですが、プレビュー機能としての制約があります。管理者は、少なくとも次の項目を確認してから検証を始めるべきです。
| 確認項目 | 見るべきポイント | 判断基準 |
|---|---|---|
| APIバージョン | 2026-05-01-preview以降を使っているか | REST APIやSDKの対応状況を確認 |
| リージョン | プレビュー対象リージョンで作成できるか | 日本利用ならJapan East対応を確認 |
| SLA | プレビュー中にSLAがない点を許容できるか | 本番の重要基盤には慎重に適用 |
| ネットワーク | Private Linkや共有プライベートリンクに依存していないか | private接続必須なら採用を見送る |
| 実行時間クォータ | 1日6時間で収まるか | 全インデクサー合計で試算 |
| 課金 | スキルセットや外部サービス呼び出しの費用を見積もったか | Azure OpenAI、Foundry、AI Servicesの請求も確認 |
| 監視 | ポータルだけに頼っていないか | REST APIで残り時間を取得する設計にする |
Serverless Developer tierはパブリックプレビューで、プレビュー中はサービスレベル契約がなく、本番ワークロードには推奨されていません。また、記事執筆時点の公式情報では、プレビュー提供リージョンはWest Central US、Switzerland North、Japan Eastとされています。(Microsoft Learn)
1日6時間の実行時間クォータに注意する
Serverless indexersで最も見落としやすいのが、日次の累積実行時間クォータです。Serverlessでは、24時間UTCウィンドウごとに6時間のクォータが設定されています。これはインデクサー単位ではなく、検索サービス全体に対して適用されます。(Microsoft Learn)
たとえば、1つのサービス内に5つのインデクサーがあり、それぞれ1回30分かかる場合、全てを1日2回実行すると合計5時間になります。さらに再実行や失敗時のリトライが加わると、6時間に近づきます。
| 例 | 計算 | 1日6時間に対する余裕 |
|---|---|---|
| 3本のインデクサーを1日1回、各20分実行 | 60分 | 余裕あり |
| 5本のインデクサーを1日2回、各30分実行 | 300分 | 残り60分 |
| 10本のインデクサーを1日2回、各20分実行 | 400分 | 超過 |
| 重いスキルセット付きで1回2時間の処理を4回実行 | 480分 | 超過 |
クォータを使い切ると、実行中のインデクサーは約5分以内に停止し、新しい実行はドキュメントを処理せず、一時的な失敗として返されます。通常の実行はUTC 00:00のリセット後に再開されます。(Microsoft Learn)
実務では、現在の平均実行時間に20〜30%程度の余裕を足して見積もるのが安全です。新規文書が少ない日は短く終わっても、月末の一括更新、権限変更、再クロール、スキルセットの再処理が重なると急にクォータを圧迫します。
監視はREST API前提で設計する
プレビュー中は、累積実行時間を確認するポータル画面が用意されていません。Microsoft Learnでは、Search Service REST APIを使ってサービス全体と個別インデクサーの実行時間を追跡する方法が示されています。(Microsoft Learn)
サービス全体の残り時間を確認する例は次の通りです。
GET {endpoint}/servicestats?api-version=2026-05-01-preview個別インデクサーの状態を確認する例は次の通りです。
GET {endpoint}/indexers('{indexerName}')/search.status?api-version=2026-05-01-previewレスポンスのindexersRuntimeまたはruntimeに含まれるusedSecondsとremainingSecondsを監視し、残り時間が少なくなったらスケジュール実行を止める、バッチを分割する、翌UTC日に回す、といった運用ルールを作っておきます。
アラートの目安は、最初は次のように設定すると運用しやすくなります。
| しきい値 | 対応 |
|---|---|
| 残り時間が50%未満 | 実行時間の長いインデクサーを確認 |
| 残り時間が20%未満 | 任意実行や再処理を停止 |
| 残り時間が10%未満 | 当日の追加取り込みを原則禁止 |
| 残り時間が0 | UTC 00:00リセット後に再実行 |
ネットワーク要件：Private Link依存の環境は要注意
Serverless indexersは、プライベート接続が必要なデータ取り込み環境では慎重に扱う必要があります。公式ドキュメントでは、ServerlessおよびS3 HDのインデクサーはパブリック実行環境でのみ実行され、Shared Private Link resourcesで提供されるプライベート実行環境は利用できないと説明されています。さらに、Serverlessではプライベート接続がサポートされていません。(Microsoft Learn)
これは、次のような構成に影響します。
- ストレージアカウントをパブリックネットワークから閉じている
- 取り込み元がPrivate Endpoint経由でしか到達できない
- 監査要件上、インデクサーのアウトバウンド通信をインターネットに出せない
- Shared Private Link resourcesを前提に既存のインデクサーを設計している
この条件に該当する場合、Serverless indexersの採用は見送るか、専用サービスや別の取り込み方式を検討するのが現実的です。S3 HDではNetwork Security Perimeterを使ってトラフィックを制御する選択肢が示されていますが、Serverlessでは同じ発想で解決できるとは限りません。(Microsoft Learn)
コスト面で誤解しやすいポイント
Serverless indexersはコスト削減につながる可能性がありますが、「取り込みが完全無料になる」という意味ではありません。Microsoft Learnでは、Serverlessのインデクサー実行はプレビュー中、スキルを除いて現在無料と説明されています。一方で、インデックスへのドキュメント書き込みにはコストが発生し、スキルセット実行は専用インデクサーと同じ考え方で課金されます。外部サービスを呼ぶスキルは、接続されたFoundryまたはAzure AI servicesリソース経由で課金されます。(Microsoft Learn)
特に費用が膨らみやすいのは、次の処理です。
| 処理 | コスト上の注意点 |
|---|---|
| Azure OpenAI Embedding skill | 文書量、チャンク数、再処理回数に比例して増えやすい |
| GenAI Prompt skill | 取り込み時に生成AIを呼ぶため、再実行時の費用に注意 |
| Azure Content Understanding skill | ドキュメント解析が重い場合、実行時間と外部課金の両方に影響 |
| 大量の再インデックス | 差分ではなく全件再処理になると、書き込みとスキル費用が増える |
| 失敗時の安易なリトライ | 同じ処理を繰り返してクォータと費用を消費する |
Serverless Developer tierについては、プレビュー初期は請求が有効化されていないものの、使用量の推定コストはAzure portalやテレメトリで確認でき、課金開始前に少なくとも30日前の通知が行われると説明されています。将来的な課金開始を前提に、検証段階からコスト可視化を組み込んでおくべきです。(Microsoft Learn)
開発者が見るべき実装上の注意点
開発者は、インデクサー定義がそのまま動くかだけでなく、実行失敗時の扱い、APIバージョン、スキルセットの再処理を確認する必要があります。
2026-05-01-preview以降のAPIを使う
Serverless indexer supportには2026-05-01-preview REST API以降が必要です。CI/CDやIaCでAzure AI Searchリソースを管理している場合、テンプレート、SDK、REST API呼び出し、運用スクリプトのAPIバージョンが古いままになっていないか確認します。(Microsoft Learn)
特に、既存のデプロイパイプラインでAPIバージョンを固定している環境では、プレビュー機能を使うサービスだけ分岐させる必要があります。全環境を一括でプレビューAPIに寄せると、予期しない差分が出る可能性があります。
クォータ超過を通常の一時障害として扱う
日次クォータを超えたとき、新しいインデクサー実行はドキュメントを処理せず、一時的な失敗を返します。ここで単純な即時リトライを組むと、失敗を繰り返すだけでなく、運用ログも汚れます。(Microsoft Learn)
アプリケーションや運用ジョブ側では、次のような制御が必要です。
remainingSecondsが十分にある場合だけ実行する- クォータ超過時はUTC 00:00以降に再実行する
- 大量再処理は手動承認にする
- 重要度の低いインデクサーは翌日に回す
- 失敗通知には「クォータ超過」と「接続失敗」を分けて表示する
スキルセットの重さを先に測る
スキルセットを多用するインデクサーでは、サーバーレス化しても処理が軽くなるわけではありません。公式ドキュメントでも、Azure OpenAI Embedding skill、GenAI Prompt skill、Azure Content Understanding skillなど外部サービスを呼ぶスキルはランタイムを早く消費するため、スキル数の削減、ドキュメントのバッチ化、エンリッチメントキャッシュの利用が推奨されています。(Microsoft Learn)
開発環境では、まず代表的な文書セットで次の数値を測ります。
| 測定項目 | 使い道 |
|---|---|
| 100ファイルあたりの実行時間 | 日次クォータの見積もり |
| 1ファイルあたりのチャンク数 | 埋め込み生成コストの見積もり |
| スキルごとの失敗率 | 再処理設計の判断 |
| 差分取り込み時の処理件数 | 通常運用時の負荷把握 |
| 全件再処理時の時間 | 障害復旧やスキーマ変更時の計画 |
移行・展開前の実務チェックリスト
Serverless indexersを検証する場合は、いきなり本番データを流すのではなく、次の順序で進めると失敗しにくくなります。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 現状把握 | 既存のインデクサー、データソース、スキルセット、実行時間を一覧化 | 1日あたりの合計実行時間が分かる |
| 制約確認 | リージョン、SLA、Private Link、未対応機能を確認 | Serverlessで動かせない要件が明確 |
| 検証環境作成 | Serverless対応リージョンに検証用サービスを作成 | 同等のインデックス構成を再現 |
| API更新 | 2026-05-01-preview以降で管理・監視を実装 | CI/CDまたは運用スクリプトが通る |
| 小規模実行 | 代表データでインデクサーを実行 | 成功、実行時間、費用傾向を確認 |
| 監視追加 | usedSecondsとremainingSecondsを取得 | クォータ超過前に検知できる |
| 段階展開 | 重要度の低いデータソースから適用 | 既存運用へ戻せる手順がある |
特に本番展開では、「戻し方」を先に決めておくことが大切です。プレビュー機能は仕様や制限が変わる可能性があります。Dedicatedの既存サービスを残したまま、Serverless側で同じデータを取り込み、検索品質と運用ログを比較する形が安全です。
採用すべきケース、見送るべきケース
Serverless indexersは、すべてのAzure AI Search構成に向くわけではありません。判断基準を明確にしておくと、プレビュー検証の優先度を決めやすくなります。
| 判断 | 向いているケース | 理由 |
|---|---|---|
| 採用を検討 | PoC、検証環境、社内ナレッジの小〜中規模RAG | 断続的な取り込みでサーバーレスの利点が出やすい |
| 採用を検討 | 取り込み頻度が日次・数時間おきで十分 | 6時間クォータ内に収めやすい |
| 採用を検討 | パブリック実行環境でも接続要件を満たせる | Serverlessのネットワーク制約に合う |
| 慎重に判断 | 重いスキルセットを多数使う | クォータと外部サービス課金を消費しやすい |
| 見送り推奨 | Private Link必須のデータソース | Serverlessでプライベート接続がサポートされない |
| 見送り推奨 | SLAが必要な本番検索基盤 | プレビュー中はSLAがない |
| 見送り推奨 | ほぼリアルタイム同期が必要 | インデクサーではなくプッシュ型が適する |
| 見送り推奨 | index aliasesやdebug sessionsに依存 | Serverless Developer tierの未対応機能に該当 |
Azure AI SearchのServerless pricing modelは、変動が大きいワークロードやマルチテナントアプリケーション向けの選択肢として説明されています。一方、安定した高負荷や予測しやすい本番ワークロードでは、Dedicated pricing modelの方が運用しやすい場合があります。(Microsoft Learn)
よくある誤解と正しい理解
サーバーレスならクォータを気にしなくてよい？
気にする必要があります。Serverless indexersにはサービス全体で1日6時間の累積実行時間クォータがあります。複数のインデクサーを同時に動かす場合、全ての実行時間が同じ予算から消費されます。(Microsoft Learn)
Azure AI Foundryの回答精度が自動的に上がる？
直接は上がりません。今回の更新は主にデータ取り込みの実行モデルに関するものです。回答精度を上げるには、文書の分割方法、メタデータ設計、ベクトル化、セマンティック設定、評価データの整備が引き続き重要です。
既存インデクサーは何も確認せずに移せる？
定義自体は変更なしで動く可能性がありますが、APIバージョン、ネットワーク、未対応機能、実行時間クォータ、スキルセット課金は確認が必要です。Serverless Developer tierは他の価格階層との移行をサポートしないため、既存サービスの単純なティア変更として考えない方が安全です。(Microsoft Learn)
プレビュー中は無料だからコスト確認は不要？
不要ではありません。インデクサー実行そのものはプレビュー中に無料と説明されていますが、スキルを除く範囲に限られます。ドキュメント書き込み、スキルセット、外部サービス呼び出し、将来の課金開始を含めて見積もる必要があります。(Microsoft Learn)
次に取るべき行動
Serverless indexers in Azure AI Searchは、Azure AI FoundryやCopilot系アプリのナレッジ取り込みを軽くする有望な更新です。特に、検証環境、社内RAG、小〜中規模のナレッジベース、負荷が断続的な取り込み処理では、管理負荷とアイドルコストを抑えられる可能性があります。
一方で、プレビュー中はSLAがなく、Private Link依存の構成には向かず、1日6時間の実行時間クォータもあります。まずは既存インデクサーの実行時間、スキルセット、接続方式、対象リージョンを棚卸しし、Serverlessに向くデータソースだけを検証環境で試すのが現実的です。
最初に行うべきことは、全インデクサーの平均実行時間を集計し、1日あたりの合計が6時間に収まるか確認することです。そのうえで、2026-05-01-preview APIを使った監視、クォータ超過時の運用ルール、スキルセット費用の見積もりを整えれば、Azure AI Foundryのナレッジ基盤をより柔軟に運用する準備ができます。
コメント