先に結論をお伝えします。時刻を決めておくことは、その時刻に動けることを意味しません。うちの処理は、五日間はほぼ定刻に起動していました。ところが八月二日は十四分遅れて起動し、しかも起動したときに仕事ができる状態かどうかは、誰も確かめていませんでした。
先にお伝えしておくと、これは社内の記事づくりを自動化した仕組みの内側で起きたことで、お客様の案件ではありません。公開済みのものが壊れたわけでも、誤ったものが外に出たわけでもない。起きたのは「その日の記事が一本、出せなかった」ことだけです。
どんな仕組みか
うちでは、ブログ記事を出す作業を三段に分けて自動で回しています。夕方に仕組みが翌日分の記事一式を用意する。夜に人が中身を確認して承認する。翌朝に仕組みが公開まで進める。
真ん中が人であることは、意図してそうしています。今日お話しするのは、その一段目——夕方に動くはずだった処理です。
お手元でいうと、毎晩決まった時刻に走るバックアップ、朝に自動で送られる予約投稿、夜間に取り込まれる売上データ。ああいう「時刻を決めて任せてあるもの」と、同じ形だと思ってください。
五日間は、時計どおりに動いていました
この処理は毎日16時03分に動く設定にしてあります。記録を見ると、七月二十八日から八月一日までの五日間、起動時刻は16時03分00秒、02秒、01秒、05秒、00秒。毎日ほぼ秒単位で時計どおりでした。
だから私たちは、この処理を「動いているもの」として扱っていました。実際に動いていたのですから、そう思うのが自然です。
その日だけ、十四分遅れました
八月二日の記録だけ、起動時刻が16時17分02秒でした。十四分の遅れです。そしてこの日、この処理のログはこの一本しかありません。
十四分という数字だけを見ると、少し出遅れただけに見えます。問題は、その十四分後がどんな瞬間だったかでした。
十四分後、パソコンは二秒だけ目を覚ましていました
パソコンの電源まわりの記録を見に行くと、同じ日の16時17分02秒に、短い自動起床が記録されていました。人が触って起こしたのではなく、パソコンが自分の用事のために少しだけ目を覚ます種類のものです。記録に残っている継続時間は二秒。そして二秒後の16時17分04秒に、また眠りに戻っています。
処理が起動した時刻は、この自動起床とまったく同じ秒でした。
念のため書いておくと、記録から言えるのはここまでです。「二秒の起床のせいで処理が失敗した」と因果まで断定できる記録は残っていません。言えるのは、同じ秒に両方が記録されていた、という一致だけです。ただ、次に何が起きたかを見ると、この一致は無視しにくいものでした。
処理は、三行だけ残して終わっていました
その日のログは全部で三行しかありませんでした。開始した、という一行。次に、インターネットの向こうにある保管先——記事の元データを置いてある場所です——へつなぎに行った処理が失敗した、という一行。最後に、失敗したので終わる、という一行です。
失敗の内容は、相手先の名前を住所に変換する段階でつまずいた、というものでした。インターネットの向こうにある相手を名前で呼び出そうとして、その名前が誰なのかを調べられなかった、という状態です。電話でいえば、番号案内につながらなかったのに近い。
そして当時のこの処理は、その一手を一回だけ試して、失敗したらそこで終わる作りでした。少し待ってもう一度、という発想が入っていなかったのです。
もう一つ、あとから気づいたことがあります。作業のあいだはパソコンを眠らせない、という設定を途中から入れてありました。ただしその設定が効き始めるのは後半の重い作業からで、いちばん最初のこの一手はまだ守られていませんでした。眠らせない措置が、眠りかけている場所より後ろに置かれていたことになります。
前の日には、同じ形が逆向きに出ていました
ここからが、私たちにとっていちばん効いた発見でした。
その前日、八月一日の夜にも、同じ形が起きています。夜に走る見張り役の処理が、定刻の20時10分ではなく20時25分37秒に起動していました。そして外へ問い合わせに行った結果を受け取れず、それを「記事が一件も無い」と読んで、警報を出しました。実際にはその時点で記事はちゃんと存在していました。誤った警報です。
この20時25分37秒も、電源まわりの記録では二秒間の自動起床と同じ秒でした。
八月一日は、問い合わせに失敗した結果を「記事が一件も無い」と読んで、誤った警報を出しました。八月二日は、記事の元データとの同期に失敗し、処理がそこで終わりました。結果は違いますが、どちらも短い自動起床と同じ秒に起動しています。自動起床との因果は、どちらも確かめられていません。
八月一日のほうについてだけは、はっきり言えることがあります。問い合わせできなかったことと、問い合わせた結果が空だったことを、区別していなかったのです。聞けなかったのに、「無い」と答えてしまった。
誰も間違えていないのに、記事だけが出なかった
この日の失敗は、その晩のうちに検知されています。夜の見張り役が「制作のログはあるが、正常に終わっていない」「用意されたはずの記事一式が無い」と判定して、警報を出しました。前日は誤って鳴った同じ見張りが、この日は正しく鳴ったことになります。
翌朝の公開処理も、安全側に止まりました。公開できるものが無いので、前日に公開済みのものを見つけて「これは既に出した」と判断し、何もせずに終わっています。二重に出さないための判定が、設計どおり働いた形です。
つまり仕組みは、どの段階でも間違ったことをしていません。今回の仕組みでは、それぞれが決められた判定どおりに動いても、その日の記事は用意されませんでした。誰も間違えていないのに、結果だけが欠けている。そういう形があり得るのだと、今回知りました。
直したことと、まだ言えないこと
三つ入れました。最初の一手を最大六回、三分ほどかけて試し直すようにしたこと。眠らせない設定を、処理の開始時点から掛けるようにしたこと。そして朝の公開処理でも、問い合わせに失敗したときは「対象が無い」ではなく「判定できなかった」として止まるようにしたことです。
ただし三つとも、同じ状況をこちらから作れないので、実地ではまだ確かめられていません。書いたものが構文として壊れていないこと、手元の自己点検が全項目通ることまでは確認しましたが、それは「書いたとおりに動く」の証明ではありません。とくに二つ目——二秒しか目を覚まさない状態のときに、眠らせない設定が本当に効くのか——は、仕組みの外側の事情なので、こちらの書き方だけでは決められない部分が残ります。前に「書いてあるだけの知らせは、まだ知らせではない」と書きましたが、今回の対処も同じで、いまはまだ「書いてあるだけ」です。
手元でできる三つのこと
一つ目は、時刻を決めて任せているものについて、その時刻にパソコンが起きているかを確かめることです。夜間のバックアップを22時に設定していて、21時には毎日ノートを閉じている。その組み合わせで本当に動く設計になっているのかを、作った人や保守の担当者に確認してみてください。据え置きのパソコンなのか、閉じてしまうノートなのか、その時刻に電源が入っているのか。ここは設定画面ではなく、ご自身の生活のほうを見ないと分かりません。
二つ目は、失敗したときに一度で諦める作りかを、作った人に聞くことです。「つながらなかったときは、少し待ってもう一度試しますか」。この一言で足ります。今回のうちの処理は、一度の名前解決の失敗で、その日の処理を終えていました。
三つ目は、動かなかった日に気づく手段を、その仕組みの外に一つ持つことです。これは前にも書きましたが、今回それが実際に効きました。今回この異常を拾ったのは、制作の処理の外側に置いた見張り役でした。中で何が起きたかを見ずに、結果だけを見る層です。
目覚ましは鳴らせても、起きられるかは別
目覚まし時計は、決めた時刻に鳴らすところまでは確実にやってくれます。でも、その時刻に自分が起きられるかどうかは、時計の仕事ではありません。寝入りばなだったのか、前の晩に遅かったのか、そこは時計の外側の話です。
自動化の「毎日16時03分」も同じでした。定刻に呼ぶ設定があることと、実際に何時に起動したかと、起動したときに仕事ができる条件が揃っているかは、それぞれ別のことです。うちはそれを、一つのことだと思って扱っていました。別々に確かめるものだったのだと思います。
これはHaruIroAIで起きた一件の話で、どの仕組みでも必ずこうなるという話ではありません。それでも、いま何かを決まった時刻に任せているなら、その時刻にご自身のパソコンが起きているかだけでも、一度確かめてみる価値はあると思います。
同じ仕組みで「動かなかった日は誰も見ていない」という話はこちらに、人と自動処理が同じ仕事を持ったときの取り違えはこちらに書きました。
決まった時刻に任せる仕組みづくりのご相談は、AI・自動化のご支援でも承っています。
この記事を書いた人
この記事の作り方
この記事は、構成・一次記録の照合・文章化にAIを使用し、HaruIroAIの編集ルールと社内の一次記録（日次自動運用スクリプトの現行コード、その実行ログ、バージョン管理の履歴、パソコンの電源管理ログ、起動設定）に基づいて作成しています。記事中の状態は2026年8月3日時点で確認したものです。社内で使っているツールの名称、保存場所、作業の識別番号は、本題と無関係なため記載していません。内容は公開前に人が最終確認しています。