見張りは動いたのに間に合わなかった日、連打防止が正常な再起動を止めた

「自動で直す仕組みが動いたのに、直っていなかった」。AI秘書の画像生成機で、10月4日に起きた話です。

何が起きたか

ラポルタでは、AI秘書の画像・動画生成を、専用のGPUマシンで動かしています。このマシンには、メモリの使用量(commit)が上限に近づくと、生成ソフトを自動で再起動する「見張り」を付けています。生成ソフトがメモリを抱えたまま居座り、マシンごと応答しなくなる事故が続いたためです。この見張りは、同じ日の昼に2回続けて枯渇したのを受けて、14時台に入れたばかりでした。

10月4日午後の記録(運用ログの時刻)は、次のとおりでした。

15:17の記録には、commit_guard_skipped(理由 cooldown)、生成ソフトのメモリ使用量(commit)49,978MB(上限40,000MB)と残っていました。見張りは異常を見つけていたのに、行動しなかったことになります。

原因は「連打防止」の規則だった

見張りには、再起動を連打しないための待機時間(クールダウン、600秒)があります。再起動しても直らないマシンを、延々と再起動し続けないための安全装置です。

ただ、この規則は「再起動が空振りした時」を想定して作ったものでした。今回は逆で、15:08の再起動は成功し、ジョブも1件完走しています。ジョブが動けば、生成ソフトはまたメモリを抱え始めます。再び上限に近づいたのは正当な新しい異常なのに、規則は「10分以内の再起動」としか見ず、見送りました。

つまり、連打防止が、成功した後の正常な再起動のかけ直しまで止めていました。

直し方: 規則を効く場面だけに絞る

直したのは、クールダウンを「本当に連打になりそうな場面」だけに限定することでした。

• 前回の再起動が失敗した時は、これまでどおり待つ
• 再起動後にジョブが0件の時も、これまでどおり待つ(何も動いていないのに再び上限を超えるなら、別の問題があるため)
• 前回の再起動が成功し、その後にジョブが1件以上終わっていれば、待機は60秒に短縮して再起動のかけ直しを許す

あわせて、再起動の記録に「再起動前後のメモリ値」が残るようにしました。15:08の再起動の記録は、再起動前の値が空(取得不能)になっており、状況を後から追うのに手間がかかったためです。

テストは4件を追加し、見張りを含むジョブ振り分けプログラムのテストは1,070件が通っています。追加したのは、次の4つです。

1. 成功した再起動のあとジョブが終わっていれば、長い待機を無視して再起動をかけ直す
2. ジョブが0件なら、待機が効く
3. 前回の再起動が失敗していたなら、待機が効く
4. 再起動の記録に前後の数値が入り、取れない時は直前値で補う

学び

1. 安全装置の「連打防止」は、成功したあとの正常な再起動のかけ直しまで止めうる。 防ぎたい失敗(空振りの連打)と、止めたくない動き(成功後の再起動のかけ直し)を、条件で分けて書く必要がありました。
2. 「見張りが動いた」と「見張りが必要な時に動いた」は別物。 再起動が成功した日に、見張りのテストは通っていました。足りなかったのは、直後に再起動をかけ直せるかを確かめるテストです。テストは後者を書きます。
3. 直した本人とは別のAI(評価役)が検収してから閉じる。 実装した側は「動いた」記録を信じがちです。別の目で、15:17の見送りの記録から読み直してもらう運用にしています。

補足: 数字の出どころと、その後

この記事の時刻と数字は、運用ログ(job_succeeded、commit_guard_skipped、commit_guard_restart、job_failed の各記録)と、是正のコミットから確認しています。2026年10月26日時点の内容です。

ログ上でホスト枯渇と判定されたのは、是正を入れた15:35までに14:27、14:42、15:22の3回でした。是正後も同じ日の16時台以降に枯渇は再発しており、見張りより先に次のジョブが始まってしまう別の穴に、その日の夕方以降も追加の直しを入れています。見張りはあくまで応急の対策で、生成ソフトがメモリを抱え込むこと自体は別の課題として扱っています。

こうした休日の障害対応まで含めて、ラポルタではAI秘書「ラポ秘書」を運用しています。

AIに任せたあとの「止まる場面」まで設計しませんか 導入して終わりではなく、今回のような自動復旧の穴や、安全装置どうしの干渉まで含めて、止まったときの備えを一緒に組みます。ラポ秘書がどんな場面で役立つか、無料相談でお気軽にご確認ください。 ラポ秘書に無料で相談する