AIと一緒にサーバー上で開発を進めていたら、ディスクの使用率が99％になっていました。
表示上は145Gの領域に143Gが使われ、空きは1.8G。開発を続けたいのに、まず容量を空けないと進められない状況です。
2026年11月8日、そこでサーバーの大掃除をしました。特に効果が大きかったのはDocker関連の整理で、この作業の前後だけで空き容量が約63.47GB増えました。
ただ、今回考えたかったのは、一度たくさん消して終わりにすることではありません。開発が途中になったり、方針が変わったりするたびに、使わなくなったものが残っていく。この状態をどう管理するか、という話です。
開発の途中にはいろいろなものが残る
私のサーバーでは、AIを使って複数の開発を進めています。そのすべてが、最初から最後まで一直線に完成するわけではありません。
途中で問題が見つかることもあります。別の修正が先に必要になることもあります。試してみたものの、その方法は使わなくなることもあります。
その過程で、検証用の環境、過去のDockerイメージ、テスト用のキャッシュ、作業用に複製したコードなどが残ります。
Dockerイメージは、アプリを動かすためのプログラムや実行環境をまとめたものです。今回のサーバーには、以前の状態へ戻すためのイメージや、検証用に作ったイメージが多数保存されていました。
作った時点では必要だったものでも、開発が進んだ後まで必要とは限りません。一方で、その「もう不要になった」を判定する工程がなければ、残り続けます。
今回、容量を圧迫していたものの中には、こうした過去の開発や検証で使った資材がありました。
まず削除する前に中身を調べる
最初は、どこまで安全に掃除できるかを調べるところから始めました。
容量が大きいからという理由だけで削除すると、今動いているサービスや、別に進めている開発に影響するかもしれません。復旧に必要なものまで失ってしまうのも困ります。
そこで、対象が現在使われているか、ほかの処理から参照されているか、削除しても再作成できるかを確認し、範囲を絞って進めました。
ここで難しかったのが、「使っていない」と「確認できていない」の区別です。
旧Codex関連の仕組みは整理する方針でしたが、その状態を取得できないために、作業領域が一律に保留される場面がありました。廃止する予定の仕組みを残すための確認が、整理を止める理由になっていたわけです。
そのため、旧システムの状態を取得できないことだけで止めず、現在の開発に影響しないか、必要な成果が残っていないかを確認する方針にしました。
最も容量が空いたのはDockerの整理でした
今回の主な清掃結果は、次のようになりました。
| 整理した対象 | 内容 | 作業前後の空き容量の増加 |
|---|---|---|
| 古い検証環境とキャッシュ | Python環境やテスト用データなど14ディレクトリ | 約4.48GB |
| 古いDockerイメージ | 復旧用の旧世代と停止済み検証環境の合計119件 | 約63.47GB |
| Dockerのビルドキャッシュ | 利用時期と保持容量の条件を付けて整理 | 約0.82GB |
| 検証用の作業コピー | 独自の変更がない24件 | 約0.72GB |
容量は各作業の前後で測定した空き容量の差です。作業の途中にはビルドやほかの書き込みもあるため、表の数字を単純に足した値と、一日の最初と最後の差は一致しません。表ではGBを10億バイトとして表記しています。
Dockerイメージの整理では、古い復旧用イメージ97件と、停止済みの検証環境に属する22件を削除しました。現在使っているものと、今回残すと決めた直近の復旧用イメージは保持しています。
この整理の直前には約6.24GBだった空き容量が、終了後には約69.71GBまで増えました。
その後のキャッシュ清掃では、一時的に約70.53GBまで空きが増えました。同じ日の22時20分の観測では、使用量が約89.12GB、利用可能な空きが約65.76GB、使用率は約58％でした。
99％の状態から、開発を進めるための余裕を取り戻せたことになります。
24件を片づけても空いたのは約0.72GB
一方で、作業領域の整理は、件数のわりに容量への効果が小さめでした。
151件の開発作業領域を調べ、そのうち独自の変更が残っていない検証用コピー24件を削除しました。コードの履歴はブランチに残し、必要なら作業コピーを再作成できる形です。
それでも空いたのは約0.72GBでした。
正直、「大したサイズじゃないな」と思いました。もちろん不要な作業領域を片づける意味はありますが、容量不足の対策としては、件数だけを見ても優先順位は分かりません。
24件の作業コピーと119件のDockerイメージでは、今回の回収量が大きく違いました。まず何が容量を使っているかを測り、大きいところから調べる必要があります。
なお、サーバー全体の容量内訳を完全に把握できたわけではありません。当日の調査では、一部のディレクトリ集計が途中で打ち切られ、全体測定用の管理コマンドも利用できませんでした。開発領域、データ、ログ、OSなどの正確な比率には、まだ確認できていない部分があります。
開発途中でも整理の候補にはできる
今回のやり取りで、私が気になったのは「開発途中だから残す」という判断です。
未完成の作業でも、今後使わないと決めたものなら、整理してよいはずです。すべての試みを完成させることも、すべての環境を残し続けることも現実的ではありません。
ただし、試作環境そのものと、そこで得られた成果は分けて考える必要があります。
再作成できる実行環境や重複した作業コピーは片づけられても、そこにしかないコードや調査メモは残したいかもしれません。必要な成果を保全してから環境を削除する、という選択もあります。
今後は、開発が完了しているかどうかだけでなく、今使っているか、今後使う予定があるか、そこにしかない成果があるかを見て判断したいと思います。
毎週点検して削除する前に聞いてもらう
一度大掃除をしても、開発を続ければ新しい環境や成果物は増えます。実際に今回も、清掃直後と夜の観測では空き容量が変わっていました。
そこで、ChatGPTの定期タスクに、サーバー容量と削除候補の点検を追加しました。
毎週日曜の日本時間20時ごろに、次の内容を確認する設定です。
- 使用量と空き容量、前回からの増減
- 使われていないDockerイメージや検証環境、放置された作業領域
- 削除候補の容量と、不要と判断した理由
- 削除した場合の影響と、必要になったときの復元方法
そのうえで、具体的な候補を示して「削除しますか？」と聞いてもらいます。
自動削除にはしていません。使わなくなった開発をどこまで片づけるか、どの復旧用データを残すかは、候補を見て判断する形です。
初回は2026年11月15日の予定で、この記事で扱う時点では設定までが完了しています。週次点検が実際に継続して動くかの確認はこれからです。また、常時監視ではないため、週の途中で急に容量が増えることまで防げるわけではありません。
開発を進めるために片づける時間を持つ
AIと開発していると、次に作るものや、次に直す問題に意識が向きます。その結果、以前作ったものを残すか捨てるかの判断は、後回しになっていました。
今回は、その積み残しが容量不足という形で表に出ました。
大掃除で余裕を取り戻せたのはよかったです。ただ、今後も「いっぱいになってから慌てて消す」を繰り返したくはありません。
作ったものを振り返り、使わなくなった環境を整理する。そのための候補集めと容量の記録をAIに任せ、残すかどうかを自分が判断する。まずは、この週次点検を続けられるか試してみます。
コメント