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

Amazon Keyspacesの発注は、業務とデータを洗い出して適合性をPoCで検証し、そのあとRFPを同じ条件で複数社に渡して比べる流れが基本です。

全体像は、Amazon Keyspacesのシステム開発の完全ガイドでもあわせて確認できます。

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

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

Amazon Keyspacesのシステム発注の全体像

Amazon Keyspacesは、Apache Cassandra互換のフルマネージド・サーバーレスデータベースです。サーバーの調達やパッチ適用はAWSに任せられます。

Cassandra Query Language（CQL）や既存のドライバーも使えるため、Cassandra資産の移行や大量データの新規基盤に向いています。採用を考えるときは、格納するデータと委託範囲を分けて考えます。

Keyspacesに向くデータと向かないデータの切り分け

Keyspacesには、営業活動の履歴やリードへの接触イベントを分けて置く構成が検討しやすいです。さらに、メールの配信・開封・クリックや、広告・キャンペーンの時系列ログも候補になります。

• 適性がある処理：大量に書き込み、顧客IDや時系列をキーに決まった形で読み出す処理。
• 別基盤も検討する処理：任意条件のJOIN、全文検索、複雑な横断集計、頻繁な帳票作成。
• 設計の起点：「顧客IDで直近30日のイベントを読む」などのアクセスパターン。

一方で、顧客マスタや商談、請求、権限などの正規系データは、AuroraやRDSなどとの役割分担が必要です。検索エンジンやデータウェアハウスも候補になります。

発注先に求めるデータ設計と業務理解

AWSはKeyspacesの提供元ですが、業務システムの要件定義や開発を単独で請け負う会社とは役割が異なります。そのため、委託先の担当者に必要な経験を確かめます。

• データ設計：Cassandraのパーティションキー設計。
• 業務連携：既存CRMとのAPI連携。
• 品質と運用：負荷試験、個人情報の権限管理、移行後の監視。

発注側は、AWS認定数やパートナーランクに加えて、類似案件のテーブル設計書や性能試験結果を確認します。移行仕様書と運用Runbookも、確認の対象になります。さらに、納品物を見ると、実装力と説明責任を具体的に比べられます。

Amazon Keyspacesの発注・外注の進め方

発注は、まず業務とデータを洗い出し、適合性を検証してから、RFPで同じ条件を複数社へ渡す順番が基本です。Cassandra系の設計は後からの変更が高くつきやすいため、検証を先に行うのが妥当です。要件定義と小規模なPoCを発注工程に含めると、設計を確かめながら進められます。

企画・要件整理での業務範囲とデータ責任者

まず、顧客、リード、商談などのデータ項目を一覧にします。メール配信や広告反応も対象に含めます。そのうえで、登録元や利用者、保持条件を整理します。

• データの条件：更新頻度、1行あたりのサイズ、保持期間。
• 管理責任：個人情報の有無、削除依頼への対応者。
• 利用範囲：営業画面に加え、MAや分析基盤の読み書き。

マスタの表記揺れや重複した顧客レコードも確認しておきます。これらを残したまま自動化やAI分析を進めると、誤った情報が蓄積されます。

要件定義書には、業務フローとデータ項目一覧を含めます。さらに、データ分類やアクセスパターンも書き、非機能要件と対象外範囲を明記します。

RFPに入れるKeyspaces固有の性能条件と比較基準

見積もりと性能を比べられるよう、RFPには処理量やデータ構造、運用条件を記載します。「高速」「大規模」といった表現では、各社が異なる条件で見積もるため、価格と性能を比べにくくなります。

• 処理量：月間読み取り・書き込み回数、ピーク時の秒間リクエスト数。
• データ設計：行サイズ、読み書き比率、整合性レベル、パーティションキー、クラスタリングキー。
• 運用条件：TTL、バックアップ、リージョン数。

API、認証、画面は、別々の項目として書きます。CRM・MA連携や移行、監視も、項目ごとに示します。

障害対応やテストも、あわせて書きます。教育と納品物も含めます。単一・マルチリージョン、オンデマンド・プロビジョンド、既存Cassandra移行・新規構築の案を求めると、方式を選ぶ根拠を比べられます。

PoCから設計・開発・テストへの段階的な進め方

採用に不安がある場合は、代表的な営業シナリオを使ったPoCを先に発注します。実データに近いサイズで処理を動かし、性能と費用を測ります。

• イベント取得：顧客ID単位での直近イベントの読み出し。
• 配信結果の記録：MA配信結果の追記。
• 古いログの削除：TTLを使った古いログの削除。

PoCで測定するのは、レイテンシーとエラー率です。WRU・RRUと想定月額も、あわせて押さえます。

