先に結論をお伝えします。自動処理には「もう済んだかどうか」を調べる関門が入っていました。それは壊れていませんでした。ただ、調べに行く場所と、済んだ証拠が実際に置かれる場所が、いつも同じとは限らない作りだったのです。
先にお伝えしておくと、これは社内の作業を自動化した仕組みの中で起きたことで、お客様の案件ではありません。二度目の実行は、実際に公開されているサイト——以下これを本番と書きます——へ届く前に拒否されています。公開したものが壊れたり、二重に出たりはしていません。困ったのは自分たちだけです。
どういう段取りで回しているか
ブログの記事を出す作業を、三段に分けて動かしています。夕方に仕組みが記事一式を用意する。夜に人が中身を確認して承認する。翌朝七時五十分に、仕組みが公開まで進める。
真ん中が人であることは、意図してそうしています。中身を見て「これでいい」と決めるのは人の仕事だと決めてあって、機械だけでは最後まで進めません。
夜の承認を終えると、画面に一行出ます。明朝七時五十分に自動で公開されます、と。つまりこの段取りは、人が承認したあと、朝まで待つことを前提にしています。
本番に届くまでに、関門は三つある
ここから先を読みやすくするために、先に関門を並べておきます。うちの朝の処理は、本番を書き換えるまでに三つの門をくぐります。
一つ目が済み確認です。この記事はもう公開したか、を調べます。済んでいれば、そこで引き返します。
二つ目が事前確認です。いま公開しようとしている中身が、承認された中身と一致しているかを照らし合わせます。読むだけで、何も書き換えません。
三つ目が使い切りの通行証です。本番を書き換える操作は、そのたびに一度だけ使える許可を要求します。クリーニングの引換券に似ていて、出せば品物は受け取れますが、券は手元から無くなります。
この日おかしくなったのは一つ目で、最後に止めたのは三つ目でした。
その夜、待たずに手で終わらせた
その日は、記事の中身が固まった直後、その場で公開まで一気に通しました。日付が変わって少し経った頃です。処理は成功し、記事はその時点で世に出ました。
ここまでは何も問題がありません。急いだこと自体が悪いわけでもない。ただ一つだけ、置き去りになったものがありました。翌朝の処理も、同じ仕事を持ったままだったことです。
夜の承認のあとには「明朝七時五十分に公開されます」という案内も出ていました。読めば、朝にもう一度動くことは分かります。ただ、朝の処理が「もう済んだ」と知る手段は、一つ目の関門——済み確認——ただ一つでした。夜のうちに手で終わらせたことを朝の処理へ伝える経路は、ほかにありません。二度目を防ぐ役目は、その一つに任せきりだったわけです。
普段は自動で回る。急ぐときは人が手でやる。この二つが同じ仕事を持っている運用は、めずらしくないと思います。そして両方が同じ台帳を見ていなければ、同じ仕事がもう一度走りかける余地は残ります。
翌朝、済み確認は「まだ済んでいない」と答えた
朝七時五十分、処理は予定どおり起き上がり、その日公開すべき記事を探しました。見つかったのは、数時間前に人が公開し終えた、あの記事です。
一つ目の関門、済み確認が働きました。そして「まだ済んでいない」と答え、処理は先へ進みました。
二つ目の事前確認も通りました。承認された中身と、これから公開しようとしている中身は一致している。青信号です。
本番の直前で、通行証が無かった
そして本番を書き換える段になって、処理は拒否されました。理由は「この操作に対する有効な許可がない」。
事前確認は「承認あり」と答えたのに、本番の実行は「許可がない」と答えたわけです。ここが分かれ目でした。二つ目と三つ目は、どちらも承認にまつわる関門ですが、見ているものが違います。
事前確認が見ていたのは、どの中身が承認済みかという記録です。これは書き換えるまで残り続けます。台帳に貼ってある、承認印の押された紙のようなものです。一方、三つ目が要求するのは使い切りの通行証のほうでした。紙は貼ってあるが、券は無い。それが朝の状態です。
券がどこで無くなったのかは、記録では追えていません。この仕組みは、本番を書き換える操作の直前に券を一枚使う作りになっています。前の晩にその操作が成功しているので、そこで使われたと考えると筋は通ります。ただ、その一枚が夜の実行で使われたと示す記録は残っていないので、そう決めつけずに書いておきます。
念のため、この記事を書いている時点で、HaruIroAIでもう一度、同じ事前確認だけを走らせて確かめました。朝の拒否から八時間以上経っていますが、いまも「承認あり」と返ってきます。読むだけの確認なので、何も変えていません。食い違いは、その朝かぎりのものではありませんでした。
いまの危険度を、ここで一度まとめておきます。公開済みの記事は正常に読めます。二重に公開されたことも、内容が壊れたこともありません。残っているのは、同じ条件がそろえば同じ形でまた止まる、という状態です。
なぜ「もう済んだ」と分からなかったのか
済み確認は、決められた場所に実行記録——ここでは済んだ印と呼びます——が残っているかどうかを見ています。あれば済み、なければ未了。単純です。
問題は、印の置き場所のほうにありました。印の出し先は、実行したときにどこに立っていたかで決まる作りだったのです。朝の処理は決まった場所へ移動してから走るので、印もいつも同じところに出ます。ところが夜、人が手で走らせたときは、立っていた場所が違いました。印は別のところに残りました。
朝の処理は、いつもの一か所を見に行って、そこには何もなかった。だから「まだ済んでいない」と答えました。見た範囲では、正しく答えています。
この関門が壊れているわけではない、というのも大事なところです。その数日前、七月二十八日と二十九日には、同じ済み確認が正しく働いて二度目を見送っています。ではなぜそのときは通じたのか。二十八日も、公開したのは人でした。ただそのとき人が立っていた場所が、たまたま朝の処理と同じだったのです。印はいつもの一か所に残り、以降の済み確認はそれを見つけられました。
つまり、通じるかどうかは、その日たまたま誰がどこに立っていたかで決まっていました。壊れていたのは関門ではなく、印の置き場所が動くことに関門が追いついていない、という関係のほうです。
事務でたとえるなら、処理済みの伝票を戻す箱が、その日たまたま座った席によって変わるようなものです。確認する人はいつも同じ箱を見ます。箱が空なら未処理。伝票は別の箱にちゃんとある。誰も嘘をついていないのに、二度目が走ります。
失敗した記録が、済んだ印になってしまう
もう一つ、あとから気づいたことがあります。
拒否されて失敗に終わった朝の実行も、記録は残しました。しかもその置き場所は、済み確認が見に行くのとまったく同じ場所、同じ名前です。中身を開けば「失敗」と書いてあります。
けれど済み確認は、中身を読みません。あるかどうかだけを見ます。つまり今そこには、失敗の記録が、済んだ印と同じ顔をして置かれていることになります。
既知の範囲では、これによる実害はまだ出ていません。この印が指しているのは、すでに公開が終わった回だからです。翌日以降は別の記事が対象になるので、いま分かっている限り、公開が止まる経路にはなっていません。それでも、印の意味が中身とずれたまま残っているのは確かです。
記録に残ったのは「失敗しました」だけだった
その朝の実行記録は、公開に失敗した、の一行で終わっています。人へ向けて出る知らせも、同じく失敗を伝える一行です。
記事はその七時間ほど前、日付が変わった直後から、すでに読める状態になっていたのにです。
責められる話ではありません。朝の処理は、自分がやろうとしたことに失敗した。その事実を正しく伝えています。ただ、朝の処理が知っているのは自分の担当範囲だけで、前の晩に何があったかは知りません。
この朝の知らせは、朝の処理から見えた範囲の結果だけを伝えていました。全体としてどうだったかではなく、自分の担当ぶんがどうだったかです。この日の「失敗しました」は、仕事が終わっていないことを意味していませんでした。前に書いた回では逆に、「成功しました」のほうが、渡すべきものができたことを意味していませんでした。同じ隙間の、表と裏です。
まだ直していません
何を直すかは決めました。済んだ印を、実行したときの立ち位置に左右されない場所へ固定すること。印はあるかどうかではなく、中身が成功かどうかで判定すること。そして、人が先に済ませたときに、自動側からもそれが分かるようにすること。
ただし、まだ入れていません。直したという実績も、それが効いたという実績もありません。
ちょうど前の日に公開した記事で、「書いてあるだけの知らせは、まだ知らせではない」と書きました。決めただけの対処も同じです。今日の時点でお伝えできるのは、こういう形の穴が実際にあった、というところまでです。
手元でできる三つのこと
一つ目は、自動で動いている仕事について、「もう済んだかどうかを何で判断していますか」と作った人に聞いてみることです。予約の取り込みでも、請求書の発行でも、バックアップでも構いません。答えが「記録が残っているかどうかを見ています」なら、次にこう聞いてみてください。その記録は、誰がどこで実行しても必ず同じ場所に残りますか。ここが今回の分かれ目でした。
二つ目は、その記録が失敗したときにも残るのかを確かめることです。残る作りなら、判定は中身まで見ているかを確かめます。見ていなければ、失敗が済んだ印として読まれます。
三つ目は、二重にやってしまうと困る仕事について、最後に止めているものが何かを確かめることです。確認だけで止めているなら、確認が一度外れたときに素通りします。券が一度きりで無くなる、同じ番号で二度目が来たら受ける側が断る、在庫が一度しか引き当てられない。そういう性質で止まっているなら、確認が間違えても最後に踏みとどまれます。
二度目を止めたのは、確認ではなかった
受発注の現場には、同じ注文に一つの番号を振っておいて、受ける側が「その番号はもう受け付けました」と言って二度目を断る、という決まりの置き方があります。
ここで効いているのは、番号そのものではありません。同じ仕事に一つの番号が付いていて、受ける側がその番号で二度目を断る、という取り決めのほうです。番号を振っただけで、受ける側が何も見ていなければ、二度目はそのまま通ります。逆に、同じ注文に毎回違う番号を振ってしまえば、受ける側は二度目だと気づけません。番号は目印にすぎず、止めているのは断る側の決まりです。
今回うちで止まったのも、形としては同じでした。済んだかどうかを調べる確認は間違えました。止めたのは、まったく別の目的で置いてあった、使い切りの通行証です。券が一枚しか無かったので、二度目は入れませんでした。
確認をもう一枚重ねるより、種類の違う関門を一枚置くほうが効くことがあります。今回でいえば、同じ場所を見て同じように有無だけを判じる確認をもう一つ足したところで、印の置き場所が動くかぎり、二つとも同じように空振りしていたはずです。見るものが重なっていれば、数を増やしても、外れるときは一緒に外れます。実際に踏みとどまらせたのは、まったく別のものを見ていた通行証のほうでした。
これはHaruIroAIで起きた一件の話で、どの仕組みでも必ずこうなるという話ではありません。それでも、人と自動処理が同じ仕事を持っているなら、二度走ったときに何が止めてくれるのかを、一度確かめてみる価値はあると思います。
同じ仕組みで、逆向きのずれが起きた話は前日の記事に書きました。そちらは「成功しました」と報告したのに、渡すものができていなかった話です。「同じ依頼かどうか」の判定を仕組みのほうが間違えた話はこちらにあります。同じ仕事に一つの番号を振って二度目を断る、という同じ考え方が、そこにも出てきます。報告と現物のあいだの隙間は、向きを変えて何度でも出てきます。
この記事を書いた人
この記事の作り方
この記事は、構成・一次記録の照合・文章化にAIを使用し、HaruIroAIの編集ルールと社内の一次記録（実行ログ・公開処理が残した実行記録・現行のスクリプトと運用手順書）に基づいて作成しています。記事中の「事前確認をもう一度走らせた」確認は、読み取りのみの操作としてHaruIroAIで実施しました。社内で使っているツールの名称、保存場所、権限まわりの作りは、本題と無関係なため記載していません。内容は公開前に人が最終確認しています。