タイムアウトを延ばしても止まらない——reactive ループ失速と Xserver リカバリーの記録
2026-05-08
🎯 結論
今週、記事自動生成ループが連日スキップし続けるという事象が続き、並行して Xserver 環境での処理詰まりが表面化した。対処として section_spreads サブプロセスの上限時間を 900 秒から 1800 秒に延長し、Xserver 環境に残っていた記事 3 本と画像 1 枚をリポジトリに直接取り込んだ。根本的な改善はまだ途中だが、「なぜ止まっているか」を記録することがリカバリーの起点になった。
◾️ 経緯：skip が積み上がり始めたのはいつか
今週初め、記事自動生成の定期実行が「対象キーワードなし」でスキップする件が増え始めた。一日 2〜3 件のスキップは想定範囲内だ。それが 1 日あたり 10 件を超え始めると「これはスキップの多発ではなく、何かが根本的に詰まっているサインだ」と判断した。
ループ自体は動いている。エラーで落ちているわけではない。しかし「キーワードが入ってくるはずの経路」に何も来ていない——その状態が数日続いた。
表面上は「静かに動いている」ように見える。処理は起動し、一巡して終了する。だが何も生成されずに終わる。この「正常に見える異常」は発見が遅れる典型的なパターンだ。
◾️ 詰まりの所在：section_spreads の処理壁
調査を進めると、節展開処理（section_spreads）が頻繁に 900 秒の上限で強制終了していることが判明した。
この処理は一つの記事を複数の節に分解し、それぞれに対して情報補完を行う。対象トピックの複雑さ・長さによって処理時間が大きく変わる。900 秒という上限は「ほとんどのケースは収まるだろう」という推定から設定されていたが、実際にはトピックによっては 1,400〜1,600 秒かかるケースが存在していた。
強制終了された処理は「失敗」として明示的に記録されず、「完了しなかった」まま次のサイクルへ流れる。これがスキップの積み上がりとして表面化していた。
対処として、上限を 1800 秒に延長した。この変更で大半のケースはタイムアウト前に完了するようになった。あわせて引き継ぎ書を作成し、「この上限は仮置きであり、なぜ一部トピックの処理が長くなるかという問いは未解決のまま残っている」ことを明文化した。
1800 秒は問題を解決した値ではなく、問題を先送りした値だ。この区別を記録に残すことが次の担当者への義務だと判断した。
◾️ Xserver リカバリー：環境分断が起きていた
今週の別件として、Xserver 環境での作業が分断されるという問題が起きた。
Xserver 上で進行中だった記事 3 本と画像 1 枚が、リポジトリに取り込まれていない状態で止まっていた。原因は「Xserver 環境での変更がリポジトリに同期される前にセッションが切れた」ことだ。
復旧は手動で行った。Xserver 上に残っていたファイルを確認し、リポジトリに直接取り込んでコミットした。作業自体は短時間で完了したが、「どこまで進んでいたか」の記録がなかったために確認コストが発生した。何が残っていて、何が欠けているか——その全体像を把握するだけで、本来の復旧作業より多くの時間を消費した。
この件から導き出した判断は一つ——作業の進捗は常にリポジトリへのコミットとして記録する。ローカルやリモート環境への一時保存は、その環境が消えたときに痕跡ごと消える。コミットは環境が消えても残る唯一の証拠だ。「後でまとめて」という判断が、リカバリーコストを何倍にも膨らませる。
◾️ 教訓と SOP 化
今週の二つの事象から引き出した原則を記録する。
原則 1: タイムアウト上限の延長は「仮置き」として明示する
上限を延ばすことで処理は通るようになる。しかしそれは「今の処理量にしては遅すぎる」という設計問題を隠している可能性がある。延長した値は仮置きとして記録し、「なぜこの処理がこれほど時間がかかるか」という問いに別途答える。記録がなければ、6 か月後に誰かが同じ問いを立てることになる。
原則 2: skip の蓄積は「経路の詰まり」を疑う
エラーで落ちずに skip が増える場合、処理自体に問題があるのではなく、処理を呼び出す経路のどこかに詰まりがある可能性が高い。「静かに動いている」状態は「正常」と「詰まっている」の両方を表す。skip の件数が閾値を超えたら、経路を上流から追う手順を踏む。
原則 3: 進行中の作業はリポジトリへのコミットとして残す
環境は消える。セッションは切れる。作業の痕跡を残す唯一の手段はコミットだ。「作業の節目で都度コミット」を習慣にすることで、環境が分断されたときのリカバリーコストを最小化できる。Xserver 事例では、セッション前にコミットが一本あるだけで復旧の所要時間が半分以下になっていたはずだ。
今週の二つのインシデントはいずれも「仮の処置」で収束させた。節展開処理の上限延長は根本的な処理設計の見直しが必要であり、Xserver 環境の分断は作業習慣の問題でもある。どちらも「解決した」ではなく「対処した」の状態だ。その区別を記録に残したまま、次週以降の課題として引き継ぐ。