サーバー保守を抱えたくない制作会社へ。Cloudflare前提の構成で消える作業・残る作業

「そろそろPHPのバージョン、上げないとまずいですよね」。月末の保守チェックのたびに、こんな会話をしている制作会社は多いはずです。WordPress本体とプラグインの更新、改ざんの監視、バックアップの世代管理、深夜のサーバー障害の一次対応。1件だけなら大した量ではありません。問題は、この作業が納品件数のぶんだけ積み上がる構造のほうです。30件抱えれば、30通りの更新スケジュールと30通りの「何かあったら」を常に持ち歩くことになる。

この構造を崩す選択肢のひとつが、Cloudflare前提——Workers＋D1＋R2といったマネージドなサービスだけでサイトを組む方法です。保守がゼロになる、とまでは言いません。それでも「消える作業」はかなり具体的に挙げられます。自サイトの運用実態と合わせて整理しました。

「借りたマシンの健康管理」がまるごと消える

レンタルサーバーやVPSの保守は、突き詰めると「借りているマシンを健康に保つ仕事」です。OSのパッチ適用、PHPやデータベースの更新、SSL証明書の期限、ディスク残量の監視。どれもサイトの中身とは関係がないのに、怠ればサイトごと止まります。

Cloudflare Workersはサーバーレスの実行環境で、公式ドキュメントでもインフラを管理せずにコードを動かす仕組みとして位置づけられています。マシンを借りる契約ではないので、OSを更新するという作業自体がそもそも存在しません。SSL証明書も、Cloudflare管理の証明書なら発行と更新が自動です。

表の右側に残した通り、消えない作業もあります。大きいのはアプリケーション側の依存関係で、Astroやnpmパッケージの更新はCloudflareに移っても自分の仕事のまま。ただ、稼働中のサーバーを夜中に踏み台にされる類のリスクとは性質が違います。手元で試してからデプロイできるので、「更新したら本番が真っ白」という緊張感はありません。改ざんされにくさの仕組みはJamstack構成が改ざんに強い理由を書いた記事に譲ります。

tsudzuri.com自体、サーバー保守なしで動いている

このサイトはAstro＋ヘッドレスCMSのEmDashをCloudflare Workers上で動かし、データベースはD1、画像などのファイルはR2に置いています。運用を始めてから、サーバー保守と呼べる作業は発生していません。更新はコードを直してgit pushするだけ。サーバー応答（TTFB）は実測でおよそ10msです。チューニングを重ねた結果ではなく、構成を選んだ時点でこうなった、というのが正直なところです。構築の具体的な手順はEmDashをCloudflareにデプロイした手順の記事にまとめてあります。

制作会社の立場では、これは「保守契約の中身が変わる」話だと感じています。マシンの健康管理に使っていた時間を、コンテンツ更新の代行や改善提案のような、クライアントの目に見える仕事へ回せるからです。

正直に書いておきたい注意点

良い話だけ並べても判断を誤らせるので、引っかかりやすい点を先に挙げます。

• 無料枠には上限があります。D1は1日あたり読み取り500万行・書き込み10万行、ストレージは合計5GBまで。R2も月あたりの操作回数に上限があります。通常のコーポレートサイト規模なら枠内に収まることも多い一方、アクセスの多いサイトや画像を大量に扱う案件では事前の試算が要ります。
• Cloudflare自体に障害が起きれば、当然その影響を受けます。マシンの面倒を見なくてよいことと、障害と無縁でいられることは別の話です。
• 稼働中のWordPressサイトを移すかどうかは、また別の判断になります。運用体制やリニューアルの時期も絡むため、WordPressをやめる判断を整理した記事を材料にしてください。

保守は「引き受ける」より「減らす」へ

Cloudflare前提で組める実装者がパートナーに1人いると、その案件は納品後の保守リストにほとんど載らなくなります。抱えているサイトの保守負担を減らしたい制作会社の方は、お問い合わせからご相談ください。新規案件の構成選定の段階からお手伝いできます。

本記事は2026年8月時点の情報です。