Azure Cosmos DBのシステム開発の発注/外注/依頼/委託方法について

Azure Cosmos DBのシステム開発を発注するなら、要件定義でアクセスパターンと非機能要件を固め、開発費とAzure利用料を分けて比較することが成功の近道です。

「どの会社へ外注すればよいのか」「請負と準委任のどちらが合うのか」「費用はいくら見ておけばよいのか」と悩む担当者は少なくありません。この記事では、Azure Cosmos DBのシステムを発注・外注・委託するときの発注形態、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積書の比較方法まで、実務で確認すべき順番に沿って解説します。

▼全体ガイドの記事
・Azure Cosmos DBのシステム開発の完全ガイド

Azure Cosmos DBのシステムを発注する前に知っておく全体像

Azure Cosmos DBは、Azure上で提供されるフルマネージドの分散NoSQLデータベースです。JSONドキュメントを扱うNoSQL APIのほか、MongoDB、Cassandra、Gremlin、TableなどのAPIを選べるため、既存の知識や移行元の構成に応じて開発方式を検討できます。

会員プロフィール、商品カタログ、注文状態、セッション、チャット履歴、IoTの時系列データ、リアルタイム在庫のように、読み書きが多く、データ項目の追加や変更が頻繁な領域では候補になりやすいです。複数リージョンへのレプリケーション、マルチリージョン書き込み、複数の整合性レベル、Change Feedによるイベント連携も、グローバルサービスやイベント駆動型の業務に活用できます。

一方で、複雑なリレーションを多用する処理、自由度の高い集計帳票、厳密なトランザクションを中心にする場合は、Azure SQLなどのRDBとの役割分担が適切な場合があります。発注時は「Azureを使いたい」と先に決めるのではなく、業務上のアクセスパターンとデータの関係性を示し、Cosmos DBを採用する理由を委託先と検証することが大切です。

Cosmos DBでは、RDBのようにテーブルを正規化してから画面を作るのではなく、「どのデータを、どのキーで、どの地域から、どの頻度で読むか」を先に決めます。コンテナー、パーティションキー、インデックス、整合性レベルを誤ると、ホットパーティションやクロスパーティションクエリが発生し、性能だけでなくRU消費と月額料金にも影響します。

RFPには、想定する同時アクセス数、通常時とピーク時のリクエスト数、許容遅延、データ量の増加、保持期間、読み取りと書き込みの比率を記載します。委託先には、パーティションキーの候補を複数示してもらい、サンプルデータを使ったRUとP95レイテンシーの測定結果を提出してもらうと、提案の比較がしやすくなります。

Azure Cosmos DBのシステムはどのような発注形態が適していますか？

結論として、要件が固まっていない場合はPoCや要件定義を先に発注し、仕様が確定した段階で開発を発注する段階発注が適しています。業務要件、画面、連携先、受入条件まで確定している小規模案件では一括発注も選べますが、Cosmos DBのデータモデルを初回から固定しすぎないことが重要です。

既存のRDBやMongoDBから移行する場合、最初から本番システムを作るのではなく、代表的なデータと主要クエリを使って小さく検証します。検証項目は、パーティションキーの偏り、1秒あたりのリクエスト数、読み取り・書き込みのRU、P95の応答時間、障害時の復旧、データ照合の可否です。合格基準を先に決めておけば、技術的に可能かどうかだけでなく、月額上限に収まるかも判断できます。

要件定義の成果物には、業務フロー、データ項目一覧、アクセスパターン、API一覧、非機能要件、移行方針、概算費用、今後の開発計画を含めます。費用を抑えるために要件定義を省くと、後半でパーティションキーや権限設計をやり直し、結果として開発費が増える可能性があります。

一括発注は窓口と責任範囲をまとめやすく、納期と予算を管理しやすい形態です。ただし、要件変更が多い案件では変更管理の手続きが増えます。段階発注は、企画・PoC、基本設計、開発・移行、運用改善の順に契約を分ける方法で、検証結果を次の発注条件へ反映しやすくなります。

自社にAzureの運用担当者がいる場合は、業務要件と受入を自社で担い、委託先にデータモデリング、アプリ開発、IaC、負荷試験を委託する内製併用も現実的です。発注前に、自社が判断する範囲、委託先が実装する範囲、障害時に誰が意思決定するかをRACIのような役割表で明文化します。

