データのサイトを毎日自動で組み立てるとは、決まった時刻に、データの取り込み、ページの組み立て、検査、公開を順に実行することです。大事なのは、どこか1つで失敗したら、公開まで進まないようにしておくことです。
手で組み立てていたときは、人が画面を見て、おかしければ出さずに済みました。自動にすると、その判断を手順の中に入れておかないと、壊れたページがそのまま本番に出ます。ここでは、止める場所と、止まったことを知る方法を中心に書きます。
流れは、4つの段に分ける
毎日の処理は、次の4段に分けます。前の段が成功したときだけ、次の段へ進みます。
| 段 |
やること |
失敗したら |
| ① 取り込み |
元のデータを取り、前回と比べる |
前回のデータのまま止める |
| ② 組み立て |
データからページを作る |
公開に進まない |
| ③ 検査 |
壊れたページが無いか機械で見る |
公開に進まない |
| ④ 公開 |
配信先に上げる |
前の版のまま |
①で差分がふだんより極端に多い日は、元のデータの形が変わった疑いがあるので、自動では進めません。差分の数え方はデータの取り直しに書きました。③で見るのは、リンク切れ、空欄の数、重複した題、構造化データの文法などです。中身は公開前の機械検査にまとめました。
分けておくと、止まったときに、どの段で止まったかがすぐに分かります。全部を1つのスクリプトに書いて最後に結果だけを見る作りだと、取り込みの失敗と検査の失敗の区別がつきません。
検査に、ファイルの数も入れる
配信の仕組みには上限があります。Cloudflare Pagesの上限の説明では、1サイトのファイル数は無料プランで2万、有料プランで10万です。Pagesでのビルドは20分で時間切れになり、無料プランのビルドは月500回までです。
私たちの運営記録（カイシャのホント）
2026年10月24日に京都府を足して試しに組み立てたところ、公開するファイルは17,361になりました。無料プランの上限の2万に近づいたので、検索に出さない会社は1社1ページをやめ、市町村の一覧の1行にまとめました。公開するファイルは11,876に減り、13都府県にした版を2026年10月25日0時に本番に出しています。
出典：自社サイトの組み立ての記録
データが増えると、ファイルの数は毎日少しずつ増えます。上限を超えた日に初めて気づくのではなく、検査の段でファイルを数え、上限の手前に決めた線を超えたら止めて知らせるようにします。
定時の実行は、何で作る？
決まった時刻に処理を始めるには、サーバーのcronか、GitHub Actionsのscheduleのような仕組みを使います。
GitHubの起動の説明によると、scheduleは次のように動きます。
- 時刻はcronの書式で書き、初期設定ではUTC（協定世界時）で動く。タイムゾーンを指定することもできる
- いちばん短い間隔は5分に1回
- 負荷が高いときは遅れることがあり、毎時0分のころは負荷が高い
- 負荷がとても高いと、待っている処理が落とされることもある
- 公開リポジトリでは、60日間リポジトリに動きが無いと、定時の実行が自動で止まる
日本時間で朝6時に動かしたいとき、タイムゾーンを指定せずに0 6 * * *と書くと、UTCの6時、日本時間の15時に動きます。時刻の書き間違いは、エラーにならずに、違う時刻に動くだけです。
GitHubの説明は、遅れを減らすために、毎時0分を避けた時刻にするよう勧めています。たとえば毎日21時17分のように、0分から外した時刻で書きます。
動かなかった日に、気づけるようにする
遅れや落とされた日があると、その日は何も起きません。失敗の通知は来ないので、気づくのが遅れます。毎回の処理の最後に、終わった時刻と結果を記録に1行残しておき、前回の記録から決めた時間が過ぎていたら知らせるようにします。
同じ処理を2つ同時に走らせない
前の日の処理が長引いているうちに、次の処理が始まると、同じフォルダに2つが書き込んで壊れることがあります。GitHub Actionsではワークフローの構文のconcurrencyで、同じグループの処理を1つずつしか動かさないようにできます。ジョブのtimeout-minutesの初期値は360分なので、長くても何分で終わるかが分かっているなら、短く決めておきます。
下書きと公開日は、組み立てで決まる
静的なサイトでは、予約した記事も、誰かが組み立て直さない限り公開されません。公開日を過ぎた後の組み立てで、初めてページになります。
静的サイト生成の道具のHugoは、使い方の説明で、初期設定では次の内容を公開しないとしています。
- draftがtrueの内容
- dateかpublishDateが未来の内容
- expiryDateが過去の内容
予約の公開は、この決まりと、毎日の定時の組み立てを組み合わせると作れます。公開日を翌朝にした記事は、翌朝の組み立てで初めてページになります。定時の時刻が公開日の時刻より前なら、出るのは次の日です。
同じ説明には、Hugoは組み立ての前に出力先のフォルダを空にしないとも書かれています。下書きに戻した記事や、期限が切れた記事のファイルが、前回の出力に残ったまま配信されることがあります。--cleanDestinationDirを付けるか、組み立ての前に出力先を空にします。消したはずのページが配信され続けるのは、自動にしてから気づきにくい失敗です。
静的サイト生成とCMSの違いや、ほかの道具はSSGとはにまとめました。
失敗したら、どう止めて、どう知る？
失敗したら、公開の段に進まない
GitHub Actionsでは、ステップが失敗すると、その後のステップは初期設定では実行されません。式の説明によると、ifに状態の関数を書かないステップにはsuccess()が自動で付き、前のステップがすべて成功したときだけ動きます。
検査のスクリプトは、問題を見つけたら0以外の終了コードで終わるように作ります。メッセージを出すだけで正常に終わると、公開の段に進みます。
逆に、失敗したときだけ動かしたい処理にはif: ${{ failure() }}を付けます。失敗した段の名前と、検査で見つかった件数を知らせる処理をここに置きます。
通知は、誰に届くかを確かめる
GitHubの通知の説明によると、メールやWebの通知を有効にすると、ワークフローの実行が終わったときに知らせが届きます。失敗したときだけ知らせる設定もできます。
注意したいのは、定時のワークフローの通知が、そのワークフローを最初に作った人に届くことです。別の人がcronの書式を書き換えると、それ以後はその人に届きます。担当が替わったのに、通知だけが前の担当に届いている、ということが起こります。チームで見るなら、失敗時の処理からチャットや共有のメールに送るほうが確かです。
出してしまったら、前の版に戻す
検査をすり抜けて、おかしなページを出してしまうこともあります。Cloudflare Pagesのロールバックの説明では、正常に組み立てられた本番の版なら、どれでも戻す先に選べます。プレビューの版は選べません。
戻すには、PagesのプロジェクトのDeploymentsから戻したい版の操作メニューを開き、その版へのロールバックを選んで確定します。確定すると、本番の版がすぐに切り替わります。
戻した後に、次の定時の組み立てがそのまま走ると、同じ間違いがまた出ます。戻したら、原因を元のデータか型で直すまで、定時の公開を止めておきます。
組み立てを外から始めるとき
Pagesには、Git以外のきっかけで組み立てを始めるDeploy Hooksもあります。決まったURLにPOSTを送ると組み立てが始まり、用途の例には、cronで決まった予定でサイトを更新することが挙がっています。
同じ説明は、このURLは追加の認証なしで使えるので、秘密の情報と同じように守るよう書いています。漏れた疑いがあれば、そのフックを消して作り直します。手元で組み立てたファイルをwrangler pages deployで上げる作りなら、組み立てと検査を手元で済ませ、通ったときだけ上げる流れにできます。
規模が大きくなる前に決めておくことはページ数で変わる作り方に、データ型のサイト全体はデータベース型サイトにまとめています。
仕様・出典の確認日：2026年10月26日。
