自動化した仕組みは静かに止まる｜止まったと分かる設計にする

作った仕組みが動かなくなる。これ自体は避けられません。問題は、止まったことに何日も気づかないことです。

手作業なら、やっていない日はすぐ分かります。自動化した処理は、動かなくてもエラーが目に見えるところに出ません。気づくのは、月末の集計が合わなかったとき、あるいは相手から指摘されたときです。この記事では、止まったことに気づく設計と、止まっている間をしのぐ手順の作り方を説明します。

ムダの現状：止まったことに気づかない

自動化した処理は、いくつかの理由で止まります。

問題は、止まっても誰も困らない期間があることです。毎朝の集計が止まっても、その日は誰も見ていないかもしれません。気づくのは、数字が必要になったときです。

「失敗したら通知」では、気づけない

多くの仕組みは、エラーが起きたときに通知する形で作られます。これが落とし穴です。

処理そのものが起動しなかった場合、エラーも起きません。失敗の通知は、失敗したことを知らせる仕組みが動いている場合にだけ届きます。

そして、通知の宛先が作った人の個人のアドレスになっていることがあります。その人が異動したら、通知は誰にも届きません。

機械に渡せる部分と、人に残す部分

1番目を「失敗したら」から「動いたら」に変えることが、この記事の中心です。

スキームの全体図：動いたことを通知する

目指すのは、止まらない仕組みではありません。止まったことがすぐ分かり、止まっている間もしのげる仕組みです。前者を目指すと、作りが複雑になって、かえって止まりやすくなります。

必要なツールと費用（2026年9月23日時点）

監視の専用ツールは要りません。小規模な自動化を数件から数十件持っている状態なら、この4つで足ります。専用ツールが要るのは、止まったときの影響が即座に出る処理を持っている場合です。

導入手順：動いた通知から始める

Step 1：成功したことを、通知する

最初にやるのは、通知の条件を変えることです。

「エラーが起きたら通知」を「処理が終わったら通知」に変えます。成功しても通知が来る形にする。

これに対して「通知が多くなる」という反応が出ます。だから、次のStep 2とセットで設計してください。

そして、通知の文面は1行で足ります。処理の名前、時刻、件数。これだけです。

Step 2：件数を、一緒に出す

通知に件数を入れると、通知の価値が変わります。

「動いた」だけの通知は、読み飛ばされます。でも「12件処理しました」なら、いつもと違う数字に気づけます。

そして、0件で成功している状態が、いちばん危ないのです。元データが読めていない、条件が合わなくなっている。処理としては成功していても、何もしていません。

0件のときは、通知に印を付けてください。「0件（要確認）」のように。毎日0件が続くなら、それは止まっているのと同じです。

通知を読む人を、決める

通知を出しても、誰も見ないなら意味がありません。読む人を決めてください。

ただし、全部を毎日読ませる必要はありません。チャットの1つのチャンネルに流し、流れているという状態だけ見える形にします。

そして、異常な数字のときだけ目に留まればよい。だから、0件や普段と桁が違う件数には印を付けます。

Step 3：宛先を、個人にしない

通知の宛先を、作った人の個人のアドレスにしないでください。

これは、実務でいちばん多い失敗です。作った人が異動や退職をすると、通知が誰にも届かなくなります。そして、止まっても分かりません。

チームで見る場所に送ってください。チャットのチャンネル、共有のメールアドレス。人が変わっても残る場所です。

そして、既にある仕組みの通知先を、この機会に確認してください。個人宛になっているものが、たいてい見つかります。

Step 4：月に1回、一覧と突き合わせる

通知が来ないことは、通知では分かりません。だから、月に1回の確認が要ります。

やることは単純です。仕組みの一覧を開き、それぞれについて直近の通知が来ているかを見る。来ていないものが、止まっているものです。

この確認は10分で終わります。仕組みの一覧がある前提です。一覧がないと、何が動いているはずかが分かりません。

一覧に持つのは5つです。処理の名前、動く頻度と時刻、何をするか、止まったときの影響、そして担当者。

一覧がない場合の作り方

自動化した処理の一覧を持っていない会社は多くあります。この場合、まず一覧を作るところから始めてください。

作り方は3つです。1つ目、定期的に届いているメールや通知から逆に引く。何かが動いている証拠です。2つ目、使っているサービスの設定画面を開いて、定期実行の設定を見る。3つ目、部署ごとに「自動で動いているものはありますか」と聞く。

