データ整合性モデル入門｜CAP定理・強整合性・結果整合性をクラウドDB選定と設計に活かす実践ガイド

2026年6月26日2026年7月2日

オンプレでOracleやSQL Serverを使い続けてきたエンジニアがクラウドのDBドキュメントを読んだとき、「結果整合性」「強整合性」「CAP定理」という言葉に戸惑うのは珍しくありません。オンプレのRDBMSではトランザクション（ACID）が当たり前だったのに、なぜクラウドのDBは整合性を「選ぶ」必要があるのか——この違和感こそが、分散システムを理解する入口です。

この記事では、クラウドDB設計で必須となるデータ整合性モデルについて、CAP定理の基礎から実務でのサービス選定まで、オンプレ経験者向けにわかりやすく解説します。取り上げる内容はこのとおりです。

・CAP定理の3要素と「なぜ3つ全ては選べないのか」の直感的な理解
・強整合性・結果整合性・BASE原則の違いと使い所
・Amazon DynamoDB・Azure Cosmos DBなどのクラウドDBが提供する整合性モデル
・ユースケース別の整合性モデル選択基準とよくある落とし穴

なぜクラウドDBで整合性が問題になるのか

オンプレのRDBMS（OracleやSQL Server、PostgreSQLなど）は、基本的に1台のサーバー上でデータを管理します。複数ノードに分散する場合でも、ほとんどのケースで「プライマリ1台」に集約して書き込みを行うため、「書いたデータをすぐ読める」のは当然のことでした。

クラウドの分散DBでは、この前提が根本的に変わります。

・データが複数のAZ・リージョンにまたがって複製される
・ネットワーク遅延や一時的な分断（パーティション）が必ず発生する
・スケールのためにノードを水平分散させる設計が基本となる

これらの要因が重なることで、「ノードAに書いたデータをノードBで読んだとき、まだ反映されていない」という状況が起こり得ます。これを「整合性の問題」と呼びます。

オンプレ経験者には「そんな設計、バグじゃないか」と感じる人もいますが、分散システムの世界では意図的なトレードオフです。なぜそのようなトレードオフが生まれるのかを説明するのが、CAP定理です。

CAP定理とは何か

CAP定理は2000年にEric Brewerが提唱した理論で、「分散システムは以下の3つの性質を同時にすべて満たすことはできない」と主張します。

・C（Consistency / 一貫性）: すべてのノードが同じタイミングで同じデータを読める
・A（Availability / 可用性）: システムが常にリクエストに応答できる
・P（Partition Tolerance / 分断耐性）: ネットワーク分断が発生しても動作し続けられる

ここで重要なポイントがあります。クラウドの分散システムにおいて、Pは「回避の選択肢がない」性質です。インターネット経由でノードが通信する以上、パケットロスやネットワーク障害による一時的な分断は必ず起こります。「分断が起きたとき動かなくていい」という選択はビジネスとして成立しません。

したがって、実際の選択は「CとAのどちらを優先するか」に絞られます。

1. CPシステム（一貫性と分断耐性を優先）

ネットワーク分断が発生したとき、すべてのノードで最新データが確認できるまでリクエストへの応答を止める（またはエラーを返す）選択です。金融取引や在庫管理など、古いデータを返すほうが害になるシステムが該当します。

代表例: Apache ZooKeeper、HBase、Amazon RDS（シングルAZのプライマリ参照）

2. APシステム（可用性と分断耐性を優先）

ネットワーク分断が発生しても応答し続けますが、一時的に古いデータを返すことを許容する選択です。SNSのタイムラインやECサイトの商品カタログなど、多少の遅延よりもサービスが停止しないことが重要なシステムが該当します。

代表例: Amazon DynamoDB（デフォルト）、Apache Cassandra、Azure Cosmos DB（Eventual設定）

整合性モデルの種類

CAP定理はあくまで「一貫性か可用性か」の二択を示すフレームですが、実際のクラウドDBでは整合性をより細かく定義しています。代表的なモデルを整理します。

強整合性（Strong Consistency）

書き込みが完了した直後のどのノードへの読み込みも、最新データを返すことを保証します。オンプレのRDBMSで馴染みのある動作に最も近いモデルです。

実装としては、書き込みをすべてのレプリカに同期してから完了を返す（同期レプリケーション）か、クォーラム読み込み（多数決で最新を決定する）などの手法が使われます。レイテンシは高くなりますが、「読んだら必ず最新」を保証できます。

結果整合性（Eventual Consistency）

書き込み後、すべてのレプリカは「いずれ」同じ状態に収束することを保証しますが、収束するまでの間は古いデータが返ることがあります。書き込みを非同期でレプリカに伝播するため、書き込みレイテンシが低く、可用性も高くなります。

「いずれ同じになる」という言葉は曖昧に聞こえますが、AWSのような大手クラウドでは通常100ms以内、ほとんどのケースで数十ms以内に収束します。「秒単位でバラつく」という状況は一般的ではありません。

セッション整合性（Session Consistency）

