先に結論です。自動化は「動いた」ときは成果物で分かりますが、「動くはずだったのに動かなかった」ときは何も起きません。 通知もエラー画面も出ず、ただ静かに止まります。弊社ではそれで毎朝の経営ブリーフィングが3日間止まり、誰も気づきませんでした。仕組みを1つ増やすなら、「これが止まったらどう気づくか」を先に決めるべきです。
何が起きたか
株式会社TOEでは、平日の朝8時に経営状況を1枚のレポートにまとめる「日次ブリーフィング」を、cron（決まった時刻にプログラムを自動実行するUNIXの標準機能）で毎日自動生成しています。社内では「AI秘書」と呼んでいる仕組みの一部です。中身の説明はここでは省きます。この記事の主役は、それが止まったことの方です。
出力ファイルの最終更新は2026年7月15日 8時01分でした。次に人間がそれに気づいたのは7月18日です。16日（木）と17日（金）は平日で、本来なら動いているはずの日でした。動いていませんでした。
| 日付 | 何が起きたか |
|---|---|
| 7月15日（火）8:01 | 最後のブリーフィングが正常に出力される |
| 7月16日（木）・17日（金） | 平日なのに出力されず。エラー通知もなし |
| 7月18日（土） | 人間が「来ていない」と気づき、原因を特定して復旧 |
原因は単純でした。cronの設定が、Xcode（Appleの開発ツール）に同梱されていたPythonのパスを指していたのです。Xcodeを更新した際にそのPythonが消え、cronから起動されるジョブが全滅しました。ブリーフィングだけではありません。登録してあった全ジョブが同時に止まっていました。
復旧そのものは、OS標準で消えることのない /usr/bin/python3 を指すように設定を書き換えるだけでした。技術的には小さな話です。問題は、止まってから気づくまでに3日かかったことの方です。
なぜ3日間、誰も気づかなかったのか
理由ははっきりしています。「動かなかったこと」を知らせる仕組みが存在しなかったからです。
cronで動く自動化には、次の性質があります。
- エラーは画面に出ません。ログファイルの末尾に静かに積まれるだけです
- 「今日は実行されませんでした」という通知は、作らない限りどこからも来ません
- 止まっても、昨日までの出力ファイルはそのまま残っているので、一見すると何も変わっていません
人間の担当者なら「レポートが出ていません」と自分から言ってくれます。自動化は言いません。今回も気づいたのは、「そういえば3日ぶんの朝ブリーフィングが来ていないな」と思った人間でした。
もう1つ、条件が重なりました。毎朝のレポートは「来たら見る」ものであって、「来なかったら騒ぐ」ものとして運用されていなかったのです。受け取る側が「来ない」ことに敏感でないと、静かな停止はそのまま見過ごされます。
頼りにしていた監査ログも役に立たなかった
「ログは取ってあるから、何かあれば調べられる」と考えていました。これも裏切られました。
各ジョブは実行のたびに監査ログへ記録を書き込む設計でした。ところがこのログは直近200件しか保持しない仕様だったのです。同じ基盤には5分おきに動くジョブと10分おきに動くジョブが混じっていて、それだけで1日数百件になります。1日1回しか動かない日次ブリーフィングの記録は、高頻度ジョブの記録にあっという間に押し流されました。実際に調べたとき、ブリーフィングの実行記録は1件も残っていませんでした。
「記録している」と「あとから調べられる」は別物でした。件数で足切りするログは、実行頻度の違うジョブが同居すると、動きの少ないジョブの記録から順に消えていきます。復旧後の7月18日には、全ジョブを共通の実行管理スクリプト経由で動かす形に載せ替え、開始・終了・所要時間・成否が1行ずつ記録されるようにしました。
あなたの会社で自動化を増やす前に決めること
この失敗から言えることは1つです。自動化を1つ導入するたびに、動かす前に次を決めてください。
- 「止まったらどう気づくか」を先に設計する。 「動いた通知」より「動くはずの時刻に動かなかった通知」の方が重要です。弊社はここを後回しにして、実際に3日ぶん取りこぼしました
- 受け取る側の習慣を決める。 「毎朝8時に来る。来ていなかったらその場で異常と見なす」と決めておくだけでも、発見は3日から数時間に縮まります
- 記録は「あとから調べられるか」で点検する。 保存件数や期間の上限を確認し、頻度の違う処理のログを混ぜないようにします
- 消えるかもしれない部品に依存しない。 開発ツールに同梱されたプログラムのパスは、更新やアンインストールで消えます。OS標準の場所か、自分で管理しているものを指すべきです
とくに1つ目は、外注でシステムを作ってもらう場合でも同じです。「止まったとき、私たちはどうやって気づけますか」と発注時に聞いてください。この質問に答えが用意されていない自動化は、いつか静かに止まり、止まったまま気づかれません。
なお、誤解のないように書き添えると、止まっていたこの仕組み自体はAIモデルを呼ばず、追加のランニングコストもゼロで動いていました。コストがかからない自動化ほど、止まっても金額の異常として表面化しないため、気づく仕組みはなおさら意図して作る必要があると考えられます。
関連する記録
まとめ
- 弊社の毎朝の自動ブリーフィングは、開発ツールの更新でPythonが消えたことをきっかけに、2026年7月15日を最後に止まりました
- 平日2日ぶんが欠けても通知は一切なく、7月18日に人間が気づくまで誰も知りませんでした
- 頼みの監査ログは直近200件しか残らない仕様で、肝心の実行記録は1件も残っていませんでした
- 自動化は「動いた」ことより「動かなかった」ことの方が検知しにくい。仕組みを1つ増やすたびに「止まったらどう気づくか」を先に決めることが、導入そのものと同じくらい重要です
株式会社TOEでは、この失敗も含めた自社実践をもとに、中小企業のAI活用・業務自動化のご相談を承っています。「止まったらどう気づくか」まで含めた設計からお手伝いします。