Azure Cosmos DB documentation update: Cosmos: Restore workspace dependenciesの変更点と確認ポイント

Azure Cosmos DB documentation update: Cosmos: Restore workspace dependencies は、Azure Cosmos DBのデータ復元機能が変わる更新ではありません。結論から言うと、Azure Cosmos DB向けRust SDK関連クレートで、azure_core と azure_identity の依存関係を一時的な固定バージョンからワークスペース管理へ戻す変更です。

特に確認すべきなのは、Azure Cosmos DBをRustアプリケーションから利用している開発者、Azure SDK for RustをGitHubブランチやプレビュー版で追従しているチーム、CI/CDで Cargo.lock や依存関係チェックを厳密に管理しているチームです。Azureポータル上のCosmos DBアカウント設定、バックアップ、ポイントインタイムリストア、データ移行そのものに直接変更が入る更新ではありません。

Azure Cosmos DB documentation update: Cosmos: Restore workspace dependencies の概要

今回の更新は、Azure SDK for RustリポジトリのPull Request「Cosmos: Restore workspace dependencies」として確認できます。このPRは2026年5月19日に release/azure_data_cosmos-previews ブランチへマージされ、Cosmos関連クレートの依存関係を再整理する内容です。PR本文では、Azure Core SDKがGAになったため、未リリースビルドではなく最新のリリース済みビルドを指すワークスペース依存関係を再び使えるようになった、と説明されています。(GitHub)

この変更の中心は、Cosmos DB向けRust SDKの Cargo.toml に書かれていた azure_core = { version = "0.35.0" } や azure_identity = { version = "0.35.0" } のような固定指定を、workspace = true に戻すことです。PRの差分では、azure_data_cosmos、azure_data_cosmos_driver、azure_data_cosmos_perf、azure_data_cosmos_benchmarks などのクレートが対象になっています。(GitHub)

観点	変更前	変更後	実務上の意味
azure_core の指定	version = "0.35.0" を個別指定	workspace = true を利用	リポジトリ全体の共通依存関係に追従しやすくなる
azure_identity の指定	version = "0.35.0" を個別指定	workspace = true を利用	認証関連クレートのバージョン管理が統一される
依存関係チェック	Cosmos向けの一時的な例外あり	例外を削除	CIや検証スクリプトで特別扱いが減る
Cargo.lock	古い依存関係が残る可能性	ロックファイルを更新	ビルド時に解決される依存バージョンが変わる可能性がある

「Restore」はデータ復元ではなく依存関係の復元

Azure Cosmos DBの文脈で「Restore」と聞くと、バックアップからの復元、削除済みアカウントの復元、ポイントインタイムリストアを連想しがちです。しかし、今回の「Restore workspace dependencies」は、Cosmos DBデータの復元機能ではありません。

ここでの「Restore」は、RustのCargoワークスペース依存関係を元に戻すという意味です。Cargoでは、ルート側の [workspace.dependencies] に依存関係を定義し、各クレート側で workspace = true と書くことで、その依存関係を継承できます。(Rust ドキュメント)

つまり、Azure Cosmos DBの管理者がAzureポータルで復元設定を変更したり、バックアップポリシーを再設定したりする必要は基本的にありません。影響を受けるのは、主にRust SDKのビルド、依存関係解決、テスト、パッケージ管理です。

なぜ今回の変更が必要だったのか

背景にあるのは、Azure SDK for Rustのコア部分が安定版になったことです。Microsoftは2026年5月14日に、Azure SDK for Rustが安定版になり、安定APIとセマンティックバージョニングの保証を備えたSDKとして利用できるようになったと発表しています。(Microsoft for Developers)

また、Microsoft LearnのRust向けAzure SDKライブラリ一覧では、azure_core と azure_identity が 1.0.0、Cosmos DB向けの azure_data_cosmos が 0.33.0 として掲載されています。これは、CoreやIdentityの基盤部分はGA相当の安定版に到達している一方で、Cosmos DBのRustクレート自体はまだ1.0系ではないことを示しています。(Microsoft Learn)

このため、今回の更新は「Azure Core SDKがGAになったので、Cosmos関連クレートも最新のリリース済みCore/Identityに合わせて依存関係を整理する」ための変更と見るのが自然です。

影響を受ける対象者

今回の更新は、Azure Cosmos DBを使っているすべての利用者に同じ影響を与えるものではありません。影響の有無は、Rust SDKをどのように使っているかで変わります。

対象者	影響度	確認すべきこと
Azure Cosmos DBをポータルや.NET/Java/Python SDKで利用している管理者	低	データベース設定や復元設定の変更は不要
Rustで azure_data_cosmos を使っている開発者	中	Cargo.toml と Cargo.lock の依存関係を確認
Azure SDK for RustのGitHubブランチを直接参照しているチーム	高	workspace = true への変更でビルド結果が変わらないか確認
CI/CDで依存関係チェックを行っているチーム	高	verify-dependencies.rs の例外削除により検証結果が変わらないか確認
本番環境でCosmos DB Rust SDKのプレビュー機能を使っているチーム	高	SDKのプレビュー扱い、認証、ロールバック手順を再確認