RFPと要件整理でAzure Cosmos DBの発注条件を固める進め方

RFPは、技術用語を並べる資料ではなく、委託先が同じ前提で提案・見積できる発注条件書です。現状の業務、解決したい課題、対象ユーザー、対象データ、連携するシステム、希望時期、予算の考え方、提案に求める成果物を記載します。書けない項目は未確定事項として明示し、提案側に確認事項と前提条件を出してもらいます。

業務要件では、誰が何を登録・検索・更新し、処理結果をどの業務で利用するかを定義します。データ要件では、ドキュメントの単位、必須項目、更新頻度、1件あたりのサイズ、データの増加量、削除や匿名化の条件を整理します。Cosmos DBではアクセスパターンがデータモデルを左右するため、「顧客を検索する」「注文と明細を同時に読む」のような操作単位で整理することが大切です。

RFPに「大量データに対応」とだけ書くと、各社が異なる前提で見積もります。たとえば、通常時とピーク時の同時利用者数、ピーク倍率、1日の読み書き回数、許容する応答時間を数値で記載します。数値がまだ測れない場合は、現行ログの調査を要件定義の作業に含め、推定値と実測値を区別して管理します。

非機能要件には、可用性、許容停止時間、RTO、RPO、バックアップ保持期間、障害通知、監視時間、性能、拡張性を含めます。複数リージョン、マルチリージョン書き込み、強整合性を選ぶほど、設計と料金の条件が変わるため、機能要件の後回しにしないことが重要です。Microsoft Learnでは、複数リージョン構成などの条件を満たす場合に99.999%の可用性SLAが示されていますが、自社の構成で適用されるかを見積時に確認します。

個人情報や機密情報を扱うなら、日本リージョンへの限定、公開ネットワークの停止、Private Endpoint、Microsoft Entra ID、Managed Identity、Key Vault、監査ログ、バックアップ復元テストをRFPに盛り込みます。Microsoft Learnのセキュリティガイダンスでも、公開アクセスを制限し、マネージドIDやロールベースアクセス制御を使い、復元手順をテストすることが推奨されています（出典：Microsoft Learn「Secure your account」、2026年）。

既存システムから移行する案件では、移行元データの品質が費用と納期を左右します。重複、表記揺れ、欠損、不要な履歴、個人情報の保存期間を発注者側で確認し、クレンジング、変換、移行、照合、切り戻しを誰が担当するかを決めます。発注者のマスタ整備やデータ確認が遅れると、委託先だけでは作業を完了できないため、担当部署と期限まで書いておきます。

受入条件は「動くこと」では不十分です。主要APIの応答時間、ピーク負荷時のエラー率、データ件数と重要項目の照合率、バックアップからの復元、権限の分離、監視アラート、障害時の連絡手順をテスト項目にします。成果物として、IaC、ソースコード、API仕様書、データモデル、インデックス方針、RU測定結果、運用手順、障害訓練の記録を納品対象に含めると、外注後の属人化を防げます。

Azure Cosmos DBのシステム開発に合う契約形態の選び方

契約形態は、成果物と責任を明確にしたいか、要件変更に柔軟に対応したいかで選びます。Cosmos DBは、負荷試験やデータ移行の結果によって設計を調整することがあるため、すべてを同じ契約に押し込めず、工程ごとに適した契約を組み合わせる方法が現実的です。

請負契約は、合意した成果物を完成させ、納品・検収する範囲に向いています。画面仕様、API仕様、データ移行手順、テスト項目、受入基準が固まっている工程では、成果物、納期、検収条件、瑕疵対応を契約書と仕様書に落とし込みやすいです。

ただし、「Cosmos DBを使ったシステム一式」のような曖昧な表現では、どこまでが完成かで認識がずれます。RU最適化、障害訓練、データ照合、運用引き継ぎを納品物と検収項目に含め、仕様変更時の追加費用と納期変更の扱いも決めます。

準委任契約は、専門家の作業や技術支援を一定期間依頼する形に向いています。要件定義、アーキテクチャレビュー、PoC、データモデリング、性能検証のように、調査結果を見ながら次の判断をする工程では、作業内容と稼働時間、報告方法、成果の定義を明確にして活用します。

