Business Rule Architecture：例外・Control・業務継続まで設計する
金融業務はhappy pathより、上限、期限、承認、再送、取消、例外処理、障害時の代替で信頼性が決まります。Ruleをcodeのif文から業務資産へ引き上げます。
Business・Application・Data・Technologyを横断し、全体最適の設計へ広げる。
先に学ぶ内容 — Prerequisite: 金融IT・信頼性学ぶこと — LEARNING GOALS
このページで学ぶこと
- Rule・Policy・Decision・Controlの違い
- 例外処理とCase Management
- 重要業務の耐性度と代替手段
体験51 · BUSINESS RULES / RESILIENCE（例外まで設計する）
業務ruleはコード内のif文として書かれていれば十分に管理されているか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際のrule実装とcase管理を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
業務ruleはコード内のif文として書かれていれば、それで十分に管理されていると思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
if文だけでは、owner・根拠・適用日・versionを誰が確認できるでしょうか？
ヒント2を見る
例外(照合差異など)は、誰がどう処理すべきでしょうか？
もっと詳しく：この問いで使う専門用語
- Decision Modelは、入力条件から業務判断と理由を導く構造です。
- Case Managementは、自動処理できない案件を人が情報と履歴を見て解決する仕組みです。
- Impact Toleranceは、重要業務がどこまで中断・劣化してよいかの上限です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
Business Ruleは文章で保存するだけでなく、判断入力、結果、例外、証拠、変更権限まで設計します。
正常処理だけでなく、保留、手動審査、取消、訂正、外部停止、期限切れを業務状態として扱います。
Business Resilienceはsystem復旧だけでなく、重要業務を許容範囲で続け、顧客影響を管理する能力です。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Decision Model
入力条件から業務判断と理由を導く構造です。
ruleを一貫してtestし、説明し、変更影響を確認するためです。
残高、上限、KYC、OTP、beneficiaryから振込可否を決めます。
Case Management
自動処理できない案件を人が情報と履歴を見て解決する仕組みです。
現実の例外を裏口操作や口頭連絡で処理しないためです。
照合差異やreversal調査をcaseとして管理する考え方です。
Impact Tolerance
重要業務がどこまで中断・劣化してよいかの上限です。
復旧優先順位と代替手段を顧客影響から決めるためです。
振込受付停止時間と未確定取引の許容量を定義します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
Ruleを分類する
Ruleへowner、根拠、適用日、version、優先順位、例外、testを持たせます。文言だけ変更して過去取引の再現性を失わないよう、取引時のrule versionや計算結果を保存します。
| 種類 | 例 | 実装候補 |
|---|---|---|
| Eligibility | KYC verifiedのみ振込可能 | DB predicate、policy |
| Calculation | fee・interest・limit | versioned rule、calculation service |
| State transition | pendingからcompletedのみ | state machine、constraint |
| Authorization | ownerだけOTP確認可能 | policy、RLS、RPC |
| Accounting | eventから借貸を生成 | accounting rule engine、DB function |
| Operational | 差異時に振込停止 | alert、feature control、runbook |
DecisionとControlを分ける
- 01Policy：未確認顧客の資金移動を禁止
- 02Decision：この顧客は現在verifiedか
- 03Action：振込を受付または拒否
- 04Control：DBがcallerと状態を再確認
- 05Evidence：判定時刻・actor・reasonをaudit
- 06Assurance：testとmonitoringでcontrol有効性を確認
例外をsystem外へ追い出さない
Excel、email、口頭だけで例外を処理すると、stateとauditがsystemから切れます。例外もlifecycle、owner、SLA、権限、証拠を持つ業務objectです。
| 例外 | 必要なCase情報 |
|---|---|
| 重複疑い | request、fingerprint、既存結果、判断者 |
| 照合差異 | 対象記録、金額、severity、原因、resolution |
| 組戻し | 原取引、理由、承認、reverse journal |
| 不正疑い | signal、凍結、顧客連絡、証拠保全 |
| 外部停止 | 滞留件数、cutoff、再開順序、顧客影響 |
Business resilience
Minibankではtransactionの原子性は学べますが、業務継続の代替channel、当番、顧客連絡、外部清算は未実装です。Business Architectureはtechnology冗長化より先に守る業務を決めます。
- 01重要業務と最低serviceを定義
- 02人・場所・application・data・technology・providerをmap
- 03中断耐性と最大未処理量を設定
- 04縮退運転・手作業・受付停止を設計
- 05scenario testで実行可能性を確認
- 06復旧後に取引とLedgerを照合
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Decision ModelとCase Managementの考え方を読んだところで、教材内の参照元で実際のrule実装とcase管理を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まず振込serviceが持つ業務ruleを見て、次に例外がどう人の確認へつながるかを見ます。
教材の参照元を確認する — Source Trail ↓振込serviceと業務rule。
src/services/TransferService.ts例外検知と管理導線。
src/app/admin/(protected)/integrity/page.tsx - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜ業務ruleにはowner・根拠・適用日・versionを持たせる必要があるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Decision Model」という言葉を使って書いてみましょう。
ヒント2を見る
ruleをコードだけに置くと業務担当者が何に困るか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Decision Model、Case Management、Impact Toleranceの3つを使って、業務ruleが単なるコードを超える理由を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- ruleにはowner・根拠・versionが必要だと説明できる
- 例外は正式なcase処理として扱われるべきだと説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1業務ruleをcodeだけに置く問題は何ですか？
業務担当が検証しづらく、根拠、変更権限、例外、証拠が見えなくなります。
Q2例外は管理者がDBを直せば解決ですか？
危険です。承認、状態遷移、追記記録、顧客影響、照合を持つ正式processが必要です。
Q3Business Resilienceの起点は何ですか？
重要業務、顧客成果、Impact Tolerance、依存関係の特定です。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- 金融庁 — 金融機関のITガバナンスに関する論点・プラクティス
経営戦略、IT戦略、DX戦略、次世代architecture、投資・risk・人材の統合
- BIAN — Service Landscape
銀行業務capabilityをService Domainとして整理する業界参照構造
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 現在の実装 — CURRENT IMPLEMENTATION
src/services/TransferService.ts振込serviceと業務rule - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/状態・認可・会計control - 現在の実装 — CURRENT IMPLEMENTATION
src/app/admin/(protected)/integrity/例外検知と管理導線