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

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

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

顧客と銀行口座

ログインユーザーが顧客となり、KYCを経て口座と台帳勘定を持つまでを追います。

04 / 07
BANKING · 銀行業務

銀行ビジネスと主要商品を、利用者・銀行・会計の視点から理解する。

先に学ぶ内容 — Prerequisite: 基礎

学ぶこと — LEARNING GOALS

このページで学ぶこと

  • Auth UserとCustomerの違い
  • 口座開設の前提条件
  • Bank AccountとLedger Accountの1対1関係

体験03 · ACCOUNTS（口座とデータモデル）

口座番号と、会計の勘定を見比べよう

まずは予想をひと言。本文を読んだ後、実際の画面と管理者側の記録を見比べます。

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

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

    新しく口座を開いたら、画面に出る残高の数字はどこから来ると思いますか？

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

    ヒント1を見る

    ログインする人と、銀行と契約する顧客は、同じ1つの記録でしょうか？

    ヒント2を見る

    画面の残高は、どの記録をもとに計算されているでしょう？

    もっと詳しく：この問いで使う専門用語
    • Auth User（ログインする本人）は、認証だけを担当する記録です。
    • Customer（顧客）は、銀行と契約する本人確認済みの利用者です。
    • Bank Account（銀行口座）は、顧客が持つ普通預金の契約です。
    • Ledger Account（台帳勘定）は、会計上の増減を記録する内部の勘定です。
まずはひと言だけで大丈夫です。

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

日常語で理解する — PLAIN LANGUAGE

まず、ここだけつかむ

1

ログインできる人、銀行と契約する顧客、お金を置く銀行口座、会計に記録する台帳口座は、それぞれ別の役割です。

2

Minibankでは認証ユーザーと顧客を結び、本人確認が完了した顧客だけが銀行口座を持てる流れを作っています。

3

cached_balanceは素早い表示のための控えであり、壊れたときは台帳から検証・再構築できることが重要です。

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

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

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

01

Auth UserとCustomer

やさしく言うと

Auth Userはログイン主体、Customerは銀行業務上の顧客です。

なぜ必要？

ログイン方法の情報と、KYCや顧客状態を切り離すと責任と権限を整理できます。

Minibankでは

customers.idをauth.usersのIDと対応させ、RLSではauth.uid()を起点に本人の行を判定します。

02

Bank AccountとLedger Account

やさしく言うと

前者は顧客に見せる口座、後者は複式記帳に使う内部の勘定口座です。

なぜ必要？

商品・契約の状態と、会計の増減ルールは別の関心事だからです。

Minibankでは

bank_accountsとledger.accountsを対応付け、取引時には両方の整合を確認します。

03

外部キーと一意制約

やさしく言うと

存在しない相手を参照しない、同じ関係を重複させないためのDBの規則です。

なぜ必要？

アプリの確認をすり抜けても、孤立データや二重口座をDBで止められます。

Minibankでは

顧客との関連や顧客1人1口座などをDB制約で表します。

04

残高cache

やさしく言うと

毎回全履歴を合計せず、すぐ表示できるよう保存した現在値です。

なぜ必要？

高速ですが、台帳と同時に更新しなければ食い違います。

Minibankでは

cached_balanceを台帳更新と同じtransactionで変更し、照合対象にします。

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

作成の順序

  1. 01Supabase Auth User
  2. 02Customer profile
  3. 03KYC: verified
  4. 04Bank Account
  5. 05Customer Deposit Liability ledger account

DBが守る関係

  • customers.auth_user_idはuniqueで、Auth User 1人につき顧客1件
  • bank_accounts.customer_idはunique制約が追加され、MVPでは顧客1人1口座
  • ledger_accounts.bank_account_idはuniqueで、口座1件に顧客預金勘定1件
  • auth.usersの削除はON DELETE RESTRICTで履歴の連鎖削除を防止
  • 口座番号は7桁文字列として生成され、先頭ゼロを保持

実際のMinibankでは

`create_bank_account()` は `auth.uid()` から顧客を解決し、KYCが `verified` であることを確認します。口座と `Customer Deposit Liability` 勘定は同じ関数・同じtransactionで作られるため、後半が失敗すれば口座作成もrollbackされます。

