あと数日遅かったら、社員名簿が消えていました — 中小企業 × AI 経営（2026年8月）

取引先にメールを送って、返事が来ない。

このとき「反対されていないから、進めていいだろう」と考えるか、「確認が取れるまで止めておこう」と考えるか。おそらく多くの方が後者を選ぶと思います。返事が来ないことは、了承ではないからです。

ところが弊社のプログラムは、前者をやっていました。しかもその先で、社員名簿を消す仕掛けになっていました。

先日その構造を見つけて、大急ぎで直しました。障害はまだ起きていません。誰も困っていません。それでも直すべき夜でした。この記事はその記録です。

何が仕込まれていたか

弊社は社員の情報を、表計算のシートで管理しています。誰が在籍していて、誰が何を担当するか。毎朝プログラムがそれを読みにいき、読んだ内容をもとに、その日のタスクを誰に届けるかが決まります。

そのプログラムは、こういう順番で動いていました。

1. シートから社員の一覧を読む
2. 読むのに失敗したら、「0人だった」ことにして先に進む
3. 一覧が0人なら、初期データで作り直す

一つずつ見ると、どれも親切な設計です。2は「エラーで全部止まるより、続けたほうがいい」という配慮。3は「初めて使うときに、自動で用意してあげる」という配慮です。

問題は、この2つが並んでいることでした。

実際に起きたこと	プログラムの受け取り方	その結果
通信が一瞬つながらなかった	「社員は0人だった」	初期データで上書き

つまり、通信が一度でも失敗したら、社員名簿がまっさらに戻る。入ったばかりの社員の登録も、退職した社員の反映も、全部です。

「返事が無い」と「0人です、という返事」

冒頭の話に戻ります。

読めなかったのと、読んだ結果が0人だったのは、まったく違う出来事です。前者は「相手から返事が来ていない」状態で、中身が何だったかは誰にも分かりません。後者は「確かに確認した結果、0人だった」という事実です。

この2つを同じ引き出しに入れてしまうと、分からないものを「無かった」ことにして先へ進むことになります。今回の名簿はまさにそれでした。

同じ間違いは、プログラムの外にもあります。

よくある場面	危ない受け取り方
発注書の返信が来ない	「異議なしだから進めよう」
現場から報告が上がらない	「問題が起きていないんだろう」
担当者が数字を出してこない	「先月と同じ数字でいいか」

どれも「情報が届いていない」だけなのに、「良い知らせだ」と読み替えています。沈黙を承諾と読む——これが今回、弊社のプログラムがやっていたことでした。

なぜ今まで無事だったのか

答えは身も蓋もありません。運が良かっただけです。

このプログラムは毎日動いています。通信の一時的な失敗というのは、クラウドのサービスを使っていれば必ず、ときどき起きるものです。相手のサーバーが「いま混み合っています、少し待ってください」と返してくるだけの、異常でもなんでもない出来事です。

つまりこの仕掛けは、毎日引いているくじでした。当たりを引いた日に名簿が消える。今まで当たらなかった、それだけです。

「ずっと動いているから大丈夫」は、この種の欠陥には何の保証にもなりません。むしろ動き続けた期間が長いほど、引いたくじの回数だけが積み上がります。

直したのは、たった一つの区別

修正の中身は、驚くほど単純でした。

「読めなかった」と「本当に0人だった」を、別のこととして扱う。

• 一時的な通信の失敗 → 名簿には触らない。そのまま次の日に任せる
• 権限が無くて読めない → これも触らない。人が直すべき問題です
• シートがまだ存在しない（本当の初回）→ このときだけ、初期データで作る

「0人だ」と判断していいのは、読むことに成功して、その結果が0人だったときだけ。当たり前のことですが、当たり前が抜けていました。

ついでに、似た危なさのある処理をあと3本直しています。ひとつ気をつけたのは、やり直しの機能を足すときは、二重に記録されないようにすることでした。失敗したらもう一度やる、という仕組みを入れると、今度は「1回目も成功していた」場合に記録が2つ並びます。直した手が新しい事故を作る、というのもよくある話です。

直した直後に、本物が来ました

この夜、いちばん背筋が冷えたのはここです。

修正を入れて動作を確かめていたまさにその最中に、本物の通信エラーが起きました。

直す前の作りなら、この瞬間に名簿は消えていました。直した後の動きはこうです——失敗を失敗として受け止め、少し待ってもう一度試し、2回目で成功し、最後まで走り切りました。名簿は無傷でした。

試験用に作った模擬エラーではありません。本番で、本物が、直した直後に来て、直したとおりに受け止められた。これ以上の動作確認はありません。

同時に、こうも思いました。修正があと数日遅ければ、これは「くじが当たった日」だったということです。

全部を直そうとはしませんでした

点検した処理のうち、あえて手を付けなかったものが2本あります。

1本は、人が手で動かすツールです。動かすときは必ず人が画面の前にいるので、失敗すればその場で分かります。もう1本は、話しかけて使うタイプの機能で、こちらはもともと備えがありました。

危なそうなものを全部同じように包み直す、ということはしませんでした。危険の形が違うものに同じ手当てをすると、コードが無駄に増えるだけです。増えた分は、次に点検するときの荷物になります。守りを固めるときほど、どこを固めないかを決める必要があります。

明日できる確認

もし社内に「どこかからデータを読んで動く自動処理」があるなら、担当の方に聞く質問はひとつだけです。

読みにいって失敗したとき、それは何をしますか？

「止まります」なら安心です。「空だったことにして先に進みます」と返ってきたら、その先で何が起きるかを一緒に追ってください。進んだ先に「空なら作り直す」「空なら消す」といった親切機能が待っていたら、弊社と同じくじを持っています。

くじは、当たる前なら破り捨てられます。

そしてこの手の仕事は、誰の目にも見えません。障害は起きないし、明日も何も変わらず動きます。防いだ事故は数字に出ません。それでも、70個の自動処理を点検した話にも書いたとおり、自動化を増やすというのは、確かめる対象を増やすことなのだと思います。