AIの使い方
これで何ができるか
複数の処理を1つの指示で見張る記事は、頻度が5倍違う2つの処理（1日4〜8回と1日1〜2回）を1本のログに混ぜて試しました。「処理ごとに計算して」と頼めば、どちらが止まっても正しく見つかります。ただし、あの記事は処理が2本まで・頻度差が5倍までという条件でした。
この記事は、処理を4本（P1〜P4）に増やし、頻度差を最大約17倍まで広げて、同じ頼み方がまだ崩れないかを確かめました。P1〜P4のどれか1本だけを4日間止める総当たり4パターンを用意しました。加えて、全処理が正常な構成（誤報ゼロの確認）も用意し、同じ指示文で各2回試しました。
- 「処理ごとに、その処理自身の記録から目安を計算して」と頼むと、止めたのがP1〜P4のどれであっても結果は同じでした。10回中10回、停止4日間を完全に名指ししています
- 全処理が正常な構成でも、2回とも誤報なく「該当なし」と答えました
- 一方、「日ごとに合算して」と頼むと、最も頻度の低いP1の停止は2回とも見逃しました。処理が2本から4本に増え、P1の割合が全体の合計に対してさらに小さくなった分、見逃しは前よりも起きやすい形になっています
前提
| かかる時間 | 20分 |
| 費用 | 無料。無料のチャットAIで足ります |
| 必要なもの | 複数の定期実行の、実行時刻が分かる記録（GitHub Actionsの実行履歴・ログファイルのタイムスタンプなど） |
| プログラミング | 不要。実行時刻の一覧をそのまま貼るだけです |
材料は、架空の処理P1〜P4の実行時刻を1本にまとめたログです。どちらも21日間（2026-09-01〜09-21）ぶんで、1行に処理名が書かれています。
- P1＝1日1〜2回（もっとも少ない）
- P2＝1日4〜8回
- P3＝1日10〜15回
- P4＝1日20〜30回（もっとも多い。P1の約17倍）
5つの構成を用意しました。
- P1だけ停止・P2だけ停止・P3だけ停止・P4だけ停止・全処理が正常の5パターン
- 停止させる構成は、対象の処理だけ09-10〜09-13の4日間を0件にしました
- 止めない構成は、全期間とも0件の日がありません
AIへの頼み方
1. 処理ごとに計算させる（もっとも少ないP1が停止）
先行記事で効いた頼み方を、4本に増やしたログにそのまま使います。
上に、P1〜P4の実行時刻が混ざった21日分のログ（約960行）を貼りました。もっとも頻度の低いP1（1日1〜2回）が停止した構成で2回試した結果です。
1回目は「該当あり：P1のみ（2026-09-10〜09-13の4日間、各0回）」。P1の目安を約1.2回/日と計算し、4日間を表で名指ししました。P2・P3・P4は「極端に少ない日はありません」でした。2回目も同じく、P1の4日間を完全に名指し。「P1は他の17日は毎日1〜2回動いていて、09-14の23:59の記録で再開しています」と根拠も添えました。
2. もっとも多いP4が停止した場合でも試す
今度は、もっとも頻度の高いP4（1日20〜30回）が停止し、他の3処理が正常な構成で、同じ指示文を2回試しました。
1回目は「該当あり：P4の4日間だけです」。P4の目安を「中央値は約27」と計算し、4日間を名指し。「P1・P2・P3は該当なし」でした。2回目も同じく、P4の4日間を完全に名指し。「同じ期間にP3は通常どおり動いています。P4だけが止まっていたことになります」と、他の処理との違いも自分から言葉にしました。
3. 残りの2パターンと、全処理が正常な構成も試す
同じ指示文を、P2だけ停止・P3だけ停止・全処理が正常、の3構成でも各2回試しました。
P2だけ停止した2回は、両方とも「該当あり：process=P2のみ」で4日間を正しく名指し。P3だけ停止した2回も、両方とも「該当あり：P3だけです」で4日間を正しく名指ししました。P1・P2・P4（またはP1・P2・P3・P4のうち停止していない3処理）への誤報は、この2構成の4回を通じて0件でした。
全処理が正常な構成（どの処理も09-10〜09-13を含む全期間で0件の日が無い版）では、2回とも「該当なし」でした。
- 1回目:「各処理で、自身の目安の半分を明確に下回る日は見当たりませんでした」
- 2回目:「どの処理にも0回の日や、自身の目安と比べて極端に少ない日はありませんでした」
止めたのがP1〜P4のどれであっても、10回中10回、停止4日間を完全に名指ししました。頻度が最大約17倍違う4つの処理が同じログに混ざっていても、どの処理の目安も混ざらず、誤報もありませんでした。
なぜ、処理が4本・頻度差17倍に広がっても食われなかったのか
10回の返りはすべて、処理ごとに別々の目安（合計や1日あたりの回数）を自分から計算していました。指示文がもともと「ログ全体」ではなく「その処理自身の記録から」と名指ししています。そのため、計算の単位が処理名で区切られたままだったのです。先行記事が2本のときに確かめた理屈が、4本・頻度差17倍に広げても同じ形で働いていました。
うまくいかないときの言い直し方
「処理ごとに」を外すと、もっとも少ない処理の停止はさらに見えなくなる
同じログ（P1が停止した構成）に、「処理ごとに」という指定を外し、「日ごとの合計」で極端に少ない日を探す聞き方に変えました。
2回とも「該当なし」でした。1回目は「ふだんは45前後で、全体は37〜53回の範囲に収まっています。最も少ない9/10(37回)でも、他の日の最小である9/13と9/18(39回)と大差なく、極端に少ない日とは言えません」。2回目も同じく、9/10の37回を「ほかの日と比べて極端に少ないとは言えません」としています。
→ 原因は先行記事と同じ、合算という作業そのものです。P1〜P4を合計すると1日あたり約45回になります。P1の1〜2回が消えても、合計は45回から37〜39回へ下がるだけで、ふだんの揺れの範囲に収まってしまいます。処理が2本から4本に増えた分、停止した処理（P1）が合計に占める割合はさらに小さくなりました（約45回のうちの1〜2回）。合算では、前よりも見つけにくくなっています。直すのは、合算をやめて「処理ごと」に戻すことです（指示文1〜3）。
応用・次の一手
| 構成 | 処理ごとに計算 | 日ごとに合算 |
|---|---|---|
| P1(最少)だけ停止 | 2/2（正しく名指し） | 0/2（見逃し） |
| P2だけ停止 | 2/2（正しく名指し） | 未測定 |
| P3だけ停止 | 2/2（正しく名指し） | 未測定 |
| P4(最多)だけ停止 | 2/2（正しく名指し） | 未測定 |
| 全処理が正常 | 2/2（誤報なし） | 未測定 |
通知やIssue登録につなげるなら、処理ごとの判定を省略せずに書かせたほうが扱いやすくなります。先行記事が確かめた言い直しが、そのまま使えます。
実務に載せるなら、次の順番がおすすめです。
- 指示文1〜3の形で、処理ごとの判定を省略せずに出させる
- 「該当あり」が返った処理だけ、自動化が静かに壊れたのを、AIに見つけさせる記事と同じ要領でGitHubのIssueを立てる
- 更新停止の異常判定は一律にしない記事は、別の軸（監視対象の更新頻度）を確かめています。監視対象を3→20系統に増やしても判定は崩れませんでした。処理数の軸・頻度差の軸・更新頻度の軸は、それぞれ別に確かめておくと安心です
⚠️ この結果は、架空の処理4本・計12回の実測です。「処理が何本に増えても、頻度差がどこまで広がっても崩れない」と一般化しないでください。試したのは、次の範囲までです。
- 処理は4本まで。6本以上に増やす場合は試していません
- 停止したのは常に1本だけです。2本以上が同時に止まる場合は試していません（先行記事の宿題の一部も、まだ残っています）
- 頻度の差は最大約17倍（1〜2回と20〜30回）まで。それ以上に差が開く組み合わせは試していません
- 停止は常に4日間・同じ日付（09-10〜09-13）でした。停止の長さや日付がずれる場合は試していません
今回の生の返りと機械照合は docs/evidence/four-process-log-keeps-each-own-baseline.md に全文置いてあります。