BEGINNER · 入門COURSE 01 · FOUNDATION

Minibank全体の仕組み

振込ボタンを押してから、安全に記録されるまで。まずは技術名を使わず、登場人物と仕事の流れで理解します。

02 / 06

FOUNDATION · 基礎

Minibank全体の地図、システム開発の基本、学び方の土台を作る。

先に学ぶ内容 — Prerequisite: なし

学ぶこと — LEARNING GOALS

このページで学ぶこと

システムを動かす5つの登場人物
「見る」と「お金を動かす」の違い
途中で失敗しても残高が壊れない理由

体験01 · ARCHITECTURE（全体の仕組み）

画面の表示と、お金の記録を見比べよう

まずは予想をひと言。本文を読んだ後、画面を観察して、記録の役割を自分の言葉で説明します。専門用語は後から確認できます。

体験学習 · STEP 1 / 5

01
まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
画面に「振込成功」と出たら、それだけでお金が正しく動いたと確かめられるでしょうか？ほかに何を見たいですか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
あなたの予想（5文字以上）
ヒント1を見る
画面に表示された数字を、どの記録と見比べたら確かめられるでしょう？
ヒント2を見る
「いくら動いたか」と「誰が操作したか」は、同じ問いでしょうか？
もっと詳しく：この問いで使う専門用語
- UI（利用者が見る画面）は、入力と結果表示の入口です。
- API（処理を依頼する窓口）は、画面から届いた依頼を受け渡します。
- DB（データベース）は、記録を保存する場所です。
- Ledger（会計台帳）は、お金が動いた根拠となる正式な会計記録です。
- Audit（監査証跡）は、誰がいつ何をしたかを追う記録です。
- System of Record（正式な正本データ）は、正しさを判断する基準となる記録です。

ARCHITECTURE FOR BEGINNERS

まずは、5人の仕事として見る

技術名はまだ覚えなくて大丈夫です。「誰が、どこで、何を確認するか」だけを上から追ってください。

Browser

あなたの画面

『残高を見たい』『振込したい』と伝える

Next.js

Webの受付

入力を受け取り、正しい窓口へ案内する

Supabase Auth

本人確認係

ログインした人が誰なのかを確かめる

PostgreSQL

銀行の事務室

実行してよいか、金額と状態が正しいかを最終判断する

Ledger / Audit

消せない記録

お金の動きと操作者を、後から説明できる形で残す

ONE TRANSFER STORY

振込情報を入力してから履歴へ残るまでの10場面

下へ進むほど、利用者から見えない銀行内部の仕事になります。

1
振込情報を入力する
送金先口座、金額、依頼人名、メモを入力します。画面の値はまだ信用されません。
2
Webの受付が本人と入力を確認する
Bearer token、Idempotency-Key、入力形式を検証してDBの振込依頼窓口へ渡します。
3
DBが振込依頼を作る
本人・KYC・両口座を確認し、送金先の正式な名義を解決します。この時点ではお金を動かさず、確認コードも作りません。
4
あなたが振込内容を確認する
DBから返された銀行・支店・預金種目・口座番号・名義・金額を見て、認証アプリのコード入力へ進みます。
5
この振込にだけ使える認可を得る
認証アプリのTOTPをブラウザがSupabase Authへ直接送ります。DBは振込内容とsessionに束縛したintent、試行回数・期限、Auth側の検証記録を確認し、認可を1回だけ消費します。
6
DBが関係する2口座へ一時的に鍵をかける
認可を消費した後、別の振込が同じ残高を同時に使わないようにします。
7
DBが送金条件をもう一度確認する
口座状態、KYC、冪等性、Ledger残高、金額と頻度の上限をlock後に再確認します。
8
4種類の記録をまとめて作る
取引記録・会計台帳・表示用残高・監査記録を、1つの資金移動として作ります。
9
全部成功したときだけ資金移動を確定する
1つでも失敗すれば資金移動部分を元に戻し、送金元だけ減る途中状態を残しません。
10
履歴と管理監視へ結果を返す
顧客は完了取引を履歴で確認し、管理者は認証待ち・失敗・期限切れを含む依頼状態を監視できます。

TWO ROADS

「見る」と「動かす」は、危険度が違う

見る

残高・口座・履歴

本人のデータだけを選び、必要な情報だけ画面へ返します。

主な守り：RLS（他人の行を見せない規則）

