第1回 問題集（全般）

正解: B. B. 関連する複数エンティティを同一パーティションキー配下でまとめて読み取り・更新できる

正解の根拠・詳細解説

単一コンテナーに関連エンティティをまとめてパーティションキーを揃えることで、1回のクエリやトランザクションバッチ操作でまとめて取得・更新できる。Cosmos DBはクロスパーティションJOINを提供せず、スループット・インデックスポリシーはコンテナー単位で適用される。

正解: B. B. 親エンティティと子エンティティが常に一緒に読み取られ、子の数が少なく増加しない場合

正解の根拠・詳細解説

埋め込み型は1回の読み取りで関連データを取得できる利点があるが、ドキュメントサイズの上限（2MB）や無制限に増加する配列はアンチパターンとなる。常に一緒に読み取られ件数が安定しているデータに向く。

正解: B. B. 読み取り時の追加クエリやJOINを避け、読み取りパフォーマンスを向上させるため

正解の根拠・詳細解説

非正規化はストレージ使用量や更新時の整合性維持コストを増やす代わりに、読み取り時に複数ソースを結合する必要をなくし、読み取りレイテンシとRUコストを削減する。

正解: B. B. 参照先エンティティが多数の親から共有され、頻繁に単独更新される場合

正解の根拠・詳細解説

多対多の関係や、共有されて単独で頻繁に更新されるエンティティは、重複更新の手間を避けるため参照型（IDで関連付け、アプリ側で複数回読み取り）が適している。

正解: B. B. 書き込み・読み取りのワークロードを均等に分散させ、ホットパーティションを避けられる値であること

正解の根拠・詳細解説

パーティションキーはコンテナー作成後に変更できないため、ワークロードを論理パーティション間に均等分散しスループットのボトルネック（ホットパーティション）を避けられる値（カーディナリティが高く、アクセス頻度が偏らないもの）を選ぶ必要がある。

正解: B. B. 複数プロパティを連結した合成（シンセティック）パーティションキーまたは階層型パーティションキーを使用する

正解の根拠・詳細解説

単一プロパティでは分散が不十分な場合、複数プロパティを連結した合成パーティションキーや、最大3階層までの階層型パーティションキー（Hierarchical Partition Keys）を使うことで、より細かい粒度の分散とクエリの効率化が可能になる。

正解: C. C. 同一の論理パーティションキー値の中で一意である必要がある（パーティションキーとidの組み合わせで一意）

正解の根拠・詳細解説

`id` は同一パーティションキー値を持つドキュメント群の中で一意であればよく、パーティションキーとidの組み合わせが実質的な一意キーとなる。異なるパーティションキー値の間では同じidを使用できる。

正解: B. B. 適切なパーティションキーやインデックスポリシー、データモデルを設計するための基礎情報を得るため

正解の根拠・詳細解説

どのクエリが多いか、どのプロパティで絞り込み・並び替えするかを把握することで、最適なパーティションキー、インデックスポリシー、データモデル（埋め込み/参照）の設計判断ができる。

正解: C. C. デフォルトでは無期限保持だが、アイテム単位で個別にTTLを指定すれば自動削除が有効になる

正解の根拠・詳細解説

コンテナーのdefaultTtlを-1に設定すると、コンテナー全体としては無期限保持がデフォルトになるが、アイテムごとに ttl プロパティを明示的に指定すればそのアイテムだけ自動削除を有効化できる。

正解: B. B. バージョン番号や日時をidまたはプロパティに含めた別ドキュメントとして保存し、type識別子で区別する

正解の根拠・詳細解説

各バージョンを個別ドキュメントとして保存し、discriminator（種別）プロパティやバージョン番号を持たせることで、同一コンテナー内に履歴を保持しつつ最新版を判別できる設計が一般的。

正解: B. B. parentId（親への参照）プロパティを各ノードに持たせ、必要に応じて再帰的にクエリする、または非正規化してパス情報を持たせる

正解の根拠・詳細解説

親への参照（parentId）を持たせて再帰的にたどる方法や、ノードごとに祖先パスを非正規化して保持する方法（マテリアライズドパス）が、ドキュメント指向DBでの階層表現の代表的な手法。

正解: C. C. 2MB

正解の根拠・詳細解説

Azure Cosmos DBの1アイテムあたりの最大サイズは2MBである。これを超える可能性があるデータは別ドキュメントに分割するか、Blob Storage等の外部ストレージへの参照に切り替える設計が必要。

正解: B. B. テナントIDをパーティションキー（または合成パーティションキーの一部）に含め、共有コンテナーでテナントを論理的に分離する

正解の根拠・詳細解説

テナントIDをパーティションキーに含めることで、共有コンテナー内でテナントごとのデータを論理的に分離しつつ、スループットやコストを共有リソースとして効率的に管理できる。専用アカウント方式はコストが高くなる。

正解: B. B. デバイスIDなどをパーティションキーとし、時間粒度ごと（例：1時間単位）にドキュメントを分割して書き込み・TTLで古いデータを自動削除する

正解の根拠・詳細解説

デバイスID等を分散キーにしつつ、時間粒度でドキュメントをロールアップ/分割することでアイテムサイズ肥大化を防ぎ、TTLで古いデータの保持期間を自動管理できる。単一巨大ドキュメントへの無制限追記は2MB上限に抵触するリスクがある。

正解: B. B. アプリケーションのアクセスパターンを分析し、JOINを多用するクエリを非正規化・埋め込みで解決できるよう再設計する

正解の根拠・詳細解説

NoSQLへの移行では、リレーショナルの正規化構造をそのまま持ち込むとJOINができず非効率になるため、実際のアクセスパターンに基づいて非正規化・埋め込み・参照を適切に組み合わせた再設計が必須。

正解: B. B. データベース内の最大25コンテナー（既定値）でRU/sを共有し、コンテナー間でスループットが動的に分配される

正解の根拠・詳細解説

データベースレベルでRU/sを共有すると、配下のコンテナー群（既定の上限あり）でスループットがプールされ、アクセス頻度の偏りに応じて動的に分配される。小規模で多数のコンテナーがある場合にコスト効率が良い。

正解: B. B. 書き込み・読み取りが特定の少数の値に集中する（ホットスポットになりやすい）

正解の根拠・詳細解説

