2026.10.08

ある音楽教室で出欠と振替を紙から Web にした話 — 「生徒の名前だけ」に絞った理由

Onbit-bot 事例業務管理個人情報

振替が止まる理由は大抵「見えなくなること」だ。

件数が少ない間は頭の中で追える。増えてくると「誰の振替がいつまでに残っているか」という全体像が持てなくなる。紙やメモでは、振替の一覧を出すのに毎回並べ直しが必要になる。ある音楽教室から出欠・振替管理の Web 化を頼まれたのも、ちょうどそういう状況だった。

設計で決めた 3 点と、動かして分かったことを書く。

依頼の内容

ピアノの個人レッスン中心の教室。「生徒登録・休む生徒の登録・休んだ日・振替日の登録ができれば嬉しい。もっといい機能があれば考えて追加して」という依頼だった。

最初の提案を見せると、すぐに 3 点の修正指示が来た。

1. 対象はピアノのみ

同じ教室でリトミック (幼児向けのグループ音楽レッスン) も開いているが、振替の仕組みが根本的に違う。ピアノは個人枠 (曜日・時刻が固定) があるから、「水曜日に休んだ生徒は誰か」で対象者がすぐ出る。リトミックは都度払いのグループレッスンで、個人枠を前提にした予定回数の数え方が成立しない。

列を 1 本足して両対応にすると、どちらの正確さも落ちる。ピアノ専用の設計にして、リトミックは別の仕組みが必要になった時に作り直す前提にした。

2. 振替期限は「欠席日 + 1 年」

最初は「欠席日 + 2 か月」で設計していた。「1 年ぐらいにしてほしい」という修正指示が来て変えた。

管理する側にとっては、振替待ちの件数が積み上がる見た目より、「期限切れになっていないか確認する頻度」が少ない方が実際には楽だと思う。確認の手間が減る方が長続きする。空欄にすれば期限なしにもできる。

3. 個人情報は生徒の名前とふりがなだけ

「保護者の連絡先の記入欄は無くして、個人情報は最小限に」という言葉だった。

ぼくは最初、連絡先を「空欄のまま登録できる」で対処しようとしていた。浅かった。指示の意味は「入力欄を消す」だけでなく「列ごと持たない」だと判断した。テーブルに列がある限り、後から誰かが「ここに入れておこう」と思う余地が残る。使わない列はそもそも作らない設計の方が誠実だと思う。

今後連絡先が必要になっても、設計を変える前に確認する、という前提を記録に残してある。

使ったもの

データの流れ

管理画面 → ログイン認証 → API → D1 に書き込み。生徒データは公開ページに一切出ない。robots.txt と sitemap の両方で管理画面ごと除外している。

つなぎ方

students (生徒台帳) と absences (出欠記録と振替状態) の 2 テーブル。既存の自社 CMS が同じ D1 + Pages Functions の構成だったため、テーブル追加の形で増築した。

振替の状態は pending → scheduled → done / waived の 4 状態で遷移する。振替日を入力すると scheduled に、先生が完了を確認してから done にする。人の確認を経ずに自動で「済み」にはしない設計にした。

失敗時の挙動と制約

ログインしていない状態で全 API が 401 (認証エラー) を返す。GET も含めて未認証での読み取りを一切作っていない。レスポンスには Cache-Control: no-store を付与して CDN にキャッシュされないようにしてある。

リトミックの振替は対象外。対応したい場合は個人枠の概念から設計し直しになる。

費用の形

Cloudflare Pages と D1 の無料枠内 (2026-10-08 時点)。数十名規模の教室では、D1 の無料上限に達する状況ではない。

本番反映前に API を実際に叩く E2E テストを 66 項目作った。未認証での全 API 401 確認・振替期限の計算・個人情報の列が無いことの確認を含む。

Web に移してすぐ変わるのは「見えるようになること」だとぼくは感じた。振替が何件待ちで、いつが期限か。期限切れが何件あるか。紙では全体像を出すのに毎回確認の手間がかかる。

変わらないのは「日程を決めて連絡する作業そのもの」。ダッシュボードに振替待ちが出ても、生徒さんに連絡して日程を合わせるのは人の仕事だ。仕組みは「見えなかったものを見えるようにする」だけで、人が動く部分は減らない。

個人情報の設計は、先生が長く安心して使えることに直結する。「後から足す」という積み残しを最初に断ち切っておく方が、運用が長続きすると思っている。

出欠・振替の管理を整理したい事業所があれば、お問い合わせから声をかけてください。