職員権限設定・請求口座情報管理仕様

文書バージョン: 0.2（実装反映）
作成日: 2026-08-11
現況再確認: 2026-08-11
ステータス: 実装済み
対象: open-hoikuict
想定利用者: 保育施設の管理者、事務職員、一般職員

1. 目的

職員の基本ロールと業務別権限を一か所で管理できるようにし、家族の口座情報を閲覧・編集できる職員を管理者と許可された事務職員に限定する。

請求入力自体は担任等の一般職員が行う場合がある一方、銀行名、支店名、口座番号、口座名義等は取り扱いに注意が必要な情報である。そのため、請求金額の入力権限と家族口座情報の管理権限を分離する。

本仕様では、既存の admin / can_edit / view_only を基本ロールとして維持し、職員ごとに業務別権限を追加する。職員名や役職名から権限を推測せず、管理者が明示的に付与した権限を使用する。

2. 実装前の課題と現在の解決

基本ロールは現在も次の3種類である。

値	表示名	概要
`admin`	管理者	管理者向け操作を含む全般的な操作が可能
`can_edit`	編集可	日常業務の作成・更新が可能
`view_only`	閲覧のみ	閲覧中心で、更新操作は不可

実装前は、家族口座情報の編集フォームがcurrent_user.can_edit、更新APIがrequire_can_editで保護され、can_editの職員全員が口座情報を編集できた。

現在は/staff/permissionsへ基本ロールと業務別権限を集約し、口座情報の表示・更新をcan_manage_billing_accountsで制御する。管理者には実効権限を常時付与し、view_onlyには業務別権限を付与しない。権限変更と口座情報変更は監査ログへ記録する。

3. この仕様での決定事項

基本ロールは admin / can_edit / view_only の3種類を維持する。
「事務職員」という新しい基本ロールは追加しない。
家族口座情報の管理には、業務別権限 can_manage_billing_accounts を追加する。
管理者は can_manage_billing_accounts の保存値にかかわらず、常に請求口座情報管理権限を持つ。
can_edit の職員には、請求口座情報管理権限を自動付与しない。
事務職員には、管理者が請求口座情報管理権限を明示的に付与する。
職員の表示名、メールアドレス、担当クラス等から権限を自動判定しない。
権限がない職員には、口座編集フォームだけでなく、口座番号や口座名義等の詳細情報も表示しない。
権限制御は画面上の表示切替だけに依存せず、更新APIでも必ず検証する。
職員権限を集約して管理する管理者専用画面 /staff/permissions を追加する。
権限変更は対象職員の次回リクエストから反映し、再ログインを必須としない。
権限変更と家族口座情報の変更は監査ログに記録する。

4. 用語

用語	定義
基本ロール	職員の全般的な利用範囲を表す `admin` / `can_edit` / `view_only`
業務別権限	特定業務だけに付与する職員単位の権限
請求口座情報管理者	`can_manage_billing_accounts` が有効な職員、または管理者
家族口座情報	`FamilyBillingProfile` が保持する支払方法、口座振替状態、銀行・支店・口座・名義等の情報
権限設定画面	管理者が全職員の基本ロールと業務別権限を確認・変更する画面
実効権限	基本ロールと業務別権限を評価した結果、実際に許可される操作

5. 対象範囲

5.1 初期実装対象

項目	内容
請求口座情報管理権限	職員ごとに付与・解除できるようにする
管理者の暗黙権限	管理者には請求口座情報管理権限を常に付与する
権限設定画面	全職員の基本ロールと業務別権限を一覧で管理する
口座情報の表示制御	権限のない職員には詳細な口座情報を表示しない
口座情報の更新制御	権限のない職員からの更新要求を拒否する
既存権限の集約	「園児台帳管理」を権限設定画面でも管理できるようにする
初期データ	管理者とデモ職員「事務」に口座管理の実効権限を付与する
監査ログ	権限変更と口座情報変更の実行者、対象、日時、変更項目を記録する
自動テスト	管理者、事務職員、一般編集職員、閲覧専用職員の権限境界を検証する