特定の値（例：ステータス「有効」など値の種類が少なく偏在するプロパティ）をパーティションキーにすると、一部の論理パーティションに負荷が集中するホットパーティション問題が発生しやすい。

正解: B. B. アプリケーションの進化に応じてドキュメント構造を段階的に変更でき、異なるバージョンのドキュメントが混在しても柔軟に扱える

正解の根拠・詳細解説

スキーマレスなドキュメントモデルでは、アプリケーションの仕様変更に応じて新旧バージョンのドキュメント構造が同一コンテナー内に混在しても、アプリケーション側で吸収しながら段階的に移行できる柔軟性がある。

正解: B. B. 子データが多数の異なる親エンティティから共有され、独立して頻繁に更新される

正解の根拠・詳細解説

共有・独立更新されるデータを埋め込むと、更新のたびに参照しているすべてのドキュメントを更新する必要が生じ整合性維持コストが跳ね上がる。このようなケースは参照型で持つ方が適している。

正解: B. B. ドキュメントサイズが2MB上限に近づき、更新のたびに全体を書き直すコストが増大する

正解の根拠・詳細解説

無制限増加配列を埋め込むと、ドキュメントが肥大化して2MB上限へ近づくほか、わずかな追記でもドキュメント全体の再書き込みが発生しRU消費と整合性管理コストが増大する。

正解: B. B. パーティション間をまたぐ自動的なJOIN処理

正解の根拠・詳細解説

Cosmos DB for NoSQLはクロスパーティションのJOINを提供していない。JOINに似た構文はあるが、それは同一ドキュメント内の配列要素を展開するためのものであり、複数パーティション間の結合ではない。

正解: B. B. type（または同様の名前のディスクリミネーター・プロパティ）

正解の根拠・詳細解説

`type`（あるいは`docType`等）のようなディスクリミネーター・プロパティをドキュメントに持たせることで、クエリ時やアプリケーションロジックでエンティティタイプを判別できるようにする設計が一般的。

正解: C. C. 顧客ID（customerId）

正解の根拠・詳細解説

最も頻繁なアクセスパターン（顧客IDによる注文一覧取得）に合わせてパーティションキーを顧客IDにすることで、そのクエリが単一パーティション内で完結し、クロスパーティションクエリのコストを避けられる。

正解: B. B. パーティションキーは作成後に変更できないため、新しいパーティションキーを持つ新規コンテナーを作成しデータを移行する必要がある

正解の根拠・詳細解説

パーティションキーはコンテナー作成時に固定され、後から変更することはできない。変更が必要な場合は新しいコンテナーを作成し、データ移行（Change Feedやバルク操作等）を行う必要がある。

正解: B. B. 3階層まで

正解の根拠・詳細解説

階層型パーティションキーは最大3階層（例：テナントID→ユーザーID→セッションIDなど）まで指定でき、より細かい粒度でのデータ分散と、サブセットによる効率的なクエリ実行が可能になる。

正解: B. B. コメントを別ドキュメントとし、記事IDを参照プロパティとして持たせ、記事IDをパーティションキー（または合成キーの一部）に含める

正解の根拠・詳細解説

数千件に達する可能性がある一対多データは埋め込むとドキュメントサイズ上限に抵触するリスクが高い。別ドキュメント化し、記事IDをパーティションキーに含めることで関連コメントを同一パーティションにまとめつつサイズ制約を回避できる。

正解: B. B. 同一の論理パーティション内で、指定したプロパティ（群）の値の重複を防止するため

正解の根拠・詳細解説

ユニークキーポリシーは同一論理パーティション内で指定プロパティの値が重複しないことを保証する制約であり、例えばメールアドレスの重複登録防止などに利用される。コンテナー作成時にのみ設定可能。

正解: B. B. データ更新時に複数箇所を整合的に更新する複雑さとストレージコストが増える

正解の根拠・詳細解説

非正規化（重複保持）は読み取り効率を高める一方、同じ情報を持つ複数ドキュメントを更新時にすべて同期させる必要があり、整合性維持の複雑さとストレージ使用量の増加というトレードオフを伴う。

正解: B. B. `{テナントID}\_{日付}` のように複数のプロパティ値を文字列連結したものをキーにする

正解の根拠・詳細解説

合成パーティションキーは複数プロパティの値を連結した文字列を新たなプロパティとして作成し、それをパーティションキーパスに指定する手法で、単一プロパティでは分散が不十分な場合に有効。

正解: B. B. idの一意性を保ちつつ、idだけでエンティティタイプを判別しやすくするため

正解の根拠・詳細解説

プレフィックス付きIDはidの一意性確保に加え、ログやデバッグ時、あるいはポイント読み取り時にidの文字列だけでエンティティタイプを識別しやすくする実践的なパターン。

正解: B. B. アプリケーション側で参照先のidとパーティションキーを使って別途クエリ（または複数回のポイント読み取り）を実行する必要がある

正解の根拠・詳細解説

Cosmos DBはクロスドキュメント・クロスパーティションのJOINをネイティブにサポートしないため、参照型モデリングではアプリケーションコード側で複数回のクエリ（fan-outパターン）を実行して関連データを組み立てる必要がある。

正解: B. B. 読み取り効率を優先し、非正規化（データの重複埋め込み）を積極的に採用する

正解の根拠・詳細解説

読み取りが多いワークロードでは、書き込み時の同期コストを多少払ってでも非正規化により読み取り時のクエリ数・RUコストを削減する設計判断が合理的になる。

正解: B. B. ドキュメントにスキーマバージョン番号プロパティを持たせ、アプリケーション側で読み取り時にバージョンに応じた変換ロジックを適用する

正解の根拠・詳細解説

スキーマレスDBではスキーマ変更時に既存データを一括変換する必要がない代わりに、アプリケーション側でバージョン番号を見て適切な読み取り変換（アップキャスト）ロジックを実装する責任がある。

正解: B. B. 常に当日の日付（YYYY-MM-DD）のみを使う値

正解の根拠・詳細解説

「当日の日付のみ」のように値の種類が極端に少なく、しかもある期間（その日のうち）はすべての書き込みが同一値に集中するキーは、書き込みが単一の論理パーティションに集中するホットパーティションを引き起こしやすい。

正解: B. B. 親子に関わるすべてのドキュメントが同一の論理パーティションキー値を持つこと

正解の根拠・詳細解説

