BEGINNER · 入門COURSE 06 · FINANCIAL IT / RELIABILITY

Javaとは何か：金融システムで使う理由と限界

Javaは言語だけでなく、JVM・標準ライブラリ・開発ツール・運用ecosystemを含むplatformです。金融機関で選ばれる理由を、長期保守・型・並行処理・監視とtrade-offから理解します。

03 / 07

FINANCIAL IT / RELIABILITY · 金融IT・信頼性

金融ITの技術選択、品質保証、安定稼働、業界の変化を設計判断へつなげる。

先に学ぶ内容 — Prerequisite: 銀行システム / ソフトウェア工学

学ぶこと — LEARNING GOALS

このページで学ぶこと

Java・JDK・JVM・bytecodeの関係
金融システムでJavaが選択肢になる理由
Javaを使うだけでは品質や安全性が完成しない理由

体験39 · FINANCIAL JAVA（言語選択の理由）

Javaという言語を採用すれば、金融システムは自動的に安全になるか確かめよう

まずは予想をひと言。本文を読んだ後、教材内の参照元で実際のversionと責任分担を確認します。

体験学習 · STEP 1 / 5

01
まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
Javaという言語を採用するだけで、金融システムの正確さや安全性が保証されると思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
あなたの予想（5文字以上）
ヒント1を見る
静的型やJVMの成熟度は、業務ruleの正しさまで保証してくれるでしょうか？
ヒント2を見る
Payment Serviceの認可・残高判定は、どこにあるか思い出してみましょう。
もっと詳しく：この問いで使う専門用語
- JVMは、Javaのbytecodeを実行する仮想machineです。
- JDKは、Javaを開発・実行・診断する道具一式です。
- LTSは、長期supportを前提にしたreleaseです。

日常語で理解する — PLAIN LANGUAGE

まず、ここだけつかむ

Javaは文法だけではなく、bytecodeを実行するJVM、開発道具のJDK、標準APIと周辺ecosystemを含むplatformです。

型、長期support、監視機能、enterprise向けlibrary、人材・運用知識を活用できることから金融systemの有力な選択肢になります。

Javaを使っても金融処理が自動的に安全になるわけではありません。業務設計、DB制約、test、監視、復旧が必要です。

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

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

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

JVM

やさしく言うと

Javaのbytecodeを実行する仮想machineです。

なぜ必要？

OS差を吸収し、memory・thread・実行最適化を管理するためです。

Minibankでは

Java 21のJVM上でPayment Serviceが動きます。

JDK

やさしく言うと

Javaを開発・実行・診断する道具一式です。

なぜ必要？

compilerや標準API、運用toolを同じplatformとして使うためです。

Minibankでは

pom.xmlでJava 21を指定します。

LTS

やさしく言うと

長期supportを前提にしたreleaseです。

なぜ必要？

重要systemのpatch・更新・移行計画を長期で立てるためです。

Minibankでは

Java 21を使いますが、distributionと更新方針は別に管理が必要です。

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

Java経路の実装と稼働確認を分ける

request/confirmはPAYMENT_BACKENDで選択します。未設定・空文字・legacyはNext.js→PostgREST RPC、javaはNext.js→Java Payment Service→PostgREST RPCです。不正な値はエラー、Javaのtimeout・5xx・通信断でもlegacyへ自動fallbackしません。旧OTP再発行はこの切替の対象外で、v7のRPCは常に42501で拒否します。TOTPの認可準備はNext.jsの/api/v1/transfers/mfaが担います。コードの存在は確認済みですが、本番・PreviewでJavaが選択されているかはUNKNOWNです。

01Next.jsがPAYMENT_BACKENDを読む
02legacy：呼出者tokenでPostgRESTへ / java：Java Payment ServiceへHTTP
03request_transfer / confirm_transfer_otpでDB処理
04Javaの@TransactionalではHTTP先のcommitを取り消せない
05応答消失時は結果不明。別backendへ自動fallbackしない

Javaは4つの要素で考える

要素	やさしい意味	開発・運用での役割
Java language	人が書く文法と型の規則	class、record、exception、genericsなどで設計を表す
bytecode	compilerが作る中間形式	特定CPUの機械語から一段分離する
JVM	bytecodeを実行する仮想machine	memory、thread、JIT、garbage collectionを管理
JDK	開発に必要な道具一式	compiler、runtime、diagnostic tool、標準APIを含む

Java source (.java)
        ↓ javac
Bytecode (.class)
        ↓ JVM
OS / CPU上で実行

金融システムで有力な選択肢になる理由

静的型により、大規模な変更の影響をcompilerとIDEで見つけやすい
JVMがOS・hardware差を吸収し、成熟したmonitoringとdiagnostic手段を持つ
Web、batch、messaging、database、securityのenterprise ecosystemが広い
LTS releaseと複数のJDK distributionにより長期保守計画を作れる
thread、transaction、validationなど業務systemに必要な基盤が豊富
長年の採用により人材・運用知識・既存資産を活用できる組織が多い

JVMが運用で見せるもの

Javaには監視機能がありますが、metricを収集するだけでは運用になりません。利用者影響、業務状態、Ledger整合性と結び、行動可能なalertへします。

観測対象	問題の例	見る理由
Heap / GC	memory pressure、長い停止	遅延とOutOfMemoryの兆候を知る
Thread	deadlock、pool枯渇、待ち	request停滞の原因を追う
CPU / JIT	hot method、過負荷	処理量と応答時間を説明する
Connection pool	DB接続待ち	DBとapplicationのcapacityを結ぶ
Exception / log	業務失敗・依存先障害	requestIdと取引状態を追跡する

Javaで起こり得る失敗

