ACID
トランザクションが保証する4性質 — 原子性・一貫性・分離性・永続性。
概要
ACIDは、トランザクションが満たすべき4つの性質——Atomicity（原子性）、Consistency（一貫性）、Isolation（分離性）、Durability（永続性）——の頭文字です。「全部成功か全部なかったことか」「ルール違反のデータを残さない」「同時実行しても互いに干渉しない」「確定したら消えない」という4つの約束をまとめて指す語彙で、RDBMSの信頼性はこの保証に支えられています。
「このデータベースはACID準拠か」「この処理でACIDのどれが破れうるか」のように、データの正しさを議論するときの共通言語として使われます。障害・同時アクセス・電源断といった不運が重なっても業務データが壊れないのは、当たり前のことではなく、この4性質を実装で守り抜いた結果です。
なぜ生まれたか
1970〜80年代、データベースの信頼性は実装ごとにばらばらの工夫で担保されており、「トランザクションが正しく動く」とは具体的に何を意味するのかを語る共通の言葉がありませんでした。障害からの回復と同時実行制御の理論が発展する中で、1983年にテオ・ヘルダーとアンドレアス・ロイターが、トランザクション処理が満たすべき要件を4つの性質に整理し、ACIDと名付けました（その基礎にはジム・グレイによるトランザクション概念の定式化があります）。
要件が明文化されたことで、データベースの実装者は「何を保証すべきか」の明確な目標を持ち、利用者は「何を信頼してよいか」を製品をまたいで判断できるようになりました。仕様と実装を橋渡しする語彙として、ACIDは40年経った今も現役です。
詳細
4つの性質
Atomicity（原子性） は「全か無か」の保証です。トランザクション内の複数の操作は、すべて反映されるか、1つも反映されないかのどちらかしかありません。途中で失敗すればROLLBACKにより開始前の状態へ完全に巻き戻ります。振込で「引き落としだけ成功」が起きないのはこの性質のおかげです。
Consistency（一貫性） は、トランザクションの前後でデータベースが定義済みのルール（制約）を満たし続ける保証です。「残高は0以上」「外部キーは実在する行を指す」といった制約に違反する変更はCOMMITできません。ここでいう一貫性はビジネスロジックの正しさそのものではなく、宣言された制約が破られないことを指す点に注意が必要です。
Isolation（分離性） は、同時に実行されるトランザクション同士が互いの途中経過を見ない保証です。理想は「1つずつ順番に実行したのと同じ結果」ですが、厳密に守ると性能が落ちるため、実際にはトランザクションの分離レベルとして保証の強さを段階的に選べるようになっています。4性質の中で唯一「調整可能」な性質と言えます。
Durability（永続性） は、COMMITが完了した変更は電源断やクラッシュが起きても失われない保証です。実装の中核はWAL（Write-Ahead Logging）で、データ本体より先に変更記録をディスクへ書き切ってからCOMMITを応答します。再起動後はこのログを再生することでCOMMIT済みの状態を復元します。
4性質の関係
4つは独立の項目というより、支え合う関係にあります。原子性はログによる巻き戻しで実現され、そのログが永続性も支えます。分離性はロックや多版管理（MVCC: 読み取り用に過去のバージョンを見せる方式）で実現され、原子性・分離性・制約検査がそろって初めて一貫性が守られます。PostgreSQLやMySQL（InnoDB）はいずれもWAL＋MVCCという組み合わせでACIDを実装しています。
ACIDの限界とBASE
ACIDの保証は、基本的に1台のデータベースの中で完結する話です。データを複数のノードに分散させると、全ノードで合意してからCOMMITする必要が生じ（2相コミット）、遅延と可用性低下が避けられません。分散環境では一貫性・可用性・分断耐性を同時に満たせないというCAP定理の制約もあり、ACIDを厳密に守ることと水平スケーリングは両立しにくいのです。
そこでNoSQLの世界では、保証を意図的に緩めたBASE（Basically Available, Soft state, Eventually consistent）という対になる考え方が生まれました。「一時的に古いデータが見えてもよいが、いずれ全ノードが一致する」結果整合性を受け入れることで、大規模分散を可能にします。実務では「注文と決済はACIDなRDBMSで、閲覧数カウントは結果整合性で」のように、データの性質ごとに必要な保証の強さを選ぶのが現代的な設計です。