📭 235件のDMが14秒で『ゼロ』になっていた——『いない』と『見えていない』を混同した3週間

ポラロイドカメラを使ったことがある方は、あの不思議な感覚をご存じかと思います。

シャッターを押すと、真っ白な四角い紙がするっと出てきます。

「おかしい、失敗したのかな」と思って、10秒、14秒と眺めます。

何も変わらないので、白いまま捨ててしまいます。

でも本当は、あと50秒ほど待てば、ちゃんと顔や景色が浮かび上がってくるのです。

「写っていない」のではなく、「まだ現像中」だっただけです。

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

• ログに「完了」と出ていれば、件数を確認しなくてもいいと思っている
• 数字がゼロになったとき、「本当にゼロ？」と疑う前に次の作業へ進んでいる
• 自動化の仕組みを設定したあと、正常に動いているかの確認をしていない
• 同じ処理を毎日走らせているのに、結果の推移を比べたことが一度もない

先に結論を言います。DMは235件と253件、ちゃんとそこにありました。

この記事では、3週間にわたって気づかなかった「偽ゼロ」の話と、待ち時間を60秒に延ばしたら一発で解決した経緯を書きます。

毎朝届いていた「送信対象：0件」

最初は「今日だけかな」と思っていた

Lilyは今、AIを使っていくつかの作業を自動化する仕組みを動かしています。

そのひとつが、SNSのDM（ダイレクトメッセージ）を送る処理です。

候補リストを読み込んで、条件に合う相手へ順番にメッセージを送るものです。

毎朝1回、自動で動くように設定してあります。

設定してから最初の数日は、正常に動いていました。

ところがある朝、処理のログを確認したら「送信対象：0件」と出ていました。

「今日は条件に合う人がいなかったのかな」と、そのまま次の作業へ進みました。翌朝も0件でした。

その次の日も、0件です。

3日続いた時点で、さすがに「おかしいかもしれない」と感じました。

でも処理そのものにエラーは出ていませんでした。

ログには「正常に完了しました」と書いてあります。

「設定が間違っているのかな」と候補リストを確認してみましたが、データは正常に入っていました。

「読み込みの対象が、たまたまゼロだっただけなのかも」——そう判断して、また次の作業へ進みました。

「ゼロが続くのが当たり前」という感覚

1週間が過ぎた頃から、不思議なことが起きました。

「ゼロが続いているのはおかしい」という感覚が、少しずつ薄れていったのです。

毎日「送信対象：0件」というログを見ていると、それが「この仕組みの普通の状態」のように感じ始めます。

「この時期は対象が少ないのかもしれない」という、根拠のない仮説が頭の中に定着していきます。

2週間が経った頃には、0件のログを見ても何も感じなくなっていました。

ログを確認して「今日も0件か」と一言つぶやいて、すぐに次の作業へ移る日々でした。

処理が走っている事実と、それが正しく動いているかどうかは、まったく別の話です。

でもその2週間、Lilyはその区別をしていませんでした。

「動いている」と「正しく動いている」を、同じものとして扱っていたのです。3週間でおそらく21回。

毎日、同じ「偽ゼロ」のログを見て、21回「今日も正常だ」と判断していたことになります。

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

「ゼロの正体」に気づいた日

ログの詳細を、ふと覗いてみた

3週間が過ぎたある日、少し時間ができました。

いつもはログの一行目だけを確認して閉じていましたが、その日は何となく詳細部分まで開いてみました。

処理の流れを最初から読んでいくと、こんな一行が目に入りました。

「DM一覧の取得完了（14秒）——0件」

...14秒？ なんとなく引っかかりました。

「取得完了」と書いてあるのに、0件というのは矛盾していないか、と。

確かめるために、手動で同じ操作をやってみることにしました。

DM一覧を取得する処理を走らせて、画面の変化をじっと観察します。

最初の数秒は、くるくると読み込み中のマークが回っています。

5秒、10秒、14秒——画面が切り替わりました。

「0件として完了しました」という表示が出ました。でも今日は、Lilyはそこで止めませんでした。

そのまま画面を眺め続けることにしたのです。

50秒を超えたところで、一気に現れた

20秒が過ぎました。画面は変わりません。

