相談する

Amazon DocumentDBのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Amazon DocumentDBのシステム開発は、業務要件と主要クエリを整理し、MongoDBとの互換性をPoCで確かめてから、設計・移行・定着へ進めます。

全体像は完全ガイドもご覧ください。

▼全体ガイドの記事
・Amazon DocumentDBのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Amazon DocumentDBのシステム開発の全体像

DocumentDBクラスタを中心に、アプリ、実行基盤、外部連携を配置した構成図。
画面、処理、外部サービスがクラスタとつながります。

Amazon DocumentDBは、MongoDB互換のAPIとドライバーを使えるフルマネージド型のドキュメントデータベースです。さらに、顧客、案件、行動イベントなどのJSONドキュメントを扱いやすく、AWSのネットワーク、認証、監視、バックアップとも組み合わせられます。

Amazon DocumentDBは、MongoDBと完全に同じではないため、「互換性があるから移行できる」と決めつけず、事前に確かめておく必要があります。

DocumentDBに向いているデータ

顧客や案件ごとに項目が変わるデータ、履歴・行動ログを扱う場合に適しています。

  • 顧客・企業情報：顧客プロフィール、企業属性、問い合わせ履歴
  • 案件情報：レコードごとに変わる案件の可変項目
  • 活動・行動データ：営業活動、メールやWebの行動ログ

顧客ドキュメントに担当者、契約状況、利用製品、最新接点をまとめておくと、画面に必要な情報を一度に読み出せます。

案件ドキュメントには、確度や金額、競合、次回アクションを持たせられます。また、属性は後から加えられます。

一方で、1件のドキュメントが巨大になると、更新競合や読み取り量の増加につながります。そのため、設計の段階で、1件あたりのサイズ、更新頻度、参照関係を開発会社と確認しておきます。

システム全体の構成

構成は、アプリ、基盤、実行基盤、外部連携の4つに分けて考えます。それぞれの役割と連携先を整理すると、次のようになります。

  • アプリ：Reactなどの画面、Node.js・Java・PythonなどのAPI
  • 基盤：DocumentDBクラスタ、認証、非同期処理、監視・ログ
  • 実行基盤：常時稼働するAPIはAmazon ECSやEC2、イベント単位の処理はAWS Lambdaが候補
  • 外部連携：商談の更新通知や顧客情報の検索連携に、変更ストリーム、Lambda、SQS、Amazon OpenSearch Serviceを利用

データを保持するクラスターボリュームと、処理能力を担うインスタンスは別々に考えます。なお、読み取りが増えた場合は、読み取りインスタンスの追加も検討します。

RDBやSaaSを優先するケース

複数の業務データを厳密に結合し、会計や請求の横断集計を中心に行うなら、AuroraなどのRDBや既存の基幹DBが適している場合があります。

ほかに、一般的な営業管理が中心なら、既存のCRMやSFAを使い、DocumentDBは可変属性や高頻度イベントの補助基盤に限る方法もあります。

選ぶ際は、必要な検索・更新・集計・連携を、現場が使い続けられる費用と性能で実現できるかを見ます。

ポイント

DocumentDBは、項目が変わるJSONデータや履歴データに向いていますが、MongoDBと完全に同じではありません。移行を判断する前に、互換性をPoCで確かめる必要があります。

Amazon DocumentDBのシステム開発の進め方

開発前に整理する4つの観点として、業務フロー、利用場面、利用条件、管理要件を並べた図。
業務と管理の条件をそろえると、後工程の判断材料になります。

開発は、データベースの設定から始めるのではなく、業務の目的と利用者の行動から逆算して進めます。全体は6つの段階に分かれます。

  1. 要件整理で業務フローとデータの責任者を決める
  2. 選定でRDB・SaaS・DynamoDB・DocumentDBの役割を比べる
  3. 設計・開発でデータモデルとクラウド構成を固める
  4. 互換性・性能・セキュリティ・移行をテストする
  5. 稼働時に移行と切り戻しを計画する
  6. 稼働後に利用状況を見ながら入力ルールと画面を定着させる

1. 要件整理：業務とデータの優先順位

業務フローと要件は、4つの観点から整理します。

  • 業務フロー：誰がいつ何を入力し、どの画面で何の判断に使うか
  • 利用場面：営業の顧客登録、案件確認、リード抽出、管理者の権限変更
  • 利用条件：役割、1日あたりの登録件数、ピーク同時接続数、検索条件、保存期間
  • 管理要件：削除・訂正、外部連携、RTO・RPO、個人情報区分、必須・任意項目

