Azure SDK 2026年6月リリースを受けても、すべてのAzure SDKを一括更新する必要はありません。まず自社のアプリケーションが対象パッケージを利用しているか確認し、該当するものだけ互換性テストを行うのが適切です。
特に確認を急ぎたいのは、プレビュー版からGA版へ移行するAzure AI Transcriptionと、メソッド名および戻り値の型が変わったMicrosoft Planetary Computer Proです。一方、今回追加された初期ベータ版を利用していない環境では、直ちにコードを変更する必要はありません。
2026年7月6日時点で確認できるMicrosoft公式ブログは、ページ上では2026年7月5日付となっています。今回の発表は単一の「Azure SDK本体」を更新するものではなく、各言語・各サービス向けライブラリの新機能、改善、修正を月単位でまとめたリリース情報です。(Microsoft for Developers)
Azure SDKの「Microsoft publishes the June 2026 Azure SDK release」で何が変わるのか
今回の主な変更は、Python向けクライアントライブラリ2製品のGAと、JavaおよびPython向け管理・クライアントライブラリ5製品の初期ベータ公開です。
| 言語 | パッケージ | バージョン | 状態 | 主な確認ポイント |
|---|---|---|---|---|
| Python | azure-ai-transcription | 1.0.0 | 初回GA | プレビュー版から移行する場合は認証、音声処理結果、非同期処理を再テスト |
| Python | azure-planetarycomputer | 1.0.0 | 初回GA | list_collectionsの名称変更と戻り値モデルの変更 |
| Java | azure-resourcemanager-fileshares | 1.0.0-beta.1 | 初回ベータ | 管理APIの試験導入、依存関係の競合 |
| Python | azure-ai-agentserver-optimization | 1.0.0b1 | 初回ベータ | 最適化設定の取得順序とフォールバック |
| Python | azure-ai-discovery | 1.0.0b1 | 初回ベータ | Discoveryワークスペース、Bookshelfとの接続 |
| Python | azure-mgmt-discovery | 1.0.0b1 | 初回ベータ | Azureリソース管理、権限、環境変数 |
| Python | azure-mgmt-fileshares | 1.0.0b1 | 初回ベータ | File Sharesリソース管理、Python要件の確認 |
公式ブログでは、Azure AI TranscriptionとMicrosoft Planetary Computer ProがPython向けの初回安定版として掲載されています。そのほかの5パッケージは初回ベータ版です。(Microsoft for Developers)
ここで注意したいのは、ブログの公開日とパッケージ自体の公開日が一致するとは限らない点です。たとえば、Python向けazure-ai-transcription 1.0.0とazure-planetarycomputer 1.0.0は、PyPI上では2026年5月18日に公開されています。Azure SDKの月次記事は、その月の主要なリリースを後からまとめた情報として捉える必要があります。(PyPI)
対象者と対応要否を先に判断する
今回のリリースに対する優先度は、現在使用しているパッケージとバージョンによって変わります。
| 現在の利用状況 | 対応要否 | 推奨する対応 |
|---|---|---|
| 今回掲載された7パッケージを使っていない | 原則不要 | 定期的な依存関係確認のみ行う |
| Python版Azure AI Transcriptionのベータ版を使用中 | 要確認 | 1.0.0を検証環境に固定し、認証と処理結果を比較する |
| .NET、Java、JavaScript版Azure AI Transcriptionのプレビュー版を使用中 | 対応推奨 | 明示された破壊的変更に合わせてコードを修正する |
azure-planetarycomputerのベータ版を使用中 | 対応が必要 | メソッド名とレスポンスの参照方法を修正する |
| 今回の初期ベータ版を新規導入したい | 評価が必要 | 本番環境と分離し、バージョンを完全固定する |
| 上記以外のAzure SDKを使用中 | 個別確認 | 言語別リリースノートで利用パッケージの変更履歴を確認する |
Azure SDKの月次リリースは、ブログで紹介されたパッケージだけに限定されません。たとえば2026年6月の.NET向けページには、安定版、パッチ版、ベータ版を合わせて112パッケージが掲載されています。ブログのハイライトに名前がないからといって、利用中のSDKに更新がないとは限りません。(Azure)
Azure AI Transcription 1.0.0の変更点と導入条件
Python版は初回GAとして公開
Python向けazure-ai-transcription 1.0.0は、Azure AI Speechの文字起こし機能をPythonアプリケーションから利用するための初回安定版です。
主な導入条件は次のとおりです。
| 項目 | 条件 |
|---|---|
| Python | 3.9以上 |
| Azure環境 | Azureサブスクリプション |
| 必要なリソース | Azure AI Speechリソース |
| 認証方式 | Microsoft Entra IDまたはAPIキー |
| 本番環境の推奨 | DefaultAzureCredentialとRBAC |
| 主な用途 | 音声ファイル、音声URLの文字起こし、話者分離、言語検出、チャンネル分離など |
Python 3.9から3.13までがパッケージの対象として示されています。Microsoft Entra IDを使用する場合は、Speechリソースに対してCognitive Services UserまたはCognitive Services Speech Userなどの適切なロールが必要です。(PyPI)
検証環境では、次のようにバージョンを明示して導入します。
python -m pip install azure-ai-transcription==1.0.0
python -m pip install azure-identity本番環境への導入では、単にpip install --upgradeを実行するのではなく、requirements.txtやロックファイルにも1.0.0を記録してください。別の開発端末やCI/CD環境で意図しない更新が発生するのを防げます。
Python版の変更履歴だけでは互換性を断定できない
Python版1.0.0の変更履歴には、「初回安定版」であることだけが明記されており、1.0.0固有の破壊的変更は掲載されていません。(PyPI)
ただし、これだけを根拠に「すべてのベータ版と完全互換」と判断するのは危険です。MicrosoftのAzure SDKリリースポリシーでも、ベータ版から安定版への移行時は変更が少なく見えることがあり、それまでのベータ版の変更を累積して確認できるようにすることが推奨されています。(Azure)
以前のベータ版を使用している場合は、少なくとも次の項目を再テストしてください。
- クライアント生成時の引数と認証方法
TranscriptionContentやTranscriptionOptionsの生成処理phrasesとcombined_phrasesの参照方法- 話者分離、言語検出、チャンネル分離の結果
- 同期クライアントと非同期クライアントの両方
- 例外の型、HTTPステータス、リトライ処理
.NET、Java、JavaScript版では明示的な破壊的変更がある
公式ブログのハイライトはPython版ですが、言語別リリースノートを見ると、Azure AI Transcription 1.0.0には言語ごとの破壊的変更があります。
| 言語 | 主な破壊的変更 | 修正の方向性 |
|---|---|---|
| .NET | TranscriptionResult.PhrasesByChannelとTranscribedPhrasesを削除 | フラットな一覧はPhrases、チャンネル別結合結果はCombinedPhrasesを使用 |
| Java | transcribeWithResponseの引数追加 | RequestOptionsを第2引数に渡す。既定動作ならnullも使用可能 |
| Java | TranscriptionDiarizationOptionsの引数なしコンストラクターを削除 | new TranscriptionDiarizationOptions(true)のように有効状態を明示 |
| Java | オフセットの型をintからDurationへ変更 | ミリ秒を前提とした算術処理を修正 |
| JavaScript／TypeScript | optionsとoperationOptionsを1つのオブジェクトへ統合 | 既存の2オブジェクトを単一のTranscriptionOptionsにまとめる |
| JavaScript／TypeScript | TranscribeOptionsのルートエクスポートを廃止 | 必要な場合はAPIサブパスから参照する |
.NET版では、チャンネル別の文字起こし結果を参照していたコードがコンパイルエラーになる可能性があります。(Azure)
Java版では、メソッドのシグネチャ、話者分離オプションの生成方法、公開型、オフセットのデータ型が変更されています。特に、オフセットを整数のミリ秒として保存、加算、JSON変換している処理は見落としやすいポイントです。(Azure)
JavaScript／TypeScript版では、次のような呼び出しをしていた場合に修正が必要です。
// 旧形式のイメージ
await client.transcribe(source, transcriptionOptions, operationOptions);
// 1.0.0での考え方
await client.transcribe(source, {
...transcriptionOptions,
...operationOptions
});JavaScript／TypeScript版1.0.0は初回GAで、Azure AI Speech TranscriptionサービスのAPIバージョン2025-10-15を対象としています。(Azure)
Azure AI Transcriptionで実施したいテスト
文字起こしSDKのテストでは、単にAPIが成功するかだけでなく、業務処理が依存しているレスポンス構造まで確認します。
同じ音声データで新旧結果を比較する
短い音声だけでなく、次のようなテスト用音声を固定して比較してください。
- 1人が話す音声
- 2人以上が交互に話す音声
- 左右チャンネルに別の音声が入ったステレオファイル
- 固有名詞や専門用語を含む音声
- 無音区間や雑音が含まれる音声
- 長時間の音声
文字起こし結果はサービス側のモデル更新などでも変化し得るため、文章全体の完全一致だけを合格条件にするのは適切ではありません。話者数、フレーズ数、タイムスタンプの単調増加、必須語句の出現など、業務上重要な条件を分けて評価します。
URL入力とファイル入力を分けて確認する
Python版のURL文字起こしでは、サービスからアクセスできる公開URLが必要です。社内ネットワーク内のURLや、期限切れのSAS URLを指定すると、ローカル端末から閲覧できてもサービス側から取得できないことがあります。(PyPI)
DEBUGログを本番で常時有効にしない
Python版では詳細なDEBUGログを有効にすると、リクエストやレスポンスの本文、マスクされていないヘッダーが記録される場合があります。APIキー、トークン、音声データに関する情報をログ基盤へ送らないよう、検証後はlogging_enableの設定を見直してください。(PyPI)
Microsoft Planetary Computer Pro 1.0.0の互換性に注意
Python向けazure-planetarycomputer 1.0.0は、Microsoft Planetary Computer ProのGeoCatalogを操作する初回安定版です。
導入にはPython 3.10以上、Azureサブスクリプション、デプロイ済みのGeoCatalogリソースが必要です。認証にはMicrosoft Entra IDが必要とされ、azure-identityの導入と、サービスプリンシパルまたはマネージドIDへの適切なロール割り当てが前提になります。(PyPI)
list_collectionsがget_collectionsへ変更
最も分かりやすい破壊的変更は、STACコレクションを取得するメソッド名の変更です。
# ベータ版で使用されていた呼び出し
collections = client.stac.list_collections()
# 1.0.0
collections_response = client.stac.get_collections()
for collection in collections_response.collections:
print(collection.id)旧メソッドを残したまま1.0.0へ更新すると、実行時に属性エラーが発生する可能性があります。IDEの全文検索だけでなく、テストコード、バッチ、Notebook、社内共通ライブラリも含めてlist_collectionsを検索してください。
戻り値が専用レスポンスモデルへ変更
1.0.0では、次のモデルなどが追加されています。
AssetStatisticsResponseBandStatisticsMapClassMapLegendResponseQueryableDefinitionsResponseTilerAssetGeoJsonTilerInfoMapResponse
また、get_collection_queryablesとlist_queryablesはQueryableDefinitionsResponseを返すようになり、get_class_map_legendはClassMapLegendResponseを返すようになりました。(PyPI)
この変更では、次のような実装が影響を受けやすくなります。
- 戻り値を直接
dictとして扱っている - レスポンス全体をそのままJSONへ変換している
- 型名を使った分岐やモックを作成している
- スナップショットテストでレスポンス全体を比較している
- 戻り値をキャッシュやデータベースへ保存している
単体テストでは、オブジェクトの型だけでなく、業務で利用しているプロパティが従来どおり取得できるかを確認してください。公式サンプルでも、get_collections()の戻り値からcollections_response.collectionsを参照する形になっています。(PyPI)
初期ベータ版5製品は評価環境から始める
Azure SDKのベータ版は、正式版に先行して新機能やAPI設計を試すためのものです。Microsoftのリリースポリシーでは、ベータ版同士の更新に破壊的変更が含まれる可能性が明記されています。正式版が出るまでバージョンを無条件に追従させず、完全なバージョン番号を固定する運用が安全です。(Azure)
初期ベータ版の導入条件とテスト項目
| パッケージ | 主な導入条件 | 優先して確認する項目 |
|---|---|---|
Java azure-resourcemanager-fileshares | Mavenで1.0.0-beta.1を直接指定 | Azureリソースの作成・更新・削除、依存関係競合 |
Python azure-ai-agentserver-optimization | Python 3.10以上 | 設定取得元の優先順位、JSON不正、通信失敗 |
Python azure-ai-discovery | Python 3.9以上、既存のDiscovery workspaceまたはBookshelf | Entra ID認証、WorkspaceClientとBookshelfClientの操作 |
Python azure-mgmt-discovery | Python 3.9以上、Azureサブスクリプション | サービスプリンシパル、サブスクリプションID、管理権限 |
Python azure-mgmt-fileshares | 実務上はPython 3.10以上を検証基準にする | File Shares管理操作、認証、長時間実行処理 |
Agent Server Optimizationは設定の優先順位をテストする
azure-ai-agentserver-optimizationは、Azure AI Hosted Agents向けの最適化設定を読み込むライブラリです。load_config()は次の順番で設定を解決します。
OPTIMIZATION_CONFIGに指定したインラインJSONOPTIMIZATION_CANDIDATE_IDとOPTIMIZATION_RESOLVE_ENDPOINTによるResolver APIOPTIMIZATION_LOCAL_DIRのローカル設定- 設定なしとして
Noneを返す
不正なJSONや読み取れないメタデータではValueErrorが発生し、Resolver APIの通信エラーなどは呼び出し元へ伝播します。正常系だけでなく、「環境変数が複数設定されている」「JSONが壊れている」「APIへ接続できない」「ローカルのbaselineがない」といった失敗ケースをテストしてください。(PyPI)
DiscoveryのクライアントSDKと管理SDKを混同しない
azure-ai-discoveryは、Discoveryワークスペース内の調査、会話、タスク、ツールを扱うWorkspaceClientと、ナレッジベースを扱うBookshelfClientを提供します。(PyPI)
一方、azure-mgmt-discoveryはAzure上のDiscoveryリソースを管理するための管理ライブラリです。両者は用途が異なるため、「管理SDKだけを導入すればワークスペース内のデータも操作できる」とは限りません。アプリケーションがコントロールプレーンとデータプレーンのどちらを操作するのかを先に整理してください。(PyPI)
File Shares管理SDKはファイルの読み書き用SDKではない
Java版azure-resourcemanager-filesharesは、Azure File Shares Resource Provider APIを扱う管理SDKで、パッケージのAPIバージョンは2026-06-01です。ファイルやディレクトリの内容を読み書きするためのクライアントと同一視しないよう注意してください。(Maven Central)
Java版のベータパッケージはAzure SDK BOMに含まれないため、Mavenではバージョンを直接指定する必要があります。Microsoftの資料では、Azure SDK BOMに含まれるのはGAライブラリであり、ベータ版などのバージョンを直接指定すると共通依存ライブラリの競合が起こる可能性があると説明されています。(Microsoft Learn)
導入後は、少なくとも次のコマンドで依存関係を確認します。
mvn dependency:tree開発環境で動いても、Azure Functions、Spark、Flink、Databricksなどの実行環境が独自の依存ライブラリを持っていると、実行時に異なるバージョンが読み込まれる場合があります。(Microsoft Learn)
Python版File SharesはPython要件の表記差に注意
azure-mgmt-fileshares 1.0.0b1のPyPIメタデータではPython 3.9以上となっていますが、同じページのREADMEと前提条件ではPython 3.10以上と記載されています。(PyPI)
このように公式ページ内で表記が一致していない場合、実務ではPython 3.10以上を検証基準とするのが安全です。Python 3.9でインストールできたとしても、サンプル、依存パッケージ、実際のAPI呼び出しまで問題なく動作するとは限りません。
Azure SDK 2026年6月リリースを安全に導入する手順
利用中のパッケージとバージョンを棚卸しする
まず、アプリケーションが直接参照しているパッケージだけでなく、推移的な依存関係も確認します。
# Python
python -m pip show azure-ai-transcription azure-planetarycomputer
python -m pip show azure-ai-agentserver-optimization azure-ai-discovery
python -m pip show azure-mgmt-discovery azure-mgmt-fileshares
# .NET 10以降
dotnet package list --include-transitive
# .NET 9以前
dotnet list package --include-transitive
# Java
mvn dependency:tree
# JavaScript／TypeScript
npm ls @azure/ai-speech-transcription.NETでは、.NET 10以降はdotnet package list、.NET 9以前はdotnet list packageを使用します。--include-transitiveを付けると推移的なパッケージも確認できます。(Microsoft Learn)
自社が使用しているAPIだけを変更一覧と照合する
変更履歴に多数の項目があっても、自社コードが利用していなければ直ちに影響するとは限りません。次の名前をリポジトリ全体で検索すると、今回の主な影響箇所を見つけやすくなります。
list_collections
PhrasesByChannel
TranscribedPhrases
transcribeWithResponse
TranscriptionDiarizationOptions
TranscriptionContent
TranscribeOptions
operationOptions
get_collection_queryables
list_queryables
get_class_map_legendソースコードだけでなく、次のファイルも検索対象に含めてください。
- 単体テストと結合テスト
- Notebook
- サンプルコードを流用したスクリプト
- 社内共通ライブラリ
- モックやスタブ
- APIレスポンスのスナップショット
- 運用手順書に記載されたコマンド
検証ブランチでバージョンを完全固定する
本番用の依存定義を直接書き換えず、検証用ブランチで対象パッケージだけを更新します。
python -m pip install --upgrade azure-ai-transcription==1.0.0
python -m pip install --upgrade azure-planetarycomputer==1.0.0
python -m pip checkpip checkでは、インストール済みパッケージについて、必要な依存関係が欠けていないか、要求バージョンと矛盾していないかを確認できます。(pip)
ベータ版では、次のようにバージョンを完全に指定します。
python -m pip install azure-ai-discovery==1.0.0b1次のような範囲指定は、将来のベータ版へ自動的に更新される可能性があるため避けた方が安全です。
azure-ai-discovery>=1.0.0b1非本番のAzureリソースで結合テストする
SDKの単体テストが通っても、認証やサービス側APIとの組み合わせで問題が発生する場合があります。
| テスト対象 | 確認内容 |
|---|---|
| 認証 | 開発者アカウント、サービスプリンシパル、マネージドIDのすべて |
| RBAC | 必要最小限のロールで操作できるか |
| エンドポイント | リージョン、リソース名、URLの組み立て |
| レスポンス | 型、プロパティ、None、空配列、ページング |
| 例外 | 401、403、404、429、5xx、タイムアウト |
| 再試行 | 二重作成や二重送信が起こらないか |
| 長時間処理 | タイムアウト、キャンセル、ポーリング |
| ログ | トークン、キー、本文、個人情報が残らないか |
| 削除処理 | テスト用リソースだけを対象にしているか |
管理SDKを評価するときは、いきなり作成・更新・削除を実行せず、最初に一覧取得や個別取得などの読み取り処理から確認します。その後、専用の検証用サブスクリプションまたはリソースグループで変更系APIを試してください。
ロールバック手順を更新前に用意する
更新前には、次の情報を保存します。
- 現在のロックファイル
- 現在のコンテナイメージ
- デプロイ済みアプリケーションのバージョン
- Azure SDKの旧バージョン
- 旧バージョンで生成されたレスポンス例
- データベースやキャッシュへ保存されるJSON形式
MicrosoftのAzure SDKリリースポリシーでも、旧SDKへ入力していたペイロードやデータを新SDKで適切に処理できるか、手動移行テストを行うことが求められています。(Azure)
SDKを戻せても、新しいレスポンス形式で保存したデータを旧SDK側が読めなければ、完全なロールバックにはなりません。コード、パッケージ、保存データの3点をまとめて確認することが重要です。
まとめ：一括更新せず、該当パッケージだけを検証する
Azure SDK 2026年6月リリースで、すべてのAzure利用者に共通する緊急作業が発生したわけではありません。最初に行うべきことは、パッケージ管理ファイルと依存関係ツリーを確認し、今回の対象ライブラリを使っているかを特定することです。
azure-planetarycomputerのベータ版を使用している場合は、list_collectionsからget_collectionsへの変更と、専用レスポンスモデルへの移行を優先して確認します。Azure AI Transcriptionのプレビュー版を使用している場合は、言語ごとの破壊的変更を確認し、固定した音声データで新旧結果を比較してください。
初期ベータ版5製品は、正式版と同じ更新運用に組み込むのではなく、非本番環境、固定バージョン、限定されたAzureリソースで評価するのが安全です。利用パッケージの棚卸し、変更箇所の検索、結合テスト、ロールバック確認までを終えてから、本番環境への反映を判断してください。
コメント