設定メニューの全体点検（2026年9月20日）
状態: 9月20日に実装・検証・プッシュ、9月21日3:45:52 JSTに本番反映完了。 詳細は設定・ログイン時間の本番更新記録を参照。
結論
「設定」から一覧を開く構成を継続し、最初の4項目に5項目を加えた 9項目 を候補とする。項目が増えたため4分類にまとめる。
追加候補は、職員管理、クラス管理、延長保育料金ルール、保護者登録の受付、保護者端末の監視。いずれも既存画面があり、設定一覧から既存のURLへ案内できる。
ただし、設定一覧を管理者専用にする当初案は修正が必要。クラス管理と延長保育料金ルールは一般職員にも閲覧・編集の権限がある。利用者の既存権限に応じて設定項目を表示し、保存処理でも従来の権限を検証する。
調査の範囲と根拠
- 基準は本番更新記録の配備版
801ed69915846bc42ec6e1f1342fc4f9f9aa6771。対応する本番用ソースのHEADと作業ツリーが未変更であることを確認。 main.pyの登録先から37モジュール・46ルーター登録・359ルート宣言を抽出。開発用や認証方式による条件付き登録、同一処理の別URLを含む静的集計であり、本番の画面数を意味しない。- 176件のHTMLテンプレートを横断検索。共通メニュー、画面内リンク、設定フォーム、個人の表示設定を抽出し、候補のGET・保存処理・権限判定を確認。
- DBの設定モデルと参照箇所も調べ、設定値だけが存在して画面がないものを区別。
- 調査用の一覧は
.local-dev/operations/settings-route-inventory-20260920.json、抽出処理は同ディレクトリのaudit-settings-routes-20260920.pyに保存。 - 実利用者のアカウントですべての画面を操作した調査ではない。本番DBの内容、環境変数の実値、設定変更や送信は調べていない。
設定一覧にまとめる9項目
| 分類 | 項目 | 実際に扱う内容 | 入口の整理案 | 既存のURL |
|---|---|---|---|---|
| 職員とログイン | ログイン時間設定 | 非操作期限・ログインからの最長時間 | 新設。職員共通、次回ログインから適用 | /settings/staff-sessions（新規案） |
| 職員とログイン | 職員管理 追加 | 職員の追加・編集・利用停止、表示順、認証管理、担当クラス | アカウント内の単独メニューを設定一覧へ移す | /staff/users |
| 職員とログイン | 職員権限設定 | 基本権限・園児台帳管理・請求口座管理 | 単独メニューを設定一覧へ移す。職員管理内の関連リンクも利用可 | /staff/permissions |
| 園の運用 | クラス管理 追加 | クラス名・表示順の登録と変更、所属園児数の確認 | 基本業務内の単独メニューを設定一覧へ移す | /classrooms/ |
| 園の運用 | 児童記録設定 | 記録の形式・閲覧範囲・年齢別作成頻度・入力項目・適用日・版履歴 | 基本業務内の単独メニューを設定一覧へ移す | /settings/child-records |
| 園の運用 | 延長保育料金ルール 追加 | 通常保育時間・朝夕の課金・猶予・単価・上限・適用期間・計算方式・請求連携 | 設定一覧にも入口を追加。月次集計からの設定リンクは業務上の文脈があるため保持 | /extended-care-fees/settings |
| 保護者と端末 | 保護者登録の受付 追加 | 初回申請の受付開始・停止、共通QRの印刷・保存 | 設定一覧にも入口を追加。保護者アカウントからの入口も保持 | /parent-accounts/registration-qr |
| 保護者と端末 | 保護者端末の監視 追加 | 端末名・監視の有効無効・監視開始終了時刻・接続状況 | 設定一覧にも入口を追加。ホームの異常警告と接続状況へのリンクは保持 | /settings/guardian-terminals |
| 保守 | バックアップ管理 | 定期実行の有効無効・頻度・時刻・曜日、手動実行、履歴 | アカウント内の単独メニューを設定一覧へ移す | /settings/backups |
「管理」と名付けられた画面を一律に移す判断ではなく、内容を確認して決めた。職員管理は職員のマスターと認証の管理、クラス管理はクラス名・表示順のマスターが中心で、今回の設定一覧に適合する。一方、園児のクラス割当そのものは園児の編集画面にあるため、その入力を設定へ移す必要はない。
権限で間違えやすい点
| 項目 | 閲覧 | 変更 |
|---|---|---|
| クラス管理 | ログイン済みの職員（閲覧のみを含む） | 編集可または管理者 |
| 延長保育料金ルール | ログイン済みの職員（閲覧のみを含む） | 料金ルールは編集可または管理者。計算モードと請求連携は管理者のみ |
| 職員管理・担当クラス | 管理者 | 管理者。認証管理や利用停止には有効な実ユーザーの管理者確認もある |
| 職員権限設定 | 有効な実ユーザーの管理者 | 同左 |
| 児童記録設定・バックアップ・端末監視 | 管理者 | 管理者 |
| 保護者登録の受付 | 有効な実ユーザーの管理者、かつ保護者ローカル認証機能が有効 | 同左 |
| ログイン時間設定 | 管理者（新規案） | 管理者（新規案） |
設定メニューの入口は認証済み職員に表示する。一般の編集可職員・閲覧のみ職員には、現状ではクラス管理と延長保育料金ルールの2項目を表示できる。閲覧のみ職員のリンクを消して参照経路を失わせない。設定の閲覧を許可することと、設定変更を許可することは分ける。
園児台帳管理や請求口座管理の業務別権限を持つだけで、管理者設定を使える扱いにはしない。カレンダーの管理権限も独自に判定されており、職員の基本権限だけで置き換えない。
設定部分はあるが、分けてから扱う候補
| 候補 | 確認した内容 | 今回の判断 |
|---|---|---|
| カレンダーの作成・管理 | 作成、名前・説明・色、共有状態の同期、アーカイブ・復元・削除がカレンダーのサイドバー内に混在 | 将来の分離候補。独立した管理GET画面がないため、今回の9項目に架空の移動先を置かない。予定の閲覧・編集・日月週切替はカレンダーに残す |
| 共用端末の登録・準備 | /guardian/setup に登録案内と「専用端末画面を開く」が同居。端末登録は専用トークン認証で職員ログインとは別 |
日常の起動入口を失わせないよう、登録案内と起動操作を分けるときに整理。現在の「保護者キオスク」を丸ごと設定へ移さない |
| 園の自作文例 | /plans/bunrei/facility/new に文例の手入力、CSV・Excel取込。編集可職員が利用する |
再利用する園内資料だが、指導計画作成に直結する。今回は指導計画内の入口を保持。文例管理を独立させる際の追加候補とする |
| 園・施設の名称 | 指導計画の施設参照値は環境変数 HOIKU_NURSERY_REF |
既存の名称編集画面はない。名称だけでなく文例などの参照範囲にも関わるため、新規設定機能として別に設計する |
| 請求の施設設定・固定料金 | BillingSetting の委託者コード等は請求画面に表示。MealFeeRule 等のモデルと計算処理もある |
対応する設定フォーム・登録ルートは今回の配備版で確認できない。「施設設定」「給食費設定」が既存画面として使えるような表示はしない |
| メール・プッシュ・端末の基盤設定 | SMTP、公開URL、通知鍵、端末登録トークンなどはサーバー設定 | メニュー移動の対象となる既存画面はない。画面化するなら保存先や適用方法も含む独立した開発となる |
カレンダーは calendar_base.html、保護者の共通QRは parent_auth/base.html の別レイアウトを使用する。共通メニューだけを変更しても、各画面の入口・戻る経路までは整わない点に注意する。特にQR画面へ設定一覧の戻るリンクを足す場合、印刷対象に混ぜない。
日常業務・個人の操作として扱うもの
| 領域 | 点検結果 |
|---|---|
| 園児・家族・保護者アカウント | 個人ごとの登録、変更申請、承認、園児との紐付け、認証復旧は日常の対象者別業務。保護者の共通受付設定だけを上記へまとめる |
| 出欠・登降園・お迎え・日次連絡 | 毎日の入力・確認・訂正。共用端末の90秒で初期画面に戻る処理は職員ログイン切れとは別機能 |
| 健康管理・園児の保育認定 | 園児ごとの業務データ。全園共通の設定と混ぜない |
| 延長料金の月次計算・調整・確定・請求転送 | 設定済みルールで実行する業務。設定一覧に移すのはルール画面への入口 |
| 請求入力・口座情報・Zengin出力 | 月次処理と個別の請求情報。口座情報には専用の業務別権限がある。画面内に「施設設定」の表示があるだけで請求ページ全体を設定扱いにしない |
| 指導計画・児童票作成・議事録・経緯・行事シリーズ | 業務記録・帳票の作成と確認。児童票の作成頻度や項目定義だけが設定 |
| 連絡タイムライン・お知らせ・アンケート・文書確認 | 作成対象や配信対象、設問、締切、確認担当の指定は個々の業務内容 |
| CSV・Excel入出力、認可施設帳票出力、カレンダー取込 | 個別のデータ処理。低頻度でもそれだけを理由に設定にしない。職員取込の管理者制限等を保持 |
| カレンダーの表示・並び、画面の絞込、個人の通知 | カレンダーの表示対象や日曜表示、データ入出力の表示列等は個人・ブラウザー単位。全園の設定と混同しない。保護者の通知・パスワード変更は保護者画面に置く |
実装へ進む場合の確認事項
- 既存8画面へのリンクと、新規ログイン時間設定を分けて扱う。メニュー整理のために既存フォームを作り直さない。
- 単独メニューから移す5項目は、クラス管理・児童記録設定・職員管理・権限設定・バックアップ管理。新たに「設定」1項目を置くと、共通サイドバーの常設項目は差引4つ減る。
- 関連業務から直接設定を開くリンク、ホームの端末異常警告、既存のURLとブックマークを保持する。
- 設定内の各ページに戻る経路を設ける。現在の業務ページへ戻るリンクは用途が異なるので失わせない。新しい任意リダイレクト値を受け取る場合は内部の許可先だけにする。
- 新規ログイン時間設定の保存・取消・未保存で戻る動作は確認案に従う。既存画面の保存タイミングや取消仕様をメニュー整理と一緒に変えない。
- 左メニューの選択表示は、
/settingsというURLの先頭一致だけで決めない。/staff/users、/staff/permissions、/classrooms、料金ルール、登録QRも設定一覧から入れる。通常の請求・料金月次画面は引き続き該当業務を選択表示する。 - 一覧を開いただけでは保存・送信・バックアップ・端末登録を実行しない。各画面のCSRF検証と権限判定を保持する。
- 管理者・編集可・閲覧のみ・未ログイン、保護者認証機能が無効な環境を確認する。旧URLの直接アクセス、既存フォームの保存、戻るリンク、スマートフォン表示も確認する。
- 本番へ進む際は最新の更新記録を再確認し、本番固有のカレンダー取込・議事録出力・端末機能・バックアップ方式を保持する。開発ブランチを丸ごと配備しない。
主なコード上の根拠
以下の行番号は基準の本番配備ソースに対応する。
templates/base.html:301以降: 共通メニューの現行構成。routers/classrooms.py:89,112,161: 閲覧とクラス追加・編集の権限。routers/staff_auth.py:630,739,857,1212: 職員、認証、権限、担当クラス。child_records/router.py:161,187とtemplates/child_records/settings.html: 児童記録設定と保存。routers/extended_care_fees.py:343,369,422,473,534: 閲覧、ルール変更、請求連携、計算モードの権限差。routers/terminal_monitor.py:36,54とtemplates/guardian/monitor.html: 接続状況、監視の保存。routers/parent_auth.py:614,631,641とmain.py:179: 登録受付の管理者・有効ユーザー確認と機能による登録条件。routers/backups.py:38,79,103: バックアップ設定、手動実行、定期実行。routers/calendar.py:310,1035,1102,1288とtemplates/calendar/_sidebar.html: カレンダー管理の実態と権限。templates/guardian/setup.html: 登録案内と起動入口の混在。plan_docs/routers/bunrei.py:32,78,109とplan_docs/auth_adapter.py:79: 自作文例の追加・取込、施設参照値。templates/billing/index.html:36、models.py:1627,1701,1719: 請求設定の表示とモデル。編集画面の存在を意味しない。
この点検を反映した9項目・4分類・表示権限について、ユーザーから実装と本番反映を依頼された。将来の分離候補は今回の対象に含めない。
改訂モックの確認
- 管理者の9項目、編集可職員の2項目、閲覧のみ職員の2項目と閲覧のみ表示をブラウザーで確認した。
- 管理者によるログイン時間設定の表示、12時間の一括入力、モック内の保存、一覧へ戻る操作を確認した。
- 736px・320pxの表示幅で9項目が存在し、設定一覧の横幅および各項目に横方向のはみ出しがないことを確認した。
mkdocs build --strictと差分の空白検査が成功した。
これは配置・動作確認用の架空データによるモックであり、権限制御を実アプリへ実装・検証した結果ではない。
実装（2026年9月20日）
- 現行本番
801ed69915846bc42ec6e1f1342fc4f9f9aa6771を土台に実装した。9項目を設定にまとめ、一般職員はクラス・料金ルールの2項目を利用できる。保護者のローカル認証が無効なら登録受付の項目を隠す。 - 管理者の設定保存はDB上の有効な管理者とCSRFを検証し、変更前後・変更者・時刻を同じトランザクションで記録する。
- 新規テーブル3個（設定・履歴・新しい職員ログインの非操作時間）を追加する。既存の認証テーブルや既存データの書換えは不要。起動時の既存のスキーマ作成処理で追加する。
- 配備前の職員ログインは環境変数の従来の非操作時間を維持する。配備後に作るログインはその時点の設定を固定し、保存後の設定変更と混在させない。Cookieの最長時間も同じログイン結果から設定する。
- 5分設定で操作を続けても更新間隔が期限に達してしまわないよう、新規ログインの更新間隔を非操作時間の半分と5分の短い方にした。
- 職員Cookieがある状態で発行するフォーム用CSRF Cookieは24時間とし、認証が有効なのに8時間で保存だけ失敗することを防ぐ。CSRFの照合・ログアウト時の破棄と、保護者だけで利用する場合の既定8時間は維持する。
- 非操作時間の単位を切り替えると値も換算する。分に換算して整数になる小数時間を許可する。未保存表示、設定後の時間例、取消、未保存で戻る確認を実装した。
- 導入だけで既存の設定値を12時間へ変更しない。管理者が「勤務中は12時間維持」→「設定を保存」を実行すると、次回ログインから12時間になる。
本実装の検証
- 本番用版の全体テスト783件成功（359.38秒）。その後、単位換算をモックに合わせ、実アプリからの操作用JavaScript配信も検証し、設定・認証の対象テスト34件を再実行して全件成功した。
- 管理者・編集可・閲覧のみの設定一覧、未ログイン拒否、無効化・降格済み管理者の拒否、CSRF拒否、入力値保持、保存監査を確認。
- 旧ログインの非操作時間保持、設定変更前後の期限とCookieの一致、期限切れ・ログアウト・資格情報変更・利用停止の失効、最短5分での操作継続を確認。
- ローカルの合成DBで実装した画面を開き、保存、取消、未保存で戻る確認、入力エラー、30分から0.5時間への換算と保存を確認。320px幅で入力と設定一覧に横方向のはみ出しがないことを確認。
- Ruffと差分の空白検査が成功。MkDocs strictも成功。
配備用の git archive で backups export-ignore が templates/backups にも適用されることを確認した。除外指定を /backups に限定し、実データのバックアップを除外しながら、設定画面のテンプレートは配備物に含める。配備物内で既存8画面のテンプレートも検証する。