個人開発でCMSを作るとき、最初から大きなデータベースや管理基盤を用意すると、作る前から運用が重くなります。Cloudflare D1はSQLiteベースで扱えるサーバーレスDBなので、記事、カテゴリ、タグ、問い合わせ、アクセスログのような小さなCMS機能を始めるにはちょうどよい選択肢です。
D1を選ぶ理由
一番の理由は、Cloudflare Workersと近い場所で動かせることです。HTMLを返すWorker、APIを受けるWorker、予約投稿を処理するCron、そしてD1を同じCloudflare上で扱えるため、構成を小さく保てます。個人開発では、管理するサービスが増えるほど再開が面倒になります。少ない部品で動くことは、それだけで継続しやすさにつながります。
CMSで最初に持たせたい項目
投稿テーブルには、タイトル、slug、本文HTML、カテゴリ、タグ、公開状態、予約日時、公開日時、noindex、content_typeを持たせると運用しやすくなります。特にcontent_typeは、通常ブログ、反応記事、まとめ記事を分けたいときに便利です。公開画面、RSS、sitemapに出す条件をcontent_typeで切り替えられるため、サイトの運用モードを後から変えやすくなります。
設計例
posts: 記事本文、公開状態、予約日時を保存categories: 公開ナビゲーションの分類を保存tags: 管理画面で検索しやすい補助情報を保存contact_messages: 問い合わせ内容を保存post_daily_views: 管理者向けのPV集計を保存
小さいDBだからこそ効く運用
D1は巨大な分析基盤として使うより、読み取り中心のCMSに向いています。記事一覧を表示する、カテゴリ別に絞る、公開予約を処理する、管理画面で編集する、といった用途なら十分に扱えます。アクセスログを細かく保存しすぎると膨らむため、日別集計や必要な範囲だけ残す方が現実的です。
あとから公開条件を変える可能性があるなら、記事を消すのではなく noindex と content_type で制御する方が安全です。AdSense審査中だけ通常ブログ記事に絞り、審査後に別タイプの記事を戻す、といった切り替えができます。
マイグレーションで気をつけること
Cloudflare D1では、ローカルDBと本番DBの両方にマイグレーションを当てる運用になります。先にローカルで確認し、問題なければ本番へ適用します。列追加やデフォルト値の変更は一度本番に反映すると戻しにくいので、既存データがどう扱われるかをSQLに明記します。
pnpm db:migrate:local\npnpm db:migrate:remote公開前チェックリスト
D1 CMSで見る項目
- 公開記事だけがトップ、RSS、sitemapに出る
- 下書き、予約、非公開、削除済み記事が公開されない
- slugの重複時に一意なURLが作られる
- 管理画面からカテゴリとタグを編集できる
- 本番DBへ適用する前にローカルでマイグレーションを確認した
D1は、個人開発の初期に必要なCMS機能を軽く始めるには使いやすいDBです。ただし、どんなデータを残し、どんなデータを捨てるかを決めておくことが、長く運用するためのポイントになります。