口座振替・自動引落しの仕組み
毎月の料金が自動で引かれる裏側では、事前同意、請求data、引落し、結果返却、入金、再請求・顧客対応が別々の段階として動きます。
銀行ビジネスと主要商品を、利用者・銀行・会計の視点から理解する。
先に学ぶ内容 — Prerequisite: 基礎学ぶこと — LEARNING GOALS
このページで学ぶこと
- 振込と口座振替の違い
- 申込みから収納企業への入金までの流れ
- 残高不足・重複請求・取消へどう備えるか
体験23 · DIRECT DEBIT（未実装機能を正直に示す）
「新しい口座振替を登録」を押したら、本当に契約が作られるか確かめよう
まずは予想をひと言。本文を読んだ後、実際の画面でボタンを押して確かめます。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
口座振替の画面で「新しい口座振替を登録」ボタンを押したら、実際にmandate（同意契約）が1件作られると思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
画面に契約一覧が表示されているからといって、ボタンも同じように機能するとは限りません。
ヒント2を見る
画面上部に何か注記が表示されていないか、よく見てみましょう。
もっと詳しく：この問いで使う専門用語
- Mandateは、顧客が収納企業からの請求引落しへ事前に同意した登録です。
- Preview UIは、まだ実装されていない機能を「準備中」と正直に示す画面です。
- PreviewActionBarは、どのボタンを押しても同じ案内文を表示するだけで、実際のデータ変更をしないUI部品です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
口座振替は、顧客の事前同意に基づき、料金を受け取る企業が指定日に引落しを依頼する仕組みです。
申込み、請求data、引落し、結果返却、企業への入金は別段階で、残高不足などの失敗結果も業務として扱います。
毎月同じように見えても請求は毎回別取引です。mandateと各請求のidentityを分けて、二重引落しと取消後請求を防ぎます。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Mandate
誰が、どの口座から、どの収納企業の請求を引くことへ同意したかという登録です。
収納企業側から始まる引落しに正当な根拠を持たせます。
mandate modelは未実装です。
Billing instruction
引落日、金額、顧客番号を指定する1件の請求です。
継続契約そのものと、毎月の具体的な請求を区別します。
請求batchと明細は未実装です。
Result code
成功、残高不足、契約なしなど処理結果を表すcodeです。
収納企業が再請求や顧客連絡を正しく分岐できます。
口座振替結果codeはありません。
Three-level idempotency
file、batch、明細の各単位で同じ送信を識別します。
大量fileの再送で一部だけ二重処理される事故を防ぎます。
振込単位のidempotencyはありますが、収納batch用ではありません。
Feature preview UI
まだ実装されていない機能を、正直に「準備中」と示す画面の作り方です。
画面が存在することと、機能が実際に動くことを利用者に混同させないためです。
`FeaturePreviewNotice`と`PreviewActionBar`が、口座振替を実装済み機能と区別して表示します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
振込との一番大きな違い
| 比較 | 振込 | 口座振替 |
|---|---|---|
| 開始する人 | 支払う側がその都度指示 | 事前同意に基づき収納企業側が請求dataを出す |
| 利用場面 | 送金、請求書の支払い | 公共料金、通信、保険料、subscriptionなど反復請求 |
| 必要な契約 | 口座利用と振込指示 | 預金者・収納企業・金融機関を結ぶ口座振替契約・mandate |
| 失敗時 | 依頼時にerrorが分かる場合が多い | 後日、残高不足などの振替結果が返る |
| 再処理 | 支払者が再振込 | 収納企業が再請求、請求書、別手段を案内 |
1回の引落しを時間順に追う
- 01顧客が口座・収納企業・対象契約を指定して振替へ同意する
- 02金融機関がmandateを登録し、有効性と本人を確認する
- 03収納企業または収納代行会社が請求日・金額・顧客番号をまとめる
- 04締切までに金融機関networkへ請求dataを送る
- 05引落日に口座状態・残高・mandate・重複を確認する
- 06成功なら顧客口座を引落し、失敗なら理由codeを記録する
- 07各金融機関の結果を集約して収納企業へ返す
- 08成功分を収納企業へ入金し、件数・金額・結果を照合する
- 09失敗分は再請求または顧客案内へ回す
systemが持つ主なdataと状態
| data | 例 | 守ること |
|---|---|---|
| Mandate | 預金者、口座、収納企業、契約番号、有効期間、状態 | 同意の証拠、変更履歴、取消後の利用禁止 |
| Billing instruction | 請求日、金額、顧客番号、受付番号 | 同じ請求の重複排除と内容改ざん防止 |
| Debit attempt | 受付・処理中・成功・失敗と理由 | 再実行と最終状態を区別する |
| Settlement | 成功件数、合計金額、入金先、手数料 | 明細合計と入金額を照合する |
| Exception | 残高不足、口座なし、契約なし、停止、data不備 | 利用者向け案内と内部原因を分ける |
事故を防ぐ設計
- 収納企業・顧客・mandateの組合せをDBで検証し、別契約の口座を使わせない
- 請求単位のidempotency keyと内容fingerprintで二重引落しを防ぐ
- 同じ口座への大量引落しでは、lock・順序・残高policyを明確にする
- 残高不足を技術障害と混ぜず、再請求回数と顧客通知を業務ruleにする
- mandate取消と請求data到着が競合した時の基準時刻を決める
- 引落明細、Ledger、結果file、収納企業への入金を毎回照合する
- 手作業訂正は二者承認・理由・前後値・auditを必須にする
実際のMinibankでは
Minibankに口座振替、mandate、収納企業、請求batch、振替結果file、再請求は実装されていません。現在あるdeposit・withdrawal・transferを組み合わせても、口座振替productにはなりません。
顧客画面には`/app/direct-debits`という将来機能を想定したpreview画面があります。「Preview / 実装準備中」の表示とともに固定のsample dataを見せますが、登録boardのbuttonを押しても実際の申込みは作成されません。
ただし、既存のtransaction、Ledger、idempotency、row lock、audit、reconciliationは、将来この機能を設計する際の基礎原則になります。実装するなら専用の業務modelと状態機械を追加し、既存withdrawal RPCの直接流用は避けるべきです。
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
口座振替の仕組みを読んだところで、実際の画面でボタンを押し、自分の言葉で説明してみます。
- 02実際に操作する — OPERATE
同じ仕組みを、動く画面から観察する
実際の顧客画面を開いて操作し、この教材へ戻ります。リンクは新しいタブで開きます。ログインが必要です。
アカウントがない場合は新規登録が必要です。本人確認・口座開設には管理者承認が必要です。承認前や操作できない場合も、この教材内の図・説明・Source Trail（教材の参照元）で代替学習し、次へ進めます。
ログイン・新規登録の入口を開く ↗操作できない場合：教材の参照元で確認する ↓もっと詳しく：管理者の画面で観察する
管理者ログインが必要です。権限がない場合は、次の「証拠を確認する」の教材による確認で進められます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まずpreview画面自体を見て、次にボタンを押した時の実装を見ます。画面の反応と実際のデータ変更が一致しているかを確かめましょう。
教材の参照元を確認する — Source Trail ↓口座振替のpreview画面本体。固定sample dataと登録ボタンを探します。
src/app/app/direct-debits/page.tsxボタンのonClickが実際に何をしているかを探します。
src/components/common/PreviewActionBar.tsx - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜMinibankは、まだ実装されていない口座振替機能を非表示にせず、あえて「Preview / 実装準備中」という画面として見せているのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「画面が動く」と「機能が実装されている」という2つの言葉を使って書いてみましょう。
ヒント2を見る
なぜ非表示にせず、あえてpreview画面として見せているのか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Mandate、Billing instruction、Feature preview UIの3つを使って、口座振替の実装範囲とpreview画面の役割を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- ボタンを押しても実際の契約は作られないと確認できる
- 画面が存在することと機能が実装されていることは別だと説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
4問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1口座振替は顧客が毎月振込buttonを押す仕組みですか？
違います。事前同意に基づき収納企業側が各回の請求を提出します。
Q2引落し成功と収納企業への入金は必ず同時ですか？
限りません。結果集約・清算・入金に別の時刻があり得ます。
Q3残高不足はsystem障害ですか？
通常は業務上の失敗結果です。再請求や顧客案内へ正しく接続します。
Q4Minibankのwithdrawalを定期実行すれば口座振替になりますか？
なりません。mandate、収納企業、請求identity、結果返却、清算、例外業務が不足しています。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- 全国銀行協会 — 決済高度化ポータル
税金・公共料金を含む口座振替など企業決済の入門
- りそな銀行 — りそなネット
提携金融機関からの引落し、結果連絡、収納企業への入金flow
- 三菱UFJ銀行 — 口座振替サービス
収納企業からの大量data送信と結果downloadの実務例
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 現在の実装 — CURRENT IMPLEMENTATION
src/app/app/direct-debits/page.tsxpreview画面本体。固定sample dataとinert buttonのみ - 現在の実装 — CURRENT IMPLEMENTATION
src/components/common/PreviewActionBar.tsx全buttonが同じnoticeを表示するだけで、実mutationを呼ばない実装 - 現在の実装 — CURRENT IMPLEMENTATION
src/services/TransactionService.ts現在の入出金service。口座振替機能ではない - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/既存Ledger・idempotency・audit設計。mandateと請求batchは未実装 - 現在の実装 — CURRENT IMPLEMENTATION
scripts/regression/将来追加時に重複・競合・rollback testを置く領域