前回【Day 14】では、
docker exec -it による稼働中コンテナへの潜入デバッグと、C#アプリケーションの内部検証術をマスターしました。第3部の締めくくりとなる本日は、コンテナ開発を意気揚々と進めるベテランエンジニアが必ずぶち当たる壁――「なぜかSSD（Cドライブ）の空き容量がどんどん消えていく…！？」という恐怖を一発で解消するメンテナンスの極意「docker system prune」を徹底解説します！
肥大化した未使用キャッシュや停止中コンテナを一掃し、大切な開発環境を常にクリーン＆爆速に保つノウハウをお届けします！
① 導入・本日の達成目標
Dockerを使い始めると、その手軽さゆえに docker run や docker build を何十回、何百回と繰り返します。
しかしある日突然、Windowsのタスクバーに「ディスクの空き領域が不足しています」という警告が表示されて青ざめることになります。
「不要なコンテナは docker rm したはずなのに、なぜ数十GBもディスクが減っているのか？」
その原因は、ビルドの中間層（レイヤーキャッシュ）や、タグが外れた古いイメージ（dangling images）、孤立したボリュームにあります。
本日の講義を終える頃には、以下の3つの目標を完全にマスターできます。
docker system dfにより、Dockerが消費しているディスク容量の4大要素（イメージ・コンテナ・ボリューム・ビルドキャッシュ）と回収可能容量（RECLAIMABLE）を正確に把握できる。docker system prune（および-aオプション）の安全設計を理解し、稼働中のコンテナを保護しながら不要なゴミファイルを一発で一括削除できる。--volumesフラグの危険性を熟知し、C#/.NET開発やGitブランチ運用における定期メンテナンスの黄金ルーチンを確立できる。
② VM / Windowsサーバー技術者のためのパラダイムシフト
長年Hyper-VやVMwareを管理してきたベテランエンジニアにとって、「ディスク容量の回収」といえば悪夢のような重労働でした。
Hyper-Vの可変容量仮想ハードディスク（.vhdx）は、ゲストOS内でファイルを削除してもホスト側のVHDXファイルサイズは自動では小さくなりません。
ディスクを縮小するには、わざわざ仮想マシンをシャットダウンし、Hyper-Vマネージャーから「ディスクの編集」を開いて「最適化（Compact）」を実行するか、PowerShellで Optimize-VHD コマンドを叩く必要がありました。
これに対し、Dockerコンテナは「OSそのものを抱え込まない」ため、ディスク管理の設計思想が極めて洗練されています。
Dockerエンジンはすべてのイメージレイヤーやキャッシュをハッシュ値で一元管理しており、稼働中のシステムを一切止めることなく、オンラインのまま不要なブロックだけをコマンド1発で瞬時に解放できるのです！
📊 仮想マシン（VHDX）と Docker のディスクメンテナンス対比
③ 容量確認の極意：docker system df
いきなり掃除を始める前に、まずは「何がどれくらいディスクを食っているのか」を把握しましょう。
Linuxのディスク確認コマンド df（disk free）に由来する docker system df を実行します。
docker system df
実行すると、以下のような美しい集計表が出力されます：
TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 12 3 4.82GB 3.15GB (65%) Containers 8 2 215MB 180MB (83%) Local Volumes 5 2 1.45GB 850MB (58%) Build Cache 42 0 8.92GB 8.92GB (100%)
4大要素と出力項目の見方
- Images（イメージ）: Docker Hubから取得したベースイメージやビルド済みイメージ。現在どのコンテナからも使われていないイメージは回収対象になります。
- Containers（コンテナ）: コンテナの読み書きレイヤー。停止中（Exited）のコンテナはそのままディスクを占有しています。
- Local Volumes（ローカルボリューム）: データベースや設定ファイルをホストに永続化している領域。
- Build Cache（ビルドキャッシュ）:
docker buildの高速化のためにBuildKitが保持している中間層。C#アプリを頻繁にビルドしていると、ここが平気で10GB〜20GBに膨れ上がります！ - RECLAIMABLE（回収可能容量）: 「今すぐ安全に削除できる容量」を示しています。上記の例では、合計で約13GBものディスクが回収可能であることが一目で分かります！
④ 一括掃除の決定版：docker system prune の仕組みと安全設計
回収可能容量を確認したら、いよいよ一括クリーンアップを実行します。
使うコマンドは docker system prune です。
1. デフォルトの prune が削除する対象
引数なしで docker system prune を実行すると、以下の「安全に消せるゴミ」だけが自動的に選別されて削除されます：
- ✅ 停止中のすべてのコンテナ（
docker ps -aで Exited になっているもの） - ✅ タグなしイメージ（dangling images）: ビルドのやり直し等で名前が
<none>:<none>になった孤立イメージ - ✅ 未使用のカスタムネットワーク: どのコンテナにも接続されていない自作ブリッジネットワーク
- ✅ 未使用のビルドキャッシュ: ビルドで参照されなくなった古い中間キャッシュ
2. 稼働中コンテナは絶対に消えない「安全設計」
「本番や開発で今まさに動いているコンテナが巻き込まれて消えたらどうしよう…」と不安になるかもしれませんが、心配無用です！
Dockerは「現在ステータスが Up（稼働中）のコンテナ」および「その稼働中コンテナが使っているイメージ」は絶対に削除しません。
WebサーバーやDBコンテナを動かしたままでも、安心して実行できます。
3. さらに徹底的に掃除する：-a (--all) オプション
docker system prune -a
-a を付けると、タグなしイメージだけでなく、「現在どのコンテナからも参照されていないすべてのイメージ」が一括削除されます。
過去に検証のためにお試しで pull して放置していた巨大なイメージ（UbuntuやNode.js、古い.NET SDKなど）を一掃したい時に絶大な効果を発揮します！
⑤ 最重要警戒ポイント：--volumes フラグの危険性と安全対策
ここで、Dockerメンテナンスにおいて最も重大な注意点をお伝えします。
デフォルトの docker system prune では、ボリューム（Volumes）は絶対に削除されません。
なぜなら、ボリュームにはデータベース（SQL Server / PostgreSQL / MySQL）の実データや、アプリケーションの永続化ファイルが保存されているからです。
しかし、ネットの記事などで紹介されている以下のコマンドを安易にコピペして実行すると、取り返しのつかない悲劇が起きます：
# ⚠️ 超厳重警戒コマンド（初心者の不用意な実行厳禁！） docker system prune --volumes
--volumes フラグを付与すると、「現在動いているコンテナにマウントされていないすべてのボリューム」が問答無用で全消去されます！
開発用のDBコンテナを一旦停止（docker stop）していた場合、その中に蓄積されていた大事な検証用テストデータやマスターデータが跡形もなく消え去ってしまいます。
日常のメンテナンスでは、絶対に
--volumes を付けずに docker system prune（または docker system prune -a）を使用してください。ボリュームの掃除が必要な場合は、docker volume ls で確認した上でピンポイントに docker volume rm <名前> で個別削除するのが安全です。
⑥ C# / .NET 開発現場での実践：ビルドキャッシュとGitブランチ運用
C#/.NETエンジニアの日常開発において、ディスク消費が最も激しくなるシチュエーションと、その対策ルーチンを見ていきましょう。
1. Visual Studio の F5 デバッグで増え続けるビルドキャッシュ
【Day 08】で解説した通り、Visual Studio 2022のコンテナツール拡張機能は、高速デバッグのために裏で頻繁に中間イメージやキャッシュレイヤーを作成します。
また、dotnet restore や dotnet publish を含むマルチステージビルドを繰り返すと、NuGetパッケージの展開キャッシュがBuildKit内に大量に積み上がります。
週末の退勤前やスプリントの終了時に docker system prune を実行する習慣をつけるだけで、開発PCのパフォーマンスを劇的に良好に保てます。
2. Gitブランチ切り替え後の残骸コンテナの整理
チーム開発では、feature/login-api や feature/order-service など、ブランチごとにコンテナを立ち上げて動作検証を行います。
Pull Requestがマージされて不要になったブランチの検証コンテナは、停止状態のまま放置されがちです。
作業ブランチを切り替えるタイミングで docker system prune を叩けば、過去のブランチの残骸コンテナが一掃され、クリーンな状態で次の機能開発に臨めます。
⑦ ハンズオン実習：SSD容量確認から一括掃除までの完全手順
それでは、手元のターミナル（PowerShell または WSL2 Ubuntu）を開いて、実際にクリーンアップの一連の流れを体験してみましょう！
# 1. 現在のDockerディスク使用量と回収可能容量を確認 docker system df # 2. 実験用に一時コンテナを起動してすぐに停止（ゴミを作る） docker run --name temp-clean-test nginx:alpine echo "掃除テスト完了" # 3. 停止中コンテナが存在することを確認 docker ps -a --filter "name=temp-clean-test" # 4. 一括掃除コマンドを実行（確認プロンプトが表示される） docker system prune # 出力例: # WARNING! This will remove: # - all stopped containers # - all networks not used by at least one container # - all dangling images # - unused build cache # Are you sure you want to continue? [y/N] y # 5. 回収結果の確認（Deleted Containers や Total reclaimed space が表示される） # Total reclaimed space: 15.2MB (環境によって異なります) # 6. 強制実行（確認プロンプトをスキップして自動化したい場合） docker system prune -f # 7. 再び容量を確認してスッキリしたことを確認！ docker system df
⑧ ベテランが陥りやすい落とし穴・現場の知恵袋
⚠️ ディスクメンテナンスの3大現場トラブルと回避策
罠① docker system prune を実行したのに Windows の Cドライブ空き容量が増えない！？
Windows 11 + WSL2 環境で最も多い質問がこれです。
WSL2のバックエンド仮想ディスク（ext4.vhdx）は、内部でファイルを削除してもWindowsホスト側のVHDXファイルサイズは自動縮小されません（内部的に空き領域として再利用されるのみ）。
Windows側の実ディスク容量を物理的に即座に回復させたい場合は、WSLを一旦シャットダウン（wsl --shutdown）した上で、PowerShell（管理者）で wsl --manage Ubuntu --shrink（または diskpart の compact vdisk）を実行してください。
罠② CI/CDパイプラインで毎回 prune -a してしまいビルドが激遅になる
GitHub Actions Runner や Jenkins などのCIサーバーで、容量節約のために毎回のビルドジョブの先頭に docker system prune -a を仕込んでしまう失敗パターンです。
せっかくのベースイメージやNuGetキャッシュが毎回吹き飛ぶため、ビルドのたびに数GBを再ダウンロードすることになり、CI時間が3分から20分へと大悪化します。
CI環境では「日次または週次の深夜ジョブ」として定期実行するか、キャッシュ有効期限を設定して運用しましょう。
罠③ prune で消したくないコンテナがあるのに stop していた
「あとで再開して使いたい重要な検証用コンテナ」がある場合は、停止（stop）させたままにしておくと prune で消えてしまいます！
消したくないコンテナは事前に docker commit でイメージとして名前を付けて保存しておくか、稼働状態のままにしておくのが鉄則です。
- 容量確認は
docker system df。Images、Containers、Volumes、Build Cache の回収可能サイズを一目で把握できる。 - 一括掃除は
docker system prune。停止中コンテナ、タグなしイメージ、未使用ネットワーク、キャッシュを安全に一掃。 - 稼働中（Up）のコンテナは絶対に消えない安全設計なので、稼働中でも安心して定期実行できる。
--volumesフラグの不用意な付与は厳禁！データベースの永続化データを守るため、日常メンテナンスではボリュームを残す。- C#開発では Visual Studio のビルドキャッシュ蓄積やGitブランチ切替時のクリーンアップに絶大な効果を発揮する。
『第4部突入！ASP.NET Core Web APIのコンテナ化（初めてのDockerfile作成）』〜FROM, WORKDIR, COPY, RUN, ENTRYPOINT の基本命令を完全マスター〜
コメント
コメントを投稿