Ledgerと複式記帳
金額を直接上書きせず、理由を持つ仕訳の積み重ねから残高を導く設計を学びます。
台帳、振込、KYC、権限、監査、照合をMinibankの実装と結び付ける。
先に学ぶ内容 — Prerequisite: 基礎 / 銀行業務学ぶこと — LEARNING GOALS
このページで学ぶこと
- Journal EntryとJournal Line
- DebitとCredit
- append-onlyとreversal
体験07 · LEDGER（台帳と複式記帳）
残高の数字と、台帳の記録を見比べよう
まずは予想をひと言。本文を読んだ後、実際の取引表示と会計上の仕訳を見比べます。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
振込したお金は、残高の数字を書き換えるだけで十分でしょうか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
「今いくらか」と「なぜその金額になったか」は、同じ問いでしょうか？
ヒント2を見る
間違った取引が見つかったとき、その記録を消してよいでしょうか？
もっと詳しく：この問いで使う専門用語
- Ledger（台帳）は、お金が増減した理由を積み上げて残す正式な記録です。
- 複式記帳は、1つの出来事を借方と貸方の両側へ同額記録する方法です。
- append-only（追記専用）は、確定済みの記録を書き換えず追加だけする方式です。
- 逆仕訳は、間違いを打ち消すために追加する反対向きの記録です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
台帳は、お金が増減した理由を消さずに積み上げる正式な記録です。残高はその記録を合計した結果にすぎません。
複式記帳では、1つの出来事を借方と貸方の両側へ同額記録します。借方・貸方は善悪や入出金ではなく、帳簿の左右の名前です。
間違いは過去の仕訳を書き換えず、反対向きの逆仕訳を追加して訂正します。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Journal EntryとJournal Line
Entryは1件の出来事の見出し、Lineはその出来事による各勘定の増減明細です。
1つの振込が複数の勘定へどう影響したかをひとまとまりで説明できます。
journal_entriesの1行に対し、journal_linesを複数作り借方合計と貸方合計を一致させます。
借方・貸方
帳簿の左側と右側です。単純なプラス・マイナスではなく、勘定の種類で増える側が変わります。
資産・負債・収益などを一貫した規則で記録し、全体の釣り合いを検証できます。
顧客預金は銀行にとって負債なので、増加は貸方、減少は借方として表します。
append-only
確定済みの記録を更新・削除せず、新しい記録だけを追加する方式です。
過去を書き換えると、当時の残高や監査説明を再現できなくなります。
posted journalの変更をtriggerと権限で拒否し、訂正はreversalを追加します。
逆仕訳
元の仕訳と借方・貸方を反対にした、新しい訂正仕訳です。
誤りを取り消しつつ、元記録と訂正理由の両方を残せます。
元仕訳との関連を保存し、同じ対象を二重にreverseできない制御を置きます。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
3つの中心概念
| 概念 | 役割 | Minibank |
|---|---|---|
| Ledger Account | 金額を集計する勘定 | 顧客預金負債、system funding、fee revenue |
| Journal Entry | 1取引のヘッダー | 種類、通貨、説明、発生日時、逆仕訳元 |
| Journal Line | 勘定ごとの借方・貸方 | 片側だけ正数、最低2行で借貸一致 |
DBレベルの不変条件
- 各lineはdebitかcreditのどちらか一方だけが正数
- deferred constraint triggerがcommit時に2行以上・借貸一致・正の合計を検査
- journal_entriesとjournal_linesのUPDATE/DELETEをtriggerで拒否
- 公開roleはledger tableへ直接アクセスできない
- 訂正は元データの編集ではなく新しいreversal entry
実際のMinibankでは
顧客預金勘定はliability・normal_side creditです。その残高は `sum(credit) - sum(debit)` で計算されます。振込で送金元をdebitにすると銀行のその顧客への債務が減り、送金先をcreditにすると債務が増えます。
v8：Business EventからBalanceまでを1本でたどる
v7までは、振込や入金などの業務テーブルが仕訳を直接作っていました。v8では、利息支払や手数料徴収のような銀行内部の出来事を「Business Event」として記録し、Posting Rule（会計ルール）で仕訳に変換します。イベント・適用ルール・仕訳・各勘定の残高は相互に参照でき、管理画面の Ledger・Posting から1画面でたどれます。
- 01Business Event
- 02Posting Rule（版を固定）
- 03Journal Entry
- 04Journal Lines
- 05Ledger Account
- 06Balance（仕訳から再計算）
| 仕組み | MiniBankでの実装 |
|---|---|
| 二重記帳の防止 | （発生元, イベント種別, Idempotency Key）が一意。同じ内容の再送は既存イベントを返し、同じキーで内容が違えば PE009 で拒否 |
| 取消（Reverse） | 元仕訳の貸借を入れ替えた仕訳を追加。元仕訳は消さない。1つの仕訳を取消できるのは1回だけ |
| 訂正（Correct） | 誤ったイベントの取消と、正しい金額の訂正イベントを同じtransactionで記帳 |
| 残高再計算 | 仕訳明細だけから残高を計算し直し、v7の cached_balance と差額を比較（時点指定も可能） |
| 整合性チェック | 全体と仕訳ごとの借方＝貸方、残高差異、Event↔仕訳↔ルールの対応、取消仕訳の反転一致を検査し、結果をv7と同じ reconciliation.integrity_runs に保存 |
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
台帳と複式記帳の考え方を読んだところで、実際の取引表示と会計上の仕訳を見比べ、自分の言葉で説明してみます。
- 02実際に観察する — OBSERVE
同じ仕組みを、動く画面から観察する
まず顧客の入出金明細を開いて観察し、この教材へ戻ります。リンクは新しいタブで開きます。ログインが必要です。
アカウントがない場合は新規登録が必要です。本人確認・口座開設には管理者承認が必要です。承認前や操作できない場合も、この教材内の図・説明・Source Trail（教材の参照元）で代替学習し、次へ進めます。
ログイン・新規登録の入口を開く ↗操作できない場合：教材の参照元で確認する ↓もっと詳しく：管理者の画面で観察する
管理者ログインが必要です。権限がない場合は、次の「証拠を確認する」の教材による確認で進められます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
基本の順序は、画面 → API Route（依頼を受ける窓口）→ TransferService（処理をつなぐサービス）→ DB / RPC（記録の保存場所と、その処理の呼び出し）です。まず最初の2つを見て、続くサービスは「もっと詳しく」で確認します。
教材の参照元を確認する — Source Trail ↓仕訳のヘッダーと明細を作る定義。1つの取引がどう2行に分かれるかを探します。
supabase/migrations/20260819155221_create_journal_entries_and_lines.sqlMigration（DB定義の変更履歴）。commit時に借方合計と貸方合計が一致するかを検査する定義を確認します。
supabase/migrations/20260819155222_create_journal_balance_constraint_trigger.sql - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜ銀行では、残高とは別に取引記録（台帳）を残す必要があるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「残高」と「台帳」という2つの言葉を使って書いてみましょう。
ヒント2を見る
間違いを直すとき、記録を書き換えるのと、新しい記録を追加するのとでは何が違うか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Journal Entry、Journal Line、append-only、逆仕訳の4つを使って、間違った取引が見つかったときの対応を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- 残高と台帳が別の記録であると説明できる
- 間違いは書き換えではなく、逆仕訳の追加で訂正されると説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1借方は増加、貸方は減少という意味ですか？
違います。勘定種類により増える側が違います。借方と貸方はまず左右の名称として理解します。
Q2確定済み仕訳の誤りをUPDATEで直してよいですか？
原則として直しません。元を残し、逆仕訳と必要なら正しい仕訳を追加します。
Q3残高が合っていれば仕訳の片側が欠けてもよいですか？
いけません。借方と貸方の均衡は取引の説明可能性と異常検知の基礎です。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/20260819155221_create_journal_entries_and_lines.sql仕訳headerとline - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/20260819155222_create_journal_balance_constraint_trigger.sqlassert_journal_entry_balanced()commit時の借貸一致 - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/20260819155223_create_post_journal_entry_function.sqlpost_journal_entry()台帳の内部write path - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/20260819155224_add_ledger_append_only_protection.sqlUPDATE/DELETE防止 - 現在の実装 — CURRENT IMPLEMENTATION
scripts/regression/suites/ledger.mjs台帳不変条件の回帰テスト - 現在の実装 — CURRENT IMPLEMENTATION
supabase/migrations/20260924100000_v8_posting_engine.sqlposting.post_event / posting.reverse_event / posting.correct_event / posting.run_integrityv8 Posting Engine - 現在の実装 — CURRENT IMPLEMENTATION
scripts/banking/v8-posting.test.mjs冪等性・同時実行・取消・訂正・整合性検出のDBテスト - 現在の実装 — CURRENT IMPLEMENTATION
src/app/admin/(protected)/ledger/events/[id]/page.tsxEventTracePage()EventからBalanceまでのトレース画面