長時間ジョブをチャット監視する方法――終了条件を先に決める契約設計

ベンチマークや移行作業を「10分おきに見てて」と頼むとき、見張り役まで終わらなくなるのは困ります。某所ラボでは、見張りを常駐ではなく、終了条件つきの契約として扱っています。

読み終えるころには、一時的な長時間ジョブに対して、何を先に決めれば安全にチャット監視を頼めるか、そしていつ見張りを終えるべきかを判断できます。

これは「ラボを支える小さな道具たち」第2期の4つ目の道具です。恒常的なシステム監視を置き換えるものではありません。画面から離れたい一時作業だけを、期限つきで引き受けるための仕組みです。

終わらない見張りは、一時作業には重すぎます

長時間ジョブでは、完走するまで進捗を知りたい一方、誰かが画面に張り付くのも、監視処理だけが無期限に動くのも避けたいところです。

そこで私は、依頼を受けた時点で「何を、どの間隔で、どこまで見て、どの条件で終えるか」を宣言する形にしました。見張りの目的は、異常を検知することだけではありません。不要になったら確実に抜けることも、同じくらい重要です。

この仕組みは3つ目を選びます。常時の健全性監視は別の仕組みに任せ、ここでは一回限りの作業に限定します。

依頼時に5項目を宣言すると、見張りの責任範囲が決まります

契約には、次の5項目を必ず入れます。

「10分おきに見てて」は、6段階の間隔プリセットから10分を選ぶ依頼です。ただし、間隔だけでは契約になりません。終了条件と異常時の権限が空いたままでは、報告はできても、どこで責任を終えるかが決まらないためです。

図1を、日常の依頼から終了までの構成図として置きます。

図1で重要なのは、継続中の確認より先に終了時の出口が決まっている点です。変化がない状態は続行ですが、契約の外まで続ける理由にはなりません。

確認結果を3つに分けると、待つべき時と調べる時が混ざりません

確認1回分は、完了数、総数、完了したか、異常かという4つを読めるひとまとまりのデータとして返します。追加の項目があれば、そのまま報告に載せます。

応答なし、想定外の形式、時間切れといった確認そのものの失敗も、異常として扱います。また、総数が前回から変わった場合は別の作業が始まったとみなし、それまでの進捗記録をリセットします。

異常時に待たずに調べる判断と、状況で見張り方を変える考え方は、見張り役をAIの判断へ寄せた記録にも通じます。ただし、この回で優先したのは判断を増やすことではなく、判断の出口を最初に固定することです。

間隔は固定せず、進捗と完了見込みで伸び縮みします

既定の初期値は15分です。依頼で10分を指定すれば10分から始めますが、以後の間隔は状況に応じて変わります。

無進捗が閾値を超えても対象が生きていれば、間隔を1段短くして深掘りします。完了見込みが3分、20分、40分以内へ近づく場合も、それぞれ1分、5分、10分へ短縮します。今より短くなる場合だけ切り替えるため、すでに細かく見ている契約を無意味に変えません。

反対に、3回連続で安定して進み、完了見込みがまだ遠ければ、間隔を1段伸ばします。上限は1時間で、夜間や長丁場向けです。それ以外は現在の間隔を維持します。

図2は、この伸縮の判断を表にしたものです。

図2の「3回連続で安定」は、報告を減らすためだけの条件ではありません。見張りの密度を下げてもよい状態を、単発の印象ではなく連続した進捗で判断するための条件です。

無進捗の既定値は1800秒、つまり30分です。1単位が最大22分かかる見込みのベンチマークなら、1800〜2100秒あたりを設定します。単位作業の上限に余裕を足して決めるので、遅いだけの正常状態を異常として急がせにくくなります。

最小構成は、依頼文で5項目を埋めることです

特殊な監視基盤がなくても、まずは依頼を契約文として残せば、役割の境界を作れます。対象は種類ごとに固定せず、依頼ごとに引数として渡す設計にしました。過去に対象を固定で書き込んだ反省があるためです。

たとえば、ベンチマークの完走待ちなら、対象名、10分という間隔、報告先、異常時は記録だけ、完了時に終了という条件を一緒に渡します。資源枯渇の兆候はその場だけの数字ではなく、積み上げの値として報告します。

この方式を選ぶべきなのは、作業単位で終わりを定義できる人です。反対に、システム全体を恒常的に守りたいなら、ここへ寄せず、既存の恒常監視を整えるほうが適しています。

生存判定は、完璧な証明ではありません

対象が生きているかどうかは、プロセスの存在確認に頼っています。番号が使い回されれば、生存と誤判定する可能性は残ります。深掘りするときは、プロセスの中身まで見る前提です。

隔離された実行環境では生存判定そのものができず、判定不能として報告する場合もあります。ファイルがあることを生存の証明にしない考え方は、プロセスを見る死活監視の記録で扱いました。

また、同じ名前の見張りを同時に複数動かすと書き込みが競合します。並行して頼むなら、見張りごとに別の名前が必要です。数時間を超える耐久については、この待ち方式だけを証跡にせず、記録を併用します。

注意: 定期処理から稼働中の仕組みへ短い状態確認を直接差し込む方式は、今の待ち方式より堅牢になり得ます。ただし新しい定期処理の追加には承認と軽い申告が必要なため、まだ着手していません。

コピペで再現

次の依頼文を、そのまま一時監視を頼むときの最小形として使えます。角括弧の中だけを、自分の作業に合わせて置き換えてください。

[対象] を [10分] おきに見張ってください。
報告先: [チャット / 記録 / 両方]
無進捗判定: [1800秒]
異常時の権限: [記録するだけ / 再開してよい / 止めるだけ]
終了条件: [全部終わったら / 資源の下限に達したら / 私が止めろと言ったら]
毎回の報告: 完了数・総数、対象が生きているか、資源枯渇の兆候
確認結果は「変化なし・続行」「異常」「全部完了」に分けてください。
異常は次の確認を待たずに報告し、全部完了なら報告して見張りを終了してください。

前提条件: 対象ごとに、完了数・総数・完了・異常を読める確認手段があること。無進捗の秒数は、1単位にかかる時間の上限へ余裕を足して決めること。恒常監視ではなく、一時的な長時間ジョブとして使うこと。

ハマり所: 同じ名前の見張りを同時に動かさないこと。プロセスの存在だけでは生存を完全には証明できないこと。隔離された環境では判定不能になることがあること。数時間を超える作業は、別の記録も併用すること。

この契約は、頼めば宣言した間隔で確認し、条件が来れば終える状態で使えます。次はどんな長時間ジョブを、この期限つきの見張りに託すでしょうか。