70個の自動処理を点検したら、壊れていたのは点検する側だった — 中小企業 × AI 経営（2026年8月）

社内に、誰も見ていない場所で黙々と作業をしている担当者がいたとします。指示は一度出しただけ。それ以来、進捗を確認したことは一度もありません。「たぶん今日もちゃんとやっているはずだ」——そう思い込んだまま何年も経っていたら、少し怖くなりませんか。

弊社には、これによく似た存在が70人分あります。ただし人ではありません。毎朝ひとりでに動くプログラムです。売上表の同期、案件データの突合、社内ドキュメントの更新、サイトの公開、記録の組版。ひとつずつは小さな処理ですが、気がつけば70個になっていました。

そして先日、そのうち何個が本当に動いているのか、誰も把握していないことに気づきました。この記事は、70個を一つずつ点検した記録です。結果から言えば止まっていた処理はゼロでしたが、代わりに別のことがわかりました。

70個を、記録の新しさで洗った

自動処理を1つ追加するのは、いまや数十分の仕事です。「毎朝7時にこれを実行」と一行書けば、翌朝からそれは勝手に動きます。

問題は、動かなくなったときに何も起きないことです。人がやっていた作業なら、担当者が休めば「今日はあの資料が出ていない」と誰かが気づきます。ところが自動処理は、止まっても静かに止まる。エラーの通知すら出ないことがあります。実際、弊社では過去に月次でページを繰り上げる処理が、そもそも自動実行の登録から漏れていたことがありました。数か月のあいだ毎月手で実行していたのに、誰もそれを「自動化されていない」と気づいていなかったのです。

そこで今回、設定を上から読むのではなく、「本当に最近動いたか」の跡を一つずつ確かめることにしました。設定に書いてあっても、対応する記録が2週間前で止まっていれば、それは動いていません。記録が今朝の日付なら、それは間違いなく動いています。申告ではなく痕跡で確かめる、という方針です。70個を、この見方で一つずつ突き合わせていきました。

「動いているつもり」は、他人事ではない

これは自動処理に限った話ではありません。中小企業には、「一度決めてから、ずっと確かめていないもの」が他にもあるはずです。

よくある「ひとりでに回っているもの」	確かめないと起きていること
毎月自動送信している請求書メール	宛先が古いまま、何ヶ月も届いていないかもしれない
在庫を自動で反映する仕組み	実は先月から数字が止まっているかもしれない
定期的に自動集計されるレポート	集計の範囲がずれたまま配られているかもしれない

自動化に前向きな会社ほど、「増やすこと」にばかり時間を使いがちです。増やす作業は成果がすぐ見えるからです。一方「確かめること」は、何も起きないことが成果なので、後回しにされやすい。しかし確かめずにいると、自動化の総量が増えるほど、思い込みの量も一緒に増えていきます。

最初に見つけた「異常」は、誤報だった

点検を始めてほどなく、「常駐しているはずの処理の一つが死んでいる」という結果が出ました。一瞬肝が冷えましたが、実際に確かめると、その処理は普通に動いていました。

原因は点検する側にありました。社内での呼び名と、実際のファイル名が違っていて、呼び名の方で探しに行っていたのです。壊れていたのは仕組みではなく、点検の仕方の方でした。

弊社ではこれを社内のルールにしています。検査が「異常あり」と言ってきたら、まず検査そのものを疑う。 誤報が何度か続くと、人はその通知を読まなくなります。そうなると、本当に壊れた日の通知も読み飛ばされる。オオカミ少年になった監視は、監視がないより危険です。

本当の発見：月6回のはずが、月23回動いていた

一通り点検し終えて、実害のある設定ミスが1件見つかりました。月末に社内ドキュメントの下書きを作る処理です。「月末の平日の夜」に動けばいい処理なので、月に6回程度のはずでした。ところが実際には、月23回動いていました。

原因は、この種の自動実行の設定によくある落とし穴でした。「日にち」と「曜日」を両方指定すると、多くの人が期待する「両方に当てはまる日」ではなく、**「どちらかに当てはまる日」**として扱われてしまうのです。

指定のしかた	期待していた動き	実際の動き
24〜31日 かつ 月〜金のつもりで指定	月末の平日だけ（月6回程度）	24〜31日のすべて＋平日のすべて（月23回）

直し方は簡単で、曜日の指定を外し、日にちだけで絞るようにしました。片方だけを指定すれば、その条件だけで動きます。

実害がゼロだったのは、二重の備えのおかげ

月23回も動いていたのに、業務上の実害はゼロでした。理由は、処理そのものの中に「営業日でなければ何もしない」という歯止めが、もう一段入っていたからです。設定の側で絞り損ねても、プログラムの側でもう一度絞っていた。余計に起動された分は、何もせずに終了していました。

安全の仕掛けは、一段だけだと破れます。設定で絞り、プログラムでも絞る。 二段構えにしておくと、片方が間違っていても事故になりません。

説明書きの方が、設定より腐っていた

点検で一番手を入れたのは、実は設定そのものではなく説明書きの方でした。以前あった処理を整理した後もその処理を説明する行だけが残っている、同じような処理が朝に2回あるのに理由がどこにも書いていない、試作段階の呼び名が今の役割と違う名前のまま残っている——そんな箇所が10件近く見つかりました。

どれも動作には影響しません。しかし半年後の自分と、これから入ってくる人を確実に迷わせます。自動化の保守コストは、処理そのものより「なぜそうなっているか」の記録が失われることで跳ね上がるのだと感じました。

70個は、70個のままにした

点検の最後に「減らせないか」も考えました。結論として、1つも減らしませんでした。70個すべてに、今も役割があったからです。

弊社の失敗はどちらかというと「作りすぎ」の方向に出やすいので、2〜3個は無駄が出るだろうと予想していました。実際にはゼロ。理由は、増やすときに毎回「これは本当に必要か」を関門にしていたからだと思います。何かを作る前に「作らない理由」を先に挙げる決まりにしている。この関門を通ってきた70個だったので、後から捨てるものが残っていませんでした。

もし社内に「毎月ひとりでに動いているはずのもの」があるなら、それが本当に先月動いたかどうかを、結果の日付で確かめてみてください。 設定を見るのではなく、結果を見る。それだけで、思っていたのと違う顔が出てくることがあります。

今回の点検は、丸一日かけて自分の目で確かめました。次はこの点検自体を自動処理にするつもりです。ただし、点検役が静かに止まっていたら意味がありません。だから「異常がなくても、月に一度は生きていると知らせる」仕組みも一緒に組み込みます。沈黙を「正常」と読み違えない。今回の誤報の一件から学んだことの延長です。