「やっぱりゼロなのかな」と思い始めた頃、画面の端がわずかに動きました。

30秒、40秒と経つにつれ、読み込みのアイコンがまた現れています。

「完了」と表示されたはずなのに、処理はまだ続いていたのです。

そのまま眺めていると、50秒を超えたあたりで——突然、リストが一気に表示されました。

235件のDMが、そこにありました。

念のため、もう一度同じ操作を試してみました。今度は253件出てきました。

3週間分のゼロは、「まだ読み込み中」の画面を14秒で見切っていた結果でした。

しばらく声が出ませんでした（笑）

「処理は完了していた」のではなく、「完了と表示された時点でまだ読み込みが終わっていなかった」だけだったのです。

自動化の仕組みが「取得完了」と判断したその瞬間、外部サービス側のデータはまだ届いていませんでした。

届く前に「ゼロ件で完了」という処理が走り、3週間それが繰り返されていたのです。

「いない」と「見えていない」はまったく別の話

電気が切れた部屋と、空の部屋

「ゼロ件」には、2種類あります。

ひとつは「本当に何もなかったゼロ」で、もうひとつは「あったのに見えなかったゼロ」です。

この2つは、意味がまったく異なります。

電気が切れた暗い部屋を見て「誰もいない」と言うのは、早合点です。

暗くて見えていないだけで、実際にはそこに誰かいるかもしれません。

「見えない」と「存在しない」を区別するには、光を持ち込んで確認するしかないのです。

Lilyの場合も、DMは確かにそこにありました。

「読み込みが終わっていない画面」を見て「空だ」と判断していただけでした。

仕組みの画面に映っていなかったのは事実ですが、だからといって「存在しなかった」わけではないのです。

この区別を意識するだけで、ゼロを見たときの向き合い方が変わります。

「ゼロ」が返ってくる3つのパターン

自動化の仕組みでゼロが返ってくるときには、大きく3つのパターンがあります。

ひとつは「本当に対象がゼロだった」という正常なゼロです。

ふたつめは、「取得に失敗してゼロになった」という異常なゼロです。

接続エラーや認証の問題で、そもそもデータが取れなかった状態です。

そして3つめが、Lilyが今回経験したパターンです。

「取得は試みたが、完了前に打ち切られてゼロになった」というタイムアウト起因のゼロです。

3つのうち、外から見た見た目はどれも同じです。「0件」とだけ表示されます。

でも中身は、まったく違います。

正常なゼロは次のアクションに進んでいいのですが、残りの2つはそのまま進んではいけません。

ログの件数だけ見ていては、この3つを区別できないのです。

AIや自動化で「見えないゼロ」が起きやすい理由

AIや自動化の仕組みでは、外部サービスへのアクセスが必ず発生します。

SNSのAPI、メール配信ツール、検索サービス——どれも「外の世界」とデータをやりとりします。

この「外の世界」は、自分の仕組みとは独立して動いています。

負荷が高い時間帯には応答が遅くなることがありますし、メンテナンスで一時的に遅延することもあります。

自分の仕組みは「正常に動いている」のに、外部サービス側の応答が遅れてタイムアウトになる——それが今回のケースでした。

設定が間違っていたわけでも、コードにバグがあったわけでもないのです。

「外の世界に合わせた待ち時間」が設定されていなかった、というだけです。

この種の問題は、ログをさらっと読んでいるだけでは見えてきません。

時間がかかるほど「ゼロになりやすい処理」を把握して、その処理の結果は少し念入りに確認する習慣が大切になります。

事業会社で身についていた「ゼロ疑い」

数字がゼロになったら、まずツールを疑う

Lilyは以前、事業会社で広告の運用や計測の仕事をしていました。

その頃に上司から何度も言われたことがあります。

「計測の数字がゼロになったら、まず計測ツール側を疑え」というものです。

広告の計測をしていると、成果の数字がゼロになる日があります。

「今日は問い合わせがゼロだったのか」とそのまま受け取りたくなりますが、経験を積むほど「本当にゼロだった」ことはめったにないと分かってきます。

計測タグがページから外れていた。フォームの仕様が変更されてデータが取れなくなっていた。

ツール側のシステム障害が起きていた。ゼロの原因のほとんどは、計測する側の問題でした。