毎日入力しない項目が増えると、導入後にデータが欠けやすくなり、スコアリングやレポートの精度も下がります。

2. 選定：DocumentDBを採用する根拠の比較

候補には既存パッケージやSaaS、RDBなどがあり、DynamoDBやMongoDB、Amazon DocumentDBも含まれます。選定では、DocumentDBが合う条件と、別の構成が必要になる条件の両方を確認します。

  • DocumentDBの適性：JSON項目の増減、顧客・案件単位の取得、AWSの認証・監視・バックアップ、読み取り拡張
  • 別構成の検討：MongoDB独自機能への依存、複雑な横断集計、グローバルな書き込み分散が必須

2026年時点でDocumentDB 8.0はMongoDB API 6.0・7.0・8.0向けドライバーをサポートします（出典：AWS公式「Amazon DocumentDB compatibility with MongoDB」、2026年）。ただし、演算子やツールの仕様は完全に同じではありません。

選定の最後には、代表的なクエリを使う小規模なPoCを行います。顧客一覧の絞り込み、案件の並び替え、期間集計を、実際に動かして確かめます。

加えて、全文検索や更新競合、権限エラーを、実データに近い条件で確かめます。バックアップからの復元についても、同じ条件で確認します。

MongoDBから再利用できる処理と、書き換えが必要な処理を表にまとめます。互換性検証表を納品物に含めれば、後からの手戻りを抑えられます。

3. 設計・開発：ドキュメントとクエリの同時設計

顧客や商談などのデータを、同じドキュメントに埋め込むか別のコレクションに分けるかは、4つの軸で判断します。

  • 常に一緒に表示するデータか
  • 更新頻度が同じデータか
  • 件数が無制限に増えるデータか
  • 単独で検索・集計するデータか

たとえば、顧客の最新担当者情報は同じドキュメントに持たせ、数年分の活動履歴は別のコレクションに分ける場合があります。

活動履歴は、顧客IDと日時で検索する前提で組むと保守しやすい場合があります。まず画面仕様を決めたうえで、クエリとインデックスを確定します。

一覧や詳細、集計などの場面ごとに、実行するクエリを設計します。また、VPCのプライベートサブネットやセキュリティグループも定めます。

TLSによる通信の暗号化と、AWS KMSによる保存時の暗号化を設計します。そのうえで、認証はIAMまたは既存IdPを使い、Secrets ManagerやCloudWatchも組み込みます。バックアップと障害通知も、設計に含めます。

個人情報の保護は、採用したあとの権限設計まで含めて完了します。そのため、役割ごとに権限を分けます。営業やマネージャーのほか、管理者と運用担当者も含めて決めます。

権限の範囲は、誰が何を参照・変更・削除できるかを、文書に書き出します。

4. テスト：互換性・性能・安全性を分けた検証

画面の動作の確認に加えて、データベースの特性に合わせてテストを分けます。

  • 互換性：CRUD、集計、インデックス、ページング、トランザクション、ドライバー、接続設定
  • 性能：通常時・ピーク時の接続数、クエリ応答、読み取り追加時の変化、データ増加後の劣化
  • 安全性：TLSなし接続の拒否、最小権限、秘密情報のログ防止、復元後の権限、監査ログ保管

MongoDBとの差は、結果の順序や未対応の演算子、retryable writesに現れる場合があります。ほかにも、インデックスや管理用DBなどで違いが出る場合があります。

DocumentDBはMongoDBと異なる専用エンジンを使うため、クエリプランやexplainの出力も異なります（出典：AWS公式「Functional differences: Amazon DocumentDB and MongoDB」、2026年）。

機能一覧の確認で済ませず、アプリが実際に発行するクエリとエラーハンドリングで確かめます。

5. 稼働：移行と切り戻しの事前計画

移行計画では、対象データの扱いと、本番切り替え前の確認手順を決めておきます。

  1. MongoDBやCRMのデータ項目対応表を作り、欠損・重複・表記揺れの扱いを決める
  2. 移行対象期間、順序、照合方法、停止時間、切り戻し条件を定める
  3. 少量データでリハーサルし、全件移行、件数と代表キーの照合、接続先変更、監視確認、利用者への告知を行う

AWS Database Migration Service（AWS DMS）を使うときは、全件ロード中の変更を保持できるよう、保持期間と処理時間を見積もります。そのため、変更ストリームの保持時間は全件ロードより長く設定する必要があります（出典: AWS公式「Migrate to Amazon DocumentDB using AWS DMS」、2026年）。

