止まったフラグを自動で解除する——計算までさせても、8回中0回しか自分からは進めなかった

これで何ができるか

二重起動を防ぐための「実行中」フラグが、異常終了のせいで立ちっぱなしになったとき、自動でそれを解除して処理を再開させる頼み方です。プログラミングは要りません。

毎日決まった時刻にAIを動かすでは、「同じ処理が複数回動いても中身が壊れない」ように前回から変わっていなければ何もしない、という多重化の指定を紹介しました。今回はその逆方向です。「実行中」フラグで二重起動そのものを防ぐ作りにしていると、フラグを立てたまま処理が異常終了した場合、次回以降ずっと「前回がまだ実行中」とみなして動かなくなります。架空の実行記録・のべ22回の実測で、この壊れ方を自分で直させる頼み方を確かめました。

結論から言うと、AIは異常を正しく見抜きます。ただし、見抜いたうえで「進める」ではなく「待つ・調査すべき」と答えます。人が見ている手動作業ならこれで正解ですが、誰も見ていない自動化では、この「調査すべき」という結論そのものが、処理を永久に止める合図になります。

前提

• この記事は「フラグが異常終了で立ちっぱなしになる」場面に絞っています。同じ処理が複数回動いても壊れないようにする設計（べき等性）は毎日決まった時刻にAIを動かすに、人が手動で処理した結果を自動側に書き戻し忘れる場面は手動で処理した続きを自動に伝えるにあります
• 実測に使ったのは架空の実行記録で、実在のシステム名は含みません

AIへの頼み方

1. まず素朴に判断させる — 4回中3回は「待つ」、残り1回も「進める」ではなかった

架空の「実行記録」を2本用意しました。どちらも「状態：実行中」のまま、本来の所要時間をはるかに超えて止まっています。

【処理名】毎朝の記事収集
【状態】実行中
【開始時刻】2026-09-02 07:30
【前回正常終了】2026-09-01 07:28
【今日の日時】2026-09-05 07:30

（もう1本は「毎晩のデータバックアップ」で、開始から30時間経過した記録です）

まず、指定なしの素朴な聞き方です。

材料2本×各2回＝4回のうち3回は「待つべき」と判断し、残り1回も「進めるべきではなく、調査が必要」と判断しました。理由づけは正確です——「開始から3日以上『実行中』のステータスが更新されていません。通常の記事収集処理が3日以上かかることは考えにくく、これは異常です」。異常だと正しく見抜いたうえで、4回とも「進める」という結論にはなりませんでした。

2. 経過時間を計算させても、結果は変わらなかった

「経過時間を数字で見せれば、判断が変わるかもしれない」と考え、計算を先にさせました。

材料2本×各2回＝4回とも、経過時間を正しく計算した（72時間・30時間）うえで、4回とも「待つべきではなく、調査・対応すべき」と答えました。「進めます」と言い切った回は0回です。1と2を合わせた8回を通じて、自分から「今回の処理を進める」と判定した回は1件もありませんでした。人が読む報告としては模範解答ですが、次に処理を進める人間がいない自動化の中では、この「調査すべき」がそのまま「止まったまま」になります。

3. 「6時間経ったら進めて」と閾値を明示する — 4回とも正しく進めた

受け身の判断をやめさせ、具体的な閾値と、それを超えたときにすることを指示しました。

材料2本×各2回＝4回とも「今回の処理を進めるべき」と判定しました。「6時間の閾値に対して72時間も経過しており、大幅に超過しています」と経過時間もきちんと比較しています。

4. 本当にまだ実行中のときは、ちゃんと「待つ」と言えるか

閾値を明示すると常に「進める」と答えるだけの雑な判定になっていないかを確かめるため、開始から2時間しか経っていない、本当にまだ実行中の可能性が高い記録も試しました。

