学習・技術検証用デモ — 本システムは実際の銀行サービスではありません。

公開情報をもとに構築した教育目的のシステムです。実在する個人情報・口座情報・機密情報・認証情報等を入力しないでください。

ミニ銀行ACADEMY SYSTEM LEARNING
銀行システムをコードから学ぶ銀行デモへ
教材メニュー
学習進捗0 / 134
あと134項目
INTERMEDIATE · 中級COURSE 03 · BANKING SYSTEM

銀行会計 Learning Hub

普通預金・振込・入出金・手数料・定期預金を、利用者の操作から仕訳、GL、Subledger、試算表、照合、整合性検査、監査まで一本につないで学びます。

03 / 08
BANKING SYSTEM · 銀行システム

台帳、振込、KYC、権限、監査、照合をMinibankの実装と結び付ける。

先に学ぶ内容 — Prerequisite: 基礎 / 銀行業務

学ぶこと — LEARNING GOALS

このページで学ぶこと

  • 顧客預金が銀行の負債である理由と、4種類の勘定の通常残高
  • 取引をAccounting Ruleと仕訳へ翻訳する方法
  • GL・Subledger・Trial Balance・Reconciliationの役割分担
  • 二重処理防止と、取引を後から説明できる証拠のつながり

体験62 · ACCOUNTING（視点を入れ替える）

顧客の預金は、銀行の帳簿でも「資産」として記録されるか確かめよう

まずは予想をひと言。本文を読んだ後、実際のAccounting Learning Hubと管理画面で確認します。

体験学習 · STEP 1 / 5
  1. 01
    まず予想する — PREDICT

    まずここだけ：思ったことをひと言書く

    顧客の預金1,000,000円は、銀行の帳簿でも顧客と同じように「資産」として記録されると思いますか？

    正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。

    ヒント1を見る

    顧客にとっての『資産』は、預かる側にとっても同じ言葉で記録されるでしょうか？

    ヒント2を見る

    『預かったお金を返す義務がある』という関係を思い出してみましょう。

    もっと詳しく：この問いで使う専門用語
    • 資産は、現金や受け取る権利など組織が持つ経済的価値です。
    • 負債は、将来他者へ返す・支払う義務です。
    • 内部振込の仕訳は、送金元の預金負債を減らし送金先の預金負債を増やします。
まずはひと言だけで大丈夫です。

この後の本文を最後まで読んでから、実際に操作して確かめるステップへ進みます。

BANKING ACCOUNTING LEARNING HUB

操作・仕訳・検査を、一本の物語として学ぶ

会計用語を暗記するページではありません。「利用者の操作が、どの規則で記帳され、どう検査・説明されるか」を順番にたどります。

01 · PERSPECTIVE

同じ100万円でも、見る人が変わると名前が変わる

CUSTOMER VIEW私の普通預金 1,000,000円

顧客にとっては、銀行から受け取れる価値なので「資産」です。

BANK VIEW顧客預金負債 1,000,000円

銀行にとっては、求められたら返す義務なので「負債」です。

DEBIT NORMAL資産 Asset

借方で増え、貸方で減る

DEBIT NORMAL費用 Expense

借方で増え、貸方で減る

CREDIT NORMAL負債 Liability

貸方で増え、借方で減る

CREDIT NORMAL収益 Revenue

貸方で増え、借方で減る

02 · END-TO-END MAP

1件の取引が、信用できる記録になるまで

  1. 01
    Business Transaction振込・入金・満期など、現実の出来事
  2. 02
    Accounting Event会計へ記録すべき出来事として識別
  3. 03
    Accounting Ruleどの勘定を借方・貸方にするか決定
  4. 04
    Journal Entry1つの出来事を表す仕訳ヘッダー
  5. 05
    Journal Lines勘定と金額を借方・貸方へ記録
  6. 06
    General Ledger勘定ごとの増減と残高へ集約
  7. 07
    Subledger顧客・契約単位の内訳を保持
  8. 08
    Trial Balance全勘定の借貸合計を一覧化
  9. 09
    Reconciliation別々の記録同士を突き合わせる
  10. 10
    Integrityあり得ない状態がないか検査
  11. 11
    Audit誰が何をしたかを後から説明
