オンラインショップで決済ボタンを押したところ、在庫が「あり」と表示されていた商品が突然売り切れになります。別のサーバーには、まだ古い在庫情報が残っていたためです。複数のコンピューターがひとつのサービスとして動くとき、データは常に同じで、応答は必ず返り、ネットワークは決して切れないという約束をすべて同時に守ることは困難です。このジレンマをひと言でまとめたものが「CAP定理（CAP Theorem）」です。
CAP定理とは、簡単に言えば「分散システムでは、一貫性（Consistency）、可用性（Availability）、分断耐性（Partition tolerance）のすべてを同時に保証することはできない」という理論です。2000年にエリック・ブリュワー（Eric Brewer）がPODCの基調講演で提唱し、2002年にセス・ギルバート（Seth Gilbert）とナンシー・リンチ（Nancy Lynch）が形式的に証明しました。
本資料では、CAP定理が生まれた背景と正確な定義から、C・A・Pそれぞれの意味、すべてを同時に満たせない理由、そして実務でこの定理をどう読み解くべきかまで、わかりやすく整理します。
CAP定理：分散システムが直面する約束
CAP定理とは何か？
分散システムは、単独のコンピューターではなく、 複数のノードがネットワークでつながった構造です。オンラインショップ、メッセンジャー、クラウドデータベースのように、規模が大きくなるほど、データを複数の場所に分けて置くのが自然です。問題は、ノード間の通信が常に完全とは限らない点です。ケーブルが切れたり、遅延が急増したり、一部のサーバーが応答しなくなったりすると、「分断（Partition）」が生じます。
ブリュワーは、このような環境でシステムが同時には守れない性質を、C・A・Pとしてまとめました。核心となるメッセージは単純です。 ネットワーク分断が実際に発生すると、一貫性と可用性のどちらかを優先しなければならないということです。よく「すべてのうち、選べるのはふたつだけ」と要約されますが、現代的な解釈では、分断耐性を事実上必須の前提とし、CとAのトレードオフとして捉えます。
この定理を読み解く際に、併せて押さえておくとよい概念は次のとおりです。
- 分散システム（Distributed System）：複数のコンピューターが、ひとつのサービスとして協力する構造です。
- ノード（Node）：その協力に参加する個々のサーバーやプロセスです。
- レプリケーション（Replication）：同じデータを複数のノードにコピーしておく方式です。
- トレードオフ（Trade-off）：ある性質を強化すると、別の性質を妥協しなければならない関係です。
C・A・P、それぞれの正確な意味
それぞれを日常的な言葉に置き換えると、概念が明確になります。
（1）一貫性（Consistency）
すべてのノードが 同時に同じ最新の値を見るという約束です。ある場所で在庫を1に減らしたなら、別の場所で直後に照会しても1でなければなりません。CAPでいうCは、データベース理論の「強い一貫性」に近く、最終的に同じになればよいという緩やかな一貫性とは区別されます。
（2）可用性（Availability）
稼働しているノードであれば、 リクエストに必ず応答するという約束です。失敗やタイムアウトなしに「読み取り・書き込みの結果が返ってくる」という意味であり、その結果が常に最新であるという意味ではありません。遅くても返答が来ることと、そもそも拒否することは、異なる選択です。
（3）分断耐性（Partition tolerance）
ノード間の通信が途絶えても、 システムが停止せずに動作し続けるという約束です。現実のインターネットやデータセンターでは分断は珍しくないため、大半の大規模サービスはPを諦めることが困難です。
わかりやすい例として、銀行の別々の支店の窓口が、電話回線だけでつながっているとしましょう。電話が切れた瞬間（分断）にも、それぞれの窓口が出金を認めると（可用性）、残高に食い違いが生じる可能性があります（一貫性の損失）。残高を一致させるために取引を止めると（一貫性の維持）、顧客は取引を断られます（可用性の損失）。
なぜすべてを同時に満たせないのか
ネットワークが分断されると、ノードのグループ同士で互いの最新の状態を確認できなくなります。このとき、選択肢はおおむね次のように分かれます。
（1）CPを選ぶ場合
一貫性を守るには、相手側の状態がわからないまま書き込みを認めてはいけません。そのため、一部のリクエストを拒否したり、待機させたりします。データは整合していますが、その瞬間、サービスは「応答なし」に見えることがあります。従来の合意に基づくデータベースや、強い一貫性を重視するシステムは、こちらに近いものです。
（2）APを選ぶ場合
可用性を守るには、各ノードが持つ情報だけでも応答します。サービスは利用できる状態を保ちますが、分断が解消されるまでは、互いに異なる値を表示することがあります。その後、同期や競合解決によって値をそろえる「結果整合性（Eventual Consistency）」の戦略と組み合わせられることがよくあります。
「CAシステム」という言葉も教科書に登場しますが、 分断が決して発生しない環境を前提とした理想化に近いものです。単独の機器や非常に安定したローカルクラスターでは近似的に実現できても、広域に分散した環境ではPを無視することは困難です。したがって、実務での問いは「C・A・Pのうち何を捨てるか？」よりも、 「分断が起きたとき、CとAのどちらを、どの程度妥協するか？」に近くなります。
実務でCAPをどう読み解くべきか
CAP定理は強力な洞察ですが、万能な分類ラベルではありません。ブリュワー自身も、後の文章で「2 out of 3」というスローガンが誤解を招いたと振り返っています。現代のシステムでは、次のような補完的な視点も必要です。
- 程度の問題：一貫性と可用性は、オンとオフを切り替えるスイッチではなく、 スペクトラムです。読み取りだけは緩やかにし、書き込みは強くする、といった組み合わせがよく見られます。
- 遅延との関係：ダニエル・アバディ（Daniel Abadi）が整理したPACELCでは、分断がないとき（Else）にも、遅延（Latency）と一貫性の間で選択があると考えます。
- 業務ごとの優先順位：決済や在庫のように金銭が関わる処理はC寄りに、フィードや閲覧数のように多少の時間差が許容される処理はA寄りになりやすい傾向があります。
設計者は、「私たちのシステムはCPだ／APだ」とひと言で済ませるのではなく、 どの操作が、どのような状況で、何を保証するのかを具体的に記述する必要があります。CAPは選択肢をなくす法則ではなく、分散環境の限界をあらかじめ示してくれる地図です。
CAP定理は、「完璧な分散システムは存在しない」という警告ではありません。 限界を認めたうえで、ビジネスに合った妥協点を設計しようという呼びかけです。ネットワークに不具合が起きるときを想定し、一貫性と可用性のどちらを守るかをあらかじめ決めること。それが、安定した分散システム設計の第一歩です。
