複式簿記から紐解くイベント駆動アーキテクチャの歴史

TL;DR

• イベントソーシングの本質は「状態を直接更新せず、出来事を追記し、畳み込んで状態を導く」こと
• この発想は新しい発明ではなく、複式簿記（15世紀）に始まる数百年来の知恵の再発見・再命名である
• 銀行の勘定系は、命名される何十年も前からこのアーキテクチャを性能要件への対処として実践していた
• Greg Young が2000年代後半に金融文脈で体系化し、CQRS という名前で普及、2010年代に専用DBと共に製品化された

入り口としての比喩：複式簿記はイベントソーシングである

設計パターンを理解する最短経路は、すでに知っている構造との対応を見つけることだ。イベントソーシングの場合、その対応物は複式簿記である。

複式簿記の仕訳は、不変の追記専用ログ（append-only log）そのものだ。「いつ・何が・いくら動いたか」を借方・貸方のペアとして記録し、過去のエントリは決して書き換えない。残高は独立した真実のデータではなく、仕訳をすべて畳み込んだ導出結果にすぎない。

balance = fold(journal_entries)   // 残高 = 仕訳の畳み込み

これはイベントソーシングの中核的な等式と完全に一致する。

current_state = fold(events)      // 現在状態 = イベントの畳み込み

残高表は「派生ビュー」、すなわちプロジェクション（projection）に相当する。

単式簿記との対比：CRUD vs イベントソーシング

観点	単式簿記 / CRUD	複式簿記 / イベントソーシング
書き込み	残高を直接上書き	出来事を追記
現在状態	テーブルに保持された値	イベントの畳み込みで導出
過去の経路	失われる	完全に保持される
訂正方法	値を書き換える	打ち消すイベントを足す

単式簿記（CRUDモデル）はシンプルで読みやすいが、「なぜ今この残高なのか」という経路が消える。複式簿記が長らく標準であり続けたのは、この経路を保持することで得られる三つの性質ゆえだ。

• トレーサビリティ: 任意時点の状態を、ログのリプレイによって復元できる
• 監査耐性: 修正は元の記録を消さず、逆仕訳という新しいエントリで打ち消す。これはイベントソーシングの補正イベント（compensating event）と同一の思想である
• 不変条件の検証: 「借方合計 = 貸方合計」という制約が、各トランザクションの整合性をその場で保証する

特筆すべきは「訂正を削除で行わない」という哲学だ。誤りがあっても元データは残し、打ち消す記録を追記する。これにより履歴が線形に積み上がり、監査可能性が担保される。そして複式簿記をルカ・パチョーリが体系化したのは15世紀——イベントソーシングに約500年先行している。

歴史を紐解く

前史：追記専用ログは新しくない

追記専用の不変ログという発想自体は、極めて古い。イベントソーシングと CQRS を体系化した Greg Young 自身が、これらは「非常に古い概念」であり、すでに何千ものシステムがこの方式で稼働していたと述べている。SQL データベースが登場する以前のメインフレーム時代には、システムは典型的にこのように作られていた。

技術的に見ても、データベースは内部的にトランザクションログ（WAL: Write-Ahead Logging）というイベントソーシングで動作している。状態を更新する前に「何をするか」を不変ログに追記し、そこから状態を構築する——RDBMS の心臓部がすでにイベントソーシングなのだ。つまりイベントソーシングは「発明」というより「再発見と再命名」に近い。

起源：金融という出発点

イベントソーシングの体系化は、Greg Young がアルゴリズム取引に携わっていた文脈から生まれた。求められたのは、決定論的で、正しさを証明できる監査ログを備えたシステムだった。これは規制産業では一般的な要件である。

ここから Young は「状態遷移こそがドメインの本質であり、それをイベントとしてモデリングすべきだ」という発想に至る。出発点が金融——複式簿記の世界——だったことは示唆的だ。実際、Young の2014年の講演では、台帳のエントリを消しゴムで消すという象徴的なスライドが用いられ、イベントストアが金融記録にとって有用なツールであることを示すのに会計台帳の例が使われている。本稿の入り口とした複式簿記の比喩は、この分野の創始者自身が中心に据えていたものだった。

命名と普及：CQRS という名前

Young が CQRS（Command Query Responsibility Segregation）という用語を作ると、コミュニティは即座にこれを採用し、以降ずっと発展させ続けてきた。当初は教育上、CQRS を先に教えてからイベントソーシングを教えるのが有利だったが、後に Young 本人は「本来はイベントソーシングが先だ」と言うようになった。