PoCの後は、テーブル設計やAPI、認証を固めます。さらに、監視やIaC、CI/CDの方針も決めます。

本番移行では、一括ロードとデュアルライトを設計します。整合性の照合や段階的な切り替え、ロールバックも、設計に含めます。

AWS公式のAdobe事例では、既存CassandraとKeyspacesへのデュアルライトを行いました。さらに、AWS Glueで履歴データを移行し、約6か月でほぼ停止なしの移行を実現しています。

これは大規模チームによる公開事例で、一般案件の納期を保証するものではありません。

契約形態と委託範囲の決め方

開発では、要件が固まった部分とPoCで検証する部分が混在しやすいです。そのため、契約名だけで決めず、工程ごとに分けて検討します。

要件定義・PoC、設計・開発、移行・運用支援の工程に分けます。そのうえで、成果物と責任を文書で確認し、検収条件と変更手続も書面に残します。

成果物と完成条件を明確にできる場合の請負契約

請負契約は、合意した成果物を受託者が完成させ、発注者が検収する関係を作りやすい契約です。そのため、納品対象と検収基準を明示できる工程に適しています。

• 設計・開発成果物：テーブル定義書、API仕様書、アプリケーション、IaCコード。
• 試験・移行成果物：テスト結果、移行手順書。
• 運用成果物：運用Runbook。

検収基準には、画面数や機能数に加えて、性能や可用性を含めます。復旧時間やデータ整合性も、検収基準に入れます。

データモデルが未確定のまま完成責任を請負側に置くと、変更費用や納期遅延を招くことがあります。そこで、要件定義やPoCは準委任で進め、本番実装の一部を請負に切り替える方法も検討します。

検証や専門家の継続支援に向く準委任契約

準委任契約は、作業や専門知識の提供を受ける形態です。要件整理や構成検討、負荷試験などの検証作業に向きます。移行計画やAWSコストレビュー、運用改善にも使えます。

• 月ごとの範囲：作業範囲と会議体。
• 進捗の記録：成果報告、設計判断の記録、課題一覧。
• 完了条件：次月の完了条件と納品資料。

検証の結果、採用DBを変える場合や、CRM本体をRDBに残す場合でも、実態に合わせて進めやすい契約です。

稼働時間を費やすだけで終わらせないため、レビュー記録や性能試験結果など、意思決定をたどれる資料を納品物に指定します。

契約書に書く成果物・権利・運用責任

契約書や個別仕様書で、成果物の帰属と納品範囲を確認します。ソースコードを受け取っても、設計意図や運用手順が分からなければ、引き継ぎや内製化は難しくなります。

• 設計・開発：設計書、CQL、API仕様、テストコード、ソースコード。
• 基盤・移行：IaC、CI/CD設定、AWSリソース、移行スクリプト。
• 運用：監視アラーム、手順書。

個人情報を扱う場合は、権限と秘密保持、再委託の扱いを定めます。保管場所やログの保存期間も決め、削除依頼と事故報告の手順を用意します。さらに、終了時の返却・消去も契約に入れます。

AWS公式資料では、TLS 1.2が必須です。加えて、IAMやSigV4、VPCエンドポイントも組み合わせられます。

ただし、暗号化機能があっても、自社の法務・情報セキュリティ要件を満たすとは限りません（出典: AWS公式「Infrastructure security in Amazon Keyspaces」、2026年確認）。

Amazon Keyspacesのシステム発注にかかる費用相場と内訳

費用は、AWS利用料、APIや連携を含む開発費、リリース後の保守・監視費に分けて見積もります。

AWS料金ページの比較には、インフラ保守や運用担当者、サポートなどの総保有コストは含まれません。そのため、発注を判断するときは、データベース単体の安さより費用全体を見ます。

AWS利用料を左右するWRU・RRU・容量・追加機能

オンデマンド容量モードは、実際に行った読み書きをRRU・WRUで計測します。一方、プロビジョンド容量モードは、予測した毎秒容量を基準にします。そのうえで、AWS公式料金ページの単位を確認し、実際のアクセスパターンで試算します。

• 書き込み処理：1KBまでの1行書き込みは1WRUです。
• 読み取り処理：4KBまでのLOCAL_QUORUM読み取りは1RRUです。
• 追加機能と周辺費用：PITR、TTL、Streams、PrivateLink、CloudWatch、API、NAT、データ転送。

たとえば、10KBの行を読む場合、LOCAL_QUORUMでは3RRUになります。

2リージョンのマルチリージョン環境で3KBの行を書くと、リージョンごとに計測されます。その場合、合計は6WRUです（出典: AWS公式「Amazon Keyspaces pricing」、2026年確認）。

