このサイトはCloudflare Pagesでホスティングしていて、デプロイ経路を2つ用意しています。Gitリポジトリに push すると自動でビルド・デプロイされる経路と、npm run deploy で手元から直接デプロイする経路です。

// wrangler.jsonc
{
  "name": "portfolio",
  "pages_build_output_dir": "dist",
  "compatibility_date": "2026-06-01"
}

Git連携を主経路にする理由

普段の運用ではGit連携を使っています。push するだけでビルドからデプロイまでが完結し、デプロイ履歴もコミット単位で追えるため、変更内容とデプロイ結果の対応が明確です。CIを別途組む必要もなく、Cloudflareダッシュボード側で「ビルドコマンド: npm run build」「出力ディレクトリ: dist」の2つを指定するだけで完結する手軽さも魅力です。

それでもWrangler手動デプロイを残す理由

一方で、Git連携だけに依存しない経路もあえて残しています。理由は、Git連携のビルド環境はブラックボックスであり、手元のビルドと差異が出る可能性をゼロにはできないからです。ローカルで npm run build して生成された dist/ を、そのまま npx wrangler pages deploy で上げられる経路があれば、「ビルドは通ったはずなのに反映されない」といった状況でも、切り分けの選択肢を持てます。

アカウントの切り替えは .env で

CLOUDFLARE_ACCOUNT_ID=xxxxxxxx

Wranglerでのデプロイ先アカウントは、Gitで管理しない .env の CLOUDFLARE_ACCOUNT_ID と、Wrangler自体の認証プロファイルの組み合わせで決まります。この値をリポジトリに含めていないのは、単に「個人のアカウント情報をコミットしない」という一般的な理由に加えて、別の端末で作業する際に対象アカウントを明示的に選び直させる、という安全弁の意味もあります。.env が無ければデプロイ自体が迷子にならずに失敗するので、意図しないアカウントへの誤爆を防げます。

「自動化に任せる」と「手を出せる余地を残す」は両立できる

自動デプロイは便利ですが、それに100%依存すると、その経路が想定と違う挙動をしたときに手も足も出なくなります。主経路をGit連携にしつつ、緊急時や検証時に頼れる手動経路を並行して残しておくことで、自動化の利便性と、いざというときの制御可能性の両方を確保できていると感じています。