AIの改修による暴走

出社日の退勤は、まず会社最寄駅から新宿駅まで行き、
新宿駅から自宅最寄駅までは確実に座るために次発乗車列に並ぶことも考慮して駅で待機します。
そして新宿駅で無事に座れたらあとは読書タイム。
逆に言えば、新宿駅に辿り着くまでは乗り換えの都合で読書をする余裕が無いのでスマホをいじるしかありません。
こういうとき、最近はGoogleアプリでニュースをチェックしていることが多いのですが、
自分のサイトを巡回することも結構あります。
そこで今日はサイトを巡回しようとしたらサイトがめちゃくちゃ重く502エラーを吐くこともあったため、
「またサーバーが攻撃されているかも？」と思いつつ内心不安になりながらも帰路を急ぎました。

サーバーのリソースモニタを見ると夕方からCPU使用率が不自然に上昇しており、
ターミナルでSSH接続するとターミナル自体が固まってしまうほどサーバーが激重状態になっていました。
が、結論から言うとこれはセキュリティ・インシデントやDDoS攻撃などではなく、
単にこのブログのフロントエンドが不当にリソースを食う設計になっていたせいで暴走していただけした。

基本的にこの手のトラブルが起きた場合はChatGPTに訊けばどうにでもなります。
React2Shellの件（#08035 / 2025年12月15日）や今回使った手法はどちらもtopコマンドを起点にしています。
これはWindowsでいうところのタスクマネージャーで、CPU使用率の高いプロセスが一目瞭然になるんですよね。
プロセス番号さえ分かればどこの何が暴走しているのかは仮想化環境内だろうと特定できるので、
今回はこのブログのフロントエンドコンテナの中にあるNode.jsが暴走していたとわかったわけです。
そしてなぜ暴走していたのかと言えば、
本家ブログで本文やタグを表示しようとするときに全記事（執筆時点で8,167本）を探索するAPIが走っていたと。
実際、ログをリアルタイムで流すようにして本番環境にアクセスしてみると、
面白いくらいアクセスした瞬間だけCPU負荷が爆上がりすることがわかりました。

今回、この原因を作ったのはAIの改修であり、これはこれで問題だと改めて思いました。
やはり自分の手が届かない範囲で改修を完結させてしまうとこういう予期せぬ問題が発生することがあるんだなと。
人力開発では何を書いて何が起こりうるのかを自分がそれなりに把握できていたのでこうした問題は起こりにくく、
それゆえにどうしてもテストなどの後工程は軽視されがちでした。
しかしエージェントコーディングにおいてはむしろ盤石なテストプロセスが必須なのかも。
AIを過信しないことはもちろん大事ですが、人の手が介入しないからこそ個々のプロセスについて言語化しておき、
ルールを過不足なく決めることは今後の開発において急務になるんじゃないかと思っています。