AI駆動開発の実運用ノート

本編の目次 › 第5部 デプロイ・運用・移植 › デプロイフローの4世代

AI駆動開発の実運用ノート No.116SSHが切れてデプロイも監視も沈黙した

AI と併走してチケット販売サービスを本番運用まで到達させた記録を、そのまま文字に残しています。今回は第5部「デプロイ・運用・移植」から、「デプロイフローの4世代」のお話です。

失敗事例SSH 切断がデプロイと監視を沈黙させた

AI のセッションが死んでも処理は死なない設計にする
事故

長時間処理を SSH 接続の生存に依存させ、無言切断で完了通知が届かない事象が反復

根本原因

接続と処理のライフサイクル未分離。完了状態が接続の外に記録されていない

ルール

デタッチ起動 + 終了トラップで必ず書かれる完了マーカー + 実測ベースの見張り

強制する仕組み

監視は短時間接続の反復ポーリングのみ。長時間トンネル監視は禁止 + 起動時に正しい型を自動注入

第2世代から第3世代への境目です。

AIのセッションからSSHでデプロイを起動していたところ、接続が切れた瞬間に、デプロイも監視もまるごと沈黙しました。処理が宙ぶらりんになります。

だから——AIのセッションが死んでも、処理は死なない設計にします。

起動したらセッションから切り離して別建てで走らせます。 完了はAIが見張るのではなく、置かれた「完了マーカー」を確認しに行きます。

つまり「AIが最後まで見届ける」という前提を捨てました。 人が席を外しても回る仕組みは、ここが起点になっています。顛末は事例10に。

つづく