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

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

ミニ銀行ACADEMY SYSTEM LEARNING
銀行システムをコードから学ぶ銀行デモへ
教材メニュー
学習進捗0 / 134
あと134項目
ADVANCED · 発展COURSE 09 · BANKING ENGINEERING

銀行エンジニアリング Lab 09：Open Banking Lab（同意 → トークン → 読取り → 振込の依頼 → 取消し）

架空の家計簿アプリを自分で動かし、同意からトークン、読取り、振込の依頼、同意の取消しまでを通して確かめます。すべてローカルの閉じた環境で、外部への通信はありません。

40 / 55
BANKING ENGINEERING · 銀行エンジニアリング

v8以降に実装した台帳・記帳エンジンなどを実際に動かし、正常時と異常時の両方から銀行システムの構造を学ぶ。

Prerequisite: BANKING SYSTEM

LEARNING GOALS

このページで学ぶこと

  • PKCEと同意の流れを自分の操作で確かめる
  • 依頼だけでは資金が動かないことの確認
  • 取消しの即時性とイベント列

PLAIN LANGUAGE

まず、ここだけつかむ

1

架空の家計簿アプリを自分で動かし、同意からトークン、読取り、振込の依頼、取消しまでを通して確かめます。

2

依頼だけでは資金が動かないことと、取消しが即時に効くことを、自分の操作で確認します。

3

Webhookの乱れを再現して、アプリ側の処理を試します。

DIFFICULT PARTS, STEP BY STEP

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

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

01

閉じた環境

やさしく言うと

外部と通信しない検証用の環境です。

なぜ必要？

実在のアプリや口座に影響を出さないためです。

Minibankでは

ローカルのDBと、127.0.0.1で待ち受ける架空のアプリだけ。

02

取消しの即時性

やさしく言うと

取り消した次の呼び出しから使えなくなることです。

なぜ必要？

漏れたトークンの被害を止めるためです。

Minibankでは

トークンが毎回、同意とクライアントの状態を確認する。

03

受信者の振る舞い

やさしく言うと

通知の受け手の失敗や重複を模擬する設定です。

なぜ必要？

外部に通信せずに、障害時の動きを確かめるためです。

Minibankでは

OK／FAIL_ONCE／ALWAYS_FAIL／DUPLICATE／REVERSE_ORDER。

準備

ローカルの検証用DBに seed を投入し、実行環境と架空のアプリを起動します。架空のアプリは、ブラウザの戻り先として127.0.0.1のポートで待ち受けるだけの小さなプログラムです。

node scripts/local/platform-seed.mjs
node scripts/local/platform-runtime.mjs   # 別のターミナルで
OB_DEST=<bobの口座番号> node scripts/local/ob-client.mjs   # 別のターミナルで

演習

演習操作観察すること
1. 同意画面alice でログインし、http://localhost:3999/start?scope=... を開く求められた範囲が平易な文で並ぶ。振込を含めると、承認は顧客が行うという注意が出る
2. 許可『許可する』を押すアプリが認可コードを受け取り、トークンに交換して口座・残高・取引を読む
3. 依頼アプリの結果ファイルで transfer.initiate を見るPENDING_CUSTOMER_APPROVAL。alice の残高は動いていない。同じキーの再送は同じ依頼を返す
4. 取消し外部アプリ連携で『許可を取り消す』直後に、以前のトークンで呼ぶと401（invalid_token）
5. 停止管理者がアプリを停止する全員の同意とトークンが即座に使えなくなり、新しい連携もできない
6. Webhook購読の振る舞いを『最初の1回だけ失敗』にして配信を2回実行1回目は失敗、2回目で配信。DEADにするには『常に失敗』で6回実行

振り返り

  • 認可コードを2回使うと何が起きたか。なぜ最初のトークンまで失効させるのか
  • アプリが振込を依頼しても資金が動かないのは、どの仕組みで守られているか

CHECK YOUR UNDERSTANDING

3問で理解チェック

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

Q1同意を取り消した直後に、以前のトークンでAPIを呼ぶとどうなりますか？
答え

401（invalid_token）になります。

Q2クライアントを停止すると、既存の同意は？
答え

すべて失効し、新しい連携もできません。

Q3DEADになった通知のイベントは失われますか？
答え

いいえ。イベント列に残り、events API で取得できます。

ここまで読めましたか？

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

SOURCE TRAIL

根拠と関連教材

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

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

Implementation Status: IMPLEMENTED IN MINIBANK（この教材が扱うコードの範囲）

  • RELATED LESSON/docs/be-openbanking-oauth-consent同意とトークン
  • RELATED LESSON/docs/be-openbanking-api-transfer資源APIと振込の依頼
  • RELATED LESSON/docs/be-openbanking-events-webhooksイベントとWebhook
  • CURRENT IMPLEMENTATIONsrc/app/admin/(protected)/open-banking/page.tsxOpenBankingPage()管理画面 Open Banking（表示は OpenBankingAdminView）
  • CURRENT IMPLEMENTATIONscripts/banking/v16-openbanking.test.mjs登録・認可・PKCE・コード再使用・スコープ・所有者検査・同意の失効・振込の依頼と確認・イベント/Webhook・秘密の非保存のDBテスト