トランザクションバッチ（TransactionalBatch）は同一の論理パーティションキー値を持つ操作群に対してのみ適用できるため、トランザクション境界を意識したデータモデリングでは親子関連ドキュメントのパーティションキーを揃える必要がある。

正解: B. B. 巨大な配列を1つのドキュメントに無制限に追記し続ける

正解の根拠・詳細解説

巨大配列への無制限追記は、ドキュメントサイズの2MB上限への抵触リスクと、わずかな更新ごとに全体再書き込みが必要になるパフォーマンス問題を引き起こすため、典型的なアンチパターンとされる。

正解: B. B. 更新頻度が大きく異なるデータは分離し、頻繁に変わるデータ（在庫数など）は別ドキュメントにして更新コストを抑える

正解の根拠・詳細解説

更新頻度が大きく異なるデータを1つのドキュメントにまとめると、低頻度更新のデータも高頻度更新のたびに再書き込みされコストが増加する。更新頻度の違いに応じてドキュメントを分離するのが効率的。

正解: B. B. idは文字列で、255バイト以下である必要がある

正解の根拠・詳細解説

idプロパティは文字列型で最大255バイトという制約がある（一部の特殊文字も使用不可）。ユーザーが明示的に指定することも、未指定時にシステムがGUIDを自動生成することも可能。

正解: B. B. 読み取り頻度・書き込み頻度・許容できる整合性の遅延のバランス

正解の根拠・詳細解説

非正規化の採用判断は、読み取りと書き込みそれぞれの頻度、および重複データ間でどの程度の整合性遅延（結果整合性）が許容できるかのバランスを評価して行う。

正解: B. B. 学生・講座それぞれを独立したドキュメントとして持ち、関連を表す中間ドキュメント（エンロールメントなど）を別途作成して両方のIDを参照する

正解の根拠・詳細解説

多対多関係は、双方を独立したエンティティとして保持し、関連自体を表す中間ドキュメント（エンロールメント等）を作ることで、件数の増加にも柔軟に対応できるモデリングが一般的。

正解: B. B. 各セッションドキュメントに ttl: 1800（秒）を明示的に設定する

正解の根拠・詳細解説

TTLは秒単位で指定し、30分後に自動削除したい場合はドキュメントに `ttl: 1800` を設定する（コンテナーのdefaultTtlが有効になっている前提）。これによりCosmos DBのバックグラウンドプロセスが期限切れアイテムを自動削除する。

正解: A. A. idとパーティションキーの両方を指定して1件を直接取得する、最も低コストな読み取り方法

正解の根拠・詳細解説

ポイント読み取りはidとパーティションキー値を指定して特定の1アイテムを直接取得する操作で、クエリエンジンを経由しないため一般的に最も低RUコスト・低レイテンシな読み取り方法となる。

正解: A. A. 想定される主要なアクセスパターンを複数列挙し、それぞれの頻度を見積もった上でモデルを設計する

正解の根拠・詳細解説

想定される複数のアクセスパターンとその頻度を事前に分析し、最も重要なパターンに最適化しつつ、他のパターンにも一定の柔軟性を持たせる設計アプローチが推奨される。

正解: A. A. IoTデバイスの種類ごとに異なるテレメトリプロパティを持つドキュメントを同一コンテナーに混在させる

正解の根拠・詳細解説

スキーマレス性を活かし、デバイス種類ごとに異なるプロパティ構成を持つテレメトリデータを同一コンテナーに混在保存し、アプリケーション側でtypeプロパティ等を使い分けて処理する設計がよく使われる。

正解: B. B. エンティティとその関係を洗い出し、アクセスパターンを分析した上で、埋め込み/参照/非正規化の方針とパーティションキーを決定する

正解の根拠・詳細解説

効果的なモデリングは、まずドメインのエンティティと関係を理解し、実際のアクセスパターンを分析した上で、それに基づいて埋め込み/参照/非正規化の方針とパーティションキーを決定する順序が推奨される。

正解: B. B. 大きなバイナリファイルはAzure Blob Storageに保存し、Cosmos DBドキュメントにはURLや参照情報のみを保持する

正解の根拠・詳細解説

Cosmos DBの1ドキュメント（アイテム）には2MBというサイズ上限があり、画像や動画などのバイナリをBase64エンコードして埋め込むと、エンコードによって元データより約33%サイズが増えるため、この上限に容易に到達します。さらにCosmos DBの課金単位であるRUはアイテムサイズにほぼ比例するため、巨大なドキュメントは読み取り・書き込みのたびにRUを浪費し、インデックス作成のコストやレイテンシも悪化します。そのため大容量バイナリはAzure Blob Storageなどのオブジェクトストレージに置き、Cosmos DB側にはBlobのURLやコンテナー名・ファイル名といった参照とメタデータだけを保持する設計が定石です。こうしておけばドキュメントは小さく保たれ、クエリはメタデータだけを高速に絞り込め、実データはCDNやSAS付きURL経由でクライアントへ直接配信できます。なおTTLはアイテムを一定時間後に自動削除する機能であり、データを圧縮する機能ではありません。

正解: B. B. ユーザーに地理的に近いリージョンから低レイテンシでアクセスさせ、可用性を高めるため

正解の根拠・詳細解説

複数リージョンへのグローバル分散により、ユーザーに地理的に近いリージョンからのアクセスでレイテンシを低減し、リージョン障害時のフェイルオーバーによって高可用性を実現できる。

正解: B. B. 設定されたすべての書き込みリージョンで同時に書き込みを受け付けられ、各リージョンが独立して書き込みを処理する

正解の根拠・詳細解説

マルチリージョン書き込み（multi-region writes）を有効にすると、構成された複数のリージョンすべてが書き込みエンドポイントとなり、各リージョンでローカルに書き込みを受け付けられるため、グローバルな書き込みレイテンシを低減できる。

正解: B. B. コンフリクト（競合）が発生し、設定された競合解決ポリシーに基づいて解決される

正解の根拠・詳細解説

マルチリージョン書き込み構成では複数リージョンからの同時更新によりコンフリクトが発生する可能性があり、Last-Writer-Wins（LWW）やカスタムの競合解決プロシージャといったポリシーに基づいて解決される。

正解: A. A. プロビジョニングは常に固定RU/sを事前確保し稼働状態にかかわらず課金され、サーバーレスはリクエストごとの消費RUに対してのみ課金される

