MiniBankは何を作ったのか
口座の画面から銀行全体の会計、そして予測の模型まで。v1〜v20を「守るべき記録が増えた物語」として読む。
本文の説明・図・掲載コードだけで読み進められます。出典リンクは、権限のある人向け（非公開GitHub）です。GitHubで閲覧権限がある方だけ開けます。
この記事でわかること
- 顧客の画面、金融の記録、銀行の運用は別の仕事としてつながる
- 新しい機能も元帳を土台にし、実績と試算を混ぜない
- ソースに機能があることと、公開環境で使えることを区別する
この記事の目次
小さな銀行を通して、大きなシステムの責任を知る
MiniBankは、架空のお金を扱う銀行システムの学習用実装です。口座番号や残高が見えるだけなら、表計算でも似た画面を作れます。しかし銀行らしい難しさは、その数字を誰が、どんな理由で変え、失敗したときに何が残るかにあります。送金ボタンを二度押したらどうなるか。処理の途中で通信が切れたら、もう一度押してよいか。後から金額の誤りが見つかったら、過去を消してよいか。MiniBankの作り方は、こうした問いを順番に引き受ける過程です。
初期の要件は、顧客情報、簡略化した本人確認、円の口座、行内振込、取引明細、複式簿記の元帳、監査の記録などでした。この時点から「金額は整数の円」「貸方と借方の合計を一致させる」「公開された利用者が残高を直接書き換えない」という土台が置かれています。後の版で融資や利息が加わっても、この土台を捨てて別の残高を作るわけではありません。
固定したソース版を読む教材です。実在の銀行口座、決済網、現金、本人確認会社につながるサービスではありません。例の人物・金額は、仕組みを説明するための架空の設定です。
同じ一万円を、三つの立場から見る
架空の山田さんが一万円を預けたとします。顧客の画面では「自分の残高が一万円増えた」が答えです。銀行の帳簿では「現金という資産が増え、お客さまへ返す義務である預金も増えた」と記録します。運用担当者は「処理が一回だけ計上され、口座の表示残高と元帳が一致しているか」を見ます。同じ出来事でも、知りたいことが違うのです。
この三つを一枚の表へ押し込めると、画面の都合で会計の証拠を消したり、調査中の案件を完了扱いにしたりしやすくなります。そこでMiniBankは、顧客向けの口座、会計用の勘定、処理や調査の記録を分けて、識別子で結びます。v10の銀行会計は既存の仕訳を集計し、v12の運用センターは各機能の記録を読んで対応待ちを作ります。「同じ事実を、目的に合う形で見る」のが全体を理解する近道です。
v1〜v7：取引の成功と、その後の説明責任を作る
v1から始まる初期の学習範囲では、ログイン、顧客、口座、入出金や振込、明細、元帳を一つの筋道で理解します。ここで大切なのは、振込画面を完成させることだけではありません。送り手だけを減らして受け手を増やせなかった状態を残さないこと、同じ依頼の再送で二重計上しないこと、誰が操作したかをたどれることまでが取引の一部になります。
さらに法人支払では、申請する人と承認する人を分ける必要が出ます。v4では別の承認者による確認や、権限変更後の再確認が強化されました。v5では指定日を承認対象の支払内容に含めます。ただし当時の指定日支払は、期日が来ると勝手に送金する仕組みではなく、指定日以降に実行する学習用の設計です。v6では、その支払を調査・解消したと言える根拠を厳しく確かめています。
v7になると、通信が途切れた後の結果照会、営業日の開始と終了、照合、復旧へと関心が広がります。「成功する一回」から「結果が見えなくても安全に扱える一回」への進化です。この読み物で初期の単純な振込を説明するときも、それだけで現在の画面全体を説明したことにはしません。後から追加された申請や認証、結果照会の段階があるからです。
v8〜v13：口座の集まりから、銀行全体の運営へ
v8は「業務上の出来事を、決められたルールで仕訳へ変える」共通の計上機構を加えます。たとえば預金利息を支払うという出来事から、利息費用と顧客預金の行を作る仕組みです。ただし、それ以前の振込や入出金をすべて新しい事象の表へ移し替えたわけではありません。古い経路も同じ元帳の基盤を使いながら、自分の業務記録を保っています。
v9では他行送金のシミュレーターが入り、依頼の受付と決済の完了が別になります。v10は個別の預金勘定をまとめて、試算表や銀行の貸借対照表を作ります。v11は元帳を読んで不自然な動きを検知するAMLの模型です。警告が出ることと、不正を断定することは分かれており、検知だけで口座凍結や取消しはしません。
v12の運用センターは、結果不明の送金、照合差異、調査や承認待ちを見渡す場所です。v13は資金を調達・運用するTreasuryと、資産と負債の期間や金利を考えるALMへ進みます。ここでも市場データは架空の前提です。機能が増えるほど重要になるのは、「どこで正式に計上するのか」「どこは読むだけなのか」を見失わないことです。
根拠：v8の追加層と既存経路の維持（非公開GitHub・要権限）
根拠：v9の架空決済シミュレーター（非公開GitHub・要権限）
v14〜v20：商品、復旧、リスク、予測をつなぐ
後半では、v14の融資、v15の預金価格、v16のOpen Banking検証環境、v17の復旧、v18のリスク、v19の複数法人・連結、v20のBank Digital Twinへ広がります。この順序は、機能名を覚えるための年表ではありません。商品が増えると守るべき契約が増え、外部の入口が増えると権限の境界が増え、銀行が複数になると単体とグループの数字を分ける必要が出る、という依存関係です。
Digital Twinは「政策金利が変わったら、預金価格や資金需要はどうつながるか」をたどる模型です。実績をある時点で写し取り、架空の仮定とシナリオを与えて計算します。たとえば預金流出を仮定した結果に資金不足が出ても、その計算だけで顧客の残高が減ったり、正式な借入が作られたりはしません。実績と予測を分けること自体が仕様です。
ここで「予測」という語は将来の保証を意味しません。前提が単純なら結果もその単純化を引き継ぎます。設定された式や入力をたどれることは、現実への適合が証明されたこととは別です。後半の章では、この違いを守りながら、初期の元帳がどう高度な説明の土台になったかを見ます。
コードは「何を引き受けたか」から読む
英語のファイル名を最初から暗記する必要はありません。「この関数は何を受け取り、何を決めず、どこへ渡すか」を読むと役割が見えます。たとえば口座サービスの次の部分は、口座開設をデータベース側の処理へ依頼しています。RPCは、離れた場所にある決まった処理を呼び出す窓口、と考えてください。
const { data, error } = await client.rpc("create_bank_account", {
p_account_type: input.account_type ?? "ordinary",
p_currency: input.currency ?? "JPY",
});この数行は口座番号を自分で発行せず、残高も自分で書きません。省略された入力を普通預金・円として渡し、データベースが返した結果やエラーを受け取ります。短いから未完成なのではなく、この場所に決定権を重複させない設計です。次の章では、ボタンからこの窓口までを一本につなげます。
なお、本編が根拠とするのはコミット0376302の固定ソースです。掲載された検証記録は、その記録の対象環境と時点についての証拠であり、この教材が実行し直した結果ではありません。2026年10月3日の修復記録も、正式なProduction適用・公開は後続ゲートで判定すると明記しています。古い資料の「将来予定」や「完了」を、そのまま現在の全体状態へ広げない読み方が必要です。
出典と、確認できた範囲
以下のリンクは非公開GitHubへの出典で、閲覧権限が必要です。本文はリンク先を開かなくても読める構成です。固定コード・設計資料を参照していますが、今回、この読み物のために銀行の取引やDB操作、本番試験は実行していません。実装や資料にある検査と、こちらで実施した検証を混同しないようにしています。
- 初期要件 ↗（非公開GitHub・要権限）
v1側の目的と基本的な金融原則 - 口座サービス ↗（非公開GitHub・要権限）
DBへの依頼を薄く保つ実装 - v8計上機構 ↗（非公開GitHub・要権限）
既存基盤へ追加し、旧取引経路は維持 - v10銀行会計 ↗（非公開GitHub・要権限）
既存元帳から銀行全体を集計 - 後半の機能一覧 ↗（非公開GitHub・要権限）
各版の扱う領域。検証判定は後続資料に更新あり - 予測模型の契約 ↗（非公開GitHub・要権限）
実績と試算の分離、範囲と限界 - 最新修復記録 ↗（非公開GitHub・要権限）
隔離検証と正式公開の区別
MiniBankは学習・検証用の銀行アプリです。架空の金額や人物は、仕組みを説明するための例です。
つながる読み物
ここまで読んだ記録を、ひとつ。
自分のペースで。あとから取り消すこともできます。