自分の実行ログで停止に気づく——24回基準だと21日全部が異常

これで何ができるか

自動化が静かに壊れたのを、AIに見つけさせるは、監視している相手（取得先のサイトやデータ）の更新が止まることを見つけます。今回は逆の軸です。監視している側——自分の定期実行そのものが、知らないうちに動かなくなっていないかを、実行時刻の記録（ログ）だけから見つけさせます。

架空の「1時間ごとに実行される予定」の処理ログ2本に、4つの指示文を各2回・計16回試した結果は、次の4つです。

1. 「1日の予定実行回数は24回です。50%を下回ったら知らせて」と予定の回数を基準にすると、どちらの記録でも4回中4回とも「ほぼ全日が異常」という同じ答えが返りました。本当に4日間止まった記録でも、何も起きていない記録でも同じです。ログの中身を入れ替えても、出てくる答えの見た目が変わりません。
2. 「まず記録から、ふだんの1日あたりの実行回数を自分で計算してください」と頼むと、4回中4回とも本当の停止日（4日間）だけを正しく名指ししました。何も起きていない記録では、4回中4回とも誤報がありませんでした。
3. 基準を渡さず「気づく点があれば教えて」と聞くだけでも、4回中4回で停止を正しく見つけました。ただし答えの形が毎回違う文章になり、通知や次の処理にそのまま渡す形には向きません。
4. 指示文3に「日付の範囲」と「行が無い日は0件として数える」を足すと、4回とも真の停止日と完全に一致しました。

📌 この記事の数字はすべて架空データでの実測です。実在の個人・企業の情報は含みません。独立した新規会話（毎回ゼロから起動・前の会話の記憶なし）で合計16回試しました。生の返りと機械照合は docs/evidence/own-average-catches-it-schedule-count-misses-it.md に全文置いてあります。

前提

材料は架空の「1時間ごとに実行される予定」の処理ログ2本です。どちらも21日間（2026-09-01〜09-21）で、1日あたり4〜8回という、予定（24回）より最初から少ない頻度で動いています。

• 材料A＝09-10〜09-13の4日間だけ、本当に実行が0回になった版
• 材料B＝対照。同じ期間のまま、09-10〜09-13も含めて全日4〜8回のまま（何も起きていない版）

AIへの頼み方

1. 名目の予定回数を基準にする（できなかった版）

まず、素直に「予定どおりの回数」を基準にしてみます。

材料Aに対する2回の返り（要約せず抜粋）です。

ログに登場する全17日とも12回未満で、50%を上回った日はありませんでした。

最少は09-05/09-16/09-17/09-21の4回、最多は09-02/09-03の8回（それでも予定の33%）。09-10〜09-13はログ自体が存在しません（ゼロ件としては数えていません）。

材料Bに対する2回の返りも、形がほぼ同じです。

ログに含まれる2026-09-01〜2026-09-21の全21日すべてで、実行回数が12回を下回っていました（最多の日でも8回）。

日次件数そのものは4回とも真値と完全一致していました。数え間違いではありません。問題は、材料Aでも材料Bでも「ほぼ全日が該当」という同じ形の答えが返ったことです。本当に4日間止まった記録でも、何も起きていない記録でも同じ答えでした。さらに材料Aの2回のうち1回は、09-10〜09-13を「ログに存在しないので数えない」と明言しました。本当の停止日を名指しすらしなかったということです。

このサイトのトラッカー自身がそうですが、元から予定どおりに動かない自動処理は珍しくありません。名目の予定を基準にした瞬間に、警報が鳴りっぱなしになります。

2. 基準を渡さずに聞く（自由記述版）

次に、何も基準を渡さず、気づいたことをそのまま書いてもらいます。

材料Aでの2回は、どちらも本当の停止区間を言い当てました。

最大の異常: 9/9 21:55から9/14 00:02まで、約4日2時間、記録が一件もない。これが群を抜いて目立つ区間です。

材料Bでの2回は、どちらも「不規則だ」とは書きましたが、特定の日を異常として名指ししませんでした。基準を渡さなくても、4回中4回とも材料Aの停止を正しく見つけ、材料Bで誤報しませんでした。ただし返り方は毎回違う文章です。「該当あり/なし」のような決まった置き場所がありません。通知を送るかどうかを機械的に判定する次の工程には、そのままでは繋げにくい形です。

