MicrosoftはAzure AI Searchの最新preview REST APIとして2026-05-01-previewを公開した。Purview sensitivity labelをknowledge baseのretrieve responseへ含める機能、Azure OpenAI skill・vectorizerのAPIM経由接続、Microsoft Foundryへのprivate connectivity、SharePoint ACL強化、list API paging、Content Understanding skill更新が含まれる。機能が広いため、一括切替ではなく用途別の検証が必要である。

何が変わったか

retrieve responseはreference単位のsensitivityLabelInfoと、回答全体のmetadata.responseSensitivityLabelInfoを返せる。APIMのazure-api.net endpointをEmbedding skill、GenAI Prompt skill、vectorizerで使える。Microsoft Foundry resourceへのnetwork security perimeterとshared private link、SharePointのASPX・list・ACL、cursor型paging、semantic chunkingや画像説明も追加された。

変更前後の差

2025-11-01-previewからwire-levelの破壊変更はないとされ、REST requestはAPI versionを差し替えて動かせる。一方、Python・JavaScript SDKのagentic retrievalではclientがKnowledgeBaseRetrievalClientへ、retrieveKnowledge(...)retrieve(...)へ改称される。機能追加とSDK source changeを分けて管理する必要がある。

誰に影響するか

Foundry IQやAzure AI Search knowledge baseをMCP・RESTから呼び出す開発者、SharePointを権限付きでindexする組織、Purview labelをRAG回答へ継承したいセキュリティ担当、Azure OpenAIへの通信をAPIMやprivate network経由にしたいplatform teamが対象である。

期限

preview版の採用期限はない。2026-04-01が最新stableであり、productionのSLAや互換性を優先する場合はstableを維持する。preview機能が必要なworkloadだけAPI versionを分け、GA時に再評価する。

必要な対応

必要な機能を明確にし、preview endpointを全serviceへ一括適用しない。Purview利用ではlabelをchunk rowへ正しくprojectし、RBAC認証と同一tenant要件を確認する。SharePoint ACLはunique permissionとsite groupを含むtest dataで検証する。SDK利用者はclient・method renameをcode searchし、compile testを行う。

実装・移行手順

  1. 現在のREST API versionとSDK versionを棚卸しする
  2. 2026-05-01-previewが必要な機能をworkload別に特定する
  3. test serviceでAPI versionだけを差し替え回帰試験する
  4. SDKのclient・method renameを適用する
  5. Purview labelをreferenceとresponseの両方で確認する
  6. chunk indexへlabelがprojectされることを検証する
  7. APIM、private link、SharePoint ACL、pagingを個別に試験する
  8. stable APIへ戻すfeature flagとdeployment設定を用意する
  9. preview制約、region、費用、SLAを承認記録へ残す

失敗しやすい点

preview全機能が自動的に有効になると思う、wire-level破壊変更なしをSDK変更なしと解釈する、response-level labelだけを見てreferenceの違いを無視する、chunkへlabelをprojectしない、API keyでPurview保護indexをqueryする、といった問題が起きやすい。

リスク

label欠落による機密情報表示、ACL同期遅延、cross-tenant制約、preview仕様変更、SDK build failure、private connectivity設定不備、Content Understanding処理の費用とtimeoutがある。response labelをUIへ表示するだけでなく、copy・share制御や監査へ結び付ける場合は誤判定時の影響を評価する。

評価方法

  • API回帰test成功率
  • SDK build・integration test結果
  • reference単位labelの欠落率
  • response labelと最優先labelの一致率
  • unauthorized documentの返却件数
  • SharePoint ACL同期時間
  • pagingで取得した総件数の一致
  • APIM・private link経由成功率
  • stable APIへのrollback時間

ロールバック

preview機能をfeature flagで分離し、問題があれば2026-04-01 stableへ戻す。preview固有fieldをoptionalに扱い、未取得でも既存response parserが壊れないようにする。SDK renameはadapterで吸収し、旧clientと新clientの呼び出しを切り替えられるようにする。

編集部分析

このversionは単なるAPI更新ではなく、RAGの回答に情報保護labelとnetwork boundaryを持ち込む変更である。機能価値は高いが、preview adoptionをサービス全体のversion upgradeとして扱うと影響範囲が広がる。機能単位の分離とstable fallbackが実務上の要点になる。

実務チェックリスト

  • [ ] 現行API・SDK versionを特定した
  • [ ] previewが必要なworkloadだけを分離した
  • [ ] SDK renameをcode searchした
  • [ ] Purview labelのchunk projectionを確認した
  • [ ] RBACとtenant条件を確認した
  • [ ] SharePoint ACLとpagingを試験した
  • [ ] stable APIへのrollbackを用意した
  • [ ] previewのSLA・費用・regionを記録した

一次情報