宅配便の追跡画面に「配達完了」と表示されていたことがあります。
「届いてるんだ」と安心して、その日の夜も普通に眠りました。
でも荷物は、3日後に届きました。
「完了」していたのは、記録の上だけでした。荷物はずっと、誰かの倉庫の棚で眠ったままでした。
全く同じことが、わたしが作ったシステムの中で起きていました。
ユーザーのリクエストが、記録上は「全部成功」のまま、39時間動かない状態が続いていました。
あなたは今こうなっていませんか？
• 自動化を動かしていて「あとは任せた」と安心している • エラーが出ていないから、正常に動いていると思っている • ログに「成功」が並んでいるから、細かく確認しなくなっている • 「失敗がない＝動いている」をほぼ同じ意味で使っている
先に結論を言います。「成功と記録されること」と「ちゃんと動いていること」は、別のことです。
この2つをずっと同じだと思っていたわたしが、利用者のリクエストを39時間止め続けていました。
監視のアラートは、その間に1度も鳴りませんでした。
この記事では、成功の記録が並んだまま39時間止まっていたジョブの原因と直し方、止まったことに気づくための監視の考え方を書きます。
kotonohaとジョブの仕組み
kotonohaというサービスの話をします。
kotonohaは、わたしが個人で作って動かしているサービスです。
利用してくださっている方がリール——縦型の短い動画——を送ると、内容を自動で処理してくれます。
依頼1件ごとに生まれるジョブと状態
このサービスには「ジョブ」という単位があって、依頼が1件届くとジョブが1つ生まれます。
ジョブとは、処理の命令を入れた箱のようなものです。「この1件をやってね」という指示の単位です。
ジョブには、生まれた瞬間から「状態」があります。
「待機中」「処理中」「完了」「失敗」——この状態が変わることで、今どこまで進んでいるかを把握できます。
そのうちの1つが「pending（保留中）」という状態で、処理が始まるのを待っているジョブに付くラベルです。
ジョブが生まれてから処理が始まるまでの、ほんの一瞬だけ通るはずの状態でした。
ひとりで設計し、ひとりで動かす
このシステムは、わたし1人で設計して、1人でコードを書いて、1人で動かしています。
こうした自動化の仕組みを1から設計するのは、当時まだ経験の浅い部分がありました。
毎日ダッシュボードを確認して、エラーがないことを確かめて、「今日も動いている」と感じながら仕事をしていました。
それが今回、完全に裏目に出ました。
📕 AIエージェントと自動化の全工程をまとめた総集編
手順・コード・テンプレをそのまま渡しています
🤖【完全版】月商160万円の「寝てても回る仕組み」をゼロから30日で組む全工程｜2026年10月版・Claude Code×AIエージェント・特典40ファイル・毎月更新
39時間止まっていたジョブ
事件が起きたのは、何気ない平日の昼過ぎでした。
利用してくださっている方から、1件の依頼が届きました。いつもと同じように、ジョブが1つ生まれました。
「ちゃんと動くだろう」と思って、その日の作業を続けました。特別な理由はありません。
いつもうまくいっていたから、今回もそうだろうと思いました。
翌日の夜に見たpendingの文字
翌日の夜でした。「そういえばあの件、どうなったかな」とふと思い、ダッシュボードを開きました。
「pending（保留中）」という文字が、そのままそこにありました。
「……え？」
依頼が届いたのは前日の12時14分でした。今は翌日の21時を過ぎていました。
タイムスタンプを2つ並べて、時刻の差を計算しました。
約39時間、ジョブは1ミリも動いていませんでした。
ログに並んだ6回の成功
「なにかミスをしたかな」と思って、ログを開きました。
ログというのは、システムが「何をしたか」を記録しておくメモのことです。
「いつ、何が起きたか」を確認するための記録で、問題が起きたときに最初に見に行く場所でもあります。
ログを開いて、わたしは少し止まりました。
「success」「success」「success」「success」「success」「success」
6回、全部「成功」として記録されていました。
監視のアラートは、1度も鳴っていませんでした。
「……どういうこと？」
成功が6回並んでいるのに、ジョブは動いていない。
エラーも出ていないのに、利用者の方は39時間待ったまま。
自分の見方を疑い続けた30分
最初は、自分の見方が間違っているのかと思いました。
「成功が6回あるなら、何かが正しく動いているはずだ」と思いました。
「ダッシュボードの表示がおかしいのかもしれない」とも思いました。
「自分の確認方法に間違いがあるのかも」とも思いました。
そう思って、あちこちを確認し続けました。30分以上かかりました。
でも結論は変わりませんでした。ジョブは動いていなかった。ログには成功しか並んでいなかった。
「ちゃんと動いてます」という証拠が積み上がっているのに、利用者への影響が消えない——この矛盾が一番つらかった。
リトライ回数を覚える場所がなかった
仕組みを少しだけ話します。難しい言葉は使いませんので、もう少し付き合ってください。
失敗したらやり直すリトライの仕組み
kotonohaには「リトライ」という機能があります。
リトライとは、処理がうまくいかなかったとき「もう1回だけやり直す」という仕組みのことです。
電話をかけたら繋がらなかった。だからもう1回かける——あの動きと同じです。
システムの世界では、こういう一時的な失敗はよく起きます。
通信が一瞬だけ不安定だったり、外部サービスが少し遅くなっていたり。
「少し待ってもう1回やれば通る」ことも多いのです。
だから「失敗したらもう1回やる」という機能は、よくある対策です。
kotonohaには、最大6回リトライする設定がありました。
「6回試してもだめなら、本当に失敗とみなす」という設計でした。
これ自体は、正しい方向の設計でした。問題は、まったく別のところにありました。
今何回目かを記録する欄がない
では、なぜ6回リトライしても「成功」だったのか。
ここが、今回の本当の問題でした。
kotonohaの実装には、「リトライが今、何回目かを覚えておく場所」がありませんでした。
ジョブのデータには、いろいろな情報が入っています。
依頼が届いた時刻、依頼してくれた方の情報、処理の内容——こういった情報はちゃんと記録されていました。
でも「今、何回目のリトライか」という欄が、どこにもなかったのです。
1回目のリトライをした後、「1回やった」という記録がどこにも残っていませんでした。
だから次にジョブが来たとき、システムは「また最初だ」と思って処理を始めます。
2回目も同じ。3回目も同じ。6回繰り返しても、「6回やった」という記憶がどこにもない。
7回目のリトライも、1回目のリトライも、実装には区別できなかったのです。
呼んだ記録が残らない病院の受付
もう少しわかりやすく言うと、こういうことです。
病院の受付で番号札を引いて、順番を待っています。
でも窓口の担当者は「今呼ぶべき番号」を確認できる仕組みを持っていません。
「43番の方」と声をかけても、担当者は「これが正しい呼び出しなのかどうか」を確かめる方法がない。
呼んでいるつもりが、実際には何も起きていない。
担当者が番号を1度呼んだ後、「呼んだ」という記録がどこにも残らない。
だから「もう1回呼ぶべきかどうか」の判断ができなくなる。
kotonohaのジョブはこの状態でした。
「自分が今、何回目の試みなのかを確認する手段」がなかったので、最大回数に達したとみなすことができないまま、永遠に待ち続けられる設計になっていました。
エラーなしで終わることは成功ではない
「リトライが6回成功した」という記録は、厳密には間違いでした。
正確には、「処理を6回試みて、6回ともエラーを出さずに終了した」でした。
エラーを出さずに終わった ≠ 成功。
「なにもできなかったけど、エラーは出していない」という状態が「成功」として記録されていたのです。
「成功」という言葉は、ふつう「うまくいった」という意味で使います。
でもシステムの処理では、「エラーを出さずに終了した」という意味しか持っていないことがあります。
この定義のズレが、今回の問題の核心でした。
エラーがなければアラートは鳴らない
監視の仕組みは、「エラーが出たときに鳴る」ように設定されていました。
エラーが出ていない。だからアラートは鳴らない。
でも、ジョブは動いていない。
「エラーがない＝正常」という前提は、今回の状態に対応できていませんでした。
「何もしていないこと」はエラーではなかったから、見張ることができていなかったのです。
異常検知と沈黙検知の2種類
監視には、大きく分けて2種類あります。
1つは「何か悪いことが起きたら教えてくれる」監視です。
エラーが発生したとき、例外が投げられたとき、レスポンスコードが異常だったとき——「起きてほしくないことが起きた」ときに動きます。
もう1つは「一定時間、正常なことが起きていなかったら教えてくれる」監視です。
「起きてほしいことが起きていない」ときに動きます。
前者はよく「異常検知」と呼ばれます。後者は「沈黙検知」とでも言うべきものです。
kotonohaに設定していたのは、異常検知だけでした。
エラーログが出たら通知する。処理が例外で止まったら通知する。外部との通信が失敗したら通知する。
これは、なにかが「壊れた」ときには機能します。でも、「何も起きていない」ときには機能しません。
今回のジョブは、壊れていませんでした。エラーも出していませんでした。
ただ、前に進んでいなかった。
「エラーがなかったから、鳴らなかった」という設計の問題が、そこに現れていました。
心拍監視のように沈黙を見張る
「沈黙検知」を別の言葉で表すと、「心拍監視」に近いイメージです。
心臓が正常に動いているなら、この間隔で必ず鼓動があるはずです。
その鼓動が止まったとき、初めて異常と判断します。
エラーを探すのではなく、「生きている証拠がないこと」を異常とみなす——この発想が、「何もしていない」を検知できるかどうかの分岐点でした。
たとえば「pendingのジョブが60分以上あったら通知する」というルールを1本加えるだけで、今回の39時間は大きく縮んでいたはずです。
その1行が、なかった。それだけのことでした。
ひとりで作ると止まっても気づけない
なぜこういう設計になってしまったのか、少し正直に書きます。
とにかく動かすことが先になる
個人でひとり全部作っていると、「最初はとにかく動かすこと」が目標になります。
まず動かす。動いたら少し改善する。
細かいエラーハンドリングや、異常な状態の検知は「あとで」になりやすい。わたしもそうでした。
kotonohaを最初に動かすことに集中していたとき、「動かなかった場合にどう気づくか」まで、細かく設計できていませんでした。
「動いていない」というのは、一見わかりにくい失敗の形です。エラーは出ない。ログには成功が並ぶ。
静かに、誰にも気づかれないまま、止まっている。
この静けさが、気づきにくさの正体です。
声をかけ合う相手がいない
チームがあれば、こういう問題は少し早く見つかります。
「そういえばあのリクエスト、どうなってます？」という会話が、どこかで生まれます。
人が複数いると、「あれ、おかしくないか」と誰かが感じる確率が上がる。
でも、ひとりでやっていると、その声をかける相手がいません。
「これ、変じゃないか」と確認し合う人がいない。
ひとりで作ってひとりで動かしているとき、「動いていない」に一番最初に気づくのは利用者です。
依頼を送った側が「返ってこないな」と感じたとき、初めて問題が浮かび上がる。
その前に自分で気づけるかどうかは、設計の問題です。
わたしが今回、39時間気づけなかったのは、この構造があったからでもあります。
動いているように見えて、実は壊れている。ひとりでやるほど、その状態は長く続きやすい。
これが今回、一番怖かったことでした。
原因の発見と3時間の修正
深夜を過ぎた頃、ようやく原因がわかりました。
コードを端から端まで追っていって、気づきました。
「リトライ回数を保存している変数が……ない。」
どこを見ても、「今、何回目のリトライか」を覚えておく場所がありませんでした。
気づいたとき、少しだけ笑いたくなりました（笑）「こんな単純なことか」と思ったからです。
でも、単純だからこそ見落とした。単純だからこそ、39時間止まり続けることができた。
この矛盾が、おかしくもあり、怖くもありました。
リトライ回数の欄と沈黙検知を追加
修正は、思ったよりシンプルでした。
まず、ジョブのデータに「リトライ回数」を記録する欄を1つ追加しました。
名前欄やメールアドレス欄と同じように、「今何回目のリトライか」を保存する欄を作る。それだけです。
ジョブが生まれたとき、その欄は「0」から始まります。
リトライが1回終わるたびに、1ずつ増えていきます。
次に、「カウンターが6に達したとき、それ以上のリトライを止めてジョブを失敗とみなす」というルールを加えました。
「failedになったとき、通知を出す」という処理も合わせて加えました。
最後に、「pendingのまま一定時間を超えたジョブがあれば、アラートを出す」という仕組みを追加しました。
これが「沈黙検知」の最初の1本でした。
実作業でかかった時間は、3時間ほどでした。
39時間と3時間の非対称
39時間止まり続けたのに、修正は3時間で終わりました。
この非対称さが、今も頭に残っています。
壊れていた時間と、直した時間が全然釣り合っていない。
それは同時に、「もっと早く気づいていれば」という話でもあります。
設計の段階で「止まったことを検知する仕組み」を入れていれば、39時間が数時間に縮んでいたかもしれない。
「あとで入れよう」にしたことのコストが、そこに現れていました。
「終了した」と「完了した」は違う
この経験から、今も意識していることが1つあります。
「動いていないことを、誰が教えてくれるか」を設計に組み込む、ということ。
何も起きなかった記録は残らない
成功のログは積み上がります。エラーのログも、たいていは残ります。
でも、「試みたけど何も起きなかった」という記録は、意識して作らないと残りません。
今回の6回のリトライは、全部終了していました。終了したから「成功」と記録された。
でもジョブは1ミリも前に進んでいなかった。
「終了した」と「完了した」は、違う言葉です。
エラーがないは問題がないではない
これはリトライの話に限りません。
自動化を動かしていて、「動いているはず」で確認をやめた瞬間から、このリスクは生まれます。
「エラーがない」は「問題がない」とは違います。
「ログに成功が並んでいる」は「処理が前に進んでいる」とは違います。
異常検知は、何かが壊れたときに教えてくれます。でも、何も起きていないことは教えてくれません。
「何も起きていない」は、壊れているのではなく、止まっているのです。
この2つを区別できる設計が、ひとりで動かすシステムには特に必要だと感じています。
あなたのシステムに確かめたい3つの問い
ひとりで自動化を動かしている方に、1つだけ確かめてほしいことがあります。
あなたのシステムは、「動かなかった」ことを教えてくれますか？
通知・上限・前進を確かめる
具体的には、3つの問いです。
「一定時間、動きのないジョブがあったとき、通知が来るか」
「上限を超えてリトライが繰り返されているとき、それを止める仕組みがあるか」
「"成功"と記録されているものが、本当に前に進んでいるか確認できるか」
この3つのうち1つでも「ちゃんと確認したことがない」と思ったなら、今日の作業の前に少しだけ確かめてみてください。
動いているかどうか確認するより、動いていないことに気づける設計かどうかを確認する——そこに一番の差があります。
「止まったことを検知する仕組みを設計に含める方法」については、Claude Codeの自律環境の仕組みと一緒に、有料記事にまとめています。 フッターのリンクからたどれます。
数字で振り返る今回の一件
最後に、今回の一件を数字だけで振り返ります。
利用者へのご迷惑：39時間記録に残った「成功」の回数：6回鳴った監視アラートの回数：0回気づくまでの時間：約1日半修正の実作業時間：3時間
これが全部、同じ1件の出来事です。
「全部成功していた」のに、何かが止まっていた。ひとりでやっているとき、それは静かに、長く続きます。
今日、一度だけ——「成功のログが並んでいること」を疑ってみてください。
📕 この記事の内容を、実装まで全部まとめた有料記事があります
手順・コード・テンプレをそのまま渡しています
AIで「寝てても回る仕組み」を30日で組む全手順｜コード不要・特典40ファイル・毎月更新
この記事の販売者
