14回動いて14回とも未確認：判定の付かない自動公開

期待していたこと

記事の自動生成と公開を、人が張り付いていない時間帯にも動かす。動いたら、出来上がったものをその処理自身が読み戻して、要求どおりかどうかを判定する。合格したものはそのまま残し、落ちたものには印を付けて人の手元に戻す。これが設計時に置いた前提だった。

ここで自動運転と呼べる状態は、ジョブが最後まで走り切ったことではない。走り切った結果に、合格か不合格かのどちらかが付いていることである。判定が付かないまま積み上がる実行は、動いた形跡が増えているだけで、人が後から全部見に行かなければならない。見に行く人が必要なら、それは自動運転ではなく自動化にとどまる。

どう数えたか

測った期間は 2026-09-26 から 2026-10-09 までの14日。ジョブの実行状況を追記している JSON Lines 形式のログを対象にした。手順は次のとおり。

  1. ログを行単位で読み、対象の自動処理（記事の自動生成と公開）のレコードだけを抜く
  2. タイムスタンプで期間を 2026-09-26〜2026-10-09 に絞る
  3. 残ったレコードをステータス別に数える（合格／不合格／未確認）
  4. 未確認のレコードについては、その理由として記録されている文字列をそのまま拾う
  5. いちばん新しい未確認レコードの時刻を控える

集計は人の記憶ではなくログだけを入力にしている。同じログを同じ期間で絞れば、同じ数字が出る。

出てきた数字

見た期間 14日（2026-09-26〜2026-10-09）
この自動処理が動いた回数 14回
合格だった回数 0回
落ちた回数 0回
未確認だった回数 14回
未確認だった割合 100.0%
最後に未確認になった時刻 2026-10-08T22:21

動いた回数が14回で、そのうち合格が0回、落ちたのが0回、未確認が14回。割合にして100.0%。判定が付いたレコードが、この期間にひとつも無い。

ログに残っている未確認の理由は「読み戻した証拠が出ていません」。つまり、生成と公開のあとに結果を読み戻す処理が、判定の材料になる出力を残していない。材料が無いので判定が下せず、ステータスは未確認のまま置かれる。

何が問題だったか

いちばん危ないのは、この数字の読み違えである。落ちた回数は0回だが、これは「一度も失敗していない」という意味ではない。合格も0回だからだ。失敗が検出されていないのではなく、成否を検出する仕組みそのものが結果を出していない。

未確認を「とりあえず動いているから正常」と読み替えた瞬間、ログは安心材料に化ける。実際には、14回のうち何回が要求どおりの成果物だったのかを、こちらは一度も知らない。知らないものを正常と書かない、という一点だけは崩さないことにした。

もうひとつ、設計上の抜けがはっきりした。判定処理を「作った」ことと、判定処理が「証拠を残している」ことは別である。読み戻しのコードは実行パスに乗っているのに、その結果がログに落ちていない。ここを分けて考えていなかったため、ステータスが未確認で埋まっていることに気づくまで14日かかった。

未確認が意味すること

  • 成果物が要求どおりかどうかは不明（合格0回）
  • 成果物が壊れているかどうかも不明（不合格0回）
  • 不明のまま公開まで進んでいる
  • したがって、品質を担保しているのは人が後から目で見る行為だけ

直っていない

この記事を書いている時点で、まだ直っていない。読み戻し処理がなぜ証拠を出力しないのかを、ログレベルで特定できていない。出力先の指定が効いていないのか、読み戻しの分岐が実行前に抜けているのか、例外を握りつぶしているのか、どれかの切り分けがまだである。

直す順番は決めてある。

  1. 読み戻し処理の入口と出口にログを出し、そもそも呼ばれているかを確かめる
  2. 呼ばれているなら、判定結果を書き出す箇所まで到達しているかを追う
  3. 到達しているなら、書き出し先と書式を揃える
  4. そのうえで、合格／不合格のどちらかが必ず付く形にステータスを設計し直す

未確認というステータス自体を無くすつもりはない。判定処理が落ちたときに未確認が出るのは正しい。問題は、未確認が例外ではなく既定値になっていることだ。

いま、どこまで来ているか

生成から公開までの実行は、人が起動しなくても走っている。最後に未確認が記録されたのは 2026-10-08T22:21 で、人が見ていない時間帯にも動いている。ここは自動化として動いている部分である。

一方、出来上がったものが要求どおりかを判定する部分は、動いていない。実行は無人、判定は有人。この状態を自動運転とは呼べない。人の手が要る箇所が残っているので、残っていると書く。

人間の仕事は減ったか

起動と実行の手間は減った。判定の手間は減っていない。むしろ、未確認のレコードが14回分たまったぶん、後から人が中身を見に行く対象が増えている。

成果物の良し悪しを人が見ている限り、ジョブの実行回数が増えるほど人の確認量も増える。確認量が実行回数に比例する構造のままでは、回数を増やすこと自体がコストになる。だから次に手を入れるのは生成の品質ではなく、判定の出力である。

次に測ること

証拠出力を実装したあと、同じ手順でログを数え直す。測り方は今回と同じで、ジョブの実行状況ログを期間で絞り、ステータス別に数える。見るのは、未確認だった割合が100.0%から下がるかどうか、そして合格と不合格のどちらかが付いたレコードが出るかどうかの二点だけにする。

合格が付くことを目標にはしない。不合格が付くことも、同じだけ価値のある結果である。判定が下りるようになって初めて、生成の品質を議論する土俵に乗る。