準委任だから成果物が不要になるわけではありません。検証レポート、設計判断の記録、課題一覧、次工程の見積、ソースコードや設定の管理場所など、期間終了時に何が残るのかを決めます。委託先に任せきりにせず、自社のプロダクト責任者が優先順位を決める体制も必要です。

おすすめしやすいのは、要件定義とPoCを準委任、仕様確定後の開発と移行を請負、リリース後の監視改善を保守契約に分ける構成です。工程ごとの責任を整理でき、PoCの結果によって本開発を縮小・延期する判断もしやすくなります。

契約書では、再委託の事前承認、個人情報の取り扱い、インシデント報告期限、知的財産権、秘密保持、アカウントの名義、退去時のデータ返却と削除、ソースコードの引き渡しを確認します。個人情報を委託する場合は、委託先の安全管理措置や再委託先の監督を確認することが個人情報保護委員会のガイドラインでも示されています（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

Azure Cosmos DBのシステム開発費用相場とコストの内訳

費用は、開発会社へ支払う初期開発費と、Azureへ支払うクラウド利用料を分けて考えます。さらに、要件定義、データモデリング、アプリ開発、移行、テスト、Azure構築、監視、運用引き継ぎの内訳を分けないと、安い見積に見えても後から追加費用が発生しやすくなります。

以下は、Azure利用料を除いた業務システム開発の概算レンジです。Cosmos DB専用の公表市場統計ではなく、一般的な業務システムの費用・工程データに、Cosmos DB固有のデータモデリング、性能検証、移行、運用設計を加味した推定です。PoCや小規模APIは100万〜300万円程度、認証・管理画面・外部API・移行・監視を含む小〜中規模システムは500万〜1,500万円程度が一つの目安になります。

マルチリージョン、Change Feed、イベント連携、障害訓練、厳格な権限管理を含む案件は1,500万〜5,000万円程度、既存データベースからの大規模移行や複数部門・複数システム連携を含む基幹案件は5,000万円〜数億円になる可能性があります。期間は、PoCで1〜2か月、小〜中規模で3〜6か月、高可用性や複数連携で6〜12か月、大規模移行で12〜24か月以上が目安です。

これらは機能数、画面数、外部連携数、移行データ量、同時接続、データ所在地、RTO・RPO、既存システムの品質で大きく変わります。社内Q&Aで整理されている一般的な業務システムの費用レンジと、要件定義10〜15%、開発30〜40%、テスト15〜20%、保守年10〜20%という比率を参考にした概算であり、個別案件の確定金額ではありません（出典：社内NotebookLM Q&A「業務システム全般_11」、2026年）。

Azure Cosmos DBの利用料は、主にスループット、保存データとインデックス、リージョン数、バックアップ、可用性ゾーン、データ転送で決まります。スループットはRU/sで表し、手動プロビジョニングは設定したRU/s、Autoscaleは時間ごとの最大RU/s、サーバーレスは消費したRUをもとに課金されます。Azure料金計算ツールでは、リージョンとAPI、スループット、ストレージを分けて入力します。

Microsoft Learnの料金説明にある例では、プロビジョニング済み500 RU/sを100 RU/sあたり毎時0.008米ドルとして、730時間で29.20米ドル／月と計算しています。サーバーレスは、月2,000万RUで5米ドル、2億5,000万RUで62.50米ドルという例が示されています（出典：Microsoft Learn「Plan and Manage Costs」、2026年）。これは説明用の例であり、実際の金額はリージョン、契約、為替、ストレージ、バックアップ、通信、割引で変動します。

開発・検証環境では、対象サブスクリプションで1アカウントに限り、無料枠として1,000 RU/sのプロビジョニング済みスループットと25GBのストレージが適用される場合があります。無料枠はサーバーレスには適用されないため、PoCの構成と本番の構成を混同しないことが大切です（出典：Microsoft Learn「Lifetime Free Tier」、2026年）。本番の予算は無料枠を前提にせず、負荷試験後の実測値で見積もります。

ランニングコストには、Azure利用料だけでなく、監視、障害対応、バックアップ復元テスト、OSやライブラリの更新、脆弱性対応、追加改修、問い合わせ対応が含まれます。一般的な目安として、年間保守費を初期開発費の10〜20%程度から検討できますが、24時間監視や即時対応を含む場合は別途見積が必要です。

