先週開催された Build 2026 では Azure Functions / Container Apps のアップデートがかなり熱かったですが、Cosmos DB は更に熱いアップデートが多くなっています。去年までは Vector Search など AI 関連の機能が中心となっていましたが、今年は AI 関連の機能よりもデータストアとしての機能強化が目立った印象です。
Build のセッション情報とアップデートについては、例年通り Cosmos DB チームの公式ブログで公開されているので、セッション込みで参照してもらうのがお勧めです。
ツール関連もアップデートが多く公開されていますが、個人的には NoSQL 機能のアップデートに注目しているので、今回も NoSQL かつ興味のあるものをまとめておきます。今回 GA した機能は大体が去年の Build で Public Preview になったもので、アーキテクチャ設計が変わる大物が多いです。
元々 Full Fidelity Change Feed と呼ばれていた All Versions and Deletes Change Feed のように数年越しの GA に到達した機能もあり、これからの Cosmos DB を利用したアーキテクチャを変える可能性を秘めています。
General Availability (GA)
Global Secondary Indexes
Preview 当初は Materialized View という名前の機能でしたが、仕組みが大きく変わったタイミングで Global Secondary Indexes という一般的にイメージしやすい機能名に代わりましたが、この度 GA となりました。Cosmos DB は Partition Key を強く意識する必要があり、その設計によってパフォーマンスとコストが大きく変わってきますが、全てのクエリに対応出来る設計というのは無理なので、現実的には以前から Change Feed を使ってより適した構造に変換する実装を行ってきましたが、GSI を使えば簡単な定義だけで同様の処理が実現できます。
GSI を使うことで複数のアクセスパターンがあっても、それぞれに最適なデータを用意しパフォーマンスを大幅に改善出来るのはもちろん、専用のデータを作成するための実装が必要ないという点が非常に優れています。シンプルにクエリを定義すれば、その結果で GSI が作られるので Partiton Key の変更だけではなくデータの削減も可能です。
Change Feed を使って実装されているので、データの一貫性を心配することなく安心して利用できます。データの書き込みについてはラグが発生するため、その点だけは注意が必要にはなります。
All Versions and Deletes Change Feed
GSI の実装にも使われている Change Feed ですが、1 つの Item に複数回の書き込みを行った場合には、それぞれの書き込みの変更を取得することは出来ず、最新の Item の情報のみが取得されるという挙動になっています。これは Change Feed が別のデータストアにトランザクションログのようなものを持つことで実現しているのではなく、書き込みのシーケンス番号を使って実現されていることに依存します。
そのような仕組みなので削除された場合は通常の Change Feed は検知できず、処理するためには Soft Delete を実装する必要がありましたが、TTL との相性が悪く削除も検知できる Change Feed が必要な場面がありました。今回の All Versions and Deletes Change Feed では名前の通り全ての書き込みと削除をトリガーとしてデータを取得出来るので、より正確なイベントソーシングの実装も可能となります。
All Versions and Deletes Change Feed の使い方としては、これまでの Change Feed と同様に Azure Functions の Cosmos DB Trigger を使って実装するのが一番簡単な方法です。最新バージョンでは対応が含まれているので、これまでと同じような使い勝手で詳細な変更の検知が行えるようになります。
仕組みとしては継続的バックアップが必須なことから、PITR で使われているトランザクションログ的なものを流用して実現していると考えられます。これまでの Change Feed はデータが残っていれば Container の作成時点からのリプレイが可能でしたが、新しいモードでは継続的バックアップの保持期間内のデータのみリプレイ可能という差があります。
Change Partiton Keys
Cosmos DB の設計で難しいと言われるのが Partition Key の設計で、一度 Container を作成すると変更できないのが辛い点でしたが、Azure Portal から Partition Key を変更する機能が公開されました。機能としては Container のコピー機能を使っていて、現在は Azure Portal だけで利用できるようです。
単純に Partition Key の変更と聞くと、インプレースで Container に対して処理が行われることを期待すると思いますが、新しい Partition Key で Container を作成し、そこに対してコピーを行うというのが実装になります。それなりに手間のかかる処理なので、これまで通り Partition Key の設計を軽く考えてよいという訳ではないです。
致命的に Partition Key の設計を間違ったケース以外では GSI が利用できるので、現実的にはあまり使う機会は多くないはずですが、上手く組み合わせて使っていきたい機能です。
Per-Partiton Automatic Failover (PPAF)
基本として Cosmos DB でマルチリージョン構成を有効化している場合に書き込みリージョンで障害が発生した場合には、自動的に他のリージョンにフェールオーバーされます。Cosmos DB の内部的には物理パーティション単位で独立しているため、どれか 1 つの物理パーティションに障害が発生しても正常な物理パーティションもフェールオーバーする必要はないのですが、アカウント全体に対して行うというのがこれまでの挙動でした。
今回 GA した Per-Partition Automatic Failover (PPAF) は名前からも分かるように、物理パーティション単位でフェールオーバーが行われるためユーザー側では何もしなくても高い可用性が維持されます。
これまで信頼性のためにマルチリージョンでの書き込みを利用、または検討していたシナリオでは PPAF を使うことで競合などを気にする必要のないシングルリージョンでの書き込みを使いつつ、同等の信頼性を得ることが出来るようになります。利用するには最新の Cosmos DB SDK が必要になる点だけは注意ですが、PPAF で得られるメリットは大きいです。
Cosmos DB vNext Emulator
長らく Preview のままで、あまり進捗が見えませんでしたが、Linux もサポートする Cosmos DB vNext Emulator がようやく GA となりました。これまでの進捗が少しずつ更新はされていましたが、今回の GA のタイミングで未対応だった機能はほとんどがサポートされるようになり、GitHub Actions などの CI でも動かしやすくなっています。
特筆すべきは新しい Emulator は Vector Search にも対応しているので、ローカルで全ての検証が行えるようになったのはコスト的にメリットがあります。ネットワークに制限がある環境でも GitHub Codespaces を使えば、開発環境含めて完結できるので利用シーンは広そうです。
Public Preview
Semantic Reranker
この 1,2 年の Cosmos DB は Vector Search や Full Text Search といった検索特化インデックスが追加されて、AI が利用するナレッジのデータベースとして利用することが大幅に増えましたが、AI Search に比べると機能的に少ないという実情はあります。特に最近の AI Search は精度を上げるための機能投入が多い印象なのですが、今回の Build で Cosmos DB でも Semantic Reranker が Public Preview として追加されたので、機能面での差を詰めつつあります。
Cosmos DB への検索は Vector Search や Full Text Search を使い、必要に応じて Hybrid Search も組み合わせながら関連性の高いデータを取得した後に、Semantic Reranker を使って関連性スコアを改善するというアプローチです。Semantic Reranker の実装は AI Search でも使われている実装やモデルと同じようです。
特徴としては Semantic Reranker の実装自体は Microsoft.InferenceService リソースとして独立して提供されているものを使うようになっているので、Cosmos DB 専用という訳ではありません。Cosmos DB SDK に Semantic Reranker の実装が入っていたので確認しましたが、Azure Portal で Semantic Reranker を有効化するとエンドポイントが表示されるので、それを設定すると REST API 呼び出しを行うというものでした。
現在の実装では Semantic Reranker のエンドポイントは AZURE_COSMOS_SEMANTIC_RERANKER_INFERENCE_ENDPOINT という名前の環境変数を設定する必要がある、珍しく少し使い勝手が悪いものでした。GA までにはもう少し統合感が出るかもしれませんが、Preview 中は少し設定値が分かりにくいので注意が必要です。
Integrated Embedding
Cosmos DB が Vector Search に対応してからは、Azure Functions と Change Feed を使って Embedding を行う処理を書いてきましたが、今回 Public Preview となった Integrated Embedding を使って、Vector Index Policy に対して利用するモデルの情報などを設定すれば、自動的に Embedding を行ってくれるので自前実装が不要になります。
実装としては GSI に近いものになっているようです。例によって Change Feed を使った実装になっているので、Container に対して項目を追加、更新をしてから非同期で Embedding が行われる仕組みです。保存した瞬間に Embedding が同期的に行われるわけではないので、Vector Search が出来るようになるまでラグが発生するはずです。
実際に Change Feed を読み取って Embedding を行うコンピューティングはコントロール出来ないので、Azure OpenAI や Foundry Models を Private Endpoints で閉じている場合は利用できないはずです。ネットワークの制限がある場合はこれまで通り自前実装が必要になります。
Multi-Vector Search
公式ブログなどでは全く触れられていないのですが、Vector Search の機能追加として Multi-Vector Search が Preview となっているようです。ドキュメントは Build 2026 のタイミングで追加されていました。
あまりこの辺りは詳しくないので、どのようなシナリオで使うべきなのかイメージが無いのですが、公式情報がもう少し出てくるのを期待したいです。
Distributed Transactions
Cosmos DB は SQL Database のような RDB とは異なり、完全なトランザクションは実現出来ないため強い整合性が必要なデータの場合は、埋め込みを利用して 1 つの項目にまとめる必要がありました。それから Transactional Batch という 1 リクエスト内でアトミックな処理を実現出来る機能が追加されましたが、同じ Container 内の同じ Partition Key の場合のみ利用できるという強い制約があります。
今回の Distributed Trasactions では異なる Container の異なる Partition Key に対してもアトミックな処理が行えるようになりました。同一 Cosmos DB アカウント内であれば利用できるという柔軟性があります。
1 つの Distributed Transaction に含められるのは 100 の処理と 2MB 以下のペイロードとなっているので、処理としては 1 リクエストで収まる範囲ということのようです。このあたりの制約は Transactional Batch とほぼ同じなので、仕組みとしては近い可能性があると思っています。
Safe Key Rotation
名前からはどのような機能か想像しにくいと思いますが、Cosmos DB に 2 つ用意されているアクセスキーが最後にいつ使われたのかを確認できる機能が追加されています。
それぞれのキーが最後にいつ使われたのかが確認できるので、キーのローテーションを使われていないことを確認して実行できるようになります。Entra ID への切り替えに伴うローカル認証の無効化も、抜け漏れなく安全に実施できる地味ですが重要な機能です。
現在 Features に Safe Key Rotation が出てきていないのでまだ確認できていませんが、数日以内に出てくると思います。
Soft Delete
Cosmos DB はデータであれば継続的バックアップを使えば任意のタイミングに戻すことが出来ますが、Database や Contianer を削除してしまうと基本は戻せないため管理には気を使う部分です。Azure Storage は全体的に Soft Delete が実装されているので Container を削除しても、簡単に戻すことが出来るのですが同様の機能が Cosmos DB にも実装されました。
デフォルトの保持期間は 1 日ですが、設定で 30 日まで伸ばすことが可能になっています。注意点としては Soft Delete を有効化した場合で Database や Container を削除した場合は、それぞれの RU とストレージサイズで課金は継続されることです。完全に削除するまでは課金が続くので、あまり長くしすぎてもコスト面での問題が出てきますし、完全に削除するまでは同名で作成できないので、デフォルトの 1 日が無難な値だと思います。
Azure Backup での Vaulted Backup
Cosmos DB は組み込みでバックアップ機能は用意されていますが、データの意図しない削除などへの対応向けで、Cosmos DB 全体のバックアップという用途向けではないです。そういったバックアップは Azure では Azure Backup が担っていますが、今回 Vaulted Backup が Preview になったので実現可能になりました。
Azure Portal に Vaulted Backup の項目が追加されているので、ここから設定を行えば Cosmos DB アカウント単位でのバックアップが可能になります。コストは Azure Backup として 7/1 から掛かるようになりますが、今月中は無料のようです。
Azure Backup に対応したことで Azure Storage などと同じような形で Cosmos DB をバックアップ出来ますし、組み込みのバックアップとは異なりスナップショットとして長期間保持することが可能です。
