🔍 26時間、昨日の数字で判断していた——自動計測が止まっても気づけない、ひとり運営の盲点

止まった時計は、1日に2回だけ正しい時刻を示します。

それ以外の時間は、ずっと間違ったまま静止しています。

壁にかかっていると、ぱっと見ただけでは止まっているとわかりません。

「まだ14時か」と思いながら、22時間以上ずっと間違った時刻で動いてしまいます。

データの計測でも、まったく同じことが起きていました。Lilyの話を、今日はしようと思います。

あなたは今、こうなっていませんか？

• 自動でデータを集めるツールを使っているが、「今日も動いたか」を確認したのは最初の1回だけ • エラーのメールや通知が来ていないから、正常に動いていると思っている • 「最近この記事が伸びていないな」という判断が、実は数日前の古いデータに基づいている • 自動化した仕組みが止まっても、誰も教えてくれない状況になっている

先に結論を言います。エラーが出なくても、データは静かに止まります。そして誰も、気づかせてくれません。

この記事では、Lilyが26時間以上データが更新されていなかったことに気づかず、古い数字で記事のパフォーマンスを判断し続けていた実話と、どう直したかを書きます。

26時間、数字が止まっていた話

その日、何がおかしかったか

ある朝、いつものようにnoteのデータをチェックしていました。

「最近この記事への反応が落ちているかも」と感じながら、過去7日分の数字を眺めていたんです。

前の週と比べて伸びていない気がして、記事の方向性を変えるべきか、少し悩んでいました。

でも実は、その時点からさかのぼって26時間以上、データが止まっていたんです。

「伸び悩んでいる」という判断そのものが、昨日のスナップショットに基づいたものでした。

何かを判断しているつもりで、判断の土台が揺れていたことになります。

何も動いていなかったのに、見た目は「普通」だった

データ収集のツールは、毎日自動で動くように設定しています。

問題は、動いた形跡はあるのに、中身が更新されていなかったことでした。

画面には昨日のデータがそのまま表示されていて、エラーのメッセージも何もありません。

「これ、止まってるな」と気づいたのは、別の作業中にたまたまログを見たときです。

ログには status: waiting とだけ書かれていました。

「待機中」という状態で、ジョブ自体は生きているんですよね。

これがいちばん厄介です。

止まっているのではなく、ただずっと「並んで待っている」状態なので、エラー扱いにはなりません。

その場で背筋がすっとしました。

「じゃあ今朝の判断は、1日前のデータに基づいていたのか」と思って。

📕 AIエージェントと自動化の全工程をまとめた総集編 手順・コード・テンプレをそのまま渡しています 🤖【完全版】月商160万円の「寝てても回る仕組み」をゼロから30日で組む全工程｜2026年10月版・Claude Code×AIエージェント・特典40ファイル・毎月更新

原因は「ブラウザ待ち」の行列だった

データ収集にブラウザは要らなかった

Lilyが使っているデータ収集は、noteの情報をAPIというルート（公式の出入り口）から直接取ってきます。

ブラウザで画面を開く必要は、本来まったくありません。

ところが仕組みを組んだときに、ブラウザを使う別の作業と同じキューに入れてしまっていました。

Playwright（ブラウザ自動化ツール）を使う別の処理のキューに、APIアクセスだけで完結する処理が混在していた、ということです。

ブラウザを使わない作業なのに、ブラウザが空くのを待っている状態になっていたんです！

行列の前が詰まると、後ろも全部止まる

Playwrightのブラウザインスタンスは、同時に立ち上げられる数に上限があります。

設定ファイルの concurrency の値が小さく、実質1本しか並列で動かせない状態でした。

ブラウザを使う別の処理が何かの拍子に時間をかけると、後ろに並んでいたものも動けなくなります。

これ、エラーではないんですよね。

「失敗した」わけじゃなくて「まだ待っている」という状態なので、アラートが出ません。

スーパーのレジに例えるなら、前の人の会計がずっと終わらないまま、後ろの人が何時間も並び続けている状態です。

