一貫性モデルの強弱階層図
結果整合性と線形化可能性の間にある段階を整頓。強い順に並べた包含関係をたどれば、どのモデルが何を許し何を禁じるかを一枚の地図として読めます。
- 1.一貫性モデルは「許される実行の集合」で順序づけられ、強いモデルほど許す実行が少なく、その実行集合は弱いモデルに包含される。
- 2.強い順の幹は 線形化可能性 → 順次一貫性 → 因果一貫性 → 結果整合性。線形化可能性だけがリアルタイム順序を要求し、合成可能（局所的→大域的）という決定的な利点を持つ。
- 3.セッション保証（read-your-writes・monotonic reads など）は結果整合性に局所的な順序を足した中間層で、因果一貫性より弱く結果整合性より強い。
一貫性モデルは「許す実行の集合」で並ぶ
分散データストアの一貫性モデルとは、並行する読み書きに対してどんな結果の見え方を許すかを定める仕様です。重要なのは、モデルを強弱で比べられる根拠が「許す実行（履歴）の集合の大小」にある点です。あるモデル A が許す全ての実行を別のモデル B も許すなら、B ⊆ A、つまり B のほうが強い（制約が多い）といえます。
強いモデルは許す実行が少ないので挙動が直感に近く推論しやすい反面、実装には強い同期（合意や同期レプリケーション）が要り、レイテンシと可用性を犠牲にします。弱いモデルはその逆です。この階層を正しく把握することが、CAP 定理で C と A のどちらに倒すかを決める前提になります。
強い順に並べた幹
主要モデルを強い順に並べ、何を要求し何を許すかを整理します。
| 順位 | モデル | 要求する順序 | 代表的に許す異常 |
|---|---|---|---|
| 最強 | 線形化可能性 (Linearizability) | 全操作の単一全順序 ＋ リアルタイム順序 | なし（直近の書き込みが必ず見える） |
| 強 | 順次一貫性 (Sequential) | 全操作の単一全順序（各プロセス内順序は保持） | 古い値が見えうる（実時間は無視） |
| 中 | 因果一貫性 (Causal) | 因果順序のみ（並行操作は順不同） | 因果のない更新の入れ替わり |
| 弱 | 結果整合性 (Eventual) | なし（最終的に収束のみ） | ほぼ全て（一時的に任意の古い値） |
包含関係は次の鎖になります。線形化可能 ⊂ 順次一貫 ⊂ 因果一貫 ⊂ 結果整合（記号の向きは「許す実行集合」の包含で、左ほど強い）。
強い ←─────────────────────────────────────→ 弱い
[線形化可能] ⊂ [順次一貫] ⊂ [因果一貫] ⊂ [結果整合]
実時間順序 全順序のみ 因果のみ 収束のみ
合成可能 合成不可 合成不可 合成不可
線形化可能性：実時間順序と合成可能性
線形化可能性は、全ての操作があたかも一瞬で（アトミックに）ある一点で発生したかのように見え、その並び順が実時間の前後関係に従うことを要求します。具体的には、操作 a が完了してから操作 b が開始したなら、順序上も a が b より前になければなりません。
これにより「書き込み完了の通知を受けた後の読み取りは、必ずその値か、より新しい値を返す」という強い保証が得られます。Raft などの合意ベースの線形化可能なストアでは、リーダー経由で全操作を一本のログに直列化することでこれを実現します（詳細は分散合意アルゴリズム）。
線形化可能性だけが持つ決定的な性質が 合成可能性 (composability / locality) です。
個々のオブジェクト（各レジスタや各キー）がそれぞれ線形化可能なら、それらを組み合わせたシステム全体も自動的に線形化可能になります。オブジェクトごとに独立して正しさを保証すれば全体が保証される、という意味で、大規模システムの正しさを部品ごとに分解して論証できます。順次一貫性以下にはこの性質がなく、各部品が正しくても全体は保証されません。
順次一貫性：全順序はあるが実時間は無視
順次一貫性は、全操作にある単一の全順序が存在し、各プロセスの操作はその個人内の発行順を保つことを要求します。線形化可能性との唯一にして決定的な差は、実時間（リアルタイム）順序を要求しないことです。
つまり「a が完了した後に b を始めた」という壁時計上の前後があっても、順序上は b を a より前に置いてよい。結果として、書き込み直後に別プロセスがまだ古い値を読むことが許されます。これが線形化可能性で禁じられていた異常です。マルチコア CPU のメモリモデルが古典的な例で、各コアの命令順は保たれるものの、他コアへの反映には遅延が許されます。
線形化可能: write(x=1) 完了 ──時間──> read(x) は必ず 1
順次一貫 : write(x=1) 完了 ──時間──> read(x) は 0 でも可
（全体で辻褄の合う一本の順序さえ作れればよい）
因果一貫性：因果のある操作だけ順序づける
因果一貫性は全順序を諦め、因果関係 (happens-before) で結ばれた操作の順序だけを全プロセスに守らせます。互いに因果関係のない（並行な）操作は、プロセスごとに別の順序で見えてかまいません。
因果関係は次の3つで定義されます。同一プロセス内の前後、書き込みとそれを読んだ読み取り（read-from）、そしてこれらの推移閉包です。「質問の投稿」と「その回答」のように、片方を見たうえで生じた更新は、全プロセスで必ずこの順に見えます。逆に無関係な2つの投稿は順不同でよい。
因果一貫性は、ネットワーク分断中でも各ノードが応答を返し続けられる（可用性を保てる）一貫性モデルの中で最も強いものとして知られています（Mahajan らの結果）。線形化可能性や順次一貫性は分断中に同期が要るため可用性を諦めますが、因果一貫性は各ノードがローカルの因果順序を尊重しつつ非同期に伝播させるだけで成立します。AP 型システムが「ただ収束する」以上の保証を欲しいとき、まず狙うのがこの層です。
セッション保証：結果整合性に足す局所的な順序
因果一貫性と結果整合性の間に、セッション保証という実務的に重要な中間層があります。これは単一クライアントのセッション（一連の操作）に対してだけ局所的な順序を約束するもので、システム全体の大域順序は要求しません。代表的な4つを挙げます。
| 保証 | 意味 | 破られると起こること |
|---|---|---|
| read-your-writes | 自分の書き込みは自分には必ず見える | プロフィール更新後の再読み込みで旧値が出る |
| monotonic reads | 一度新しい値を読んだら古い値に戻らない | リロードのたびに時間が巻き戻って見える |
| monotonic writes | 自分の書き込みは発行順に適用される | 後の更新が先の更新に上書きされる |
| writes-follow-reads | 読んだ値より後に書いた値は、その後に反映 | 返信が元投稿より先に見える |
これらはいずれも結果整合性に特定方向の単調性を足したもので、結果整合性より強く、しかし因果一貫性より弱い位置にあります。なぜ弱いかというと、セッション保証はあくまで1クライアント視点の約束であり、異なるクライアント間の因果関係（writes-follow-reads を全クライアントに拡張したもの）までは保証しないからです。因果一貫性は、この4保証を全クライアント横断で同時に満たしたものに相当する、と捉えると階層が腑に落ちます。
結果整合性：収束だけを約束する床
階層の床にあるのが結果整合性です。約束するのは一点だけ――「新しい更新が止まれば、いずれ全レプリカが同じ値に収束する」。この「いずれ」までの間は、レプリカは任意に古い値や、書き込み順と無関係な値を返してよく、ほとんどの異常が許されます。
収束を破綻なく行うため、結果整合な実装は衝突解決規則を持ちます。素朴な LWW（Last-Write-Wins）はタイムスタンプの大きい書き込みを採用しますが、時刻のずれで更新が消える危険があります。これを構造的に避けるのが CRDT（Conflict-free Replicated Data Type）で、結合則・交換則・冪等性を満たすマージ演算により、適用順に依らず同じ状態へ収束します。
結果整合性という言葉は「最終的に揃う」しか言っておらず、揃うまでの途中でどれだけ古い値や入れ替わりを許すかには一切触れません。だから「結果整合性です」だけでは実用上の安全性を判断できません。実際には read-your-writes などどのセッション保証を併せて持つかを確認しないと、ログイン直後に自分の変更が消えて見えるといった事故を防げません。製品仕様を読むときは「結果整合性」の語の隣にある追加保証に注目してください。
階層を実装コストと結びつける
なぜ強いモデルほど高くつくのか。強いほどレプリカ間の同期点を多く要求するからです。線形化可能性は全書き込みを一本の順序に通すため合意（過半数の同期）が要り、分断時は可用性を落とします。順次一貫性も大域順序のため同様の同期が要ります。因果一貫性は因果メタデータ（ベクタクロックなど）を運べばよく非同期伝播で済み、可用性を保てます。結果整合性は伝播が最も緩く最速・最も可用です。
トランザクションの分離レベルも同じ発想で並んでおり、Serializable が最強で Read Committed に向けて弱まります。両者は別軸（一貫性モデルは単一オブジェクトの可視性、分離レベルは複数オブジェクトの並行トランザクション）ですが、「強い保証ほど同期を要し遅い」という構図は共通です（トランザクション分離レベル、スナップショット分離と並行性アノマリー）。
強い順の幹 線形化可能性 → 順次一貫性 → 因果一貫性 → 結果整合性を即答できるように。線形化可能性だけがリアルタイム順序を要求し、合成可能であること、順次一貫性との差は実時間順序の有無であること、因果一貫性は高可用な一貫性の上限であること、セッション保証（read-your-writes など）が結果整合性と因果一貫性の中間であることが頻出です。
まとめ
一貫性モデルは「許す実行の集合」の包含で強弱が決まり、強い順の幹は 線形化可能性 ⊂ 順次一貫性 ⊂ 因果一貫性 ⊂ 結果整合性 です。線形化可能性は実時間順序を課し唯一合成可能、順次一貫性はそこから実時間順序だけを外し、因果一貫性は因果のある操作のみ順序づけて高可用な一貫性の上限となり、結果整合性は収束だけを約束します。両者の間にセッション保証という局所順序の中間層があります。強いほど同期点が増えてレイテンシと可用性を犠牲にするので、用途ごとに必要十分な強さを選ぶのが原則です。
データベース Article
一貫性モデルの強弱階層図を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
一貫性モデル
比較で見る軸
難易度: advanced / カテゴリ: データベース / タグ数: 5
導入後に効く点
強い順の幹は 線形化可能性 → 順次一貫性 → 因果一貫性 → 結果整合性。線形化可能性だけがリアルタイム順序を要求し、合成可能（局所的→大域的）という決定的な利点を持つ。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- advanced
- カテゴリ
- データベース
- タグ数
- 5
判断チェックリスト
- 自社の用途が「一貫性モデル / 分散システム」に近いか確認する。
- 強みである「一貫性モデルは「許される実行の集合」で順序づけられ、強いモデルほど許す実行が少なく、その実行集合は弱いモデルに包含される。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。