たとえば初期開発費が1,500万円なら、保守費の起点は年150万〜300万円程度、月額では約12.5万〜25万円程度です。ただし、この計算は保守範囲の比率から出した目安であり、特定の会社が提示する金額ではありません。見積書では、月次報告、監視対象、障害一次切り分け、復旧支援、軽微改修の時間、追加作業の単価を分けて確認します。

Azure Cosmos DBの委託先選定と見積比較のポイント

委託先は、Azureを使えるかだけでなく、Cosmos DB固有のデータ設計、RU最適化、移行、障害訓練、運用監視まで担えるかで選びます。Microsoft Learnには、Cosmos DBのNoSQL移行やアプリ開発に対応するパートナー一覧がありますが、掲載は案件の成功や自社案件への適合を保証するものではなく、一覧も更新されます（出典：Microsoft Learn「Azure Cosmos DBへの移行およびアプリケーション開発パートナー」、2026年）。

実績を聞くときは、「Azure案件があります」ではなく、Cosmos DBを本番で使ったか、どのAPIを選んだか、パーティションキーをどう決めたか、ピーク時のRUやレイテンシーをどう管理したかを確認します。移行案件なら、移行元、データ量、停止時間、並行稼働、照合、切り戻しまで質問します。

提案書に実績が書かれていても、実際に担当するエンジニアが同じとは限りません。面談にはデータモデリング担当、アプリ担当、インフラ・セキュリティ担当、運用責任者に参加してもらい、想定するデータモデルと障害時の判断を説明してもらいます。公開できない事例は無理に社名を求めず、規模、課題、設計判断、結果を匿名化して確認します。

複数社へRFPを渡すときは、同じデータ量、同じ画面数、同じ外部連携数、同じリージョン要件、同じテスト範囲を前提にします。見積は、要件定義、PoC、基本設計、詳細設計、アプリ開発、Azure構築、データ移行、テスト、リリース、教育、保守を分け、各工程の人月または工数と単価を確認します。

Azure費用は開発会社の費用と別建てにし、RU/s、Autoscaleの最大値、ストレージ、リージョン、バックアップ、転送、周辺サービスを前提として記載してもらいます。初期費用が安くても、監視、移行、性能改善、運用設計が抜けていれば比較になりません。逆に高い見積でも、納品物とリスク対策が具体的なら、総保有コストが下がる場合があります。

Azureの標準機能で解決できる課題に、独自機能を増やしすぎると、開発費と保守費が膨らみます。特に、使わない高い可用性構成、過剰な自動インデックス、不要なクロスパーティションクエリ、要件のないAI機能を先に追加する提案には注意が必要です。必要性、代替案、将来拡張の条件を提案書で説明してもらいます。

ロックイン対策として、Azureアカウントを発注者名義で契約し、ソースコード、IaC、設計書、テストデータ、監視設定、運用手順を自社が保管します。Cosmos DBから別サービスへ移行できるかを完全に保証する必要はありませんが、データエクスポート、APIの責任範囲、契約終了時の支援、認証情報の返却・削除を決めておくと、委託先の変更に備えられます。

発注後のテスト・データ移行・運用引き継ぎを成功させる方法

発注後は、開発会社から納品を受けるだけでなく、発注者が受入判定できる状態を作ります。単体テストや結合テストに加え、RU、P95レイテンシー、ピーク負荷、障害、バックアップ復元、権限、監査、移行データの照合を確認し、本番運用の担当者が手順を実行できることまで検証します。

負荷試験では、平均値だけでなく、ピーク時のRU消費、P95やP99の応答時間、スロットリング、エラー率、パーティションごとの偏りを記録します。Cosmos DBの料金や性能はアクセスパターンで変わるため、実際の利用に近いデータサイズとクエリで検証し、想定ユーザー数だけを入力した試験で済ませないことが重要です。

2025〜2026年に注目される統合ベクトルストアを使う場合も、AI機能を先に実装するのではなく、元データの表記揺れ、重複、更新責任、評価データを整理します。Microsoft Learnでは、Cosmos DB for NoSQLで元のJSONデータと埋め込みを同じ場所に保存し、DiskANNなどのベクトルインデックスを利用できると説明されていますが、量、次元数、検索精度、RU、更新頻度をPoCで確認してから本番機能にします（出典：Microsoft Learn「Integrated Vector Store」、2026年）。

