配布資料 50事例 #10: SSH 切断が、デプロイとその監視を沈黙させた

「AI が最後まで見届ける」という前提を捨てるまでに、4回失敗しました。 同じ根っこの失敗が、形を変えて何度も出てくる典型例です。

何が起きたか

10〜25分かかる staging・本番デプロイをめぐって、同種の失敗が反復しました。

1. 「デプロイ完了しても待機が続く」「未完了なのに完了扱いになる」。通知メール送信のタイムアウト未設定による無限ハング、リモート実行ツールの60秒タイムアウトをデプロイ時間が超過、そして「処理中」と「ハング」を区別する完了マーカーの不在が重なっていました
2. 監視用に張った長時間 SSH（完了ファイルを待つ while ループ）が、無出力時間中の idle 切断で無言のまま死に、完了通知が届きませんでした。 同一セッションで2回連続しました
3. 導入した watchdog のしきい値が短すぎ、ビルドの正常な無音区間で誤発火してデプロイプロセス自体を kill しました。二次事故です
4. 対策が不徹底のまま直接 nohup で起動したデプロイが、接続断で消失しました

なぜ起きたのか

表面的には、個々のタイムアウトと idle 切断です。

構造は一つです。 長時間処理の生存を、切断に弱い同期 SSH セッションの生存に依存させていました。

接続と処理のライフサイクルが分離されておらず、完了状態が接続の外——永続マーカー——に記録されていませんでした。

そこから生まれたルール

「デプロイは非同期起動スクリプトと状態確認スクリプトのペアでのみ実行する」

非同期起動スクリプトは、セッションから切り離して起動し、終了トラップで完了マーカーを必ず書き、ログ停滞の watchdog を持ちます。 そして「SSH ワンショットの直接実行・長時間 SSH トンネル監視・バックグラウンド while sleep 監視は禁止」。

「監視は短時間接続のポーリング（1〜2秒で接続・切断を60〜90秒周期）で行う」

watchdog のしきい値は、誤発火の事故を受けて実測ベースの15分に是正しました。

どう機械に守らせたか

①スクリプト側の構造対策が主体になります。非同期起動、trap で必ず書かれる完了マーカー（exit code 付き）、heartbeat 付きの watchdog ②デプロイスクリプトの起動を検知した PreToolUse フックが、「監視はマーカーポーリングで」という正しいパターンを毎回注入します

持ち帰るなら

AI にインフラ操作を任せるときの鉄則は2つだと思っています。

AI のセッションが死んでも処理は死なない。処理の状態はいつでも外から分かる。

長時間処理は必ずデタッチ起動と永続マーカーにして、AI には「マーカーを短時間接続で見に行く」動作だけをさせます。 watchdog を入れるなら、正常系の最長無音時間を実測してから閾値を決めてください。