03 · JOURNAL EXAMPLES

6つの取引を借方・貸方に翻訳する

借方は「入金」、貸方は「出金」という意味ではありません。勘定区分と取引の意味から、左右を決めます。

入金

外部から100,000円を預かり、顧客への返還義務が増える

DEBIT · 借方SYSTEM_FUNDING（資産） 100,000円
CREDIT · 貸方Customer Deposit Liability（負債） 100,000円

MinibankのSYSTEM_FUNDINGは学習用の内部相手勘定です。実銀行の現金・決済勘定を再現したものではありません。

出金

顧客へ100,000円を返し、預金返還義務を減らす

DEBIT · 借方Customer Deposit Liability（負債） 100,000円
CREDIT · 貸方SYSTEM_FUNDING（資産） 100,000円

入金と反対向きです。顧客画面の『出金』と銀行帳簿の借方・貸方は同じ言葉ではありません。

振込

銀行全体の預金総額は変えず、返す相手をAからBへ移す

DEBIT · 借方送金元 Customer Deposit Liability 10,000円
CREDIT · 貸方送金先 Customer Deposit Liability 10,000円

負債の内部振替です。送金元への義務が減り、送金先への義務が同額増えます。

手数料

顧客への返還義務を減らし、銀行の手数料収益へ振り替える

DEBIT · 借方Customer Deposit Liability（負債） 330円
CREDIT · 貸方FEE_REVENUE（収益） 330円

預金元本は銀行の収益ではありません。サービスの対価である手数料だけを収益として分けます。

定期預金の作成

普通預金として返す義務を、定期預金契約として返す義務へ移す

DEBIT · 借方Customer Deposit Liability（負債） 500,000円
CREDIT · 貸方TIME_DEPOSITS_PAYABLE（負債） 500,000円

銀行全体の負債合計は変わらず、負債の種類と返済条件が変わります。

定期預金の満期

元本と利息を普通預金へ戻し、利息を銀行の費用として認識する

DEBIT · 借方TIME_DEPOSITS_PAYABLE 500,000円 ＋ INTEREST_EXPENSE 1,000円
CREDIT · 貸方Customer Deposit Liability 501,000円

元本の負債を消し、利息費用を加えた金額を普通預金の返還義務として計上します。利息ゼロなら費用行は作りません。

04 · LEDGER LAYERS

General Ledgerの合計を、Subledgerの内訳で説明する

GENERAL LEDGER · 統制勘定TIME_DEPOSITS_PAYABLE1,000,000円

定期預金として銀行が返す義務の合計

SUBLEDGER · 契約別の内訳
TD-A300,000円
TD-B200,000円
TD-C500,000円

確認式： GL残高 1,000,000円 ＝ Subledger契約残高の合計 1,000,000円。Minibankでは pooled account と public.time_deposits の契約明細を別々に持つため、この一致を継続的に確かめる必要があります。

05 · TRIAL BALANCE

借方と貸方が一致しても、「正しい」とは限らない

借方合計＝貸方合計
分かること

記録された仕訳全体が算術的に釣り合っているか。

分からないこと

金額・勘定・顧客・日付・取引そのものが正しいか。

06 · THREE CONTROLS

Reconciliation・Integrity・Auditは、別の質問に答える

MATCHReconciliation

別記録は一致する？

業務取引、仕訳、残高cache、契約明細など、別々に保存された記録を突き合わせます。

例：定期預金契約合計 ＝ TIME_DEPOSITS_PAYABLE
VALIDIntegrity

あり得ない状態はない？

借貸不均衡、孤立記録、残高不一致、actor衝突など、不変条件違反を探します。

例：posted仕訳に2行以上あり借貸一致
WHO / WHEN / WHYAudit

誰が何をした？

actor、時刻、対象、操作、前後関係を残し、判断と変更の経緯を説明します。

