<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>運用 on Claude Code 始めました</title><link>https://kitepon-rgb.github.io/WebAICoding/tags/%E9%81%8B%E7%94%A8/</link><description>Recent content in 運用 on Claude Code 始めました</description><generator>Hugo</generator><language>ja</language><lastBuildDate>Sat, 04 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://kitepon-rgb.github.io/WebAICoding/tags/%E9%81%8B%E7%94%A8/index.xml" rel="self" type="application/rss+xml"/><item><title>AIにサーバーを任せて3日間で起きたこと</title><link>https://kitepon-rgb.github.io/WebAICoding/post/ai-server-management-log/</link><pubDate>Sat, 04 Apr 2026 00:00:00 +0000</pubDate><guid>https://kitepon-rgb.github.io/WebAICoding/post/ai-server-management-log/</guid><description>&lt;h2 id="はじめに"&gt;はじめに&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://kitepon-rgb.github.io/WebAICoding/post/ai-server-management/"&gt;前回の記事&lt;/a&gt;で、自宅サーバーの管理をAIに丸ごと任せた話を書いた。深夜にAIがパトロールして、昼間は監視スクリプトが異常を検知したらAIが出動する仕組みだ。&lt;/p&gt;
&lt;p&gt;仕組みを作った話はした。では、実際に動かしてみてどうだったか。3日間の運用で起きたことを書く。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="監視スクリプトが自分自身を壊した"&gt;監視スクリプトが自分自身を壊した&lt;/h2&gt;
&lt;p&gt;運用3日目の朝、監視スクリプトが異常を検知した。&lt;code&gt;license_api_prod&lt;/code&gt;コンテナが応答しない、と。&lt;/p&gt;
&lt;p&gt;AIが出動して調査を始めた。SSHでサーバーに接続して、コンテナの状態を確認する。結果——&lt;strong&gt;コンテナは正常に動いていた。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;誤検知だった。しかも2分後、今度は&lt;code&gt;ddnser&lt;/code&gt;でも同じ誤検知が出た。&lt;/p&gt;
&lt;h3 id="原因ssh接続の開きすぎ"&gt;原因：SSH接続の開きすぎ&lt;/h3&gt;
&lt;p&gt;AIが突き止めた原因はこうだ。&lt;/p&gt;
&lt;p&gt;監視スクリプトは60秒ごとにサーバーの状態をチェックする。システムリソース（ディスク、メモリ、スワップ）で3本、7つのコンテナのヘルスチェックで最大9本。合計10本以上のSSH接続を&lt;strong&gt;同時に&lt;/strong&gt;開いていた。&lt;/p&gt;
&lt;p&gt;OpenSSHには&lt;code&gt;MaxStartups&lt;/code&gt;という設定がある。同時接続数の上限だ。デフォルトは10。監視スクリプトがこの上限を超えていて、接続が弾かれていた。つまり、&lt;strong&gt;監視スクリプト自身がサーバーに負荷をかけて、自分のSSH接続を失敗させていた。&lt;/strong&gt;&lt;/p&gt;
&lt;h3 id="1回目の修正並列を直列に"&gt;1回目の修正：並列を直列に&lt;/h3&gt;
&lt;p&gt;AIはヘルスチェックの実行方式を&lt;code&gt;Promise.allSettled()&lt;/code&gt;による全並列から&lt;code&gt;for...of&lt;/code&gt;による順次実行に変更した。SSH接続が同時に1本しか開かれなくなった。&lt;/p&gt;
&lt;h3 id="2回目の修正リトライの追加"&gt;2回目の修正：リトライの追加&lt;/h3&gt;
&lt;p&gt;直列にしても、一時的なSSH切断は起こりうる。サーバー側の負荷やネットワークの瞬断で、1回だけ接続が切れることはある。&lt;/p&gt;
&lt;p&gt;2分後の2回目の誤検知を受けて、AIは「SSHトランスポートエラー」を判別するヘルパー関数を追加した。&lt;code&gt;Connection closed&lt;/code&gt;、&lt;code&gt;Connection refused&lt;/code&gt;、&lt;code&gt;ETIMEDOUT&lt;/code&gt;などのパターンを検出して、3秒待ってから1回リトライする。リトライ後も失敗した場合だけ異常として報告する。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;修正は2段階。並列→直列でSSH接続数を削減し、リトライで一時的な切断に対応。&lt;/strong&gt; どちらも人間の介入なし。Discordに「修正しました」と通知が来て、それで終わりだ。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="深夜パトロールが見つけたもの"&gt;深夜パトロールが見つけたもの&lt;/h2&gt;
&lt;p&gt;毎日深夜4時にAIがサーバー全体を巡回する。セキュリティ設定、リソース使用量、コンテナの構成、ログの中身。人間が日常的にチェックしない部分を、AIが代わりに見る。&lt;/p&gt;
&lt;h3 id="nextcloudのログが21gb"&gt;Nextcloudのログが21GB&lt;/h3&gt;
&lt;p&gt;運用2日目のパトロールで、AIがNextcloudのログファイルの異常に気づいた。&lt;/p&gt;
&lt;p&gt;&lt;code&gt;/var/mnt/nextcloud_data/nextcloud.log&lt;/code&gt; — &lt;strong&gt;21.3GB。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;ログファイルが21GBに膨れ上がっていた。NFS上にあるためディスクの逼迫は起きていなかったが、ログローテーションが機能していない。自分では気づけなかった。&lt;/p&gt;
&lt;h3 id="selinuxの拒否ログが1241件"&gt;SELinuxの拒否ログが1,241件&lt;/h3&gt;
&lt;p&gt;もう一つ。SELinuxがauction-botの&lt;code&gt;auction.db&lt;/code&gt;に対するlockアクセスを毎分拒否していた。過去24時間で1,241件。&lt;/p&gt;
&lt;p&gt;SELinuxはPermissiveモードで動いているので、実際にブロックはされていない。アプリは正常に動く。ただ、拒否のたびに&lt;code&gt;setroubleshoot&lt;/code&gt;というデーモンが起動して分析を行い、CPU 22.9%を一時的に消費していた。&lt;/p&gt;
&lt;p&gt;実害はないが、無駄にリソースを食っている。AIが見つけなければ、ずっと放置されていたと思う。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="日々の定点観測"&gt;日々の定点観測&lt;/h2&gt;
&lt;p&gt;パトロールは毎日サーバー全体を見て回る。何を見るかもAIが判断するが、結果として日をまたぐとトレンドが見えてくる。&lt;/p&gt;
&lt;h3 id="スワップ使用率の推移"&gt;スワップ使用率の推移&lt;/h3&gt;
&lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;日付&lt;/th&gt;
 &lt;th&gt;スワップ使用率&lt;/th&gt;
 &lt;th&gt;備考&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;4/2&lt;/td&gt;
 &lt;td&gt;89%&lt;/td&gt;
 &lt;td&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;4/3&lt;/td&gt;
 &lt;td&gt;92%&lt;/td&gt;
 &lt;td&gt;微増傾向&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;4/4&lt;/td&gt;
 &lt;td&gt;62%&lt;/td&gt;
 &lt;td&gt;サーバー再起動でリセット&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;スワップが日々積み上がっていく傾向をAIが追跡していた。4/4にサーバーが再起動されてリセットされたが、再起動なしの長期稼働ではスワップが逼迫する可能性がある。AIはレポートに「継続監視が必要」と毎回書いている。&lt;/p&gt;
&lt;h3 id="fail2banのban推移"&gt;fail2banのBAN推移&lt;/h3&gt;
&lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;日付&lt;/th&gt;
 &lt;th&gt;現在BAN中&lt;/th&gt;
 &lt;th&gt;累計BAN&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;4/2&lt;/td&gt;
 &lt;td&gt;14 IP&lt;/td&gt;
 &lt;td&gt;235&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;4/3&lt;/td&gt;
 &lt;td&gt;10 IP → 14 IP&lt;/td&gt;
 &lt;td&gt;242 → 293&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;4/4&lt;/td&gt;
 &lt;td&gt;8 IP&lt;/td&gt;
 &lt;td&gt;—&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;SSHへのブルートフォース攻撃が日常的に来ている。&lt;code&gt;admin&lt;/code&gt;、&lt;code&gt;ubuntu&lt;/code&gt;、&lt;code&gt;mysql&lt;/code&gt;といった汎用ユーザー名での接続試行。fail2banが淡々とBANしている。パスワード認証は無効で鍵認証のみなので突破はされないが、攻撃が来ていること自体は知っておきたい。AIがレポートで毎日報告してくれる。&lt;/p&gt;</description></item></channel></rss>