大規模移行の事例として、AWSのAiSensyは、AWS DMSを使って120TBを3週間、ダウンタイムなしで移行しました。また、文書DB費用を20％削減し、クエリ性能を95％改善したと報告しています（出典: AWS公式AiSensy事例、2026年）。

これは大規模サービスの個別事例のため、期間や効果をそのまま当てはめず、実データのリハーサルで判断します。

6. 定着：入力と活用のサイクル

稼働後は、ログイン数だけで成功を判断せず、利用状況とデータ品質を月次で確認します。

  • 利用状況：必須項目入力率、次回アクション設定率、レポート利用数
  • データ品質・支援：重複登録率、MA連携失敗数、問い合わせ件数
  • 運用手順：マスタ責任者、データ修正申請、権限承認者、退職者アカウント停止

入力に時間がかかる画面や不要な項目は、現場の担当者の声をもとに見直します。

変更ストリームを使うと、顧客更新をLambdaで非同期に連携したり、OpenSearchや分析基盤へイベントを送ったりできます。

変更ストリームのイベントは標準で3時間保持され、設定により最大7日まで延長できます（出典: AWS公式「Using change streams with Amazon DocumentDB」、2026年）。

連携先の停止や再処理に備えて、保持期間や重複イベントの扱いを決めておきます。再実行の手順と監視アラートは、発注側と開発会社で定めます。

ポイント

迷ったときは、業務の目的と利用者の行動に戻って判断します。互換性はPoCで確かめ、そのうえで設計と移行、定着へ進みます。稼働後の見直しも、この流れに含めます。

Amazon DocumentDBの費用相場とコストの内訳

PoCから大規模まで、4段階の開発規模ごとの概算費用を横棒で比較した図。
規模が上がるほど、見積もりレンジも広がります。

費用はAWS利用料と、設計・開発・移行・テスト・教育・保守の人件費に分けて考えます。

AWS利用料は、インスタンスやストレージの構成で変わるほか、I/O、バックアップ、データ転送の量でも変わります。

開発費は、機能数や連携数、移行の難しさで左右されます。さらに、性能要件や利用者数、運用時間によっても変わります。

ここに示す数字は、公開情報と一般的な業務システム開発をもとにした概算レンジです。日本リージョンや個別要件を確定させるものではありません。

AWS利用料の見込み方

AWS公式の米国東部の料金例は、db.r5.largeを2台、データ50GB、バックアップ50GB、月2億I/Oという構成です。この条件では、Standardが月449.42米ドル、I/O-Optimizedが月459.86米ドルです。1米ドル=150円で機械的に換算すると、約6.7万〜6.9万円です。

日本リージョンやインスタンス、為替は、この料金例とは別に扱います。実行基盤や監視、転送、サポート費も別です（出典: AWS公式「Amazon DocumentDB pricing」、2026年）。

料金例だけで予算を決めず、AWS Pricing Calculatorに実際のデータ量とアクセス量を入力して試算します。そのうえで、検証環境から本番、大規模利用までの月額の幅を、構成とアクセス量ごとに把握します。

  • 検証環境：単一インスタンス、少量データ、稼働時間を限定する場合はDocumentDB単体で月3万〜10万円程度
  • 小規模な本番CRM・MA：冗長化した2〜3インスタンス、バックアップ、監視、実行基盤を含み、AWS全体で月15万〜50万円程度となる場合
  • 大規模な利用：大きなアクセス量、グローバルクラスター、長期バックアップでは月50万〜数百万円以上となる可能性

月額の確認の前に、ピーク同時接続数と保存期間を見積もります。

ServerlessとProvisionedの選び方

アクセスの変動やI/O量、環境ごとの稼働条件から、ServerlessとProvisionedのどちらが合うかを考えます。

  • Serverless：検証、キャンペーン、イベント処理など、需要に応じて容量を調整する用途
  • Provisioned：常時安定し、応答性能を予測しやすい本番業務
  • 料金モデル：I/O量、請求変動、環境ごとの稼働時間に合わせてStandardとI/O-Optimizedを比較
  • 月額試算：開発・本番でモデルを分け、稼働時間、容量、バックアップ、追加I/Oも含める

読み取りインスタンスの数とタイプは、負荷テストで決めます。なお、2026年5月にはDocumentDB 8.0でServerlessが利用可能になりました。

