自社の判断再現の検証パイプラインでは、大量の会話ペアを抽出する処理を長時間バックグラウンドで走らせる。ある回で、通信経路が切れているにもかかわらず、処理全体が「件数ゼロの正常終了」として完走していたことが分かった。この記事はその経緯と直し方をまとめる。
この記事で分かること
- 通信が切れているのに、なぜ処理が例外を出さず完走してしまったか
- 空の結果が後続の工程へそのまま流れてしまう理由
- 「正常終了」の判定を終了コードだけに頼らないための直し方
この記事で分からないこと(正直に書く)
- 同種の構造がほかのバッチ処理にも残っていないかは、横断で洗い直していない
- 直した後の較正を、実際に通信を落として確認する形ではまだ1回しか行っていない
通信が切れているのに「正常終了」と表示された
自社の判断再現の検証パイプラインでは、大量の会話ペアを抽出する処理を長時間バックグラウンドで走らせる。ある回では、抽出処理を動かしたまま作業セッションを終了したところ、リモートの推論サーバーへの通信経路(トンネル)がセッションと運命を共にして切れてしまった。ところが処理はエラーにならず、すべての対象データが「DONE n_pairs=0」という、件数だけがゼロの正常終了メッセージを出して終わっていた(出所: 自社の運用記録、確認日2026-09-06)。
空の結果が、そのまま次の工程へ流れた
通信が切れた状態では、抽出処理は判定に使うラベル付けの応答を一件も受け取れない。それでも処理自体は例外を起こさず、件数ゼロのまま完走したことになっていた。後続の工程はその空の結果を疑わずに受け取り、空のファイルを無言で書き、選定処理も空のデータで前回の結果を上書きしてしまった。ログだけを見ると全工程が完走したようにしか見えない(出所: 自社の運用記録、確認日2026-09-06)。
なぜ気づけなかったか
「正常終了」を判定する基準が、終了コードとログの文言だけだったことが原因である。前段の処理では候補データに数百件のヒットが出ていたにもかかわらず、後段の件数がゼロになるという矛盾を、どの工程も検査していなかった。通信が切れても処理自体はプログラムとして最後まで走り切るため、壊れているのに200を返す、という故障の形の一種として現れていた(出所: 自社の運用記録、確認日2026-09-06)。
どう直したか
2026-09に4点を直した。抽出処理の冒頭で推論サーバーへの疎通を確認し失敗していればその場で止め、前段でヒットが出ているのに後段の件数がゼロという組み合わせを異常として扱い後続へ進ませず、通信経路をOSのサービスとして常駐させ作業セッションの終了に道連れで切れないようにし、再実行時は空のまま残ったファイルを消してから走らせるようにした(出所: 自社の運用記録、確認日2026-09-06)。
検査に何を書けば次は見つかるか
完走したかどうかは、終了コードではなく数字の整合で見る。前段のヒット件数がゼロより大きいのに後段の件数がゼロであれば、それは正常な「該当なし」ではなく異常である。バックグラウンドで長時間動く処理ほど、依存している通信経路がどの寿命に紐づいているかを最初に確認しておく価値がある。
同じ「見張る側は健全だと言い続けていた」型の事故は、疎通は健全なのに全リクエストが失敗していた記事や、システム切替で書き込みだけが静かに消えた記事でも扱っている。
自社の検証パイプライン・運用監視について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. 何が起きていたのか
会話ペアを抽出する処理を動かしたまま作業セッションを終了したところ、通信経路がセッションと一緒に切れ、抽出処理は結果を一件も受け取れないまま「件数ゼロ」の正常終了メッセージを出して完走していた。
Q2. なぜエラーにならなかったのか
通信が切れても処理自体はプログラムとして最後まで走り切る作りだったため、例外は発生せず、件数がゼロという形でしか異常が現れなかった。
Q3. 後続の工程はどうなったか
空の結果をそのまま受け取り、空のファイルを無言で書き、選定処理も空のデータで前回の結果を上書きした。ログだけを見ると全工程が完走したように見えた。
Q4. どう直したのか
処理の冒頭で通信の疎通を確認して失敗時は即座に止めること、前段にヒットがあるのに後段の件数がゼロという組み合わせを異常として扱うこと、通信経路を作業セッションに依存しない形で常駐させることの3点を直した。