同じセッション（クライアント）内では、自分が書いたデータを必ず読める（Read-your-writes）ことを保証します。他のクライアントからは結果整合性となりますが、自分の操作の範囲内では強整合性に近い動作をします。

Azure Cosmos DBのデフォルト設定がこのモデルで、SNSやECサイトのような「自分の操作結果はすぐ見たい、他人の操作は多少遅れてもいい」というユースケースに適しています。

モノトニック読み込み整合性（Monotonic Read Consistency）

一度読んだ値より古い値を返さないことを保証します。「さっき読んだら古いデータが返ってきた」という経験を防ぎます。DynamoDBのデフォルト読み込みはこの保証を含みます。

ACIDとBASE：2つの設計哲学

データ整合性を語るとき、「ACID」と「BASE」という2つの頭字語も頻繁に登場します。

ACID原則（従来のRDBMS）

・A（Atomicity / 原子性）: トランザクションは「全成功」か「全ロールバック」のどちらかだけ
・C（Consistency / 一貫性）: 制約やルールを常に満たした状態を保つ
・I（Isolation / 独立性）: 並行トランザクションが互いに影響しない
・D（Durability / 永続性）: コミット済みデータは障害が起きても消えない

ACID原則は「正確さ」を最優先します。銀行の振込処理やECの在庫引き当てなど、データの正確性がビジネスの根幹となる処理に向いています。

BASE原則（分散NoSQL）

・BA（Basically Available / 基本的に可用）: 常に何らかのレスポンスを返す
・S（Soft state / 軟状態）: 入力がなくても時間の経過とともに状態が変化する
・E（Eventual consistency / 結果整合性）: 最終的には整合した状態に収束する

BASE原則は「可用性」を最優先します。SNSのいいね数やECの閲覧数カウンターなど、多少の誤差があっても止まらないことが重要な処理に向いています。

ACIDとBASEは対立する概念ではなく、「どちらの方向でシステムを設計するか」という軸です。現代のクラウドDBは両者の間を柔軟に移動できる仕組みを持つようになっています。

クラウドDBサービスと整合性モデルの対応

理論を理解したところで、実際のクラウドサービスがどう実装しているかを確認します。

1. Amazon RDS / Aurora

マネージドRDBMSなのでACID原則に従います。プライマリインスタンスへの読み書きは強整合性が保証されます。

ただしリードレプリカ（読み込み専用のコピー）は非同期レプリケーションです。リードレプリカへの読み込みは結果整合性となり、レプリカラグ（遅延）が発生します。

Aurora Global Databaseでは、セカンダリリージョンへのレプリケーションは非同期で、RPOは通常1秒未満です。「グローバル展開しても強整合性が欲しい」という場合には適していません。

2. Amazon DynamoDB

DynamoDBはデフォルトで結果整合性の読み込みを提供します。強整合性が必要な場合はAPIパラメータで指定できます。

# AWS CLI — DynamoDBの強整合性読み込み aws dynamodb get-item \ --table-name Orders \ --key '{"OrderId": {"S": "ORD-12345"}}' \ --consistent-read # このフラグで強整合性を指定 # デフォルト（結果整合性）では --consistent-read を省略する

強整合性読み込みは読み込みキャパシティユニット（RCU）を2倍消費します。コスト面のトレードオフがあるため、「本当に最新データが必要な処理だけ」に限定して使うのが現場での定石です。

DynamoDB Transactionsを使えば、複数アイテムにまたがるACIDトランザクションも実現できます。ただしコストは通常の2倍で、スループットにも影響します。

3. Azure Cosmos DB

Cosmos DBは業界でも珍しい「5段階の整合性レベル」を提供します。

整合性レベル	特徴	適したユースケース
Strong（強整合性）	読み込みは必ず最新値を返す	金融トランザクション、在庫管理
Bounded Staleness（有界整合性）	最大K操作またはT秒以内の遅延を保証	リアルタイムゲームのスコア、株価表示
Session（セッション整合性）	同一セッション内は強整合性（デフォルト）	ECサイト、SNS、ユーザープロファイル
Consistent Prefix（一貫したプレフィックス）	書き込み順序は保証、遅延は許容	ソーシャルメディアのアクティビティログ
Eventual（結果整合性）	最も可用性が高く、最も整合性が弱い	商品レビュー数、ページビューカウンター

整合性レベルが強くなるほど、レイテンシが上がりスループットが下がります。Cosmos DBの場合、アカウントレベルでデフォルト整合性を設定し、リクエストごとに「より弱い整合性」へダウングレードする形で柔軟に調整できます（強い方向へのアップグレードはできない点に注意してください）。

4. Google Cloud Spanner

Spannerは「外部整合性（External Consistency）」を提供します。これはCAP定理のCP分類の中でも最も強い保証で、分散トランザクションを世界規模でACIDに保てます。GoogleのTrueTime API（GPS・原子時計ベースの時刻同期機構）が基盤となっており、他のサービスでは真似できない強みです。

コストはDynamoDBやRDSより大幅に高くなりますが、「グローバルで強整合性が絶対必要」なユースケース（グローバルECの在庫、金融決済）では検討に値します。

