Q.StudioからCloudflareへ移す場合、Cloudflare Workersの有料プランは必要ですか？

お知らせを社内の担当者が管理画面から書くのか、制作側がファイルを直して公開するのかで、合うCMSは変わります。

担当者が自分で書くなら、管理画面で入力した内容をAPIで取り出す仕組みのmicroCMSが候補になります。サイト本体のデザインを崩す心配がなく、必要なテキストや画像データだけをAPI経由で取得して表示できる設計です。管理画面にログインしてタイトルや本文を入力し、公開します。静的なサイトでは、公開のあとにビルドが走るようWebhookを設定しておけば、サイトへの反映まで自動で進みます。

microCMSの料金プランによると、クレジットカードの登録が要らない無料のHobbyプランがあります。メンバーは最大3名まで登録可能で、作成できるAPIは最大5個まで。お知らせ欄やブログ記事の更新だけであれば、無料枠の範囲で十分に賄えますね。ただし、月間のデータ転送量が20GBまでに制限されており、これを超えるとAPIの配信が停止する点には注意が必要です。

一方、外部のサービスを増やしたくないなら、Astroのsrc/pages/にMarkdownファイルを置く方法もあります。置いたファイルがそのままサイトのページとして扱われるため、お知らせ1件を1ファイルで書けます。とはいえ公開するにはビルドとデプロイの作業が要るので、HTMLやコマンドに慣れていない担当者が毎回更新するのは少し難しいかもしれません。

Cloudflare Pagesを無料プランのまま運用する場合、どのような数値の上限が設けられているのでしょうか。無料プランの上限は、月500回のビルド、1サイトあたり20,000ファイル、1ファイル25MiB、1プロジェクトあたり100件のカスタムドメインです（Pagesの制限）。

これらの数値は変わることがあるため、記事や画像が多いサイトは同じページで最新の値を確かめたうえで、書き出したファイル数が上限に収まるかを先に数えておきましょう。

Functionsを呼び出さない静的ファイルへのリクエストであれば、閲覧数や転送量に制限はなく、無料かつ無制限に配信を続けられます。一方で、サーバーサイドの動的処理を担うPages Functionsを追加した場合は利用枠の計算が変わります。Functionsで50,000件、Workersで50,000件使えば、その日の枠は残らない計算になります（Pages Functionsの料金に例があります）。この日次枠はUTC午前0時にリセットされる仕組みです。

Functionsを組み込んだプロジェクトでは、既定ですべての通信がFunctionsを経由してしまいます。静的ファイルの無料・無制限枠を活かしたい場合は、_routes.jsonファイルを作成して静的ルートをFunctionsの対象から除外しておきます。Pages CIやWranglerはfunctionsディレクトリを見つけるとこのファイルを自動で作るので、除外の範囲が合っているかを開いて確かめてください。

たとえば制作会社の担当者と社内の広報担当が、同じTeamプランのWorkspaceに参加しているとします。Studioのセキュリティ告知では、全登録顧客について、ユーザー名、メールアドレス、ハッシュ化されたパスワードなどのアカウント情報が流出した可能性があると公表されています。対象の範囲は、告知の最新の内容で確かめてください。Teamプランのメンバーも、Studioにアカウントを登録している以上、この対象に含まれます。パスワードは、Studioのパスワードを設定していればアカウント設定の画面から変更し、GoogleやFacebookのログインだけで設定していなければ変更時にエラーが出ても追加の対応は要らず、今のパスワードが分からなければログイン画面の「パスワードをお忘れですか？」から再設定する、と案内されています。

パスワードは平文のまま保存されていたわけではなく、ハッシュ化されていました。それでも元のパスワードを割り出される可能性を完全には否定できないため、Studioは変更を求めています。

通常の変更手続きは、管理画面の右上にあるアイコンから［設定］を選び、［アカウント］内の［パスワードを変更］から進めます。現在のパスワードと新しいパスワードを入力して保存すれば完了です。

社内の連絡網を通じてチーム全員の登録状況を確認し、必要なメンバーから速やかに変更を進めてもらう流れを作っておきましょう。

急なアクセスの増加でWorkersの無料枠を使い切ってしまった場合、公開しているWebサイトは完全に停止してしまうのでしょうか。止まるのはWorkerを通るリクエストで、Workerを通らない静的ファイルの配信はそのまま続きます。実際、Workers Static Assetsなどを利用して配信している静的ファイルへのリクエストは、そもそもWorkerの実行回数枠を消費しません。

Workers Freeで提供されるリクエスト枠はアカウント単位で1日100,000件であり、UTC午前0時にリセットされます。この上限を超えた場合、Workerスクリプトを実行する動的な通信に対しては原則としてError 1027が返され、処理が遮断されます。ただ、この動きはルートごとに設定できますよ。Fail openにすると、Workerを迂回してWorkerが無い状態と同じように応答します。Fail closedにすると、1027のエラーページを返します。

ちなみに、OpenNextで配信する場合、run_worker_firstがfalseならリクエストはWorkerに届く前に処理され、課金もされません。既定値もfalseです。

日次10万件の上限を気にせず安定して動かしたいなら、有料のWorkers Paidへの移行が選択肢に入ります。Paidには1日あたりのリクエスト上限がなく、基本枠を超えた分は従量課金になるため、日次の上限でWorkerのリクエストが遮断されることはありません。料金はWorkersの料金体系で確認できます。