動かす

振込・KYC・管理操作

お金や状態が変わるため、本人・権限・現在状態・重複・残高をまとめて確認します。

主な守り：専用RPC、lock、transaction、監査

REMEMBER ONLY THESE

最初に覚えるのは、この3つだけ

1
画面を信用しすぎない
画面は書き換えられるため、本人と内容をサーバー・DBで確認します。
2
お金の最終判断はDBで行う
残高や台帳を持つ場所が、権限・状態・金額も同じ瞬間に確認します。
3
途中まで成功させない
金融更新をまとめて確定・取消します。依頼状態や失敗記録を残す範囲は区別します。

MANY TRANSACTIONS AT ONCE

大量の取引が同時に来たら、どうなる？

金融システムは「1件が正しく動く」だけでは足りません。給料日や障害後の再送で、大量の依頼が重なっても金額を壊さないことが必要です。

1大量の依頼が到着

同じ時刻に多数の振込や照会が届きます。通信失敗による再送も混ざります。

2重複を見分ける

idempotency keyで、同じ依頼を何度受けても送金は1回にします。

3口座ごとに順番を守る

同じ口座へ触る処理はlockで競合を防ぎ、別口座の処理は並行して進めます。

4短時間で確定

1件ごとのtransactionを短く保ち、全部成功または全部取消にします。

二重送金を防ぐ

retryや二重クリックは冪等性で同じ結果へまとめます。

残高の取り合いを防ぐ

残高確認の前に行をlockし、古い残高を同時利用させません。

deadlockを減らす

複数口座の鍵を、常に決められた順番で取得します。

最後はDBが守る

同時実行でも一意制約・会計制約・transactionを適用します。

TRUST IS AN OPERATIONAL OUTCOME

銀行の「信用」は、正しいコードだけでは作れない

利用者から見た信用とは、残高が正しいことに加え、必要なときに使え、異常を早く見つけ、復旧でき、何が起きたか説明できることです。

正確性金額を壊さない

複式記帳・制約・transaction

可用性必要なときに使える

監視・容量管理・冗長化

回復性壊れても戻せる

backup・復旧訓練・手順

検知力異常に早く気づく

observability・alert・照合

説明力後から証明できる

台帳・監査・incident記録

安定稼働は、毎日の循環で維持する

観測
エラー率、遅延、DB接続、lock待ち、照合結果を見る
検知
通常と違う状態をalertで担当者へ知らせる
対応
影響を止め、手順に沿って切り分け・復旧する
検証
台帳・残高・監査を照合し、正しく戻ったか確認する
改善
原因と対応を記録し、設計・監視・訓練へ反映する

ここから先は発展技術名を使った詳しい構成図を見るRLS・RPC・schema・transactionを理解したくなったら開いてください

REQUEST PATHS

技術名で見る、読み取りと書き込み

READ残高・口座・履歴を見る

1
Server Componentserver側でsessionを取得
2
Supabase clientcallerのtokenで接続
3
Table / read RPCRLSまたは専用wrapper
4
最小response必要な列だけ画面へ返す

WRITE振込・KYC・管理操作

1
Route Handler入力形式を検証
2
Supabase Authtokenから本人を確定
3
Service → public RPC振込request/confirmはlegacy/javaを選択。caller tokenを維持
4
DB内で再認可uid・role・状態・残高
5
atomic commit金融更新rollback／外側で失敗状態を保存

DATABASE ROOMS

schemaは、DB内の部屋分け

外から入れる受付はpublicだけです。会計・管理・監査の部屋へ直接入れないようにします。

外部向け窓口public

customersbank_accountstransfers公開RPC

許可された関数だけが内部へ進む

core

金融処理の内部手順

ledger

会計台帳と仕訳

admin

管理者と管理操作

audit

操作の監査記録

reconciliation

不整合の検査結果

ops

管理画面向けの読み取り

ALL OR NOTHING

transactionは「全部成功」か「全部取消」

1回の振込同じtransactionの中

01本人・入力
02口座lock
03状態・残高
04会計仕訳
05取引記録
06表示残高
07監査記録

どこか1つでも失敗→ すべて処理前へ戻す

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

金融更新を戻す範囲と、失敗後に残す記録

