これで何ができるか
更新頻度がばらばらな相手（週1回・月1回・不定期）をまとめて監視するとき、「何日更新が無ければ異常」という基準の決め方によっては、正常な相手を誤って異常判定してしまうことがあります。プログラミングは要りません。
架空の更新履歴を3系統つくりました。①週次で変動が小さい相手（6〜8日ごと）②月次で変動が大きい相手（28〜34日ごと）③実際に65日間更新が止まっている相手、の3つです。これを1回の依頼にまとめて、「異常の基準をどう決めるか」という頼み方を5通り×各2回＝10回試しました。
意外だったのは、直近6回の更新間隔から基準を計算させるという、いちばん「賢そう」に見える言い方が裏目に出たことです。こう頼むと、更新間隔がほぼ一定（変動±1日程度）の相手について、わずか1日の遅れを2回とも「異常」と誤判定しました。変動が小さいほど、統計的な基準も実績のすぐ近くに来てしまうためです。一方、「固定14日を超えたら異常」という単純な言い方は、月1回しか更新されない相手を2回とも誤って異常判定しました。14日という数字自体が、月次の相手にははなから短すぎたのです。
本当に止まっている相手（65日間の停止）を見逃した回は、5通り×10回を通じて1回もありません。問題は「見逃し」ではなく「誤検知」の側で、しかもどの言い方を選ぶかによって、誤検知される相手が入れ替わるという点が今回の発見です。
前提
- 監視している相手が複数あり、それぞれ更新の頻度が違うこと（週1回・月1回・不定期など）
- その頻度の違いを、過去の更新履歴（日付の一覧）としてAIに渡せること
- 「異常＝更新が止まっている」を毎日AIに判定させて、通知や報告に使う場面があること
この記事は「更新が止まったことをどう検知の仕組みに載せるか」ではなく「何日を基準にするか」という1点に絞っています。検知そのもの（止まったソースを見つけて記録する仕組み）は自動化が静かに壊れたのを、AIに見つけさせるにあり、あちらは「最終更新日＝今日か」という固定・厳格な判定でした。今日ではないことが正常にありうる相手（月1回・不定期）を扱うのは今回が初めてです。あとから足した項目に記録が無い場合の扱いはあとから足した監視項目、古い記録まで巻き込むかで別に扱っています。
AIへの頼み方
材料は3系統の更新履歴（日付のみ）です。今日の日付は2026-09-06、最終更新からの経過日数は①9日・②33日・③65日になるように仕込んであります。
【今日の日付】2026-09-06
【監視している3つの相手の更新履歴（すべて過去の実績。日付のみ）】
① 週刊ニュースレター（取引先Aが週1回配信）
2026-07-18
2026-07-25
2026-07-31
2026-08-07
2026-08-15
2026-08-22
2026-08-28（最終更新）
② 仕入れ先からの月次価格表（月1回、更新日は月によってばらつく）
2026-01-31
2026-02-28
2026-03-31
2026-05-04
2026-06-02
2026-07-05
2026-08-04（最終更新）
③ 委託先からの納品完了メール（だいたい2週間おき）
2026-04-07
2026-04-21
2026-05-06
2026-05-19
2026-06-04
2026-06-18
2026-07-03（最終更新）
1. まず、基準の決め方ごとAIに丸投げする
（この下に、上の3系統の更新履歴をそのまま貼ります）
2回とも、「過去の最大間隔＋余裕」という妥当な基準を自分で決め、①②を異常と判定しませんでした。①は「過去最大の8日は超えたが、まだ閾値未満で要注意」、③は「閾値の3倍以上、明確に異常」と正しく判定しています。
なぜこの言い方か。基準の決め方も含めて丸投げすると、AIがどんな筋道を選ぶかが分かります。ここでは相手ごとに違う基準を自分から作った、というのが1つ目の観察です。
2. 「直近6回の間隔から計算して」と、より厳密に頼む
丸投げより厳密に聞けば、もっと安定するはずだと考えて試しました。
2回とも、変動がほぼ一定（±1日程度）の①だけを、誤って「異常」と判定しました。返ってきた式は「平均＋2×標準偏差」で、①の標準偏差は0.69日しかないため、閾値が「約8.2日」という実績のすぐ近くに来てしまい、9日というわずか1日の超過が「統計的に見て明らかな逸脱」と判定されています。②（変動が大きい月次）は同じ式でも閾値が35日前後まで広がるため、33日は正常のままでした。
なぜこの言い方が裏目に出たか。「統計的に計算する」は一見いちばん厳密に見えますが、変動が小さい相手ほど基準が厳しくなるという副作用があります。規則正しく動いている相手ほど、わずかな遅れが「これまでに無い異常値」に見えてしまうのです。
3. 「固定14日」を全部の相手に当てる
逆に、シンプルな固定日数で全部を判定したらどうなるかも試しました。
2回とも、月1回しか更新されない②を、誤って「異常」と判定しました。2回目の返りでは、AI自身が「これは元々月1回のペースなので、一律14日しきい値だと毎月機械的に異常判定される構造になっています」「実運用ではオオカミ少年化しやすい」と、なぜこの基準が良くないかまで説明しています。
4. 「固定35日」なら、今回はどちらも避けられた
2回とも、①②を誤って異常と判定せず、③だけを正しく異常と判定しました。ただし②は「33日／35日」とわずか2日の余裕しかなく、AI自身も両方の回で「僅差」「来週にずれ込む場合は要注視」と注記しています。今回たまたま合っただけで、月の更新日がもう数日ずれる相手だったら同じ35日でも誤検知していたはずです。
うまくいかないときの言い直し方
1つの日数に決め打たず、相手ごとに計算させる
指示文2（統計計算）と指示文3（固定14日）、それぞれの弱点を避ける言い方を試しました。
2回とも、①②③すべてで正しい判定に戻りました。①の基準は「8日＋3日＝11日」、②は「34日＋3〜5日＝37〜39日」と、相手ごとに違う基準が作られ、どちらも誤検知していません。「1つの日数に決め打たない」という一文が、指示文2・3両方の失敗を防ぐ形になっています。
境界線に近いものを「黄信号」にして、白黒だけにしない
①は9日／基準11日、②は33日／基準37日と、どちらも「まだ正常だが余裕が少ない」状態でした。二値判定だと、この際どさが伝わりません。
2回とも、①を「黄信号」・②を「正常」・③を「異常」と、3段階で正しく分けました。①は基準まで残り2日で黄信号、②は残り4日で正常、という際どい違いも両方の回で一致しています。「異常」と「まだ正常」の間に1段階置くと、境界線ぎりぎりの相手も、事故ではなく注意喚起として扱えます。
この結果を「1つの式が常に正しい」と受け取らない
今回「固定35日」が誤検知しなかったのは、たまたま②の実績（28〜34日）にこの数字が収まっていたからです。相手の更新間隔がもっと長い（2〜3か月おき）場合や、逆にもっと短い場合には、同じ35日という数字は機能しません。効いたのは特定の日数ではなく、「相手ごとに、その相手の実績から基準を決める」という考え方そのものです。指示文5（言い直し方の1つ目）の形を、監視する相手が増えても崩れない基本形として使ってください。
応用・次の一手
この記事の値打ちは「賢そうな計算式ほど、規則正しい相手には厳しくなりすぎる」という、直感に反する落とし穴を1つ確認できたことです。自動化が静かに壊れたのを、AIに見つけさせるのような「今日更新されたか」の固定判定と組み合わせるなら、更新頻度が一定でない相手だけ、この記事の指示文5の形に差し替えるという使い分けができます。
毎日ひとりでに回すなら、毎日決まった時刻にAIを動かすの形に載せて、言い直し方の2つ目（黄信号つき）を保存版にするのがおすすめです。いきなり赤信号にせず、余裕が少なくなった時点で気づけます。
監視対象がもっと増えて、種類も増えてきたら、あとから足した監視項目、古い記録まで巻き込むかも合わせて確認してください。あちらは「記録そのものが無い項目」、この記事は「記録はあるが頻度がばらばらな複数の相手」という、隣り合う別の落とし穴です。
見張る相手が1つで、正常な間隔がもともと決まっている場合は、止まったフラグを自動で解除するのほうが近い形です。あちらでは「6時間経ったら異常とみなす」という固定の閾値を明示した版が正しく働きました。同じ「固定の閾値」でも、相手が1つで正常な間隔が決まっているか、相手ごとに正常な間隔が違うかで、向き不向きが逆になります。
⚠️ 今回試したのは3系統・10回という小さな規模です。監視対象が10件・20件と増えたときに、AIが相手ごとの基準を毎回一貫して計算し続けられるかは、まだ確かめていません。
📌 この記事の実測は、架空の更新履歴3系統・全10回（言い直し方の追加確認2種を含めると全14回）です。判定はすべて生の回答を人が読んで確定し、docs/evidence/flat-threshold-misfires.md に全文置いてあります。