残高管理から台帳サービスへの進化

2026/9/16 Merpay Tech Talk 〜メルカリグループ全体を支える決済基盤の全容[会計編]〜 で発表した内容です
https://mercari.connpass.com/event/404444/

Transcript

1. 残高管理から台帳サービスへの進化 Merpay Tech Talk 〜メルカリグループ全体を支える決済基盤の全容 [会計編]〜 @kobaryo 1
2. kobaryo 2024年新卒入社 Payment & Customer Platform Balance チームのProduct Engineer 台帳基盤や債権管理基盤の開発・運用がメ イン 2
3. Outline 01 これまでの会計連携 02 台帳サービスを使った会計連携の全体像 03 台帳サービスの高い拡張性 3
4. Outline 01 これまでの会計連携 02 台帳サービスを使った会計連携の全体像 03 台帳サービスの高い拡張性 4
5. 前提：会計コードを引き回すことによる会計連携 • 会計帳簿サービス に各マイクロサービスが会計イベントを 送信 • プロダクトから会計コード を受け取り、決済時の情報とともに帳簿 サービスに伝え、その情報をもとに会計レポートを 出力 ◦ 勘定科目を出すにはプロダクト側の情報が不可欠 5
6. これまでのメルペイの会計連携 プロダクト QRコード決済 ネット決済 メルカード メルカリ … 決済サービス 決済基盤 残高管理サービス 会計帳簿サービス 6
7. これまでのメルペイの会計連携 プロダクト QRコード決済 ネット決済 お客さまが加盟店で QRコード決済 メルカード メルカリ … 決済サービス 決済基盤 残高管理サービス 会計帳簿サービス 7
8. これまでのメルペイの会計連携 プロダクト QRコード決済 ネット決済 メルカード メルカリ … 会計コード 決済サービス 決済基盤 残高管理サービス 会計帳簿サービス 8
9. これまでのメルペイの会計連携 プロダクト QRコード決済 ネット決済 会計コード メルカード メルカリ … 決済サービス 決済基盤 残高管理サービス 会計帳簿サービス 9
10. これまでのメルペイの会計連携 プロダクト QRコード決済 ネット決済 メルカード メルカリ … 決済サービス 残高消費 決済基盤 残高管理サービス 会計帳簿サービス 会計コード validation 10
11. これまでのメルペイの会計連携 プロダクト QRコード決済 ネット決済 メルカード 決済サービス メルカリ … 変動ごとの残高の Snapshotも記録 残高消費 決済基盤 お客さまの残高消費 残高管理サービス 帳簿サービス 残高変動 残高 会計コード validation -1000 残高 +1000 1000 0 11
12. これまでのメルペイの会計連携 プロダクト QRコード決済 ネット決済 メルカード メルカリ … 決済サービス 決済基盤 売上金付与 残高管理サービス 加盟店様の売上金付与 会計帳簿サービス 残高変動 残高 会計コード +1000 1000 validation 12
13. これまでのメルペイの会計連携 プロダクト QRコード決済 ネット決済 メルカード メルカリ … 勘定科目に対応 決済サービス 非同期 決済基盤 会計コード + 残高種別 残高管理サービス 会計帳簿サービス 13
14. これまでのメルペイの会計連携 • 残高管理サービスはお金が増えた・減ったの単式簿記 • 一方で会計帳簿サービスが会計レポートを出すのに必要なのは お金の流れを表す複式簿記 • 決済サービスが会計連携の責務を持つ必要がある • 会計上のお金の流れとその結果である残高との間の紐付けが 間接的になるので、リコンサイルや調査がしづらい 14
15. これまでのメルペイの会計連携 プロダクト QRコード決済 ネット決済 メルカード メルカリ … 非同期 決済サービス 会計コード 決済基盤 残高管理サービス 会計帳簿サービス 決済には直接関 係ない会計情報 15
16. これまでのメルペイの会計連携 プロダクト QRコード決済 ネット決済 メルカード Product sideが会計 に何が必要か意識 する必要がある メルカリ … 非同期 決済サービス 会計コード 決済基盤 残高管理サービス 会計帳簿サービス 決済には直接関 係ない会計情報 16
17. Outline 01 これまでの会計連携 02 台帳サービスを使った会計連携の全体像 03 台帳サービスの高い拡張性 17
18. 残高管理サービスから台帳サービスへの進化 • 実体のある残高を管理する残高管理サービスから、お金の 流れ全てを記帳する 台帳サービス (ledger) に進化 ◦ お金の流れ全般とその結果のSingle Source of Truth ◦ 会計帳簿に記帳すべきものはお金の流れとしてまず台帳に 記帳し、会計連携の責任は台帳サービスが持つ 18
19. 複式簿記によって会計に必要な情報を保持 • 残高を増やす・減らすではなく 価値交換 (Exchange) という単位の endpoint → 複式簿記 ◦ お金の流れを全てこのExchangeで表すので、抽象度が高く 拡張性も高い Sourceの口座 Targetの口座 金額 会計コード <お客さまの残高口座 ID> <加盟店様の売上金口座 ID> 1000 merpay_qr_payment 会計コード＋ Source/Targetの 口座の残高種別で勘定科目が定まる 19
20. 台帳サービスを利用した会計連携 プロダクト QRコード決済 ネット決済 メルカード メルカリ … 決済サービス 決済基盤 台帳サービス New 会計帳簿 サービス 20
21. 台帳サービスを利用した会計連携 プロダクト QRコード決済 ネット決済 メルカード メルカリ … 会計コード 決済サービス 決済基盤 台帳サービス New 会計帳簿 サービス 21
22. 台帳サービスを利用した会計連携 プロダクト QRコード決済 会計コード ネット決済 メルカード メルカリ … 決済サービス 決済基盤 台帳サービス New 会計帳簿 サービス 22
23. 台帳サービスを利用した会計連携 プロダクト QRコード決済 validation 決済基盤 ネット決済 メルカード メルカリ … 決済サービス Exchange 会計コード 台帳サービス New 会計帳簿 サービス 23
24. 台帳サービスを利用した会計連携 プロダクト QRコード決済 ネット決済 メルカード メルカリ … 決済サービス 決済基盤 勘定科目に 対応 会計コード + 残高種別 台帳サービス 非同期 New 会計帳簿 サービス 24
25. 台帳サービスを利用した会計連携 プロダクト QRコード決済 ネット決済 メルカード メルカリ … 決済サービス 会計コード 決済基盤 台帳サービス 会計帳簿サービスの事情を気にせず、 お金の移動のみを気にすれば良い Exchange New 会計帳簿 サービス 25
26. 台帳サービスの利点 • 信頼性の高さ ◦ 確定した残高情報のログと会計のデータが1対1に対応するので リコンサイルが容易 ◦ お金の流れが確定したものについてのみ会計連携される ことがアーキテクチャ的に保証される • 上流からの扱いやすさ ◦ プロダクト側が会計帳簿システムの事情を知らなくて良い ▪ 気にするのはお金の流れまで ◦ 残高種別による勘定科目の違いを台帳サービスが吸収 26
27. 台帳サービスの利点 • お金の流れであるフロー情報だけでなく、システムから ストック情報 を出しやすい 例：メルカリグローバルアプリ Seller（日本） ある時点でここにいくら分の資 産があるか知りたい Buyer（海外） 倉庫 ① ② 27
28. 口座残高を利用したストック情報の導出 • 状態ごとに口座・残高種別を分け、状態遷移を Exchangeで表 す • ある時点でのある状態の資産の額は、その時点での口座残高 そのもの 知りたい時点の口座の Snapshotを見れば良い Exchange ① Buyerの口座 Exchange ② 倉庫 Sellerの口座 28
29. Outline 01 これまでの会計連携 02 台帳サービスを使った会計連携の全体像 03 台帳サービスの高い拡張性 29
30. 台帳サービスの特徴 • 残高種別（・通貨・地域）の新規追加が容易 ◦ 新規ビジネス・会計要件に素早く対応可能 ◦ Account Specによる残高の振る舞いの宣言的な定義 ◦ 追加による他マイクロサービスとのインターフェースやDBス キーマへの影響がほとんどない 30
31. Account Spec • 残高種別ごとの振る舞いを宣言的に定義 var funds = accountSpec{ UpdatePolicy: everytime } var flow = accountSpec{ UpdatePolicy: logOnly } var stock = accountSpec{ UpdatePolicy: async } 31
32. Account Spec • 残高種別ごとの振る舞いを宣言的に定義 var funds = accountSpec{ UpdatePolicy: everytime } var flow = accountSpec{ UpdatePolicy: logOnly } var stock = accountSpec{ UpdatePolicy: async } • 変動に対して残高を毎回 更新 • たとえばお客さまの残高は 0を下回ってはならないの で、毎回同期的に更新され る必要がある 32
33. Account Spec • 残高種別ごとの振る舞いを宣言的に定義 var funds = accountSpec{ UpdatePolicy: everytime } var flow = accountSpec{ UpdatePolicy: logOnly } var stock = accountSpec{ UpdatePolicy: async } • 変動に対して変動のみ記 録し、残高は更新しない • 残高のロックを取らないの で、トランザクション数が多 い状況下でも動く • 会計上のフロー情報のた めであれば残高を管理す る必要はない 33
34. Account Spec • 残高種別ごとの振る舞いを宣言的に定義 var funds = accountSpec{ UpdatePolicy: everytime } var flow = accountSpec{ UpdatePolicy: logOnly } var stock = accountSpec{ UpdatePolicy: async } • 変動に対して残高を非同 期に更新 • 残高のロックを取らないの で、トランザクション数が多 い状況下でも動く • 会計上のストック情報であ れば、残高変動時のチェッ クは必要ない 34
35. まとめ • 台帳サービスになることで進化した点 ◦ 複式簿記により、実際のお金の流れと会計情報の間の 信頼性が向上 ◦ フロー情報だけでなくストック情報といった会計情報もシス テムで対応 ◦ 高い拡張性による新規ビジネス・会計要件への素早い 対応 35