正解の根拠・詳細解説

プロビジョニングされたスループットは事前に確保したRU/sに対して使用量に関わらず課金されるが、サーバーレスは実際に消費したリクエストユニット分のみ課金される、間欠的・予測困難なワークロードに適したモデル。

正解: A. A. 設定した最大RU/sと、その10%（最小値）の間で自動的にスケールし、実際に消費されたピークRU/sに基づいて課金される

正解の根拠・詳細解説

自動スケールは設定した最大RU/s（Tmax）とその10%にあたる最小値の範囲内で需要に応じて自動的にスケールし、その時間枠で実際に到達した最高RU/sに基づいて課金されるため、変動の大きいワークロードに適している。

正解: B. B. 追加した読み取りリージョン内のクライアントが低レイテンシでデータを読み取れるようになる

正解の根拠・詳細解説

読み取りリージョンを追加すると、そのリージョンに近いクライアントからの読み取り要求を低レイテンシで処理できるようになる。書き込みは（マルチリージョン書き込みが有効でない限り）依然として書き込みリージョンに送られる。

正解: B. B. 書き込みリージョンで障害が発生した場合に、どのリージョンへ自動的にフェイルオーバーするかの順序を制御するため

正解の根拠・詳細解説

リージョンの優先順位リストを設定しておくことで、現在の書き込みリージョンで障害が発生した際にAzureが自動フェイルオーバーする先のリージョンの順序を制御できる（自動フェイルオーバーが有効な場合）。

正解: B. B. 既存データを含むコンテナー全体が新リージョンへバックグラウンドでシームレスにレプリケートされ、ダウンタイムなしで利用可能になる

正解の根拠・詳細解説

Azure Cosmos DBはリージョン追加をオンラインで行い、既存データはバックグラウンドでシームレスにレプリケートされるため、アプリケーションのダウンタイムなしで地理的分散を拡張できる。

正解: B. B. 複数の論理パーティションが1つの物理パーティションにマッピングされ、Cosmos DBが内部的にデータと負荷に応じて物理パーティションの分割・統合を自動管理する

正解の根拠・詳細解説

論理パーティションは同じパーティションキー値を持つアイテムの集合であり、物理パーティションはそれらを実際に格納するストレージとコンピュートのまとまりです。両者は1対1ではなく、通常は多数の論理パーティションが1つの物理パーティションにマッピングされます。Cosmos DBはデータ量やプロビジョニングされたスループットの増加を検知すると、物理パーティションの分割（スプリット）を内部で自動的に実行し、論理パーティションを新しい物理パーティションへ再配置します。この処理はサービス側で透過的に行われ、利用者が物理パーティションを手動で作成・削除することはできません。利用者が制御できるのはパーティションキーの選択であり、カーディナリティが高く値の分布が偏らないキーを選ぶことが重要です。特定のキーにアクセスが集中すると、その論理パーティションを抱える物理パーティションだけがRU上限に達してスロットリング（429）を起こす、いわゆるホットパーティションが発生します。

正解: B. B. コンテナー内で作成・更新されたアイテムの変更を、発生順（パーティションキー内で順序保証）でストリームとして取得できる仕組み

正解の根拠・詳細解説

変更フィードは挿入・更新されたアイテムの変更を、各論理パーティション内での発生順序を保つ形でストリームとして読み取れる仕組みで、追加のAzure FunctionsトリガーやChange Feed Processorライブラリから利用できる。

正解: B. B. Cosmos DBコンテナーへの変更（変更フィード）を検知して、別のAzureサービス（Event Hubsなど）にイベントを連携・処理する

正解の根拠・詳細解説

Cosmos DBトリガー付きのAzure Functionsは変更フィードを購読し、新規・更新アイテムを検知して別システムへのイベント連携、通知処理、集計処理などを自動実行する統合パターンの基盤となる。

正解: B. B. 元データへの変更を検知し、関連する複数のドキュメントへ自動的に変更内容を反映するFunctionを実行することで、非正規化されたコピーを最新の状態に保つ

正解の根拠・詳細解説

変更フィードをトリガーにしたAzure Functionsで、元データの更新を検知し、非正規化して保持している関連ドキュメント群を自動的に同期更新する仕組みを構築でき、整合性維持を自動化できる。

正解: A. A. 参照先ドキュメントが削除された際に、関連する他ドキュメントの参照プロパティを自動更新・クリーンアップするFunctionを実行する

正解の根拠・詳細解説

Cosmos DBはリレーショナルDBのような外部キー制約を持たないため、変更フィードで親エンティティの変更・削除を検知し、関連ドキュメントの整合性をアプリケーションロジック（Functions等）で能動的に維持する設計が必要になる。

正解: B. B. トランザクションストアに加えて分析ストアを有効化し、ETLパイプラインなしでほぼリアルタイムに大規模分析クエリ（Synapse Spark/SQL）を実行できるようにする

正解の根拠・詳細解説

Synapse Linkは分析ストア（列指向ストレージ）をコンテナーに対して有効化し、トランザクションワークロードに影響を与えずにETLパイプラインを構築せずSynapse Spark/SQLからほぼリアルタイムで分析クエリを実行できるようにする統合機能。

正解: B. B. Cosmos DB MirroringはMicrosoft Fabricに対するアプローチで、Spark connectorはSynapse Analytics環境からアクセスする際の選択肢の一つであり、要件に応じて使い分ける

正解の根拠・詳細解説

Microsoft Fabricへの統合にはCosmos DB Mirroringが提供され、Synapse Analytics環境ではSpark connectorやSynapse SQLからの分析ストアアクセスが選択肢となる。要件（リアルタイム性、利用環境）に応じて適切な方式を選ぶ。

正解: B. B. トランザクションワークロードに追加のRUコストをかけずに、分析クエリ用の別ストレージ（列指向）へほぼリアルタイムで自動同期される

正解の根拠・詳細解説

分析ストアはトランザクションストアとは独立した列指向ストレージで、有効化するとトランザクション側のRUに負荷をかけずバックグラウンドでほぼリアルタイムに同期され、大規模分析を低コストで実行できる。

正解: B. B. 古いデータの変更を検知し、別のストレージ（例：Blob StorageやセカンダリのCosmos DBコンテナー）へ自動的にコピー・移動するFunctionを構築する