重要なのは、Azure Core SDKのGAとAzure Cosmos DB Rust SDKのGAを混同しないことです。Microsoft LearnのCosmos DB Rustクイックスタートでは、Azure Cosmos DB用Rust SDKはパブリックプレビューであり、SLAなし、本番環境では推奨されない旨が記載されています。(Microsoft Learn)

開発者がまず確認すべき依存関係

RustアプリケーションでAzure Cosmos DBを利用している場合、最初に見るべき場所は Cargo.toml と Cargo.lock です。特に、azure_core や azure_identity をアプリケーション側で直接固定している場合は注意が必要です。

次のような指定が残っている場合、今回の更新後のCosmos関連クレートと依存関係がずれる可能性があります。

[dependencies]
azure_data_cosmos = "0.33.0"
azure_core = "0.35.0"
azure_identity = "0.35.0"

このようにCoreやIdentityだけを古いバージョンに固定していると、Cosmos側が期待する依存関係とアプリケーション側の依存関係が分かれ、重複バージョン、型の不一致、認証コードの変更対応漏れが起きることがあります。

まずは、プロジェクト内に古い固定指定がないか確認します。

grep -R 'azure_core.*0\.35\.0\|azure_identity.*0\.35\.0' .

依存関係ツリーも確認しておくと、複数バージョンが混在しているか判断しやすくなります。

cargo tree -i azure_core
cargo tree -i azure_identity

更新後は、ロックファイルを含めてビルドを確認します。

cargo update -p azure_core -p azure_identity
cargo build
cargo test

CIで再現性を重視している場合は、Cargo.lock をコミットしたうえで、--locked を使ったビルドも確認してください。

cargo build --locked
cargo test --locked

管理者が確認すべきポイント

Azure Cosmos DBの管理者にとって、今回の更新で最も大事なのは「サービス設定の変更ではない」と切り分けることです。以下の設定は、今回のPRによって直接変更されるものではありません。

項目	今回の更新で変更されるか	補足
Azure Cosmos DBアカウントのリージョン	いいえ	SDK依存関係の変更であり、リージョン構成は変わらない
バックアップポリシー	いいえ	定期バックアップや継続的バックアップの設定変更ではない
ポイントインタイムリストア	いいえ	「Restore」はデータ復元機能の更新ではない
コンテナーのパーティションキー	いいえ	データモデルやコンテナー設計には影響しない
RU/s、オートスケール設定	いいえ	スループット設定には影響しない
認証方式	直接はいいえ	ただしRust SDK側で azure_identity を更新する場合は動作確認が必要

一方で、RustアプリケーションがMicrosoft Entra ID、マネージドID、Azure CLIログインなどを使ってCosmos DBに接続している場合は、azure_identity の更新に伴う認証フローの動作確認が必要です。ローカル開発では通るが、AKS、Azure Container Apps、Azure Functions、VM上のマネージドIDでは失敗する、というパターンは実務で起きやすい問題です。

移行・展開時の実践チェックリスト

今回の変更に追従する場合は、いきなり本番環境のコンテナイメージやバイナリを差し替えるのではなく、依存関係の変化を小さく確認するのが安全です。

変更前に確認すること

チェック項目	確認方法	失敗しやすいポイント
azure_core のバージョン	cargo tree -i azure_core	0.35系と1.0系が混在している
azure_identity のバージョン	cargo tree -i azure_identity	認証コードだけ古い前提で書かれている
Cargo.lock の状態	git diff Cargo.lock	ロックファイルを更新せずCIだけ失敗する
feature指定	Cargo.toml を確認	default-features や reqwest、tokio 関連の差分を見落とす
認証方式	ローカル、ステージング、本番相当で接続確認	ローカルのAzure CLI認証だけで判断してしまう

安全に更新する手順

依存関係の固定指定を確認する

古いバージョンが明示されている場合は、なぜ固定しているのかを確認します。互換性テストのために意図的に固定しているなら、すぐに削除せず、更新用ブランチで動作確認します。

grep -R 'azure_core\|azure_identity\|azure_data_cosmos' Cargo.toml **/Cargo.toml

ロックファイルを更新する

依存関係を更新したら、Cargo.lock の差分を必ず確認します。Rustの依存関係更新では、直接指定したクレートだけでなく、推移的依存関係も変わることがあります。

cargo update
git diff Cargo.lock

ビルドとテストを分けて実行する

最初にコンパイルエラーを潰し、その後に認証やCosmos DB接続を含む統合テストを実行します。

cargo build --all-targets
cargo test --all-targets
cargo clippy --all-targets --all-features