誰も怒っていないし、店員さんもエラーを出していない。でもレジは全然進んでいません。

キューに「タイムアウトなし」という盲点があった

もっと言うと、そのキューには timeout の設定がありませんでした。

「何分待っても応答がなければ諦める」という動作をしないんです。

前のジョブが終わるまで、理論上は何時間でも待ち続けます。

これが26時間という時間につながった直接の原因でした。

timeout を設定しておけば、一定時間後にエラーとしてログに記録されます。

エラーが記録されれば、通知を設定してある場合はSlackやメールに飛ばせます。

timeout: 300（5分）のように設定しておくだけで、気づくタイミングが「26時間後」ではなく「5分後」になります。

「タイムアウトなし」のまま動かし続けることは、詰まったときに誰も気づかない仕組みを作っているのと同じです。

なぜ26時間も気づけなかったのか

「最近は正常だった」という思い込み

データ収集の仕組みは、設定してから毎日動いていました。

1週間も2週間も問題なく動いていたので、「今日も動いているはず」という前提が固まっていたんです。

昨日動いた。一昨日も動いた。だから今日も動いている。

この推論、論理的に見えるんですが、これが盲点になりました。

継続的に動いていた実績があるほど、「今日も大丈夫」という感覚は強くなります。

でも実績は過去のことで、今日の動作を保証するものではありません。

確認コストがゼロに近いのに、「大丈夫だろう」という思い込みで確認を省いていたんです。

データが「それっぽく見える」のが一番こわい

止まっていても、画面に表示されているのは直近のデータです。

昨日の数字がそのまま今日の数字として見えていて、違和感がありません。

「今週は伸び悩んでいるな」「この記事は反応が薄いな」という判断を、26時間分古いデータで行っていました。

正確なデータを集めているつもりで、実は昨日のスナップショットを見ていたんです。

これを知ったとき、しんどかったです、、、

何かを判断している気分でいたのに、判断の土台が揺れていたことになるので。

「伸び悩んでいる」という判断も、実際には確認できない

もっと困ったのは、26時間止まっていた間の判断が「正しかったのかどうか」を確かめる方法がない点です。

古いデータを見て「この記事は今週反応が薄い」と判断した内容は、そのまま次の行動に影響します。

「もう少し別のテーマで書いてみようか」という思考が、古いデータを土台にして進んでいました。

気づいて直したから良かったものの、1週間気づかなかったとしたら、判断のずれがもっと大きくなっていたと思います。

データが古かった期間のログは残っていますが、その間に何が起きていたかは「本当は分からない」ままです。

「あのときの判断は正しかったのか」という問いに、答えを出す方法がないんです。

ひとり運営に「監視者」はいない

チームがあった頃は、誰かが止まったことに気づいた

Lilyは以前、月3,000万円規模の広告運用をチームでやっていました。

そのときは、計測ツールが止まれば誰かが気づきました。

「今日のレポートが来ていないけど、どうした？」とSlackで声がかかります。

「昨日から数字が動いていないね、何かあった？」と誰かが指摘してくれます。

チームで動いていると、データを見る人間が複数いるので、1人が気づかなくても誰かが気づきます。

チーム自体が、計測インフラの「監視機能」を担っていたんです。

ひとりだと、気づいてくれる人がいない

ひとり運営では、その仕組みが丸ごとありません。

止まっても、怒ってくれる人も、指摘してくれる人も、いないんです。

自動化した仕組みが静かに詰まっていて、誰も何も言わない。

画面には昨日のデータが表示されていて、見た目は正常に見える。

これが、ひとり運営の構造的な盲点だと思います。

自動化の密度を上げるほど、「止まっても気づかない」リスクが上がっていくんです。

「誰も確認しない」は組織ではありえない状態

組織でマーケをやっていた頃、計測インフラの担保はチームが分業でやっていました。

データエンジニアが集めて、マーケがチェックして、マネージャーがレポートを承認する。

どこかで止まれば、誰かがおかしいと感じます。

このフローが、意図せず「監視」の役割を果たしていたんです。