正解の根拠・詳細解説

変更フィードをトリガーとして、特定の条件（古いデータ、アクセス頻度の低下など）を満たすデータを安価なストレージ（Blob Storageなど）へ自動的にコピー・移動するアーカイブパイプラインを構築できる。

正解: B. B. 変更フィードをトリガーとするAzure Functionが変更内容を受け取り、Event Hubsへイベントとして送信し、複数の下流システムがそれを購読する

正解の根拠・詳細解説

変更フィード（Change Feed）は、コンテナーへの挿入と更新を論理パーティションごとに順序を保った形で記録し続ける仕組みで、これをトリガーとするAzure Functionsを配置すると、アプリケーション側でポーリング処理を書かなくても変更を受け取れます。Functionsのトリガーは内部で変更フィードプロセッサーとリースコンテナーを使い、複数インスタンスへの負荷分散と処理位置のチェックポイントを自動的に管理します。受け取った変更をEvent Hubsへパブリッシュすると、下流の各システムはコンシューマーグループ単位で独立して購読でき、送信側と受信側が疎結合になるうえ、リアルタイム分析・監査ログ・キャッシュ更新など用途の異なる処理を後から並行して追加できます。Cosmos DBのリージョン間レプリケーションはデータのコピーを複数リージョンに保持する機能であり、外部システムへイベントを配信する用途には使えない点に注意してください。

正解: B. B. すべてのプロパティ（ワイルドカードパス `/\*`）に対して自動的にインデックスが作成される

正解の根拠・詳細解説

Cosmos DB for NoSQLのデフォルトインデックスポリシーは、すべてのプロパティに対するワイルドカードパス`/\*`を自動的にインデックス化する「automatic indexing」が有効になっている。

正解: B. B. 書き込み時のインデックス更新コスト（RU）を削減し、ストレージ使用量も抑えるため

正解の根拠・詳細解説

フィルタやソートに使われないプロパティをインデックスから除外すると、書き込み時にそのプロパティ分のインデックス更新処理が不要になり、書き込みRUコストとインデックス用ストレージを削減できる。

正解: B. B. 複数プロパティでの ORDER BY、または複数プロパティを組み合わせた等価フィルタとソートを行うクエリ

正解の根拠・詳細解説

複合インデックスは、複数プロパティを組み合わせたORDER BYや、複数条件によるフィルタ＋ソートを行うクエリのパフォーマンスを大幅に改善する。単純な単一プロパティのクエリには通常のレンジインデックスで十分。

正解: B. B. リクエストチャージ（Request Charge、消費RU数）

正解の根拠・詳細解説

各クエリ・操作のレスポンスに含まれる「リクエストチャージ（消費RU数）」を確認することで、クエリやインデックス設計の効率性を評価し、最適化の余地を判断できる。

正解: B. B. OFFSETで指定した件数分のドキュメントを内部的にスキップして読み進める必要があり、大きなOFFSETほどRUコストが増加する

正解の根拠・詳細解説

OFFSET LIMITはスキップする件数分のアイテムも内部的に処理対象としてカウントするため、大きなOFFSET値になるほど読み飛ばし処理のコストが増加する。継続トークン（Continuation Token）を使ったページングがより効率的。

正解: B. B. 前回のクエリの停止位置から効率的に次ページを取得でき、大きなOFFSET値によるRUコスト増加を避けられる

正解の根拠・詳細解説

継続トークンは前回の取得位置を示す情報をクライアントが保持し、次回のクエリ実行時にその位置から再開するため、OFFSETのような読み飛ばし処理が発生せず効率的なページングが可能になる。

正解: B. B. 1回のラウンドトリップで取得する件数や並列実行するパーティション数を調整し、レイテンシとスループットのバランスを最適化するため

正解の根拠・詳細解説

ページサイズや並列度（MaxConcurrency等）を調整することで、ネットワークラウンドトリップ数とクライアント側のメモリ使用量、レイテンシのバランスを、ワークロードの特性に応じて最適化できる。

正解: B. B. 可能な限りWHERE句にパーティションキーを含め、クエリが単一（または少数の）パーティションに絞り込まれるようにする

正解の根拠・詳細解説

クエリ条件にパーティションキーを含めることで、Cosmos DBはそのクエリを対象パーティションのみに絞り込んで実行でき、すべての物理パーティションをスキャンするクロスパーティションクエリのコストを回避できる。

正解: B. B. 頻繁に読み取られる同一クエリ/ポイント読み取りの結果をキャッシュし、バックエンドへのRU消費を抑えながら低レイテンシな読み取りを実現する

正解の根拠・詳細解説

Integrated Cache（専用ゲートウェイ経由）は、繰り返し実行される同一クエリやポイント読み取りの結果をキャッシュすることで、バックエンドのRU消費を抑えつつ読み取りレイテンシを改善する機能。

正解: B. B. 大量のドキュメントをまとめて挿入・更新する際に、内部的にリクエストをグループ化してスループットを最大化したい場合

正解の根拠・詳細解説

バルク実行モードは大量データの一括投入・更新時に、SDK内部で複数操作をグループ化・並列化することでスループットを最大化し、効率的にRUを使い切れるように設計された機能。

正解: B. B. JavaScript

正解の根拠・詳細解説

Cosmos DB for NoSQLのサーバーサイドプログラミング（ストアドプロシージャ・プレ/ポストトリガー・UDF）はJavaScriptで記述され、コンテナーに登録して実行する。

正解: B. B. 単一の論理パーティション内でのみ実行され、実行時間にも上限（既定では数秒程度）がある

正解の根拠・詳細解説

ストアドプロシージャは単一の論理パーティション内でのみ実行可能であり、トランザクション境界もパーティション内に限定される。また実行時間にも制限があり、長時間処理には不向き。

正解: B. B. SELECT \* を多用し不要なプロパティまで毎回取得する

正解の根拠・詳細解説

`SELECT \*` で不要なプロパティまで取得し続けると、ネットワーク転送量やクライアント処理のオーバーヘッドが増加する。必要なプロパティのみを指定するプロジェクションがパフォーマンスとコストの両面で有利。

正解: B. B. 同一リージョン内のデータセンター障害に対する耐性を高め、高可用性を実現するため

正解の根拠・詳細解説

