無人運用のパイプラインで、エラーを出さずに壊れていた故障が8件。最長は約4か月（未検証の報告）

何が起きたか

筆者（krbrr）は、5つの情報源から記事を集め、ローカルLLM（Ollama）で採点し、上位を改善提案ファイルにする自作のパイプラインを、Claude Codeに作らせ・直させながら毎日無人で回している。Python 3.11とSQLite、定期実行はWindowsタスクスケジューラとPowerShellスクリプトで、筆者が見るのはDiscordの通知と決裁だけである。修正コミットと調査記録から数え直したところ、エラーを出さないまま壊れていた故障のうち、期間まで言えるものが8件あったと筆者は述べている。個人環境でのn=1の記録で、8件のうちClaude Code固有の話は1件だけだとしている。

現場の混乱

筆者が挙げた8件は次のとおりである。日付は筆者の記述による。

1. 依存ライブラリが仮想環境に入っておらず、収集が約10日止まった（2026年5月、開始日は不明）。Discord通知も同じライブラリを読み込んでおり、一緒に止まった。筆者が直近の収集情報を確認するよう頼んで発覚した。なお同じ期間には集計処理のKeyErrorによる別の不具合も重なっており、どこまでが依存起因かは切り分けられていない。
2. 7月15日の日次収集が丸1日欠落した。未実行の検知は48時間で、健全性チェックは6時間ごと。最後の判定時点の経過は46.3時間でPASSとなり、次の判定の前に翌日分が成功して経過がリセットされた。
3. 収集プロセスが途中で落ちた回が2回（7月21日・23日）あった。日次ログ63回分に非0で終わった回はなく、この2回はログに終了行がなかった。
4. 日次バックアップのタスク定義は5月1日にリポジトリへ追加され、開始予定は5月2日だったが、Windowsに登録されておらず、9月3日の初回まで約4か月一度も動いていなかった。
5. 評価に失敗した9件が最長799時間（約33日）放置された。翌日以降は再試行しない構造で、診断コマンドはWARNを出していたが、通知はFAILだけだった。
6. 週次の品質ゲートの通知が8月23日に鳴らなかった。F1は0.526で合格ライン0.7を下回っていた。
7. Claudeデスクトップアプリの定期タスクが、8月30日から9月27日の5回、許可確認で固まった。
8. 評価の前段フィルタ用モデル（qwen2.5:1.5b）が9月21日にOllamaから消え、28日間（9月21日〜10月18日）素通りした。

発見のきっかけはまちまちだった。9月2日の大規模レビュー、レビュー対応中にWARNを読んだこと、翌日に週次ログを読んだことなどである。8件目は、まったく別のエラー（記事本文取得の通信切断）を調べていて偶然見つかった。筆者は、見つかったものしか数えられず、今も見えていない無音の故障があると考えるべきだと書いている。

原因

筆者は、無音になった理由を5つの型に整理している。

• fail-openが「気づかない」も生む（6件目・8件目）。止めない代わりに、恒久的な故障も一過性と同じ扱いで流れた。8件目では「モデルがない」が通信エラーと同じ扱いで1件ごとに3回再試行され、最後は前段フィルタを通さず本評価へ回った。ログには毎日約800行のWARNINGが出たが、Discordには何も届かず、診断コマンドは「Ollamaに接続できるか」しか見ていなかった。
• 起動記録やexit 0は動いた証拠ではない（2・3・4・7件目）。3件目では、収集コマンドが内部で失敗しても終了コード0を返す作りで、プロセスごと消えるとスクリプトが終了コードの分岐まで届かなかった。7件目では、死活監視が定期タスクの最終起動時刻だけを見ており、起動はしているので正常に見えた。その監視役も同じ定期タスクで、同じように止まっていた。
• 通知経路が監視対象と一緒に壊れる（1・6・7件目）。6件目では、通知処理の変数名の誤りによる例外が、週次ループを止めないためのcatchに吸われた。
• 鳴っているのに届かない（5・7・8件目）。7件目では成果物の鮮度警告が約9月12日から毎日届いていたが、案内文が実際の原因（許可確認待ち）を指しておらず、10月3日の調査まで空回りした。
• 閾値と周期の擦れ（2件目）。周期24時間の仕事に48時間の閾値をかけたため、1日だけの欠落は必ずすり抜ける。

7件目の根本原因について、筆者は、環境変数CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1が有効だと許可モードが既定に強制される、という有力仮説までで、挙動が変わった版は特定できていないとしている。8件目のモデルが消えた理由、4件目の定義が登録されなかった理由、1件目の開始日は、記録がなく不明である。

対策

筆者は件ごとに次のように直した。

• 1件目：依存が無くても動くよう計測部分を何もしない版に差し替えられるようにし、日次スクリプトの先頭で依存の整合チェックとimportの試験を行うようにした。診断コマンドに未評価の滞留・連続失敗・止まったままの実行を見る項目を足した。
• 2件目：未実行の閾値を30時間に詰めた。
• 3件目：収集コマンドの終了コードに「0=正常・1=失敗・3=一部失敗」の約束を持たせ、スクリプトは分岐だけを持つ形にした。
• 4件目：9月2日のレビュー後に登録し直し、9月3日5:30に初回が成功した。最新のバックアップファイルが48時間より古ければFAILにする検知を足した。
• 5件目：日次収集のあとに未評価を最大50件だけ拾い直す処理を毎日走らせ、拾えなかった時だけ通知する。
• 6件目：8月24日に修正した。通知を足したら、失敗する入力を与えて本当に鳴るかを1回確かめる運用にした。
• 7件目：10月4日にWindowsタスクスケジューラとclaude -p --permission-prompts none（確認が要る操作は待たずに拒否する）へ移した。試験では10月3日付の58件を5.5分で処理した。
• 8件目：恒久エラー（モデルがない）と一過性エラーを分け、恒久エラーは1回だけERRORを出してその実行の残りは呼ばないようにした。診断コマンドでは使うモデルの実在も照合する。存在しないモデル名を設定して診断がFAILになることも確かめた。

あわせて、fail-openのcatchが出すメッセージを定期点検でgrepする対象にし、警告の案内文に「一番多い原因」と調査記録のパスを書くようにした。

教訓として筆者は、検知を設定が正しいかではなく起きた証拠で見ることを挙げている。無人で回している仕組みについては、最後に成果物が更新された時刻を、通知ではなく自分の目で確かめるとよい。