ひとりで回すと、その流れが全部1人に集まります。

設定するのも自分、使うのも自分、確認するのも自分。

どこかが抜けても、誰も補完してくれません。

自動化によって「全部自分でできる」ようになるのは良いことです。

でも同時に、「全部自分で確認しなければならない」という責任も生まれるんですよね。

どう直したか

ブラウザ待ちの行列から切り離して動かす

対処は比較的シンプルでした。

データ収集の処理を、Playwrightのキューから外して、独立したスクリプトとして動かすようにしました。

APIにアクセスするだけの処理には、ブラウザのセッションが不要です。

requests や httpx といったHTTPクライアントのライブラリを使えば、ブラウザの状態にまったく左右されません。

設定ファイルから browser_context: playwright の指定を消して、APIクライアントのみで動く構成に変えました。

修正後すぐに確認すると、当日分のデータが正しく更新されていました！

「作業の種類」で動かす仕組みを分ける

今回の失敗を一言で言うと、「ブラウザが必要な作業」と「必要ない作業」を同じキューに混ぜていたことです。

片方が詰まれば全部が止まる、という構造になっていました。

料理で言えば、電子レンジを使う料理と、鍋を使う料理を、同じ「電子レンジが空いてから」というルールで順番待ちさせていたようなものです（笑）

鍋は鍋で独立して動かせるのに、わざわざ電子レンジを待たせていました。

作業の種類によって、動かす仕組みを分けておく。

これ、動いている間はなかなか気づかないことです。

うまく動いているからこそ、構造の問題に気づきにくいんですよね。

直した後の確認の仕方

修正後、最初にやったのは「今日のデータが今日の日付で入っているか」の確認です。

具体的には、データストアの updated_at フィールドと、スクリプトの実行ログの completed_at を照合しました。

両方が当日のタイムスタンプになっていれば、正常に収集されたということです。

このとき、ログファイルに status: completed と出力されていることも合わせて確認しました。

status: waiting のまま終わっていたら、また同じ問題が再現しています。

この確認作業そのものは1分もかかりません。

でもこれをやっていなかったから、26時間分の盲点が生まれました。

計測を「信頼できる状態」に保つための習慣

「最終更新日時」を必ず表示する

Lilyが最初に追加したのは、データに「最後に更新された時刻」を表示することです。

「このデータは本日12:35時点のものです」という表示を、ダッシュボードの上部に追加しました。

更新日時が昨日のままなら、「あ、止まっているかも」とすぐ気づけます。

たったこれだけで、見落としのリスクが大きく下がります。

数字が気になって確認を開いたとき、最初に目に入るのがこの更新時刻です。

「今日のデータ」として見ていたものが、実は12時間前のものだった、ということを防げます。

実装としては、データを書き込むスクリプトの最後で last_fetched_at を更新し、表示側でその値を読むだけです。

データベースでも、JSONファイルでも、仕組みは変わりません。

週に1回、「本当に動いているか」を確認する

自動化は設定したら終わり、ではないと今回で実感しました。

少なくとも週に1回、「今週分のデータが正しく入っているか」を確認する習慣を作りました。

確認の内容は3点です。

1つ目は、updated_at が今日や昨日の日付になっているか。

2つ目は、実行ログに status: completed が残っているか。

3つ目は、数字に極端な断絶がないか（前日比ゼロや、突然2倍になっていないか）。

この3点を確認するのに、慣れれば5分かかりません。

1週間に1度、5分かけて確認するだけで、168時間分の盲点を防げます。

自動化の恩恵を受けながら、手動確認のタイミングを定期的に入れておく。

手間に見えますが、これがないと「自動化を信じすぎて気づかない」という状況を繰り返します。

自動化が増えるほど、「止まったときの設計」が大事になる

エラーが出ない失敗が、一番こわい

エラーが出る失敗は、すぐわかります。

赤い文字や警告が出れば、「何かおかしい」とすぐ気づけます。

でも今回のように、エラーが出ないまま止まっている失敗は、気づくのが難しいです。

