Cosmos DB for MongoDB vCore ― collection‑level schema validator

vCore のコレクションに $jsonSchema を付けて動きを確かめていくと、MongoDB の感覚で期待する反応と、Cosmos 側の公開仕様の間に少し距離があるのが分かる。まずは仕様で確認できる範囲を固めておかないと、挙動をどう扱うか判断しづらい。公開されている情報だけを基準にして、どこまでが“使える”とみなせるのかを整理しておく。

Cosmos DB for MongoDB vCore は MongoDB 互換 API を提供するが、MongoDB の全機能をそのまま提供するわけではない、という点は公式に明記されている。サポート範囲はサービス側の実装に依存し、ユーザーが Preview を切り替える仕組みもない。ここがまず前提になる。そのうえで、collection‑level の $jsonSchema validator が vCore でサポートされている、という記述は公開仕様のどこにも見当たらない。書き込み時の schema enforcement が利用可能である、という情報も同様に確認できない。つまり、MongoDB の validator がそのまま動く、という前提は公式には保証されていない領域になる。

実際に作業していると、この“仕様に書かれていない部分”がそのまま挙動に出る。createCollection に validator を付けても、collMod で validator を更新しても、書き込み時に弾かれる動きは返ってこない。MongoDB のような enforcement の反応がなく、静かなまま処理が進む。公開仕様に記述がない以上、ここは“まだサポートされていない”と判断するしかない。

一方で、読み取り側の動きは素直で、クエリの流れは普通に通る。MongoDB 互換 API の範囲で動いている部分と、まだサービス側で公開されていない部分の境界がそのまま見える。仕様に書かれていない部分を深読みしても意味がないので、観測した挙動は挙動として扱い、設計の前提には置かない方が安全になる。vCore はフルマネージドで、ユーザーが機能公開を操作する手段はない。サポート範囲はサービス側の更新に従う形になるため、アプリ側のスキーマ検証は引き続き必要になる。検証用の小さな DB を横に置いて、スキーマのズレを早めに拾う運用は現実的で、仕様の空白を埋める手段としては十分に機能する。

Cosmos DB for MongoDB vCore の $jsonSchema validator は、公開仕様にサポートが明記されていない領域にあり、書き込み時の enforcement も同様に情報がない。MongoDB と同じ動作を前提にすると設計が崩れるため、アプリ側の検証を主軸にし、仕様に書かれている範囲だけを前提に組み立てる方が安定する。触っていると“開いている層”と“まだ沈黙している層”の境界が見えるが、仕様に載っていない部分は観測した事実として扱い、判断の根拠にはしない方がいい。