「1円のズレも許されない」——Fintech Engineering Handbookが示す、金融ソフトウェアの設計哲学がWebアプリケーション全体に求める根本的転換

なぜ「1円のズレ」は許されないのか——金融ソフトウェアが示す「完全性」の定義

銀行口座から1万円を引き出すとき、私たちは当たり前のように「正確に1万円」が出てくると信じています。しかし、このシンプルな期待の裏には、数十年にわたって磨き上げられたソフトウェア設計の哲学があります。

金融機関が扱うシステムでは、1円の誤差も許されません。なぜなら、その1円は誰かの資産を侵害するからです。従来、この「完全性」を実現するためには、複雑で高コストなエンタープライズシステムが必要とされてきました。しかし、近年のフィンテック企業の台頭により、**より洗練された設計原則**が明らかになってきました。それが、GitHubで公開されている「Fintech Engineering Handbook」です。

このハンドブックが重要なのは、単なる「金融業界向けのTips集」ではなく、**モダンなアーキテクチャでお金の正確性をどう担保するか**という根本的な問いに答えているからです。AWS、Google Cloud、Kubernetesといった分散システムの時代に、どうやって「1円のズレ」を防ぐのか。その答えは、従来の金融システムの常識を覆すものです。

「二重動作」を排除する設計——冪等性がなぜ金融システムの生命線なのか

Fintech Engineering Handbookの最初の原則は、**お金を二重に動かさない**ということです。これは「冪等性（べきとうせい）」という概念と関連しています。

冪等性とは、同じ操作を何度繰り返しても、結果が同じであるという性質です。例えば、あなたが送金ボタンを3回押してしまった場合、通常のWebアプリケーションでは3回送金が実行されてしまいます。しかし金融システムでは、**最初の1回だけが有効で、残りの2回は自動的に無視される**必要があります。

これを実現するには：

• トランザクションIDの導入——各取引に一意のIDを付与し、重複を検出
• データベースレベルの制約——同じトランザクションIDでの二重実行をそもそも受け付けない
• ステートレスな設計——どのサーバーで処理しても同じ結果になる仕組み

クラウドネイティブなシステムでは、ネットワーク遅延やサーバーの再起動により、同じリクエストが複数回処理される可能性があります。金融システムがこれに対応するには、**アプリケーションレベルではなく、データベースの設計そのものに冪等性を組み込む**必要があるのです。

「端数を勝手に消さない」——丸め誤差が引き起こす監査地獄

次の原則は、**端数（丸め誤差）の取り扱い**です。

一見するとシンプルな問題に見えますが、これが金融システムで最も厄介な問題の1つです。例えば、1000円を3分割する場合、計算上は333.333…円になります。では、この0.001円をどうするのか？

従来のシステムでは、浮動小数点演算（floating-point arithmetic）が使われてきました。しかし、浮動小数点は**本質的に不正確**です。コンピュータの2進数表現の関係で、0.1 + 0.2 ≠ 0.3という問題が発生します。

Fintech Engineering Handbookの推奨は、**固定小数点演算（decimal型）またはBigDecimal型の使用**です。すべてのお金を「最小単位（1円未満の場合は1銭）」の整数として扱うことで、丸め誤差を完全に排除します。加えて、以下の原則が重要です：

• 丸め方法の明示化——切り上げ？切り下げ？四捨五入？決めたら絶対に変えない
• 丸めの記録——どこでいくら丸めたのか、すべて記録に残す
• 丸め誤差の帳簿——端数がどこに吸収されたのか、追跡可能にする

この厳密さは、銀行の「日計表」（毎日の収支をチェックする帳簿）で数円の誤差が発生した場合、徹底的に原因を追及する金融実務から生まれています。

「後から説明できる形で記録する」——監査ログの設計がコンプライアンスを決める

最後の原則が、**完全な監査証跡（audit trAIl）**です。

金融機関では、なぜか数百万円の誤差が発見された場合、「いつ、誰が、何をしたのか」を数年前まで遡って説明できなければいけません。これはコンプライアンス要件であり、法的責任です。

モダンなシステムでこれを実現するには：

• イベントソーシング——すべての変更を「イベント」として記録し、状態はその集計から導き出す
• 不変のログ——一度記録されたログは削除・改ざん不可
• タイムスタンプの正確性——日本の場合、JJYY信号による正確な時刻同期が必要な場合も
• メタデータの完全性——IPアドレス、ユーザーID、変更前後の値、すべてを記録

つまり、Fintech Engineering Handbookが求める監査ログは、**単なるデバッグ用の情報ではなく、法的証拠として通用するドキュメント**なのです。これは、機械学習やAIが金融意思決定に関わる場合、「なぜこの融資を断ったのか」を説明可能にする要件にも繋がります。

なぜこれはテック業界全体に必要なのか

Fintech Engineering Handbookの原則は、何も金融機関だけに限りません。

ECサイトの在庫管理、広告プラットフォームの課金、サブスクリプション業者の請求——**お金が動く場所すべてで、同じ原則が求められます**。しかし多くのスタートアップやテック企業は、スピードを優先してこれらの原則を軽視しがちです。その結果、数年後に「なぜか売上と帳簿が合わない」という悪夢に直面することになります。

さらに、AIやMLの時代においても重要性は増しています。金融機関がアルゴリズムに意思決定を委ねる場合、その決定ロジックを「後から説明できる形で記録する」ことは、単なる監査要件ではなく、社会的責任になりつつあります。

まとめ——「完全性の哲学」がもたらす未来

Fintech Engineering Handbookが示すのは、**「お金を扱うシステムは、いかなる場合でも100%正確である必要がある」という不可侵の原則**です。これは、クラウドネイティブ、マイクロサービス、AIといったモダンテクノロジーの時代でも変わりません。

むしろ、システムが複雑になるほど、この原則の重要性は増します。なぜなら、複雑さは誤差の温床だからです。

金融ソフトウェアの設計原則は、結局のところ**「信頼」**を作るための哲学です。ユーザーが安心してお金を預けられるシステムとは、技術的な完全性と、それを立証する記録が一体になったものなのです。テック業界がこの原則を学び、実装することは、単なる技術的進化ではなく、社会における信頼インフラの構築を意味しているのです。