小規模な検証では、最初の3か月に月3,000万オンデマンドWRUが無料です。また、月3,000万オンデマンドRRUと1GBのストレージも無料利用枠に含まれます。無料利用枠は支払アカウント単位です。

あわせて、開始月や適用条件を確認します（出典: AWS公式料金ページ、2026年確認）。

追加機能や周辺サービスも別費用を生むため、見積は機能ごとに分けてもらいます。そのうえで、PITRの対象表やTTLの削除量、PrivateLinkのエンドポイント数も確認します。

開発会社への費用を左右する検証範囲と本番要件

開発費は、PoCの有無やデータ移行、連携、性能・監査要件の範囲によって変わります。そのため、検証だけの依頼と本番開発を含む依頼は、分けて見積もります。

• PoC・データモデル検証：100万円〜300万円。
• 単一機能のイベント蓄積・API連携：300万円〜1,000万円。
• CRM・MAの一部を本番化：1,000万円〜3,000万円。
• 大規模移行や監査要件：3,000万円〜1億円超が初期の検討レンジ。

大規模移行には、既存Cassandraからの移行やマルチリージョンが含まれる場合があります。監査要件まで含む場合もあります。これらの金額は、Keyspaces専用の公定価格ではありません。

これは、リサーチノートにあるクラウド業務システムの相場を、設計・移行・非機能試験を含む案件に読み替えた推定です。

開発期間の目安は、PoCが4〜8週間、最小構成が3〜6か月です。連携や移行を含む中規模案件は6〜12か月、大規模移行や複数拠点の運用設計まで含む場合は12〜24か月程度です。

総額の予算化（AWS・開発・保守の3層）

予算は、AWS利用料、開発費、運用保守費に分けて考えます。そのうえで、規模や工程によって異なる目安を、同じ条件で比べます。

• 小規模な本番のDB・バックアップ：単一リージョン、数GB〜数十GB、数百万〜数千万件の読み書きで月額3,000円〜5万円程度。
• 小規模構成のAWS全体：APIや監視を含め月額1万円〜15万円程度。
• 中規模イベント基盤：Keyspaces関連は月額10万円〜100万円程度。
• 中規模構成のAWS全体：アプリ、ETL、分析、マルチリージョンを含み月額50万円〜300万円以上の初期レンジ。

これらは、アクセス量や構成が未確定な段階の予算枠です。そのため、実際の料金表に合わせて、リージョンや行サイズ、読み書き回数で再計算します。

工数配分の参考は、要件定義10〜15%、設計15〜35%です。実装は30〜40%、試験は15〜20%、移行・教育は5〜10%です。

データクレンジングや性能検証を削って安く見せる見積には、注意が必要です。運用費には、コストレビューや障害対応を含めるかを明記してもらいます。削除依頼と性能改善についても、含めるかを示してもらいます。

見積もりの比較と委託先の選定

要件定義や移行、テストを省いた提案は、見積金額だけを見ると安く見えることがあります。そのため、RFPと同じ前提条件で、工程や作業時間、成果物を比べます。さらに、見積の前提や除外事項、追加費用も確認します。

要件定義書とRFPで渡す同じ条件

候補会社へ渡す資料には、現行構成と対象業務、画面・APIを記載します。また、データ項目と処理量、性能目標も書きます。さらに、移行対象と希望時期も加えます。

• 現行と業務：現行構成、対象業務、画面・API一覧。
• データと性能：項目、月間件数、ピーク時秒間リクエスト、目標レイテンシー、保持期間。
• 移行と時期：移行対象、希望リリース時期。

「大量データだから」という理由に加えて、読み書きシナリオや、JOINや検索を担うシステムも示します。

提案書では、パーティションキーとホットパーティション対策、整合性を確認します。再試行やTTL、削除の扱いも見ます。

PITRや監視の扱いに加え、移行とロールバックまで計画に含まれるかを確認します。数値の根拠が負荷試験やAWS料金計算に結び付いているかを見れば、後の仕様変更を減らせます。

委託先の担当者に確認する経験

選定では、会社の実績に加えて、担当者の経験と設計レビューへの参加を確認します。なお、Keyspacesの公開実績が少なくても、候補になり得ます。

• AWS：AWS上の構築やデータ移行。
• NoSQL：Cassandraのクエリ起点設計やDynamoDBなどの運用。
• 業務と移行：業務システム、イベント基盤の性能試験、移行・運用。

担当者には、WRU・RRUと行サイズの見積もり方を尋ねます。あわせて、マルチリージョンの競合や、デュアルライト中の不整合の検知についても質問します。IaCやソースコードの納品範囲、障害時の一次対応時間、月額監視費も確認します。

