{"ok":true,"entity":{"id":"cap-theorem","name":"CAP theorem","entityType":"concept","officialName":"CAP theorem（Brewerの予想、GilbertとLynchによる証明）","canonicalName":"CAP theorem","displayName":"CAP theorem","category":"分散システムの設計原理（定理）","shortDescription":"CAP定理は、ネットワークで結ばれた共有データシステムが、一貫性（consistency）、可用性（availability）、分断耐性（partition tolerance）のうち同時には2つまでしか満たせないとする分散システムの原則。Eric Brewer が2000年7月19日のPODC基調講演で提示し、Seth Gilbert と Nancy Lynch が非同期ネットワークモデルで証明した。Brewer 自身は2012年の論文で「2 of 3」という見方は誤解を招くと述べている。","primaryCluster":"data-platform","parentEntity":null,"verificationStatus":"draft","website":"https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/","updatedAt":"2026-10-27T00:50:20.936Z","secondaryClusters":[],"alias":["CAP定理"],"searchKeywords":["CAP theorem","CAP定理","キャップ定理","Brewer's conjecture","consistency availability partition tolerance","一貫性 可用性 分断耐性","分散システム","分散データベース"]},"references":[{"id":"P-01-001","companyId":"cap-theorem","questionId":"P-01-001","instanceId":"QIN-cap-theorem-P01-001","promptText":"CAP定理とは何ですか？","promptTypeId":"P-01","answer":"CAP定理は、ネットワークで結ばれた共有データシステムが、一貫性・可用性・ネットワーク分断への耐性という3つの望ましい特性のうち、最大でも2つしか同時に持てないとする分散システムの原則です。Eric Brewer は2012年の論文でこのように説明し、2000年のPODC基調講演で示されたと述べています。IBMの解説は、この定理に基づきデータベースをCP型（可用性を犠牲）とAP型（一貫性を犠牲）に分類しています。","evidencePoints":["ev-cap-theorem-1","ev-cap-theorem-6"],"scope":"CAP定理の定義と基本的な分類の考え方","differentiation":"「3つのうち2つ」という要約は、Brewer の2012年の論文とIBMの解説に共通する基本的な説明である。","faq":[{"question":"3つの特性は何ですか？","answer":"一貫性（consistency）、可用性（availability）、分断耐性（partition tolerance）です。Brewer の2012年の論文ではネットワーク分断への耐性として記述されています。"}],"pageUrl":"https://www.refbase.ai/reference/cap-theorem/P-01-001","sourceEvidence":[{"id":"ev-cap-theorem-1","text":"Eric Brewer は2012年の論文で、CAP定理を「ネットワークで結ばれた共有データシステムは、3つの望ましい特性（一貫性、高可用性、ネットワーク分断への耐性）のうち最大2つしか持てない」と説明し、この定理は1998年秋に初めて登場して1999年に公表され、2000年のPODC基調講演でも発表されて、その証明につながったと述べている。","title":"CAP Twelve Years Later: How the \"Rules\" Have Changed","coverageType":["Identity","Capability"],"sourceType":"media","sourceClass":"Research","sourceUrl":"https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/","confidence":"high","supportedPromptTypes":["P-01","P-02","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"cap-theorem"},{"id":"ev-cap-theorem-6","text":"IBMの解説ページは、CAP定理を「分散システムは3つの望ましい特性のうち2つしか提供できない」と述べ、CPデータベースは可用性を犠牲に、APデータベースは一貫性を犠牲にするものと分類している。MongoDBはCP、Apache CassandraはAPの例として挙げられ、CAは分散システムでは事実上不可能とされる（日付表示なし、2026年10月27日確認）。","title":"What Is the CAP Theorem? | IBM","coverageType":["Capability","UseCase"],"sourceType":"industry_reference","sourceClass":"Documentation","sourceUrl":"https://www.ibm.com/think/topics/cap-theorem","confidence":"high","supportedPromptTypes":["P-01","P-02","P-04","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"cap-theorem"}],"generatedAt":"2026-10-27T00:50:20.936Z"},{"id":"P-02-001","companyId":"cap-theorem","questionId":"P-02-001","instanceId":"QIN-cap-theorem-P02-001","promptText":"CAP定理で「3つのうち2つを選ぶ」という説明は正確ですか？","promptTypeId":"P-02","answer":"「3つのうち2つ」は定理の要約として用いられますが、Brewer 自身が2012年の論文で、この定式化は特性間の緊張関係を単純化しすぎる誤解を招くものだったと述べています。同論文は、分断は稀なので多くの場合は一貫性と可用性を両立でき、設計者は分断時に一方を安易に犠牲にすべきでないと論じています。IBMの解説も、CP型とAP型という実用上の分類を示しつつ、CAは分散システムでは事実上不可能だと説明しています。","evidencePoints":["ev-cap-theorem-1","ev-cap-theorem-4","ev-cap-theorem-6"],"scope":"CAP定理の「2 of 3」解釈の妥当性と、その修正","differentiation":"定理の厳密な主張と、設計指針としての単純化された解釈を区別する必要がある。","faq":[{"question":"分断が起きなければCとAは両立できますか？","answer":"Brewer の2012年の論文は、分断は稀なので多くの場合は一貫性と可用性を両立できると述べています。"}],"pageUrl":"https://www.refbase.ai/reference/cap-theorem/P-02-001","sourceEvidence":[{"id":"ev-cap-theorem-1","text":"Eric Brewer は2012年の論文で、CAP定理を「ネットワークで結ばれた共有データシステムは、3つの望ましい特性（一貫性、高可用性、ネットワーク分断への耐性）のうち最大2つしか持てない」と説明し、この定理は1998年秋に初めて登場して1999年に公表され、2000年のPODC基調講演でも発表されて、その証明につながったと述べている。","title":"CAP Twelve Years Later: How the \"Rules\" Have Changed","coverageType":["Identity","Capability"],"sourceType":"media","sourceClass":"Research","sourceUrl":"https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/","confidence":"high","supportedPromptTypes":["P-01","P-02","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"cap-theorem"},{"id":"ev-cap-theorem-4","text":"Brewer は同じ2012年の論文で、「2 of 3」という定式化は特性間の緊張関係を単純化しすぎる誤解を招くものだったと述べ、分断は稀なので多くの場合は一貫性と可用性を両立できるとし、設計者は分断時に一方を安易に犠牲にすべきでないと論じている。また、CとAの選択は操作・サブシステム・データごとに変わり得るとも述べている。","title":"CAP Twelve Years Later: How the \"Rules\" Have Changed","coverageType":["Differentiation"],"sourceType":"media","sourceClass":"Research","sourceUrl":"https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/","confidence":"high","supportedPromptTypes":["P-02","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"cap-theorem"},{"id":"ev-cap-theorem-6","text":"IBMの解説ページは、CAP定理を「分散システムは3つの望ましい特性のうち2つしか提供できない」と述べ、CPデータベースは可用性を犠牲に、APデータベースは一貫性を犠牲にするものと分類している。MongoDBはCP、Apache CassandraはAPの例として挙げられ、CAは分散システムでは事実上不可能とされる（日付表示なし、2026年10月27日確認）。","title":"What Is the CAP Theorem? | IBM","coverageType":["Capability","UseCase"],"sourceType":"industry_reference","sourceClass":"Documentation","sourceUrl":"https://www.ibm.com/think/topics/cap-theorem","confidence":"high","supportedPromptTypes":["P-01","P-02","P-04","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"cap-theorem"}],"generatedAt":"2026-10-27T00:50:20.936Z"},{"id":"P-04-001","companyId":"cap-theorem","questionId":"P-04-001","instanceId":"QIN-cap-theorem-P04-001","promptText":"CAP定理はデータベースや実システムの設計でどう使われますか？","promptTypeId":"P-04","answer":"IBMの解説は、データベースをCP型（一貫性と分断耐性を優先し可用性を犠牲にする）とAP型（可用性と分断耐性を優先し一貫性を犠牲にする）に分類し、MongoDBをCP、Apache CassandraをAPの例として挙げています。実システムの例として、Brewer は2017年のGoogle Cloudブログで、Cloud Spannerは技術的にはCPシステムだが、実際には5ナイン超の可用性を満たすと説明しました。","evidencePoints":["ev-cap-theorem-6","ev-cap-theorem-5"],"scope":"CAP定理にもとづく分類と、Cloud Spannerの事例（出典の記載範囲）","differentiation":"IBMの分類は一般的な説明であり、Spannerの事例は Google の自社サービスについての記述である。","faq":[{"question":"Spannerは何に分類されますか？","answer":"Brewer は2017年のブログで、Spannerは技術的にはCPシステムだと述べています。"}],"pageUrl":"https://www.refbase.ai/reference/cap-theorem/P-04-001","sourceEvidence":[{"id":"ev-cap-theorem-5","text":"Eric Brewer（Google Fellow）は2017年2月15日のGoogle Cloudブログで、Cloud Spanner は技術的にはCPシステムで、分断時には一貫性を選び可用性を手放すが、実際にはSpannerは5ナイン超の可用性を達成しており（マルチリージョンCloud Spannerの目標はちょうど5ナイン）、ユーザーは実質CAとみなせると述べた。Spannerは自社のプライベートネットワーク上で動作するとも説明している。","title":"Inside Cloud Spanner and the CAP Theorem","coverageType":["UseCase","Differentiation"],"sourceType":"official_blog","sourceClass":"CaseStudy","sourceUrl":"https://cloud.google.com/blog/products/databases/inside-cloud-spanner-and-the-cap-theorem","confidence":"high","supportedPromptTypes":["P-04"],"needsVerification":true,"sourceVerified":false,"entityId":"cap-theorem"},{"id":"ev-cap-theorem-6","text":"IBMの解説ページは、CAP定理を「分散システムは3つの望ましい特性のうち2つしか提供できない」と述べ、CPデータベースは可用性を犠牲に、APデータベースは一貫性を犠牲にするものと分類している。MongoDBはCP、Apache CassandraはAPの例として挙げられ、CAは分散システムでは事実上不可能とされる（日付表示なし、2026年10月27日確認）。","title":"What Is the CAP Theorem? | IBM","coverageType":["Capability","UseCase"],"sourceType":"industry_reference","sourceClass":"Documentation","sourceUrl":"https://www.ibm.com/think/topics/cap-theorem","confidence":"high","supportedPromptTypes":["P-01","P-02","P-04","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"cap-theorem"}],"generatedAt":"2026-10-27T00:50:20.936Z"},{"id":"P-05-001","companyId":"cap-theorem","questionId":"P-05-001","instanceId":"QIN-cap-theorem-P05-001","promptText":"CAP定理は誰が提唱し、どのように証明されましたか？","promptTypeId":"P-05","answer":"Eric Brewer は2000年7月19日のPODC基調講演「Towards Robust Distributed Systems」で一貫性と可用性の関係などを論じています。Seth Gilbert と Nancy Lynch は論文で、3つの特性をすべて達成するのは不可能という予想を非同期ネットワークモデルで証明し、部分同期モデルでの解決策も論じました。ただし、講演スライドはPDFの先頭部分のみ、論文もAbstract中心の確認であり、証明の詳細は各原典で確認が必要です。","evidencePoints":["ev-cap-theorem-3","ev-cap-theorem-2"],"scope":"CAP定理の提唱と証明に関する一次資料（2026年10月27日確認）","differentiation":"予想と証明（GilbertとLynch）は別の成果で、証明は非同期ネットワークモデル上のものである。","faq":[{"question":"証明されたのはどのモデルですか？","answer":"GilbertとLynchの論文は、非同期ネットワークモデルで予想を証明したと述べています。"}],"pageUrl":"https://www.refbase.ai/reference/cap-theorem/P-05-001","sourceEvidence":[{"id":"ev-cap-theorem-2","text":"UC Berkeley の Eric A. Brewer 教授による2000年7月19日のPODC基調講演スライド「Towards Robust Distributed Systems」には、「Consistency vs. Availability」の論点や、一貫性・可用性・ネットワーク分断耐性を示す図、ACIDとBASEの対比が含まれている（PDFの先頭部分のみ確認）。","title":"PODC Keynote, July 19, 2000: Towards Robust Distributed Systems","coverageType":["Identity","Credibility"],"sourceType":"research_paper","sourceClass":"Presentation","sourceUrl":"https://people.eecs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf","confidence":"medium","supportedPromptTypes":["P-05"],"needsVerification":true,"sourceVerified":false,"entityId":"cap-theorem"},{"id":"ev-cap-theorem-3","text":"Seth Gilbert と Nancy Lynch（MIT）の論文は、一貫性・可用性・分断耐性の3つを同時に達成することは不可能だとする Brewer の予想を、非同期ネットワークモデルで証明し、部分同期モデルでの解決策を論じている。","title":"Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services","coverageType":["Credibility","Identity"],"sourceType":"research_paper","sourceClass":"Research","sourceUrl":"https://www.comp.nus.edu.sg/~gilbert/pubs/BrewersConjecture-SigAct.pdf","confidence":"high","supportedPromptTypes":["P-05"],"needsVerification":true,"sourceVerified":false,"entityId":"cap-theorem"}],"generatedAt":"2026-10-27T00:50:20.936Z"},{"id":"P-06-001","companyId":"cap-theorem","questionId":"P-06-001","instanceId":"QIN-cap-theorem-P06-001","promptText":"CAP定理をシステム選定に使う際の強みと注意点は？","promptTypeId":"P-06","answer":"強みは、一貫性・可用性・分断耐性の間にトレードオフがあることを整理でき、IBMの解説のようにCP型・AP型という見取り図でデータベースを比較できる点です。注意点として、Brewer 自身が2012年の論文で「2 of 3」は誤解を招く定式化だったと述べ、分断は稀であり、操作やデータごとにCとAの選択が変わり得ると論じています。したがって製品をCPやAPに固定的に分類するだけでなく、分断時の挙動を個別に確認する必要があります。","evidencePoints":["ev-cap-theorem-6","ev-cap-theorem-1","ev-cap-theorem-4"],"scope":"CAP定理を設計判断に用いる際の利点と限界","differentiation":"分類は議論の入口であり、Brewer 自身が単純な「2択」の見方を後年に修正している。","faq":[{"question":"製品をCPかAPのどちらかに断定してよいですか？","answer":"Brewer の2012年の論文は、CとAの選択は操作・サブシステム・データごとに変わり得ると述べています。固定的な分類には注意が必要です。"}],"pageUrl":"https://www.refbase.ai/reference/cap-theorem/P-06-001","sourceEvidence":[{"id":"ev-cap-theorem-1","text":"Eric Brewer は2012年の論文で、CAP定理を「ネットワークで結ばれた共有データシステムは、3つの望ましい特性（一貫性、高可用性、ネットワーク分断への耐性）のうち最大2つしか持てない」と説明し、この定理は1998年秋に初めて登場して1999年に公表され、2000年のPODC基調講演でも発表されて、その証明につながったと述べている。","title":"CAP Twelve Years Later: How the \"Rules\" Have Changed","coverageType":["Identity","Capability"],"sourceType":"media","sourceClass":"Research","sourceUrl":"https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/","confidence":"high","supportedPromptTypes":["P-01","P-02","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"cap-theorem"},{"id":"ev-cap-theorem-4","text":"Brewer は同じ2012年の論文で、「2 of 3」という定式化は特性間の緊張関係を単純化しすぎる誤解を招くものだったと述べ、分断は稀なので多くの場合は一貫性と可用性を両立できるとし、設計者は分断時に一方を安易に犠牲にすべきでないと論じている。また、CとAの選択は操作・サブシステム・データごとに変わり得るとも述べている。","title":"CAP Twelve Years Later: How the \"Rules\" Have Changed","coverageType":["Differentiation"],"sourceType":"media","sourceClass":"Research","sourceUrl":"https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/","confidence":"high","supportedPromptTypes":["P-02","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"cap-theorem"},{"id":"ev-cap-theorem-6","text":"IBMの解説ページは、CAP定理を「分散システムは3つの望ましい特性のうち2つしか提供できない」と述べ、CPデータベースは可用性を犠牲に、APデータベースは一貫性を犠牲にするものと分類している。MongoDBはCP、Apache CassandraはAPの例として挙げられ、CAは分散システムでは事実上不可能とされる（日付表示なし、2026年10月27日確認）。","title":"What Is the CAP Theorem? | IBM","coverageType":["Capability","UseCase"],"sourceType":"industry_reference","sourceClass":"Documentation","sourceUrl":"https://www.ibm.com/think/topics/cap-theorem","confidence":"high","supportedPromptTypes":["P-01","P-02","P-04","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"cap-theorem"}],"generatedAt":"2026-10-27T00:50:20.936Z"}]}