金融更新の仕訳・transfers・残高cache・成功audit（TRANSFER_COMPLETEDと内側の変更trigger）は、confirm_transfer_otpの内側の例外blockでまとめてrollbackします。先に保存済みのrequestは消えません。transfer_auth.consumeによる認可済みintentの消費（consumed_at）、request=failed、TRANSFER_FAILEDは内側のrollbackの対象外で、外側のDB transactionがcommitすると残ります。

TOTPコードの正誤はDBではなくSupabase Authが判定します。DBはNext.jsのtransfer_mfa_broker経由で検証前に試行を予約し、その時点でintentのattemptsを加算します（累積5回まで、間隔30秒以上）。認証に失敗しても変わるのはintentとAuth側の状態だけで、requestはpending_otpのまま、金融データも変わりません。新しい認可がないままconfirmすると、transfer_auth.consumeが42501で拒否し、その呼出し全体がrollbackします。request=failedは金融更新の例外を捕捉した経路です。未捕捉例外・deferred constraint・commit自体の失敗なら、その呼出し全体の変更がrollbackするため、失敗記録の永続化を無条件には保証しません。

場面	金融更新	外側commit後の状態・event
依頼作成	まだ記帳しない	pending_otp、TRANSFER_OTP_REQUESTED（event名は従来のまま）。確認コードは生成しない
TOTPの誤入力・Auth検証失敗	資金移動に入らない	予約時点でintent.attemptsが加算済み（累積5回まで）。requestはpending_otp
新しい認可なしのconfirm（未認可・60秒超過・別session・内容変更）	consumeが42501で拒否し、その呼出し全体をrollback	requestはpending_otp、intentは未消費のまま
認可後の資金移動で捕捉した例外	内側の仕訳・transfer・cache・成功auditをrollback	intent消費済み、request=failed、TRANSFER_FAILED
成功	金融更新と成功auditを保存	request=completed、transfer_id、intent消費済み
外側transaction/commit失敗	その呼出し全体をrollback	その呼出しの失敗eventも保証しない。過去のcommit済み依頼とは別

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しない

読み取りと書き込みの2つの経路

MinibankはNext.js、Supabase Auth、PostgREST、PostgreSQLで構成されています。ただし、残高を見る処理と振込を実行する処理では、DB側の入口が異なります。

経路	入口	DB側の主な防御
読み取り	Server Component → Supabase client → table / read RPC	RLS、専用read wrapper、列の絞り込み
書き込み	Form → Route Handler → Service → business RPC	auth.uid()、状態検査、locking、constraint、transaction、audit

schemaで責務を分ける

schema	役割	Data API
public	顧客・口座・公開RPCの境界	公開対象。ただしRLSと権限で制限
ledger	勘定科目・仕訳	非公開
core	入出金・手数料・逆仕訳の内部処理	非公開
admin	管理者と冪等リクエスト	非公開
audit	監査ログ	非公開
reconciliation	整合性検査結果	非公開
ops	管理画面向け集約・読み取り	内部実装

実際のMinibankでは

`src/proxy.ts` は `/app` と `/admin` のSupabaseセッションcookieを更新しますが、認可境界ではありません。Route HandlerはBearer tokenをSupabase Authで検証し、そのtokenを引き継いだrequest clientでDBへ接続します。顧客データはRLS、金融操作はSECURITY DEFINER RPCが最終判断します。

Banking Platform層（v8〜）：業務ごとに1つの管理RPC

v8以降の機能は、v7の顧客向け処理を置き換えずに、その上へ積み上げています。業務領域ごとに非公開schemaを1つ持ち、管理画面からの入口は `public.admin_<領域>(action, data)` という1本のRPCだけです。権限確認（`platform.require_operator`）はRPCの中で毎回行うため、画面やAPIを迂回しても同じ判定を受けます。

画面からの更新操作は共通のRoute Handler（`/api/v1/admin/platform/[domain]`）を通り、同一オリジン確認とIdempotency-Keyの付与を行ってからRPCを呼びます。

01顧客・管理者の操作
02Core Banking（v7：振込・入出金・定期預金）／Payment（v9：他行宛送金）
03Business Event（v8）
04Posting Engine（記帳ルールで仕訳化）
05Ledger（追記専用の仕訳と勘定）
06Interbank Simulator（v9：架空の決済システムと決済）
07Balance・Reconciliation（再計算・整合性検査・未決済送金の照合）
08Accounting（v10：GL・試算表・BS/PL・補助元帳照合・日次締め）
09AML（v11：台帳を後から読んで検知・ケース調査）
10Operations（v12：状態・キュー・追跡・インシデント）
11Treasury（v13：GLからのポジション・満期ギャップ・シナリオ・資金取引）
12管理コンソール（調査・照会・取消・訂正）

