理系猫凛のAI開発日誌｜2026年11月8日
AIに自分専用のサーバーシステム「Personal AI Platform」を開発させています。
前日の11月7日は、AIの開発や配備に何度も人間の承認が必要になる問題と向き合っていました。11月8日もその続きを進めるつもりだったのですが、途中で、もっと差し迫った問題が出てきました。
サーバーの空き容量がなくなり、開発そのものが進められなくなったのです。
そしてこの日は、サーバーの大掃除と、AIが自律的に開発を進める仕組みの改修という、二つの大きな作業に取り組むことになりました。
開発を止めたのは、ディスク容量でした
AIを使って開発を続けていると、テスト環境やビルド済みのDockerイメージ、検証用の作業領域が次々に増えていきます。
一つひとつは開発に必要だったものです。しかし、検証が終わっても古いものが残り続けると、いつか容量を圧迫します。
今回は、その問題が実際に起きました。容量不足で書き込みや検証が難しくなり、先に清掃しなければ開発を再開できない状態になりました。
まず対象を調査したところ、古いPythonの仮想環境、pytestやmypyの検証キャッシュ、以前のRunnerの復旧用Dockerイメージ、停止済み検証環境のイメージなどが見つかりました。
ただし、使われていなさそうだからといって、何でも消せるわけではありません。古いイメージでも復旧に必要かもしれませんし、作業領域には未保存の変更が残っている可能性もあります。
そこでAIには、現行サービスで参照されていないことと、削除しても復旧や開発に支障がないことを確認した対象だけを消すようにしました。
Dockerイメージ119件を削除。空き容量は約70GBへ
最初に、過去の検証で作られたPython環境やテスト用キャッシュを14領域削除し、実測で約4.48GBの空きが増えました。
しかし、それだけでは根本的な解決になりません。特に大きかったのがDockerです。
調査の結果、削除対象として安全性を確認できたのは、古いRunnerの復旧イメージ97件と、停止済み検証環境に関連するイメージ22件の計119件。小分けに削除し、その都度、削除対象がなくなったことと稼働環境が維持されていることを確認しました。
Docker清掃の直前から直後にかけて、空き容量は約6.24GBから約69.71GBに増加しました。差は約63.47GBです。共有データや同時書き込みの影響もあるため、個々のイメージのサイズを単純に合計した数字ではありません。
さらに、未使用のビルドキャッシュを限定的に整理して約0.82GBの空きを追加で確保。13時37分時点の実測では、空き容量は約70.53GBになりました。
容量がほぼない状態から、かなり余裕のある状態まで戻せたのは、この日の大きな成果でした。
その後、変更が残っていないことを検証した古い開発用作業領域（worktree）24件も正規の手順で解放し、観測上さらに約0.72GBの空きが増えました。開発中の作業領域や、使用中のコンテナ、データベース、復旧に必要なイメージは保持しています。
「消す」より難しいのは、「消してよい」と判断すること
今回、印象的だったのは、削除コマンドそのものよりも、削除してよい対象を見極めるほうが難しかったことです。
Dockerには大量の「回収可能」と表示されるデータがありました。しかし、その表示だけでは本当に安全に削除できるとは判断できません。
開発の履歴、現在のコンテナからの参照、復旧用イメージ、他の開発作業との関係を確認する必要がありました。
実際、削除できることを十分に証明できなかった古いイメージや作業領域は、そのまま残しました。
AIにサーバーを管理させるというのは、何でも自動で消させることではありません。「根拠が揃えば実行する。揃わなければ止める」という境界をどう設計するかが重要なのだと、改めて感じました。
本筋の開発も進めました。ただし、まだ未完成です
清掃と並行して、前日から続く「AIの通常開発を必要以上の承認で止めない仕組み」の改修も進めました。
目標は、通常のコード修正なら、品質検証、マージ、本番配備、動作確認まで自律的に進めること。一方で、権限や認証の変更、危険な操作、検証の証拠が足りない場合には、従来どおり止まるようにすることです。
11月8日には、複数のサービスに改修を反映し、PublishingとKnowledgeでは実際の機能修正を通常経路で配備・確認できました。Development MCPでも通常配備の成功を確認しています。
しかし、Runnerの通常更新では、認証の受け渡しや独立した実行処理の照合に問題が残りました。修正用のプルリクエストも作成しましたが、正式な全件検査が時間制限にかかり、まだ本番反映できていません。
ここは重要で、一部の経路で成功したことと、仕組み全体が完成したことは違います。
この日の開発も、成功した部分と未完成の部分を分けて記録することにしました。
今回の経験を、今後のサーバー管理に活かしたい
今回のように、開発を続けるうちに不要なデータが蓄積し、容量不足で止まってしまうのは避けたいところです。
そのため、空き容量や使用率を定期的に確認し、古いDockerイメージや開発用作業領域の削除候補を洗い出し、削除前に人間が判断できる運用も考えています。
なお、11月8日に実施・確認できたのは、清掃作業中の容量・ジョブ監視です。週次の自動チェックと削除候補の通知については、稼働まで確認できていません。 ここも次の課題として残しています。
開発が進むにつれて、コードを作るだけではなく、開発を続けられる環境そのものを維持する必要が出てきました。
以前はサーバーの中身がよく分からないまま、AIの作業結果を見ていた部分もありました。今回は、何が容量を使っているのか、何を残すべきなのか、どこに安全策が必要なのかを、以前より具体的に考えられた気がします。
11月8日は、AIに何かを「作らせる」だけでなく、AIと一緒に「維持する」ことを学んだ一日でした。
開発の完成形や詳しい実装は、まとまった段階で別の記事にしたいと思います。まずは、こうした途中経過も記録していきます。
コメント