誰が、何を見て、何を変えられるか
個人・法人・銀行担当者の境界を、具体的な一件から読み解く。
本文の説明・図・掲載コードだけで読み進められます。出典リンクは、権限のある人向け（非公開GitHub）です。GitHubで閲覧権限がある方だけ開けます。
この記事でわかること
- ログイン済みというだけでは他人のデータに届かない
- 法人の manager と銀行の admin_manager は別の役割
- 強い役割にも対象範囲・別人確認・停止条件がある
この記事の目次
役職名より、対象と操作を先に決める
「管理者は何でもできますか」という質問には、そのままでは答えられません。誰の立場で、どの法人や口座に対して、読むのか、変更するのか、承認するのかを分ける必要があります。MiniBank では、ログイン利用者、個人の顧客、法人の所属、銀行の運用者が別の概念です。同じ人が複数の立場を持っても、境界は消えません。
架空の青空商事の佐藤さんが、会社の支払を申請しながら個人口座も持っている場面を考えます。個人口座を見る根拠は本人との所有関係です。会社の口座を見る根拠は法人の所属です。佐藤さんの名前が同じだからといって、両方の権限を一つにまとめると、退職や所属変更を安全に反映できなくなります。
個人は、自分の情報を決められた入口から
個人向けの API は、Auth で本人を検証し、その利用者のトークンで DB に接続します。基礎の口座 RLS は、顧客情報を介して本人の口座に読取りを絞ります。口座表を直接更新して残高や状態を書き換える権限は渡していません。振込や本人確認は、その業務用に用意された関数へ頼みます。
これは、画面が親切だから安全なのではなく、別のクライアントから呼ばれても境界を維持するためです。ただし、受付用の関数が強い権限で動く場合は、関数の中の所有者確認も欠かせません。「RLS がある」という一行だけで判断せず、直接読取りと業務関数のどちらを通るかを追います。
法人内でも、作る人と認める人を分ける
法人の閲覧担当 viewer、支払担当 operator、管理担当 manager という役割に加え、v4 の承認では有効な approver の所属を確認します。manager は自動的に approver も兼ねるわけではありません。佐藤さんが申請した十万円を、その申請者自身が承認してよいという意味にもなりません。
承認後に人の役割が変わるため、支払実行時には申請者と承認者の現在の所属と版を読み直します。権限を取り消してから再付与しても、古い承認を無条件に復活させない狙いです。限度額や所属の変更にも、別人確認が必要なものがあります。会社の管理を便利にする一方、便利な管理画面から支払統制を外せないようにしています。
銀行の担当者は、顧客の代理出納係ではない
銀行側では、有効な運用者が扱う管理操作と、admin_manager に限定する強い操作があります。KYC 審査や口座凍結のような入口も、単なるログイン確認の後に DB の運用者情報を参照します。役割や有効状態が待ち時間の間に変わらないよう、権限レコードをロックする処理も入っています。
一方、法人支払の調査ケースを担当できることは、顧客の代わりに支払を実行・取消しできることではありません。v6 の調査は、支払と仕訳を読むことで根拠を確かめ、ケースの履歴を更新する範囲です。顧客法人への所属などがある銀行担当者を、その法人の独立した確認者として扱わない条件もあります。権限は、業務の目的に必要な分だけを与えます。
一覧を見られても、明細すべてを見られるとは限らない
運用センターは広く問題の存在を知らせる入口ですが、そこへ全組織の機微な金額や理由を無条件に並べるわけではありません。v20 の強化では、グループ移動のキューに載せる情報を絞り、詳細は権限を持つ画面で示す設計です。問題があると知る権限と、そのすべての中身を読む権限を分けています。
Digital Twin の返却内容も、通常の運用者には基準の銀行と役割を持つ entity の範囲へ絞り、全体や連結情報は admin_manager の範囲にしています。保存済みの結果を人ごとに作り替えるのではなく、返す内容を制限します。強い役割でも、全体の書込停止や別人確認といった別の条件を無視してよいわけではありません。
認可を読む：一つの role だけで決めない
説明用の擬似コードです。実際の操作ごとの条件を読み落とさないための順番です。
本人の確認は済んでいるか
対象の口座・法人・entity に届いてよいか
現在の所属と役割は操作に足りるか
別人による確認が必要か
現在の状態と停止条件は操作を許すか例として、青空商事の支払承認待ちを知った銀行担当者が、その場で自分を法人の承認者として扱うことはできません。キューに問題が見えることは、問題を解決するためのあらゆる権限を与えることではないからです。同様に、一覧へ表示される識別子を使って別の詳細 API を呼んでも、詳細側で対象範囲を確認する必要があります。画面の移動先だけを隠す対策では、直接の呼出しに対応できません。こうした境界を読むには「この人は管理者」という肩書きの表より、対象ごとに読む・提案する・承認する・実行するを並べる方が有効です。一つの操作に複数の条件が重なるため、役割を強くしたのに操作できない場合もあり得ます。それをすぐ不具合とせず、別人確認や対象範囲が残っているかを確かめます。
権限表は、実測と一緒に育てる
実際に確かめるなら、許される人が成功するだけでなく、別法人の人、閲覧だけの人、無効化した人、申請者本人、古い画面を開いた人が拒否されるかも必要です。読取りが空になる場合と、変更が明確に拒否される場合を分け、拒否後に残高や状態が変わらないことまで観察します。
本ガイドは固定ソースで定義された境界を整理しています。十月三日の修復記録でも、operator と manager の権限差は未実証と明記されています。したがって、ここに書いた役割を現在の公開環境で全件試した権限表とは呼びません。実装上の条件を出発点に、環境と操作を固定した検証へつなげるための読み方です。
出典と、確認できた範囲
以下のリンクは非公開GitHubへの出典で、閲覧権限が必要です。本文はリンク先を開かなくても読める構成です。固定コード・設計資料を参照していますが、今回、この読み物のために銀行の取引やDB操作、本番試験は実行していません。実装や資料にある検査と、こちらで実施した検証を混同しないようにしています。
- 本人を確かめる API ↗（非公開GitHub・要権限）
Bearer トークンを Auth で検証する境界 - 法人所有と操作者の分離 ↗（非公開GitHub・要権限）
v3 の追加範囲と v4 の設計上の不変条件 - 利用者権限を保つ接続 ↗（非公開GitHub・要権限）
利用者のトークンを DB へ引き継ぐ設計 - 口座の行単位制御 ↗（非公開GitHub・要権限）
本人の口座の読取りと直接更新の禁止 - 法人の承認・設定変更 ↗（非公開GitHub・要権限）
別人承認・権限の版・限度額の統制 - 管理操作の権限とロック ↗（非公開GitHub・要権限）
口座凍結・KYC・管理者変更の権限再確認 - 法人支払の調査ケース ↗（非公開GitHub・要権限）
ケースの解消と資金移動を分離する - 停止境界の強化コード ↗（非公開GitHub・要権限）
業務変更の停止と診断・無効化の例外 - 2026年10月3日の修復 RC 記録 ↗（非公開GitHub・要権限）
追加修復と最新記録時点の検証・未実施の範囲 - 停止境界のテストソース ↗（非公開GitHub・要権限）
拒否結果だけでなく更新の不変を検査する仕様
MiniBankは学習・検証用の銀行アプリです。架空の金額や人物は、仕組みを説明するための例です。
つながる読み物
ここまで読んだ記録を、ひとつ。
自分のペースで。あとから取り消すこともできます。