5.2 初期実装対象外

施設ごとに自由なロールを作成する機能
ロールと権限の組み合わせをテンプレートとして保存する機能
権限承認ワークフローや二者承認
項目単位で「閲覧のみ」「編集可」を細かく分ける機能
家族単位、クラス単位で口座管理者を限定する機能
外部IDプロバイダー側のグループと業務別権限の自動同期
銀行口座情報の暗号化方式変更
Zengin作成、銀行提出、結果取込等の既存権限の全面的な再設計

6. 権限モデル

6.1 基本ロールと業務別権限

基本ロールは全般的な操作範囲に使用し、機微情報を扱う業務は業務別権限で制御する。

初期実装で権限設定画面に表示する業務別権限は次のとおりとする。

権限キー	表示名	説明
`can_manage_child_records`	園児台帳管理	園児・家族・保護者アカウントの追加と編集を許可する
`can_manage_billing_accounts`	請求・口座情報管理	家族の支払方法、口座振替状態、銀行・支店・口座情報の閲覧と編集を許可する

将来、業務別権限が増える場合は同じ画面に追加する。候補として、有給管理、職員管理、請求確定、Zengin出力管理等がある。

6.2 実効権限

請求口座情報管理の実効権限は次の式で判定する。

can_manage_billing_accounts_effective
  = user.staff_role == "admin"
    OR user.can_manage_billing_accounts == true

管理者の権限は暗黙に有効とする。管理者のチェックボックスは権限設定画面でチェック済みかつ変更不可として表示し、「管理者には常に付与」と注記する。

view_only の職員に業務別管理権限を付与することは認めない。基本ロールが view_only に変更された場合、保存済みの業務別権限は無効化する。再び can_edit に変更しても自動復元せず、管理者が明示的に再付与する。

6.3 権限判定の共通化

権限名、表示名、説明、管理者への暗黙付与条件は共通の権限定義に集約する。各テンプレートやルーターに個別の条件式を散在させない。

コード上は、次の責務を持つ共通関数またはサービスを用意する。

指定職員が権限を持つか判定する。
管理者の暗黙権限を反映する。
view_only と業務別管理権限の矛盾を防ぐ。
権限がない更新要求を 403 Forbidden で拒否する。
画面表示用に実効権限一覧を返す。

7. アクセス制御表

7.1 請求入力と家族口座情報

表示・操作	閲覧のみ	編集可・権限なし	編集可・口座管理権限あり	管理者
請求月・請求金額の閲覧	可	可	可	可
既存ルール内での請求金額入力	不可	可	可	可
支払方法・振替状態の概要表示	可	可	可	可
銀行・支店・口座番号・名義の詳細表示	不可	不可	可	可
家族口座情報編集フォーム	不可	不可	可	可
家族口座情報更新API	不可	不可	可	可

7.2 権限設定

表示・操作	閲覧のみ	編集可	管理者
権限設定画面の閲覧	不可	不可	可
基本ロールの変更	不可	不可	可
業務別権限の付与・解除	不可	不可	可
権限変更履歴の閲覧	不可	不可	可

8. 画面仕様

8.1 職員権限設定画面

パス: /staff/permissions

アクセスできるのは管理者だけとする。未ログイン時は既存の職員ログイン導線へ遷移し、管理者以外は 403 Forbidden とする。

画面上部に次を表示する。

画面タイトル「職員権限設定」
説明「職員の基本権限と業務別権限を設定します」
職員名検索
有効状態による絞り込み
基本ロールによる絞り込み
「職員管理へ戻る」リンク

職員は行単位で表示し、次の列を持つ。

