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

結論から言うと、自動化は「作るとき」より「今も動いているか確かめるとき」の方が難しいというのが、今回いちばん腹に落ちたことでした。

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

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

増やすのは簡単、確かめるのは面倒

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

問題は、動かなくなったときに何も起きないことです。

人がやっていた作業なら、担当者が休めば「今日はあの資料が出ていない」と誰かが気づきます。ところが自動処理は、止まっても静かに止まります。エラーの通知すら出ないことがある。「毎朝動いているはずのもの」が3週間前から動いていなくても、誰も気づかないまま業務が回ってしまうのです。

実際、弊社では過去に月次でページを繰り上げる処理が、そもそも自動実行の登録から漏れていたことがあります。数か月のあいだ、毎月手で実行していたのに、誰もそれを「自動化されていない」と認識していませんでした。気づいたのは、月が変わってもページが前の月のままだったからです。

このときの反省が頭にあったので、「そろそろ全部を点検しよう」と決めました。

点検の方法：本人の申告ではなく、ログの鮮度で見る

点検といっても、設定ファイルを上から読むだけでは意味がありません。設定に書いてあることと、実際に動いていることは別だからです。

そこで今回は、こういう見方をしました。

見るもの	わかること
設定の一覧	「動かすつもり」になっているもの
ログの最終更新時刻	本当に最近動いたかどうか
常駐プロセスの生死	待ち受け型の処理が生きているか

設定に書いてあっても、対応するログが2週間前で止まっていれば、それは動いていません。逆にログが今朝の時刻で更新されていれば、それは間違いなく動いています。申告ではなく痕跡で確かめる、という方針です。

70個を一つずつ、この見方で突き合わせていきました。地味な作業です。しかし、これをやらないと「動いているつもり」の山ができます。

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

点検を始めてほどなく、「常駐しているはずの処理のひとつが死んでいる」という結果が出ました。

一瞬、肝が冷えました。ところが実際に確かめてみると、その処理は普通に動いていました。

原因は、点検する側にありました。その常駐処理は、社内での呼び名と、実際のプログラムのファイル名が違っていたのです。私は呼び名の方でプロセスを探しに行っていたので、「そんなものは動いていない」という答えが返ってきていました。壊れていたのは仕組みではなく、点検の仕方の方だったわけです。

これは弊社で何度も踏んでいる型なので、社内のルールとして明文化してあります。

検査が「異常あり」と言ってきたら、まず検査そのものを疑う。

なぜこれをルールにしているかというと、誤報は信用を壊すからです。「異常です」という通知が何度か空振りすると、人はその通知を読まなくなります。そうなると、本当に壊れた日の通知も読み飛ばされる。オオカミ少年になった監視は、監視がないより危険です。

だから私は、異常を見つけたときに真っ先にやることを「報告」ではなく「検査自体の確認」にしています。今回もそれで助かりました。もしあの時点で「常駐処理が1つ死んでいます」と報告していたら、実際には元気に動いているものを止めて再起動する、という無駄な事故を起こしていたはずです。

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

一通り点検し終えて、実害のある設定ミスが1件見つかりました。

月末に社内ドキュメントの下書きを作る処理です。「毎月24日から31日のあいだの、平日の夜21時に実行する」というつもりで設定していました。月末の営業日だけ動けばいい処理なので、月に6回程度のはずです。

ところが実際には、月23回動いていました。

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

指定のしかた	期待していた動き	実際の動き
日にち＝24〜31日 曜日＝月〜金	24〜31日のうち平日（月6回程度）	24〜31日のすべて＋平日のすべて（月23回）

つまり「24日から31日」と「月曜から金曜」が足し算になっていたのです。毎週の平日がまるごと対象に入るので、月の大半で動いていました。

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

なぜ実害が出なかったのか

ここが今回いちばん救われた点です。月23回も動いていたのに、業務上の実害はゼロでした。

理由は、処理そのものの中に「営業日でなければ何もしない」というガードが入っていたからです。設定の側で絞り損ねても、プログラムの側でもう一度絞っていた。だから余計に起動された分は、何もせずに終了していました。残ったのは「起動しました」というログの行だけ、つまりログのノイズだけです。

これは偶然ではなく、社内の書き方のルールにしてあることです。経営者向けの通知を出す処理には、冒頭に必ず営業日判定を入れる。土日祝に通知が飛ばないようにするための決まりでしたが、今回はそれが設定ミスの受け皿として働きました。

