自動運転の見張りが46回動いて40回落ちた。まだ直っていない

自動運転の見張りが46回中40回落ちている話

何を期待していたか

この処理は、自動運転そのものを見張る役目として置いたものです。人間が毎回ログを開いて確認しなくても、処理の終わりに「送る・閉じる・戻す」の三つが揃っているかを機械側で検証し、揃っていなければ落ちる。落ちなければ、その回は人間が見なくてよい。そういう設計です。

期待していたのは、落ちる回がだんだん減って、見張りが静かになっていくことでした。見張りが静かになってはじめて、人間が確認しない状態、つまり自動運転に近づいたと言えます。見張りが鳴り続けている間は、鳴るたびに人間がログを開くので、自動化はされていても自動運転ではありません。

実際に何が起きたか

測り方は単純です。実行ログ（ジョブの実行結果が一行ずつ積まれるファイル）を対象期間ぶん読み、この処理の実行行だけを抜き出して、合格と不合格を数えました。期間は14日、2026-10-22から2026-11-04までです。集計に使ったのは記録に残っている判定結果だけで、手元での再実行や推測は混ぜていません。

見た期間	14日（2026-10-22〜2026-11-04）
この自動処理が動いた回数	46回
落ちた回数	40回
合格した回数	6回
落ちた割合	87.0%
落ちた理由の種類	1件
期間内にはじめて落ちた時刻	2026-11-02T12:49
最後に落ちた時刻	2026-11-04T03:47

46回動いて40回落ちています。合格は6回。落ちた割合は87.0%です。見張りとしては鳴り続けている状態で、静かになる気配は期間の終わりまでありませんでした。

落ちた理由は一種類しかない

落ちた理由が何通りあったかを数えたところ、1件でした。つまり40回の不合格は、ばらばらの原因で散発的に落ちているのではなく、同じ一つの条件に毎回引っかかっています。

記録に残っている理由はこれです。

• 検証: FAIL 送る・閉じる・戻すのうち 1件が失敗（本人へ回して開いている 10件が、直して送った 1件より多い）

見張りは「本人へ回して開いたままになっている件数」と「直して送った件数」を比べています。前者が後者を上回っている限り、この検証は落ちます。ログに記録された時点の数字は、本人へ回して開いている 10件に対し、直して送った 1件。この差が埋まらないまま実行が繰り返されました。

何が問題だったか

問題は、見張りが壊れていたのではなく、見張りが正しく鳴っていたことです。検証条件そのものは意図どおりに動いています。落ちているのは、検証の向こう側にある実務の状態です。

差し戻された案件が溜まり、それを直して送り返す側が追いついていない。その状態が続く限り、見張りは毎回同じ理由で落ちます。落ちた理由が1件しかないという事実が、それを示しています。仕組みの不具合であれば、改修で落ちなくすることができます。実務の滞留であれば、仕組みをいくら触っても検証は合格に変わりません。

ここで「検証条件のほうを緩めて合格にする」という手もありますが、それをやると見張りの意味がなくなります。鳴らなくなっただけで、滞留は残るからです。緩めていません。

どう直したか — まだ直っていない

直っていません。

期間内にはじめて落ちたのが2026-11-02T12:49、最後に落ちたのが2026-11-04T03:47です。この間、同じ理由で落ち続けています。最後の記録の時点でも合格に変わっていません。

落ちた理由が1件しかない以上、やることは一つに絞れます。本人へ回して開いている件数が、直して送った件数を上回っている状態を解消すること。これを実施したうえで、同じ検証（送る・閉じる・戻す）が次の実行ログで合格に変わるかどうかを見ます。まだ実施して確認を終えた段階ではないので、この記事の時点では「対応の方向が決まっている」までです。

現在どこまで来ているか

現在地を、事実だけで並べます。

1. 見張りは動いている。14日で46回実行されている
2. 見張りは鳴っている。40回落ちている。落ちた割合は87.0%
3. 鳴っている理由は特定できている。種類は1件だけ
4. 合格した回は6回ある。条件が揃えば通ること自体は確認できている
5. 合格に変えるための対応は、まだ完了していない

合格が6回あるので、検証が常に落ちる作りになっているわけではありません。通る回も存在します。ただし46回のうち6回であって、これを「おおむね動いている」とは書けません。

人間の仕事は本当に減ったか

減っていません。

この見張りが落ちるたびに、人間がログを開いて理由を読み、差し戻しの溜まり具合を見に行く必要があります。14日で40回落ちているので、その回数ぶん人間の確認が発生しました。見張りを置く前と比べて、確認の中身は短くなっているかもしれません（どこが落ちたかは理由の行に書かれているため）。しかし確認そのものはなくなっていません。

さらに、落ちている原因が実務側の滞留であるため、ログを読んだあとに手を動かす先も人間側です。本人へ回して開いている 10件に対して、直して送ったのが 1件。この差を埋めるのは仕組みではなく人の作業です。

実行は自動で回っています。判定も自動で出ています。その意味で自動化はできています。ただし、鳴った後に人が開き、人が直す箇所が残っている以上、ここは自動運転ではありません。残っています。

この記録をどう使うか

この記事は、直った報告ではありません。46回中40回落ち、落ちた割合87.0%、理由は1件、最後に落ちたのが2026-11-04T03:47、という状態をそのまま置いたものです。

次に出す記事では、差し戻しと修正送付のギャップを解消する対応を実施したあとの実行ログを、同じ測り方で読み直します。期間と対象ファイルは変えません。合格回数と落ちた割合が動いたかどうかだけを見ます。動かなければ、動かなかったと書きます。