3つとも完全ではありません。3つをやって突き合わせると、だいたい揃います。そして、この作業で出てきた「誰も知らない処理」が、いちばん危ないものです。

担当者は、個人名で書く

一覧の担当者を、役職や部署で書かないでください。誰が見るかが決まりません。

そして、作った人と担当者を分けてください。作った人が異動しても、担当者は残ります。担当者は、止まったときに誰に相談すればよいかを知っている人であれば足ります。

中身を全部理解している必要はありません。止まったことに気づいて、動ける人を割り当てる。これで十分です。

Step 5：止まったときの手順を、先に書く

仕組みを作った時点で、止まったときの手順を書いてください。後回しにすると、書かれません。

書くのは3つです。この処理が止まると何が困るか。手作業でやる場合の手順。そして、いつまでに復旧が必要か。

2つ目が要点です。自動化する前にやっていた手順を、そのまま残しておく。新しく書く必要はありません。

そして、3つ目で「今日中」なのか「今月中」なのかを決めておくと、止まったときに慌てずに済みます。多くの処理は、数日止まっても致命的ではありません。

最初は、止まると困る3つだけ

全部の仕組みに通知を付けようとしないでください。

最初は3つです。止まったときの影響が大きいものから選びます。お金が動くもの、外部に送るもの、法令で期限があるもの。

この3つで、通知の形式と月1回の確認の手順を確かめます。そこから広げてください。

そして、この3つを選ぶ過程そのものに価値があります。「止まったら何が困るか」を1件ずつ考えると、実は誰も困らない処理が見つかることがあるからです。

誰も困らない処理は、止める候補です。動かし続ける理由がないなら、監視の対象を増やす前に止めてください。監視すべきものを減らすのが、いちばん確実な対策です。

現場の合意の取り方：作った人に依存させない

担当の役割を、「気づくこと」に限る

2つ目の懸念は、担当の役割を広く取りすぎているから生まれます。

担当がやるのは2つです。月に1回、通知が来ているかを確認すること。来ていなければ、決まった相手に連絡すること。

直すことは、担当の役割に入れません。気づく人と、直す人を分けてください。この分け方にすると、担当を引き受けてもらえます。

そして、連絡する相手を一覧に書いておいてください。作った人、詳しい人、外部の委託先。名前と連絡先が書いてあれば、担当は迷いません。

この相手が社内にいない場合もあります。その場合は、そう書いてください。「作った外部の担当者は既に離任。修理の当てはない」。書いてあれば、止まったときに手作業へ切り替える判断が速くなります。

直せなくても、止まらない状態にする

3つ目の懸念は、実際に起きる問題です。作った人しか中身が分からない仕組みは、必ずあります。

これを全部なくすのは現実的ではありません。代わりに、直せなくても業務が止まらない状態を作ってください。

Step 5で手動の手順を書くのは、このためです。直るまでの間、手作業で回せるなら、仕組みが止まっても業務は止まりません。

失敗パターンと限界：気づけないものがある

「動いているが、間違っている」は検出できない

この記事の設計で気づけるのは、止まったことだけです。

動いているが結果が間違っている、という状態は検出できません。条件の設定が変わって違うものを対象にしている、計算の一部が古いままになっている。こうした場合、通知は正常に届きます。

これに対しては、別の確認が要ります。月に1回、出てきた結果をいくつか目で見る。全件ではなく、数件で足ります。

この確認を、通知の確認と同じタイミングでやってください。別のタイミングにすると、片方がやられなくなります。

通知の仕組み自体が止まることがある

通知を送る部分も、処理の一部です。ここが止まると、何も届きません。

完全に防ぐことはできません。ただし、月1回の突き合わせがあれば、通知が来ていないこと自体に気づけます。

だから、月1回の確認を省かないでください。通知を出しているから安心、という状態がいちばん危ない。

そして、この月1回の確認そのものを自動化しないでください。確認を自動化すると、その自動化が止まったときに誰も気づけません。

人が一覧を開いて目で見る工程を、1つだけ残す。10分で終わる作業なので、月に1回なら負担になりません。どこかに人の目を残すことが、この設計の前提です。

止まった影響が、後から出るものがある

止まったことに気づいても、その間に生じた影響が後から出ることがあります。

記録が取られていなかった。通知が送られていなかった。データが更新されていなかった。

だから、復旧したときに止まっていた期間の処理をやり直すかどうかを判断してください。やり直す場合の手順も、Step 5であわせて書いておきます。