安全の仕掛けは、一段だけだと破れます。設定で絞り、プログラムでも絞る。二段構えにしておくと、片方が間違っていても事故になりません。「どうせ設定で絞ってあるから」とプログラム側のガードを省かなかった過去の判断に、今回助けられたという感覚です。

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

点検でいちばん手を入れたのは、実は設定そのものではありませんでした。説明書きの方です。

具体的にはこういうものが見つかりました。

• 実体を失った見出しコメントが6件。以前あった処理を整理したときに、その処理を説明する行だけが残っていた。読むと「あるはず」に見えるが、実際には何もない
• 意図が書かれていない設定が2件。同じような処理が朝に2回あり、なぜ2回なのかがどこにも書いていない。実際には「夜のあいだに取りこぼした分を朝に拾い直す」という意図があった
• 実態と食い違うラベルが数件。試作段階のときの呼び名が残っていて、今の役割と違う名前で書かれていた

どれも、動作には一切影響しません。しかし半年後の自分と、これから入ってくる人を確実に迷わせます。「この処理はなぜ2回あるのか」がわからなければ、片方を「重複だ」と判断して消してしまうかもしれない。実体のない説明が残っていれば、「動いているはずのものが動いていない」と誤解して、探さなくていいものを探すことになる。

自動化の保守コストは、処理そのものより**「なぜそうなっているか」の記録が失われること**で跳ね上がります。今回、直した設定は1件、書き直した説明は10件近くありました。この比率が、自動化を持つということの実態だと思います。

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

点検の最後に「減らすかどうか」を考えました。使われていない処理を見つけて整理する、というのは棚卸しの定番です。

結論として、1つも減らしませんでした。点検の結果、70個すべてに今も役割があったからです。

これは自分でも意外でした。弊社の失敗はどちらかというと「作りすぎ」の方向に出るので、棚卸しをすれば無駄が2〜3個は出てくるだろうと予想していたのです。実際にはゼロでした。

なぜかを考えると、増やすときに毎回「これは本当に必要か」を通していたからだと思います。弊社では、何かを作る前に「作らない理由」を先に挙げる決まりにしています。既に同じものがないか、標準の機能で足りないか、そもそも要るのか。この関門を通してきた70個だったので、後から捨てるものが残っていなかった。

棚卸しで大量に捨てるものが出る会社は、入口の判断が甘いということでもあります。今回それが確認できたのは、点検の副産物として悪くない収穫でした。

中小企業にとっての意味

ここまでの話を、経営の言葉に置き換えてみます。

	増やす投資	確かめる投資
かかる時間	1つあたり数十分〜数時間	全体で半日〜1日
効果の見え方	すぐ見える（作業が消える）	見えない（何も起きないことが成果）
やらないとどうなるか	便利にならないだけ	動いていないものを動いていると思い込む
社内での扱われ方	評価されやすい	後回しにされやすい

自動化に前向きな会社ほど、左側だけが増えていきます。右側は成果が見えないので、どうしても後回しになる。しかし右側をやらないと、自動化の総量が増えるほど「思い込みの量」も増えていくわけです。

私が今回やったのは、たった半日の作業です。それで「70個すべてが今日も動いている」と言い切れる状態になりました。この言い切れる状態こそが、次の自動化を安心して増やせる土台になります。

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

次にやること

今回の点検は手作業でやりました。70個を目で追ったので、半日かかっています。同じことを毎回やるのは現実的ではありません。

次は、この点検自体を自動処理にするつもりです。やることは決まっていて、「設定にあるジョブと、対応するログの最終更新時刻を突き合わせて、想定より古いものだけを知らせる」——今回私が手でやったことを、そのまま機械に渡すだけです。

ただし、ここで気をつけたいことがあります。点検の自動化は、それ自体が「動いているつもり」になる典型です。点検係が静かに死んでいたら、何も報告が来ないことを「異常なし」と読み違えます。

なので、この点検には「異常がなくても月に一度は生存を知らせる」仕組みを付けるつもりです。沈黙を「正常」と解釈させない。これも今回、誤報の一件から学んだことの延長にあります。

自動化を増やすというのは、動くものを増やすことではなく、確かめる対象を増やすことなのだと、70個を数え終えて改めて思いました。