答え：AIの修正と、読者が開くサイトへの反映は別の仕事だからだ。 コードを保存できても、公開する仕組みが止まっていれば、画面は昨日のまま。寝ている間にAIが働いてくれる時代に、最後のドアだけ人間が押し続けるのは、なんとも惜しい。
1. 朝起きたら「ほぼ完了」。でも画面は変わっていない
夜に「デザインを直して、広告も配置して、多言語ページも届けて」と頼んだとする。朝の報告は立派だ。修正済み、検査済み、保存済み、未公開の翻訳は数千件。担当ごとの進捗まで整理されている。
ところが実際のサイトを開くと、旧デザインがお出迎えする。AIは徹夜、サイトは寝坊。なぜか働いた側と公開された側の出勤時間が違う。
ここで必要なのはAIを叱ることではなく、仕事を四つに分けて見ることだ。作った、保存した、配信した、読者の画面で確認した。 四つ目まで行って初めて「終わり」である。
2. 犯人は一人ではなく、出口が詰まっていた
サイトの更新には、修正を保管する場所と、実際に公開する仕組みがある。前者に新しいファイルが並んでも、後者が使えるとは限らない。さらに、文章を届ける作業とサイト本体のプログラムを入れ替える作業は別々に動く場合がある。
だから「記事は増えているのに広告や画面デザインは古い」「翻訳は完成しているのに外国語ページが出てこない」という、一見矛盾した状態が起きる。倉庫は満杯、出荷ゲートは閉鎖中。
一番つらいのは、担当が努力していないことではなく、いくら働いても最後の一か所で成果が積み上がってしまうことだ。
3. 無料枠の罠は二種類ある
Cloudflareの無料プランを例にすると、2026年10月時点でWorkers Buildsのビルド時間は月3,000分、Workersのリクエストは1日100,000回という別の制限を持つ。[1][2]
公開用のビルド時間切れは、新しいプログラムを配る経路の問題。一方、日々のリクエスト上限超過は、いま動いているサイトがアクセスを処理する経路の問題だ。
どちらも「無料枠切れ」なので一緒に見えやすいが、直す場所が違う。前者は無駄な再ビルドを減らしたり、認められた別の配信経路を整えたりする。後者はそもそもWorkerを通る通信を減らし、静的ファイルなどで代替できる部分を減量する。
ビルドの予算が増えても、閲覧の上限が自動で増えるわけではない。台所のガスを復旧させても、店の入口の渋滞は解消しない。
4. 失敗を繰り返して「失敗する権利」を使い切る
最悪の循環はこうだ。ビルドに失敗する。原因を十分に確かめず再実行する。また失敗する。無料の残り時間が減る。やっと直したころには、今月の実行枠が尽きている。
「失敗しました」の報告が十枚できたが、読者に届いた変更はゼロ。これでは失敗報告書の印刷工場である。
対策は地味で効く。失敗ログから同じ原因を特定し、手元で再現できる部分を直してから再実行する。内容だけ変えた記事なら、サイト全体の建て替えを毎回走らせない。一か所が止まっても、安全に独立公開できる文章まで巻き添えにしない。
5. 「AIが全部やる」の意味を一段上げる
夜中のAIに求めたいのは、成功した作業だけを並べる報告ではない。どこまで届いたか、止まったのはなぜか、独立して進められることは何かを自分で追い、許可された範囲で修理を続けることだ。
公開経路を増やす場合も、複数の担当が同時に古い版で上書きしない仕組みが要る。鍵や契約上の操作だけ所有者に残し、それ以外は同じ最新版と共通の進捗を見て進める。
そして最後に、実際の公開ページを開き、新しい文章やボタンが見えるところまで確かめる。「保存しました」と「公開されました」の間にある一文字違いが、運用では巨大な谷なのだ。
6. 寝ている間に働いてくれるAIの、本当の成績表
夜中に何件直したかより、翌朝何件が読者へ届いているか。失敗した仕事を何件回復したか。同じ故障を何回繰り返さずに済んだか。見るべき数字はそこにある。
人間は企画して、寝る。AIは修正し、失敗を拾い、出荷まで確かめる。
朝の報告が「いっぱい作りました」から「公開ページで確認しました」に変わったら、そのとき初めて言える。
おはよう。昨日よりサイトが起きている。
