LASSIC Media らしくメディア
CAP定理とは？分散システムの3要素を解説
LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・検証を受託
分散システムの設計を検討していると、「CAP定理」という言葉に行き当たることがあります。似た響きの用語に、単一のデータベースにおけるトランザクションの性質を指す「ACID特性」がありますが、この二つは扱う対象がそもそも異なるものです。ACID特性は一つのデータベースの中で完結する話であるのに対し、CAP定理は複数のサーバー（ノード）にデータを分けて持つ分散システムに固有の制約を扱います。同じ「一貫性」という言葉が使われていても、指している範囲が違う点にまず注意が必要でしょう。
本記事では、CAP定理を構成する3つの要素の定義と、なぜそれらを同時に満たすことが難しいとされるのか、CP型・AP型と呼ばれる設計の傾向、結果整合性（eventual consistency）という考え方、そして実務での捉え方までを、システムの企画・設計に携わる法人担当者向けに整理します。特定製品の優劣比較には立ち入らず、考え方の骨格を押さえることに焦点を当てます。
この記事のポイント
- CAP定理は、分散システムがConsistency（一貫性）・Availability（可用性）・Partition tolerance（分断耐性）の3つを同時には満たせないという原理で、単一DBのACID特性とは別の話です。
- 「3つのうち2つを選ぶ」という説明は、ネットワーク分断が発生している間に限られる注意点があり、平常時にそのまま当てはまるわけではありません。
- CP型・AP型のどちらが優れているかではなく、要件に応じて一貫性と可用性のバランスを選ぶ考え方が実務では大切です。
目次
CAP定理の3要素とACID特性との違い
CAP定理は、複数のノードにデータを分散して持つシステムにおいて、次の3つの性質を同時に満たすことはできないという原理です。まず、この3つの定義を整理しておきましょう。
一貫性・可用性・分断耐性という3つの性質
一つ目のConsistency（一貫性）は、どのノードに読み取りリクエストを送っても、最新の書き込み結果か、もしくはエラーのどちらかが返ってくるという性質です。二つ目のAvailability（可用性）は、正常に稼働しているノードであれば、どのリクエストに対しても何らかの応答を返すという性質を指します。三つ目のPartition tolerance（分断耐性）は、ノード間の通信の一部が失われても、システム全体としては動作を続けられるという性質です。
ここで注意したいのが、ACID特性との違いです。ACID特性は原子性・一貫性・独立性・永続性という、単一のデータベースにおけるトランザクションが備えるべき性質を指すもので、一つのデータベース内部の整合性ルールを扱う概念です。一方のCAP定理は、複数のノードにまたがる分散システム全体の制約を扱うものであり、対象としている領域が異なります。ACID特性の話をしているつもりが、いつの間にかCAP定理の話にすり替わってしまうと、議論がかみ合わなくなるため、両者は分けて捉えておきたい概念です。
提唱の経緯（ブリュワー氏の予想とギルバート・リンチによる証明）
CAP定理は、2000年にエリック・ブリュワー氏が学会（PODC）での講演で提示した予想が出発点になっています。その後2002年に、MITのセス・ギルバート氏とナンシー・リンチ氏が、非同期ネットワークモデルという条件下でこの予想を数学的に証明し、定理として確立されたものです。学術的な背景を持つ理論であるため、条件設定を離れて過度に単純化して語られる場面もあり、次の章で触れる注意点にもつながってきます。
なぜ3つを同時に満たせないのか
3つの性質がどうして同時に成立しないのか、ネットワーク分断が発生した瞬間を例に考えてみましょう。
ネットワーク分断が起きたときに何が起こるか
複数のノードで構成される分散システムでは、ノード間の通信が何らかの理由で途切れる「分断（パーティション）」が起こり得ます。分断が起きている間に、あるノードへ書き込みリクエストが届いたとしましょう。このとき、他のノードと通信できないため、書き込んだ内容を全ノードに反映できたかどうか確認できないのです。ここで一貫性を優先すれば、確認が取れるまで応答を保留するかエラーを返すことになり、可用性が損なわれます。逆に可用性を優先すれば、他ノードとの整合が取れていない状態でも応答を返すことになり、一貫性が損なわれるわけです。広域に分散するシステムでは通信の途絶が起こり得るという前提に立つと、分断耐性を確保したうえで、実質的にCとAのどちらを優先するかという選択に行き着きます。
「3つのうち2つを選ぶ」という説明の注意点
CAP定理はしばしば「3つのうち2つしか選べない」と紹介されますが、これは分断が実際に発生している間の話であって、分断が起きていない平常時にそのまま当てはまる表現ではありません。多くのシステムは平常時にはCとAの両方を満たしているように見えており、分断が発生した瞬間にだけ、どちらを優先するかの判断が表面化する構造になっています。Google Cloudの技術解説でも、可用性を犠牲にする必要があるのは分断が起きている間だけであり、その影響を和らげる工夫は複数存在すると説明されており、単純な二択の図式だけで理解すると実態とずれる可能性がある点は押さえておきたいところです。
CP型とAP型の具体例
実際の分散システムは、分断時にどちらを優先する設計を選ぶかによって、大まかにCP型とAP型という傾向に分けて語られることがあります。
一貫性を優先するCP型の傾向
CP型は、分断が起きた際に一貫性（C）を優先し、確認が取れないノードに対しては応答を保留したりエラーを返したりする設計です。複数拠点間で同期的にデータを複製するリレーショナルデータベースの構成や、複数ノード間の合意形成を担う分散協調システムなどは、この傾向に寄りやすいといえます。金融取引のように、古いデータでの応答が業務上の問題につながりやすい領域で採用されることが多い考え方です。
可用性を優先するAP型の傾向
AP型は、分断が起きても可用性（A）を優先し、他ノードとの整合が取れきっていない状態でも、手元にあるデータで応答を返す設計です。分散型のキー・バリュー・ストアや、いわゆるNoSQLと呼ばれる製品群の一部は、可用性を重視した設計思想を持つ傾向があります。SNSのタイムラインやアクセスログの集計など、多少の表示遅延よりも応答が返り続けることを優先したい領域と相性が良い考え方です。
| 観点 | CP型 | AP型 |
|---|---|---|
| 分断時の優先 | 一貫性（確認できないなら応答を保留・拒否） | 可用性（確認できなくても手元データで応答） |
| 代表的な傾向を持つ構成 | 同期レプリケーション構成のRDB、分散協調システム | 分散KVS・一部のNoSQL製品 |
| 相性が良い領域の例 | 金融取引など古いデータでの応答が問題になりやすい領域 | SNSタイムラインなど応答の継続を優先したい領域 |
| 弱点・限界 | 分断時に一部リクエストへ応答できなくなることがある | 分断時に古いデータを返す可能性が残る |
対比表からも分かるとおり、CP型とAP型は優劣を比べる関係ではなく、分断が起きた際にどちらの性質を手放すかという設計判断の違いです。次の図は、この違いをイメージにしたものです。
結果整合性（eventual consistency）という考え方
AP型の設計でよく採用されるのが、結果整合性（eventual consistency）という考え方です。これは、書き込み直後の一瞬はノード間でデータが一致していない状態が生じ得るものの、時間が経てば各ノードのデータが同じ値へと収束していくという発想に基づいています。「読み取ったら常に最新の値が返る」ことを保証する強い一貫性とは異なり、収束するまでの間は古い値が読み取られる可能性を許容する設計です。
この考え方は、可用性を優先したいシステムにとって現実的な妥協点として使われています。一方で、収束するまでの時間（どのくらいの遅延で一致するか）はシステムの実装によって幅があるため、業務要件として「どの程度の遅延まで許容できるか」を事前に整理しておくことが、設計判断の材料になるでしょう。強い一貫性が必要な処理と、多少のずれを許容できる処理を、一つのシステムの中でも見極めて使い分ける発想が実務では採られています。
実務での捉え方とPACELCへの発展
CAP定理を実務に落とし込む際は、CP型とAP型のどちらが優れているかという二択で考えるより、扱うデータの性質ごとに一貫性と可用性のバランスをどこに置くかを判断する視点が実践的です。
データの性質に応じてバランスを選ぶ
在庫数や決済結果のように、古いデータでの応答が業務上の誤りに直結しやすいデータは、一貫性を重視した設計と相性が良いといえます。一方、アクセスログの集計値や商品のレコメンド表示のように、多少の遅延やずれがあっても大きな支障が出にくいデータは、可用性を重視した設計を選びやすい領域です。一つのシステムの中でも、扱うデータの重要度に応じて設計方針を分けるという考え方が現実的でしょう。
PACELC定理という発展的な考え方
CAP定理はネットワーク分断が発生した場面に焦点を当てた理論ですが、これを拡張した考え方としてPACELC定理と呼ばれるものが紹介されることがあります。分断（Partition）時にはAvailabilityとConsistencyのトレードオフを、分断が起きていない平常時（Else）にはLatency（応答速度）とConsistencyのトレードオフを考える、という枠組みです。分断時だけでなく平常時のトレードオフにも目を向けたい場合の参考として、名前だけでも押さえておくと理解の幅が広がるでしょう。
まとめ：要件に応じてCとAのバランスを選ぶ
本記事では、分散システムに固有の制約であるCAP定理について、Consistency（一貫性）・Availability（可用性）・Partition tolerance（分断耐性）という3要素の定義と、単一データベースのACID特性とは異なる概念であることを整理しました。ネットワーク分断が発生した場面でCとAのどちらを優先するかという判断が生じる一方、この二択がそのまま当てはまるのは分断時に限られる点にも触れています。
CP型とAP型は優劣で語るものではなく、扱うデータの性質と業務要件に応じてバランスを選ぶ設計判断の材料です。結果整合性やPACELC定理といった関連する考え方も踏まえながら、自社のシステムがどちらの傾向を選んでいるのか、あるいは選ぶべきなのかを整理しておくと、設計や発注の場面での認識のずれを防ぎやすくなります。
よくある質問
CAP定理は、3つのうち2つを自由に選べるという理解でよいですか。
その理解には注意が必要です。2つしか選べないという説明が当てはまるのは、ネットワーク分断が実際に発生している間に限られます。平常時はConsistencyとAvailabilityの両方を満たしているように見えるシステムがほとんどであり、分断が起きた瞬間にどちらを優先するかの判断が表面化する、という構造で捉えておくと実態に近いでしょう。
CAP定理とACID特性は何が違いますか。
ACID特性は、原子性・一貫性・独立性・永続性という、単一のデータベースにおけるトランザクションの性質を指すものです。これに対しCAP定理は、複数のノードにまたがる分散システム全体の制約を扱う理論であり、対象としている領域が異なります。同じ「一貫性」という言葉が使われますが、指している範囲は別ものと捉えておく必要があります。
CP型とAP型はどちらを選ぶべきですか。
一方が優れているという関係ではなく、扱うデータの性質によって適した設計が変わります。決済結果や在庫数のように古いデータでの応答が業務上の誤りにつながりやすいデータはCP型寄り、多少のずれが許容できる集計データなどはAP型寄りの設計と相性が良い傾向にあります。
結果整合性を採用すると、データはいつ一致しますか。
一致するまでの時間は、システムの実装やネットワーク状況によって幅があり、一律の時間を示すことは難しいところです。結果整合性は「いずれ収束する」ことを前提とした考え方であるため、業務要件としてどの程度の遅延まで許容できるかを事前に整理しておくことが、設計判断の助けになります。
PACELC定理とはどのようなものですか。
CAP定理を拡張した考え方として紹介されるもので、ネットワーク分断時にはAvailabilityとConsistencyのトレードオフを、分断が起きていない平常時にはLatency（応答速度）とConsistencyのトレードオフを考える、という枠組みです。分断時だけでなく平常時の判断にも目を向けたい場合の参考になります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：AWS「CAP の定理 – 可用性およびその他：AWS の分散システムの回復力の理解と向上」（https://docs.aws.amazon.com/ja_jp/whitepapers/latest/availability-and-beyond-improving-resilience/cap-theorem.html）
- *2 出典：Google Cloud「Inside Cloud Spanner and the CAP Theorem」日本語版（https://cloud.google.com/blog/ja/products/gcp/inside-cloud-spanner-and-the-cap-theorem）
