【ITニュース解説】Why Your FinTech App is Bleeding Money (And How Double-Entry Bookkeeping Fixes It)

システムエンジニアが金融アプリケーションを開発する際、お金の正確な管理は極めて重要だ。しかし、従来の「データベースの残高を直接更新する」方式では深刻な問題が生じうる。例えば、口座に100ドル持ち、60ドルの引き出し要求が同時に2回発生した場合、両方の処理が同時に「残高は100ドル」と読み取ることがある。その後、それぞれが残高を40ドルに更新すると、最終残高は40ドルとなり、合計120ドルが引き出されたにも関わらず、口座は100ドルしか持っていなかったという矛盾が生じる。残高はマイナス40ドルとなり、システムは実際よりも多くのお金を払い出したことになる。これは「レースコンディション」と呼ばれる同時実行性の問題であり、金融システムでは致命的となる。

この方式は監査性にも大きな問題がある。残高を上書きし続けると、過去にどのような取引が行われその残高になったのかという履歴が失われる。監査人が過去の残高の根拠を尋ねても、システムは現在の情報しか提供できず、具体的なお金の動きは追跡できない。お金は単なる数値ではなく、時間の経過とともに変化する権利や義務の記録であり、この履歴の欠如は金融システムに許容できない脆弱性をもたらす。

これらの問題を解決するため、金融業界で何世紀も使われてきた「複式簿記（double-entry bookkeeping）」の考え方をソフトウェア開発に応用する。複式簿記は、残高を直接変更せず、すべての取引を「不変な追記専用のイベントログ」として記録するという考え方である。これは、Gitのようなバージョン管理システムやイベントソーシングと呼ばれるアーキテクチャと似ている。Gitが変更履歴を積み重ね、現在の状態をその履歴から導き出すように、複式簿記でも、すべての金融取引を「仕訳伝票（Journal Entry）」として不変な形で記録し、口座の残高は、その口座に関連するすべての仕訳伝票の履歴を合計して計算される「ビュー（見方）」として扱われる。これにより、いつでも過去のどの時点の残高でも正確に再現でき、優れた監査性と回復力を持つ。

複式簿記の核心には、「デビット（Debit）」と「クレジット（Credit）」という概念がある。これらは一般的なお金の増減とは異なり、ある取引において価値がどこからどこへ移動したかを示す方向性である。すべての金融取引は価値の閉じたループの移動であり、お金が突然発生したり消滅したりすることはないため、必ず2つ以上の「記帳行（Posting Line）」で構成され、常に「デビットの合計とクレジットの合計が等しくなる」という厳格な「ゼロサム不変条件」を満たす必要がある。この条件を満たさない取引は、数学的に無効としてシステムによって拒否され、データの整合性が強力に保証される。

複式簿記では、すべての口座を「資産（Asset）」「負債（Liability）」「資本（Equity）」「収益（Revenue）」「費用（Expense）」という5つの基本的な分類に割り当てる。この分類によって、デビットとクレジットがその口座の残高に与える影響が決まる。例えば、資産や費用の口座はデビットで増加し、クレジットで減少する。一方、負債、資本、収益の口座はクレジットで増加し、デビットで減少する。このように、お金の性質に応じて口座を分類し、デビットとクレジットのルールを適用することで、システム全体のお金の流れを正確かつ一貫して管理できる。

これらの会計原則をプログラミングで実装する際、特に金融システムではわずかな計算誤差も許されないため、JavaScriptの標準的な浮動小数点数ではなく、Decimal.jsのような任意精度計算ライブラリを必ず使用し、誤差を避ける。システムは、口座定義、記帳、取引全体といった要素で構成され、これらをTypeScriptの型定義で明確に構造化できる。LedgerEngineクラスを通じて、口座の作成、取引記録（コミット）、残高取得を行う。取引コミット時には、ゼロサム不変条件が厳密にチェックされ、不正な取引はエラーとして拒否される。残高取得時には、その口座に関連するすべての仕訳伝票の履歴をたどり、各記帳のデビットとクレジットを口座の種類に応じ加算・減算し、正確な残高を計算する。

SaaSの年間サブスクリプション料金99ドルをユーザーが支払う場合を例に取る。この取引は、システム内の「Stripeからの入金用現金口座」（資産口座）が99ドル「デビット」され、同時に「繰延べ収益口座」（負債口座）が99ドル「クレジット」されるという仕訳伝票として記録される。これにより、お金の発生源から最終的な使用まで追跡できる監査可能な記録が残る。従来の変更可能な残高管理方法を捨て、複式簿記が提供する不変なイベントログと厳格なゼロサム不変条件を採用することで、金融ソフトウェアは非常に堅牢で信頼性が高く、過去の状態を正確に再現できる「壊れない」アーキテクチャへと進化できる。