アベイラビリティゾーンを利用することで、同一リージョン内の物理的に分離されたデータセンター間でデータをレプリケートし、データセンター単位の障害に対する耐障害性を高めることができる。

正解: C. C. 地理空間データ（緯度経度など）に対する距離・範囲検索

正解の根拠・詳細解説

空間インデックスはGeoJSON形式で格納された地理空間データに対して、近接検索や範囲検索（ST\_DISTANCEやST\_WITHINなど）を効率的に実行するために使用される。

正解: B. B. TCP接続でバックエンドのレプリカと直接通信し、Gatewayモードよりも低レイテンシ・高スループットを実現しやすい

正解の根拠・詳細解説

Directモード（TCPプロトコル）はゲートウェイを経由せずバックエンドレプリカと直接通信するため、ゲートウェイモード（HTTPS）よりも低レイテンシ・高スループットが期待できる、サーバーサイドアプリケーションで推奨される接続方式。

正解: B. B. そのプロパティへのインデックスパスを確実に含め、必要であれば複合インデックスも検討する

正解の根拠・詳細解説

頻繁にフィルタ・ソート条件として使われるプロパティには確実にインデックスを効かせ、複数プロパティの組み合わせが多用される場合は複合インデックスを追加することで、クエリ効率を高められる。

正解: B. B. 単一クライアント（セッション）内での読み取り一貫性を保ちつつ、強整合性よりも低レイテンシ・高可用性を実現できるバランスの良いデフォルト設定だから

正解の根拠・詳細解説

Session整合性はCosmos DBの既定の整合性レベルで、同一クライアントセッション内では自分が書き込んだ内容を必ず読み取れる一貫性を保証しつつ、Strongレベルよりも低レイテンシ・高可用性を実現できる実用的なバランスを提供する。

正解: B. B. WHERE句でサーバー側に絞り込みを行わせることで、不要なドキュメントの転送・読み取りコストを削減できるから

正解の根拠・詳細解説

クライアント側で全件取得後にフィルタする方式は、不要なデータの転送・読み取りRUを無駄に消費する。WHERE句でサーバー側に絞り込みを行わせることで、必要なデータのみを効率的に取得できる。

正解: B. B. バルク実行モードや並列処理を活用し、一時的にスループットを増強（自動スケールや手動スケールアップ）した上でインポートする

正解の根拠・詳細解説

大量データの一括投入では、バルク実行モードでの並列化に加え、インポート期間中だけスループットを一時的に増強する（その後元に戻す）ことで、RUの無駄なく短時間で処理を完了できる。

正解: B. B. インデックス利用状況や実行時間の内訳を確認し、クエリやインデックス設計のボトルネックを特定するため

正解の根拠・詳細解説

クエリメトリクスにはインデックス使用率、ドキュメント読み取り件数、VMの実行時間などの詳細な内訳が含まれ、これを分析することでクエリが非効率になっている原因（インデックス未使用など）を特定できる。

正解: B. B. 必要なクエリパターンを分析し、不要なパスをexcludedPathsで除外しつつ、必要なパスのみを残す選択的インデックスを設計する

正解の根拠・詳細解説

Cosmos DBは既定ですべてのプロパティのパスを自動的にインデックスします。これはクエリを書きやすくする一方で、書き込みのたびに全パスのインデックスを更新するため、書き込みRUとストレージ消費が増えます。インデックスポリシーはコンテナー単位のJSONで定義でき、includedPathsとexcludedPathsで対象を制御できるので、実際に実行されるクエリのWHERE句やORDER BY句で参照されるパスだけを残し、ログ本文や大きなネスト配列など検索対象にならないパスをexcludedPathsで除外するのが選択的インデックスの考え方です。これにより書き込みコストを抑えつつ必要なクエリ性能は維持できます。インデックスポリシーは運用中でも変更でき、再インデックスはバックグラウンドで進行して既存の読み書きを止めません。ただし除外したパスを検索条件に使うとスキャンとなってRUが跳ね上がるため、除外の前にクエリパターンを棚卸ししておくことが必須です。

正解: D. D. Strong

正解の根拠・詳細解説

Strong整合性はすべてのリージョンで書き込み完了後に必ず最新のコミット済みデータを読み取れることを保証する最も強いレベルだが、レイテンシと可用性のトレードオフが最も大きい。

正解: C. C. Eventual

正解の根拠・詳細解説

Eventual整合性は最終的にすべてのレプリカが同じ値に収束することのみを保証し、順序保証や即時反映の保証がない代わりに、最も低いレイテンシと最も高い可用性を提供する。

正解: B. B. 設定した時間間隔またはバージョン数の範囲内で、読み取りが書き込みより遅れることを許容しつつ、その遅れの上限を保証する

正解の根拠・詳細解説

Bounded Stalenessは、指定した「K個の操作」または「T秒」のいずれかの範囲内で読み取りの遅延（古さ）の上限を保証する整合性レベルで、Strongに近い予測可能性と高可用性のバランスを取る。

正解: B. B. 書き込みの順序通りに（一部が欠けることはあっても順序が逆転することなく）読み取れることを保証する

正解の根拠・詳細解説

Consistent Prefix整合性は、複数の書き込みがあった場合にそれらが書き込まれた順序を逆転させることなく読み取れることを保証する（一部の書き込みが反映前でも、反映済みの分は正しい順序で見える）レベル。

正解: C. C. Session

正解の根拠・詳細解説

Cosmos DBアカウント全体のデフォルトの整合性レベルはSessionであり、同一クライアントセッション内での読み取り一貫性と、実用的なレイテンシ・可用性のバランスを提供する。アカウント単位で変更可能。

正解: B. B. 可能。SDKやREST APIのリクエストオプションで、アカウントのデフォルトより弱いレベルへ一時的にオーバーライドできる（強くすることはできない）

正解の根拠・詳細解説

個々のリクエストでアカウント既定の整合性レベルより「弱い」レベルへの一時的なオーバーライドは可能（例：デフォルトStrongのアカウントでEventualへ弱める読み取りを行う）が、デフォルトより強くすることはできない。

正解: A. A. Last-Writer-Wins（LWW）（\_tsプロパティに基づく）

正解の根拠・詳細解説

デフォルトの競合解決ポリシーはLast-Writer-Wins（LWW）で、システムプロパティ`\_ts`（タイムスタンプ）に基づき、最も新しいバージョンが優先される。カスタムプロパティやマージプロシージャを使った独自ロジックも設定可能。

