InfoQ が 30+ Updates per Second per Account: Uber Scales Ledger Processing with Batching と報じました。1 アカウントあたり秒間 30 件超の更新を捌くという話は、単なる高負荷自慢ではありません。ポイント・電子マネー・ウォレット・在庫・売上といった「残高（バランス）」を扱うシステムは、1 円・1 個のズレも許されず、しかも同じアカウントへの更新が集中すると行ロック競合で詰まる——という、残高システム共通の難所を Uber がどう乗り越えたかを示しているからです。
一方で受託開発の現場では、「ポイントが二重付与された」「キャンセルと購入が交差して残高がマイナスになった」「月次の締めで台帳と売上が合わない」という事故が後を絶ちません。受託でシステム開発を支える立場では、これは 「残高を足し引きできるか」ではなく、「同時更新が集中しても整合性を崩さず、詰まらせず、後から監査で追える形で引き渡せるか」を設計に組み込む課題だと捉えています。これまで Meta 級データ取り込み基盤の再設計受託（GH Media） で扱った 大量データ処理、Postgres / SQLite による堅牢ワークフローのバックエンド受託（GH Media） で扱った 処理の信頼性、バックエンドのメモリ・コスト最適化受託（GH Media） で扱った 性能設計と接続して、本記事では 「残高・台帳基盤設計支援」を 受託パッケージとして整理します。
なぜ「残高システム」は普通の CRUD と違うのか
| 観点 | 普通の CRUD | 残高・台帳設計 |
|---|---|---|
| 正しさ | だいたい合えばよい | 1 円もズレてはいけない |
| 同時更新 | 稀にしか競合しない | 同一口座に集中して競合 |
| 整合性 | 上書きで十分 | 加減算の順序が結果を変える |
| 取り消し | 削除すれば戻る | 訂正は逆仕訳で記録 |
| 監査 | あれば便利 | 全取引を追えることが必須 |
| 成果 | 動けばよい | ズレない・詰まらない・追える |
つまり 「残高を計算できる」ことと「ズレず・詰まらず・追える台帳を作れる」ことは別物であり、受託でも 「追記型の仕訳・冪等な取り込み・競合に強い更新方式を設計し、監査と締めまで含めて引き渡す」ことが品質の前提になりました。これにより 「ズレない残高基盤」を成果物として保証できます。
残高システムを壊す 3 つの落とし穴と設計原則
原則 1: 「現在値の上書き」ではなく「追記型の仕訳」で持つ
残高カラムを直接書き換えると、競合と障害で簡単にズレます。受託では 取引を 1 行ずつ追記する台帳（Ledger）+ 残高はその集計という構造で、いつでも再計算・監査できる設計にします。
原則 2: 「二重実行」を冪等キーで無害化する
リトライ・通知重複は二重付与を生みます。受託では 取引 ID を一意キーにした冪等な取り込みで、何度実行しても結果が変わらないようにします。
原則 3: 「行ロック競合」をバッチ・分割で逃がす
人気アカウントへの集中更新は行ロックで詰まります。受託では 更新のバッチ集約や口座のシャーディングで、スループットを保ったまま整合性を守ります（Uber 事例の核心）。
受託で提供する「残高・台帳基盤設計支援」5 フェーズ
フェーズ 1: 現状診断（1〜2 週間）
- 残高ズレ・二重付与・締め不整合の発生状況
- 同時更新のホットスポット（人気口座）の特定
- 現行のトランザクション設計・冪等性の評価
- 監査・締め要件の整理
フェーズ 2: 台帳設計（1〜2 週間）
- 追記型 Ledger とスナップショットの設計
- 冪等キー・整合性制約の定義
- 競合回避方式（バッチ / シャーディング）の選定
- 締め・突合・訂正（逆仕訳）フローの設計
フェーズ 3: 実装（3〜5 週間）
- Ledger テーブルと残高集計の実装
- 冪等な取引取り込みパイプライン
- 高頻度更新のバッチ集約 / ロック戦略
- 監査ログ・突合ジョブの実装
フェーズ 4: 検証・移行（1〜2 週間）
- 同時更新・障害注入での整合性テスト
- 既存残高データの移行と初期突合
- 負荷テストでスループット確認
フェーズ 5: 継続運用（継続）
- 日次/月次の自動突合・締め
- 残高ズレ検知アラート
- ホットスポットの継続監視と分割
受託向け技術スタック標準セット
| レイヤ | 推奨アプローチ | 代替 |
|---|---|---|
| 台帳 | 追記型 Ledger + スナップショット | 残高カラム直接更新（非推奨） |
| 冪等性 | 取引 ID の一意制約 | 自前の重複チェック |
| 競合回避 | バッチ集約 / シャーディング | 単純行ロック（詰まる） |
| 整合性 | DB トランザクション + 制約 | アプリ任せ |
| 突合 | 自動リコンサイル | 手作業の月次照合 |
| 監査 | 全取引の不可変ログ | 上書きログ |
どの案件に必要か / 不要か
| 必要な案件 | 優先度が低い案件 |
|---|---|
| ポイント / ウォレットを扱う | 金額を扱わない |
| 在庫・残高がマイナス厳禁 | 在庫概念がない |
| 同一口座に更新が集中する | 更新頻度がごく低い |
| 監査・締めが事業要件 | 厳密な突合が不要 |
| 二重付与が起きている | 整合性事故の実績がない |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象範囲 | 台帳化する残高 | 既存残高の移行 |
| 整合性保証 | ズレ検知・突合の責任分界 | 許容誤差ゼロの前提 |
| 性能 | スループット目標 | ピーク時の要件 |
| 訂正 | 逆仕訳・取り消し方針 | 監査要件 |
| 引き渡し | 設計 / 突合 Runbook | 保守体制 |
| 継続保守 | 締め / 監視 | 運用費用 |
価格モデル — 残高・台帳基盤パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 台帳診断 | 35 万円〜 | 1 システム | ズレ要因の棚卸し + 設計レポート |
| 標準構築 | 180 万円〜 | 中規模 | Ledger 設計 + 冪等取り込み + 突合 |
| 本格構築 | 360 万円〜 | 高負荷 | + バッチ集約 / シャーディング + 負荷試験 |
| Lite 保守 | 8 万円〜 / 月 | 小規模 | 突合 + ズレ検知 |
| Standard 保守 | 24 万円〜 / 月 | 中規模 | + 締め自動化 + ホットスポット対応 |
顧客側 ROI 試算（ポイント / ウォレット想定）
| 項目 | 残高直接更新 | 台帳基盤 | 差分 |
|---|---|---|---|
| 二重付与 | 都度発生・補填 | 冪等で防止 | 損失と返金対応の削減 |
| 残高ズレ | 締めで発覚 | 日次突合で即検知 | 信頼毀損の回避 |
| 詰まり | ピークで停止 | バッチで吸収 | 機会損失の抑制 |
| 監査対応 | 手作業で追跡 | ログで即追跡 | 対応工数の削減 |
| 年間効果 | — | — | 付与損失の削減 + 信頼の維持 |
標準構築（180 万円〜）でも、二重付与による損失と、残高不整合による信頼毀損を防ぐだけで十分に正当化できます。金銭に直結する残高は、事故 1 件の代償が設計コストを上回ります。
ハマりやすい 5 つの落とし穴
落とし穴 1: 残高カラムを直接更新する
競合と障害で静かにズレます。追記型 Ledger + 集計にします。
落とし穴 2: リトライを冪等にしない
通知重複で二重付与します。取引 ID の一意制約を張ります。
落とし穴 3: 人気口座を単純行ロックで捌く
ピークで詰まり停止します。バッチ集約 / 分割で逃がします。
落とし穴 4: 取り消しを物理削除で行う
監査で追えなくなります。逆仕訳で訂正を記録します。
落とし穴 5: 突合を月次の手作業に頼る
発覚が遅れ被害が拡大します。日次の自動突合にします。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜2 | ズレ要因・ホットスポットの棚卸し |
| Week 3〜4 | 追記型台帳 + 冪等 + 競合回避の設計 |
| Week 5〜9 | 実装 + 障害注入・負荷テスト |
| Week 10〜11 | 残高移行 + 初期突合 |
| Week 12〜13 | 締め自動化 + ズレ検知の運用開始 |
まとめ — 「とりあえず足し引き」から「ズレない・詰まらない・追える状態で引き渡す」へ
残高を扱うシステムは、1 円・1 個のズレも許されず、同時更新が集中すると詰まります。受託でシステム開発を支える立場では、追記型の仕訳・冪等な取り込み・競合に強い更新方式を設計し、監査と締めまで含めて引き渡す 「残高・台帳基盤設計支援」が、ズレない残高基盤を成果物として届ける新しい主力サービスです。大量データの取り込み基盤は Meta 級データ取り込み基盤の再設計受託（GH Media） を、長時間処理の堅牢化は Postgres / SQLite による堅牢ワークフロー受託（GH Media） を併読してください。
弊社では台帳診断 / 標準構築 / 本格構築 / Lite / Standard の各段階で本パッケージを提供しています。「ポイントが二重付与される」「締めで残高が合わない」「ピークで決済が詰まる」というご相談は お問い合わせフォーム からお気軽にどうぞ。