この時期、DDD（ドメイン駆動設計）コミュニティと密接に結びつきながら広まった点も重要である。Eric Evans のドメインモデリングの思想と、Young のイベント中心の発想が結合し、2010年代のマイクロサービス時代に一気に実用化された。

製品化：学術的パターンから主流へ

2012年に Event Store（2019年に正式法人化）が設立される。これはイベントソーシングが学術的パターンから主流のアーキテクチャ標準へと成熟していく、10年がかりの進化を象徴している。EventStoreDB という専用データベースが開発され、現在は Kurrent という名称になっている。

時期	出来事
15世紀	複式簿記の体系化（追記専用・不変ログの原型）
〜2000年代	メインフレーム/金融系で追記ログ方式が無名のまま稼働
2000年代後半	Greg Young が金融文脈でイベントソーシングを再発見・体系化
2000年代末〜2010年代	CQRS として普及、DDD と結合
2010年代〜現在	専用DB（Event Store / EventStoreDB → Kurrent）と共に製品化

ケーススタディ：銀行勘定系という名前のないイベントソーシング

「メインフレーム時代には普通にこう作っていた」を最もよく体現するのが、銀行のオンラインシステムである。イベントソーシングや CQRS が命名されるより何十年も前から、金融系ではこの構造が当たり前に動いていた。

典型的な構成は次の三層に分かれる。

1. 勘定系（更新系 / コマンド側）: 日中のオンライン取引を「取引明細（トランザクションログ）」として追記する。各取引は借方/貸方のペアであり、これが不変のイベントログにあたる。残高をその場で上書きせず、取引を積み上げる。
2. 夜間バッチ（プロジェクション生成）: 営業終了後にバッチが起動し、その日の取引明細を集計して残高テーブルや照会用テーブルを再計算・書き出しする。これは CQRS のリードモデル構築そのものである。
3. 照会系（参照系 / クエリ側）: 翌営業日、窓口や ATM が参照するのはバッチで生成された照会用テーブルだ。書き込み（コマンド）と読み取り（クエリ）が、経路もデータモデルも分離されている——これが CQRS の本質である。

注目すべきは、この分離が理論からの演繹ではなく、制約からの必然だった点だ。当時のハードウェアでは、オンラインのレスポンスタイムを守りつつリアルタイムで全集計を維持することは不可能であり、重い集計は夜間にまとめて処理するほかなかった。「即時性が必要な更新」と「整合した状態での参照」を時間軸で分離した結果、コマンドとクエリが自然に分かれた。後年 Young らが理論として整理したものを、現場は性能要件への対処として先に実践していたのである。

旧来の勘定系と現代のイベントソーシングの差分

同じ追記ログ方式でも、両者には設計思想上の決定的な違いがある。

• リプレイの目的: 銀行バッチの追記ログは、主に監査・突合・障害復旧のためのものであり、「任意の過去状態を自由に再構築する」ことを設計目標とはしていなかった。現代のイベントソーシングは、過去状態の復元やプロジェクションの再構築を積極的な機能として位置づける。
• 更新頻度: 旧来は日次バッチのため、参照系は「昨日時点」——結果整合性が日単位だった。現代はストリーム処理でニアリアルタイムにプロジェクションを更新でき、遅延は秒〜分のオーダーに収まる。
• モデリング思想: 旧来は「取引を記録する」という素朴な発想にとどまった。Young の貢献は「状態遷移＝ドメインイベントこそが本質であり、それを中心にモデリングする」という思想的転換を加えた点にある。同じ追記ログでも、設計の出発点が異なる。

まとめ

歴史的には「銀行はずっとイベントソーシングを実践していた」と言えると同時に、「だが誰もそう呼ばず、思想として体系化もしていなかった」とも言える。さらに遡れば、複式簿記は500年前から同じ哲学を実践していた。

イベント駆動アーキテクチャの本質は、特定の技術スタックではなく、「過去を消さず、状態を出来事の積み重ねとして捉える」という考え方そのものにある。Greg Young らの仕事は、ゼロからの発明ではなく、現場の暗黙知と数百年来の知恵に名前と理論を与え、再利用可能な設計パターンとして確立したことだった。新しいパターンに出会ったとき、その起源を古い実務に探してみると、理解がぐっと深まることがある——複式簿記とイベントソーシングは、その好例である。