14回動いて14回とも未確認、合格も不合格も出ていない
期待していたのは「書いて、出して、読み戻して判定が残る」まで
記事の生成から公開までを、人の操作をはさまずに回す処理を動かしている。期待していた動きは、生成する・公開する、で終わりではない。公開したあとに出来上がりをもう一度読み戻し、狙った形で出ているかを判定し、その判定を実行記録に書き込むところまでを含めて一回の実行とする、という組み方だった。
読み戻しまで入って、はじめて人が見なくても回っている状態になる。生成と公開だけなら、出来上がりが崩れていても誰も気づかないまま次の実行に進んでしまう。最後の読み戻しは、おまけではなく本体のほうだった。
実測：14日間で14回動き、14回とも未確認
測り方を先に書く。ジョブの状態を実行ごとに一行ずつ追記しているログファイルを、2026-09-27から2026-10-10までの14日分、そのまま読んだ。集計といっても難しいことはしていない。この自動処理の行だけを抜き出し、各行に入っている判定の値が「合格」か「落ちた」か「未確認」かを数えただけ。推測で埋めた行はない。
| 見た期間 | 14日（2026-09-27〜2026-10-10） |
| この自動処理が動いた回数 | 14回 |
| 未確認だった回数 | 14回 |
| 合格だった回数 | 0回 |
| 落ちた回数 | 0回 |
| 未確認だった割合 | 100.0% |
| 最後に未確認になった時刻 | 2026-10-09T23:05 |
合格が0回で、落ちたのも0回。実行そのものは14回とも最後まで進んでいる。それでも判定だけが存在しない。この14回は、通ったのでも落ちたのでもなく、通ったかどうかが分からない状態のまま置かれている。最後に未確認になったのは2026-10-09T23:05。
記録に残っていた理由はひとつだけ
未確認になった理由としてログに書かれていたのは、読み戻した証拠が出ていません、という一点。読み戻しの結果が良かったとも悪かったとも書かれておらず、読み戻した形跡そのものが記録に出てこない。
問題は「落ちていない」を「通っている」と読めてしまうこと
落ちた回数が0回という数字は、パッと見ると悪くない数字に見える。エラーで赤くなった実行がないので、通知も飛ばないし、気づく機会もない。だが同じログに、合格も0回と書いてある。
ここを混ぜると、運用の判断がまるごと狂う。
- 落ちていないは、不具合が検出されていないという意味でしかない
- 通っているは、出来上がりを読み戻して問題がなかったという意味になる
- いまのログで言えるのは前者だけで、後者を言える材料はどこにもない
未確認の割合は100.0%。14回のうち一度も、出来上がりを確かめた記録が残っていない。この状態を「問題なく回っています」と書いてしまうと、以後の記事も運用判断も、確かめていない前提の上に積み上がる。だから、未確認は未確認のまま書く。正常とは書かない。
まだ直っていない。原因の切り分けも終わっていない
読み戻しの証拠がログに出ない理由として、いまの時点で考えられる筋は分かれている。どれが当たりかは、まだ特定していない。
- 読み戻しの処理が、そもそも実装されていない
- 実装はされているが、実行経路に入っていない（呼ばれていない）
- 実行はされているが、結果をログに書き出していない
- 実行も書き出しもしているが、判定を書き込む前に処理が終わっている
この四つは、どれも「落ちた回数が0回」という同じ見え方になる。見え方が同じである以上、ログを眺めているだけでは区別がつかない。コード側で読み戻し処理の有無と呼び出し位置を確認し、呼ばれているなら出力先を確認する、という順で潰すしかない。
現時点では、そのどれも終わっていない。だからこの記事は、直した報告ではなく、直っていないことの記録になる。
いまどこまで来ているか：自動化ではあるが、自動運転ではない
生成と公開は、人が押さなくても最後まで進んでいる。14日間で14回、止まらずに動いた。その意味では自動化はできている。
ただ、出来上がりが狙った形になっているかどうかは、機械の側では誰も見ていない。見ていないので判定が出ず、判定が出ないので未確認が100.0%になる。結果を確かめる役目は、いまも人に残っている。人が確かめなければ正しさが分からない工程が残っている以上、これは自動運転ではない。
区別して言うなら、こうなる。
- 自動化できた部分：生成から公開までの実行（14回とも完走）
- 自動運転になっていない部分：公開後の読み戻しと判定（未確認14回）
人間の仕事は減ったか
実行を起動する手間は減った。一方で、出来上がりを目で見て確かめる作業は残ったままで、しかも機械の側に判定が残らないので、どの回を見てどの回を見ていないかも人の記憶に依存している。14回のうちどれが確かめ済みかを、ログからは引けない。
見方によっては、確かめる負担はむしろ分かりにくくなっている。赤いエラーが出ないので、確かめ忘れても誰も教えてくれない。未確認が静かに積み上がる形になっている。
次に確かめること
調べる順番は決めてある。
- 読み戻し処理が実装されているかを、コード上で確認する
- 実装されている場合、実行経路から呼ばれているかを確認する
- 呼ばれている場合、判定の書き出し先とログ出力の有無を確認する
そのうえで、次に同じ自動処理が動いたとき、判定が未確認以外で記録に残るかを見る。残らなければ、原因の切り分けが足りていないということになる。合格ラインは記事末尾に書いた条件のとおりで、落ちた回数が0回のままであることを合格の根拠には使わない。