正解: B. B. ビジネスロジックに応じて、複数バージョンの値をマージするなど、単純な「新しい方が勝つ」以上の柔軟な競合解決ロジックを実装できる

正解の根拠・詳細解説

カスタム競合解決プロシージャ（JavaScriptで記述するマージプロシージャ）を使うことで、単純に新しい方を採用するのではなく、両バージョンの値をフィールド単位でマージするなど、業務要件に応じた柔軟な競合解決が可能になる。

正解: B. B. 過去の任意の時点（既定で過去7日間または30日間）への点復元（Point-in-time Restore）が可能になる

正解の根拠・詳細解説

継続的バックアップモードは秒単位で変更をキャプチャし、保持期間内（7日間または30日間のプラン）の任意の時点へのポイントインタイムリストアを可能にする、誤削除やデータ破損からの復旧に有効な機能。

正解: A. A. 既定では一定間隔（既定4時間ごと）でバックアップが取得され、Microsoftが管理するストレージに保持される（既定の保持期間あり）

正解の根拠・詳細解説

定期的バックアップ（既定モード）は既定で4時間ごとにスナップショットを取得し、既定で8時間（最大30日まで延長可能）の保持期間、Microsoft管理のストレージに保存される。復元には基本的にサポートチケットでの依頼が必要。

正解: B. B. マスターキー（アカウントキー）を共有する代わりに、ユーザーやサービスプリンシパル単位で最小権限のロールを割り当て、より細かいアクセス制御を実現できる

正解の根拠・詳細解説

Azure RBAC（Microsoft Entra ID認証）を利用すると、強力な権限を持つアカウントキーを配布する代わりに、ユーザーやアプリケーションごとに必要最小限のデータプレーン操作権限を割り当てることができ、セキュリティが向上する。

正解: B. B. プライベートエンドポイント（Private Endpoint）またはVNetサービスエンドポイント

正解の根拠・詳細解説

プライベートエンドポイントを使うことで、Cosmos DBアカウントへのアクセスを指定したVNet内のプライベートIPアドレス経由に限定し、パブリックインターネットからのアクセスを遮断できる。VNetサービスエンドポイントも同様にネットワーク境界での制御が可能。

正解: B. B. すべてのデータはデフォルトでMicrosoft管理キーにより自動的に暗号化され、必要に応じてカスタマー管理キー（CMK）に切り替えることもできる

正解の根拠・詳細解説

Cosmos DBに保存されるすべてのデータはデフォルトでMicrosoft管理の暗号化キーによって自動的に暗号化されており、追加の要件があればAzure Key Vaultと連携したカスタマー管理キー（CMK）への切り替えも可能。

正解: B. B. マルチリージョン構成や複数の可用性ゾーンの利用、整合性レベルの選択によって、99.99%や99.999%といった異なる可用性SLAが提供される

正解の根拠・詳細解説

Cosmos DBは構成（シングル/マルチリージョン、可用性ゾーン利用、整合性レベル）に応じて99.99%（シングルリージョン書き込み）から99.999%（マルチリージョン書き込み構成時の読み取り可用性）まで、複数段階のSLAを提供する。

正解: B. B. SDKが組み込みのリトライポリシーに基づき、指定された待機時間（retry-after）の後に自動的にリトライする

正解の根拠・詳細解説

Cosmos DB SDKには既定でリトライポリシーが組み込まれており、429（スロットリング）エラーを受け取った場合、レスポンスに含まれる推奨待機時間に基づいて自動的にリトライを行う仕組みが提供されている。

正解: B. B. リクエストごとの詳細なテレメトリ（クエリ実行内容、RU消費、レイテンシなど）を収集し、トラブルシューティングや監査に活用するため

正解の根拠・詳細解説

診断ログをLog AnalyticsワークスペースやStorage Accountへ送信することで、個々のリクエストの詳細（実行クエリ、消費RU、レイテンシ、ステータスコードなど）を可視化し、パフォーマンス分析やセキュリティ監査に利用できる。

正解: B. B. プロビジョニングされたRU/sに対して実際の消費が上限に近く、スロットリングが発生しやすい状態である

正解の根拠・詳細解説

正規化されたRU消費率は、プロビジョニングされたスループットに対する実際の使用率を示す指標で、これが100%近くで推移している場合はスロットリング（429）が発生しやすく、スケールアップやクエリ最適化の検討が必要なサインとなる。

正解: B. B. キーが漏洩した場合のリスクを軽減し、セキュリティのベストプラクティスに従うため

正解の根拠・詳細解説

アカウントキーは強力な管理者権限を持つため、定期的なローテーション（プライマリ・セカンダリの併用による無停止での切り替え）を行うことで、キー漏洩時の被害範囲やリスクを最小化するセキュリティ対策となる。

正解: B. B. 許可されていないネットワークからのデータプレーンへの不正アクセスを防止するため

正解の根拠・詳細解説

IPファイアウォールルールを設定することで、指定したIPアドレス範囲（オフィスのIPやAzureサービスのIPなど）以外からのアクセスを拒否し、不正アクセスのリスクを低減するネットワークセキュリティ対策となる。

正解: B. B. マスターキーを配布せずに、モバイル/Webクライアントなど信頼度の低いクライアントに対して、特定のリソースへの限定的かつ時間制限付きのアクセス権を発行するため

正解の根拠・詳細解説

リソーストークンは、強力な権限を持つマスターキーをクライアントに直接配布する代わりに、ミドルウェア（トークンブローカー）が発行する、特定リソースへの限定的かつ有効期限付きのアクセス権を提供する仕組みで、モバイルアプリ等のシナリオに適する。

正解: B. B. プロビジョニングされたRU/s（または自動スケールの最大値）を増加させる、またはクエリ・インデックスを最適化してRU消費自体を削減する

正解の根拠・詳細解説

スロットリングが頻発する場合は、まずRU/sの増加でキャパシティを確保するか、非効率なクエリやインデックス過多によるRU消費自体を見直して削減するという2方向のアプローチで対応するのが基本。

正解: B. B. 継続的バックアップによるポイントインタイムリストア、またはアカウントレベルでのリソースロック設定

正解の根拠・詳細解説

