データストアの配置方針 ― RDBMS/NoSQL/キャッシュ/検索の組合せ ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第6弾として、データストアの全体配置方針について解説する記事です。

2026年は RDBMS・KVS・検索エンジン・時系列DB・ベクトルDB・オブジェクトストレージを用途特化で組み合わせるのがデフォルト。「何をどこに置くか」の設計が運用コストとレイテンシを決めます。本記事はシステム全体の配置方針に特化し、各カテゴリ概要・Polyglot Persistence・スケール戦略・バックアップ設計まで扱います（個別アプリの詳細選定は別カテゴリ「データアーキテクチャ」へ）。

本記事のテーマについてさらに詳しく知りたい方は『システム設計のセオリーと実践方法がこれ1冊でしっかりわかる教科書』も参考にしてみてください。

そもそもデータストアとは何か

データストアとは、ざっくり言えば「アプリケーションが扱うデータを保管・取り出しする仕組みの総称」です。

図書館を想像してください。書籍は本棚（RDBMS）に整然と並べ、よく参照される辞典はカウンター横（キャッシュ）に置き、ポスターや写真は別棟の倉庫（オブジェクトストレージ）に収めます。1か所に全部詰め込むと溢れるし探せない──用途ごとに最適な保管場所を選ぶのが、データストアの配置方針です。

本記事の守備範囲

データストア選定は「システムアーキテクチャ段階の全体方針」と「個別アプリケーションアーキテクチャでの詳細選定」の2段階で決まります。本記事は前者、つまりシステム全体として何をどう配置するかに特化します。

本記事の立場は「システムアーキテクチャ設計時にRDBMS / NoSQL / キャッシュ / 検索 / オブジェクトストレージをどう組み合わせるか」の全体地図です。データ量や機能要件に基づく具体の選定フローは別カテゴリ「データアーキテクチャ」の記事で扱います。

本記事の問いは「どのデータストア種を組み合わせるか」です。個別の選定フローは別カテゴリで深掘りします。

なぜデータストアの配置方針が重要なのか

もしデータストアの配置を深く考えずに進めたらどうなるか。「とりあえず全部RDBMSに入れておこう」で始めたシステムが、半年後にアクセス集中でレスポンス10秒超え──慌ててキャッシュを足そうにも、アプリのデータアクセス層を丸ごと書き直す羽目になります。逆に流行りに乗って NoSQL を選んだら、後から「やっぱりJOINが必要だった」と気づいても、数千万件のデータ移行は数日〜数週間のダウンタイムを伴います。

データストアの選定は、システムアーキテクチャの中で最も後戻りが困難な判断です。アプリのコードは書き直せても、スキーマと大量データが積み上がった後のDB移行は桁違いに重いのが現実です。現在は RDBMS・NoSQL・キャッシュ・検索エンジン・オブジェクトストレージを組み合わせるのが本命で、ここで「何を選んだか」が向こう5〜10年を左右します。

「後から考える」が通用しない領域です。最初の判断が重要になります。

主な4カテゴリ

データストアは用途別に4つのカテゴリに大別できます。それぞれ得意な用途が異なるため、1つのシステム内で複数を組み合わせるのが現代の主流です。

加えてオブジェクトストレージ（S3等）が画像・動画・添付ファイルの保管先として使われます。どのデータをどこに置くかの設計センスが、アプリ全体のパフォーマンスと運用コストを決めます。

RDBMS（リレーショナルデータベース）

RDBMS は、データを表（テーブル）形式で管理し、SQLで操作する伝統的なデータベースです。ACIDトランザクション（Atomicity 原子性・Consistency 一貫性・Isolation 独立性・Durability 永続性）による強整合性を保証し、金融・業務アプリなどデータの正確性が絶対に必要な領域で圧倒的な実績があります。

新規案件で特別な理由がない限り、PostgreSQLを選ぶのが鉄板です。JSON型・全文検索・GISなど多機能さがOSSの中で突出しており、拡張性でも他を引き離しています。MySQLは古くからのWebサービスに多く、今も現役で戦えますが、新規選定では PostgreSQL に軍配が上がる場面がほとんどです。