ピーク容量を常時確保する場合と比べると、最大90％のコスト削減がうたわれています。ただし、これはワークロードなどで変わる最大値で、実際の削減額を保証するものではありません（出典：AWS公式「Amazon DocumentDB Serverless is now available on DocumentDB 8.0」、2026年）。

I/Oが多く、請求額の変動を抑えたい場合は、I/O-Optimizedも比較の対象にします。

I/O-Optimizedは、I/O料金を含めて費用を見通しやすい反面、少量のI/Oでは常に有利とは限りません。

開発費と期間の相場

DocumentDB専用の公的な開発費統計はありません。そのため、金額は営業・CRM・MAの相場と一般的なクラウド開発を、案件要件に置き換えた概算です。

  • PoC：技術検証やMongoDBデータの一部移行で100万〜300万円、1〜2か月程度
  • 小規模新規：顧客・案件・活動管理、権限、検索、簡易レポート、AWS基盤、テストで500万〜1,500万円、3〜6か月程度
  • 中規模：既存CRM・MA・基幹連携、クレンジング、段階移行、監査ログ、運用設計で1,500万〜5,000万円、6〜12か月程度
  • 大規模：複数拠点、複雑な権限、DR、複数リージョン、数千万件からTB級の移行で5,000万円〜数億円、12〜24か月以上となる可能性

保守・改修費は、初期開発費の年10〜20％程度を別に見込みます。その中には、要件変更やDocumentDBのバージョン更新、脆弱性対応、監視改善が含まれます。

ポイント

費用は、AWS利用料と人件費に分けて考えます。AWS利用料は構成とアクセス量で、開発費は機能数や連携数で変わるため、見積もりの前に条件をそろえておく必要があります。

Amazon DocumentDBの見積もりを取る際のポイント

見積もりでは、総額だけでなく、どの作業が含まれるか、発注者側がどの判断を担うかを確認します。

データモデルや互換性、クラウド設定、移行、保守を別会社が担うと、障害時にどこまでを誰が受け持つかが曖昧になりやすい領域です。そのため、要件書と質問票をそろえ、複数社に同じ条件で依頼します。

発注前に整理する要件

発注前の要件は、業務条件、データ条件、処理条件の3つに分けて整理します。

  • 業務条件：対象業務、利用者数、同時接続数、希望稼働時間、希望リリース時期
  • データ条件：既存DBの種類・バージョン、件数・容量・増加量、個人情報の項目、保持期間
  • 処理条件：主要クエリ、検索・集計条件、連携先、RTO・RPO、想定予算

サンプル文書を数件渡せば、項目のばらつきや個人情報の混在を確かめられます。

画面一覧に加えて、代表的な業務シナリオと、画面を何秒以内に表示したいかも書き添えます。

見積書は、要件定義やPoC、モデリング、AWS基盤、アプリ開発が、それぞれ行に分かれているかを確認します。外部連携、データクレンジング、全件移行についても、その行の有無を確かめます。

リハーサルや教育、保守が含まれるかを確認します。性能・セキュリティ試験と稼働立ち会いについても、項目として挙がっているかを見ます。

納品物は、有無を明記してもらいます。設計書やAPI仕様書、データ辞書、テスト結果のほか、IaCやソースコード、運用手順書も対象です。

開発会社の比較観点

発注先は、実績や担当範囲、検証材料、得意領域の4つの観点で比べます。

  • 実績：DocumentDBやMongoDB互換環境の案件、PoC、AWS設計・構築
  • 担当範囲：アプリ開発、移行、セキュリティ、監視・障害対応、定着支援
  • 検証材料：互換性検証表、負荷試験条件、切り戻し計画、障害時の窓口
  • 得意領域：クラウド専業会社の基盤・運用、大手SIerの連携・ガバナンス

選ぶ際は、知名度よりも、PoCの成果物と運用後の責任者を重視します。riplaのような一貫支援会社には、要件整理からクラウド構成、開発、定着まで、まとめて相談できます。

依頼範囲は、DocumentDBだけか、顧客・案件・活動の業務画面まで含むかで分けます。さらに、既存CRMやMAとのデータ連携の有無を明確にします。

見積もりの抜け漏れの防ぎ方

見積もりでは、初期費用に加えて、後から追加費用になりやすい運用項目を確認します。

  • 初期・移行：アプリ開発費に加え、AWS利用料、移行、テストデータ、教育、運用監視
  • 継続費用：変更ストリームの追加I/O、バックアップの保持、ログの保管、DMS、複数環境
  • 保守費用：バージョン更新、脆弱性対応、休日の障害対応
  • TCO：開発、AWS月額、第三者サービス、保守、将来改修を分けて整理