継続的バックアップモードを有効にしておくことで、コンテナーやデータベースの誤削除・誤更新があった場合でも、保持期間内の任意時点へ復元できる。加えてAzureリソースロックでコンテナー削除自体を防止する運用対策も併用される。

正解: B. B. 正規化されたRU消費率、スロットリング（429）発生数、サーバー側レイテンシ

正解の根拠・詳細解説

正規化RU消費率、429エラー発生率、サーバー側レイテンシといった指標にAzure Monitorアラートを設定することで、スループット不足やパフォーマンス劣化を早期に検知し、プロアクティブな対応が可能になる。

正解: B. B. データの読み取りのみを許可し、誤った書き込みや削除操作のリスクを排除したアクセス権をアプリケーションに付与するため

正解の根拠・詳細解説

読み取り専用キーを発行することで、レポーティングや分析用途のアプリケーションに対して、書き込み・削除権限を持たない最小権限のアクセスを許可し、誤操作やセキュリティリスクを低減できる。

正解: B. B. 設定された優先順位リストに基づき、Cosmos DBが自動的に次に利用可能なリージョンへ読み取りをルーティングする（自動フェイルオーバーが有効な場合）

正解の根拠・詳細解説

自動フェイルオーバーを有効にしておくと、あるリージョンが利用不可になった場合、設定済みのリージョン優先順位リストに基づきCosmos DBが自動的に次のリージョンへトラフィックをルーティングし、アプリケーションの可用性を維持する。

正解: B. B. アプリケーションの特性（レイテンシ許容度、リトライ回数の上限など）に応じて挙動を調整し、ユーザー体験やコストを最適化するため

正解の根拠・詳細解説

デフォルトのリトライ・タイムアウト設定はほとんどのケースで適切だが、超低レイテンシが求められるシナリオや、特殊なネットワーク環境などに応じて、最大リトライ回数や待機時間を調整することでアプリケーション要件に最適化できる。

正解: B. B. Azure Key Vaultに格納されたカスタマー管理キー（CMK）へのアクセスなど、他のAzureリソースへの認証をパスワード管理なしで安全に行う

正解の根拠・詳細解説

マネージドIDを使うことで、Cosmos DBアカウントがAzure Key Vault等の他のAzureリソースに対して、資格情報をコード内に保持せずに安全に認証・アクセスできるようになる（CMK利用時の鍵取得など）。

正解: B. B. トラフィックが予測困難で間欠的・低頻度ならサーバーレス、安定的または予測可能な高頻度トラフィックならプロビジョニング（自動スケール）が適している

正解の根拠・詳細解説

サーバーレスは使用量に応じた課金で間欠的・低頻度・予測困難なワークロードに向き、プロビジョニング（自動スケール含む）は安定したまたは予測可能な高トラフィックに対してコスト効率が良い。サーバーレスには一部の機能制約（マルチリージョン書き込み不可など）もある点に注意。

正解: B. B. RU消費傾向、スロットリング発生状況、ストレージ使用量、インデックスポリシーの妥当性を定期的にレビューし、必要に応じて調整する

正解の根拠・詳細解説

運用フェーズでは、RU消費やスロットリングの傾向、ストレージ増加、クエリパターンの変化に応じたインデックスポリシーの見直しなどを定期的にレビューし、コストとパフォーマンスの両面で最適な状態を維持することが推奨される。

正解: B. B. メトリクスは集計された数値（RU消費量やレイテンシの平均など）を提供し、診断ログは個々のリクエスト単位の詳細情報を提供する

正解の根拠・詳細解説

メトリクスはAzure Monitorで時系列の集計値（平均RU消費、リクエスト数など）をダッシュボードやアラートに利用するのに適し、診断ログは個々のリクエストレベルの詳細（実行クエリ文、消費RU、レイテンシ等）を記録し、詳細なトラブルシューティングに利用される。

正解: B. B. 直近で追加・変更されたクエリパターンやインデックスポリシーの変更、非効率なクロスパーティションクエリの有無

正解の根拠・詳細解説

RUコストの急増は、新しく追加されたクエリの非効率性（クロスパーティション化、インデックス未活用）、データ量の急増、インデックスポリシーの変更などが原因となることが多いため、直近の変更点を中心に調査するのが効果的。

正解: B. B. 処理をより小さなバッチに分割し、必要に応じて継続トークンのような仕組みで複数回の呼び出しに分けて実行する

正解の根拠・詳細解説

ストアドプロシージャには実行時間の制限があるため、大量データの一括更新では処理を小さなバッチに分割し、未処理分の有無を返却して呼び出し側がループ実行する設計にすることで、タイムアウトを回避しつつ確実に処理を完了できる。

正解: B. B. サーバー側レイテンシはCosmos DB内部での処理時間のみを指し、クライアント側の合計レイテンシにはネットワーク往復時間やSDKのリトライ待機時間なども含まれる

正解の根拠・詳細解説

サーバー側レイテンシはCosmos DBサービス内部での処理にかかった時間を示すのに対し、クライアントが実際に観測する合計レイテンシには、ネットワーク往復時間、SDKでのリトライ待機、シリアライズ処理なども加算されるため、両者は一致しないことが多い。

正解: B. B. 一時的な障害やスロットリングに対しては、指数バックオフなどの待機戦略を用いたリトライを実装し、永続的なエラーとは区別して処理する

正解の根拠・詳細解説

Cosmos DBで発生するエラーには、時間をおけば解消する一時的なものと、要求内容そのものに原因がある永続的なものがある。プロビジョニングしたRU/sを超過した際に返るスロットリング（HTTP 429）や、一時的なネットワーク断・タイムアウト・サービス側の一時的な利用不可は前者にあたり、少し待って再送すれば成功する可能性が高い。この待機時間を一定にせず、リトライのたびに間隔を指数的に広げる指数バックオフを用いると、多数のクライアントが同時に再送して負荷をさらに増幅させる事態を避けられる。待機を入れずに即座に再試行する方式は、混雑を悪化させて回復を遅らせるだけであり適切ではない。一方、要求の構文誤り（400）や認証・認可の失敗（401／403）は何度送っても結果が変わらないため、リトライ対象から除外して即座にエラーとして扱うべきである。なお各言語のCosmos DB SDKは、スロットリング時の自動リトライ回数や最大待機時間を設定できる仕組みを標準で備えており、リトライ処理をすべて自前で実装しなければならないわけではない。