例：管理者操作と取引完了event
07 · RETRY SAFETY

「完了画面が出ない」から、二重取引は生まれる

WITHOUT IDEMPOTENCY
  1. 定期預金作成を送信
  2. DBは成功
  3. 応答だけ途切れる
  4. 利用者が再送
  5. 2契約になる危険
WITH IDEMPOTENCY
  1. 要求identityを付ける
  2. DBは1回だけ成功
  3. 応答だけ途切れる
  4. 同じ要求を再送
  5. 同一結果に収束

これは定期預金のような「1回で1契約を作る処理」に必要な設計原則です。要求identityだけでなく金額・期間などの内容も照合し、同じidentityを別内容へ使う要求は衝突として拒否する必要があります。実装状況は取引ごとに異なるため、各RPCの引数・一意制約・回帰テストを個別に確認します。

08 · OPEN THE REAL SCREEN

教材を読んだら、実際の記録を管理画面で追う

以下はすべて実装済み画面です。リンク先は管理者専用で、閲覧には管理者デモへのログインが必要です。教材から認証を迂回することはありません。

ADMIN DEMO REQUIREDAccounting Dashboard

勘定残高・直近仕訳・会計全体の入口

ADMIN DEMO REQUIREDJournal Explain

仕訳一覧から1件を選び、ruleとlinesを追跡

ADMIN DEMO REQUIREDTrial Balance

全勘定の借方・貸方・残高を確認

ADMIN DEMO REQUIREDReconciliation

業務記録と会計記録の照合結果

ADMIN DEMO REQUIREDTransaction Story

定期預金一覧から契約を選び、一連の記録を追跡

ADMIN DEMO REQUIREDIntegrity Check

不変条件違反や異常状態の検査

ADMIN DEMO REQUIREDAudit Log

重要操作のactor・時刻・対象を確認

日常語で理解する — PLAIN LANGUAGE

まず、ここだけつかむ

1

会計は『誰の視点で見るか』が最初の難所です。顧客の預金は顧客にとって資産ですが、銀行にとっては返す義務なので負債です。

2

借方・貸方はプラス・マイナスそのものではありません。資産・費用は借方で増え、負債・収益は貸方で増える、という勘定ごとのルールがあります。

3

信用できる会計は仕訳だけでは終わりません。GLの合計をSubledgerの内訳で説明し、Trial Balance、照合、整合性検査、監査を別々の目的で使います。

順番に理解する — DIFFICULT PARTS, STEP BY STEP

難しいポイントを、順番にほどく

専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。

01

資産

やさしく言うと

現金や受取る権利など、組織が持つ経済的価値です。通常は借方で増えます。

なぜ必要？

どの種類の勘定か分からないと、借方・貸方の意味を判断できません。

Minibankでは

入金の相手勘定など、取引の性質に応じた内部勘定で表します。

02

負債

やさしく言うと

将来、他者へ返す・支払う義務です。通常は貸方で増えます。

なぜ必要？

顧客預金を銀行の利益と誤解せず、返還義務として記録するためです。

Minibankでは

顧客の普通預金ledger accountは銀行側のliabilityとして扱われます。

03

収益

やさしく言うと

サービス提供などで得た価値です。通常は貸方で増えます。

なぜ必要？

顧客から預かった元本と、銀行が得た手数料を区別する必要があります。

Minibankでは

手数料は顧客預金負債の減少と、fee revenueの増加として記帳します。

04

内部振込の仕訳

やさしく言うと

送金元の預金負債を減らし、送金先の預金負債を増やします。

なぜ必要？

合計額を変えずに、誰へ返す義務かだけを移す出来事だからです。

Minibankでは

例として1万円なら、送金元顧客預金を借方1万円、送金先顧客預金を貸方1万円にします。

05

費用

やさしく言うと

利息の支払いなど、収益を得るために銀行が負担する価値です。通常は借方で増えます。

なぜ必要？

元本の移動と、銀行が新たに負担したコストを分けるためです。

Minibankでは

定期預金満期の利息をINTEREST_EXPENSEの借方へ記録します。