null、例外の握りつぶし、不適切な共有可変状態
金額へのdouble利用や丸め規則の不一致
thread pool・connection pool・queueの無制限化
長いGC pauseやmemory leak
dependencyやJDK updateの放置
@Transactionalの範囲を外部HTTPまで広がると誤解
frameworkの自動設定を理解せず権限・公開範囲を広げる

MinibankのJava 21を読む

Payment ServiceはJava 21、Spring Boot、record、BigDecimal、RestClient、Bean Validationを使います。Java側はHTTP境界と型付きオーケストレーションを担い、認可・残高lock・Ledgerは既存PostgreSQL RPCへ残しています。

この構成の教材価値は、Javaへすべて移すことではなく、言語・framework・databaseの責任をどこで分けるか観察できる点にあります。

体験学習の続き · LEARNING LOOP

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

JVM・JDK・LTSの考え方を読んだところで、教材内の参照元で実際のversionと責任分担を確認し、自分の言葉で説明してみます。

STEP 2〜5 / 5

02
仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
03
証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
管理者画面を利用できない場合
この項目は教材内のSource Trailと解説で確認できます。実画面を開けなくても学習完了条件を満たせます。代替確認を行った場合は、下のチェックを入れて進めてください。
pom.xmlがJava 21（LTS）を指定していることservices/payment-service/pom.xmlを教材の参照元で確認し、long-term supportの対象であるJava 21が指定されていることを見ます。これにより、長期保守を前提にしたversion選択がされていることが分かります。確認先を開く ↗この記録の意味を確認する → 教材内「LTS」へPayment Serviceが認可・残高・Ledgerの判断をJava側に持たないことapplication/PaymentApplicationService.javaを教材の参照元で確認し、認可・残高lock・Ledger記帳がJavaコードになく、既存PostgreSQL RPCへ委ねられていることを見ます。これにより、Javaという言語選択自体が業務の安全性を保証するわけではないことが分かります。確認先を開く ↗この記録の意味を確認する → 教材内「JVM」へ
04
コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まずpom.xmlでどのJavaを使っているかを見て、次に型を使った値オブジェクトの実装を見ます。言語選択と業務の安全性の関係を確かめましょう。
Java 21とSpring Bootの構成。
services/payment-service/pom.xml
型と不変条件を結ぶ値オブジェクト。
services/payment-service/src/main/java/com/minibank/payment/domain/Money.java
教材の参照元を確認する — Source Trail ↓
05
自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜJavaのような成熟したplatformを使っても、業務設計・DB制約・testが別途必要なのでしょうか？短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
あなたの説明（20文字以上）
ヒント1を見る
「platform」と「業務設計」という2つの言葉を使って書いてみましょう。
ヒント2を見る
Javaを使わなくても必要になるものは何か考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
JVM、JDK、LTSの3つを使って、Javaが金融systemで有力な選択肢になる理由と限界を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint
- Java採用自体が安全性を保証しないと説明できる
- 業務判断の場所がJavaではなくDB側にあると説明できる

理解を確かめる — CHECK YOUR UNDERSTANDING

3問で理解チェック

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

Q1Java sourceをCPUが直接実行しますか？

答え

通常はcompilerがbytecodeへ変換し、JVMが実行します。

Q2Javaを選べば高品質になりますか？

答え

なりません。品質は設計、実装、test、運用、組織能力を含む結果です。

Q3JVMで何を監視しますか？

答え

heap、GC、thread、CPU、exception、connection poolなどを業務指標と結びます。

ここまで読めましたか？

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

業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE

業界資料・参考文献

一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。

Oracle — Java Virtual Machine Specification
JVMとplatform非依存なclass fileの公式仕様
Oracle — Java SE Support Roadmap
LTS releaseとsupport lifecycleを確認する公式資料
Oracle — Java SE Monitoring and Management
JVMのmonitoring・management機能

教材の参照元 — SOURCE TRAIL

根拠と関連教材

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

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

現在の実装 — CURRENT IMPLEMENTATION — Primary Sourcesrc/lib/config/paymentBackend.tsgetPaymentBackend切替の許容値・default・不正値拒否。稼働環境の値はUNKNOWN。
現在の実装 — CURRENT IMPLEMENTATION — Primary Sourcesrc/services/TransferService.tsrequestTransfer / confirmTransferOtp / reissueTransferOtprequest/confirmのみbackend切替。残存createTransfer関数のコメントは現ACLの根拠にしない。
現在の実装 — CURRENT IMPLEMENTATIONsrc/services/JavaPaymentBackend.tsJavaへのHTTP adapterとエラー処理。自動fallbackなし。
現在の実装 — CURRENT IMPLEMENTATIONservices/payment-service/pom.xmlJava 21とSpring Bootの構成
現在の実装 — CURRENT IMPLEMENTATIONservices/payment-service/src/main/java/com/minibank/payment/domain/Money.java型と不変条件を結ぶ値オブジェクト
現在の実装 — CURRENT IMPLEMENTATIONservices/payment-service/src/main/java/com/minibank/payment/application/PaymentApplicationService.javaJavaとDB transaction境界の分離
関連教材 — RELATED LESSON/docs/java-minibank-architecture関連教材の入口。Java基礎からArchitectureまでの詳細教材

このページで学ぶこと

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

まず、ここだけつかむ

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

Java経路の実装と稼働確認を分ける

Javaは4つの要素で考える

金融システムで有力な選択肢になる理由

JVMが運用で見せるもの

Javaで起こり得る失敗

MinibankのJava 21を読む

画面操作なしで、仕組みを確かめる

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

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

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

3問で理解チェック

業界資料・参考文献

根拠と関連教材