妻ブログを Cloudflare Pages Direct から GitHub 連携に切り替えるための手順メモ

daily-log

きっかけ

妻のブログのディレクトリを開いて、ふと「これって自分の GitHub で管理してたっけ？」と手が止まった。リポジトリ名を確認したら自分のアカウント配下に確かにあった。ただ、デプロイ経路の記憶が曖昧で、Cloudflare Pages に Direct Upload で投げていたのか、GitHub 連携で動かしていたのかが思い出せない。

Claude Code に Cloudflare 側のプロジェクト設定を見てもらって、答えが出た。Direct Upload で動いていた。 ローカルから wrangler pages deploy で直接ファイルを上げているタイプで、GitHub とは何も繋がっていない。

何が困るのか

このまま GitHub に push しても、Cloudflare 側は気付かない。妻が更新するたびに自分がローカルから手で wrangler を叩く運用になる。そもそも妻と自分で同じ環境を共有するなら、リポジトリの master を共通の真実にして、そこに push したら勝手にデプロイされる状態が望ましい。

ここで悩ましいのが、Cloudflare Pages の仕様。

Direct Upload プロジェクトと Git 連携プロジェクトは「プロジェクト種別」として別物で、後から切り替えられない。

つまり、いま動いている Direct プロジェクトを途中から GitHub 連携に変更するボタンは存在しない。作り直すしかない。

救いはドメインを自分が握っていること

一瞬「ドメイン移行が面倒だな」と肩を落としかけたが、よく考えたらドメインのレジストラ管理は自分でやっていて、Cloudflare のネームサーバーに向けているだけ。Cloudflare Pages のプロジェクトを作り直しても、新しいプロジェクト側にカスタムドメインを再紐付けすればそのまま使える。DNS の整合性さえ取れれば、ユーザー側からは何も変わらない。

影響範囲は Cloudflare Pages のプロジェクト再作成だけで済む、と判断した。

採用した運用イメージ

  • リポジトリの master に push → Cloudflare Pages が GitHub webhook を受けて自動ビルド → デプロイ
  • リポジトリは妻と Collaborator として共有
  • 自分はドメインと Cloudflare 側のオーナーシップを保持
  • 妻は記事を書いて push するだけ、ローカルから wrangler を叩く必要なし

「自分が管理、更新は妻」という非対称な役割分担に、GitHub 連携がきれいに当てはまる。

実際の手順

ここから先は、当日 Claude Code に整理してもらってカレンダーに貼ったメモの抜粋。

Step 1. 既存の Direct プロジェクトを削除する

  1. Cloudflare ダッシュボードにログイン
  2. Workers & Pages → 対象のブログプロジェクトを開く
  3. Custom domains タブでカスタムドメインを 先に外す（外さないと新プロジェクトに付け直せない）
  4. Settings → Delete project でプロジェクトを削除

ここでドメインを先に剥がさないと、新プロジェクト側で「このドメインは既に他のプロジェクトに紐付いている」と弾かれる。剥がしてから消す、の順序を守る。

Step 2. GitHub 連携で新プロジェクトを作る

  1. Workers & Pages → Create application → Pages → Connect to Git
  2. 対象の GitHub リポジトリを選択
  3. Production branch を master に設定
  4. ビルドコマンド・出力ディレクトリをブログのスタックに合わせて入力
  5. 環境変数があれば登録

このタイミングで初回ビルドが走り、ビルド成功すれば Cloudflare 配下の *.pages.dev のサブドメインで一旦アクセスできる状態になる。

Step 3. カスタムドメインを新プロジェクトに付け直す

  1. 新プロジェクトの Custom domains タブで Add custom domain
  2. 手元のドメインを入力
  3. DNS レコードを Cloudflare 側が自動で書き換えてくれる（同じネームサーバー配下なので一発）
  4. 数分待つと SSL 証明書が再発行される

ここが一番ハラハラする工程だが、ネームサーバーが Cloudflare に向いている前提なら、レコードの調整は Cloudflare 内部で完結する。

Step 4. master プッシュで自動デプロイを確認

  1. ローカルで適当な変更（README に1行追記など）を加えて master に push
  2. Cloudflare の Deployments タブで新しいデプロイがキューに入るのを目視
  3. ビルドが緑で終わり、本番 URL に変更が反映されているかブラウザで確認

ここまで通れば、運用切り替え完了。以後は妻が記事を書いて push するだけで、自分が wrangler を叩く出番はなくなる。

Step 5. リポジトリを妻と共有する

  1. GitHub のリポジトリ Settings → Collaborators
  2. 妻のアカウントを Collaborator として招待
  3. 妻側で招待を accept、ローカルに clone

ハマりどころ予防

ドキュメントに残しておきたかったのは、たぶん未来の自分が踏むであろう小さい罠。

  • カスタムドメインを剥がす前に旧プロジェクトを削除しない — ドメインが旧プロジェクトに紐付いたまま消すと、新プロジェクト側で再紐付けする際に「他プロジェクトと衝突」のエラーが出ることがある。先に剥がす。
  • Production branch の名前を間違えない — 妻ブログのリポジトリは master のまま運用しているので、デフォルトの main で作るとビルドが走らない。
  • ビルドコマンドの設定を旧プロジェクトから引き継ぐ — Direct Upload では wrangler 側で完結していた処理が、GitHub 連携では Cloudflare ビルダー側に移る。package.json の scripts と環境変数を確認しておく。
  • 環境変数を忘れない — Direct Upload では使っていなかった環境変数が、GitHub 連携プロジェクトのビルド時には必要になる場合がある（API キーなど）。

カレンダーに残す

「これ手順をドキュメントに残しておいてください。Google のスキル使って、カレンダーのメモ欄に貼っておいてください」と Claude Code に投げて、当日の 16 時に予定を作ってもらった。手順書はメモ欄に貼り付けてある。

将来「あ、これいつだったっけ」と探すとき、月日記事と Google カレンダーの両方から辿れる二重化。記事だけだと検索性が弱いし、カレンダーだけだと文章が消える。両方に置くと両方から思い出せる。

学び

形容詞で言えば「Cloudflare の Direct Upload は罠だった」になる。動詞で書き直すと、Direct Upload で立ち上げたプロジェクトは GitHub 連携への切り替えボタンが存在せず、最初から作り直さないといけない。 立ち上げのときに何を選んだかで、後の運用の自由度が決まる。

最初の 1 分の選択が、後の 1 時間の作業を決める、というやつ。妻のブログだから影響は小さかったが、これがクライアント案件だったらと考えるとゾッとする。新規 Pages プロジェクトを作るときは、迷ったら GitHub 連携で始めるのを既定にしようと決めた。