設計書のサンプルやテスト結果を示せる会社は、発注後の連携を判断する材料になります。

安すぎる見積の対象外と追加費用

初期費用が低くても、本番前後に追加費用が発生しやすい条件があります。そのため、見積もりの対象外や別契約の範囲を確認します。

• 工程の対象外：要件定義なし、性能試験なし、移行は別途。
• 運用の対象外：監視は別契約、AWS費用は実費。
• 本番移行の作業：データ整備、夜間切り替え、ロールバック、削除処理、引き継ぎ。

高額な提案でも、すべてをフルスクラッチにしているとは限りません。たとえば、CRM画面を既存パッケージやRDBに置き、Keyspacesを大量イベントに限る案なら、リスクと費用を抑えられる場合があります。

3社程度から同じ要件で提案を受け、金額と期間を並べて比べます。体制や納品物、運用条件も合わせて見ます。

Amazon Keyspacesのシステム発注でよくある質問

発注前によく相談される疑問を並べました。自社のデータ量や要件に当てはめて、提案依頼書に加える確認事項として使えます。

既存のApache CassandraからAmazon Keyspacesへ移行する場合の発注方法は何ですか？

CQLやドライバーの互換性を確かめるとともに、データモデルや利用機能を洗い出します。さらに、アクセスパターンと運用手順も一覧にします。

まず、一括ロードやデュアルライト、照合を含む移行PoCを発注します。段階切り替えとロールバックも、その中で確かめます。そのうえで、本番移行は別工程として契約する方法が安全です。

AWS公式のAdobe事例でも、既存環境とKeyspacesへのデュアルライトや、AWS Glueによる履歴データ移行が使われています。

CRM全体をAmazon Keyspacesへ載せるべきですか？

CRM全体を載せるより、まずは顧客マスタや商談をRDBや業務パッケージに残す構成から検討します。Keyspacesは、行動イベントや配信ログの格納層として使います。

JOINや自由検索が中心の場合は、Keyspaces単独では設計が難しいため、読み書きパターンを確かめます。必要に応じて、検索・分析基盤と連携します。

Keyspacesの実績が公開されていない会社へ相談してもよいですか？

相談はできます。ただし、AWS構築の経験だけで判断せず、Cassandraや類似NoSQLの設計経験を確認します。

加えて、AWS移行や負荷試験、監視の経験を見ます。個人情報管理の経験も確認します。

実績を公開できない場合は、担当予定者の設計書サンプルやPoCの進め方を確かめます。WRU・RRUの算定方法と、障害対応体制も見ます。

Amazon Keyspacesの月額費用は契約前に確定できますか？

利用量やリージョン、行サイズが未確定なら、正確な月額は確定できません。読み書き比率や容量モード、追加機能（PITR、TTL、Streams、PrivateLink）も、試算の前提として固める必要があります。

• 試算の前提：AWS料金表やコスト計算ツールに入力した条件。
• 予算管理：月額の試算レンジ、予算アラート。
• 見直し頻度：実績との差を確かめる間隔を、見積書・運用契約に記載。
• 費用の区分：開発会社の費用とAWSの実費を別欄にする。

まとめ：要件・契約・費用を分けた発注の要点

外注時は、CRM全体ではなく、イベントログや大量・低遅延データのどこに使うかを決めます。アクセスパターンや行サイズ、WRU・RRUを、要件とRFPにまとめます。保持期間やセキュリティ、移行方式も、同じ資料に書きます。PoCでは、性能と費用を測ります。

発注前に確認する要点

委託先は、AWSの経験だけでなく、Cassandra・NoSQLの設計経験も確認して選びます。既存連携や移行、負荷試験の経験を見ます。監視や個人情報対応の経験も確かめます。

請負と準委任は、工程ごとに使い分けます。成果物と検収の条件は契約書に記載し、ソースコードやIaCも納品範囲に含めます。

移行仕様やRunbookも盛り込みます。再委託と障害対応の扱いも、同じ契約書で定めます。

最初の相談で用意する資料と質問

事業に合う提案を比べられるよう、相談の前に資料と発注条件を整理します。

• 現行資料：現行構成図、データ項目。
• 規模と要件：月間件数、ピーク処理量、保持・削除要件。
• 発注条件：希望時期、予算枠、想定する納品物。
• 提案の比較：同じ条件での設計根拠、試験方法、費用内訳、追加費用。

資料と質問をそろえておけば、Keyspacesを使うこと自体ではなく、事業に合うシステムを発注しやすくなります。

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

▼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を創業。