3. 自分の記録から目安を計算させる（効いた版）

名目の予定ではなく、ログそのものから「ふだんの回数」を出させます。

材料Aでの返り（1回目の抜粋）です。

記録のある日（09-10〜09-13を除く17日間）の合計は101件で、1日あたりならすと約6件です。ふだんはどの日も4〜8件程度に収まっています。この目安と比べると、極端に少ない日があります。2026-09-10（0件）・2026-09-11（0件）・2026-09-12（0件）・2026-09-13（0件）。4日連続で実行記録がゼロになっており、ふだんの目安から明らかに外れています。

材料Bでの返りは、2回とも「該当なし」でした。

結論: 目安（約6回/日）と比べて極端に少ない日（0件を含む）は見当たりません。該当なし。

4回とも、異常日の判定が真値と完全一致しました。材料Aでは4回中4回とも09-10〜09-13の4日間だけを正しく名指しし、材料Bでは4回中4回とも誤報がありませんでした。基準を名目の予定ではなく記録そのものから計算させるだけで、指示文1の失敗と指示文2の弱さが両方解消しています。

うまくいかないときの言い直し方

名目の予定回数を基準にすると、何回聞いても「全部が異常」になる

「1日に何回動く予定か」を基準にしないでください。直すのは基準の決め方そのものです。更新停止の異常判定は一律にしないは、複数の監視対象に同じ固定閾値を当てると、相手ごとに誤検知が起きることを確かめました。更新頻度が違う相手を、1つの基準で測った結果です。今回は1つの処理でも、名目の予定自体が実態と離れていれば同じことが起きます。「まず記録から目安を計算して」と頼み直してください。

自由記述だと、答えの形が毎回違う

指示文2は正しく異常を見つけますが、文章の長さや構成が回ごとに違います。自動処理の次工程（Issueを立てる・通知を送るなど）に繋ぐなら、答えの形を決めてください。指示文3のように「該当する日が無ければ『該当なし』と答えてください」と、決まった結論の書式を指定することです。毎日決まった時刻にAIを動かす仕掛けの通知判定にそのまま載せられます。

「ログに行が無い日」を0件と数えてくれるか分からない

今回の指示文1では、2回のうち1回が「09-10〜09-13はログ自体が存在しないので、ゼロ件としては数えていません」と明言しました。完全に実行が止まって記録の行自体が無くなる、という最悪のケースほど、こうして見えなくなる危険があります。0件アラームに休業日を教えるで確かめた直し方がそのまま使えます。「日付の範囲」を先に決め、「該当する行が無い日は0件として数えてください」と明示することです。

材料A・Bそれぞれ2回試したところ、4回とも真の異常日と完全に一致しました。09-10〜09-13は、2回とも「ログに行が無いので数えない」という抜け道を使わず、明示的に0件として数えたうえで異常に名指しされています。指示文3だけでも材料Aの4回は正しく答えていましたが、それは「存在しない日付に気づいて自分で埋めた」結果です。この一文を足すほうが、運に頼らず確実です。

応用・次の一手

名目の予定ではなく、ログそのものから「ふだんの回数」を計算させること。これが、本当の停止と平常なばらつきを区別する唯一の分かれ目でした。日付の範囲を足すと、さらに取りこぼしの余地が減ります。

実務に載せるなら、次の順番がおすすめです。

1. 指示文4の形で、ふだんの目安と判定結果を決まった書式で出させる
2. 「該当なし」以外が返った回だけ、自動化が静かに壊れたのを、AIに見つけさせると同じ要領でGitHubのIssueを立てる
3. この指示文をそのまま、監視対象のワークフローごとに毎朝1回動かす

⚠️ この記事が実測していないことは2つです。

• 複数の処理をまとめて見張る場合（更新停止の異常判定は一律にしないが近いですが、あちらは監視対象の更新頻度の話です）
• 実行間隔がさらに不規則な処理（今回は1日4〜8回という、ある程度安定した頻度の材料でした）

次に測るなら、監視対象を複数まとめて1回の指示文に渡し、処理ごとに別の「ふだんの目安」を正しく計算し分けられるかを確かめるところから始められます。