コンポーネント	責務	主なschema	実装version
Core Banking	顧客・口座・振込・入出金・定期預金	public / core	v7まで
Posting Engine	Business Eventの記帳、冪等性、取消・訂正	posting / accounting	v8
Ledger	仕訳・勘定・残高（System of Record）	ledger	v7まで（v8から共用）
Reconciliation	整合性検査の実行と結果保存	reconciliation	v7まで（v8で posting 検査を追加）
Payment / Interbank Simulator	他行宛送金の状態管理、架空の決済システム、決済・返却・照会	interbank	v9
Accounting / Closing	勘定科目表、GL・試算表・BS・PL、補助元帳照合、仮受金、日次・月次締め	gl	v10
AML / Fraud Simulator	取引モニタリング（台帳を読む）、アラート、ケース調査、判断・二次確認・上申	aml	v11
Operations Center	SYSTEM STATUS、例外・照合・AML・承認キュー（各業務から毎回計算）、原因追跡、インシデント・SLA	opscenter	v12
Treasury / ALM Simulator	GLからのポジション、満期別ギャップ、固定の架空市場シナリオでの流出・金利ショック試算、コール取引の記帳	treasury	v13
Lending / Credit	個人向け学習用融資：申込・審査の提案・別人の決裁・実行・日割利息・返済・延滞とデフォルト分類・専用の訂正。貸付金と預金を1つの仕訳で計上	lending	v14
Deposit & Pricing	預金商品の価格（金利・手数料・中途解約）の版管理、見積り、契約時の固定、普通預金の日次残高利息と月次手数料。契約と実行記録を仕訳から再計算して照合	pricing	v15
Open Banking Sandbox	架空の第三者アプリ向けの閉じた検証環境：OAuth（認可コード＋PKCE）、顧客の同意と即時の取消し、範囲つきの読取りAPI、振込の依頼（承認は顧客本人）、同意ごとのイベント列と模擬Webhook	openbanking	v16
Reliability / DR	書込停止（fence）・復旧の状態機械と二者確認・書込世代による旧 writer の遮断・バックアップ時点の記録（manifest）と復元後の検証・演習（RTO/RPO の測定）・復元後の訂正	recovery	v17
Enterprise Risk	信用・金利・流動性・オペレーショナルのリスクを、同じ凍結した入力から公開した式と架空のパラメータで計算し、基準とストレスを比較・再現し、対策案を決定として記録（元帳を書き換えない）	risk	v18
Group / Multi-Entity	架空のグループの複数の法人（entity）：entity ごとの独立した元帳と役割、2段階のグループ内資金移動と片側だけ確定した場合の扱い、相互勘定の照合、確定したスナップショットからの連結（消去は報告上の計算で、元帳を書き換えない）	bankgroup	v19
Bank Digital Twin	実績を凍結したベースラインと別の模型で、政策金利から預金価格・預金残高・調達コスト・貸出収益・Treasury/ALM・資金不足・予測BS/PL・リスクまでの因果を、シード値と明示した仮定で再現・比較（実績と予測を分離し、元帳には書き込まない）	twin	v20
Platform共通	管理者権限確認・追記専用保護・共通RPC入口	platform	v8

この設計で守っていること

UIを迂回してAPI/RPCを直接呼ばれても、DBがcallerと権限を再確認する
金融処理の途中で失敗しても、業務記録だけ・仕訳だけが残らない
顧客向けRLSと管理者向けRPCを混ぜず、データ面と制御面を分離する
private schemaをData APIへ露出せず、外部から直接ledgerやauditへ書かせない
constraintで予防し、reconciliationで保存済みデータを検出する

体験学習の続き · LEARNING LOOP

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

全体の仕組みを読んだところで、実際の画面・記録・コードを見て、最初の予想と見比べながら自分の言葉で説明してみます。

STEP 2〜5 / 5