列	内容
職員	表示名、メールアドレス、有効状態
基本ロール	管理者、編集可、閲覧のみ
園児台帳管理	業務別権限チェックボックス
請求・口座情報管理	業務別権限チェックボックス
最終更新	権限の最終更新日時と更新者
操作	「この職員の権限を保存」ボタン

誤操作による一括変更を避けるため、初期実装では職員単位で保存する。複数行をまとめて保存する機能は設けない。

管理者の業務別権限はチェック済みかつ操作不可とする。最後の有効な管理者を管理者以外へ変更する操作、自分自身の管理者権限を外す操作は、既存の職員管理と同様に拒否する。

view_only を選択した場合、業務別管理権限のチェックを外して無効化する。保存前に「閲覧のみでは業務別管理権限を付与できません」と画面内に説明する。

保存成功時は、同じ画面に「○○さんの権限を更新しました」と表示する。検証エラー時は変更を保存せず、対象行の近くに理由を表示する。

8.2 職員追加・編集画面

職員追加画面では初期の基本ロールを選択できる。新規職員の業務別権限は初期値をすべて無効とし、管理者を選んだ場合のみ実効権限が暗黙に有効になる。

既存職員の編集画面は、表示名、メールアドレス、表示順、有効状態等の基本情報を中心とする。権限については現在値を要約表示し、「権限設定を開く」リンクから /staff/permissions の対象職員位置へ遷移できるようにする。

権限の変更操作は原則として権限設定画面へ集約し、複数画面に同じチェックボックスを重複配置しない。

8.3 園児別請求入力画面

対象パス: /billing/cycles/{cycle_id}/child-charges/{child_id}

請求口座情報管理者には、現行の「家族口座情報の編集」フォームを表示する。対象項目は次のとおりとする。

支払方法
口座振替状態
銀行コード、銀行名カナ
支店コード、支店名カナ
預金種目
口座番号
口座名義カナ
新規コード
依頼書回収日
備考

権限のない職員には編集フォームを表示しない。代わりに「口座情報は管理者または請求・口座情報管理権限を持つ職員が管理します」と表示する。

一般職員が業務上確認できる情報は次に限定する。

支払方法
口座振替状態
口座情報が登録済みか未登録か

次の情報は権限のない職員には表示しない。

顧客番号
銀行コード、銀行名
支店コード、支店名
預金種目
口座番号
口座名義
新規コード
依頼書回収日
口座に関する備考

「末尾4桁だけ表示」等の部分表示も初期実装では行わない。業務上必要になった場合は、別途「口座情報閲覧」権限を追加して検討する。

9. URL・API仕様

用途	メソッド	URL	必要権限
権限設定一覧	GET	`/staff/permissions`	管理者
職員別権限更新	POST	`/staff/permissions/{user_id}`	管理者
園児別請求入力	GET	`/billing/cycles/{cycle_id}/child-charges/{child_id}`	職員ログイン
家族口座情報更新	POST	`/billing/cycles/{cycle_id}/child-charges/{child_id}/profile`	請求口座情報管理者

家族口座情報更新APIは、既存の require_can_edit ではなく、請求口座情報管理専用の認可処理を使用する。

更新APIでは認可を、対象データの取得・検証・変更より前に実行する。権限がない場合は 403 Forbidden を返し、データベースを変更しない。

10. データモデル

10.1 usersへの追加項目

users テーブルへ次の列を追加する。

列	型	初期値	内容
`can_manage_billing_accounts`	boolean	`false`	家族口座情報管理権限の保存値

User には次の実効権限プロパティを追加する。

can_manage_billing_accounts_effective

このプロパティは、管理者または保存値が有効な職員に対して true を返す。

10.2 権限変更監査ログ

権限変更を記録するため、次の情報を保持する。

項目	内容
対象職員ID	権限を変更された職員
権限キー	`staff_role`、`can_manage_child_records`、`can_manage_billing_accounts` 等
変更前	変更前の値
変更後	変更後の値
実行者ID	操作した管理者
実行者名スナップショット	操作時点の表示名
変更日時	UTCで保存し、画面ではJST表示