ユースケース別の整合性モデル選択基準

理論がわかったところで、実務でどう判断するかを整理します。

強整合性が必要なケース

・金融決済・送金: 残高の二重読み込みや二重送金は致命的
・在庫引き当て: 在庫ゼロなのに「在庫あり」と表示されると返品・クレームが発生する
・座席・部屋の予約: ダブルブッキングは顧客信頼を直撃する
・ログイン・セッション管理: 認証情報の不整合はセキュリティ問題になる

→ Amazon RDS / Aurora（プライマリ参照）、DynamoDB（ConsistentRead=true＋Transactions）、Cosmos DB Strong / Session

結果整合性で十分なケース

・SNSのタイムラインやいいね数: 数秒の遅れは誰も気にしない
・ECの商品閲覧数・レビュー件数: カウンターは多少ずれていても問題ない
・ニュースフィードのキャッシュ: 最新でなくても読めることが重要
・ゲームのランキング集計: リアルタイム性より応答速度を優先したい

→ DynamoDB（デフォルト）、Cosmos DB Eventual / Consistent Prefix

セッション整合性が現実的な落とし所になるケース

・ECのカート操作: 自分がカートに入れた商品はすぐ見たい（他人のカートは無関係）
・プロフィール更新: 更新直後に自分の変更が反映されていることを確認したい
・コメント投稿後の一覧表示: 自分のコメントがすぐ表示されないと「投稿できたか」不安になる

→ Cosmos DB Session（デフォルト）、DynamoDB（ユーザーIDに基づくルーティングで擬似的に実現）

よくあるトラブルと対処法

【ハマり1】DynamoDBから書き込み直後に古いデータが読める

DynamoDBのデフォルト読み込みは結果整合性です。書き込み直後に同じアイテムを読んだとき、古い値が返ることがあります。

「書いた直後に読んだのに値が変わっていない！バグか？」と混乱したエンジニアは多いです。

対処法: 最新データが必要な読み込みには --consistent-read を指定する。ただし全操作に付けると2倍のコストがかかるため、必要な箇所に限定して使うことが重要です。

【ハマり2】Aurora Global Databaseのセカンダリリージョンで古いデータが返る

Aurora Global Databaseのセカンダリリージョンは読み込み専用で、非同期レプリケーションです。プライマリに書いてすぐセカンダリで読んでも、通常RPOである1秒未満の遅延があります。

対処法: 「強整合性が必要な読み込みはプライマリリージョン」「参照系・レポート系はセカンダリリージョン」と明示的に振り分ける設計にする。

【ハマり3】Cosmos DBの整合性レベルをStrongにしたら書き込みが遅くなった

Cosmos DBのStrong整合性は、すべてのレプリカに同期してから完了を返します。マルチリージョン設定でStrongを選ぶと、地理的に離れたレプリカへの同期待ちが発生し、レイテンシが大幅に増加します。

対処法: マルチリージョンではBounded StalenessまたはSessionを検討する。Strongが必要な操作を1リージョンに集約する設計も選択肢です。

【ハマり4】「結果整合性だから多少ずれていい」が想定外の障害原因になる

結果整合性で設計したシステムで、ネットワーク輻輳やレプリカの再起動といった障害が発生したとき、「長時間古いデータが返り続ける」という状況になることがあります。

対処法: 結果整合性を採用する場合も、「最大どのくらいの遅延まで許容するか」をSLOとして定義しておくことが重要です。Cosmos DBのBounded Stalenessを使えば「最大X秒の遅延」を保証できます。

本記事のまとめ

データ整合性モデルは、クラウドDB設計の根幹です。ポイントを整理します。

・CAP定理: 分散システムでPは不可避。CとAのどちらを優先するかの選択になる
・強整合性: 書いたデータはすぐ読める。レイテンシは高いがデータの正確性を保証する
・結果整合性: 高可用性・低レイテンシだが、一時的に古いデータを返す可能性がある
・セッション整合性: 自分のセッション内では強整合性。多くのWebアプリで現実的な選択
・ACID vs BASE: RDBMSはACID（正確さ優先）、分散NoSQLはBASE（可用性優先）

サービス	デフォルト整合性	強整合性オプション	特記事項
Amazon RDS / Aurora	強整合性（プライマリ）	標準	リードレプリカは結果整合性
Amazon DynamoDB	結果整合性	ConsistentRead=true（RCU 2倍）	Transactionsで複数アイテムACID可
Azure Cosmos DB	セッション整合性	Strong（5段階から選択）	最も柔軟な整合性モデル
Google Cloud Spanner	外部整合性（最強）	標準	グローバル分散でACIDを保証

オンプレのRDBMSで「整合性は当然あるもの」と思っていたエンジニアにとって、分散DBの整合性モデルは最初の壁になります。しかし一度理解してしまえば、「なぜこのサービスがこの設計になっているのか」が腑に落ちるようになります。ユースケースと整合性モデルを照らし合わせ、設計の根拠を言語化できるエンジニアを目指してください。

Linuxサーバー上でDBを運用する際の基礎知識については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。