静かに、見た目は正常なまま、データだけが古くなっていきます。

自動化した仕組みが増えるほど、この「静かな失敗」が起きる可能性も増えます。

1つの仕組みを作るたびに、「これが止まったとき、どう気づくか」を同時に設計しておく必要があります。

status: waiting と status: failed は、どちらも「正常に完了していない」という意味では同じです。

でも status: failed はアラートが出て、status: waiting は何も通知しない。

この非対称を意識しておくだけで、見落としのリスクが大きく変わります。

「動いているはず」を疑うタイミングを意識的に作る

毎日同じ時間に動いていると、「今日も動いているはず」という前提が強くなります。

これ自体は悪いことじゃないんですが、「疑うタイミング」を意識的に作っておかないと、今回みたいなことが起きます。

Lilyが今やっているのは、週1回の確認に加えて、数字が「いつもと違うな」と感じたときに「データが止まっていないか」を最初に疑うことです。

「パフォーマンスが落ちた」より先に「計測が止まっていないか」を確かめる、という順番の入れ替えです。

数字がおかしいとき、原因は2種類あります。

「本当にパフォーマンスが変わった」か、「計測が壊れている」かです。

後者を先に潰す癖をつけると、誤った前提で次の施策を打つリスクがなくなります。

「タイムアウト」と「完了通知」を最初から組み込む

今回の教訓で一番実装に直結するのは、「タイムアウト設定」と「完了通知」の2つです。

タイムアウトは、処理が一定時間以内に終わらなかったら強制的にエラーにする設定です。

timeout: 300 と設定しておくと、5分以内に終わらないジョブはエラー扱いになります。

エラーになれば、ログに記録されるし、通知を設定しておけばSlackやメールにも飛ばせます。

完了通知は、逆に「正常に終わったときに通知する」仕組みです。

「今日も動いた」という記録が残るので、「最後に通知が来たのはいつだっけ？」

という確認ができるようになります。

タイムアウトが「止まりを検出する網」で、完了通知が「動いた証拠の蓄積」です。

この2つを組み込んでおくだけで、「止まっても気づかない」という状況を大きく減らせます。

Lilyがこういう自動化の仕組みをどう作っているか、全体の構造はClaude Codeで作った自律環境の記事にまとめています。

興味のある方はフッターのリンクからどうぞ。

26時間が教えてくれたこと

「信頼できるデータ」は、意識しないと崩れる

データに基づいて判断する。マーケティングを長くやってきたLilyには、当たり前のことです。

でもそのデータ自体が正しいかどうかを、26時間も見落としていました。

正しいデータを集めることと、集めたデータが今日のものかを確かめることは、別の話なんです。

後者を怠ると、どれだけ丁寧に集めたデータも、判断の根拠にはなりません。

止まった時計が、そのことを教えてくれました。

「自動化しているから大丈夫」の油断が、一番静かに精度を下げる

今回の件を通じて、Lilyが一番学んだのはここです。

「自動化している」という事実が、確認の動機を消してしまうんです。

手作業でやっていれば、「今日はまだやっていないな」という感覚が残ります。

自動化すると、「どこかで動いているはず」という感覚に変わって、確認の意欲が落ちます。

自動化の恩恵は本物です。毎日同じ作業を手でやるより、ずっと効率的です。

でも「自動化＝安心」ではなく、「自動化＝確認を忘れやすくなる」と捉え直すことが、ひとり運営では大事だと思います。

今日、できる1つのこと

もし自動でデータを集めるツールや仕組みを使っているなら、今日一度「最後に動いた時刻」を確認してみてください。

想定通りの時刻になっていますか？

確認の方法がわからなければ、「最近このツールが正しく動いているか、怪しいと思ったことはあるか」を自分に問いかけてみてください。

「そういえば最近確認していないな」という感覚があるなら、それが確認のタイミングです。

Lilyが今回学んだのは、「動いているはず」という思い込みが、一番静かに判断精度を下げる、ということです。

まず今日のデータが今日のものかを確かめる。それだけで、26時間分の盲点を防げます。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順