とくに、法令で保存や報告が求められている記録に関わる処理は、止まっていた期間の扱いを慎重に確認してください。判断に迷う場合は、対象となる法令に応じた専門家に確認してください。

この設計が向かない場合

止まったことが即座に業務に影響する処理では、月1回の確認では遅すぎます。この場合は、通知が来ないことを機械が検出する形が必要です。

ただし、その仕組み自体も止まりえます。どこかで人が見る工程は残ります。

そして、自動化している処理が数百件を超える規模では、一覧を人が確認する形は成り立ちません。この場合は、監視の専用の仕組みを検討する段階です。

AIを使うなら、通知の要約に

通知の中身をAIに監視させる使い方は、慎重に考えてください。監視の仕組みが増えると、そちらも止まりえます。

効くのは、月1回の確認のときに、溜まった通知を要約させる使い方です。「今月、0件だった処理」「件数が普段と大きく違った処理」を出す。

ただし、要約に出てこなかったものが正常だとは限りません。一覧との突き合わせは、人が行ってください。要約は、突き合わせを速くする補助として使います。

効果の測り方

1つ目が、この設計の中心的な効果です。止まること自体は防げないので、気づくまでの日数で測ってください。

2つ目は、ゼロを目指す数字です。個人宛の通知が残っている限り、その人が異動したときに止まります。

3つ目も、ゼロではなく100%を目指します。ただし、影響の小さい処理まで手順を書く必要はありません。止まると困る処理について、書かれているかを見てください。

まとめ

自動化した仕組みは止まります。これは避けられません。問題は、止まったことに何日も気づかないことです。

やることは3つです。「失敗したら通知」を「処理が終わったら通知」に変えること。通知に件数を入れ、0件のときは印を付けること。そして、通知の宛先を個人ではなくチームで見る場所にすることです。

0件で成功している状態が、いちばん危ない。処理としては成功していても、何もしていません。

そして、月に1回、仕組みの一覧と実際に届いた通知を突き合わせてください。通知が来ないことは、通知では分かりません。この確認は10分で終わりますが、一覧がある前提です。

最後に、仕組みを作った時点で止まったときの手順を書いてください。自動化する前にやっていた手順を、そのまま残しておけば足ります。直せなくても業務が止まらない状態を作ることが、止まらない仕組みを目指すより現実的です。

よくある質問

エラー通知だけでは、なぜ足りないのですか

処理そのものが起動しなかった場合、エラーも起きないからです。失敗の通知は、失敗したことを知らせる仕組みが動いている場合にだけ届きます。だから、成功したことも通知する形に変えてください。そして、通知が来ないことは通知では分からないので、月1回の突き合わせが必要です。

成功も通知すると、通知が多くなりませんか

通知の文面を1行にしてください。処理の名前、時刻、件数。これだけです。そして、チャットの1つのチャンネルに流し、流れているという状態だけ見える形にします。全部を毎日読ませる必要はありません。0件や普段と桁が違う件数にだけ印を付ければ、そこに目が留まります。

「0件で成功」は、正常ではないのですか

正常なこともありますが、いちばん危ない状態でもあります。元データが読めていない、条件が合わなくなっている。処理としては成功していても、何もしていません。0件のときは通知に印を付けて、毎日0件が続くなら止まっているのと同じだと考えてください。

通知の担当になると、直す責任も負いますか

担当の役割を「気づくこと」に限ってください。やるのは2つです。月に1回、通知が来ているかを確認すること。来ていなければ、決まった相手に連絡すること。直すことは担当の役割に入れません。気づく人と直す人を分けると、担当を引き受けてもらえます。

作った人しか直せない仕組みは、どうすればよいですか

全部をなくすのは現実的ではありません。代わりに、直せなくても業務が止まらない状態を作ってください。仕組みを作った時点で、止まったときに手作業でやる手順を書いておく。自動化する前にやっていた手順を、そのまま残しておけば足ります。

動いているが結果が間違っている場合は、気づけますか

この設計では気づけません。通知は正常に届きます。だから、月1回の通知の確認と同じタイミングで、出てきた結果をいくつか目で見てください。全件ではなく数件で足ります。別のタイミングにすると、片方がやられなくなります。

同じ部門の記事

導入ツールを乗り換えるときのデータ移行｜全部を持っていかないと決める2026年10月21日
導入業務マニュアルが更新されない理由｜作る前に、更新の担当と頻度を決める2026年10月15日
導入業務棚卸しを2時間で終わらせる｜大中小の分類をやめ、頻度と時間の2軸で並べる2026年10月9日