06

GLとSubledger

やさしく言うと

GLは勘定の合計、Subledgerは顧客や契約ごとの内訳です。

なぜ必要？

合計残高だけでなく、何の積み上げでその合計になったかを説明するためです。

Minibankでは

TIME_DEPOSITS_PAYABLEの残高をpublic.time_depositsの契約別元本合計と照合します。

07

Trial Balance

やさしく言うと

全勘定の借方・貸方を一覧にし、合計が釣り合うかを見る表です。

なぜ必要？

会計全体の算術的な不均衡を早く見つけるためです。

Minibankでは

Accounting Consoleで勘定別debit、credit、balanceと全体の一致を表示します。

08

内部Ledgerと実銀行会計

やさしく言うと

学習用の資金台帳と、銀行全体を外部報告する法定会計は範囲が違います。

なぜ必要？

借貸一致を、実銀行の財務諸表や銀行間決済まで完成した証拠と誤解しないためです。

Minibankでは

会計consoleとpooled accountはありますが、外部清算、中央銀行勘定、規制報告は再現していません。

発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。

実装済みのAccounting Rule Registry

Minibankの正本は `accounting.rule_definitions` と `accounting.rule_lines` です。各ruleは、rule familyを識別する `rule_code`、正の整数の `version`、`DRAFT / ACTIVE / INACTIVE` のstatus、適用期間を持ちます。DRAFTは編集できますが、一度ACTIVEになった版は説明文を含めて変更・削除できません。

`accounting.activate_rule()` はDRAFT版をACTIVEにすると同時に、同じ取引種別の旧ACTIVE版を同一transaction内でINACTIVEへ移し、適用終了時刻を固定します。v1.2.0では将来日予約や単独deactivateはなく、『新しい版を今activateする』ことだけが正式な状態遷移です。Registryは記帳engineそのものではなく、既存業務RPCが作る仕訳と、投稿時に有効だったrule版を結ぶ正本・追跡基盤です。

  • `rule_code + version` は一意で、同一取引種別のopenなACTIVE版は最大1件
  • 固定明細ruleはactivate前に2行以上、reversalのdynamic_mirror ruleは0行を要求
  • 新規Journal Entryは投稿時にruleを解決できなければfail-closedで記帳しない
  • `journal_entries.accounting_rule_definition_id` が投稿時の版へ固定され、後日の新version有効化では変わらない
  • 管理画面 `/admin/accounting/rules` は全version・全statusをRead-onlyで表示し、変更操作は公開しない
取引種別借方貸方経済的な意味
transfer送金元の顧客預金負債送金先の顧客預金負債預金返還義務の相手を移す
depositSYSTEM_FUNDING顧客預金負債顧客への返還義務を増やす
withdrawal顧客預金負債SYSTEM_FUNDING顧客への返還義務を減らす
fee顧客預金負債FEE_REVENUE預金元本と手数料収益を分ける
time_deposit_open顧客預金負債TIME_DEPOSITS_PAYABLE普通預金負債を定期預金負債へ移す
time_deposit_cancelTIME_DEPOSITS_PAYABLE顧客預金負債定期預金負債を普通預金へ戻す
time_deposit_maturityTIME_DEPOSITS_PAYABLEとINTEREST_EXPENSE顧客預金負債元本と利息を満期入金する

Transaction Storyは、画面の物語ではなく証拠の鎖

管理画面のJournal ExplainとTime Deposit Transaction Storyは、別々のtable名を見せるだけではなく、業務上の出来事からrule、仕訳、明細、監査までを関連づけます。障害や問い合わせの時に『残高はいくらか』だけでなく『なぜそうなったか』へ答えるための画面です。

  1. 01Business Transaction：利用者が定期預金を作成・解約・満期処理
  2. 02Accounting Rule：取引種別に対応する期待仕訳
  3. 03Journal Entry：取引1件の会計header
  4. 04Journal Lines：借方と貸方の勘定・金額
  5. 05Subledger：time_deposits契約の状態・元本・利息
  6. 06Reconciliation / Integrity：別記録の一致と不変条件を検査
  7. 07Audit：actor・時刻・対象を追跡

