検索向けの題と説明文の自動調整13回が全て未確認のまま

期待していたのは「書き換えて、結果を見て、合否が残る」こと

検索結果に出る題と説明文を、記事ごとに自動で調整する処理を動かしている。期待していた動き方は単純で、対象を選び、題と説明文を書き換え、書き換えた後の表示を読み戻して、意図どおりになっているかを判定し、その結果をログに残す——ここまでが一区切りのはずだった。

自動運転と呼べる状態にするには、最後の判定が要る。書き換えが走ったという記録だけでは、何が起きたのか分からない。合格したのか、落ちたのか、それすら分からないものを「動いている」と呼ぶわけにはいかない。

測り方はこうしている。処理の実行結果を一行ずつ追記しているログ（job-status.jsonl）から、この自動調整の処理に該当する行だけを抜き出し、期間で絞って状態ごとに数える。見た期間は14日、2026-10-07から2026-10-20まで。

合格が0回、落ちたのも0回。にもかかわらず13回動いている。つまり13回すべてが、合格とも不合格とも言えない「未確認」のまま置かれている。未確認だった割合は100.0%。最後に未確認が記録された時刻は2026-10-19T09:25で、そこから状態は変わっていない。

ログに残っていた、確かめられない理由はひとつだけだった。読み戻した証拠が出ていません。書き換えの後に表示結果を読み戻す処理の出力が、ログのどこにも現れていない。だから判定のしようがなく、未確認として積み上がっている。

問題の形をはっきりさせておく。13回という数字は、処理が起動して何らかの書き換え動作まで到達したことを示している。ここは止まっていない。止まっているのは、その先の読み戻し（変更後の表示結果を確認する処理）だ。

この状態で起きることは、次のふたつに整理できる。

成果が測れない。題と説明文を変えたことで表示がどうなったのかを、合格・不合格の形で積み上げられない。効いているのか効いていないのかが、13回分まるごと空白になる。
壊れていても気づけない。書き換えの内容が意図とずれていたとしても、落ちた回数は0回のまま出てくる。0回という数字は「問題がなかった」ではなく「判定していない」の表示でしかない。

ここを取り違えると、未確認100.0%を「エラーゼロで安定稼働」と読んでしまう。落ちた回数が0回であることと、正しく動いていることは、まったく別の話だ。今の時点で、この処理が正常に動いているかどうかは分からない。分からないものを正常とは書かない。

この記事を書いている時点で、読み戻しが出力されない原因は特定していない。実装が入っていないのか、入っているが結果をログに書き出していないのか、書き出しているが抽出条件から漏れているのか——そのどれなのかを切り分けていない。

したがって、この処理は直っていない。修正も入れていない。13回ぶんの未確認はそのまま残っている。

やる順番は決めている。

順番を飛ばして測り直しても意味がない。判定できない仕組みのまま回数だけ測れば、未確認がもう一度積み上がるだけになる。

この処理について言えるのは、起動と書き換えまでは人の操作なしに走っているということだけだ。14日のあいだに13回、人が実行ボタンを押さずに動いている。そこは自動化できている。

一方で、その結果が正しいかどうかを確かめる経路が存在していない。確かめられないものは、人が見に行くしかない。結果の良し悪しを判断する役割が人間側に残っている以上、これは自動運転ではない。「人間が確認しなくても回る」状態の、確認にあたる部分がまるごと欠けている。

書き換えを手で打ち込む作業はなくなった。そのぶんは減っている。ただし減ったのと同時に、「13回ぶんの結果を誰も見ていない」という未処理が発生している。今後この13回を遡って確認するなら、それは新しく生まれた人間の仕事だ。

手を動かす時間が減ったことと、見届ける責任が減ったことは別で、後者はまだ減っていない。むしろ、合否が残らない形で回数だけ増える仕組みは、確認の負担を後ろへ積み送りする。14日で13回という頻度は、放っておけばそのぶん積み上がり続ける。

読み戻しの仕組みを確認し、欠けていれば実装・修正する。そのうえで、今回と同じ測り方——job-status.jsonlからこの処理の行を抜き出し、期間で絞って状態ごとに数える——で測り直す。

見るのは回数ではなく、合格と不合格が数字として出てくるかどうかだ。未確認だった割合が100.0%から動かないなら、原因の切り分けが間違っていたことになる。そのときは、原因の特定からやり直す。