実行ログを開いて、同じ狙いキーワードの下書きが2本できているのに気づいたことがある。私はブログ5サイトをAIで自動化し運営している。9月末から10月上旬にかけて、自動化の再発防止につながる事故が4パターン連続した。原因は設定ミスではなく、定期実行の場所が2か所に増えていたことだった。
自動化で同じ事故が4パターン、6日間に連続した
9月30日から10月5日までの6日間に、運営している複数のブログの自動処理で、似た形の事故が続けて起きた。1つ1つは別のシステムで動いているので、最初は無関係な話だと思っていた。並べてみると、どれも同じ処理が1日に2回動いたという一点で共通していた。
自動化の失敗は、再試行では直らないこともある。自動化の失敗｜同じ再試行では直らない時があるでは、4回再試行しても回復しなかった障害を書いた。今回の4パターンは再試行の失敗ではなく、むしろ成功している処理が2回動いてしまう、逆方向の事故だった。
| 症状 | 気づいた瞬間 | 処置 |
| 記事の校正が同日2回実行され、後発が先発の修正を古い本文で上書き | 公開済みの記事に、消えたはずの修正が残っていないか確認したとき | 先発の修正内容をベースに、2回分の修正をマージして再投稿 |
| 同じ狙いキーワードで2本目の下書きができていた | 投稿前の最終確認で、同じテーマの下書きがもう1本あるのに気づいた | 2本目をゴミ箱へ移し、紐づく画像や出典ファイルも無効化 |
| 別の自動処理で、ファイルの中身が読み込み直後に変わっていた | 読み込んだ内容をもう一度開いたら数字が変わっていた（ファイルのmd5が変化） | 変わった後の内容を土台に、作業をやり直した |
| 同じ作業が5日連続で二重に動きかけた | 作業を始める前に、その日の実行ログの末尾を確認したらすでに完了していた | 新しく作らずそのまま終了（実害はゼロ） |
再発防止の前に見えた、事故の共通点
4パターンを並べて、2つのことに気づいた。まず、同じ処理が2回動くと、2回目が1回目の成果を消すことがある。記事の校正のように、後から動いたほうが正しいと思い込みやすい処理ほど、実は危ない。
もう1つは、事故に気づけた実行は、すべて作業を始める前に今の状態を読み直したものだったこと。自動化の監視が「異常なし」と報告しても、監視そのものが見落とすことがある。その話は自動化の監視が嘘をついた話｜見落としの正体と対策に書いた。今回効いたのは監視を強化することではなく、作業の入り口でもう終わっていないかを自分で読み直す手順を1つ足すことだった。
自動化の本当の原因は設定ミスではなく実行場所が2か所あったこと
調べてみると、きっかけは9月24日以降のことだった。手元のパソコンに登録していた定期実行の設定が、知らないうちにクラウド側にも複製されるようになっていた。パソコン側は決まった時刻に動き、クラウド側は数分遅れて動く。同じ処理が1日に2回走る条件が、気づかないうちにそろっていた。
クラウド側にあった37件を、確認のうえ一度すべて無効化した（削除はせず、戻せる形で止めた）。うち2件は、その時点ですでに停止していたものだった。パソコン側の58件には変更を加えていない。設定を書き間違えたわけではなく、実行する場所そのものが2か所に増えていたのに、誰も把握していなかった。これが原因だった。
自動化の実行場所を1つにまとめた対処
10月6日に、「このコンピューターのみ」という選択肢が仕組みの側から廃止された。パソコン側だけで動かす、という選び方自体ができなくなったため、10月8日にクラウド側へ一本化した。移動できなかった分はパソコン側を一時停止し、クラウド側の設定を有効化し直した。
一本化した直後に、別の前提が変わっていることにも気づいた。クラウド側で動くと、実行ログの時刻が協定世界時（UTC）で記録される。10月10日に、各ブログの設定ファイルへ時刻を日本時間で記録するルールを1行だけ加えて対処した。実行場所を変えると、こうした前提も一緒に変わる。見落としやすい例として、ここに短く残しておく。
再発防止策が効いているかを3週間の数字で確認した
一本化しただけで終わりにせず、効いているかどうかを数字で見ることにした。各ブログの検索データを自動で取得する処理を確認した。一本化後の10月12日・19日・26日の3週にわたって、運営している5つのブログすべてで取得が成功していた。
| 週 | 実行日 | 結果 |
| 1週目 | 10月12日 | 5ブログすべて成功 |
| 2週目 | 10月19日 | 5ブログすべて成功 |
| 3週目 | 10月26日 | 5ブログすべて成功 |
もう1つ、別の自動処理でも動きがあった。10月1日から5日まで、作業を始める前にもう終わっていないかを確認する手順が5日連続で働いた。二重の動作を実害なく止めていた。再発防止策は、一度仕組みを直して終わりではなく、こうして日数を重ねて確認してはじめて効いていると言える。もちろん、これで事故が永久に起きなくなるとまでは言えない。来月また別の形で同じ根の問題が出てくる可能性は残っている。
業務改善の一般的な解説がある。原因を特定したあとの対策は、元に戻ることのない仕掛けをつくる必要があるとされている。そしてそれは、日常の業務の中に織り込まれることを指すと説明されている。対策を人の注意力だけに任せず、仕組みのほうに置くという考え方は、今回の対処とも重なる。
参考：中小企業基盤整備機構 J-Net21／キヤノンMJ「再発防止策の考え方」
まとめ｜再発防止は「チェックを足す」より「書く前に読む」が効いた
今回の4パターンから持ち帰れるのは3つ。同じ処理の二重実行は、2回目が1回目の成果を消すことがある。気づけたのは監視ではなく「書く前に読む」習慣だった。そして原因は設定ミスではなく、実行場所が増えたのに誰も把握していなかったこと。一覧を2か所で持つと、だいたいズレる。
直したのは実行場所だけで、仕組みそのものを大きく変えたわけではない。地味な対処だが、3週間分の結果を見るまでは、正直どこまで効くか半信半疑だった。
よくある質問
Q. 再発防止策は、一度直せばそれで終わりですか？
いいえ。対策を仕組みに組み込んで、しばらく結果を確認してはじめて効いていると言える状態になります。今回も一本化してから3週間分の実行結果を見て、ようやくそう言える段階に来ました。
Q. 同じような事故は、どんな自動化でも起こりますか？
実行する場所が複数になっている自動化では起こりやすいと考えています。今回の原因も、定期実行の登録先がパソコン側とクラウド側の2か所に増えていたことでした。
Q. 気づくための工夫はありますか？
作業を始める前に、その日の実行ログの末尾を確認する手順を加えました。すでに完了していれば新しく作らずに終了する、というだけの手順です。これだけで5日連続の二重実行を実害なく止められています。
あわせて読みたい
