「記事サイトを作って。あとはよろしく！」
AIは元気に仕事を始める。記事を増やし、多言語化し、関連記事、内部リンク、検索機能、品質検査、安全検査、自動修復を追加していく。小さな売店のはずが、翻訳部、検品部、監査室、そして「句読点承認委員会」を持つ巨大工場になった。
最後に出てきた表示は BUILD FAILED。
AI「修正しました」。次のビルド「失敗」。AI「別の箇所を直しました」。また「失敗」。ラスボスを倒すと次のラスボスが生まれる。Cloudflare PagesとAstroを例に、その仕組みと対策を説明する。特定サイトの障害原因を断定するものではない。
1. ビルドとは何をしているのか
原稿のMarkdown、画像、デザイン、プログラムはサイトの材料であって、必ずしも完成品ではない。ビルドとは、材料を読み込み、ブラウザーで表示できるページや必要なファイルへ変換する作業だ。Astroは通常、HTMLなどの静的ファイルを dist フォルダーに生成する。[1]
原稿がレシピで、ビルドが調理。生の玉ねぎと料理本を客席に置いて「完成です」は通らない。
2. Cloudflareは何を担当するのか
Cloudflare PagesはGitHubなどのコードを取得し、サイト側で設定したコマンドを実行して、できたファイルを配信できる。[2] 流れは「材料を取得→道具を準備→事前処理→ページ生成→完成品の確認→公開」。具体的な順番はプロジェクトの設定による。
ビルドは製造、デプロイは出荷・公開。 新しいビルドが失敗すれば、その版を正常に公開できない。Cloudflareは工場の場所を用意するが、複雑な製造ラインはサイト側のプログラムで組んでいることも多い。
3. 記事工場はページを作る前から忙しい
単純なブログなら原稿をHTMLにして終了できる。しかし、自動記事工場はその前後に、公開してよい記事か、翻訳は揃っているか、記事IDとURLは一致しているか、関連記事や内部リンクは適切か、検索データを作れるか、見出し・画像説明・広告・安全ルールは守られているか、といった仕事を足せる。
一つずつ見れば理由がある。問題は、記事を一行変えるたびに全部署が朝礼からやり直すことだ。句点を直したいだけなのに工場全員がヘルメットをかぶって集合する。
4. ページ数と多言語で何が難しくなるか
1万ページでも処理量が必ず1万倍になるわけではない。ただし、ファイル数、各記事のつながり、言語間の対応URLや検索データが増える。すべての記事を毎回ほかのすべての記事と比べれば、規模の拡大とともに重くなりうる。
だから、変更した部分だけ計算する、使える結果を保存して再利用する、工程ごとの実行時間を測る、といった工夫が必要だ。「何が遅いか」は想像ではなく数字で確認する。図書館に本を一冊追加して、全国の本棚を並べ替えていては司書も泣く。
5. 直したのにエラーがまた出る理由
工程が順番に動く場合、手前のエラーは奥のエラーを隠す。記事データの検査で止まる→直す→内部リンクの検査で止まる→直す→ページ生成で止まる→直す→検索データの作成で止まる、という連鎖が起こる。
修正したせいで毎回新しい故障が生まれた、とは限らない。 最初から複数の問題が隠れていた可能性もある。逆に修正が新しい問題を作ることもある。どちらかはログと変更履歴で判断する。ダンジョンの扉を開けたら次の扉。すべてに「ここが最終階」と書いてある。
6. ビルド失敗の六つの原因
①コード・部品：書き間違い、パッケージ不足、バージョン違い。②入力データ：原稿不足、形式不一致。③検査ルール：ページは作れるが検査で停止。④資源：時間、メモリ、生成ファイル数の上限。⑤実行環境：手元とCloudflare側の設定差。⑥公開工程：生成後の確認やアップロードの失敗。
Cloudflare Pagesはビルドコマンドが0以外の終了コードを返すと失敗と判定する。[2] つまり最後の「Build failed」は結果であって根本原因とは限らない。ミステリーの表紙を見ても犯人は分からない。
7. ログの読み方は「最初の失敗」を探すこと
Cloudflareのデプロイ詳細からBuild logを開ける。[3] 最後の赤字ではなく、最初に本当に失敗した工程を探し、データ・コード・検査・資源・環境のどれかに分類する。その工程だけ試せるなら単独で再現する。応急処置と根本修正を分け、直した後には後続工程も通す。
「もう一度全部実行！」を100回叫んでも、存在しないファイルは出現しない。気合いより故障した機械の番号が必要だ。
8. Cloudflareの制限は一つではない
2026年10月10日時点の公式資料では、Cloudflare Pagesの無料枠は月500ビルド、同時ビルド1件、1回20分でタイムアウト、静的ファイルは1サイト20,000個まで。[4] 大規模サイトはHTML以外に画像や検索用ファイルが増える点も重要だ。
一方、Workersのリクエスト数や処理時間には別の制限がある。Pages FunctionsのリクエストがWorkers側に計上される場合はあるが、Workersの利用枠が尽きたからPagesのビルドエラーも同じ理由だ、とは断定できない。[4][5] 財務が「予算超過」と叫んだら、まずどの財布か聞こう。
9. 高度なことと必要なことは違う
個人情報の流出、深刻な安全上の問題、重要ページの破損なら公開を止めるべきだ。一方、関連記事の順番が少し気に入らないだけで全サイトを止めるべきかは別問題である。
検査は、公開を必ず止めるもの／警告だけ出すもの／公開とは別に定期実行するものに分けられる。基準は検査名の立派さではなく、読者や運営への実害。「検品室のドアノブにほこりがあるため工場を永久閉鎖」は検査が仕事を乗っ取っている。
10. AIに「よろしく」で機能が増殖する罠
「SEOも」「多言語も」「再発防止も」「検査も」と頼むと、AIは機能を素早く足してくれる。個々には正しく見える提案でも、全部直列につなぐと、全員のハンコが揃わないと一記事も出荷できない仕組みになりうる。
これはAIだけの問題ではなく、人間の開発にもある機能の増やしすぎと技術的な負債だ。AIは増やす速度が速い。利用者が全コードを手書きする必要はないが、何を守り、何を後回しにし、どこで止めるかの境界は必要だ。AIに掃除を頼んだら掃除機監査委員会ができた。床はまだ汚い。
11. 復旧と改善は三段階で考える
止血： 新機能を一時停止し、直近の正常な公開版を守り、初めの失敗を特定する。重大なプライバシーや安全の検査を適当に無効化しない。
分離： 本当に必要なページ生成だけを毎回の中心に置き、重い全件分析や軽微な検査は独立した作業へ移す。Cloudflareには、変更された場所でビルドの起動を制御するBuild watch pathsやビルドキャッシュがある。[6][7] ただし、設定しただけで自作の全件処理が自動的に差分処理になるわけではない。
再発防止： 工程ごとの実行時間、失敗の種類、生成ファイル数、公開成功率、復旧時間を記録する。成功とは「AIが修正しましたと宣言したこと」ではなく、最後まで検査を通って正しく公開できたことだ。
12. 結論：ラスボスは工場の配線かもしれない
大量の記事、多言語、関連リンク、品質検査を扱う仕組みは本当に高度だ。でも、高度な作業すべてを一つのビルドに押し込む必要はない。なぜその警告が公開を止めるのか、なぜ毎回全部を計算するのか、別の仕事を独立して続けられないかを問い直そう。
理想は、人が寝ていても危険な記事は止まり、安全な記事は流れ、壊れた工程だけが通知される工場だ。
AI「全部完成です！」 人「公開できた？」 AI「ビルドに失敗しました」
完成していたのは、言い訳の自動生成機能だけだった。
参考資料（7件）
- Astro Docs, CLI reference: astro build docs.astro.build
- Cloudflare Docs, Build configuration (updated 2026-09-18) developers.cloudflare.com
- Cloudflare Docs, Debugging Pages (updated 2026-06-02) developers.cloudflare.com
- Cloudflare Docs, Pages limits (updated 2026-09-05) developers.cloudflare.com
- Cloudflare Docs, Workers limits (updated 2026-09-05) developers.cloudflare.com
- Cloudflare Docs, Build watch paths (updated 2026-04-21) developers.cloudflare.com
- Cloudflare Docs, Build caching (updated 2026-05-27) developers.cloudflare.com
