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

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

ミニ銀行ACADEMY SYSTEM LEARNING
銀行システムをコードから学ぶ銀行デモへ
教材メニュー
学習進捗0 / 134
あと134項目
INTERMEDIATE · 中級COURSE 06 · FINANCIAL IT / RELIABILITY

業務設計：コードより先に銀行業務の正しさを決める

金融システムの品質は、要件どおりにコードを書く前に、誰が・何を・どの状態で・どの証拠を残して行うかを設計できているかで大きく決まります。

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

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

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

学ぶこと — LEARNING GOALS

このページで学ぶこと

  • 業務設計と画面設計の違い
  • 正常系・例外・取消・締め・人手対応の設計
  • 業務ルールを状態・権限・会計・監査へ翻訳する方法

体験40 · FINANCIAL BUSINESS DESIGN（画面より先に決める）

業務設計は、画面の項目やレイアウトを決める作業か確かめよう

まずは予想をひと言。本文を読んだ後、教材内の参照元で実際の状態遷移と例外経路を確認します。

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

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

    業務設計は、画面のレイアウトや入力項目を決めることだと思いますか？

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

    ヒント1を見る

    画面を経由しないAPIやbatchでも、同じ業務ruleは守られるでしょうか？

    ヒント2を見る

    『安全に振り込む』をtestできる条件に直すとどうなるでしょうか？

    もっと詳しく：この問いで使う専門用語
    • 状態機械は、現在の状態ごとに許可する次の操作を決めます。
    • 不変条件は、どの経路でも絶対に破ってはいけない条件です。
    • 業務例外は、自動処理だけでは終えられない状況です。
まずはひと言だけで大丈夫です。

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

日常語で理解する — PLAIN LANGUAGE

まず、ここだけつかむ

1

業務設計は画面項目を決める作業ではなく、誰が、どの条件で、何を確定し、どの証拠を残すかを決める作業です。

2

正常系だけでなく、再送、競合、取消、訂正、締め、外部停止、照合差異、人手対応を設計します。

3

業務ruleを状態機械、不変条件、権限、会計、監査、運用へ翻訳し、同じ条件をtest可能にします。

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

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

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

01

状態機械

やさしく言うと

現在の状態ごとに許可する次の操作を決めます。

なぜ必要？

完了済み取引を再実行するなど不正な遷移を防ぐためです。

Minibankでは

OTP待ちからcompletedやexpiredへ進む条件があります。

02

不変条件

やさしく言うと

どの経路でも絶対に破ってはいけない条件です。

なぜ必要？

画面・API・batchが増えても金融上の正しさを守るためです。

Minibankでは

借貸一致、二重送金なし、他人の口座を操作しないことです。

03

業務例外

やさしく言うと

自動処理だけでは終えられない状況です。

なぜ必要？

現実には組戻し、照合差異、外部停止、問い合わせが起きるためです。

Minibankでは

Integrity issueを管理者が確認する経路があります。

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

業務設計は『画面に何を置くか』ではない

業務設計では、顧客・行員・外部機関・systemがどの責任を持ち、何を受け付け、どの条件で確定し、失敗・取消・訂正・問い合わせへどう対応するかを決めます。

画面はその一部です。画面を迂回したAPI、夜間batch、外部からの結果通知、管理者操作、障害復旧でも同じ業務ルールを守る必要があります。

設計対象決める問い振込の例
Actor誰が依頼・承認・取消・閲覧できるか顧客、管理者、外部銀行、運用担当
State何をもって受付・実行・完了・失敗かrequested、OTP待ち、completed、failed
Rule金額・期限・回数・口座状態の条件は何か残高、KYC、上限、OTP期限
Evidence後から何を説明できる必要があるかrequest、判定、仕訳、audit、response
Exception自動処理できない時に誰がどう扱うか重複疑い、組戻し、照合差異

1件の取引を6つの視点へ翻訳する

  1. 01利用者価値：何を実現する取引か
  2. 02状態機械：許可する状態と遷移は何か
  3. 03不変条件：絶対に破れない条件は何か
  4. 04Accounting：どの業務eventで何を記帳するか
  5. 05Authorization：誰がどの対象へ操作できるか
  6. 06Operations：異常をどう検知し、止め、復旧するか

例外系が業務の本体になる

状況業務上の問い
応答が返らない受付済みか、再送してよいか、結果照会できるか
残高が処理中に変わるどの時点で確保・再確認するか
外部先が停止受付を止めるか、保留するか、いつ失効するか
誤った取引削除せず、どの承認でreversalするか
照合が不一致自動停止範囲、調査owner、顧客影響は何か
締め時刻を越えるbusiness dateとvalue dateをどう扱うか

業務部門と技術部門の共同成果物

業務部門だけでは実装上の競合や障害を見落とし、技術部門だけでは契約・会計・顧客対応を誤る可能性があります。共同で決め、同じ成果物をtestと運用へつなぎます。

  • 用語と金額・日付・状態の定義
  • 業務フローとsequence diagram
  • 状態遷移表と権限matrix
  • 会計rule・仕訳例・照合rule
  • 正常・異常・取消・再送のacceptance criteria
  • 手作業、二者承認、escalation、runbook
  • 法令・規程・顧客説明とのtraceability

Minibankで設計を追う

Minibankの振込では、request_transfer、OTP、execute_transfer、Ledger、Auditが別の責任を持ちます。教材ではコード名を覚えるだけでなく、どの業務事実がどこで確定するかを追います。

1回50万円・JST日次100万円の振込上限と内部取引の取消仕訳は実装済みです。一方、外部決済や他行への組戻しなど未実装の領域は、画面だけ先に作らず、状態・会計・認可・運用を先に定義する必要があります。