02
実際に操作する — OPERATE
同じ仕組みを、動く画面から観察する
まず顧客画面を開いて観察し、この教材へ戻ります。リンクは新しいタブで開きます。ログインが必要です。
アカウントがない場合は新規登録が必要です。本人確認・口座開設には管理者承認が必要です。承認前や操作できない場合も、この教材内の図・説明・Source Trail（教材の参照元）で代替学習し、次へ進めます。
ログイン・新規登録の入口を開く ↗操作できない場合：教材の参照元で確認する ↓
利用者の画面 · MINIBANK顧客ダッシュボード ↗
表示された残高と、取引の入口を探してみましょう。
利用者の画面 · MINIBANK振込画面 ↗
入力から確認へ進み、どこで操作を確定するのか観察します。学習用のデモ情報を使います。
もっと詳しく：管理者の画面で観察する
管理者ログインが必要です。権限がない場合は、次の「証拠を確認する」の教材による確認で進められます。
Accounting Console（会計を確認する画面） ↗
会計台帳にある金額と、画面の残高のつながりを見ます。
Audit（監査記録） ↗
誰が、いつ、どの操作をした記録かを見ます。
03
証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
管理者画面を利用できない場合
この項目は教材内のSource Trailと解説で確認できます。実画面を開けなくても学習完了条件を満たせます。代替確認を行った場合は、下のチェックを入れて進めてください。
利用者に見える状態画面の残高と取引の表示を見て、金額を裏付ける記録が別に必要か考えます。確認先を開く ↗この記録の意味を確認する → 教材内「「見る」と「動かす」は、危険度が違う」へLedger（会計台帳）の状態同じ取引の借方と貸方（会計の左右の記録）が同額になっているかを見ます。確認先を開く ↗この記録の意味を確認する → 教材内「最初に覚えるのは、この3つだけ」へAudit（監査記録）の証拠誰が、いつ、何をしたかを見て、金額を記帳する会計台帳との役割の違いを確かめます。確認先を開く ↗この記録の意味を確認する → 教材内「銀行の「信用」は、正しいコードだけでは作れない」へIntegrity（記録の整合性確認）照合結果に記録の食い違いが示されているかを見ます。確認先を開く ↗この記録の意味を確認する → 教材内「大量の取引が同時に来たら、どうなる？」へ
04
コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
基本の順序は、画面 → API Route（依頼を受ける窓口）→ TransferService（処理をつなぐサービス）→ DB / RPC（記録の保存場所と、その処理の呼び出し）です。まず最初の2つを見て、続くサービスは「もっと詳しく」で確認します。
利用者が振込を入力し、確認コードを送る画面。まず入力と確認の役割を探します。
src/components/customer/TransferForm.tsx
API Route（依頼を受ける窓口）。入力を検査し、サービスへ渡します。
src/app/api/v1/transfers/request/route.ts
もっと詳しく見る：残りのファイルと処理の約束
API Routeから受け取った依頼と振込処理をつなぐサービス。依頼をどこへ渡すかを探します。
src/services/TransferService.ts
Migration（DB定義の変更履歴）。金融更新の権限と整合性を守る定義を確認します。
supabase/migrations/20260907102613_banking_authorization_and_integrity.sql
参照元のCURRENT IMPLEMENTATION（現在の実装）とHISTORICAL IMPLEMENTATION（過去の実装）を区別します。古い変更履歴だけでは現在の定義を判断できません。
教材の参照元を確認する — Source Trail ↓
05
自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
画面の「成功」以外に何を見れば、お金が正しく動いたか確かめられるでしょうか？金額の記録と、操作した人の記録について、短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
あなたの説明（20文字以上）
ヒント1を見る
最初の予想と、実際に確認した記録を比べてみましょう。
ヒント2を見る
「金額を確かめるには…」「操作した人を確かめるには…」と書き始めてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
UI（画面）、API（依頼の窓口）、DB（記録の保存場所）、Ledger（会計台帳）、Audit（監査証跡）の役割を結び付けて説明してみましょう。専門用語をすべて使う必要はありません。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint
- 画面の表示を、金額の根拠となる記録と見比べられる
- お金の記録と、誰が操作したかの記録を区別して説明できる

理解を確かめる — CHECK YOUR UNDERSTANDING

5問で理解チェック

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

Q1金融更新のrollbackで依頼や失敗記録も全部消えますか？

答え

Q2振込の確認コードは銀行が作って画面に表示し、DBに保存しますか？

答え