値が変化していない項目は監査ログに追加しない。

10.3 家族口座情報変更監査ログ

口座情報更新時に次を記録する。

対象の家族ID
対象の園児ID
対象の請求月ID
変更された項目名
実行者ID、実行者名スナップショット
変更日時

監査ログに完全な口座番号や口座名義を複製して保存しない。初期実装では変更された項目名だけを記録し、必要な場合でも口座番号はマスクした値のみを扱う。

11. 認証セッションと権限反映

業務別権限は、権限変更後の次回リクエストから反映する。

請求口座情報は機微性が高いため、認可判定をログイン時に発行した権限Cookieだけに依存させない。ログイン中の職員IDを使用して現在の User をデータベースから取得し、その時点の実効権限を評価する。

これにより、管理者が口座管理権限を解除した場合、対象職員が再ログインしなくても以後の表示と更新を禁止できる。

対象職員が無効化済み、削除済み、または職員IDを解決できない場合は、権限なしとして扱う。

12. 監査と安全性

権限変更画面と更新APIは管理者だけが利用できる。
権限変更時は既存のCSRF対策を適用する。
口座更新APIは請求口座情報管理権限を毎回確認する。
権限のない職員向けHTMLに、口座番号や口座名義等を埋め込まない。
非表示にするだけで、DOM、JavaScript変数、data属性へ値を残してはならない。
エラーメッセージに口座番号、名義、顧客番号等を含めない。
アプリケーションログへフォーム入力値をそのまま出力しない。
監査ログには、完全な銀行口座情報を複製しない。
権限変更と口座情報変更は、データ更新と監査ログ追加を同一トランザクションで確定する。

13. 主な処理フロー

13.1 事務職員への権限付与

管理者が /staff/permissions を開く。
対象の事務職員を検索する。
「請求・口座情報管理」を有効にする。
対象職員の行にある保存ボタンを押す。
サーバーは管理者権限、対象職員、基本ロール、入力値を検証する。
権限を保存し、監査ログを追加する。
対象職員の次回リクエストから口座情報の詳細表示と編集を許可する。

13.2 権限のない職員による請求入力

一般職員が園児別請求入力画面を開く。
サーバーは請求金額入力権限と口座管理権限を別々に評価する。
請求金額入力欄は既存ルールに従って表示する。
口座情報は支払方法、振替状態、登録有無だけを表示する。
家族口座情報編集フォームと詳細値は表示しない。

13.3 権限のない更新要求

権限のない職員が口座情報更新URLへ直接POSTする。
サーバーはリクエスト時点の職員レコードと実効権限を確認する。
403 Forbidden を返す。
FamilyBillingProfile と監査ログを変更しない。

13.4 権限解除

管理者が事務職員の請求口座情報管理権限を解除する。
権限変更と監査ログを保存する。
対象職員が既にログイン中でも、次回リクエストから詳細表示と更新を禁止する。

14. エラー表示

状況	応答・表示
未ログインで権限設定画面を開く	既存の職員ログイン画面へ遷移
管理者以外が権限設定画面を開く	`403 Forbidden`
権限のない職員が口座更新APIを呼ぶ	`403 Forbidden`、データ変更なし
存在しない職員の権限を更新する	`404 Not Found` または安全に職員一覧へ戻す
`view_only` に業務別権限を付与する	保存せず、検証メッセージを表示
最後の管理者を降格する	保存せず、既存の管理者保護メッセージを表示
権限保存中にDBエラーが発生する	権限と監査ログをロールバックし、一般化したエラーを表示

15. データ移行と初期値

