配信基盤の使い分け
配信先は2つに分かれている。
| プロダクト | 配信先 | 理由 |
|---|---|---|
| codese.net | Vercel | Next.js。ビルドが要る |
| ちょうぼっち | Vercel | Next.js + サーバ側の処理がある |
| Valscope | Vercel | Next.js。DBへのアクセスがある |
| サムネジェネレーター | Cloudflare Pages | 静的ファイルだけ。ビルドが無い |
分ける基準
サムネジェネレーターは推論をブラウザ側でやるため、サーバは モデルとHTMLを配るだけになる(ブラウザ内でAIを動かす)。 そこにNext.jsのビルド基盤を持ち込む理由が無い。
wrangler.toml に出力ディレクトリを書くだけで済んでいる。
name = "thumbnail-app"
pages_build_output_dir = "public"
Vercel の無料枠に当たると何が起きるか
デプロイ回数に日次の上限がある(Hobbyは1日100件)。 上限に達すると 新しいデプロイが通らなくなる。
2026-08-21にこれに当たり、4プロジェクトすべてで Gitからの自動デプロイを止めた。
{ "git": { "deploymentEnabled": false } }
自動デプロイを止めた副作用
mainへマージしても本番に反映されなくなる。 ここが一番危ない。
CIは通り、PRはマージされ、GitHub上では完了に見える。 それでも本番は古いままになる。
実際に、マージ済みの記事7本が本番で404のまま4日以上放置された。
気づいたのは、本数を目視で数えるのをやめて、リポジトリと本番の
sitemap.xml を突き合わせるスクリプトを書いてからだった。
python3 scripts/check-blog-published.py
「マージした」と「公開された」を別の状態として扱う。 自動デプロイを止めるなら、突き合わせる手段を同時に用意する。
デプロイは明示的に起動する。
bash scripts/vercel-deploy.sh top-page
教訓
無料枠の上限は「使いすぎたら止まる」だけでは終わらない。 回避策として入れた設定が、別の前提を静かに壊す。
止めた機能が何を担保していたかを書き残しておかないと、 数日後に「なぜ反映されないのか」から調べ直すことになる。