古いエンジンを選ぶ場合は、サポート期限とアップグレード計画を確認します。

たとえば、AWSは2025年に、Amazon DocumentDB 3.6のExtended Supportを発表しました（出典：AWS公式「Amazon DocumentDB 3.6 Extended Support」、2025年）。標準サポート終了後の追加料金とセキュリティ更新も案内しています。

初期構築時の選択は、短期の互換性だけで決めず、3年から5年の運用に必要な更新作業も見積もりに含めます。

ポイント

見積もりは、総額だけでなく、含まれる作業と発注側が担う判断を比べて読みます。要件書と質問票をそろえ、複数社に同じ条件で依頼すると、比較の土台がそろいます。

よくある質問

MongoDBとの違いやCRM・MAとの適性を含め、費用や移行停止時間について、発注前に判断できるよう回答します。

MongoDBからAmazon DocumentDBへそのまま移行できますか？

アプリやドライバーを再利用できる可能性はありますが、完全移行できるとは限りません。そのため、主要クエリや集計、インデックスを実データで検証します。

トランザクションや接続設定、管理用処理についても、実データで確かめます。加えて、AWS DMSやmongodumpなどの移行方式、データ照合、切り戻しも含めてPoCを行います。

CRMやMAのデータベースにAmazon DocumentDBは適していますか？

顧客属性や案件、接点履歴など、項目が増減するJSONデータに適しています。フォーム送信やメール開封、Web行動の記録も、この種のデータに含まれます。

複雑な会計集計や厳格な参照整合性が中心ならRDB、一般的な営業管理ならSaaSを主役にする案も比べます。また、DocumentDBを可変属性やイベント処理に限って使う構成も、選択肢になります。

小規模なAmazon DocumentDBのシステム開発はいくらかかりますか？

開発費とAWS利用料の概算は、4つの項目で目安が分かれます。

  • 技術検証：100万〜300万円
  • 小規模新規システム：顧客・案件・活動管理を含め500万〜1,500万円程度
  • 検証環境のAWS利用料：月3万〜10万円程度
  • 本番AWSインフラ全体：月15万〜50万円程度

金額は、リージョンやデータ量、可用性で変わります。さらに、アクセス量と連携数によっても左右されます。初期予算は、AWS Pricing Calculatorと複数社の同一条件見積もりで再確認します。

データ移行の停止時間を短くできますか？

AWS DMSなどで全件ロードと変更データ反映を分けたうえで、事前リハーサル、件数・代表キーの照合、段階的な切り替えを行えば、停止時間を短くできる可能性があります。

停止時間ゼロは先に約束せず、データ量や更新頻度、許容できる不整合、切り戻し条件をもとに計画します。そのうえで、利用者への告知や切り替え後の監視体制も評価します。

まとめ

Amazon DocumentDBの開発は、顧客やリード、商談、行動ログを業務でどう使うかを整理して始めます。要件整理と選定から、設計開発、テスト、稼働を経て定着まで、6段階で進めます。

MongoDB互換性や主要クエリ、個人情報、AWS月額は、PoCとチェックリストで確認します。移行や現場入力も、PoCとチェックリストで見ていきます。

採用判断の中心になるPoC

DocumentDB 8.0やServerlessを選べるとしても、自社のクエリとデータ量で必要な性能と料金が出るとは限りません。PoCでは、2つの点を確かめます。

  • 互換性・性能：代表データと利用シナリオでの確認
  • 運用・復旧：バックアップ復元、権限、移行、障害時の復旧

PoCの結果をもとに、DocumentDBを主役にするか、RDBやSaaSと役割を分けるかを決めます。その結果は、見積もりの前提条件と、本番移行の受け入れ基準に残しておきます。

要件と見積もり条件の整理

要件をまとめてから、見積もりの依頼と相談先の選定へ進みます。

  1. 利用者の役割、データ件数と増加量、主要クエリ、既存システム、連携先、個人情報、RTO・RPO、希望時期を1枚にまとめた資料
  2. PoCと本開発を分けた複数社への見積もり依頼と、AWS利用料、移行、テスト、教育、保守の範囲の比較
  3. 業務要件とクラウド技術の両方を理解する会社への相談と、採用・不採用の判断材料

▼全体ガイドの記事
・Amazon DocumentDBのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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