朝、自作の常駐ツールの様子を見ようとターミナルを開いたら、ログが異常な速さで流れ続けていました。起動しては数秒で落ち、また起動しては落ちる。いわゆる「クラッシュループ」というやつです。うん。地味に嫌な症状だなと思いました。今回は、その原因をClaude Codeと一緒に特定して、安定運用に戻すまでの経緯を、before/afterの視点で書いておこうと思います。
ある朝、ログが異常な速さで流れていた
その常駐ツールは、記事の内容を要約して手元に届けてくれる自作の小さなサーバーで、普段は静かに動いているはずのものでした。ところがその朝は様子が違って、起動ログと終了ログが数秒おきに交互に出続けていたのです。プロセス管理の仕組みで「落ちたら自動で再起動する」設定にしていたので、落ちるたびに律儀に立ち上がり直し、また落ちる。永遠にループしているような状態でした。
放っておいても直りそうにないので、Claude Codeを開いて「このサーバー、再起動を繰り返しているんだけどログを見てもらえますか」と相談するところから始めました。
Claude Codeと一緒に原因を追う
ログを一緒に読んでもらうと、起動直後に決まって同じエラーで落ちていることがわかりました。「ポートがすでに使われている」という趣旨のエラーで、いわゆるEADDRINUSEというやつです。つまり、サーバーが起動しようとした時点で、同じポートを別のプロセスがすでに使っていた、ということでした。
思い返せば、直前に手動でツールを再起動しようとして、うまく終了できていなかった古いプロセスが裏で生き残っていた可能性が高そうでした。そこに自動再起動の仕組みが「落ちたからまた起動しよう」と何度も上書きをかけようとして、毎回同じポートで衝突する。これが今回のクラッシュループの正体だったのです。
Before：とにかく再起動する設計だった
それまでのサーバーは、起動処理の中でポートの空き状況を一切確認していませんでした。落ちたら再起動する、という発想だけで作っていたので、「なぜ落ちたか」を見ずに「とにかくもう一度起動する」ことしか考えていなかったのです。平常時はこれで何の問題もなく動いていたのですが、一度でも終了処理が中途半端なプロセスを残してしまうと、そこから抜け出せなくなる作りでした。
Claude Codeに設計を見てもらいながら話していて、「落ちた原因を確認せずに再起動だけを繰り返す仕組みは、こういう時に弱いですね」という指摘をもらい、たしかにそのとおりだなと思いました。
After：既存プロセスを確認してから動くガードを入れる
そこで入れたのが、サーバーを起動する前に「そのポートを今すでに使っているプロセスがないか」を確認し、あれば先にそちらを片付けてから起動し直す、というガード処理です。EADDRINUSEを検知したら即座に再起動を試みるのではなく、一度立ち止まって現状を確認してから動く、という順番に変えました。
- 起動前にポートの使用状況を確認する
- すでに動いているプロセスがあれば、それを認識した上で処理する
- 確認が取れてから初めて新しいプロセスを起動する
やっていることは地味です。でも「落ちたらすぐ起動」から「確認してから起動」に変えるだけで、同じ失敗を無限に繰り返す構造がなくなりました。Claude Codeとやり取りしながら、ログの読み方から修正方針の相談、実際のコード修正までを一緒に進められたのは、こういう地味だけれど効く直し方にたどり着けた理由の一つだったと思います。
安定して動くようになって気づいたこと
修正後は同じ症状が出ていません。当たり前のことのようですが、常駐ツールというのは動いているのが当たり前すぎて、普段はあまり中身を意識しないものだなと、今回のことで改めて思いました。
自分の仕事道具として使っているツールでも、いざ壊れると「なぜ落ちたか」を突き止める作業が必要になります。今回はClaude Codeと一緒にログを読み、原因を一つずつ確認しながら直せたことで、思っていたより短い時間で安定運用に戻すことができました。うん、こういう小さな積み重ねが、結局は制作の現場を支えているんだなと思います。
自作ツールの運用や、AIと一緒に開発を進める体制づくりに興味のある方は、ご相談はお問い合わせからどうぞ。