Azure SDK documentation update: Remove all MixedReality SDKs は、Azure SDK利用者にとって「Mixed Reality関連SDKを新規利用し続けてよいか」を見直すべきサインです。結論から言うと、Azure Remote Rendering、Azure Spatial Anchors、Azure Object Anchorsなどに関連するAzure Mixed Reality系のクラウドサービスはすでに退役済み、または退役扱いになっており、該当SDKを使っている場合は依存関係・コード・CI/CD・Azureリソースを棚卸しして、削除または機能置き換えを進める必要があります。今回の変更は、単なるドキュメント整理ではなく、廃止済みサービスに依存した開発・運用を残さないための実務上重要な更新です。(GitHub)
Azure SDK documentation update: Remove all MixedReality SDKsで何が変わるのか
今回確認すべきポイントは、Azure SDK for PythonのリポジトリでMixedReality関連SDKを削除する変更が進められていることです。GitHubのPRでは、Mixed Realityサービスが退役済みであるため、それらのSDKを削除できると説明されています。PR概要でも、Mixed Reality SDKパッケージ本体、依存関係、リポジトリ設定、ドキュメント、パイプライン設定の整理が含まれるとされています。(GitHub)
重要なのは、「SDKが消えるから困る」というより、SDKの前提になっているAzure Mixed Reality系サービスがすでに退役フェーズにあるという点です。SDKを残しても、サービス側が利用できない、サポートされない、セキュリティ更新や不具合修正の対象外になる可能性があるため、既存システムでは早めに利用箇所を特定しておく必要があります。
変更の背景はMixed Realityサービスの退役
Microsoftのライフサイクル情報では、Azure Spatial Anchorsは2024年11月20日に退役、Azure Object Anchorsは2024年5月20日に退役扱いのAzure更新項目として掲載されています。また、Azure Remote Renderingは2025年9月30日に退役し、退役後はセキュリティ更新、非セキュリティ更新、バグ修正、技術サポートを受けられないと説明されています。(Microsoft Learn)
つまり、今回のAzure SDK documentation updateは「Mixed Reality開発そのものが終わる」という意味ではありません。対象は、Azure上で提供されていたMixed Reality系クラウドサービスと、それらを操作するSDKです。HoloLens、Unity、OpenXR、一般的な3D/XR開発とは切り分けて考える必要があります。
影響を受ける主なSDKと確認ポイント
Azure SDK for Pythonの変更では、次のようなMixedReality関連パッケージや設定が削除対象として扱われています。PRのファイル一覧には、azure-mgmt-mixedreality、azure-mixedreality-authentication、azure-mixedreality-remoterendering、関連するCI設定、テストリソース、ドキュメント、Conda関連設定などが含まれています。(GitHub)
| 対象 | 主な用途 | まず確認すべき場所 |
|---|---|---|
azure-mixedreality-remoterendering | Azure Remote RenderingをPythonから操作するSDK | 3Dモデルのリモートレンダリング、レンダリングセッション作成、ARR関連のサンプルコード |
azure-mixedreality-authentication | Mixed Reality STSからアクセストークンを取得する認証SDK | MixedRealityStsClient、アカウントID、アカウントドメイン、アカウントキー |
azure-mgmt-mixedreality | Mixed RealityリソースをAzure Resource Manager経由で管理するSDK | Spatial Anchors、Object Anchors、Remote Renderingアカウントの作成・取得・キー操作 |
| CI/CD・ドキュメント設定 | リポジトリ内のテスト、ビルド、ドキュメント生成 | GitHub Actions、Azure Pipelines、Conda設定、README、社内手順書 |
PyPI上でも、azure-mixedreality-authentication、azure-mgmt-mixedreality、azure-mixedreality-remoterenderingはいずれも非アクティブまたは非推奨扱いの情報が確認できます。特に各パッケージ説明では、2025年10月1日以降はメンテナンスされない旨が記載されています。(PyPI)
対応が必要な人・不要な人
対応が必要なのは、Pythonアプリケーションや自動化スクリプト、CI/CD、IaCテンプレートでAzure Mixed Reality系のSDKやリソースを使っているチームです。特に、過去にHoloLensやUnity向けの検証プロジェクトを作り、そのまま依存関係だけが残っているケースでは、ビルドやセキュリティ棚卸しで問題になりやすくなります。
| 立場 | 対応要否 | 理由 |
|---|---|---|
| PythonでAzure Remote Renderingを呼び出していた開発者 | 必要 | SDK・サービスともに継続利用前提で設計し直すべき |
| AzureリソースをIaCで管理しているインフラ担当者 | 必要 | Microsoft.MixedReality/* リソース定義が残っている可能性がある |
| CI/CDでAzure SDK for Pythonのリポジトリやサンプルを参照している担当者 | 必要 | 削除後にテスト対象やドキュメント参照が壊れる可能性がある |
| HoloLensアプリをローカルレンダリングのみで開発している人 | 多くの場合は不要 | Azure Mixed Realityクラウドサービスに依存していなければ直接影響は小さい |
| Azure SDKを使っているがStorage、Key Vault、Cosmos DBなどのみ利用している人 | 不要 | MixedReality SDK削除とは別領域 |
判断に迷う場合は、「Mixed Reality」という名前だけで判断せず、実際にAzure上のリソースやPythonパッケージを参照しているかを確認してください。UnityプロジェクトやXRアプリにMixed Realityという言葉が含まれていても、Azureの該当クラウドサービスを使っていなければ、今回のSDK削除の影響は限定的です。
まず確認する場所：依存関係、コード、Azureリソース
対応は、いきなり移行先を探すよりも、利用実態の棚卸しから始めるのが安全です。特に退役済みサービスでは「少しだけ使っている」「昔の検証コードが残っている」「CIだけが参照している」といった状態が多く、見落とすとビルド失敗や不要なシークレット残存につながります。
Pythonの依存関係を確認する
まず、プロジェクト内にMixedReality関連パッケージが入っていないか確認します。
python -m pip freeze | grep -i mixedreality依存関係ファイルも検索してください。
grep -Rni "azure-mixedreality\|azure-mgmt-mixedreality\|mixedreality" \
requirements.txt pyproject.toml poetry.lock Pipfile.lock setup.py setup.cfg . 2>/dev/null確認対象は、アプリ本体だけではありません。次のファイルにも残っていることがあります。
| 確認対象 | 見落としやすい内容 |
|---|---|
requirements.txt | 検証用SDKが固定されている |
pyproject.toml | 直接依存ではなく開発用依存に残っている |
poetry.lock / Pipfile.lock | すでに使っていない推移的依存が残っている |
Dockerfile | 古いサンプル実行用にpip installしている |
| CI設定 | テストジョブだけがMixedRealityサンプルを実行している |
| 社内テンプレート | 新規プロジェクト作成時に不要なSDKが入る |
コード内のimportとクラス名を確認する
次に、SDKのimportや主要クラスが残っていないか確認します。
git grep -n \
-e "azure.mixedreality" \
-e "azure.mgmt.mixedreality" \
-e "MixedRealityStsClient" \
-e "RemoteRenderingClient" \
-e "SpatialAnchors" \
-e "ObjectAnchors" \
-e "RemoteRendering"見つかった場合は、単にimportを消すのではなく、そのコードがどの業務機能に紐づいているかを確認してください。たとえば、リモートレンダリングを使って3Dモデルを表示していたのか、アカウントキーを取得する管理スクリプトだけだったのかで、対応の重さが大きく変わります。
Azure上のMixedRealityリソースを棚卸しする
Azure Resource GraphやAzure CLIで、Mixed Reality系リソースが残っていないか確認します。Azure Resource Graphの対応リソース種別には、microsoft.MixedReality/objectAnchorsAccounts、remoteRenderingAccounts、spatialAnchorsAccountsなどが掲載されています。(Microsoft Learn)
az resource list --resource-type Microsoft.MixedReality/remoteRenderingAccounts -o table
az resource list --resource-type Microsoft.MixedReality/spatialAnchorsAccounts -o table
az resource list --resource-type Microsoft.MixedReality/objectAnchorsAccounts -o tableサブスクリプションが複数ある場合は、全サブスクリプションを対象にします。
for sub in $(az account list --query "[].id" -o tsv); do
az account set --subscription "$sub"
echo "Subscription: $sub"
az resource list --query "[?contains(type, 'Microsoft.MixedReality')].[name,type,resourceGroup,location]" -o table
doneリソースが見つかった場合は、削除可否を即断しないでください。請求、監査、アプリ連携、キー参照、社内ドキュメントの有無を確認し、利用終了の記録を残してから削除します。
移行の考え方：SDK置き換えではなく機能整理から始める
今回の変更で注意すべきなのは、単純な「新SDKへアップグレード」では済まない点です。退役済みサービスに紐づくSDKのため、一般的なAzure SDK更新のようにバージョンを上げれば解決するとは考えないほうが安全です。
Azure Remote Renderingを使っていた場合
Azure Remote Renderingは、高精細な3DモデルをクラウドGPU側でレンダリングし、デバイスへストリーミングするためのサービスでした。Microsoft Learnでも、Azure Remote Renderingは2025年9月30日に退役したと説明されています。(Microsoft Learn)
移行検討では、次のように要件を分解します。
| もともとの要件 | 見直しの方向性 |
|---|---|
| HoloLensなど軽量デバイスで巨大3Dモデルを表示したい | モデル軽量化、LOD、ローカルレンダリング、別のレンダリング基盤を検討 |
| 複数拠点から同じ3D資産を確認したい | 3Dデータ配信、ビューア、共同レビュー機能を分けて再設計 |
| Pythonでレンダリングセッションを自動作成していた | セッション自動化を廃止するか、新しい配信・表示方式に合わせて作り直す |
| アカウントキーでARRへアクセスしていた | キー・環境変数・Key Vaultシークレットを棚卸しして削除または無効化 |
ここでありがちな失敗は、「GPU VMを立てれば同じことができる」と短絡的に考えることです。Remote Renderingは単なるGPU計算ではなく、3Dモデル処理、ストリーミング、認証、クライアント統合を含むサービスでした。代替を検討する場合は、レンダリング品質、遅延、ネットワーク帯域、端末性能、運用コストをまとめて評価する必要があります。
Azure Spatial AnchorsやObject Anchorsを使っていた場合
Azure Spatial AnchorsやObject Anchorsを使っていた場合は、SDKの削除よりも、アプリ体験そのものへの影響を先に見ます。Spatial Anchorsは空間上の位置共有、Object Anchorsは物体認識・3Dモデル照合に関わるため、代替はアプリの目的によって大きく変わります。
確認すべき観点は次の通りです。
| 確認項目 | 判断基準 |
|---|---|
| アンカー共有が必須か | 複数ユーザー・複数端末で同じ位置を共有しているか |
| オフライン動作が可能か | クラウド連携なしでローカル認識に切り替えられるか |
| 3Dモデル照合の精度要件 | 業務上、誤認識が許容されるか |
| 保存済みデータの扱い | 過去のアンカー情報やアカウント情報を削除・保管する必要があるか |
| 端末依存機能の有無 | HoloLens、モバイルAR、OpenXR、Unity側機能で代替できるか |
この領域は、公式後継SDKを探すよりも、要件を「位置合わせ」「共有」「認識」「可視化」「記録」に分けて再設計するほうが現実的です。特にPoC段階の機能であれば、廃止を含めた判断を早めに行うことで、保守コストを抑えられます。
認証SDKだけ残っている場合
azure-mixedreality-authenticationだけが残っているケースもあります。これは、Mixed Reality STSからアクセストークンを取得するためのSDKです。PyPIの説明でも、Azure Remote RenderingなどのMixed Realityサービスで使うSTS向けパッケージとして説明されています。(PyPI)
認証SDKだけが残っている場合、実際の機能はすでに使われていないことがあります。次の項目を確認してください。
| 確認対象 | 対応 |
|---|---|
MIXEDREALITY_ACCOUNT_ID | 不要なら環境変数・CI変数から削除 |
MIXEDREALITY_ACCOUNT_DOMAIN | Key Vaultやシークレット管理から削除対象にする |
MIXEDREALITY_ACCOUNT_KEY | 露出リスクがあるため、使っていないなら無効化・削除 |
MixedRealityStsClient | 呼び出し元機能が廃止済みならコードごと削除 |
| Azure ADアプリ・サービスプリンシパル | Mixed Reality専用の権限が残っていないか確認 |
使われていない認証情報を残すと、セキュリティレビューで指摘されやすくなります。特にアカウントキーを環境変数やCIシークレットに残している場合は、SDK削除と同時に整理してください。
CI/CDや社内ドキュメントで起きやすい問題
PRでは、SDK本体だけでなく、CI/CDパイプライン、ドキュメントの目次、Conda設定、リグレッションテストマトリクス、CODEOWNERSなどの整理も含まれています。これは、MixedReality SDKが単体のパッケージとしてだけでなく、リポジトリ運用やドキュメント生成にも組み込まれていたことを示しています。(GitHub)
社内プロジェクトでも、同じような問題が起きます。
| 問題 | 具体例 | 対応 |
|---|---|---|
| ビルドが失敗する | 削除済みサンプルやREADMEを参照している | CI対象から外す、テストを削除する |
| 依存関係監査で警告が出る | 非推奨パッケージがlockファイルに残る | lockファイルを再生成する |
| ドキュメントが古い | 「Azure Remote Renderingを使う」と書かれている | 退役済みであることを明記し、手順を削除する |
| シークレットが残る | ARRアカウントキーがCI変数に残っている | 不要なシークレットを削除し、監査記録を残す |
| IaCテンプレートが残る | Microsoft.MixedReality/*をデプロイしようとする | Terraform、Bicep、ARMテンプレートから削除する |
特にCI/CDでは、「本番機能では使っていないがテストだけが参照している」状態がよくあります。この場合、アプリの動作には影響がなくても、依存関係更新やリポジトリ整理のタイミングで突然ビルドが落ちます。不要なテストやサンプルは、早めに削除しておくのが安全です。
実務で使える対応手順
以下の順で進めると、影響範囲を見落としにくくなります。
| 手順 | 作業内容 | 完了条件 |
| -: | ——————— | ——————————————– |
| 1 | Python依存関係を検索する | MixedReality関連パッケージの有無が分かっている |
| 2 | import、クラス名、環境変数を検索する | 実際の利用コードと未使用コードを分類できている |
| 3 | Azureリソースを棚卸しする | Microsoft.MixedReality/* リソースの有無が分かっている |
| 4 | CI/CDとIaCを確認する | パイプライン、Dockerfile、Terraform、Bicepの参照を洗い出している |
| 5 | 機能を分類する | 廃止、置き換え、保留の判断ができている |
| 6 | シークレットを整理する | 不要なキー、環境変数、Key Vaultシークレットを削除している |
| 7 | ドキュメントを更新する | 社内手順書に退役済みサービスを前提とした記述が残っていない |
削除作業では、いきなり本番ブランチで依存関係を消すのではなく、専用ブランチでテストを回してください。特に古いPoCコードが本番リポジトリに同居している場合、削除によって意外なテストや型チェックが失敗することがあります。
移行判断の基準
MixedReality SDKの利用箇所が見つかったら、次の基準で判断します。
| 状態 | 推奨対応 |
|---|---|
| すでに使っていない検証コード | コード、依存関係、ドキュメント、シークレットを削除 |
| 本番機能だが利用頻度が低い | 機能廃止を含めて業務側と判断 |
| 本番機能で利用中 | 代替アーキテクチャを設計し、段階的に移行 |
| SDKだけ残っているが呼び出しがない | lockファイル更新とCI確認を行って削除 |
| Azureリソースだけ残っている | 請求・監査・データ保管要件を確認して削除計画を作る |
ポイントは、SDKの置き換え先を探す前に、機能を残す必要があるかを判断することです。退役済みサービスに紐づく機能は、技術的に延命できても運用リスクが残ります。業務上不要になっている機能なら、移行より削除のほうが正しい判断になる場合があります。
注意点：PRの状態と各言語SDKの扱いは個別に確認する
今回の主なソースはAzure SDK for PythonのGitHub PRです。PRページでは、2026年5月時点でレビューや承認が進んでいることが確認できますが、リポジトリのマージ状況や各パッケージ配布状態はタイミングによって変わります。作業前には、利用しているSDKのリポジトリ、PyPI、Azure公式ドキュメント、社内の依存関係管理を必ず確認してください。(GitHub)
また、今回のPRはPythonリポジトリに関する変更です。Java、.NET、JavaScript、Goなど他言語のSDKを使っている場合は、それぞれのAzure SDKリポジトリやパッケージ管理サイトで確認が必要です。「Pythonで削除されるから全言語で同じ日付に削除される」とは断定しないほうが安全です。
まとめ：まずはMixedReality依存の棚卸しから始める
Azure SDK documentation update: Remove all MixedReality SDKsで押さえるべき結論は明確です。Azure Mixed Reality系サービスは退役済みのため、該当SDKを新規採用せず、既存プロジェクトでは依存関係・コード・Azureリソース・CI/CD・シークレットを棚卸しする必要があります。
最初にやるべきことは、次の3つです。
azure-mixedreality、azure-mgmt-mixedreality、Microsoft.MixedRealityをコードと設定ファイルから検索する- Azure上にRemote Rendering、Spatial Anchors、Object Anchors関連リソースが残っていないか確認する
- 見つかった機能を「削除」「置き換え」「保留」に分類し、不要なSDKとシークレットを整理する
この対応は、単なるライブラリ整理ではありません。退役済みサービスへの依存を減らし、ビルド失敗、セキュリティリスク、古い社内手順の放置を防ぐためのメンテナンスです。まずは利用実態を確認し、使っていないものから安全に削除していきましょう。
コメント