Minibank内部Ledgerと、実銀行会計の境界

区分Minibankで確認できることこの教材の対象外
記帳資産・負債・収益・費用、借貸一致、append-only、reversal銀行全体の完全な勘定科目体系
GL / Subledgerpooled accountと顧客・契約別明細、accounting console法定総勘定元帳と連結会計
検査Trial Balance、Reconciliation、Integrity、Audit規制当局向け報告と外部監査手続一式
決済同一Minibank内の資金移動他行clearing、中央銀行当座預金、外部settlement
財務報告学習用の会計説明と残高集計貸借対照表・損益計算書・税務の完全実装

体験学習の続き · LEARNING LOOP

ここまで読めましたか？続けて確認してみましょう

資産・負債・内部振込の仕訳を読んだところで、実際の管理画面で会計記録を確認し、自分の言葉で説明してみます。

STEP 2〜5 / 5
  1. 02
    実際に観察する — OBSERVE

    同じ仕組みを、動く画面から観察する

    この仕組みは管理者向けの画面で確認できます。管理者ログインがない場合は、この教材内の図・説明・Source Trail（教材の参照元）で代替学習し、次へ進めます。

    管理者ログインがない場合：教材の参照元で確認する ↓
    管理者の画面 · MINIBANKAccounting Dashboard ↗

    勘定残高・直近仕訳・会計全体の入口を観察します。管理者ログインが必要です。

  2. 03
    証拠を確認する — EVIDENCE

    何を見たか、1つずつ確かめる

    Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。

    画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。

  3. 04
    コードの処理経路を追う — CODE TRAIL

    コードを書く必要はありません

    ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。

    まず仕訳の説明UIを見て、次にTrial Balance画面の実装を見ます。顧客視点と帳簿視点がどう対応するかを確かめましょう。

    業務取引からauditまでの説明UI。

    src/components/admin/JournalExplainPanel.tsx

    借方・貸方・残高を一覧化するTrial Balance画面。

    src/app/admin/(protected)/accounting/trial-balance/page.tsx
    教材の参照元を確認する — Source Trail ↓
  4. 05
    自分の言葉で説明する — EXPLAIN

    LEVEL 1 — やさしい説明（まずここだけ）

    なぜ顧客にとっての『資産』が、銀行の帳簿では『負債』として記録されるのでしょうか？ 短い2文を目安に説明してください。

    日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。

    ヒント1を見る

    「資産」と「負債」という2つの言葉を使って書いてみましょう。

    ヒント2を見る

    振込で銀行全体の預金総額が変わるかどうかも考えてみましょう。

    もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）

    資産、負債、GLとSubledgerの3つを使って、顧客の預金がどう会計記録として表現されるか説明してみましょう。

    挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。

    説明の確認ポイント — Checkpoint
    • 顧客視点と銀行帳簿視点が逆になると説明できる
    • 振込が負債の内部振替であり全体の預金総額を変えないと説明できる
予想5文字以上・証拠2項目・説明20文字以上で完了できます。

証拠の確認：0 / 2。LEVEL 2（専門用語での説明）は任意です。

入力はこのブラウザに保存されます。Academy教材の進捗とは別の学習メモです。

理解を確かめる — CHECK YOUR UNDERSTANDING

6問で理解チェック

答えを頭の中で考えてから、各項目を開いて確認してください。

Q1顧客の預金が銀行には負債なのはなぜですか？
答え

銀行には顧客の求めに応じて返す義務があるからです。視点が顧客側と逆になります。

Q2内部振込で銀行全体の顧客預金総額は増えますか？
答え

増えません。返す相手が送金元から送金先へ移るだけです。

Q3手数料と預金元本を同じ収益にできますか？
答え

できません。預金は返還義務、手数料は収益で、会計上の性質が違います。

Q4定期預金のGL残高は何で説明しますか？
答え

time_depositsにある契約別元本、つまりSubledgerの合計で説明し、一致を照合します。