新規の第一候補はPostgreSQLです。迷ったらここから疑います。

NoSQLの4系統

NoSQL は「Not Only SQL」の略で、RDBMS以外のデータベース全般を指します。スケール性と柔軟なデータ構造が特徴で、用途により4つの系統に分かれます。

NoSQLの基本思想は「RDBMSの整合性を犠牲にしてでもスケールさせたい」です。ECの商品カタログ・SNSの投稿履歴・IoTログのような「大量データを高速に書き込みたい」ケースで本領を発揮します。逆に整合性が命の業務アプリで選ぶのは筋が悪いです。

DynamoDB と Redis

DynamoDB（AWS製）とRedisは、NoSQLの中でも特に実務でよく使われる2大製品です。似たKVSですが、得意領域がはっきり違います。

DynamoDBはフルマネージドの分散KVSで、「スケールを意識せず書き込める」のが最大の利点です。理論上無限にスケールし、サーバーレスアーキテクチャと相性が良いため、高トラフィックAPIで選ばれます。ただしJoin・集計が苦手で、RDBMSと逆に「先にアクセスパターンを決めてテーブル設計する」発想が必要です。

Redisはインメモリキャッシュ用途のデファクトスタンダードです。メモリ上にデータを置くためミリ秒未満のレスポンスを実現し、セッション管理・ページキャッシュ・レート制限・ランキング（ZSET）・Pub/Sub など用途が幅広いです。

DynamoDBはスケール特化、Redisはキャッシュ特化。役割が違います。

検索エンジン

検索エンジンは、文章や商品説明などのテキストの中身を素早く検索する専用DBです。RDBMSでも LIKE '%キーワード%' は可能ですが、数万件を超えると遅すぎて実用にならないため、専用の検索エンジンを別に用意するのが定石です。

日本語全文検索では、形態素解析（Kuromoji）の設定が鍵を握ります。日本語は単語の切れ目が明確でないため、適切な辞書を使わないと「東京都」が「東京」と「都」に分解される、といった検索漏れが連発します。

オブジェクトストレージ

オブジェクトストレージは、画像・動画・PDFなどのファイルを保管するための専用ストレージです。RDBMSに画像を直接入れるとDBが肥大化して性能が落ちるので、「メタデータはRDBMS、実体はオブジェクトストレージ」という分離が基本です。ここを守らないのは典型的な地雷踏みです。

CDN（CloudFront等）と組み合わせると、配信の高速化とトラフィックコスト削減が同時に効きます。Cloudflare R2 は S3互換で帯域課金がないため、動画配信など帯域が支配的な用途で注目されています。

用途別の選び方

複数のデータストアを役割ごとに使い分けるのが現代の主流です。典型的な構成は以下の通りです。

用途ごとに最適なDBを組み合わせる考え方を Polyglot Persistence（多言語永続化）と呼びます。

Polyglot Persistence

Polyglot Persistence は、1つのシステムで複数のデータストアを組み合わせて使う設計思想です。「1つのDBで全部」は設計的には綺麗に見えても、用途ごとに最適なDBを選ぶ方が性能・コスト・運用性のバランスで勝ちます。

ECサイト・SaaSプロダクトでは、この種の分業構成がほぼ標準です。各データストアは同期的に連携せず、非同期メッセージキュー（SQS/Kafka等）でつなぐのが障害耐性の観点でも筋がいい設計です。同期で繋いでしまうと、1つのDBが落ちた瞬間に連鎖停止が起きます。

「1DBで全部」は過去の話。役割ごとに最適な道具を使うのが現代流です。

スケールとレプリケーション

データ量やアクセス数が増えると、DBは単一サーバーで処理しきれなくなります。レプリケーションとシャーディングでスケールさせるのが基本戦略です。

クラウドマネージドDB（Aurora・Cloud SQL・Cosmos DB）を使うと、これらの複雑な構成をスイッチひとつで有効化できます。自前構築との運用コスト差は圧倒的で、「自前でシャーディングを組むのは相応の体力がないと手を出さない方がいい」というのが実務的な結論です。

