概要
CloudflareやCloudflare Pagesなどのクラウド型サービスは、非常に便利です。
高速配信、CDN、HTTPS、自動デプロイ、GitHub連携、プレビュー環境、ロールバックなどを、比較的低コストで実現できます。
一方で、クラウド型の運用には従来のFTPやレンタルサーバー時代とは異なる注意点があります。
それが、過去バージョンが残り続けるという点です。
Cloudflare PagesやGitHub連携では、現在公開されているファイルだけでなく、過去のcommit、deployment履歴、preview deployment、CDN cache、検索エンジン側のcacheなど、複数の場所に過去の状態が残る可能性があります。
これは便利な反面、消したつもりでも、どこかに残っているという状態を生みやすくなります。
FTP時代との違い
以前のホームページ運用では、FTPでサーバーへファイルをアップロードする方式が一般的でした。
例えば、index.html を修正してアップロードすれば、サーバー上の古い index.html は上書きされます。
- 現在のローカルファイル
- サーバー上の公開ファイル
- 訪問者が見ているファイル
これらが、比較的一致しやすい運用でした。
もちろん、ブラウザキャッシュやサーバーキャッシュの問題はありましたが、基本的な感覚としては「上書きすれば古いものは消える」に近かったと言えます。
過去バージョンを残す場合も、多くは手動バックアップでした。別フォルダに保存する、zipで保管する、古いファイル名で残す、といった方法です。
クラウド時代は履歴が前提
一方、Cloudflare PagesやGitHub連携では、履歴を残すことが前提になっています。
- Git commit
- deployment history
- preview deployment
- rollback
- branch deploy
- pull request preview
これは非常に便利です。過去の状態に戻せる、誰が何を変更したか追える、テスト環境を自動で作れる、公開前に確認できる。こうしたメリットは、FTP時代にはなかなか得にくいものでした。
しかし同時に、重要な感覚の違いもあります。
今のファイルを消したことと、過去の状態が完全に消えたことは別という点です。
現在のリポジトリから削除しても、Git履歴、deployment履歴、preview URL、CDN cache、検索エンジン側のcacheなどには、過去の情報が残る可能性があります。
実務で起きやすいこと
実務では、次のようなものが残りやすくなります。
- 公開済みの古いHTML
- 古いmeta description
- 古いtitleタグ
- 誤って公開したテストページ
- 一時的に置いた画像
- 確認用のHTML
- 古いcanonical
- 古いsitemap.xml
- 削除済みURL
FTP時代であれば、上書きや削除によって「今のサーバー上には存在しない」と判断しやすい場面でも、クラウド運用では別の場所に残っている可能性があります。
特に注意が必要なのは、検索エンジン側のキャッシュです。
Cloudflare側やGitHub側で削除しても、GoogleやBingがすぐに検索結果から消してくれるとは限りません。検索結果にタイトルやスニペットが残ることもありますし、古いURLが「クロール済み」や「検出済み」としてしばらく残ることもあります。
そのため、削除したのに検索結果へ残るという現象は普通に起こります。
Cloudflareは非常に高速
Cloudflareの大きな特徴の一つは、デプロイ速度が非常に速いことです。
GitHubへpushすると、数十秒から数分でCloudflare Pagesに反映されます。さらにCloudflareのCDNによって、世界中へ高速配信されます。
これは非常に便利です。しかし裏を返すと、間違った内容も高速で公開されるということでもあります。
- テスト用の文章を残したままpushする
- noindex予定のページを公開してしまう
- 古いcanonicalを残したまま公開する
- 未確認の画像パスを公開する
- 顧客名や内部メモを残したまま公開する
そのため、Cloudflare Pagesを使う場合は、公開前確認のルールが非常に重要です。
- push前確認
- branch運用
- preview deployment確認
- sitemap確認
- robots.txt確認
- meta情報確認
- 画像・リンク確認
自動デプロイは便利ですが、確認を省略してよいという意味ではありません。
現在のファイルだけを見てはいけない
クラウド運用では、現在のファイルだけを見る感覚だと危険です。
実際には、複数のレイヤーに過去状態が存在します。
- GitHub履歴
- Cloudflare deployment履歴
- branch
- preview deployment
- CDN cache
- ブラウザcache
- Search Engine cache
- AI crawlerの取得履歴
つまり、クラウド時代のWeb運用では、何を公開しているかだけでなく、何がどこに残る可能性があるかを意識する必要があります。
特にCloudflare PagesとGitHubを組み合わせる場合、GitHubの履歴管理とCloudflareのdeployment履歴が重なります。さらに、検索エンジンやAIクローラーが取得すれば、外部のレイヤーにも情報が残る可能性があります。
AI時代はさらに注意が必要
現在は、検索エンジンだけでなくAIクローラーもWeb上の情報を取得する時代です。
- Googlebot
- Bingbot
- GPTBot
- ChatGPT-User
- Google-Extended
- ClaudeBot
- PerplexityBot
一度公開された情報は、検索エンジン、AIクローラー、キャッシュ、引用、学習データ、スクリーンショットなど、複数の場所へ残る可能性があります。
つまり、一度公開された情報は、完全削除が難しいという前提で考える必要があります。
- 顧客情報
- テストデータ
- 非公開予定の情報
- 社内メモ
- 仮の価格
- 未確認のサービス内容
- 個人情報
- APIキーや認証情報
こうした情報は、そもそも公開環境へ置かないことが重要です。
CloudflareやGitHubが危険という話ではありません。便利な仕組みだからこそ、公開される前提、履歴が残る前提で運用設計する必要があるということです。
Time合同会社での考え方
Time合同会社では、GitHub、Cloudflare Pages、Google Sites、Firebase、AIクローラーなどを組み合わせてWeb運用を行っています。
その中で重要視しているのは、クラウドは履歴が残る前提で設計するという考え方です。
- branch分離
- preview確認
- テスト環境分離
- push前確認
- sitemap管理
- robots.txt管理
- Search Console確認
- 公開前のmeta確認
- 不要ファイルを置かない運用
特に少人数運用では、勢いで公開してしまう事故が起きやすくなります。
Cloudflare Pagesは非常に速く、GitHub連携も便利です。しかしその分、公開までの距離が短くなります。だからこそ、軽い確認フローを決めておくことが重要です。
よくある誤解
CloudflareやGitHubを使うと、すべてを完全に管理できているような感覚になりやすいです。
しかし実際には、複数のレイヤーが存在します。
- Git履歴
- deployment history
- CDN cache
- preview URL
- 検索エンジン
- AI crawler
- ブラウザcache
そのため、削除した = 完全消去ではありません。
また、Cloudflareの管理画面上では問題がなくても、検索エンジン側には古い情報が残っている場合があります。逆に、GitHub上では削除されていても、過去のcommitには残っている場合があります。
クラウド運用では、どのレイヤーの話をしているのかを分けて考えることが重要です。
まとめ
FTPやレンタルサーバー時代は、基本的に上書きの感覚が中心でした。
しかし、Cloudflare PagesやGitHubを使う現在のクラウド運用では、履歴が残ることが前提になります。
- Git履歴
- deployment履歴
- preview deployment
- CDN cache
- 検索エンジンcache
- AI crawlerの取得履歴
Cloudflare PagesやGitHubは非常に便利です。自動デプロイ、高速配信、履歴管理、ロールバックなど、実務上のメリットは非常に大きいです。
しかし現在は、公開後も情報が残り続ける時代です。
そのため、何を公開するかだけでなく、何が残る可能性があるかまで含めて考えることが、クラウド時代のWeb運用では重要になっています。