この記事の対象：Claude Codeを使って自動化を運用している方。自動実行が止まっても通知が来ない、ログを見るまで気づかないという状況を経験したことがある方に向けた記録です。
対象読者
Claude Codeを使ったスクリプトや自動化フローを継続的に稼働させている方向けです。
これは「成功しました」と返ってきていた2日間が、実は何も動いていなかったという話です。エラーログも無く、異常終了の通知も来ず、ローカルでの動作確認では問題なし——そのまま気づかなかった原因と、その後どう変えたかを書きます。
何が起きていたか
自動実行のスクリプトがあります。毎晩決まった時間に動いて、決まった処理をして、ログに「完了」と書いて終わるものです。
その処理が止まっていました。2日間。
ログを見ると、スクリプト自体は起動していました。ただ、途中の処理が実行されていなかっただけです。終了コードは0（正常）でした。
原因はClaude APIの利用枠（レート制限）でした。深夜に実行するスクリプトが複数あり、ある時間帯に集中しすぎて上限に達していた。APIの呼び出しは失敗していましたが、スクリプトはエラーをキャッチして「スキップ」として処理し、結果として何も書かずに「完了」として終了していました。
悪意があるわけでもバグでもなく、設計のとおりに動いた結果として「2日間何も起きなかった」になっていました。
見落とした理由
最初に「なぜ気づかなかったのか」を整理しました。
1つ目：ログを毎日見ていなかった。「完了」と書かれたログが積まれているだけでは、中身を確認しなければ問題に気づけません。ログの存在は安心感を与えますが、ログの内容を確認する習慣がないと盲点になります。
2つ目：「完了」が実際の処理の完了を意味していなかった。スクリプトの終了と、意図した処理の完了は別です。スクリプトが終了コード0で終わっていても、中で何も処理されていないケースがあります。この違いを意識していませんでした。
3つ目：APIの利用枠は毎日変動する。昨日は動いた。今日も動くはず。という思い込みがあります。APIのレート制限は呼び出し量や時間帯に依存するため、前日動いた設定が今日も動く保証はありません。
4つ目：処理結果がどこかに出力されていなかった。例えば「今日の処理で何件を書き込んだか」が記録されていれば、0件が続いたときに気づきやすかったです。処理数が0の日が2日続いたら何かがおかしいと判断できます。
変えたこと——検知の仕組み
止まっていた期間に変えたのは主に2点です。
処理結果を数値で記録する：スクリプトの終了メッセージを「完了」から「今回の処理件数：◯件（スキップ◯件）」に変えました。ログを見たとき、処理件数が0の行が続いていれば異常と判断できます。
件数が0の場合は別のログに書く：通常のログとは別に、異常系（0件・スキップ過多）をまとめて記録するファイルを作りました。毎日のログを全部読まなくても、このファイルを見れば「何かあった日」が分かります。
あわせて、スマホへの通知（ntfy）を組み込みました。処理件数が期待値以下の場合に通知が来るようにした結果、問題が起きたその日に気づける確率が上がりました。
APIの利用枠問題への対応
根本の原因だったAPIの利用枠については、実行時間の分散で対応しました。
複数のスクリプトが同じ時間帯に集中していたことが原因だったため、実行スケジュールをずらして1時間に集中しないようにしました。ずらした後は、同じ時間帯での競合が起きなくなりました。
APIのレート制限は外から制御できないため、こちら側でできることは「使い過ぎない設計にする」ことと「超えたときに検知できる仕組みを持つ」ことです。制限に引っかかること自体は避けられませんが、引っかかったまま気づかないことは設計で防げます。
リトライの設計についても見直しました。失敗したときにリトライするのは良いですが、リトライも全て失敗した場合に「スキップ」として処理を続けるのか「エラーとして停止する」のかは、業務の重要度によって変えるべきです。重要な処理はスキップではなくエラーで止めた方が、後から気づきやすいです。
自動化の「動いているつもり問題」
自動化の怖さは、「動いているつもり」が長く続けられるところにあります。
スクリプトが稼働していることと、意図した結果が出ていることは別です。ログが積まれていても、ログの中身を確認しなければ問題は見えません。毎日手動で確認する設計では、いずれ確認が止まります。だから仕組みが必要になります。
今回の経験で変えた習慣：毎晩のスクリプトの実行後に、処理件数の集計を朝の通知に含めるようにした。ゼロの日が1日でもあれば確認する。これだけで同じ問題は防げるようになりました。
2日間気づかなかったことは反省ですが、2日で気づけたのは別の確認経路（他のログ）があったからです。止まったまま1週間気づかないケースもありえました。自動化を運用する場合、「止まっても気づける仕組み」を「実行の仕組み」と一緒に作ることが重要だと実感しています。
今回確認すること
- スクリプトの終了コード0が「意図した処理の完了」を意味しているか
- 処理件数が0の場合に気づける記録・通知があるか
- APIのレート制限に達した場合の動作（スキップ・エラー停止）が業務の重要度に合っているか
- 複数のスクリプトが同じ時間帯に集中していないか
- ログを読まなくても「今日何件動いたか」が分かる仕組みがあるか
自動化は動いていれば問題ないように見えます。でも「動いているつもりで止まっている」の期間が長くなるほど、後から取り戻すコストが増えます。早期検知の設計は、実行の設計と同じくらい大事です。
関連記事：
https://note.com/light_tern636/n/n5ed64755795e
Copilot・Power Automate・AIツールの導入・活用のご相談は、ココナラで受け付けています。