AIの使い方
これで何ができるか
自分の実行ログで停止に気づく記事は、「自分の記録から計算したふだんの目安」と比べさせる頼み方を確かめました。定期実行の停止を、見逃しも誤報もなく見つけられています。ただし、あの記事が見張ったのは1つの処理だけでした。
実際の運用では、頻度の違う複数の処理を1つのログにまとめて渡したくなります。この記事は、1日4〜8回動く処理X（多数派）と、1日1〜2回しか動かない処理Y（少数派）を同じログに混ぜ、頼み方を2種類で比べました。
- 「処理ごとに、その処理自身の記録から目安を計算して」と頼むと、止まった処理が多数派でも少数派でも、4回とも停止4日間を完全に名指ししました
- 「日ごとに合算して、ふだんの目安と比べて」と頼むと、多数派(処理X)が止まった回は合計も落ちるので正解しました。しかし少数派(処理Y)が止まった回は、2回とも「該当なし」という見逃しになりました
前提
| かかる時間 | 20分 |
| 費用 | 無料。無料のチャットAIで足ります |
| 必要なもの | 複数の定期実行の、実行時刻が分かる記録（GitHub Actionsの実行履歴・ログファイルのタイムスタンプなど） |
| プログラミング | 不要。実行時刻の一覧をそのまま貼るだけです |
材料は、架空の処理X（1日4〜8回）と処理Y（1日1〜2回）の実行時刻を1本にまとめたログです。どちらも21日間（2026-09-01〜09-21）ぶんで、1行に処理名が書かれています。
- セット1＝多数派の処理Xだけ09-10〜09-13の4日間、本当に実行が0回になった版。処理Yは全期間正常
- セット2＝役割を入れ替えた版。少数派の処理Yだけ09-10〜09-13の4日間が0回で、処理Xは全期間正常
AIへの頼み方
1. 処理ごとに、その処理自身の記録から目安を計算させる（多数派が停止）
先行記事で効いた頼み方を、複数の処理が混ざったログにそのまま使います。
上に、処理X・処理Yの実行時刻が混ざった21日分のログ（131行）を貼りました。多数派の処理Xが停止したセット1で2回試した結果です。
1回目は、処理Xの合計100回・中央値5回/日から「ふだんは4〜8回」と自分で計算しました。09-10〜09-13の4日間は「記録が1件もありません」として、正しく名指ししています。処理Yは「21日間の合計31回、平均約1.5回/日」。「9/10〜9/13も毎日実行されています」と誤報なしでした。2回目も同じく、処理Xの09-10〜09-13を「約4日半にわたって記録がありません」と名指し。処理Yは「極端に少ない日も0回の日もありません」でした。
2. 役割を入れ替えて、少数派が停止した材料でも試す
今度は処理Y（少数派）が停止し、処理Xが正常な材料（セット2）で、同じ指示文を2回試しました。
1回目は「process=Yが2026-09-10〜09-13の4日間、実行回数0件」と正しく名指ししました。処理Xは「合計122回、1日平均約5.8回。最少は4回で、極端に少ない日はありません」でした。2回目も同じく、処理Yの4日間を完全に名指ししています。処理Xは「最少でも4回で、0回の日もない」と誤報なしでした。
止まった処理が多数派(X)か少数派(Y)かにかかわらず、4回とも停止4日間を完全に名指ししました。頻度が5倍近く違う処理X（4〜8回/日）と処理Y（1〜2回/日）が同じログに混ざっていても、どちらの目安も混ざりませんでした。
なぜ、頻度の違いで目安が食われなかったのか
4回の返りはすべて、処理ごとに別々の合計・平均を自分から書いていました。「処理Xの合計は100回」「処理Yの合計は31回」のように、集計そのものを処理名で分けていたのです。指示文がもともと「ログ全体の目安」ではなく「その処理自身の記録から」と名指ししているからです。
うまくいかないときの言い直し方
「処理ごとに」を外して、合算で聞くとどうなるか
同じログに「処理ごとに」という指定を外し、「日ごとの合計」で極端に少ない日を探す聞き方に変えました。まず、多数派の処理Xが停止したセット1です。
2回とも停止4日間を正しく見つけました。1日あたりの合計が「ふだん6〜10回」から「1〜2回」まで落ち込み、合計そのものが目立ったからです。
次に、少数派の処理Yが停止したセット2で、同じ指示文を試しました。
合算では、2回とも「該当なし」でした。1回目は「09-13の4回が最少だが、極端に少ないとは言えない」という判定です。2回目も「09-13が4回で最も少ないが、Xの実行間隔が長い日」として、同じ結論でした。
2回目は返りの最後で「Yは09-10〜09-13の4日間、実行記録がありません」と気づいてはいました。ですが「1日あたりの回数では異常に見えません」として、主たる判定は「該当なし」のままでした。
→ 原因は合算という作業そのものです。処理Xは1日4〜8回動きます。処理Yの1〜2回が消えても、合計はほかの「ふだんの少ない日」(09-04・09-20など)と同じ範囲に収まります。多数派の停止は合計の落ち込みとして見えますが、少数派の停止は多数派の数字に埋もれて見えなくなります。直すのは、合算をやめて「処理ごと」に戻すことです（指示文1・2）。
応用・次の一手
| 指示文 | セット1（多数派Xが停止） | セット2（少数派Yが停止） |
|---|---|---|
| ①②処理ごとに計算 | 2/2（正しく名指し） | 2/2（正しく名指し） |
| ③④日ごとに合算 | 2/2（まぐれで正解） | 0/2（該当なしに見逃し） |
通知やIssue登録につなげるなら、処理ごとの判定を省略せずに書かせたほうが扱いやすくなります。
実務に載せるなら、次の順番がおすすめです。
- 指示文1の形で、処理ごとの判定を省略せずに出させる
- 「該当あり」が返った処理だけ、自動化が静かに壊れたのを、AIに見つけさせる記事と同じ要領でGitHubのIssueを立てる
- 処理を3つ以上に増やすなら、増やした版でも見逃し0になるかを同じ数え方で測り直す
処理が3つ・4つと増えても大丈夫か、確認の仕方も聞いてみました。
返ってきた12項目のうち、次に自分で試すなら優先したいのは次の3点でした。
- 処理数を段階的に増やし（2→3→4→6）、各構成で「1つだけ止める」をすべての処理について1回ずつ試す。止める処理を総当たりにすると、特定の処理だけ見逃す偏りも拾える
- 頻度差を5倍よりもっと広げる。今回通ったのは、差が5倍程度だったからかもしれない
- 全処理が正常なログで、誤報がゼロになることも必ず確認する。見逃しだけ測ると、何でも異常と言う結果でも通ってしまう
更新停止の異常判定は一律にしない記事は、別の軸（監視対象の更新頻度）で3→20系統に増やしても判定が崩れないことを確かめています。処理数を増やす検証にはこちらの数え方も参考になります。
⚠️ この結果は、架空の処理2本・計8回の実測です。「合算すると必ず少数派を見逃す」と一般化しないでください。試したのは、次の範囲までです。
- 処理は2本まで。3本以上を1本のログに混ぜる場合は試していません
- 頻度の差は最大5倍（4〜8回と1〜2回）まで。それ以上に差が開く組み合わせは試していません
- 停止は常に4日間・同じ日付（09-10〜09-13）でした。停止の長さや日付がずれる場合は試していません
今回の生の返りと機械照合は docs/evidence/mixed-log-keeps-each-process-own-baseline.md に全文置いてあります。