同じ指示文・材料だけ差し替えて2回試したところ、2回とも「待つべき」と正しく判定しました。「経過時間が2時間であり、判定基準の『6時間以上』に達していません。そのため……異常終了とは判断できません」。閾値を明示しても、条件を満たさない場面ではちゃんと待つ側に倒れます。

5. 進める場合は、記録も正しく書き直せるか

自動化として使うには、進めると判断したときに実行記録そのものを更新できないと意味がありません。書き戻しも指示に加えました。

材料2本×各2回＝4回とも「進める」と判定し、4回とも開始時刻を「今日の日時」の値に正しく更新しました。しかも「前回正常終了」の欄は、まだ今回の処理が完了していないので更新せず、直近の正常終了記録をそのまま残す——という細かい判断も4回とも正しくできていました。

6. 全部乗せの推奨版

3・4・5を1つにまとめた、実際にコピーして使える版です。

材料2本×各1回＝2回とも正しく「進める」と判定し、書き戻しも正しく行われました。3〜6を合わせた材料2本×計10回・のべ150件を通じて、判定・書き戻しとも誤りは0件でした。

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

すでに3日間、止まったままだった

もし1・2の素朴な指示文のまま運用していて、実際に3日間止まっているのに気づいたら、その指示文自体を見せて直させてください。

独立した会話2回とも、「開始時刻から◯時間以上経過していたら異常終了とみなして進める」という、3の指示文と同じ形の直し方を自分から提案しました。閾値は「24時間」（毎朝の処理という前提から）で、6時間より緩めでしたが、考え方は同じです。自動化の外から壊れ方を説明して直させれば、直し方そのものはAIが思いつきます。先に完璧な指示文を書こうとするより、動かしてみて止まったら、その状況を見せて直すほうが早いというのは、監視の項目をあとから増やすでも同じでした。

応用・次の一手

この記事の実測でいちばん確かなのは、AIは「実行中フラグが3日も更新されていない」という異常そのものは、8回とも正確に見抜いていたことです。壊れていません。壊れていたのは、その先の「では、どうするか」という判断が、指示していない限り「調査してください（＝人が見てから決めてください）」の側に寄ることでした。

自動化に人はいません。「調査すべき」という結論は正しい忠告ですが、次にそれを読んで動く人間がいない仕組みの中では、その忠告自体が処理を止め続けます。フラグ方式で二重起動を防ぐなら、「フラグ方式は使うな」ではなく、「経過時間で自動的に無効化する閾値を必ず添える」が、この記事が確かめた対処法です。

⚠️ この実測は、あくまで今回作った架空の実行記録・今回の実測環境での結果です。「AIは異常を検知しても絶対に進めない」という一般化はできません（4回中1回はもともと「進めるべきではなく、調査すべき」という判断そのものは的確でした）。確かなのは、閾値と「進めてよい」という許可を明示した版だけが、10回中10回・本当にまだ実行中の材料でも2回中2回、狙いどおりに動いたという一点です。

📌 この記事の実測は、架空の実行記録2本（開始から3日・30時間経過）に対して、無指定・経過時間を計算させる・6時間の閾値を明示・書き戻しも指示・全部乗せの推奨版の5版を、材料2本×各2回（推奨版のみ各1回）＝計18回・のべ90件、機械照合しました。加えて、本当にまだ実行中（経過2時間）の材料に閾値版を使う確認を2回、すでに止まった状態からの言い直しを独立2回、試しています。「今回の処理を進める」と判定した回は、無指定・計算のみの8回中0回、閾値を明示した10回中10回、まだ実行中の材料では2回中0回（正しい判断）でした。書き戻しの誤りは0件です。⚠️ 実測に使ったAIは、このセッション内で起動した独立プロセス（claude --safe-mode --tools ""。CLAUDE.md・skills・plugins・履歴を全部無効化し、呼び出しごとに完全に独立しています）です。生の回答は docs/evidence/stuck-flag-proceed-verdict.md に全文置いてあり、一般化はせず機械で確認できた件数だけを根拠にしています。