Cosmos DB接続をステージングで確認する

アプリケーションが実際にCosmos DBへ接続する処理は、ユニットテストだけでは検出できないことがあります。少なくとも以下を確認してください。

確認項目	具体例
読み取り	既存アイテムの取得、クエリ実行
書き込み	テスト用コンテナーへの作成・更新・削除
認証	ローカル開発資格情報、マネージドID、サービスプリンシパル
エラー処理	401、403、429、タイムアウト時のリトライ
ログ	SDK更新後も診断ログやトレースが欠落しないか

本番展開はカナリアで行う

Cosmos DBへの接続処理は、認証、HTTPクライアント、リトライ、タイムアウト、リージョン指定など複数の層にまたがります。依存関係更新だけでも、実行環境によって差が出ることがあります。

本番では、全台同時更新ではなく、少数インスタンスでカナリア展開し、次の指標を見てから段階的に広げるのが安全です。

監視項目	見るべき変化
401/403エラー	認証方式や権限解決の問題
429エラー	リトライ挙動や負荷の変化
P95/P99レイテンシ	HTTPクライアントや接続再利用の影響
失敗リクエスト率	SDK更新後の例外増加
コンテナ再起動回数	起動時認証や設定読み込み失敗

よくある誤解と注意点

Azure Core SDKのGAはCosmos DB Rust SDKのGAと同じではない

今回のPR説明ではAzure Core SDKのGAが理由として挙げられていますが、それは azure_core など基盤クレートの話です。Cosmos DB向けRust SDKは、Microsoft Learn上ではパブリックプレビューとして案内されており、本番利用可否の判断は別途必要です。(Microsoft Learn)

特に、金融、医療、決済、基幹業務など停止影響が大きいシステムでは、プレビューSDKの利用を本番標準にする前に、サポート条件、SLA、障害時の切り戻し、代替SDKの有無を確認してください。

Cargo.lock だけを更新して安心しない

Cargo.lock の更新でビルドが通っても、Cargo.toml に古い固定指定が残っていると、将来の更新で再び同じ問題が出ます。特にワークスペース構成のプロジェクトでは、ルートの Cargo.toml、各サブクレートの Cargo.toml、CIの依存関係キャッシュをセットで確認する必要があります。

feature指定の差分を見落とさない

今回の差分では、単にバージョン番号を置き換えるだけでなく、default-features = false や features = ["reqwest"] のような指定も関係します。HTTPクライアント、非同期ランタイム、認証方式に関わるfeatureは、ビルドできても実行時の挙動に影響することがあります。

GitHubブランチ参照のプロジェクトは特に注意する

crates.ioの公開版だけを使っている場合と、Azure SDK for RustのGitHubブランチを直接参照している場合では、影響の出方が異なります。GitHubブランチを直接参照している場合、ワークスペース依存関係の変更をより早く取り込む可能性があるため、CIでの検出が重要です。

[dependencies]
azure_data_cosmos = { git = "https://github.com/Azure/azure-sdk-for-rust", branch = "release/azure_data_cosmos-previews" }

このような指定をしている場合は、対象ブランチの更新で依存関係が変わるため、コミットハッシュ固定や検証済みタグ利用も検討してください。

今回の更新を受けて取るべき行動

RustでAzure Cosmos DBを使っていない場合、今回の更新に対して特別な作業は不要です。Azure Cosmos DBのデータ、バックアップ、コンテナー、RU/s設定が変わる更新ではありません。

Rustで azure_data_cosmos を使っている場合は、次の順番で確認してください。

優先度	やること	目的
高	azure_core と azure_identity の固定指定を確認	古い0.35系への依存を見つける
高	cargo tree で複数バージョンの混在を確認	型不一致や重複依存を防ぐ
高	Cargo.lock を更新してCIでビルド	再現性のある依存関係にする
中	認証処理をステージングで確認	azure_identity 更新の影響を検出する
中	カナリア展開で監視	本番影響を最小化する
低	バックアップ/復元設定を確認	今回の変更とは無関係だが、誤解防止のために整理する

まとめ

Azure Cosmos DB documentation update: Cosmos: Restore workspace dependencies は、Azure Cosmos DBのデータ復元機能ではなく、Azure Cosmos DB向けRust SDK関連クレートの依存関係を整理する更新です。

主な変更は、azure_core と azure_identity の一時的な固定バージョン指定をやめ、Cargoワークスペースの依存関係へ戻すことです。Azure Core SDKがGAになったことで、未リリースビルドではなくリリース済みビルドを参照できるようになった点が背景にあります。(GitHub)

管理者は、Azure Cosmos DBアカウント設定やバックアップ設定が変わる更新ではないと切り分けてください。開発者は、Cargo.toml、Cargo.lock、cargo tree、CI/CD、認証処理を確認し、ステージング環境でCosmos DB接続を検証してから本番へ展開するのが安全です。