Claude Codeでcron監視を自動化｜定期実行を自己復旧する事例

Claude Codeでcron監視を自動化すると、定期実行ジョブ14件の異常確認を仕組み化できます。

要点1: ジョブ状態、配信エラー、実行遅延、ログを5項目で診断
要点2: 自動修復は再実行1回までなど、ガードレール付きで設計
要点3: 正常時は通知せず、問題時だけ原因と対応結果を報告

対象: AIエージェントや業務自動化ジョブを運用する企業担当者

今日やること: 自社の定期実行ジョブ一覧と失敗時の対応手順を棚卸しする

この記事の著者

株式会社Nexa 代表取締役川島陸

一橋大学経済学部卒業後、フォーティエンスコンサルティング株式会社（旧株式会社クニエ）にて法人向けAI導入支援等を経験。独立後、AI系メディア運営やDify/n8nの導入支援を経て、株式会社Nexaを創業。法人向けAI研修・AI導入支援・AI関連メディア運営を手掛ける。

詳しく見る無料相談をする

この記事の目次

導入企業の課題と背景
AI導入の選定プロセス
具体的な活用方法
導入後の成果と効果
成功のポイントと教訓
同様の課題を持つ企業へのアドバイス
よくある質問
まとめ

AIエージェントの定期実行は、作ることよりも「失敗に気づき、復旧できる状態にすること」が重要です。

ある事業会社では、複数の業務自動化ジョブを動かすうちに、ジョブの成否確認が人手に依存していました。そこでClaude Codeを使い、cron監視と自動復旧を行う「ジョブの主治医」のような仕組みを構築しました。

この記事では、実際の会話履歴をもとに、固有名詞や金額を伏せた形で、定期実行ジョブの自己診断・自動復旧をどう設計したかを解説します。

導入企業の課題と背景

この事例の企業では、AIエージェントを使った定期実行ジョブが増えていました。メール確認、データ同期、通知、記事制作など、複数の業務が時間指定で自動実行される状態です。

しかし、ジョブが増えるほど「どれが動いていて、どれが失敗しているか」を人間が把握しにくくなります。最初は数件でも、10件を超えると毎回の確認だけで運用負荷になります。

定期実行は増えるほど見えなくなる

定期実行ジョブの怖い点は、失敗してもすぐに業務が止まらないことです。たとえば、毎朝のレポート生成が1回失敗しても、担当者が気づくまで数時間から数日かかることがあります。

今回の対象環境では、有効なジョブが14件、意図的に停止しているジョブが13件ありました。人間が一覧を見れば確認できますが、毎日それを続けるのは現実的ではありません。

よくある状態	放置した場合のリスク
前回実行がエラー	同じエラーが繰り返される
配信エラー	成果物が作られても担当者に届かない
次回実行時刻が過去のまま	スケジューラが詰まっている可能性がある
ログに例外が出ている	表面上は成功でも内部で欠損が起きる
認証情報が切れている	連携先サービスの処理が止まる

実務でのポイントは、成功・失敗の表示だけで判断しないことです。配信エラー、実行遅延、ログの異常も合わせて見る必要があります。

通知だけでは運用が詰まる

監視の第一歩は通知です。ただし、通知だけでは問題が残ります。毎回「エラーです」と届いても、誰が何をすればよいか分からなければ、結局は人間がログを見に行くことになります。

この企業では、通知を増やすのではなく「診断結果、原因、試した修復、残った課題」を1つのレポートにまとめる方針にしました。正常時は通知しない設計にしたため、担当者は問題があるときだけ確認すればよくなります。

AI導入の選定プロセス

今回の設計で重要だったのは、すべてをAIに任せなかったことです。Claude Codeは、コード生成や運用手順の整理に強い一方、監視対象の状態判定まで毎回自然言語で行うと、判断がぶれる可能性があります。

そこで、診断は決定論的なスクリプトで行い、修復方針の判断だけをAIに任せる構成にしました。

決定論的スクリプトとAI判断を分ける

決定論的スクリプトとは、同じ入力なら同じ結果を返すプログラムのことです。ジョブ一覧ファイルやログを読み、条件に合うかどうかを機械的に判定します。

