金融機関の技術スタック：世代の違う仕組みを安全につなぐ
金融機関に共通する唯一の技術スタックはありません。長く動く勘定系、新しいWeb・モバイル、外部決済、データ分析、監視・セキュリティを、責任と信頼境界で組み合わせる考え方を学びます。
金融ITの技術選択、品質保証、安定稼働、業界の変化を設計判断へつなげる。
先に学ぶ内容 — Prerequisite: 銀行システム / ソフトウェア工学学ぶこと — LEARNING GOALS
このページで学ぶこと
- 金融システムを構成する代表的な技術層
- メインフレーム・Java・クラウドが共存する理由
- 製品名より先に責任・データ・障害範囲を決める方法
体験22 · FINANCIAL IT STACK（技術スタック）
銀行のシステムは、1つの技術に統一されているべきか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元でMinibank自体の技術構成を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
銀行のシステムは、1つの新しい技術に統一されているほど優れていると言えるでしょうか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
古い仕組みと新しい仕組みが同時に動いていたら、それは失敗でしょうか？
ヒント2を見る
Minibankには、Next.jsだけでなく、Javaで書かれた部分もあるでしょうか？
もっと詳しく：この問いで使う専門用語
- System of Recordは、複数の値が食い違ったときに正しいとする正式記録です。
- Integrationは、別々のシステムがAPIなどで連携することです。
- 非機能要件は、速さ・安全性・復旧など機能以外の条件です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
銀行システムは1つのprogramではなく、勘定系、決済、Web・mobile、外部連携、会計、data分析、監視など多数の仕組みで構成されます。
長く動くmainframe、新しいJava service、cloudやSaaSが共存することがあります。新旧だけで優劣を決めず、責任・data・障害範囲で評価します。
製品名を先に選ぶのではなく、重要業務、正となる記録、性能、停止許容、security、復旧、運用能力から技術を選びます。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
System of Record
複数の値が違った時に正しいとする正式記録です。
画面、cache、分析dataのどれを直すべきか判断するためです。
資金変動はLedgerを正とし、cached balanceを照合します。
Integration
別々のsystemがAPI、message、fileなどで連携することです。
1つの銀行業務が多くの部品と外部機関をまたぐためです。
Next.js、Spring Boot、PostgREST、PostgreSQL RPCが連携します。
非機能要件
速さ、安全性、停止許容、復旧など機能以外の条件です。
同じ振込機能でも必要な技術構成が大きく変わるためです。
transaction、idempotency、auditなどを機能と一緒に設計します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
最初に：銀行は1つの巨大アプリではない
銀行には、口座・残高・利息を管理する勘定系、振込やカードを扱う決済系、Web・モバイル・ATM・店舗などのチャネル、会計・リスク・不正検知・監査・データ分析など多数の領域があります。
同じ銀行でも、長期間安定稼働してきたメインフレーム、Javaなどの分散系、SaaS、クラウドネイティブなサービスが共存します。新旧というラベルだけで優劣を決めず、重要業務、変更頻度、可用性、データ整合性、移行可能性で評価します。
代表的な7つの層
| 層 | 代表的な役割 | 技術の例 |
|---|---|---|
| Channel | Web、mobile、ATM、店舗、call center | Web framework、native app、BFF |
| Edge / Access | 入口保護、認証、rate limit、routing | WAF、API gateway、IAM、MFA |
| Business Service | 振込、口座、融資、KYCなどのユースケース | Java / Spring、.NET、COBOL、その他 |
| Integration | system間の同期・非同期連携 | REST、gRPC、message queue、event streaming、file transfer |
| System of Record | 口座・契約・取引・Ledgerの正式記録 | RDBMS、mainframe data store、append-only ledger |
| Data / Analytics | 報告、不正検知、risk、BI、AI | DWH、data lake、stream processing、ML platform |
| Platform / Operations | 実行、配布、監視、秘密、復旧 | on-prem、cloud、container、CI/CD、observability、SIEM、HSM |
同期APIだけで全体をつながない
利用者が結果を待つ照会や受付には同期APIが向きます。一方、大量処理、他行連携、通知、会計集約にはmessage、event、batch、managed file transferなども使われます。
すべてを同期呼び出しにすると、遠い依存先の遅延や停止が利用者画面まで連鎖します。非同期化すれば自動的に安全になるわけでもなく、順序、重複、再試行、滞留、照合を設計する必要があります。
| 連携 | 向く場面 | 必要な設計 |
|---|---|---|
| 同期API | 即時の照会・入力検証・受付 | timeout、rate limit、idempotency、fallback |
| Message / Event | 疎結合な後続処理・大量処理 | 重複排除、順序、dead letter、再処理 |
| Batch / File | 締め処理・外部一括連携 | cutoff、件数金額照合、再送、暗号化 |
| Database transaction | 同じDB内の原子的変更 | lock、constraint、rollback、監査 |
技術選定は非機能要件から逆算する
- 01重要業務とSystem of Recordを定義する
- 02取引量・peak・応答時間・停止許容を定量化する
- 03整合性・監査・security・data residencyを決める
- 04障害範囲と依存先を地図にする
- 05運用者・support期限・移行方法を含め候補を比較する
- 06小さな検証とfailure testで前提を確かめる
- 人気の製品より、組織が安全に運用できるか
- 機能数より、障害時に縮退・復旧・切戻しできるか
- 単体性能より、end-to-endの制限値とbackpressure
- 導入費より、保守・監査・移行・終了までのTCO
- 新規性より、重要業務に必要なsupport lifecycle
Minibankをこの地図へ置く
MinibankではNext.jsがChannelとBFF、Supabase Authが認証、PostgRESTがData API、PostgreSQL RPCが金融操作、ledger schemaが正式な会計記録を担います。追加されたSpring Boot Payment Serviceは別のBusiness Service入口です。
学習用の小さな構成であり、message broker、mainframe、multi-region、HSM、enterprise data platform、銀行間networkは備えていません。一般的な金融ITの概念と、Minibankに実装済みの範囲を区別します。
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
金融機関の技術スタックの考え方を読んだところで、教材内の参照元でMinibank自体の技術構成を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まずNext.js側のAPI境界を見て、次にSpring Boot側のサービスを見ます。2つの技術がどう並行しているかを確かめましょう。
教材の参照元を確認する — Source Trail ↓MinibankのNext.js API境界。既存の振込入口を探します。
src/app/api/v1/追加されたSpring Boot Business Service。別の技術スタックがどう並行しているかを探します。
services/payment-service/ - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜ銀行のシステムは、1つの技術に統一するのではなく、複数世代の技術を組み合わせて運用されるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「責任」と「障害範囲」という2つの言葉を使って書いてみましょう。
ヒント2を見る
Minibankが複数の技術を組み合わせている理由を考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
System of Record、Integration、非機能要件の3つを使って、技術選定が製品名から始まらない理由を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- 複数の技術が責任を分けて共存できると説明できる
- 正式な記録がどの層にあるべきか説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1すべての銀行が同じ技術スタックですか？
いいえ。歴史、規模、商品、国、規制、外部接続により異なります。
Q2すべてを同期APIで接続すれば簡単ですか？
依存先障害が連鎖しやすくなります。用途に応じてmessageやbatchも使い、重複・順序・照合を設計します。
Q3技術選定で製品機能以外に何を確認しますか？
運用能力、support、障害範囲、capacity、security、移行・撤退、TCOを確認します。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- 金融庁 — 金融機関のITガバナンスに関する対話のための論点・プラクティス
経営戦略とIT戦略、ITガバナンスを一体で考えるための公式資料
- Basel Committee — Digitalisation of finance
API、AI/ML、DLT、cloudと新たな提供者が銀行へ与える影響
- 金融庁 — 電子決済等取扱業者のシステムリスク監督上の着眼点
API、外部サービス、取引急増、品質、capacity、cloud riskの観点
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 現在の実装 — CURRENT IMPLEMENTATION
src/app/api/v1/MinibankのNext.js API境界 - 現在の実装 — CURRENT IMPLEMENTATION
services/payment-service/追加されたSpring Boot Business Service - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/PostgreSQL RPC・Ledger・Auditの実装 - 関連教材 — RELATED LESSON/docs/java-minibank-architecture関連教材の入口。Java / Spring Boot各層の教材