第4幕の締めくくりです。自動化を作れるようになったら、最後に必ず向き合うべきこと——「壊れたとき、どうするか」です。これを設計しないと、せっかくの自動化が、ある日あなたの知らないところで業務を止めます。
- 最も危険なのは「サイレント失敗」——警告も出さず、仕事だけが静かに止まる
- 自動化は「作って終わり（set-and-forget）」ではない。壊れる前提で見張る
- 情シス不在でも「エラー通知・ログ・定期確認」の3点で気づける
自動化は「エラーで止まる」より「静かに止まる」
多くの人は、自動化が壊れるとき「エラー画面が出て止まる」と思っています。本当に怖いのは、その逆です。自動化の専門家は、こう警告します。
サイレント失敗（静かな失敗）こそ、最も危険なボットの故障である。
（flobotics）
エラーも警告も出ず、「成功したフリ」をして、実は仕事だけが止まっている。これが最悪の壊れ方です。誰も気づかないまま、請求が送られない・データが溜まらない・通知が来ない状態が続く。しかもこれは珍しくありません。Forresterの調査では、45%の企業が週1回以上、自動化（ボット）の故障を経験しています。
実例：項目名を変えただけで、3週間誰も気づかなかった
具体的な怖さを、実例で見ましょう。ある会社で、顧客管理ツール（HubSpot）の項目名を一つ変更しただけで、それを参照していた全部の自動化が無通知で停止しました。問題は、それに誰も気づかなかったこと。営業マネージャーが異変に気づいたのは、3週間後でした。
これが「set-and-forget（作ったら忘れる）の幻想」です。自動化は、つないだ先（アプリやツール）が仕様を変えるたびに、黙って壊れます。自動化は「作って終わり」ではなく、生き物のように世話が要る。これを前提にしないと、静かな事故が積み重なります。
情シスがいなくても、壊れに気づける3点セット
では、専任のIT担当がいない中小企業はどうすればいいか。難しい監視システムは要りません。「壊れたら気づける」最小の3点を、自動化を作るときに一緒に組み込みます。
- エラー通知 自動化が失敗したら、チャットやメールで自分に知らせる設定を必ず入れる。多くのツールに標準機能がある（例：Zapierは連続でエラーが続くと自動でオフにし、メールで知らせる）。
- ログ（実行記録） 「いつ・何件・成功したか」の記録を残す。月末に「先月、本当に動いていたか」を振り返れる。
- 定期確認 「週1回、自動化が動いているか目視する」係と曜日を決める。HubSpotの例も、誰かが見ていれば3週間にはならなかった。
注意点も正直に。エラー通知は「失敗したら知らせる」ものなので、「成功扱いだが中身が空（サイレント失敗）」は捕まえきれないことがあります。だからこそ「人の定期確認」を残す。前回の人間承認と同じで、要所に人を残すのが、自動化を安全に回す鍵です。
「自動化の負債」——増えるほど絡まる
もう一つ、長く運用するほど効いてくる注意があります。自動化を増やしていくと、「どれがどれにつながっているか分からない」状態（スパゲッティ化）になり、一つ直すと別が壊れる、という保守の負担が溜まります。これを「自動化の負債」と呼びます。
対策はシンプルです。連載No.2の「小さく始める」と同じで、むやみに増やさない・使っていない自動化は止める・何のための自動化かを記録しておく。数を競うのではなく、効いている少数を確実に保守する。これが、自動化を「資産」にし「負債」にしないコツです。
上段：「項目名変更→自動化が無通知で停止→3週間誰も気づかない」のタイムライン（じわじわ被害が広がる）。下段：それを防ぐ３点セット「①エラー通知 ②ログ ③週1の定期確認」。中央に「自動化はset-and-forgetできない＝壊れる前提で見張る」。
まとめ
- 最も危険なのはサイレント失敗（静かに止まる）。45%の企業が週1回以上ボット故障を経験。
- 自動化は「作って終わり」ではない。つなぎ先が変わるたびに黙って壊れる。
- 情シス不在でも「エラー通知・ログ・週1の定期確認」で気づける。増やしすぎず負債にしない。