現況:「動いているはず」の作業枠が実は9時間前に止まっていた
2026年9月12日時点で、うちでは複数のAIモデルに作業を割り振り、それぞれの空き状況を見ながら次の仕事を回しています。ある日、空き枠を確認したところ「1件が実行中」と表示されました。開始時刻を見ると、もう9時間近く経過しています。長くかかる作業もありますが、開始直後からログが一度も更新されていないのは不自然です。
そこで、止める前にまずその作業の記録をたどってみることにしました。すると意外な事実が出てきます。その作業は9時間前、必要な残高が足りずにたった数秒で失敗し、とっくに終わっていたのです。にもかかわらず、空き枠の管理の仕組みはそれを「実行中」と数えていました。
対応:原因はプロセスID(pid)の使い回しだった
なぜ終わった作業が「実行中」と数えられていたのか。調べてみると、空き枠の管理はその作業に割り当てられたプロセスID(pid、OSがプロセスに振る番号)が今も存在するかどうかだけを見て、生死を判定していました。作業自体は9時間前に終了していたのですが、OSは空いた番号を律儀に再利用します。たまたま同じ番号が、診断の27分前に起動したばかりの、まったく別の常駐サービスに割り当て直されていました。つまり「番号が存在する」という一点だけを頼りにした結果、別人に成りすまされた幽霊の枠が生まれていたわけです。
これはただの表示ミスでは済みません。もし「9時間ログが無いから止まっているのだろう」と判断してその番号のプロセスを強制終了していたら、実際に殺してしまうのは元の作業ではなく、たまたま同じ番号を引き継いだ別サービスです。無関係な処理を巻き添えにしかねませんでした。
対応としては、生死判定の材料を「番号の存在」だけに頼るのをやめました。作業が正常に終わった/失敗した際に残す完了記録ファイルの有無と、その番号のプロセスが今どんなコマンド名で動いているかを照合し、両方が一致して初めて「実行中」と扱うように仕組みを直しました。これで、作業を割り振る側の数え方では、番号だけが使い回された偽の「実行中」を除外できるようになりました(2026年9月12日時点)。ただ、同じ弱点は作業を起動する側の数え方にも残っていて、2日後の9月14日に同じ型の誤表示がまた出て作業の投入を止めてしまい、翌15日にそちらにも同じ照合を入れました。
結果:幽霊枠が1つ塞いでいた空きを取り戻し、判断の型を残した
修正後に確認すると、作業を割り振る側の数え方では、幽霊化していた1枠分が正しく「空き」として数えられるようになりました。なお、この日はその枠を使うAIサービスの残高そのものが尽きていたため、空いた枠に次の作業が実際に入ったのは、料金の払い方を定額に切り替えた同じ日の夜からです。
この一件からの教訓は次の2つです。
- 「番号が存在する」ことと「その処理が生きている」ことは別物。 OSは終了したプロセスの番号を惜しみなく再利用します。存在チェックだけの生死判定は、時間が経つほど誤判定の確率が上がる構造的な弱点だと考えたほうがいいです。
- 「長時間ログが無い=動いている」と決めつける前に、まず完了記録とコマンド名の実測をする。 この日から、特に、その判定結果をもとに強制終了のような後戻りしにくい操作をする場合は、思い込みで実行せず先に正体を確認する一手間を惜しまないようにしています。
裏方の仕組みが自分自身の勘違いに気づいて直す、というのも地味ですがAI秘書の大事な役割の一つだと思っています。
こうした地道な運用の穴を、人が気づく前に埋めたい方へ AI秘書は、こうした誤判定のような細かい運用の穴も、見つけたら止める前に原因まで確かめて直します。導入のご相談はお気軽にどうぞ。 ラポ秘書に無料で相談する