ひとことで言うと
D1はCloudflare Workersから`env.DB.prepare('SELECT ...')`のようなSQLで直接呼び出せるサーバーレスSQLiteデータベースです。ユーザーテーブルやアクセスログテーブルをD1に持ち、Workers上のコードがリクエストごとにクエリを発行するという構成が典型的な使い方になります。
SQLiteを採用しているため、PostgreSQLやMySQLに比べてスキーマが軽量で、プロトタイプや小〜中規模のWebアプリに向いています。2024年以降はGA（一般提供）となり、無料プランでも5GBのストレージと1日500万行の読み取りが利用できます。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
HTML共有で関係する場面
HTMLプレビュー共有サービスがパスワード認証やメール認証を実装する際、認証情報や共有リンクのメタデータ（有効期限・閲覧者メールアドレスなど）の保存先としてD1が活用されます。Workers内でJWTを検証し、D1の`sessions`テーブルを参照してアクセス可否を判断するパターンが一般的です。
AI生成HTMLのバージョン管理にD1を使うケースもあります。`pages`テーブルに`slug`・`html_url`・`created_at`・`is_active`カラムを用意しておけば、差し替え時に古いバージョンをD1側で無効化するだけでURLを変えずにコンテンツを更新できます。実ファイルはR2に置き、D1はメタデータのみ管理するという役割分担が効率的です。
よくある誤解
「D1はファイルを保存できる」と思われることがありますが、D1はテキストやJSON形式のデータを扱うRDBであり、画像や大きなHTMLバイナリを直接保存する用途には向いていません。HTMLのソース本体はR2に置いてURLだけD1に記録するのが正しい設計です。
「WorkersとD1は同一リージョンにある」という誤解もあります。実際にはD1のプライマリデータベースは特定のリージョンに配置されており、地理的に離れたWorkerからクエリすると若干のレイテンシが生じます。ただしD1にはread replicaが自動的に作成される仕組みがあり、読み取り性能の低下は多くの場面で軽減されます。
安全に使うための注意点
D1へのアクセスはWorkers経由に限定し、D1のバインディング（`env.DB`）をブラウザから直接呼び出す経路を作らないことが基本原則です。Wrangler設定で`wrangler.toml`のバインディング名を適切に管理し、誤って公開APIがSQLを直接受け取るような実装にならないよう注意してください。
SQLインジェクション対策としてプリペアドステートメントを必ず使いましょう。`env.DB.prepare('SELECT * FROM users WHERE email = ?').bind(email).first()` のように`?`プレースホルダにユーザー入力を渡す書き方にすることで、任意SQLが実行されるリスクをほぼゼロにできます。文字列連結でクエリを組み立てる実装は絶対に避けてください。
よくある質問
D1のデータはどこのデータセンターに保存されますか？
デフォルトでは最初にデータベースを作成したリージョン付近のCloudflareのデータセンターに配置されます。ダッシュボードでロケーションを指定することも可能で、日本リージョンを選択するとAPACデータセンターに優先配置されます。
D1はトランザクションをサポートしていますか？
はい。`db.batch()`を使って複数のSQL文をアトミックに実行できます。たとえばユーザー登録と初回セッション作成を同時に行うときに利用でき、どちらかが失敗した場合は両方ロールバックされます。
無料プランのD1でHTMLプレビューサービスを運営できますか？
小〜中規模なら十分です。無料プランで1日500万行の読み取り・10万行の書き込みが可能で、共有リンクのメタデータ管理程度であれば余裕を持って収まります。月間アクセスが数十万件を超えたら有料プランへの移行を検討してください。