体験学習の続き · LEARNING LOOP

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

状態機械と業務例外の考え方を読んだところで、教材内の参照元で実際の状態遷移と例外経路を確認し、自分の言葉で説明してみます。

STEP 2〜5 / 5
  1. 02
    仕組みを確かめる — CONCEPT CHECK

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

    この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。

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

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

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

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

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

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

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

    まず状態遷移がどう制限されているかを見て、次に例外がどう人の確認へつながるかを見ます。

    振込の状態遷移とルールを定義するmigration履歴。

    supabase/migrations/

    業務例外を人が確認する画面の実装。

    src/app/admin/(protected)/integrity/page.tsx
    教材の参照元を確認する — Source Trail ↓
  4. 05
    自分の言葉で説明する — EXPLAIN

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

    なぜ業務設計では、正常系だけでなく再送・競合・取消といった例外系を先に決める必要があるのでしょうか？ 短い2文を目安に説明してください。

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

    ヒント1を見る

    「状態機械」と「業務例外」という2つの言葉を使って書いてみましょう。

    ヒント2を見る

    正常系だけを決めて例外系を後回しにすると何が困るか考えてみましょう。

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

    状態機械、不変条件、業務例外の3つを使って、業務設計がなぜ画面設計より広い活動なのかを説明してみましょう。

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

    説明の確認ポイント — Checkpoint
    • 業務設計は画面より広い範囲を扱うと説明できる
    • 例外系も検証可能な条件へ翻訳する必要があると説明できる
予想5文字以上・証拠2項目・説明20文字以上で完了できます。

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

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

理解を確かめる — CHECK YOUR UNDERSTANDING

3問で理解チェック

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

Q1画面仕様が完成すれば業務設計も完成ですか？
答え

いいえ。API、batch、管理操作、会計、監査、障害対応も含めます。

Q2『安全に振り込む』はtest可能な要件ですか？
答え

不十分です。二重処理数、借貸一致、権限など検証可能な条件へ具体化します。

Q3誰が業務設計を行いますか？
答え

業務・技術・security・会計・運用などが共同で決めます。

ここまで読めましたか？

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

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

業界資料・参考文献

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

教材の参照元 — SOURCE TRAIL

根拠と関連教材

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

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

  • 現在の実装 — CURRENT IMPLEMENTATION — Primary Sourcesupabase/migrations/20260920074653_transfer_totp_intent_authorization.sqlpublic.request_transfer / public.confirm_transfer_otp / public.reissue_transfer_otp / public.prepare_transfer_mfa#128。依頼は確認コードを生成せずotp_plaintext=null。confirmはtransfer_auth.consumeで認可済みintentを消費してからexecute_transferを呼ぶ。reissueは常に42501。稼働DBへの適用はUNKNOWN。
  • 現在の実装 — CURRENT IMPLEMENTATION — Primary Sourcesupabase/migrations/20260920083426_require_fresh_totp_on_intent_session.sqlpublic.transfer_mfa_broker#129。intentのAuth session自身に、予約・検証より後のTOTP AMRを要求する最新broker定義。
  • 現在の実装 — CURRENT IMPLEMENTATION — Primary Sourcesupabase/migrations/20260920115556_scalar_journal_posting_atomic_cache.sqlpublic.execute_transfer最新定義。ledger.post_journal_entryの戻り値をscalar uuidで受ける。検証・lock・上限・冪等性は従来どおり。既存ACLは維持。
  • 現在の実装 — CURRENT IMPLEMENTATIONsrc/app/api/v1/transfers/mfa/route.tsintent準備・challenge束縛・試行予約・認可完了のserver入口。TOTPコードは受け取らない。
  • 現在の実装 — CURRENT IMPLEMENTATIONsrc/components/auth/TransferMfa.tsxブラウザがSupabase Authへchallenge/verifyを直接送る部分。成功の自己申告は認可にならない。
  • 現在の実装 — CURRENT IMPLEMENTATIONsrc/app/api/v1/transfers/route.ts認証済みの旧直接振込入口はOTP_REQUIREDを返す。
  • 現在の実装 — CURRENT IMPLEMENTATIONsrc/lib/errors/apiError.tsOTP_REQUIREDのHTTP statusは409。
  • 現在の実装 — CURRENT IMPLEMENTATIONscripts/mfa/intent-db.test.mjsintent束縛・回数/期限・単回消費・session検査のSQL受入test。Auth行はfixtureで、実Authの証明ではない。当日のPASSも意味しない。
  • 過去の実装 — HISTORICAL IMPLEMENTATIONsrc/lib/config/demoOtpDisplay.ts#128以前のデモコード表示フラグ。v7ではDBがコードを返さず、Productionでは常にfalse。
  • 過去の実装 — HISTORICAL IMPLEMENTATIONscripts/regression/suites/transferOtp.mjs#128以前のデモOTP（誤入力・再発行・期限）の回帰test。v7の認可方式の根拠にしない。
  • 関連教材 — RELATED LESSON/docs/transaction-design関連教材の入口。Domain Modeling、Transaction、API/DB境界の既存教材
  • 過去の実装 — HISTORICAL IMPLEMENTATIONsupabase/migrations/業務ルールを状態・制約・RPCへ翻訳した履歴
  • 現在の実装 — CURRENT IMPLEMENTATIONscripts/regression/業務条件を検証可能なtestへした例
  • 関連教材 — RELATED LESSON/docs/architecture関連教材の入口。振込・Ledger・Accounting・Operationsの既存教材