Petal開発記録：GitHub Pages を卒業して Worker + R2 に移行した理由

最終更新：2026/02/05

OJapp Petal を作り始めて 3か月。最初は GitHub Pages を使って開発していました。 「無料で使える」「簡単に公開できる」「静的サイトなら十分」──そう思っていたけど、Petal の機能が増えていくほど、GitHub Pages の限界に何度もぶつかるようになりました。

この記事では、実際に開発しながら感じた “GitHub Pages 卒業ポイント” と、 Worker + R2 に移行したことで得られた圧倒的な快適さをまとめます。

GitHub Pages で感じた限界

① 更新しても反映されない（反映まで数分〜数十分）

Petal の UI を直したり、テキストを微調整したりしても、GitHub Pages はすぐに反映されません。
反映されたとしても、ブラウザ側のキャッシュ・iOS の影キャッシュ・GitHub の反映遅延が重なって、 「直ってるのか直ってないのか」すらわからない時間が続く。

開発スピードが完全に止まる瞬間が多かったです。

② キャッシュの二重地獄（Safari × GitHub）

iOS Safari のキャッシュは強力で、WebClip（ホーム画面アイコン）だとさらに更新されにくい。 そこに GitHub Pages の “遅延更新” が重なると、 「本番が古いまま」「手元のコードは新しい」「どっちが本当？」 という混乱が生まれる。

Webツール開発者としては、致命的な開発ストレスでした。

③ 動的処理ができない

Petalでは、 ・ユーザー認証 ・画像アップロード ・公開/非公開の切り替え ・承認フロー などが必要になります。

これらは静的サイトの GitHub Pages では不可能。 API を別場所に作り、構成が複雑になるのも大きな理由でした。

Worker + R2 を使ってみたら、世界が変わった

① 更新が即時反映（0.1秒〜数秒）

Cloudflare Worker にコードをデプロイすると、 ほぼリアルタイムで世界中に反映されます。

GitHub の「更新されてるか謎」な時間が完全に消え、 一気に開発スピードが2〜3倍になりました。

② API がネイティブに作れる

Petal の ・ユーザー情報 ・Petal 投稿データ ・承認ステータス
などはすべて Worker 上の API と D1 / R2 で処理しています。

「静的サイトに無理矢理 API を付ける」のではなく、 最初から API 前提で構築できるのが本当に楽。

③ 画像は R2 に置くだけで高速＆安定

Petal は “1人1投稿・画像必須” という仕組みなので、画像ストレージが重要です。

R2 に置いた瞬間、 ・読み込み高速 ・容量ほぼ気にしなくていい ・コストも激安 になり、GitHub のブロブ管理のストレスがゼロになりました。

④ iOS の影キャッシュ問題がほぼ解決

Worker を使うと、レスポンスヘッダでキャッシュ制御ができるため、 iOS 特有の “古いアイコンを読み続ける問題” が激減しました。

GitHub Pages ではどうにもならなかった部分なので、ここが最大のメリットかもしれません。

Petal の成長に合わせて、仕組みも成長していく

GitHub Pages は「静的ページを置く場所」としては最強ですが、 Petal のような ユーザー参加型・画像投稿型・承認管理型 のサービスには限界がありました。

Worker + R2 に移行したことで、 ・本番反映の速さ ・動的API ・キャッシュ制御 ・ストレージの拡張性 が揃い、Petal の開発は次のフェーズに進めるようになりました。

まとめ：GitHub Pages は卒業。Petal の未来のために Worker へ

GitHub Pages は本当に素晴らしいサービスです。 最初のOJappも、ここから始まりました。

でも、Petal の仕組みが成長するにつれて、 「静的サイト」から「サービス」へ進む必要が出てきた。

Worker + R2 への移行は、 そのタイミングが来たというだけの話です。

ここから Petal は、 もっと速く、もっと自由に進化できる。 そんな環境にやっと辿り着けました。

👉 Petalはこちら（開発中）