今回の診断スクリプトでは、主に次の情報を確認しました。

診断対象	見る項目	判定例
ジョブ定義	有効・停止中の状態	停止中は問題扱いしない
前回実行	`last_status`と`last_error`	エラーなら問題として記録
配信結果	`last_delivery_error`	通知先に届いていなければ問題
次回実行	`next_run_at`	2時間以上過去なら遅延扱い
ログ	エラーログの直近更新	新しい例外があれば確認対象

Claude Codeは、このスクリプトを作成し、どの項目を監視すべきかを整理する役割を担いました。診断結果はHEALTHYまたはPROBLEMS_FOUNDで始まる形式にし、後続処理が迷わないようにしています。

自動修復の範囲を限定する

自動復旧は便利ですが、危険もあります。たとえば、ジョブを勝手に削除したり、スケジュールを変更したりすると、別の業務影響が出る可能性があります。

そのため、今回の設計では「直してよいこと」と「人間に任せること」を明確に分けました。

自動修復してよいこと	自動修復しないこと
スケジューラの再起動	ジョブの削除
一時的な失敗ジョブの1回だけ再実行	ジョブ設定の恒久変更
一時フォルダに消えた仮想環境の再構築	認証情報の再発行
ネットワーク失敗の再試行	通知先チャンネルの変更

この線引きが、AIエージェント運用では特に重要です。AIに権限を渡すほど便利になりますが、同時に誤操作の影響も大きくなるためです。

＼ Claude Codeの導入、何から始めればいいかわかります／

法人様のAI導入に関するご相談はこちら

具体的な活用方法

今回作った仕組みは、3層構造です。1つ目は健康診断スクリプト、2つ目は修復プレイブック、3つ目は12時間おきにそれを実行する定期ジョブです。

Claude Codeは、会話の中で既存のジョブ一覧、ログの場所、状態ファイルの構造を確認しながら、この3層を順番に作りました。

監視した5項目

健康診断スクリプトでは、最低限の監視項目を5つに絞りました。多くしすぎると誤検知が増え、少なすぎると実務上の失敗を見逃します。

監視項目	目的	実務上の意味
スケジューラ稼働	定期実行そのものが動くか確認	ここが止まると全ジョブが止まる
前回実行ステータス	ジョブ単位の失敗を検知	原因調査の入口になる
配信エラー	成果物が届いたか確認	実行成功でも業務上は失敗になり得る
実行遅延	次回予定が過去に残っていないか確認	スケジューラ詰まりを検知できる
エラーログ	表面に出ない例外を拾う	早期発見につながる

これらは、特殊な環境に限らず応用できます。Google Apps Script、サーバー上のcron、クラウド関数、社内バッチでも、同じ考え方で監視項目を設計できます。

修復プレイブックの例

修復プレイブックとは、エラーの種類ごとに「何をしてよいか」を書いた運用ルールです。AIに自由判断させるのではなく、事前に決めた範囲で対応させます。

今回のプレイブックでは、たとえば次のように整理しました。

症状	自動対応	人間対応に回す条件
スケジューラ停止	再起動を試す	再起動後も停止している
一時的なタイムアウト	対象ジョブを1回だけ再実行	2回目以降も失敗する
仮想環境がない	依存環境を再構築	インストールが失敗する
認証切れ	修復せず報告	ユーザー操作が必要なため
配信先エラー	修復せず報告	チャンネル招待や権限確認が必要なため

ポイントは、認証切れや権限不足を無理に直さないことです。これらは人間の承認やログインが必要になるため、AIが勝手に進めるべきではありません。

通知を減らす[SILENT]運用

監視ジョブは、正常時にも通知するとすぐにノイズになります。そこで、正常時は[SILENT]だけを返すルールにしました。これにより、問題がない日は通知されません。

一方、問題が見つかった場合は、次の情報を報告します。

どのジョブで問題が起きたか
エラー内容は何か
自動修復を試したか
修復後の再診断結果はどうか
人間が対応すべきことは何か

この設計により、担当者は「通知が来たときだけ見る」運用にできます。AIエージェントの導入では、通知量を減らすことも重要な成果です。

