2026.05.12
ピアノ教室のホームページ刷新
はじめに
前回(5/11)の記事を公開した直後、つまり 5/12 の 0 時過ぎから、また 29 コミット入りました。前日が「リビルドを丸 1 日でやった」だったので、この日は 昨日HP刷新に向けて動き始め、運用に必要なものを詰めていく日 になりました。
ざっくり書くと:
- D1 binding を本番有効化: 朝 10:34 にコメントアウトを外して、Waltz の CMS が正式稼働
- 管理画面のパスワード変更機能を Waltz / Onbit 両方に実装: 運用担当に渡す前に必須
- a11y を詰めて Lighthouse スコア 100 に: Tabs を
aria-hidden→inertに変えたり、LINE pill の緑を darken して WCAG AA に合わせたり - スケジュール CMS の仕様を 3 回作り直した: 「時刻あり 4 コース」→「時刻なし 2 コース」→「年度始まり(4 月始まり)で A4 1 枚印刷」
- R2 + D1 で画像アップロード CMS を投入: 後からドラッグ&ドロップにも対応
- お知らせ専用ページ
/news/を新設: ナビも日本語表記に揃え、ホームの「スケジュール」タブは当月カレンダーに差し替え
時系列で書いていきます。
朝。D1 binding を有効化して、CMS が動く状態にする
前日の終わりは、wrangler.toml の D1 binding を一度コメントアウトして静的サイトだけ先に publish した状態で止まっていました。理由は前回の記事に書いた通りで、database_id がプレースホルダのままだと Cloudflare Pages の deploy 全体が rejected されるからです。
朝、まずやることは決まっていて、D1 を実際に作って、UUID を wrangler.toml に貼って、binding を有効化する。それだけで CMS が本番で動き始める(b7e51ca)。
パスワード変更画面を作る
admin 画面に「パスワード変更」を実装しました(632414a)。Waltz だけじゃなく Onbit の方にも同じものを入れておいて、今後の役に立てれるように⋯。両方とも同じ PBKDF2 + sessions のスキーマで動いているので、片方だけ実装してもう片方は放置、というのは将来の自分が必ず混乱するからです。
Lighthouse を詰める。a11y を 95 → 100 に
CMS が動いた段階で、いったん Lighthouse を回しました。Performance / Best Practices / SEO は既に 100 近く出ていて、引っかかったのは Accessibility だけ。具体的には:
- Tabs に
aria-hidden="true"を当てていたら、子要素にフォーカス可能要素があると違反(タブの非アクティブパネルの中の<button>や<a>がスクリーンリーダーから不可視なのに focusable な状態)。これはaria-hiddenではなくinert属性に変えて解決(5d055bb)。inertだと配下の focusable 全部が無効化される。 - Footer の LINE ボタンの背景が公式色
#06c755で、白文字とのコントラスト比 2.3:1。WCAG AA は 4.5:1 が必要。緑を#047a35まで darken して 5.47:1 に(bb4d9c4→29dc3ed)。ブランド色のグリーンは維持しつつ落とした感じで、現物見ても違和感は出てない。 - TeacherCard で「保有資格」を
<h4>にしていたら heading-order 違反。<h2>(講師名)→<h4>(資格)でh3がスキップされていた。<h3>に上げて解決(d848636)。
これで Accessibility が 100 になった。a11y って「対応した感」だけ出して中身が伴っていないことが多いと思うんですが、Lighthouse のスコアだけだと意味がなくて、実際に Android Chrome の TalkBack で読み上げさせるとどうなるか を確認するまでがセットだと思う。今回はそこまではやってない(時間の都合)。次の機会にやる。
デスクトップ Hero の装飾が消えていた
11:24 ごろ、「PC 画面で見たら雲とふわふわの丸が無くなってる」と気づき対応(5f80054)。前日の Hero リビルドの過程で、モバイル用の装飾を mobile only にする CSS を入れたつもりが、デスクトップ側からも消えていた、というやつ。
このタイプの「前は出ていたのに、いつのまにか消えていた」系のバグは、Tailwind の utility class で条件を間違えると簡単に発生する。ローカル開発はデスクトップで見ていることが多いので、モバイル ↔ デスクトップの両方で動作確認しないと気づけない。
Onbit 公式の about ページに競合比較を追加
Onbit 公式(apps/website/)の「なぜ Onbit か」ページに、競合との比較セクションを追加しました(40c9c5a)。
| DIY(自分でやる) | 制作会社 | Onbit | |
|---|---|---|---|
| 着手までの時間 | ✕ | 〇 | 〇 |
| 月額の固定費 | 〇 | ✕ | 〇 |
| 仕様変更のスピード | △ | ✕ | 〇 |
| 自分で更新できるか | 〇 | △ | 〇 |
みたいな表。これは前から書きたかったやつで、お問い合わせをくれた人が「Onbit と他の制作会社、何が違うんですか」を聞きやすくするための補助線。文章の中で書くより、3 列の表にした方が比較しやすい(これは商品ページの定石なので特に発見はない)。
その他諸々の変更や機能追加。。。
29 コミットを並べてみると、新規機能の実装 + 既存機能の作り直し + 既存機能のバグ修正 + 環境要因による壊れの修復、と 4 種類の作業が混じっています。最初から正解の仕様で作れたものは 1 つもなくて、ほぼ全部が「作って、見せて、聞いて、直す」のループでした。
特にスケジュール CMS は、3 回作り直したけど 1 回目の構造(schedule_entries テーブル + admin + 印刷用ビュー)がベースになっていて、捨てたのは表面的な「コース数」「時刻入力」「並び順」だけ。最初の構造を素直に組んでおけば、表面の作り直しは安い という設計の練習にもなりました。
明日以降の作業は、
- スケジュール CMS の運用負担を 1 週間試してもらって、運用上のバグを 1 個ずつ潰す
- 顧客向け CMS としての商品化に向けて密かに動く。
このあたり。今回の Waltz リビルドは「Onbit の自前 CMS 商品のドッグフード」という位置づけだったので、商品化に転用できる学びを早く外に出していきたいと思います。