「数字はツールを通してしか見えない。ツールは壊れうる」——これが計測の世界の常識でした。

だからゼロを見たら、まず「ツールがおかしくないか」を確認する癖が自然とついていました。

自分で作った仕組みでは、逆になっていた

なのに、自分で組んだ自動化の仕組みでは、まったく逆のことをしていました。

「ゼロと出た＝本当にゼロだ」と、反射的に受け入れていたのです。

振り返ってみると、「自分で設計したものへの信頼」が、疑う目を曇らせていたのだと思います。

他人が作ったツールなら「バグがあるかも」と自然に疑えます。

でも自分で作ったものは、「ちゃんと考えて設計した」という前提が無意識に働きます。

「自分が作ったのに壊れているはずがない」という思い込みは、自覚のないまま積み上がっていきます。

3週間後に真相を知ったとき、「あの頃の自分はなぜ疑わなかったのか」と思い返しましたが、答えは明確でした。

「自分で設計した」というだけで、疑う基準をゆるめていたのです。

これはAIや自動化を使い始めた人が陥りやすい、静かな罠だとLilyは感じています。

信頼と検証は、矛盾しない

大切なのは、「信頼するか、検証するか」という二択ではないということです。

自分が組んだ仕組みを信頼することは、正しい態度です。

でも信頼することと、検証することは矛盾しません。

むしろ「信頼しているからこそ、定期的に確かめる」というサイクルが、長く安全に動かし続けるための基本です。

車のオイルを信頼しているドライバーも、定期点検は欠かしません。

自動化の仕組みも、同じ考え方が当てはまります。

「設定したあとは確認しない」のは、信頼ではなく放置です。

この区別を意識するようになってから、Lilyの仕組みとの向き合い方が変わりました。

直し方は、たった2行の変更だった

「14秒」を「60秒」に延ばした

問題の原因が分かってしまえば、修正はそれほど難しくありませんでした。

処理の設定の中に、「DM一覧の読み込みを待つ上限時間」という項目がありました。

そこが14秒になっていたのです。この14秒という数字は、設定した記憶がありませんでした。

おそらく最初に仕組みを作ったときに、デフォルトの値としてそのまま残っていたのだと思います。

デフォルト値が使いっぱなしになっていた——よくある話ですが、気づかないままだと大きな影響が出ます。

その数字を60秒に変えました。変更したのは、たった2行の設定です。

翌朝ログを確認したら「送信対象：235件」と表示されていました。

3週間ゼロだったものが、設定を変えた翌日に一気に解消されました。

もう少し複雑な問題だと覚悟していたので、拍子抜けするほど簡単でした。

「それでも出なければ1回だけ再読み込み」を追加した

念のため、もうひとつ小さな処理を加えました。

60秒待っても読み込みが完了しない場合に、1回だけページを再読み込みする処理です。

「完全に固まってしまったときの保険」として入れました。

ポイントは「1回だけ」という上限を設けたことです。

再試行を繰り返すと、処理が長くなりすぎてほかの処理に影響が出ます。

2回試しても出なければ、そもそもその時間帯は状態が安定していないということでもあります。

1回だけ試して、それでも出なければ「今日はスキップ」として次へ進む——この設計が、シンプルで安定していました。

「待つ」「1回だけ再試行する」「それでも出なければスキップ」の3段構えで、現在は安定して動いています。

AIの自律的な動かし方についてより詳しい仕組みは、別のnoteにまとめていますので、気になった方はフッターのリンクからどうぞ。

「完了ログ」を信じすぎていた

「完了」には2種類の意味がある

今回の一番の学びは、ここにあります。

「ログに完了と出ているから大丈夫」は、思っているほど信頼できません。

「完了」という言葉は、「正しく終わった」と「打ち切られて終わった」の両方の場面で出てくるからです。

ソフトウェアの処理で「完了」と表示されるとき、それは「指示した処理が一区切りついた」ということを意味します。

「意図した通りの結果が得られた」という意味では、ないのです。

Lilyのケースでは、「読み込みがタイムアウトして0件として完了した」という状態でした。

処理は確かに終わっていましたが、正しくは終わっていなかったのです。

3週間、毎朝この「完了ログ」を見て安心していました。

