MiniBankv20CORE BANKING / ACCOUNTING / SECURITY / OPERATIONS
画面個人口座、法人口座、振込、権限管理、MFA。
裏側元帳・会計・日次運用から、融資、預金価格、リスク、グループ連結、将来の試算まで。
送金、融資、元帳、権限、リスク管理、復旧まで。
MiniBank v20は、銀行システムの表側と裏側を、
つくりながら理解するための学習・検証環境です。
Finance × Engineering × AI Development経理・財務の視点から、AIとともに銀行システムを20世代にわたって拡張してきた。
WHAT MINIBANK DOES10 operations
見えるのは銀行画面。つくったのは、
MiniBankは学習・研究・検証用のシミュレーションです。実際の預金を受け入れたり、実資金を送金したりする銀行サービスではありません。実在する個人情報・口座情報・機密情報を入力しないでください。
MiniBank System Overview
利用者が見る画面から、その裏側にある認証、権限、取引制御、台帳、仕訳、銀行間決済、会計、AML、日次運用、障害対応、資金管理まで。
さらに、それらを読み解くArchitectureとAcademyまで。
以下の規模・教材数・試験数はv13時点の記録です。既存機能を土台として保持し、その下にv14〜v20の進化を増補しています。最新の教材数・試験数とは区別してください。
CHANNEL
BANK CORE
OPERATE
UNDERSTAND
PERSONAL BANKINGv1–v2個人向け銀行利用者登録・ログイン本人確認申請・KYC審査口座開設・凍結・解除・利用停止普通預金・入出金履歴振込先登録・振込MFA / TOTP定期預金章 01–03 CORPORATE BANKINGv3–v5法人向け銀行法人口座・法人メンバーRole / PermissionMaker / Checker指定日支払重要設定変更の二者確認法人全体の日次上限章 04–07 LEDGER / POSTINGv8台帳・記帳基盤Business EventPosting RuleJournal EntryLedger逆仕訳Integrity Check章 10–11 / 17–18 INTERBANK PAYMENTv9銀行間決済Participant BankClearingSettlement中央銀行預け金RESULT_UNKNOWN の照会章 19–21 BANK ACCOUNTINGv10銀行会計・決算General LedgerTrial BalanceBalance SheetProfit & Loss補助元帳照合日次・月次締め章 22–24 AMLv11不正・AMLScanAlertCaseInvestigationEvidenceDecision章 25–26 OPERATIONS CENTERv6–v7 / v12日次運用・障害対応論理営業日・EOD / BODReconciliation調査案件・復旧Backup / RestoreSystem StatusException / Approval QueueTrace・Incident・Runbook章 12–16 / 27–29 TREASURY / ALMv13資金繰り・ALM預金流出シナリオ必要調達額・調達コストInterest Rate ShockNIIWhat-ifGL → ALM → Posting章 30–34 ARCHITECTURE構造と責任分界Customer / Corporate / Admin UINext.js / TypeScriptPostgREST / Business RPCPostgreSQL Business LogicJava / Spring Boot Payment Service章 38–40 MINIBANK ACADEMY学習コンテンツ9 Courses107 LessonsBank Engineering 29 Lessons6 Labs章 41–46 TRANSACTION INTEGRITYIdempotencyConcurrencyRESULT_UNKNOWNReversalIntegrity Check全領域を横断SECURITY & CONTROL認証認可RLSDatabase PrivilegeRPCFail ClosedMFAMaker / Checker監査記録全領域を横断PART ADDENDUMv13 → v20
一件の取引を正しく残す。その土台を保ちながら、商品、連携、復旧、リスク、グループ、試算へと広がりました。
第1〜52章は、MiniBankをv13まで作り上げたストーリーです。口座と振込、法人の承認、台帳とGL、日次締め、AML、運用、Treasury / ALM。これらは新しい版でも土台として残ります。
v14〜v20の増補は、その土台に何をつないだのかを説明します。融資の元本は銀行の資産になり、預金の価格は調達費用になる。両者をリスクの入力へ、さらに銀行全体の試算へつなげると、一件の取引とは違う時間軸が見えてきます。
申込から審査・実行・返済・延滞・照合まで。預金とは反対側から銀行の資産を見る。
金利や手数料を版で管理し、見積りと契約時の条件を区別する。
利用者の同意、認可、トークン、APIと通知を、閉じた検証環境でつなぐ。
止める、復元対象を宣言する、照合する、別の人が再開を判断する。
信用・市場・流動性・オペレーショナルを、同じ入力と明示した式で比較する。
法人別の元帳を守り、相互勘定を照合してから、報告上の連結を作る。
凍結した実績と架空の仮定から、銀行全体の変化を理由とともにたどる。
ここは学習・研究用のシミュレーションです。追加機能の説明は固定したv20基準コードと関連仕様に基づきます。コードの存在、隔離環境の試験記録、本番での確認は別の根拠として扱います。
PART DESIGNMiniBank v20 / Architecture
MiniBankは、画面や機能だけでなく、取引、権限、元帳、デプロイ、障害復旧までを一つのシステムとして設計しています。
融資・預金価格から、連携・復旧・リスク・グループ・Digital Twinへ。v14〜v20で広がる領域を、6つの視点から見渡します。
これらは責任の分け方や確認の考え方を読む設計図です。機能のコード実装、DBの定義・履歴、公開環境での業務検証は、それぞれ別の根拠として示しています。各図の下で、確認した範囲と設計上の目標を分けて説明します。
System Context
この図の読み方Next.js・TypeScript・Supabase/PostgreSQLクライアントは固定コードの依存関係で確認しています。箱はそれぞれが独立したサービスであることを意味しません。本体の公開deploymentはVercel、公開クライアントの接続先はSupabaseと確認しています。Storageの業務利用までは確認していません。監視・ログ・復旧の役割は運用設計です。常時通知、定期バックアップ、事業継続の稼働実績を保証するものではありません。固定基準コードにあるmigrationファイルを数えると150本です。接続先DBのmigration履歴も150件で、固定150本との版番号・名称が一致しました。SQL内容の完全同一性や全業務の成功実証とは別です。
Runtime / Transaction Flow
この図の読み方TOTP/MFA、session・role・scope確認、対象操作のauditはコード上の制御です。OperatorとManagerの現在のProductionでの権限差や拒否試験は未実証です。管理画面やAMLのAlert/Caseは、状態を確認・分析する仕組みです。全取引の事前AML、常時リアルタイム通知、自動の外部alertを意味しません。
Security & Trust Boundary
この図の読み方本体公開URLで、証明書を検証したHTTPS/TLS 1.2接続を確認しました。全endpointの最低TLS政策や旧versionの無効化を確認した値ではありません。Vercelの標準DDoS対策と、個別のWAF・rate limit設定は別です。有効な個別設定は未確認で、銀行システム全体の保護を実証したという意味ではありません。Session/Auth、TOTP、入力検証のコードと、監査対象の業務tableでRLSが有効なことを確認しています。特権bypassを含む全roleの本番拒否試験までは実施していません。保存時暗号化はHosted Supabaseの提供仕様の範囲で説明しています。手動export、アプリの秘密情報、別のbackup保管まで保護済みとするものではありません。アプリ内の記録と、外部ログ集約・通知・保存期間の設定は別です。後者は設計・検証対象として残しています。確認したCIはtypecheck・lint・buildです。依存関係の脆弱性検査、PreviewとProductionの完全な環境分離、Incident対応の常時運用は未実証です。図のOperator/Manager Production E2Eは追加検証事項です。LPの画面確認や本体のbuild成功で代用しません。
Data / Ledger Architecture
この図の読み方150 migration filesは、固定基準コードのファイル数です。DB履歴150件との版番号・名称一致を確認しました。「未適用0」は固定150版に対する履歴差分で、将来のmigrationやSQL内容の完全一致を含みません。接続先DBのmetadataでPostgreSQL engine 17を確認しています。最新minorへの更新や脆弱性0の証明ではありません。25はpublicと空のcoreを含む業務schemaの集合、122はその通常table数です。provider管理領域・view・partitioned tableは業務table数に含めません。対象122 tableのRLS有効とFK・制約・indexの存在を確認しましたが、全データの整合や全roleの安全性保証とは別です。
Deployment & Reliability
この図の読み方Vercelの公開配信と、接続先DBのap-northeast-1配置を確認しています。CDN配信を銀行全体の多地域DB、HA、自動拡張の実証と読み替えません。Health/smoke/integrityの確認項目と、その常時・自動実行は別です。現在のProductionでの起動条件や失敗時の停止連携は未確認です。未適用0は、監査時点の固定150版とDB履歴の一致を表します。全機能のrelease gate完了を示すものではありません。Metrics・traces・logsの観測は運用設計です。外部収集、dashboard、長期保持が有効な設定・契約として確認されたわけではありません。
Failure / Recovery Architecture
この図の読み方書込停止・世代・復元宣言・検証・再開制御はコード上の仕組みです。すべてのbatch/queue制御やDB snapshot保全が現在のProductionで実施済みとは確認していません。アプリ設定・IaC・秘密情報・Object Storageは保管対象の設計例です。実保管、versioning、長期保持、定期復元の実証ではありません。DB backupがStorage objectも含むと解釈しないでください。
送金ボタンを押した。
画面に「成功」と表示された。
それだけで、本当に銀行システムは完成なのでしょうか。
MiniBankが作ってきたのは、
こうした「画面の先にある問題」を扱う仕組みです。
PART ICustomer Banking
MiniBankには、利用者として銀行を体験するための機能があります。
しかし、残高を表示するだけの銀行デモではありません。
利用者が行った操作が、その後の取引記録や台帳までつながることを重視しています。
は、それぞれ別の条件です。
画面を開けたからといって、金融取引まで許可されるわけではありません。
利用者に見える残高と、その裏側の銀行の記録をつなげます。
ここでも「送る」だけでは終わりません。
金融更新の前に確認すること
これらを確認してから金融更新へ進みます。
MiniBankでは、振込認可にTOTPを利用したMFAフローを組み込んでいます。
単に入力欄に6桁の数字を入れているだけではありません。
認証と金融取引を分けて考える。
その考え方まで含めて実装しています。
実在銀行の本人認証方式を完全に再現するものではありません。
MiniBankでは定期預金も扱います。
「定期預金残高」という数字を画面へ表示するだけではありません。
普通預金から定期預金へ資金が移れば、銀行の内部記録も変わる。
満期になれば元本と利息が動く。
利用者の商品状態と、銀行側の会計をつなげます。
利息計算は学習用の簡略化されたモデルです。
PART IICorporate Banking
個人向け銀行機能に会社名を付けただけではありません。
法人では、「会社」と「操作する人」を分けます。
口座の所有者は法人。
操作するのは、それぞれのユーザーIDを持った担当者です。
法人ユーザーの役割は、実装上4つです。
役割によって操作できる機能を分けます。
同じ法人に所属しているからといって、全員が同じ操作をできるわけではありません。
BANK SIDE — 法人Roleとは別
銀行側の担当者は、法人のRoleとは別に、銀行の管理者Role（オペレーター／管理責任者）として扱います。
法人支払では、申請・承認・実行を分離します。
銀行システムだけでなく、
企業内部統制の考え方
まで扱っています。
指定日付きの支払依頼も扱います。
申請日。指定日。実行日。この3つを分けます。
指定日前なら実行を拒否する。
指定日を過ぎてから実行したなら、実際に実行された日を記録する。
そして、指定日になったからといって無条件に送金するわけではありません。
実行時にも、
などを確認します。
自動振込サービスではなく、学習用の指定日支払フローです。
MiniBankでは、支払いだけでなく、
こうした操作にも二者確認の考え方を入れています。
法人全体の日次上限も、口座や担当者を分けるだけで簡単に回避できないように扱います。
PART IIITransaction Integrity
Idempotency・Concurrency・RESULT_UNKNOWN・逆仕訳・Ledger。
金融システムでは、
「ボタンを二回押した」
「通信が切れて再送した」
だけで二重送金になってはいけません。
MiniBankでは、依頼を識別するキーを使います。
同じ依頼が再び届いたとき、
二つの処理が同じ古い残高を読み、
それぞれが勝手に引き落としたら、
残高は壊れます。
そのためMiniBankでは、
重要な金融更新をデータベース側で制御します。
これらをバラバラに更新するのではなく、必要な単位で整合させます。
これはMiniBankで特に重視している考え方です。
このとき、
「失敗したから、もう一度送ろう」
と考えると、
二重送金になる可能性があります。
そこでMiniBankでは、
を区別します。
結果が分からなければ、
金融システムでは、
「分からない状態」を正しく扱うこと自体が機能です。
銀行の帳簿で、
都合の悪い取引を削除してしまったら、
何が起きたのか後から分からなくなります。
MiniBankでは、訂正が必要な場合、
元の仕訳を残したうえで、
反対方向の仕訳を追加する
逆仕訳
を扱います。
| 記録 | 借方 | 貸方 | 扱い |
|---|---|---|---|
| 元の仕訳 | 勘定 X | 勘定 Y | 残す |
| 逆仕訳 | 勘定 Y | 勘定 X | 追加（反対方向） |
何が起きたのかを後から追えることを重視します。
MiniBankは、
口座テーブルの残高数字だけを増減させるアプリではありません。
取引の裏側には、
銀行側の台帳があります。
顧客に見えるお金の動きと、銀行側の会計をつなぐ。
ここは、経理・財務の視点からMiniBankを見ると特に面白い部分です。
PART IVBusiness Day / Recovery
論理営業日・EOD / BOD・照合・調査・Backup / Restore。
MiniBankには、システムが管理する論理営業日があります。
という流れを管理します。
締め処理が始まれば、新しい金融更新を止める。
一方で、すでに依頼された取引の結果確認まで止めてしまうわけではない。
「金融取引を受け付ける時間」と「結果を確認すること」を分けます。
End of Day。Beginning of Day。
MiniBankでは、単なる日付更新ではなく、銀行業務として扱います。
必要な日次処理を確認してから締める。
問題があれば、
「なかったこと」にせず、
調査対象へ回します。
金融システムでは、
複数の場所に似た数字が存在します。
これらが一致しているか確認する。
それが照合です。
MiniBankでは、
「画面上の残高がそれっぽい」
だけで正常とは判断しません。
差異を検出したら、
それ自体を運用上の問題として扱います。
こうしたものを調査案件として扱います。
そして、
案件を「完了」にすることと、お金を動かすことを分離する。
調査画面で完了ボタンを押したからといって、
金融記録まで都合よく書き換わるわけではありません。
バックアップを復元できた。
アプリも起動した。
だから復旧完了。
……ではありません。
MiniBankでは隔離した検証環境で、
復元後のデータを照合し、
安全に金融更新を再開できる状態かを確認する考え方まで扱っています。
起動できることと、安全に再開できることを分ける。
これも金融システムの重要なテーマです。
PART Vv8 – v10 · Posting / Interbank / Accounting
v8 Ledger & Posting Engine から、v13 Treasury / ALM Simulator まで。
v8では、Ledger & Posting Engineを追加しました。
それまで各業務の中に存在していた記帳を、
より体系的な仕組みとして扱います。
つまり、Business Event → Posting Rule → Journal Entry → Ledger という流れです。
「振込処理のコードの中で仕訳を書いた」
だけではありません。
銀行取引を会計記録へ変換する仕組みそのものを、一つの基盤として扱う。
MiniBankはここで、一段階違うシステムになりました。
Posting Engineでは、
帳簿そのものの整合性も確認します。
差異を抱えたまま締め処理を完了させてしまえば、
問題を含んだ帳簿が「締めた結果」として残ってしまいます。
だから、
異常を検知したら、締め処理を完了させない。
整合性チェックで問題が見つかった日次・月次の締めは、
CLOSEDではなくBLOCKEDとして記録し、
運用者に対応を求めます。
「とりあえず締める」ではなく、
金融システムでは安全側に倒すことも重要な設計です。
v9では、Interbank Payment Simulatorを追加しました。
MiniBank内部の口座振替だけでなく、
別の銀行へ送金するケースを扱います。
MiniBankでは、この流れを学習用にシミュレーションします。
実際の銀行ネットワークへ接続するわけではありません。
しかし、
自分の銀行内だけで残高を減らせば他行送金が終わるわけではない
という重要な考え方を、動く形で扱います。
顧客Aから顧客Bへ送る。
二人が同じ銀行なら、銀行内部の帳簿で完結できます。
しかし、相手が別の銀行なら、銀行同士の決済が必要になります。
そこで登場するのが、銀行側の決済用資金です。
MiniBankでは、銀行間支払と中央銀行預け金を意識した勘定をつなぎます。
これにより、
顧客の振込
と
銀行間の資金決済
を分けて考えられます。
v9では、銀行間決済でも RESULT_UNKNOWN を重要な状態として扱います。
送信した。
しかし返答がない。
この状態で同じ決済を再送したら、
二重決済になる可能性があります。
そこで、再送ではなく照会を行います。
相手側・決済側の確定状態を確認し、
その結果に合わせてMiniBank側の状態を解決する。
実装上も、
結果不明の取引に対して安易な再送をさせず、
照会によってSETTLEDへ解決する流れを用意しています。
v10では、Bank Accounting & Closingへ進みました。
顧客が振り込んだ。定期預金を作った。利息を支払った。他行から入金があった。
それらは最後に、
銀行の会計へ集約されます。
これは会計の基本です。
しかし、
画面へ式を書くだけなら簡単です。
重要なのは、
実際の取引を積み上げた結果として、
その関係が保たれていること。
MiniBankでは、
それぞれをつなぎ、
銀行業務の結果を会計として確認します。
「会計画面があります」から、「締め処理まで動く」へ。
v10でMiniBankはそこまで広がりました。
PART VIv11 – v13 · AML / Operations / Treasury
v11 Fraud / AML Simulator・v12 Banking Operations Center・v13 Treasury / ALM Simulator。
v11では、Fraud / AML Simulatorを追加しました。
Ledgerに記録された取引を監視し、
一定のルールに該当するものを検出します。
しかし、
アラートが出たからといって、
その時点で不正と決めつけるわけではありません。
アラートと不正確定を分ける。これはAMLを扱ううえで非常に重要な考え方です。
MiniBankのAMLフローでは、
必要な調査を行わないまま、
いきなり判断しようとすると拒否される設計があります。
誤検知なら、
誤検知として完了する。
「怪しいから自動で口座凍結」
だけの単純な仕組みにしない。
検知・調査・判断・実処理を分けています。
v12では、Banking Operations Centerを追加しました。
ここでMiniBankは、
「機能を持つシステム」から
「運用するシステム」
へ進みます。
金融システムで問題が起きたとき、
ただログを眺めるだけでは判断できないことがあります。
MiniBankでは、
運用画面から原因を追跡するための情報をつなぎます。
取引を「業務の流れ」として追う。
それがOperations Centerの役割です。
MiniBankでは、
問題発生後の運用までをシステム設計の対象にしています。
v13では、Treasury / ALM Simulatorを追加しました。
ここまで来ると、
顧客向け銀行アプリという枠を大きく超えます。
銀行は、
資産と負債を見ながら、
必要な資金を確保しなければなりません。
Treasury / ALM Simulatorでは、
預金流出シナリオを設定できます。
数字で確認します。
MiniBankでは、
市場シナリオを使ったWhat-if分析を行います。
架空の銀行条件を入力し、
再現可能なシナリオとして計算します。
例えば、
さらに流出率を大きくすれば、
資金ショートが発生するケースも確認できます。
これらはMiniBankの学習用シナリオに基づく計算例であり、実在銀行の財務状況や規制指標ではありません。
v13で重要なのは、
ALM画面だけを独立して作ったのではないことです。
PART EXAMPLETransfer / Ledger / GL
AからBへ、同じ銀行内で10,000円を振り込む。これは実取引ではなく、記録の関係を読むための例です。Aの預金が減り、Bの預金が増える。銀行から見ると、顧客に対する預金負債の内訳が移ります。
取引のBusiness EventをPosting Ruleに従って仕訳へ変換し、Ledgerに残す。GLでは科目の集計を行い、補助元帳と照合する。この説明上の順序を、すべてが同時に一つのトランザクションで確定する保証として読み替えません。
残高の数字だけでなく、なぜその数字になったのかを残す。
PART v14Lending / Credit
個人向けの架空融資を、申込画面だけで終わらせず、契約・返済・会計・運用までつなげます。
融資は、ボタンを押して残高を増やす処理ではありません。申込が届き、担当者が審査し、別の管理責任者が承認する。実行時には、承認の期限と、その時点で有効な担当者・決裁者の権限をもう一度確認します。
顧客には、自分の申込、契約、返済予定が見えます。管理者の審査メモや内部の提案まで、そのまま顧客に返す構成にはしません。第5章のMaker / Checkerを、今度は信用供与へつなぐ考え方です。
基準の商品は固定金利・元金均等12回の学習用モデルです。契約には締結時の金利と返済回数を保存します。後で新しい商品の版を作っても、既存契約の約束を一斉に変えません。
返済予定表は元本と利息を区別します。利息は日数と残元本をもとに計算し、返済は確定済み未収利息から元本へ充当します。口座の残高が足りなければ、部分的に引き落として成功と見せるのではなく、処理を失敗として扱います。
期日を過ぎた延滞の状態と、契約そのものの状態も区別します。デフォルトの確定は別人確認を伴い、元本や未収利息を都合よく消す操作ではありません。回復や訂正にも理由と記録が必要です。
第17章のPostingと第22章のGLは、融資でも土台です。元本残高だけが合っていても、契約と仕訳が食い違えば十分ではない。その関係を、照合で確かめます。
実信用情報の照会、自動与信、実資金の融資・回収、法人融資、繰上返済、実際の税務や法令適合性の保証は対象外です。教材で扱う法人融資の概念と、この個人向け実装を混同しません。
PART v15Deposit / Pricing
預金の金利・手数料・中途解約条件を版として管理し、見積りから会計まで理由を残します。
同じ定期預金でも、契約した時期で金利は変わります。そこで商品と価格の版を分け、提案者と別の管理責任者が承認します。公開された版の内容は後から書き換えず、新しい条件は新しい版として扱います。
見積りでは、元本・期間・営業日に対して適用する版、満期日、利息、中途解約の目安を確認できます。契約までに見積りが失効したり条件が変わったりした場合は、古い画面を信じて進めず、再見積りが必要になります。
契約時には版と金利、開始日・満期日、中途解約条件を固定して保存します。現在の価格表を読み直して、過去の契約の利息を勝手に変えることはしません。版を持たない旧契約も、推測で新しい版へ付け替えず、従来の扱いを区別して残します。
普通預金の利息は、期間の残高と版付き金利から再計算できる形にします。口座維持手数料には免除条件を持たせ、残高不足のときは請求できなかった記録を残します。実行済みの同じ口座・期間を重ねて処理しないことも、金額計算と同じくらい大切です。
新しい定期預金は契約時の条件から満期や解約の利息を計算し、業務の記録をLedgerの仕訳と照合します。これにより、v13の調達コスト、v18のリスク、v20の試算が「いま表示中の金利」だけに依存しない入力を持てます。
対象は架空の円建て預金商品です。実際の金利決定、税、預金保険を扱いません。v15の価格管理を、既存の他行送金手数料を全面変更する機能として説明しません。
PART v16Open Banking Sandbox
架空の外部アプリを使い、同意・認可・API・通知の境界を学ぶ、閉じたSandboxです。
利用者がログインしたことと、外部アプリが口座を読めることは別です。まず架空クライアントを登録し、利用者が同意する範囲を確認します。認可コードをPKCEとともにトークンへ交換し、その資格とscopeで資源APIにアクセスします。
口座、残高、取引の参照と、振込の依頼は権限が異なります。本人の対象か、同意がいまも有効か、クライアントが停止していないかを確認します。第三者アプリから振込を依頼できても、利用者自身の承認まで省略するものではありません。
状態の変更はイベントとして記録し、Webhookの配信を模擬します。成功、失敗、再試行、重複、逆順といった受信者の振る舞いを試すための仕組みです。通知は結果を伝えるものであり、通知を受けるたびに資金を動かす処理ではありません。
受け手はイベントIDで重複を除き、同意ごとの順番を見ます。欠けた通知はAPIで追いつく。振込の応答が消えたときは、元の冪等キーで状態を照会する。第8・9章のRESULT_UNKNOWNと二重送金防止が、連携の外側でも同じ意味を持ちます。
同意の失効、トークンの期限切れ、scope不足、他人の口座、改ざんされた署名を、正常な成功と区別して拒否します。金融結果と通知の結果を分けることで、連携の障害を金融取引のやり直しへ直結させません。
実第三者、実金融機関、実API、外向きのWebhook配信を接続するサービスではありません。OAuth / PKCEを学ぶ教育用の簡易構成で、認可サーバーの認証や実運用への準拠を保証しません。
PART v17Reliability / Recovery
何を戻したのか。その状態で再開してよいのか。復旧の判断にも、証拠と別人確認を持たせます。
古いバックアップを戻して、帳簿の借貸が合っているだけで再開してしまうと、障害前の取引が欠けていても見逃すおそれがあります。復旧では、内部の整合性だけでなく、戻すべき状態との一致が必要です。
書き込みを止め、復元対象の識別情報と書き込み世代を、障害前に外へ控えた値に照らして宣言する。口座・元帳・GLだけでなく、融資、価格、グループなどの関連領域も照合する。問題が残っていれば、検証結果を成功に置き換えず、再開を止めます。
限定された差異の修復と、復元後の全体検証は別です。修復できる範囲を絞り、提案・確認・実行の記録を残します。元の履歴を消して何事もなかったように見せることとは違います。
復旧結果を提出した人と、再開を認める人を分ける。提出後に状態が変わっていないかも確認する。第16章までの安全な再開と、第27〜29章の例外・Incident・Runbookを、新しい領域が増えた状態でも守るための統制です。
「照合が通った」「隔離環境で復元を試した」「本番をこの手順で復旧した」は、それぞれ違う証拠です。実際に運用する人の作業や、外へ控える情報を含む手順まで確認して、はじめて運用として評価できます。
本番の自動バックアップ、PITR、Authデータの自動復元、無停止復旧、RTO / RPOの保証を意味しません。復旧演習の記録と本番での実施条件は別途照合対象です。
PART v18Enterprise Risk
融資、価格、ALM、運用の記録を凍結し、仮定と計算式を明示した比較へつなげます。
違う時点の残高や契約を比べて、シナリオの差だけだと誤解しないように、入力のスナップショットを取ります。パラメータも承認された版を使い、実行記録には入力、式、結果、警告、欠測を残します。
金利上昇、預金流出、信用ストレス、複合ストレスを、同じスナップショットで比較する。保存した入力から再計算し、結果を確かめる。指標の意味と前提が分かっているから、単に赤い数字が出るダッシュボードとは違う読み方ができます。
必要なALMや価格の入力がなければ、欠測や代替の仮定を明示します。計算できない値を0にして安全に見せません。また、異なる単位の指標をそのまま合算しません。同じ円の単位で整理した総合比較も、相関・分散効果を考慮しない簡易モデルであることを残します。
対策案には、対象の実行結果、理由、期待する効果を記録し、別の管理責任者が判断します。その承認は意思決定の記録です。勝手に融資条件や取引上限を変更したり、調達取引を実行したりはしません。
v13のTreasury / ALMが資金や金利を見る土台なら、v18は信用と運用も含めて比較する視点です。v20では、その計算を試算の期末状態へつなぎます。
PD・LGD・損失係数は教育用の架空の仮定です。規制上の自己資本比率、LCR / NSFR、認証済みリスク計測、実市場価格の評価、集中リスクや相関を含む全面的なリスク管理を提供しません。
PART v19Group / Consolidation
元帳は法人別に守る。相互勘定は照合する。連結の消去は報告上で行う。
既存の銀行を基準法人とし、追加法人には独立した元帳と、扱える人の役割を持たせます。基準銀行の記帳は、引き続き既存のPosting Engineが入口です。グループの画面ができたからといって、銀行の元帳を別の書き込み口に置き換えません。
法人口座の顧客と、グループ内の法人を管理する権限も異なります。グループ管理は、既存の全データを単に「法人ID付きの一枚の表」に移す説明ではありません。
グループ内の資金移動は、送り手が記帳する段階と、受け手が記帳する段階を持ちます。資金供与、返済、役務の対価には、それぞれ異なる相互勘定が残ります。二つの法人をまたぐ一つの仕訳を作って、両側の責任を曖昧にしません。
片側だけが確定しているときは、照合待ちとして扱います。理由を残して受け取りを再試行するか、送り手の仕訳を逆仕訳で取り消すかを判断する。完了していないものを成功と表示しない、第9章からの考え方です。
法人別の借貸、相手別の債権・債務、基準銀行の補助元帳、読み取りadapterを別々に照合します。「全体の合計が合っている」だけで、片側の欠落を隠しません。
同じ営業日の法人別スナップショットを合算し、債権・債務と受取・支払手数料を報告上で消去します。消し切れない残りは、移動中なのか、説明できない不一致なのかを分けて示します。確定後に元帳が動いた場合も、報告時点との差として読みます。
連結報告は、法人ごとの元帳を書き換える訂正処理ではありません。v20のベースラインにも、法人別とグループ全体を区別した入力としてつながります。
対象は架空のグループと簡易連結です。持分法、外貨換算、少数株主持分、実在企業の連結財務報告、完全な会計基準対応を提供するものではありません。
PART v20BANK DIGITAL TWIN
取引を記録する仕組みから、条件を変えて理由をたどる試算へ。
預金の金利は、どこまで追随するのか。
預金が流出したら、いくら調達する必要があるのか。
貸出の利息収益と調達費用は、どのように変わるのか。
v20のBank Digital Twinは、凍結したMiniBank内の実績データと、明示したモデルの仮定を使い、条件を変えたときの影響をたどる試算機能です。
政策金利から、預金価格、預金残高、調達コスト、貸出収益、資金繰り、試算上のBS・PL、リスクまで。
一つの条件変更を、つながりのある変化として見ていきます。
同じ入力で計算し直す。条件をそろえたシナリオを比べる。仮定を変え、何が結果を左右するかを確かめる。
大切なのは、未来を言い当てることではなく、結果に至る理由をたどれることです。
取引で残った実績と、条件を変えて作る試算。二つを混ぜずにつなぐ。
凍結した入力 ＋ 架空の仮定 ＋ シナリオ ＋ シード
出力は試算の記録。正式な元帳・口座残高・契約への書き戻しはありません。
同じベースライン・モデルの版・シード値をそろえた試算を比較する。
入力をそろえてから条件の違いを見ることで、比較してよい結果の組を区別します。
保存した入力から再計算し、結果が一致するか確認する。
凍結入力と保存済み結果のハッシュを照合し、同じ条件を再現できるかを確かめます。
各段階の入力・式・出力と、仮定の感応度を確かめる。
感応度はパラメータを一つずつ変える分析です。自動で最適な経営判断を提案するものではありません。
4入力から9段階をたどる計算、比較・再計算・感応度は固定コード上の実装を確認しています。現在のProductionで業務E2Eを実証したという意味ではありません。試算は実績ではありません。正式な元帳・口座残高・商品契約は変更しません。模型の仮定は架空であり、現実の銀行を予測するための精度検証や、統計的な当てはめを行ったものではありません。試算の入力・実行結果は専用領域に記録します。
v13のTreasury・ALM、v14の融資、v15の預金価格、v18のリスク、v19の法人別元帳。Digital Twinはそれぞれの実績を凍結し、同じ言葉と計算につなげます。
既存の固定金利融資は、金利ショックで一斉に変動金利へ変更しません。価格の版、既存契約、新規貸出を区別します。
必要な入力がないときは、実行を拒否する場合や、注意・欠測を返す場合があります。見栄えのために0で埋めたグラフは作りません。
ここで示す図は、試算の仕組みを説明する概念図です。実績を予測の数値として読み替えず、入力・仮定・欠測とともに結果を読みます。
試算を支える仕組みを見る →1件の取引を考えてみます。
一つひとつ別々のデモを作ったのではありません。
できる限り、
一つの銀行の中でつなげる。
それがMiniBankの設計思想です。
PART VIISecurity & Control
認証・認可・RLS・Database Privilege・RPC・Fail Closed・MFA・Maker / Checker・監査記録。
MiniBankでは、画面を非表示にするだけで権限管理を終わらせません。
認証。認可。RLS。データベース権限。RPC。口座状態。法人所属。法人ロール。振込限度額。Maker / Checker。MFA。監査記録。
これらを組み合わせます。
「見えない」だけではなく、「できない」。
この境界を重要視しています。
AUDIT TRAIL
金融システムでは、
結果だけではなく、
経緯をたどれること
も重要です。
MiniBankでは、
重要操作と監査記録をつなげます。
PART VIIIArchitecture
MiniBankでは、利用者画面だけでなく、システム内部の責任分界も学習対象です。
概念的には、
という関係になっています。
MiniBank Architectureでは、単に
と製品名を並べるのではありません。
その技術に、どの責任を持たせているか
を見ることを重視します。
MiniBankには、
Java / Spring BootによるPayment Serviceもあります。
Next.js / PostgreSQLだけではなく、
エンタープライズ開発で広く使われるJavaの構成からも、
銀行システムを学べます。
重要なのは、
技術が違っても、金融取引の正しさは一つ。
その考え方を共有します。
PART IXMiniBank Academy
振込ができる。
それと、振込がなぜ安全に処理できるのか説明できる。
これは違います。
第41〜46章はv13時点の教材構成です。コースへの割当レッスン数と、教材ページのroutes数は異なります。現在のProduction表示数は別途照合対象です。固定基準コードの割当数は、v20増補で確認範囲とともに紹介します。
MiniBank Academyは、
動いているMiniBankを教材にして、銀行業務とシステム設計をつなげて学ぶコンテンツです。
Academyは、基礎から専門領域まで広がっています。
MiniBankの全体像、基本用語、画面・API・DBの関係。
口座、決済、預金、銀行ビジネスなど。
台帳、会計、振込、認証、監査、照合。
トランザクション、並行処理、API、DB、テスト、障害対応。
Java、Spring Boot、Controller / Service / Repositoryなど。
安定稼働、品質、技術選択、金融システムの信頼性。
業務、アプリケーション、データ、技術を横断して設計する。
法人金融、企業財務、融資、コミットメントライン、シンジケートローンなど。
Posting。Interbank Payment。Bank Accounting。AML。Operations Center。Treasury / ALM。MiniBank v8〜v13で実装した銀行内部機能を、実装と結びつけて学びます。
v8〜v13既存教材を残しながら、
v8〜v13に合わせて銀行エンジニアリング教材を追加。
新しい銀行エンジニアリングには、29レッスン。6つのLab。総まとめ。を用意しています。
目的から選ぶLearning Pathは7つ。
さらに、
自分のバックグラウンドから、銀行システムへ入れます。
Labでは、
正解だけを読むのではありません。
自分ならどう判断するのか。
実装を見ながら考えます。
Academyでは、
実銀行の仕組みについても扱います。
しかし、
教材で説明していることが、
すべてMiniBankの実行機能として存在するわけではありません。
例えば、
これらを提供しているわけではありません。
を混同しない。
これもMiniBank Academyの重要な方針です。
PART LEARNArchitecture / Academy / v20
新しい領域も、操作だけで終わらせず、設計と計算の前提へ戻ります。
個人口座から始める。第17章で取引と仕訳をつなぐ。第22章でGLを読み、第30章で資金繰りを見る。その先で融資・価格・リスクをたどると、Digital Twinの入力がどこから来たのかを説明できます。
Architectureは、画面・認証・API / RPC・DBの権限・元帳・GLという責任の流れを読み解く入口です。6枚の設計図と、第38〜40章の既存説明を行き来できます。図に描かれた運用構想と、実際の確認済み機能も分けて読みます。
固定基準コード上で、9コースへのレッスン割当は133件です。Bank Engineeringは55件、そのうちLabは13件。これはコースへの割当数で、routes数・教材ファイル数・現在のProduction表示数を数えた値ではありません。第41〜46章の107件などはv13当時の構成として残しています。教材の将来設計や対象外の業務を、利用画面の実装機能と数えません。
PART XEvolution / Verification / Process
第47〜50章はv13までの進化と検証記録です。掲載する試験数はv13時点の値で、v20の試験数や本番の確認結果を示すものではありません。
MiniBankは、
最初からこの規模だったわけではありません。
MiniBankでは、
機能追加だけでなく、
継続的に検証を行っています。
v13の検証では、
さらにRelease Candidateでは、
をローカルの検証環境で実施しました。
また、
Academy全ルート。内部リンク。管理画面。顧客画面。モバイル表示。
なども確認しています。
テスト数が多ければ安全だ、と単純に言うつもりはありません。
しかし、
「動いたから完成」ではなく、何を確認したのかを残す。
それを開発プロセスの一部にしています。
MiniBankは、
AIを活用して開発してきたプロジェクトです。
AIは大量のコードを作ることができます。
しかし、
コードが生成されたことと、
正しい銀行システムになったことは同じではありません。
だから、
を分けて進める。
AIが速いからこそ、
人間は「何を正しいとするのか」を決める。
MiniBankは、
AI時代のシステム開発そのものを学ぶプロジェクトでもあります。
MiniBankの特徴の一つは、
技術だけから銀行を見ていないことです。
これらを、
システム実装と結びつけています。
それらを横断することを目指しています。
PART EVIDENCEEvidence / Boundaries
コードがあること。試験で通ったこと。公開環境で確認したこと。これらは別の根拠です。v20の説明は、その区別を保ち、まだ照合できていない情報を成功として扱いません。
| 区分 | 説明できる範囲 |
|---|---|
| 実装コード | v14〜v20の業務migration・型・関連仕様を固定基準コードで照合。機能の存在と説明範囲を確認。 |
| 隔離環境の試験 | ローカル受入・過去の試験記録は存在。本番の最終公開結果や、現在の適用状態を証明するものとは分ける。 |
| Unit / DB / Privilege / MFA | v20最終公開記録との件数・区分の照合はTBD。未照合の最新試験数やPASSバッジは掲載しない。 |
| 画面・復旧・整合性 | 本番の主要画面、隔離復元、限定修復、最終整合性の公開記録は追加照合対象。未確認を検証済みとしない。 |
| DBの定義・履歴 | 2026年10月3日の監査対象は、業務schema 25（publicと空のcoreを含む）・通常table 122。provider管理領域、view、partitioned tableは業務table数に含めません。固定ソースのmigrationファイル150本と接続先DBの履歴150件は、版番号・名称が一致。SQL内容の完全同一性を確認したという意味ではありません。 |
| 公開・運用の設計 | 公開deploymentとGit連携は確認しましたが、全機能の本番業務E2Eとは別です。mainの保護設定は無効。自動バックアップ・PITR・通知・自動復帰・可用性の実証は未確認で、実稼働済みとは紹介しません。 |
第48章に残した試験数はv13当時の記録です。この紹介は、金融サービスとしての安全性・可用性・法令適合性や、外部監査・認証を保証するものではありません。
PART XIScope
MiniBankは、
実在の銀行システムと同等ではありません。
だからこそ、
できていることと、できていないことを分けて説明します。
銀行という題材を通じて、
業務・会計・技術・運用を、
一つのシステムとしてつなげる。
それがMiniBankです。
PART FAQQuestions / Learning
できません。MiniBankは架空の銀行システムシミュレーションです。実資金、実在金融機関との決済、実際の預金受入を提供しません。実在の個人情報・認証情報・金融情報を入力しないでください。
つながっていません。他行、KYC、Open Bankingのクライアントや通知は、学習・検証用の模型または閉じたSandboxです。外部連携が実稼働しているという意味ではありません。
個人口座などの利用者向け画面と、管理者権限を必要とする機能は別です。利用者向けの入口から、他行の決済や銀行全体の設定・試算を無制限に操作できるわけではありません。
しません。MiniBank内の凍結実績と、明示した架空モデルによる試算です。未来予測の精度、実データへの統計的な当てはめ、実際の経営判断の妥当性を保証しません。正式な元帳や契約へも書き戻しません。
管理機能には役割と権限が必要です。このLPから管理者権限や認証情報を提供することはありません。公開の紹介と、権限を持つ検証者の操作範囲を区別しています。
利用者の操作から、第1〜52章の説明、Architecture、MiniBank Academyへ順に進めます。まず一件の振込を読み、台帳・GL・日次運用へ戻り、その後で融資・価格・リスク・Twinをつなぐ読み方がおすすめです。
そして、その仕組みをAcademyで学ぶ。
MiniBank v20
Banking System, built to understand.