130回のうち40回が未確認のまま置かれている理由

期待していたのは「動いた／動かなかった」がログだけで分かる状態だった

自社サイトの記事生成と公開を、人が見ていない時間帯にも回している。この処理には実行のたびに結果を書き出す仕組みを付けてあり、状態は logs/job-status.jsonl に一行ずつ追記される。期待していたのは単純で、朝このファイルを開けば、昨夜の実行が通ったのか落ちたのかが、人の判断を挟まずに分かる状態だった。

自動運転を名乗るには、実行が自動であるだけでは足りない。結果の判定まで自動でなければ、結局のところ毎朝人間が「これはどっちなんだ」と中身を見に行くことになる。そこを機械側に寄せたくて、成否を記録する仕組みを先に入れた。

測り方

  • 対象：記事の自動生成と公開を行う処理
  • データ：logs/job-status.jsonl に追記された実行レコード
  • 期間：14日（2026-09-10〜2026-09-23）
  • 集計：期間内の実行回数と、その内訳（合格／不合格／未確認）を状態フィールドで数える

実際に出た内訳は、0合格・90不合格・40未確認だった

14日（2026-09-10〜2026-09-23）のあいだに、この処理は130回動いていた。内訳は次のとおり。

期間 14日（2026-09-10〜2026-09-23）
実行回数 130回
合格 0回
不合格 90回
未確認 40回
未確認の割合 30.8%
最後に未確認になった時刻 2026-09-22T19:05

合格が0回である以上、この処理はまだ目的を果たしていない。それは分かる。問題はその隣にある40回のほうで、これは落ちたわけでもなく、通ったわけでもない。ログにはただ「未確認」と残っている。

この記事の主役はこの40回のほうだ。落ちた90回は、落ちたという事実がログに残っているぶん、次に何を直せばいいかの手がかりがある。未確認の40回には、それがない。

未確認になる理由は「読み戻した証拠が出ていない」ことだった

ログに残っている、確かめられない理由はひとつだけだった。読み戻した証拠が出ていません、である。

記事を生成して公開したあと、本当に公開先に反映されたかを確かめるには、書いた側の記録だけでは足りない。公開後にもう一度読みに行って、意図した内容がそこにあることを確認し、その確認結果を記録として残す必要がある。この「読み戻して残す」部分の出力がない実行が、未確認として積み上がっている。

つまり未確認の40回は、「公開に失敗した回」ではない。「公開できたかどうかを判定する材料が揃っていない回」である。この区別は重要で、前者なら再実行すればいいが、後者は再実行しても同じく未確認が増えるだけになる。

ここで書けないこと

未確認の40回について、実際には公開まで届いていた可能性はある。だが届いていた証拠がないので、届いていたとは書かない。確かめていないものを正常とは書かない。これは判定を甘くすると自動運転そのものが意味を失うからで、ログ上「未確認」と出たものは、記事の中でも未確認として扱う。

翌日に測り直したら、未確認は減っていなかった

集計の窓を一日ずらして、14日（2026-09-11〜2026-09-24）で同じ指標を取り直した。

期間 14日（2026-09-11〜2026-09-24）
不合格 83回
未確認 47回
未確認の割合 36.2%
最後に未確認になった時刻 2026-09-23T19:05

未確認は40回から47回へ、割合は30.8%から36.2%へ動いた。窓をずらしただけなので、この差は期間の端が入れ替わったぶんを含んでいる。それでも読み取れるのは、未確認が過去の一時的な事故ではなく、いまも発生し続けているということだ。最後に未確認になった時刻も 2026-09-22T19:05 から 2026-09-23T19:05 へ移っている。どちらも19:05で、夜間の同じ実行枠で起きている。

まだ直していない

読み戻した証拠が出ない原因は、まだ特定できていない。検証ロジックの実装漏れなのか、公開先を読みに行く権限の問題なのか、公開直後に読みに行って反映前の状態を掴んでいるタイミングの問題なのか、いまの時点では切り分けられていない。原因が分からないまま「たぶんこれだろう」で手を入れると、直ったかどうかも同じく未確認になる。

やる順番は決めてある。

  1. 検証ロジックのコードを読み、読み戻しの結果を記録に書き出す経路が実装されているかを確かめる
  2. 実行環境で、公開先を読みに行けるだけの権限があるかを確かめる
  3. 公開から読み戻しまでの間隔と、19:05という実行枠の条件を確かめる
  4. 原因を特定して修正したうえで、同じ期間の長さ・同じ指標でログを取り直す

修正したと言えるのは、この最後まで終わって数字が動いたときだけだ。現時点では、40回も47回も未確認のまま置かれている。

人間の仕事は減っていない

この処理は、記事の生成と公開という実行部分については人の手を離れている。14日で130回動いたのは、人が起動をかけたからではない。その意味では自動化されている。

だが自動運転ではない。合格が0回で、不合格が90回ある時点で成果物は出ていないし、それ以上に、40回ぶんの「どっちか分からない実行」が残っている限り、誰かが中身を見に行かないと状態が確定しない。人間が確認しなくても回る状態、という定義からは外れている。

むしろ未確認が増えると人間の負担は増える。落ちた記録なら原因のログを追えばいいが、未確認は何が起きたのかを公開先まで見に行って手で確かめることになる。30.8%が36.2%へ動いたというのは、手で確かめる対象が減っていないという意味でもある。

判定できないログは、ログとして機能していない

この件から取り出せるのは、自動運転の成否を「実行できたか」で測るとこうなる、ということだ。実行は130回できている。それでも、結果を機械が判定できる形で残していなければ、実行回数はただの回数でしかない。

結果の記録には、書いた側の記録と、読み戻した側の記録の両方が要る。片方しかないと、状態は「合格」でも「不合格」でもなく「未確認」に落ちる。いま自社のログに40回ぶん積まれているのが、その状態そのものである。

次に書くのは、読み戻した証拠が出ない原因を特定して修正し、同じ指標で取り直した数字になる。未確認が残っているうちは、この処理について「動いています」とは書かない。