ログの「何件」まで読む習慣

これを防ぐには、「何件処理されたか」まで確認するクセが大切です。

「完了しました——0件」というログを見たとき、2つの読み方があります。

ひとつは「対象が0件だったから完了した」、もうひとつは「何らかの理由でゼロになって完了した」です。

この2つを区別するには、前後のログと件数の推移を見る必要があります。

「昨日は200件だったのに今日は0件」という変化は、正常なゼロではない可能性が高いのです。

件数がゼロのときは、一度立ち止まる——それだけで、今回のようなケースはかなり早く気づけます。

今は「件数ゼロ」を見たら自動的に立ち止まるルールを自分で作りました。

完了ログをそのまま信じるのではなく、件数という数字で補完するのです。

この小さな習慣が、同じミスを防ぐには十分に機能しています。

「変化に気づく」仕組みを作る

もうひとつ、意識するようになったことがあります。「結果の推移を定期的に比べる」という習慣です。

今日の結果だけを見ていると、それが正常かどうかの判断が難しいことがあります。

でも「先週と比べてどうか」「3日前と比べてどうか」という視点を加えると、異変に気づきやすくなります。

毎日同じ処理を動かしているなら、結果にも大きなブレはないはずです。

急に増えたり、急にゼロになったりするときは、何かが変わっているサインです。

「変化を見る」目を持つことで、異常なゼロを見逃さない体制が作れます。

処理の結果を日次で眺める習慣は、異変の早期発見に直結します。

3週間分の「見えていた損失」を振り返る

処理されなかったDMの数を考える

3週間、毎日200件を超えるDMが処理されないまま過ぎていきました。日数は21日です。

規模については詳細を伏せますが、かなりの量でした。

もちろん全員が反応するわけではありませんし、全員が対象として適切だったかも分かりません。

ただ「処理すらされていなかった」という事実は変わりません。

3週間ずっと、入り口の扉が閉まったままだったような状態でした。

扉が閉まっていることに気づかず、「今月は反応が少ない」と感じていた期間でもあります。

原因は扉にあったのに、「やり方が悪いのかな」と悩んでいたとしたら、それはかなりもったいない時間の使い方です。

本当の損失は「3週間気づかなかった」こと

数字の損失よりも、Lilyが重く受け止めたのは「3週間気づかなかった」という事実そのものです。

なぜ3週間もかかったのか。ログを毎日確認していたのに、なぜ気づけなかったのか。

振り返ると、3つの原因が重なっていました。ひとつめは「ゼロが続くことに慣れてしまった」こと。

ふたつめは「完了ログを詳しく読まなかった」こと。

そして3つめは「自分で作った仕組みだから正しく動いているはず」という先入観です。

この3つが重なると、異常がそこにあっても気づけなくなります。

3週間は少し長かったですが、これが1年続いていた可能性もゼロではありませんでした。

「いつ気づけるか」は、どれだけこまめに「変化」を見ているかで決まります。

「動いているはず」から「動いていることを確認した」へ

今回の経験から、Lilyは仕組みを動かしたあとの確認方法を変えました。

「自動化したから後は任せておこう」ではなく、週に1回は実際の処理件数を目で確認するようにしました。

「0件が続いていたら、1度だけ手動で同じ操作をやってみる」というルールも加えました。

自動化を信頼することは大切です。

でもその信頼は、たまに確認することで初めて安全になります。

「動いているはず」と「動いていることを確認した」は、まったく別の言葉です。

この違いを意識するだけで、ゼロが3週間続いても気づかない——という状況はかなり減らせると感じています。

処理の件数を「週に1度だけ眺める」という小さな時間が、大きな見落としを防いでくれます。

自動化は「放置していい」ではなく、「確認の頻度を減らせる」ものです。

ゼロになったとき、「本当にゼロなのか」を1秒だけ考える余地を、仕組みの設計の中に残しておきたいのです。

ポラロイドを14秒で捨て続けた3週間が、Lilyに大切なことを教えてくれました。

「ゼロ」は、本当にゼロとは限りません。「まだ現像中」かもしれないのです。

次に自動化の結果が「0件」と出たとき、捨てる前に少しだけ待ってみてください。

235件が、静かにそこで待っているかもしれません。

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