AIエージェントや定期実行ジョブの運用設計に不安がある場合は、まず自社の業務フローに合わせて「どこまで自動化し、どこから人間が見るか」を整理することが重要です。設計の壁打ちや導入計画は、AI顧問の無料相談でご相談いただけます。

AI顧問の無料相談はこちら →

導入後の成果と効果

この仕組みを入れたことで、定期実行ジョブの運用確認が標準化されました。対象環境では、有効ジョブ14件をまとめて診断し、正常時は通知しない状態まで確認できています。

重要なのは、単に「監視を作った」ことではありません。エラーが起きたときの初動が、毎回同じ品質で行えるようになったことです。

運用確認の手間を削減

以前は、ジョブ一覧を開き、前回実行時刻やエラーを目視で確認する必要がありました。今は健康診断スクリプトが、問題の有無を1行目で返します。

変更前	変更後
人間がジョブ一覧を確認	スクリプトが自動診断
正常時も確認作業が必要	正常時は通知なし
エラー原因を都度調査	原因と対応方針をまとめて報告
復旧手順が属人的	プレイブックで標準化

これにより、担当者は毎日の確認作業から解放され、問題が起きたときの判断に集中できます。

エラー時の初動を標準化

自動化の運用では、エラーそのものよりも「エラー時に何をするかが毎回違う」ことが問題になります。ある日は再実行し、別の日は放置し、別の日は設定を変えてしまう。これでは原因が追いにくくなります。

今回の事例では、再実行は1回まで、ジョブの削除や編集は禁止、直せないものは人間対応として報告、というルールにしました。

このようなガードレールがあると、AIが動いても運用が荒れません。自動復旧は「強い権限を渡す」ことではなく、「安全な初動を自動化する」ことだと考えると設計しやすくなります。

＼業務自動化のお悩み、プロが30分で整理します／

法人様のAI導入に関するご相談はこちら

成功のポイントと教訓

この事例から得られる教訓は、AIエージェント運用全般に使えます。特に重要なのは、監視対象を絞ること、自動修復の権限を制限すること、人間対応を残すことです。

ジョブ削除・編集は禁止する

監視ジョブに強すぎる権限を持たせると、問題が起きたときに被害が広がります。たとえば、エラーを解消するためにジョブを停止したつもりが、必要な業務通知まで止めてしまう可能性があります。

今回の仕組みでは、ジョブの削除、編集、停止、再開を禁止しました。監視ジョブができるのは、診断、限定的な再実行、環境再構築、報告までです。

これは中小企業のAI導入でも重要です。最初から完全自律を目指すより、まずは「安全な補助者」として運用に入れる方が成功しやすくなります。

再実行は1回までにする

ジョブが失敗したとき、再実行すれば直ることもあります。ネットワークの一時不調やAPIの一時エラーであれば、1回の再実行で成功する場合があります。

しかし、何度も再実行すると、外部サービスに負荷をかけたり、同じ処理が重複したりする危険があります。そのため、今回のプレイブックでは「1ジョブにつき再実行は1回まで」としました。

このような上限は、AIエージェントに限らず、すべての自動復旧で必要です。無限リトライは、障害を悪化させる典型的なパターンです。

人間対応を残す

認証切れ、権限不足、通知先の招待漏れなどは、自動で直しにくい領域です。無理に自動化すると、認証情報の扱いや権限管理のリスクが高まります。

そのため、今回の仕組みでは、人間対応が必要な問題は「修復せず、原因と推奨アクションを報告する」設計にしました。

AIエージェントの価値は、人間を完全に不要にすることではありません。人間が見るべき問題だけを残し、それ以外の確認や初動を減らすことにあります。

同様の課題を持つ企業へのアドバイス

同じように定期実行ジョブを運用している企業は、いきなり自動復旧まで作る必要はありません。まずは、失敗を見逃さない状態を作ることから始めるのがおすすめです。

小さく始めるチェックリスト

最初に棚卸しすべき項目は、次の5つです。

チェック項目	確認すること
ジョブ一覧	何が、いつ、どこで動いているか
成功条件	何をもって成功とするか
失敗条件	エラー、未配信、遅延をどう判定するか
通知先	誰に、どの粒度で知らせるか
復旧手順	再実行してよいか、人間確認が必要か