バックアップとリストア

データストアのバックアップ戦略は、障害・誤操作・ランサムウェア対策の最後の砦です。肝心なのは「取っているか」ではなく「戻せるか」リストア訓練を定期実施しないと、いざという時に復旧できない事例が今でも繰り返し発生しています。

クラウドマネージドDBはPITRが標準機能で、過去5〜35日の任意の時点に戻せます。年次・月次の長期保管は別途エクスポートが必要なケースが多いです。

データ量・トラフィック別のDB選定

「なんとなくPostgreSQL」は正解率が高いですが、データ量とトラフィックの段で選ぶ最適解が変わります。下記は2026年4月時点の目安です。

データ量が1テーブル1,000万行を超えたらインデックス設計とパーティション検討、1億行でシャーディング検討、10億行でNoSQL選択肢が現実的。というのが経験則です。先にキャッシュ（Redis）を足すだけで改善する場面は多く、DBを替える前にキャッシュで済む検証を先にすべきです。

悩んだらPostgreSQL単一 → キャッシュ追加 → レプリカ追加 → シャーディングの順。いきなりNoSQLは筋が悪いです。

AI時代の判断軸 ― データストア選定はどう変わるか

AI駆動開発が前提になると、データストアの選定軸に「スキーマをコードで管理できるか」「AIがクエリ・マイグレーションを正確に書けるか」が加わります。ただ、それだけの話ではありません。AI時代はデータストアの使われ方そのものが変わってきています。

SQLとAI生成精度の関係

AIにコードを書かせたとき、SQLの精度は他のクエリ言語と比べて圧倒的に高いです。50年の歴史で蓄積された膨大な学習データがあるので、当然と言えば当然です。一方、DynamoDBの PartiQL や MongoDBの集約パイプラインは独自性が高く、AIが正しく書けないケースが頻繁に発生します。

これは「NoSQLを使うな」という意味ではありません。DynamoDBやRedisが最適な用途は変わりません。ただし、AIにクエリを書かせる前提で設計するなら、アクセスパターンを型で定義する（TypeScript型定義 → DynamoDB操作コード生成）など、AIが正確にコードを書ける仕組みを意図的に用意しておく必要があります。

ベクトルDBという新しい層

2024年以降、Polyglot Persistence に「ベクトルDB」という新しい層が加わりました。RAG（Retrieval-Augmented Generation）を使ったAI機能をプロダクトに組み込む場合、テキストや画像をベクトル化して格納・検索する専用のデータストアが必要です。

判断の分かれ目は「既存のPostgreSQLにpgvectorを足すか、専用DBを立てるか」です。ベクトル数が100万件以下ならpgvectorで十分で、余計な運用を増やさない方がいい。100万件を超えて検索レイテンシが問題になったら専用DBへの分離を検討する、という段階的アプローチが現実的です。

スキーマ管理とAI活用の前提条件

AIはマイグレーションSQLの生成が得意です。「user_name列をfull_nameに改名したい」と伝えれば、expand/contractパターンに沿った3段階のマイグレーションを正しく生成してくれます。ただし、これが機能するには前提条件があります。

1. スキーマがコードで管理されている — Prisma Schema / Drizzle Schema / SQL マイグレーションファイルがGitに入っている
2. 既存のマイグレーション履歴がある — AIは過去のマイグレーションパターンを文脈として読み込んで、プロジェクトの慣習に合わせた出力を行う
3. テーブル定義とアプリコードが同じリポジトリにある — AIがスキーマ変更とアプリコード変更の整合性を一度に確認できる

逆に言えば、GUIでスキーマを管理していてコードに定義がない状態では、AIはマイグレーション支援ができません。「スキーマをコードで管理する」はもはや技術的な好みの問題ではなく、AI活用の前提条件です。

AI機能をプロダクトに組み込む場合のデータ設計

