PR本記事にはプロモーション（アフィリエイトリンク）が含まれる場合があります。
CONTENTS目次
結論から書きます。cron（決まった時刻に処理を自動実行する仕組み）でブログ記事を週1本自動生成していたのですが、それが1週間ほど止まっていたことに、私は1週間経ってから気づきました。しかも肝心の失敗ログが消えていて、原因を確定できませんでした。この記事では、何が起きて、何を調べて、結局どこまで分かったのか、そして「止まったことに気づく仕組み」をどう足したのかを、うまくいかなかった部分も含めて正直に書きます。プログラミング未経験でAI任せの自動化を組んでいる方に、同じ落とし穴を先に知ってもらえたら嬉しいです。
この記事でわかること
- cronで自動化したブログが1週間止まっても気づけなかった実録
- Vercel無料プランはログ保持が短く、原因を後から追えないという落とし穴
- 「止まったことに気づく仕組み」まで作らないと自動化は危ういという学び
8月24日から更新が止まっていた
このブログの記事は、cronで週に1本、自動生成・自動公開する仕組みにしています。cronというのは「毎週この曜日のこの時刻に、この処理を動かして」と予約しておく機能のことです。私はコードを書けないので、AIに手伝ってもらいながらこの仕組みを組み、あとは放っておけば勝手に記事が増える、という状態にしていました。
ところがある日ふと管理画面を見て、8月24日以降まったく更新が止まっていることに気づきました。気づいたのは止まってから1週間ほど経った後です。自動化のこわいところはまさにここで、動いていない間もこちらは「勝手に動いているはず」と思い込んでいるので、異常にまったく気づけません。
自動化は一度組むと安心してしまいますが、放置は「動いている前提」に乗っかっているだけだと痛感しました。記事が増えていないという結果を、たまたま自分の目で見つけただけだったのです。
⚠️ 注意： 自動化は「組んだ時点」がゴールではありません。動き続けているかを確認する手段がないと、止まっても誰も教えてくれません。
調べた範囲は全部「正常」だった
まず原因を探そうと、思いつく場所を順番に確認しました。私のような未経験者でもチェックできた項目を挙げます。
- Cronの設定（予約の書き方）→ 問題なし
- 環境変数
CRON_SECRETとANTHROPIC_API_KEY→ どちらも8月23日にProduction（本番環境）へ追加済み - Cron JobsのEnabled（有効化）→ オンになっている
環境変数というのは、APIキーなどの秘密の設定値を、コードに直接書かずに預けておく箱のようなものです。CRON_SECRET はcronからの正しいアクセスかを確認する合言葉、ANTHROPIC_API_KEY はAIを呼び出すための鍵、という役割です。
ところが**どこを見ても、現時点では全部「正常」**でした。設定は生きている、キーもある、cronも有効。それなのに1週間止まっていた。ここで一気に手詰まり感が出ました。「正常なのに動いていなかった」というのは、いま正常でも過去に何かあった、という意味です。過去を見に行かないと分かりません。
手動Runは成功。でも当時の原因は特定できなかった
次に、Cron Jobsの画面にある「手動Run」を試しました。予約を待たずに、今すぐ1回だけ処理を走らせるボタンです。結果は、cron経由の認証も通り、記事生成も成功（outcome=success）。手動で叩けば普通に動くことが分かりました。この手動Runのおかげで記事は7本に増えました。
ここで矛盾にぶつかります。今は動く。設定も正常。なのに8月24日は止まっていた。じゃあ当時は何が違ったのか——。それを確かめようとログ（処理の記録）を見に行ったのですが、ここで最大の壁にぶつかりました。
⚠️ 注意： Vercelの無料プラン（Hobby）は、ログ保持がおよそ1時間しかありませんでした。1週間前のログはとっくに消えていて、8月24日当時に何が起きたのかを直接確認する手段がありませんでした。
ログ保持というのは、実行の記録をどれだけの期間残しておいてくれるか、という設定です。有料プランなら長く残る場合もありますが、無料プランは短い。「後で調べればいい」が通用しないわけです。結果として、8月24日当時の失敗原因は特定できませんでした。ここは正直に書いておきます。分からなかったものは分からなかった、です。
犯人はたぶん「デプロイし忘れ」による401
原因は確定できませんでしたが、状況から見立てはひとつ立ちました。それは「環境変数を追加した後に、本番デプロイをしていなかった」線です。
デプロイというのは、書いたコードや設定を本番環境に反映して、実際に動く状態にする作業です。ポイントは、環境変数を追加しただけでは、その値がすでに動いているデプロイには反映されないことがある、という点です。つまり、8月23日に合言葉（CRON_SECRET）を追加しても、それを反映した新しいデプロイをしていなければ、cronは古いデプロイ（合言葉を知らない状態）を叩き続けます。
すると何が起きるか。cronがアクセスしても合言葉が合わず、401というエラーで弾かれます。401は「あなたが誰か確認できない・認証できない」という意味の返事です。これなら「設定は正常なのに動かなかった」という矛盾がきれいに説明できます。
| 見えていた状態 | 実際に起きていた（見立て） |
|---|---|
| 環境変数は追加済み | 追加後にデプロイしておらず古い版が動作 |
| cronは有効 | cronは動くが401で弾かれていた |
| いま手動Runは成功 | その後デプロイされ合言葉が反映された |
あくまで見立てで、証拠となるログは残っていません。それでも、環境変数を触ったら本番デプロイまでセットで行う、という教訓は自分の中に強く残りました。
次に追えるように、成否をログへ自分で残した
今回いちばん困ったのは「原因が追えないこと」でした。そこで、次に同じことが起きたときに追跡できるよう、対策を入れました。具体的には、Claude Code（AIにコードの編集を任せられるツール）を使って、[cron] outcome=... という形式のログを、処理のすべての分岐に追加しました（コミットb3818c6、テストは24件パス）。
成功したら成功、失敗したらどこで失敗したかを、必ず自分の手で記録として残す、という考え方です。プラットフォーム側のログが消えるなら、消えない形で自分の成否を書き出しておくしかありません。
- 成功・失敗の両方をログに出す（片方だけだと沈黙の失敗を見逃す）
- どの分岐で止まったか分かるように印を付ける
- 「動いていること」を、結果だけでなく記録でも確認できるようにする
💡 ポイント： 自動化は「作る」だけでなく「止まったことに気づく」仕組みまでがワンセットです。特に無料プランはログが消えるので、成否を自分で残すのが現実的な自衛策になります。
このあたりの手探りの経緯は、運営者の考え方をまとめた/aboutページと合わせて読んでもらうと、なぜ私がここまで慎重になったのか伝わるかもしれません。監視といっても大げさなものではなく、まずは「成否をログに残す」ところからで十分だと感じています。
まとめ
AIで自動生成しているブログのcronが1週間止まり、しかもVercel無料プランのログ保持が短く、当時の原因は特定できませんでした。見立ては「環境変数追加後に本番デプロイをしておらず401で弾かれていた」線です。手動Runは成功し記事は7本に増えました。今回の学びは、自動化は作って終わりではなく、止まったことに気づく仕組みまで作らないと危ういということ。ログが消える環境では、成否を自分でログに残すのが現実的な自衛策でした。
FAQ
よくある質問
Qcronが止まっているのに気づけなかったのはなぜですか？
自動化は動いている前提で放置してしまうため、止まっても通知が来ませんでした。私の場合は記事が増えていないことに自分で気づくまで1週間かかりました。成否を知らせる仕組みがないと、異常に気づくのが遅れます。
QVercelの無料プランでログが消えるのは避けられますか？
無料プラン（Hobby）はログ保持がおよそ1時間で、1週間前の記録は残っていませんでした。有料プランで期間が延びる場合もありますが[要確認]、現実的な対策は、成否を自分でログとして書き出し、消えない形で残しておくことだと考えています。
Q401エラーはどういう意味ですか？
401は「認証できない・あなたが誰か確認できない」という返事です。今回は、環境変数の合言葉を追加した後に本番デプロイをしておらず、cronが古い版を叩いて弾かれていた、という見立てを立てました。確定はできていません。