users.can_manage_billing_accounts を false で追加する。
既存の管理者は保存値にかかわらず実効権限を持つ。
ローカルサンプルおよびデモデータの「事務」職員には保存値 true を設定する。
担任、看護師、栄養士、パート職員等には自動付与しない。
表示名が「事務」であることを本番データ移行条件には使用しない。
本番相当データでは、管理者が権限設定画面から対象職員へ明示的に付与する。
移行直後に管理者が0人になる変更や、最後の管理者を降格する変更は認めない。

SQLiteでは既存の組み込みスキーマ更新方式に合わせて列を追加する。管理対象外のデータベースでは、利用側が同等のスキーマ変更を実施する。

16. テスト仕様

16.1 権限判定

管理者は保存値が false でも実効権限を持つ。
can_edit かつ権限が true の職員は実効権限を持つ。
can_edit かつ権限が false の職員は実効権限を持たない。
view_only の職員は保存値にかかわらず実効権限を持たない。
無効な職員、存在しない職員は実効権限を持たない。

16.2 口座情報画面

管理者には詳細情報と編集フォームが表示される。
権限を付与された事務職員には詳細情報と編集フォームが表示される。
権限のない担任には、銀行名、支店名、口座番号、名義、備考が表示されない。
権限のない担任には編集フォームと保存ボタンが表示されない。
閲覧専用職員にも詳細情報と編集フォームが表示されない。
権限のない職員向けHTMLソースに口座番号や口座名義が含まれない。

16.3 口座情報更新API

管理者は更新できる。
権限を付与された事務職員は更新できる。
権限のない can_edit 職員は 403 となる。
view_only 職員は 403 となる。
権限のない更新要求で口座情報が変化しない。
更新成功時に監査ログが1件追加される。
更新失敗時に口座情報と監査ログの両方がロールバックされる。

16.4 権限設定画面

管理者だけが一覧を表示できる。
管理者だけが権限を更新できる。
管理者以外からの直接POSTは 403 となる。
管理者の暗黙権限がチェック済み・変更不可で表示される。
view_only と業務別管理権限を同時に保存できない。
自分自身または最後の管理者を不正に降格できない。
権限変更時に変更項目ごとの監査ログが追加される。
権限解除が対象職員の次回リクエストから反映される。

17. 受入条件

次をすべて満たした場合に、本仕様の初期実装を完了とする。

管理者と、明示的に権限を付与された事務職員だけが家族口座情報を編集できる。
担任等の一般編集職員が口座更新URLへ直接POSTしても更新できない。
権限のない職員向け画面およびHTMLに、詳細な口座情報が含まれない。
一般編集職員は、口座管理権限がなくても既存ルール内で請求金額を入力できる。
管理者が /staff/permissions で基本ロールと業務別権限を確認・変更できる。
管理者の実効権限が常に有効である。
権限解除が再ログインなしで反映される。
権限変更と口座情報変更が監査ログに記録される。
既存の最後の管理者保護が維持される。
権限境界を確認する自動テストがすべて成功する。

18. 実装順序

権限定義と共通判定処理を追加する。
users.can_manage_billing_accounts と監査ログ用モデルを追加する。
SQLiteの組み込みスキーマ更新とデモ初期データを更新する。
職員権限設定画面と更新APIを追加する。
家族口座情報の表示制御を変更する。
家族口座情報更新APIを専用権限で保護する。
口座情報変更監査ログを追加する。
職員編集画面から重複する権限変更UIを整理する。
権限別の自動テストと実画面確認を行う。

19. 将来拡張

業務別権限が少数の間は、既存の can_manage_child_records と同様に users のboolean列で管理する。権限数が増え、施設ごとの権限セットや任意ロールが必要になった場合は、次の構造への移行を検討する。

権限定義テーブル
職員と権限の関連テーブル
施設ごとのカスタムロール
ロールと権限の関連テーブル
権限付与の開始日・終了日
二者承認や期限付き権限

初期実装では汎用RBAC基盤の導入を優先せず、権限定義と判定処理をコード上で集約し、画面上の設定場所を一本化する。