ブログもお知らせも自社運用 — 民泊サイトの内製CMS

はじめに

サイトを公開したら終わり、ではありません。季節のイベント情報、周辺のお店の入れ替わり、よくある質問の追加 — 宿のサイトは公開してからが本番です。

そのたびに制作会社へ依頼していては、費用も時間もかかります。この記事では、運営者自身がコンテンツを更新できる管理画面を内製した話を紹介します。

何を管理画面で扱い、何を扱わないか

更新頻度で線を引く

管理画面で扱えるようにするか、それとも設定ファイルに書くか。この判断は「どのくらいの頻度で変わるか」で決めました。

すべてを管理画面で編集できるようにすると、開発コストが膨らむだけでなく、触ってはいけない部分まで触れてしまうリスクが生まれます。キャンセル規定の文面を誤って消してしまったら大事故です。

メール文面をあえて編集不可にしているのはそのためです。管理画面では文面のプレビューだけを見られるようにし、変更したいときは開発側で対応する形にしました。

管理画面の構成

管理画面は「運営管理」と「コンテンツ管理」の2区画に分けています。

日々の予約対応と、じっくり行うコンテンツ更新では、頭の使い方がまったく違います。同じ画面に混ぜず、区画を分けたことで迷いにくくなりました。

管理画面のログインをどう守るか

二段構えの認証

管理画面は、インターネット上の誰でもURLを開けてしまいます。そこで認証を二段構えにしました。

パスワードを覚えてもらう方式にしなかったのは、使い回しや漏洩のリスクを避けるためです。メールを受け取れる人だけが入れる、というシンプルな仕組みにしました。

「誰が入れるか」を環境変数で管理する

ログインできるメールアドレスは、データベースではなく環境変数（サーバーの設定値）で管理しています。

これには理由があります。データベースで管理していると、万一データベースへ不正にアクセスされたとき、管理者を追加されてしまいます。環境変数なら、サーバーの設定を変えられる人しか触れません。担当者が変わったときも、設定から外せば即座に全セッションが無効になります。

画面を通れたことを権限と見なさない

ログイン画面を通過したことは、その先のすべての操作を許可する理由にはなりません。記事の削除、ゲスト専用ページの発行といった個々の操作でも、毎回あらためて権限を確認しています。

役割も「オーナー」「管理者」「編集者」「運用担当」「閲覧のみ」に分け、記事は書けるが予約情報は見られない、といった制御ができるようにしました。

操作履歴を残す

誰がいつ何をしたかは、すべて履歴として記録しています。記事の作成・更新・削除、画像のアップロード、ゲスト専用ページの発行 — トラブル時に「いつからおかしくなったか」を追えるようにするためです。

ただし履歴には、機密情報そのものは残しません。「ゲスト専用ページのURLを再発行した」という事実は残しますが、発行されたURLは記録しません。

3つのサブテーマ

安全な文章編集

自由に書けるエディタは、そのままだと危険なHTMLを埋め込む経路にもなります。編集の自由度と安全性をどう両立させたかは「リッチエディタと安全なHTML」で解説します。

画像の自動最適化

スマホで撮った写真をそのままアップロードすると、数MBの巨大なファイルがサイトに載ってしまいます。自動でリサイズ・軽量化する仕組みは「画像アップロードの最適化パイプライン」で説明します。

公開フローと多言語

下書き、予約公開、4言語への展開。運用を楽にする公開の仕組みは「下書き・予約公開・多言語」で解説します。

まとめ

内製CMSの設計で大事にしたのは、次の3点です。

1. 更新頻度で線を引く — よく変わるものだけ管理画面に。触ってはいけない部分は設定ファイルへ
2. 認証は二段構え、権限は毎回確認 — 画面を通れたことを権限と見なさない
3. 管理者リストは環境変数で — データベース経由での管理者追加を防ぐ