移行は、本番当日に初めて実施しないことが原則です。サンプル移行、全量移行、差分移行、データ照合、アプリ接続の切り替え、旧環境への切り戻しをリハーサルし、所要時間と担当者を記録します。停止できない業務では、並行稼働やChange Feedなどの方式を候補にしますが、整合性と重複排除の方法を事前に決めます。

移行完了の判定は、総件数だけでなく、重要項目、更新日時、関連する状態、個人情報のマスキングを照合します。移行後に業務部門が確認する画面や帳票を決め、問題があった場合の切り戻し期限も設定します。発注者側のデータ担当者が検証に参加しないと、技術的には移行できても業務上の欠損を見逃すため注意が必要です。

運用開始後は、RU消費、ストレージ、スロットリング、エラー率、P95レイテンシー、パーティションの偏り、バックアップ状態、権限変更を監視します。Cost Managementで予算とアラートを設定し、Autoscaleの最大値や複数リージョンの追加によって想定を超えたときに通知されるようにします。

引き継ぎでは、手順書を読むだけでなく、発注者の担当者がアラート確認、ログ調査、バックアップ復元、アクセス権変更、障害連絡を実行します。委託先との保守契約に、月次レビュー、性能改善の提案、Azureサービスの更新確認、緊急時の連絡先を含めると、納品後も安定運用しやすくなります。

よくある質問（FAQ）

Azure Cosmos DBの発注では、技術選定だけでなく、費用、契約、移行、運用の責任分担がよく質問されます。特に重要な質問への回答を、発注前の判断に使える形でまとめます。

PoCや小規模APIなら100万〜300万円程度、小〜中規模の業務システムなら500万〜1,500万円程度が概算の起点になります。マルチリージョンや大規模移行を含む場合は1,500万〜5,000万円程度から数億円まで広がるため、要件定義、移行、テスト、Azure構築、保守を分けた見積を取得します。

要件と成果物が固まっている開発・移行工程は請負契約、調査やPoC、要件定義のように結果を見ながら進める工程は準委任契約が合いやすいです。実務では、要件定義を準委任、仕様確定後の開発を請負、運用を保守契約に分ける段階的な組み合わせが使いやすいです。

Cosmos DBの本番実績、パーティションキーとRUの設計力、既存データの移行経験、Azureのセキュリティと監視、障害訓練、納品物の範囲を確認します。提案書の会社名や認定だけで判断せず、担当エンジニアに具体的な設計判断、負荷試験、失敗時の対応を説明してもらうことが重要です。

移行は可能ですが、単純なコピーではなく、データモデル、パーティションキー、クエリ、インデックス、整合性、アプリの接続方式を見直します。サンプル移行と本番リハーサルを行い、データ照合、差分反映、切り戻し、業務部門の受入まで含めて計画することが必要です。

まとめ

Azure Cosmos DBのシステムを外注するときは、まず自社の業務に採用する理由と、Cosmos DBではない方がよい処理を整理します。そのうえで、アクセスパターン、パーティションキー、RU/s、整合性、リージョン、RTO・RPO、セキュリティ、移行対象をRFPにまとめます。

発注形態は、未確定事項が多ければPoC・要件定義から段階発注し、確定した開発範囲は請負、検証や専門支援は準委任で分けます。見積比較では、開発費とAzure利用料、初期費用と保守費、移行と運用引き継ぎを分離し、実績だけでなく担当者の設計力と納品物まで確認します。

最初から大規模な本番開発を契約するのではなく、代表データと主要なクエリを使って、性能、RU、月額、移行、障害復旧を測定します。測定結果をもとに本番の構成と予算を見直せば、Cosmos DBの強みを活かしながら、過剰なカスタマイズや予想外の追加費用を抑えやすくなります。

委託先との打ち合わせでは、この記事の確認項目をそのまま質問票に変え、提案の前提、費用、契約、体制、受入条件を同じ書式で提出してもらいます。自社の業務とデータに合うパートナーを選び、納品後も自社で運用判断できるAzure Cosmos DBのシステムを構築することが、発注の最終的なゴールです。

▼全体ガイドの記事
・Azure Cosmos DBのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。