1 customer → 1 bank_account → 1 liability ledger_account

体験学習の続き · LEARNING LOOP

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

口座の作られ方を読んだところで、実際の画面と管理者側の記録を見比べ、自分の言葉で説明してみます。

STEP 2〜5 / 5
  1. 02
    実際に操作する — OPERATE

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

    まず顧客画面を開いて観察し、この教材へ戻ります。リンクは新しいタブで開きます。ログインが必要です。

    アカウントがない場合は新規登録が必要です。本人確認・口座開設には管理者承認が必要です。承認前や操作できない場合も、この教材内の図・説明・Source Trail（教材の参照元）で代替学習し、次へ進めます。

    ログイン・新規登録の入口を開く ↗操作できない場合：教材の参照元で確認する ↓
    利用者の画面 · MINIBANK顧客ダッシュボード ↗

    ログインした後、自分の名前と口座の入口が表示されるか見てみましょう。

    利用者の画面 · MINIBANK口座情報 ↗

    口座番号と残高がどのように表示されるか観察します。

    もっと詳しく：管理者の画面で観察する

    管理者ログインが必要です。権限がない場合は、次の「証拠を確認する」の教材による確認で進められます。

    Accounting Console（会計を確認する画面） ↗

    同じ口座に対応する会計上の勘定（Ledger Account）を見ます。

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

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

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

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

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

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

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

    基本の順序は、画面 → API Route（依頼を受ける窓口）→ TransferService（処理をつなぐサービス）→ DB / RPC（記録の保存場所と、その処理の呼び出し）です。まず最初の2つを見て、続くサービスは「もっと詳しく」で確認します。

    口座開設RPCを呼び出すサービス。顧客と口座をどう結びつけるかを探します。

    src/services/AccountService.ts

    Migration（DB定義の変更履歴）。口座と会計上の勘定を同時に作る定義を確認します。

    supabase/migrations/20260819155226_extend_create_bank_account_with_ledger_account.sql
    教材の参照元を確認する — Source Trail ↓
  4. 05
    自分の言葉で説明する — EXPLAIN

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

    なぜ口座（Bank Account）と、会計の勘定（Ledger Account）を別々に作るのでしょうか？ 短い2文を目安に説明してください。

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

    ヒント1を見る

    「口座」と「会計の勘定」という2つの言葉を使って書いてみましょう。

    ヒント2を見る

    もし片方だけを作って、もう片方を作らなかったら何が困るか考えてみましょう。

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

    Auth User、Customer、Bank Account、Ledger Accountの4つの役割を結び付けて説明してみましょう。

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

    説明の確認ポイント — Checkpoint
    • 口座と会計上の勘定が別の記録であると説明できる
    • 画面の残高が再計算可能な値であると説明できる
予想5文字以上・証拠3項目・説明20文字以上で完了できます。

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

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

理解を確かめる — CHECK YOUR UNDERSTANDING

3問で理解チェック

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

Q1ログインユーザーと銀行口座を直接同じ表にしない理由は？
答え

認証、顧客契約、口座、会計で責務とライフサイクルが異なるためです。

Q2cached_balanceだけを正式な記録にしない理由は？
答え

現在値だけでは増減の根拠がなく、破損時に検証・再計算できないからです。

Q3KYC未完了の利用者は口座を作れるべきですか？
答え

Minibankの設計上は作れません。口座作成時にもDB側でKYC状態を確認する必要があります。

ここまで読めましたか？

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

教材の参照元 — SOURCE TRAIL

根拠と関連教材

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

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

  • 現在の実装 — CURRENT IMPLEMENTATIONsrc/services/CustomerService.tscreateCustomer()顧客プロフィール作成
  • 現在の実装 — CURRENT IMPLEMENTATIONsrc/services/AccountService.tscreateAccount()口座開設RPCの呼び出し
  • 過去の実装 — HISTORICAL IMPLEMENTATIONsupabase/migrations/20260819155226_extend_create_bank_account_with_ledger_account.sqlcreate_bank_account()口座と台帳勘定の原子的作成
  • 現在の実装 — CURRENT IMPLEMENTATIONscripts/regression/suites/account.mjs口座開設のDB回帰テスト