管理画面を「何でもできる画面」にしない
法人の所有と人の権限を分け、承認・調査・解消にそれぞれの責任を置く。
本文の説明・図・掲載コードだけで読み進められます。出典リンクは、権限のある人向け（非公開GitHub）です。GitHubで閲覧権限がある方だけ開けます。
この記事でわかること
- 会社の口座所有と、個人の操作権限は別に持つ
- 承認・支払実行・調査の終了は別の状態変化
- 運用センターは問題を集め、担当機能へ戻す入口
この記事の目次
会社のお金は、ログインした人のお金ではない
架空の青空商事には、経理担当の佐藤さん、承認担当の鈴木さん、閲覧担当の森さんがいるとします。三人が同じ口座を扱っても、口座を所有するのは青空商事です。担当者が退職しても口座が個人に付いて移動しては困ります。v3 は、法人という所有主体と、ログインする個人と、両者を結ぶ所属を分けました。
この分離によって「どの法人に属し、いま何を許されているか」を操作ごとに確かめられます。銀行側の審査担当と、法人側の管理者も別です。法人管理者だから銀行の審査を通せる、銀行担当者だから顧客の支払を自由に実行できる、という横滑りを防ぎます。名称が似ていても、権限の所属先まで読む必要があります。
十万円の支払を、三つの事実に分ける
佐藤さんが十万円の支払を作り、鈴木さんが確認し、実行に進む例で考えます。v4 は申請、別人の承認、実際の実行を分けます。承認済みは、まだ支払済みではありません。申請内容は固定されるため、承認後に宛先だけを差し替えることはできず、変更は取消しと新しい申請で扱います。
さらに、承認したときの所属情報の版を覚えておきます。鈴木さんが承認後に権限を失ったら、古い承認をそのまま使うべきではありません。実行時に現在の所属と版を読み直すのは、過去の同意と現在の権限を両立させるためです。会社全体の日次上限も、複数の口座や操作者をまたいで確認します。
指定日が来ても、運用の仕事は残る
v5 の指定日支払は「十月十日以降に実行できる」という商品条件を加えます。指定日になれば自動送金されるわけではなく、元の担当者の実行が必要です。予約時点で残高も拘束しないため、指定日に資金が足りなければ支払は止まります。日付の予約と、資金の予約を同じものとして見せないことが大切です。
そこで v6 は、遅れている支払や問題の調査を扱うケースを加えました。銀行担当者は調査メモや解消申請を残せますが、顧客の代わりに振込や取消しを行う権限は増えません。問い合わせの窓口を作るために、顧客の意思決定まで奪わない設計です。運用機能の追加ほど「何を変えてよいか」を狭く定める意味があります。
十月十日の指定日を過ぎた支払が一覧に残っていても、運用担当がすぐ代理実行することは解決になりません。担当者の実行忘れ、実行時の残高不足、承認者の所属変更では、次に必要な確認が違います。たとえば承認者が異動したなら、支払の内容が変わっていなくても再承認が必要になり得ます。調査ケースは、その理由と連絡・確認の経過を置く場所です。指定日を過去へ書き換えたり、実際には今日行った支払を指定日に行ったように記帳したりする場所ではありません。商品の日付、実行した日付、調査した日付を分けて残すと、顧客の期待と実際の事実を混同せず説明できます。予約という便利な言葉の裏に、資金確保や自動実行を勝手に足さないことも、管理画面の大切な責任です。
「解決しました」という文章だけでは閉じない
佐藤さんから「支払は済みました」と連絡が来たとしても、ケースを閉じる根拠は言葉だけでは足りません。v6 の解消確認では、支払依頼と送金記録の宛先・金額などが一致し、対応する仕訳があるかを DB で再照合します。未払いで終了したなら、終了状態と送金記録が存在しないことを確認します。
そのうえで、解消申請者とは別の銀行担当者が確認します。調査中に別の人が記録を更新した場合は、記録の版が変わり、古い画面の操作を止めます。手順は増えますが、誤った状態を「解決」として閉じてしまうリスクを下げます。ケースの履歴は追記し、何が分かって判断が変わったのかを後から追えるようにします。
実装を読む：ケースの終了と送金を分ける
説明用の擬似コードです。ケースを閉じる処理から送金を作るわけではありません。
現在の担当権限を確認する
ケースの版が画面の版と一致するか確認する
支払と仕訳の根拠を読み直す
解消申請者と確認者が別人か確認する
ケースの確認結果と履歴を追加する疑わしい動きは、結論ではなく調査の入口
v11 の AML シミュレーターは、短時間の多数の出金や新しい口座の大きな出金などを、ルールで見つけます。ここで出たアラートは犯罪の判定ではありません。元帳の取引を走査して根拠を残し、口座単位のケースで調査し、必要なら別の担当者の二次確認や責任者への上申へ進めます。
検知だけで口座を自動凍結したり、送金を取り消したりしない点が重要です。異常らしさと、実際に取引を止める判断には距離があります。検知ルールを厳しくすれば見逃しを減らせる場合がある一方、普通の活動も拾いやすくなります。根拠・調査・判断を分けることで、誤検知を検討する余地を残しています。
一つの一覧に集めても、責任は混ぜない
v12 の運用センターは、例外、照合差異、AML、承認待ちを集めます。各問題の状態を別の表へ丸写しせず、元のデータから読取り時に組み立てるため、二か所の「解決済み」が食い違うのを避けます。担当者は一覧から支払や仕訳をたどり、その問題を管理する画面へ戻って対処します。
重大な問題はインシデントとして、調査中、解消、終了を記録します。ただし、自動で担当者を呼び出す通知基盤や実際の AML サービスは、この実装範囲に含まれません。また、新しい役割の差がコードに定義されていることと、現在の環境で試したことは別です。十月三日の記録でも operator と manager の差は未実証とされており、本章も設計上の役割として説明しています。
出典と、確認できた範囲
以下のリンクは非公開GitHubへの出典で、閲覧権限が必要です。本文はリンク先を開かなくても読める構成です。固定コード・設計資料を参照していますが、今回、この読み物のために銀行の取引やDB操作、本番試験は実行していません。実装や資料にある検査と、こちらで実施した検証を混同しないようにしています。
- 法人所有と操作者の分離 ↗（非公開GitHub・要権限）
v3 の追加範囲と v4 の設計上の不変条件 - 法人の承認・設定変更 ↗（非公開GitHub・要権限）
別人承認・権限の版・限度額の統制 - 指定日支払の商品契約 ↗（非公開GitHub・要権限）
指定日は自動送金でも残高拘束でもない - 法人支払の調査ケース ↗（非公開GitHub・要権限）
ケースの解消と資金移動を分離する - v11 AML の実装範囲 ↗（非公開GitHub・要権限）
ルール検知・ケース・二次確認と非目標 - v12 運用センター ↗（非公開GitHub・要権限）
元データから作るキューとインシデントの流れ - 2026年10月3日の修復 RC 記録 ↗（非公開GitHub・要権限）
追加修復と最新記録時点の検証・未実施の範囲
MiniBankは学習・検証用の銀行アプリです。架空の金額や人物は、仕組みを説明するための例です。
つながる読み物
ここまで読んだ記録を、ひとつ。
自分のペースで。あとから取り消すこともできます。