はじめに、こちらの立場を明かします
この記事を書いている株式会社TOEは、福岡でWeb制作とAI開発をしている会社です。自社の業務を41本のcron（時刻を決めて自動実行する仕組み）で回しています。経理・営業・メディア更新まで、かなりの部分をAIエージェントに任せています。
つまり「AIで会社を自動化しましょう」と言える立場にあります。利害関係者です。
だからこそ、今回も先に社内で決めました。都合の悪い数字が出ても、そのまま載せる。
結論から言います。都合の悪い数字が、はっきり出ました。「毎朝ちゃんと動いている」と思っていた自動化の多くは、そもそも起動すらしていませんでした。 ひどいものは、5.3日のあいだに動くはずだった11回のうち、実際に動いたのは1回だけ。91%が抜けていました。
用語を3つだけ
- cron（クーロン） … 「毎朝7時」「5分ごと」のように、時刻を決めてプログラムを自動実行するOSの仕組みです。今回、当社は41本を登録しています。
- 発火（はっか） … cronが予定時刻に来て、実際にジョブを起動することです。予定があっても、PCが起きていなければ発火しません。
- 実行履歴 … 当社の自動化基盤は、ジョブが起動するたびに1行、終了するたびに1行を
runs.jsonlというファイルに記録しています。開始・終了・成否・所要時間つきです。今回はこの記録を数えました。
何を、どうやって数えたか
対象期間：2026年7月18日 12:20 〜 7月23日 18:40（5.3日）。実行履歴1,425件の全数。
やったことは単純です。
- 登録しているcron定義から、各ジョブの「予定時刻ルール」を取り出す。
- 実行履歴
runs.jsonlから、各ジョブが実際に何回起動したかを数える。 - 「期間中に発火するはずだった回数」と「実際に発火した回数」を突き合わせる。
ここで一つ、恣意が入らないように基準を決めました。月に1回・特定日にしか動かないジョブ（請求書発行、月次PLなど）は、今回の5.3日に発火予定日が来ていません。これは「正常」として除外します。問題にするのは、期間中に発火予定があったのに、その回数に届かなかったジョブだけです。
結果：発火予定に届かなかったジョブ（欠落率の高い順）
| ジョブ | 予定 | 実績 | 欠落 | 状態 |
|---|---|---|---|---|
| UchUchU 日次処理 | 11 | 1 | 10 | 91%抜け |
| AIの鬼 日次処理 | 10 | 2 | 8 | 80%抜け |
| 補助金の鬼 記事生成 | 5 | 1 | 4 | 80%抜け |
| UchUchU 記事生成 | 5 | 1 | 4 | 80%抜け |
| 見積システム同期 | 4 | 1 | 3 | 75%抜け |
| 朝の運用チェック | 5 | 2 | 3 | 60%抜け |
| 銀行残高同期 | 4 | 2 | 2 | 50%抜け |
| LINE受信処理 | 1,517 | 927 | 590 | 39%抜け |
| メール意思決定 | 759 | 468 | 291 | 38%抜け |
| 日次ブリーフィング | 4 | 3 | 1 | 25%抜け |
| リード取込 | 4 | 3 | 1 | 25%抜け |
そして、期間中に発火予定があったのに、一度も動かなかったジョブが5本ありました。
| 完全に沈黙していたジョブ | 予定 | 実績 |
|---|---|---|
| ご無沙汰フォロー・ドラフト | 1 | 0 |
| AIの鬼 note自動投稿 | 4 | 0 |
| 補助金の鬼 データ更新 | 5 | 0 |
| UchUchU 週次レビュー | 1 | 0 |
| 営業health再採点 | 1 | 0 |
一番効いているのは、メディア更新系の壊滅です。UchUchU・AIの鬼・補助金の鬼という3つの自社メディアの日次更新が、そろって80〜91%抜けていました。毎朝更新しているつもりで、実際には5〜6日に1回しか動いていなかったことになります。
なぜ抜けたのか（ここは断定しません）
正直に書きます。この記事の時点で、原因の切り分けは終わっていません。
ただ、少なくとも2種類の別の原因が混じっていることは、履歴の形から見えます。
1つ目（高頻度ジョブ）。5分ごとに動くはずのジョブ（LINE受信・メール意思決定）が、きれいに4割ほど抜けています。この「一定割合で、時間帯に偏って抜ける」形は、プログラムのバグというより、cronが発火するべき時刻にPCが起きていなかったときに出やすい形です。当社の自動化は1台のMacで無人運用しており、cronはスリープ中には発火しません。ここはスリープの疑いです。ただし裏を取るまで断定はしません。
2つ目（メディア更新系）。これはスリープでは説明がつきません。理由は、同じメディア日次ジョブのうち1本（AIの鬼 日次処理）は、73分かけて最後まで完走した記録が残っているからです。スリープしていたら73分の連続実行はできません。メディア更新の処理は総じて長く、補助金の鬼で38〜51分、UchUchUで26分かかっています。1回が数十分と長いこと自体が、抜けと関係しているのはほぼ間違いない。
ただし、ここで正直に書いておきます。当初、私たちは「1回の実行が15分（900秒）の上限を超えて打ち切られている」と考えました。基盤には実際に15分で強制終了する設定があるからです。ところが履歴を数え直すと、その上限が900秒のままのジョブが51分も完走している記録が見つかりました。つまり単純な「15分で殺されていた」説は、自分のデータに否定されました。長い処理が抜けの原因に絡んでいるのは濃厚だが、どういう機序で抜けているのかは、まだ突き止められていません。 分かった気になって書くより、分からないと書きます。
この機序の追跡と、止まったメディアをどう復旧させたかは、次の記録（止まったメディア更新を、見張り役が自動で叩き起こしていた話）で追います。
一方で、起動したうえで失敗した回数は、はっきり数えられました。期間中のerror終了は35回。内訳はメール意思決定27回、LINE受信4回、朝の運用チェック2回、見積同期と補助金ストック各1回です。起動さえすれば、9割以上は正常に終わっていました。問題は「失敗」ではなく「起動していない」ことのほうが、はるかに大きい。
この調査で、自分たちが思い知ったこと
- 「動いているはず」は、数えるまで幻です。ダッシュボードには全ジョブが緑で並んでいました。緑は「最後に動いたとき成功した」を意味するだけで、「毎回動いている」は意味していませんでした。
- 成功率だけ見ていると、この問題は絶対に見つかりません。 起動したジョブの成功率は96%。優秀に見えます。数えるべきは成功率ではなく、発火予定に対する発火率でした。
- 止まって困る順に対策する。 5分ごとのLINE処理が4割抜けても、次の5分で拾えます。しかし1日1回のメディア更新が抜けると、その日は丸ごと更新なしです。同じ「欠落」でも重みが違います。
自動化の本数を増やすときに本当に必要なのは、ジョブを足すことではなく、「予定した回数、ちゃんと発火したか」を毎日数える仕組みでした。当社はこれを次の宿題にします。
関連する記録
- 自動化が3日間止まっていたのに、誰も気づかなかった — 今回の「定性版」。何が起きたかを言葉で書いたもの。
- 自動化26本に「見張り役」の画面を付けたら、そもそも全部止まっていた — その画面が、今回「緑なのに動いていない」を見逃していた話につながります。
- 止まったメディア更新を、毎時cronで自動再始動させている話 — 抜けたジョブを拾い直す側の仕組み。
まとめ
- 社内のcron自動化41本の実行履歴1,425件（5.3日ぶん）を全数調査した。
- 期間中に発火予定があったジョブのうち、メディア更新系は80〜91%が発火していなかった。
- 発火予定があったのに一度も動かなかったジョブが5本あった。
- 起動後の成功率は96%と高い。問題は「失敗」ではなく「起動していない」ことだった。
- 原因は少なくとも2種類。高頻度ジョブはスリープ疑い、メディア更新系は1回が数十分と長いことが絡む。ただし「15分上限で殺されていた」という当初の見立ては、900秒設定のまま51分完走した記録が見つかって自分で否定した。機序はまだ未解明。
- 教訓は一つ。自動化は「成功率」ではなく「発火予定に対する発火率」で数える。