Q5Trial Balanceが一致すれば、すべて正しいですか？
答え

いいえ。左右同額を誤った勘定や顧客へ記帳しても一致するため、Reconciliation、Integrity、Auditも必要です。

Q6Minibankの借貸が一致すれば、実銀行の財務会計も完成ですか？
答え

いいえ。Minibank内部Ledgerの整合性を示すもので、外部清算、中央銀行勘定、法定財務報告は別の範囲です。

ここまで読めましたか？

完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。

教材の参照元 — SOURCE TRAIL

根拠と関連教材

CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。

確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。

  • 現在の実装 — CURRENT IMPLEMENTATION — Primary Sourcesupabase/migrations/20260930110000_v15_pricing.sqlpublic.mature_time_deposit定期満期の最新定義。v15以降の契約は契約時の価格（版）の金利を使い、JST暦日数で単利・税引前・floorの利息を計算する。v15より前の契約は従来の式のまま。
  • 現在の実装 — CURRENT IMPLEMENTATIONsupabase/migrations/20260930110000_v15_pricing.sqlpricing.run_ordinary_interest / pricing.simple_interest普通預金の利息（管理責任者が期間ごとに実行）。日次の終値残高×その日に有効な金利を合計して1回だけ切り捨てる。
  • 現在の実装 — CURRENT IMPLEMENTATIONsupabase/migrations/20260930100000_v14_lending.sqllending.accrue_locked / lending.repay貸出利息（v14）。日割で計上し、返済のたびに未収利息から充当する。
  • 過去の実装 — HISTORICAL IMPLEMENTATIONsupabase/migrations/20260920115556_scalar_journal_posting_atomic_cache.sqlv15の直前の定期満期の定義。計算式は v15 より前の契約で現在も使われる。
  • 過去の実装 — HISTORICAL IMPLEMENTATIONsupabase/migrations/20260907113002_serialize_account_products.sql口座→商品の順のlockを導入した前々回の定義。
  • 過去の実装 — HISTORICAL IMPLEMENTATIONsupabase/migrations/20260824170001_time_deposit_maturity.sql満期利息の導入履歴。関数本体は後続migrationで再定義。
  • 過去の実装 — HISTORICAL IMPLEMENTATIONsupabase/migrations/20260828210001_accounting_rule_registry_schema.sqlaccounting.activate_rule()version・status・不変性を持つ正本Registry
  • 過去の実装 — HISTORICAL IMPLEMENTATIONsupabase/migrations/20260828210004_journal_rule_trace_column.sqlJournal Entryから投稿時rule版への固定参照
  • 過去の実装 — HISTORICAL IMPLEMENTATIONsupabase/migrations/20260828210005_connect_journal_rule_trace.sqlledger.post_journal_entry()投稿時rule解決とfail-closed
  • 現在の実装 — CURRENT IMPLEMENTATIONsrc/app/admin/(protected)/accounting/rules/page.tsx全versionを表示するRead-only管理画面
  • 過去の実装 — HISTORICAL IMPLEMENTATIONsupabase/migrations/20260824130001_create_time_deposits.sqlTIME_DEPOSITS_PAYABLEと契約別Subledger
  • 過去の実装 — HISTORICAL IMPLEMENTATIONsupabase/migrations/20260824170001_time_deposit_maturity.sqlINTEREST_EXPENSEと満期仕訳
  • 現在の実装 — CURRENT IMPLEMENTATIONsrc/app/admin/(protected)/accounting/page.tsxAccounting Dashboard
  • 現在の実装 — CURRENT IMPLEMENTATIONsrc/components/admin/JournalExplainPanel.tsx業務取引からauditまでの説明UI
  • 現在の実装 — CURRENT IMPLEMENTATIONsrc/services/AdminAccountingService.tsTrial Balance、Reconciliation、Transaction Story取得
  • 現在の実装 — CURRENT IMPLEMENTATIONscripts/regression/suites/accountingConsole.mjsrule registryと会計説明機能の回帰検証