トランザクションとACID、そして特許
トランザクションとは、複数の操作をまとめて「全部成功するか、全部なかったことにするか」のどちらかにする処理単位です。仕組みを振込の例で手を動かして確かめ、ACID の4性質と担保技術を対応づけたうえで、この分野の特許がどこに集まり、実務で何が論点になるかを整理します。
1. トランザクションの仕組み
典型例は銀行振込です。A 口座から引き落とし、B 口座に入金する2つの操作のうち、片方だけが実行されることは許されません。手順は次のとおりです。
これを支える主な実装技術は4つあります。
WAL（Write-Ahead Logging）
データ本体を書き換える前に、変更内容をログへ永続化します。障害が起きたらログを使って復旧します。
並行制御
同時に動くトランザクション同士の干渉を防ぎます。
2PL（二相ロック）：ロックを取得する段階と解放する段階を分けます。
MVCC（多版型同時実行制御）：データの版を複数保持し、読み取りが書き込みを待たずに済むようにします。PostgreSQL や Oracle など、現在の主流です。
リカバリ
代表的な方式は IBM の ARIES です。障害後に「分析 → 未反映分の再実行（Redo）→ 未確定分の取消（Undo）」の3段階で整合状態へ戻します。
分散トランザクション
複数のノードにまたがる場合は 2PC（二相コミット）を使います。コーディネータが全参加者に「準備できたか」を確認し、全員が了承した場合だけコミットします。
A 口座（10,000円）から B 口座（5,000円）へ 3,000円を振り込みます。落ちるタイミングと方式を選ぶと、再起動後の残高が出ます。
2. ACID
ACID はトランザクションが満たすべき4つの性質で、それぞれ上の実装技術で担保されます。
| 性質 | 意味 | 主な担保技術 |
|---|---|---|
| Atomicity（原子性） | 全部実行か全部取消か | WAL、Undo ログ、2PC |
| Consistency（一貫性） | 制約（残高≥0 など）を常に満たす | 制約チェック（アプリ側の責任も大きい） |
| Isolation（独立性） | 同時実行しても互いに干渉しない | ロック、MVCC、分離レベル |
| Durability（永続性） | コミット済みの結果は障害でも消えない | WAL、fsync、レプリケーション |
Isolation には強さの段階がある
分離レベルは性能とのトレードオフです。
- Read Uncommitted / Read Committed：他のトランザクションの変更がどこまで見えるかを制限する、弱めのレベルです。
- Repeatable Read：同じデータを2回読んだとき、同じ値が返ることを保証します。
- Serializable：順番に1件ずつ実行した場合と同じ結果を保証する、最も強いレベルです。
分離レベルを下げると、次の異常が起こりえます（✕＝起こりうる、○＝防がれる）。
| 分離レベル | ダーティリード | 反復不能読み取り | ファントム | Write Skew |
|---|---|---|---|---|
| Read Uncommitted | ✕ | ✕ | ✕ | ✕ |
| Read Committed | ○ | ✕ | ✕ | ✕ |
| Repeatable Read | ○ | ○ | ✕ | ✕ |
| Serializable | ○ | ○ | ○ | ○ |
SQL 標準の定義による整理です。実装で挙動は変わります。たとえば PostgreSQL の Repeatable Read はスナップショット分離として実装されていてファントムは起きませんが、Write Skew は防げません。
なお、分散 NoSQL では可用性を優先して BASE（結果整合性）を採る設計も一般的です。Spanner 以降の「NewSQL」は、分散環境でも ACID を両立させる方向に進みました。
3. 関連する特許技術
知財の観点で押さえておくべき点を3つに分けて整理します。
基本概念はすでに公知
ACID、2PL、2PC、WAL の原理は 1970〜80年代に Jim Gray らの論文や教科書で確立されています。基本特許は存在しないか、とうに失効しています。現在出願・権利化されているのは、改良技術や適用分野を限定した組合せ発明です。
特許が集中している技術領域
| 領域 | 中身 | 代表的な出願人・例 |
|---|---|---|
| ログ・リカバリの高速化 | ARIES 系、フラッシュメモリや不揮発メモリ（NVM）向けのログ手法 | IBM（1990年代の ARIES 系が代表例） |
| MVCC・スナップショット分離の実装 | 版管理やガベージコレクションの手法 | Oracle、SAP（HANA）、Microsoft（Hekaton／インメモリ OLTP） |
| 分散コミット・合意 | 2PC のブロッキング回避、Paxos/Raft との統合、時刻同期による整合性保証 | Google の Spanner（TrueTime）関連 |
| クラウド DB | 計算とストレージを分離した構成でのログ処理、マルチリージョンでのコミット | Amazon Aurora 型の構成 |
| ブロックチェーン | 台帳上のトランザクション順序付け、スマートコントラクトの原子性 | 金融機関、IT 大手 |
実務上の論点
特許適格性
日本では「ソフトウェアによる情報処理がハードウェア資源を用いて具体的に実現されている」ことが要件です。米国では Alice 判決以降、抽象的アイデアとして拒絶されるリスクがあります。性能改善（遅延や I/O の削減）を具体的な構成で書けるかどうかが鍵になります。
侵害の立証
DB の内部処理は外から観察しにくく、侵害を立証しにくい分野です。そのため防衛出願やクロスライセンス材料としての性格が強くなります。
OSS の影響
PostgreSQL などの OSS が実装を公開してきたため、公知例が豊富で新規性のハードルが高い分野です。Apache 2.0 の特許許諾条項や、CockroachDB などのライセンス変更といったライセンス戦略の方が事業上のインパクトが大きいのが実情です。
自分で調べるには
個別の特許番号や権利状況は、J-PlatPat や Google Patents で「MVCC」「two-phase commit」「write-ahead log」などのキーワードと、IPC 分類 G06F16/23（構造化データの更新処理。トランザクション・整合性はこの配下）を組み合わせて検索すると、主要な出願人と出願動向を把握できます。
原理は半世紀前に公開され、権利は「どう速くするか」「どこで使うか」の改良に移った。この分野で効くのは、単独の特許より、公開と許諾をどう組むかの設計である。