先に結論だけお伝えします。うちの仕組みは、成功したかどうかを「終わったときに異常扱いになったかどうか」だけで判定していました。人へ渡すものができているかは、見ていませんでした。そして失敗を知らせる側には、そもそも黙って終わる経路と、知らせの文章そのもので処理が落ちる経路がありました。
穴は一つではなく、三つありました。一つ直しても、残りの二つで同じことが起きます。
念のためお伝えしておくと、これは社内の作業を自動化した仕組みの中で起きたことで、お客様の案件ではありません。おかしなものがお客様に届いたわけでもありません。困ったのは自分たちだけです。
何を自動化していたか
社内の定型作業をひとつ、毎日決まった時刻に自動で動かしています。夕方に仕組みが動いてその日の成果物を用意し、夜に人が中身を確認して承認し、翌朝に仕組みが最後まで進める。この三段です。
大事なところは、真ん中が人だということです。中身を見て「これでいい」と決めるのは人がやると決めてあって、仕組みだけでは最後まで進めないようにしてあります。ここは意図してそう作りました。
この仕組みを動かし始めたのは、これから書く出来事が起きた日の、前の日です。作ってすぐでした。
一つ目の穴。「異常が出なかった」を、できたことにしていた
動かし始めた翌日の夕方、仕組みは予定どおり動き出し、40分ほど走って、異常扱いにならずに終わりました。終了状態だけを見れば、何ごともありません。
ところが、人が確認するはずの最後の成果物は、用意されていませんでした。
正確に言うと、何も作られなかったわけではありません。途中までの作業物は、作業用の場所にちゃんと残っていました。抜けていたのは最後の一手——それらをまとめて、人が見て承認できる形にして差し出す工程——だけです。ここが無いと、次の朝の処理は何も受け取れません。
あとからログを読み返すと、途中に妙な一行が残っていました。処理が自分で「この工程が終わるのを待ちます」と書いているのです。そして待たずに終わっていました。待つと言って、待たなかった。
問題はその先です。当時の仕組みは、成功したかどうかを終わったときに異常扱いになったかどうかだけで判定していました。異常扱いで終わらなければ成功。ただそれだけです。人へ渡すものが本当に在るかどうかは、一度も確認していませんでした。
工場のラインが止まらずに一日を終えたことと、出荷できる製品が1個できたことは、別のことです。途中の工程を飛ばしていても、ラインは終業時刻を迎えます。それをもって「本日の生産は完了しました」と報告する仕組みを、私たちは作っていたわけです。
人が報告するときには、たいてい現物を見ます。「送っておきました」と言う前に送信済みの箱を見る。「印刷しておきました」と言う前にトレイを見る。当たり前にやっているその確認を、機械には求めていませんでした。
なお、当時の仕組みそのものはすでに書き換えてしまっていて、元のかたちは残っていません。ここに書いた当時の挙動は、翌朝の発覚時に書き留めた記録に基づいています。
二つ目の穴。失敗を知らせる経路が、二通りの理由で黙っていた
次の朝、最後まで進める側の処理が動きました。この日、進める候補そのものは見つかっています。ただ、夜に人がやるはずの承認が済んでいなかったため、処理は「進めない」と正しく判断して止まりました。判断は合っています。
問題はそのあとでした。止まったことを人に伝える文章を組み立てるところで、処理そのものが落ちたのです。
知らせの文面は、「本日は公開しませんでした（対象は◯番です）」のようなひな形になっていて、◯のところに実際の番号を差し込む形で書いてあります。このとき、差し込む値の名前のすぐ後ろに、全角の閉じ括弧を続けて書いていました。仕組みはその全角の括弧までを名前の一部だと読み取ってしまい、「そんな名前のものは無い」と言って停止しました。括弧を半角にするか、名前の範囲をはっきり囲っておけば起きないたぐいの書き間違いです。
止めるべき日に、正しく止まると判断できていた。それを人に伝える一行で、落ちていた。宛名を書き間違えた手紙のようなもので、中身が正しくても届きません。安全のために止まる設計は、止まったことが人に届いて初めて働きます。届かなければ、何も起きなかった日と区別がつきません。
そして、ここを直そうとして中身を読み直したときに、もっと静かな穴が見つかりました。この処理には、何もせずに黙って終わる分岐が別に三つあったのです。進める対象が無い。前の日のものが古すぎる。もう済んでいる。三つとも、知らせを出さずに終わる作りでした。
このうち「進める対象が無い」は、前の日の失敗をそのまま映した状態です。夕方の処理が成果物を用意できず、翌朝に進めるものが何も無ければ、ここに入ります。一番知らせるべき状態が、一番静かな経路でした。
三つ目の穴。動かなかった日は、誰も見ていない
ここまでの二つは、どちらも「仕組みが動いたとき」の話です。厄介なのはもう一つのほうでした。
仕組みがそもそも動かなかった日には、何も出ません。パソコンが落ちていた。設定が外れていた。処理が固まったまま終わらなくなった。このとき、その仕組みからは異常も正常も出てきません。
自分の動作を自分で報告する作りは、動かなかったという事故だけは、構造的に報告できません。
日報を思い浮かべると分かりやすいかもしれません。出社していない日には、日報も出てきません。「日報が来ていない」ことに気づく人が別にいないと、休んだことが誰にも伝わらない。仕組みにも同じ穴がありました。
実際、今回それに気づいたのは仕組みではなく人でした。事故の次の朝、人が今日の分は出たのかと聞いたことがきっかけです。自動化の話でこう書くのは体裁が悪いのですが、そうだったので、そのまま書いておきます。
直したことと、直せていないこと
気づいたその日のうちに、三つの穴すべてに手を当てました。
一つ目の穴（成功の判定）には、二つ。まず、成功かどうかを、異常の有無ではなく人へ渡すものが実際に在るかで判定するように変えました。あるはずのものが無ければ、異常が出ていようといまいと警告を出します。もう一つ、処理に2時間30分の打ち切りを入れました。固まったまま終わらなくなる経路が塞がっていなかったためです。時間を超えたら処理を終了させ、そのうえでいつもどおり成果物があるかを確かめて、無ければ警告します。
二つ目の穴（伝わらない知らせ）には、知らせそのものの手当て。黙って終わっていた三つの分岐すべてに知らせを付け、あわせて、処理が落ちる原因になっていた書き方を、同じ書き方をしていた箇所ごとまとめて直しました。
三つ目の穴（動かなかった日）には、外側の見張り。それぞれの処理の外に、もう一段、見張りを置きました。毎晩決まった時刻に走って、その日の結果だけを四点見ます。今日の処理は走ったか。成果物はあるか。朝の処理は動いたか。前の日のやりかけが残っていないか。最後の一つを見ているのは、やりかけが残っていると翌日の処理が「前回が片づいていない」と判断して止まり、そこから何日も連鎖して止まってしまうからです。中で何が起きたかは見ません。結果だけを見ます。
ただし、直せていないこともあります。この見張りも、同じパソコンの同じ仕組みで動いています。パソコンが長く落ちていれば、見張りも走りません。一段外側には出ましたが、装置の外には出ていない。ここは正直に書いておきます。
実際、最初の対処を入れたあと、その日の次の実行でも、処理は同じように最後の成果物を用意しないまま早く終わりました。成果物が無いことを見つけるところまでは動きましたが、それを知らせる文章で、別の全角括弧を同じように名前の一部として読み取り、また処理が落ちました。
そこで、成果物が無い場合は、残っている作業物を引き継いで続きを一度だけ動かす強制を加えました。あわせて、知らせの文章に同じ書き間違いが無いかを探し、実際に文章を組み立てても落ちないことを確かめる検査も追加しました。
ただし、この再発後に加えた対処が効いたかどうかは、まだ言えません。追加後の運用実績がなく、有効性を十分に示せていないからです。
作った知らせは、一度動かしてみるまで分からない
今回いちばん残ったのは、これでした。
落ちていた知らせは、その日まで一度も通ったことのない経路にありました。書いた時点では、誰もそれが動くかどうかを知りませんでした。書いてあるから動くだろう、と思っていただけです。実際には、そこに書いた全角の括弧一つで止まっていました。
なので新しい見張りは、作ったその日に実際に走らせました。異常があると判定して、警告を記録に書き出すところまでは、HaruIroAIで実行して確認しています。ちなみにこのときの実行は、まだその日の処理が動く前の時刻に走らせた確認なので、本番の異常を捕まえた例ではありません。それでも、書いたものが素通りせずに動くことは分かりました。
手元でできる三つのこと
一つ目は、自動化の「完了しました」が何を見て言っているのかを、作った人に一度聞いてみることです。バックアップでも、予約の自動返信でも、データの取り込みでも構いません。「処理が異常なく終わったら完了」と答えが返ってきたら、そこが今回と同じ形です。できたものが在ることを見て判定してください、と頼めます。バックアップならファイルの日付と大きさ、自動返信なら送信済みの記録が、その「できたもの」にあたります。
二つ目は、失敗したときに本当に連絡が来るのかを、実際に確かめておくことです。ただし、動いている本番の設定を自分で外して試すのはやめてください。処理が中途半端なところで止まると、おかしなデータが残ったり、元に戻せなくなったりします。試すなら、本番とは別に用意した練習用の環境で行います。そういう環境が無いなら、自分でいじらずに、その仕組みを作った人や保守している人へ「失敗したときの連絡が本当に届くか、一度試してほしい」と頼むのが確実です。依頼するときは「本番に影響が出ない試し方でお願いします」と添えてください。安全に試せる方法が無いなら、無理に実施しないことです。
三つ目は、「動かなかった日」に気づく方法を一つだけ決めておくことです。凝った仕組みは要りません。毎朝その成果物を開いて日付を見る、でも構いません。大事なのは、その仕組み自身に頼らずに結果だけを見る手段が一つはある、という状態にしておくことです。
火災報知器は、点検で鳴らしてみるまで分からない
火災報知器は、火が出たときに鳴るためにあります。ただ、いざというときに本当に鳴ってくれるかどうかは、点検で一度鳴らしてみるまで分かりません。天井に付いているだけの白い箱と、鳴ることを確かめてある報知器は、見た目は同じでも別のものです。
自動化の知らせも同じでした。書いてあるだけの知らせは、まだ知らせではない。それを、動かし始めた翌日に起こして、その次の朝に教わりました。
これはHaruIroAIで起きた1件の話で、どの仕組みでも必ずこうなるという話ではありません。それでも、いま何かを自動で動かしているなら、「うまくいったときの連絡」ではなく「うまくいかなかったときの連絡」を、一度確かめてみる価値はあると思います。
自動で出てくる報告が実態とずれていた話は、以前にも書きました。そちらは「まだ終わっていません」と出ていたものが、実は7週間前に終わっていた、という逆向きのずれでした。「確認しました」の後で実態が違っていた話はこちらです。報告と現物のあいだにある隙間は、方向を変えて何度でも出てきます。
この記事を書いた人
この記事の作り方
この記事は、構成・一次記録の照合・文章化にAIを使用し、HaruIroAIの編集ルールと社内の一次記録（実行ログ・事故翌日に作成した記録・現行の設定）に基づいて作成しています。社内で使っているツールの名称、仕組みが何を作る処理かの詳細、社内の保存場所は、本題と無関係なため記載していません。内容は公開前に人が最終確認しています。