v7（migration 20260920074653と20260920083426）の振込認可は、Supabase Authの認証アプリTOTPを振込intentへ束縛する方式です。request_transferは確認コードを生成・返却せず（otp_plaintext列は応答互換のため残り、常にnull）、reissue_transfer_otpは常に42501で拒否します。prepare_transfer_mfaは所有者・Auth session・送金元・送金先・金額・memo・依頼人名・idempotency key・期限のhashをintentへ固定します。ブラウザはコードをSupabase Authへ直接送り、Next.jsとDBはコードも、そのhashも受け取らず保存もしません。DBはAuth所有のchallenge検証時刻、AAL2 session、同じsessionのTOTP AMRを読んで認可し、confirmは60秒以内の認可を1回だけ消費します。DEMO_OTP_DISPLAY_ENABLEDでDBのコード生成は復活しません。TOTPは時刻ごとの値で、振込先や金額への署名ではなく、フィッシング耐性も主張しません。稼働DBへの適用はこの教材ではUNKNOWNです。

Q3なぜ画面でボタンを隠すだけでは安全ではないのですか？

答え

利用者は画面を使わず、APIやRPCへ直接リクエストを送れるからです。最終的な認可はサーバーとDBで行う必要があります。

Q4金融操作の最終判断をする場所はどこですか？

答え

PostgreSQL内のRPC、RLS、権限、制約です。Next.jsは入口ですが、最後の防御線ではありません。

Q5振込途中で仕訳作成に失敗したらどうなりますか？

答え

金融更新の例外block内の変更がrollbackされ、取引記録や片側残高だけの成功を残しません。request=failed等は外側commit後に残ります。

ここまで読めましたか？

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

教材の参照元 — 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の認可方式の根拠にしない。
現在の実装 — 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 IMPLEMENTATIONsrc/proxy.tsproxy()セッションcookieの更新
現在の実装 — CURRENT IMPLEMENTATIONsrc/lib/auth/getAuthContext.tsrequireAuthContext()APIのBearer token検証
現在の実装 — CURRENT IMPLEMENTATIONsrc/lib/db/supabaseRequestClient.ts呼出者tokenを使うDB client
現在の実装 — CURRENT IMPLEMENTATIONsupabase/config.tomlData APIへ公開するschemaの設定
現在の実装 — CURRENT IMPLEMENTATIONsrc/app/api/v1/admin/platform/[domain]/route.tsPOST()v8〜の管理操作の共通入口
現在の実装 — CURRENT IMPLEMENTATIONsrc/domain/platform/request.tsPLATFORM_RPC到達できる管理RPCの許可リスト
現在の実装 — CURRENT IMPLEMENTATIONsupabase/migrations/20260930100000_v14_lending.sqlpublic.admin_lending / public.loan_customerv14の入口：管理用と顧客用を別のRPCに分け、所有者と権限をDBが判定
現在の実装 — CURRENT IMPLEMENTATIONsupabase/migrations/20260930110000_v15_pricing.sqlpublic.admin_pricing / public.pricing_customerv15の入口：価格の版・見積り・利息・手数料。承認は別の管理責任者
現在の実装 — CURRENT IMPLEMENTATIONsupabase/migrations/20260930120000_v16_open_banking.sqlpublic.ob_gateway / public.ob_tokenv16の匿名の入口：Bearerトークン、または認可コードとPKCE検証子をDBが検証。匿名が実行できるのはこの2つだけ
現在の実装 — CURRENT IMPLEMENTATIONsupabase/migrations/20260930180000_v20_digest_v3.sqlpublic.admin_recoveryv17の入口：復旧の状態・manifest・検証・演習・訂正・外に控える運用者の一覧（operators_list）。再開は提出者とは別の管理責任者
現在の実装 — CURRENT IMPLEMENTATIONsupabase/migrations/20260930140000_v18_risk.sqlpublic.admin_riskv18の入口：スナップショット・実行・比較・パラメータと対策案の決裁
現在の実装 — CURRENT IMPLEMENTATIONsupabase/migrations/20260930150000_v19_group.sqlpublic.admin_groupv19の入口：entity・役割・グループ内の移動・照合・スナップショット・連結
現在の実装 — CURRENT IMPLEMENTATIONsupabase/migrations/20260930170000_v20_freeze_hardening.sqlpublic.admin_twinv20の入口：ベースライン・シナリオ・実行・再計算・比較・感応度・実績との差・モデルの版の決裁