プロダクトにAI機能（チャット・レコメンド・要約等）を組み込む予定がある場合、データストア設計の段階で以下を考慮しておく必要があります。後から追加しようとすると、既存テーブルとの関連付けやデータ移行で苦労します。

選定の優先順位

1. データの性質（強整合／結果整合／キャッシュ）でカテゴリを絞る
2. 規模とアクセスパターンから用途別DBを足す判断（先に正規化DBで始める）
3. スキーマをコードで管理できるかをAI時代の必須要件にする
4. ベクトルDB の要否を早期に判断する — AI機能のロードマップがあるなら、pgvector対応のPostgreSQLを最初から選んでおく
5. バックアップ + リストア訓練の運用コストを前提に置く

やってはいけないこと

「DBは後から変えられない」の本番を決めるのがスキーマ変更と選定ミスです。禁じ手を徹底回避します。

2017年1月31日の GitLab DB削除事件（エンジニアが本番と開発を取り違えて rm -rf、5種類のバックアップが全滅）は、バックアップ戦略だけでなくDB操作の権限管理・二重確認の重要性を示す事例です。

スキーマ変更は「マイグレーションツール + PR レビュー + 段階適用」の3点セットを省略すると必ず事故ります。

MongoDB の「なんとなく」事件（業界事例）

スタートアップで「スキーマを自由に変えたいから」という理由だけで MongoDB を選び、半年後にECの注文履歴から売上レポートを集計するフェーズに入った瞬間に、Join もトランザクションもほしい仕様が次々に出てきて現場が止まった。という事例は一度ならず聞かれます。結局 PostgreSQL に移行し、移行作業そのものに3ヶ月を溶かしたチームもあるといいます。

2018年頃、似たような流れで MongoDB 採用のスタートアップを見ていたことがありますが、注文集計の要件が出た瞬間にクエリが書けず、結局BIツールに回すためにPostgreSQLへの日次同期を入れる羽目になったと聞きました。

教訓は、「DB選定は今の楽さではなく、1年後の要件で決める」ということです。特にトランザクションが絡むアプリは、悩んだらRDBMSから始める。必要になったときだけNoSQLを足す、の順序を逆にすると痛い目を見ます。

「スキーマレスが楽」は、集計が始まるまでの話です。

決めるべきこと — 自分のプロジェクトでの答えは？

以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• メインDB（PostgreSQL / MySQL / Aurora / DynamoDB）
• キャッシュ戦略（Redis / Memcached / アプリ内 / CDN）
• 検索基盤（OpenSearch / PostgreSQL全文検索 / SaaS）
• ファイルストア（S3 / R2 / Blob Storage）
• バックアップ方針（RPO / RTO / 保管期間）
• 暗号化（保存時・転送時・鍵管理）
• スケール戦略（レプリカ / シャーディング / マルチリージョン）

決定理由の残し方

データストアの選定は長期にわたってシステム全体に影響するため、なぜその製品を選んだかをADRとして記録に残すことが重要です。以下に具体例を示します。

数か月後・数年後に「なぜMySQLではなくPostgreSQLなのか」を新メンバーが問い合わせてくる場面は必ず訪れます。後から見返したとき「なぜこの選択をしたか」が一目でわかることが、ADR の最大の価値です。

この記事に関連する記事

https://senkohome.com/arch-intro-system-cloud-vendor/ https://senkohome.com/arch-intro-system-security/ https://senkohome.com/arch-intro-system-application-types/

まとめ

本記事はシステムアーキテクチャレベルでのデータストア配置方針について、Polyglot Persistence・スケール戦略・スキーマ変更の鬼門まで含めて解説しました。如何だったでしょうか。

新規はPostgreSQL中心に、用途特化を必要最小限で足す（キャッシュにRedis、検索にOpenSearch、画像にS3）のが2026年の鉄板です。最初から多層構成は運用が破綻するので、足りなくなってから足す順序が現実的です。

次回は「ネットワーク」（VPC・サブネット・CIDR設計）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

本記事で扱った内容の詳細は AWS データベースサービス も合わせて参考にしてください。

それでは次の記事も閲覧いただけると幸いです。