Windowsの開発用Dドライブに残った空きは3.26 GiBでした。AIエージェントと開発キャッシュや出力の用途を調べ、Rustの単発ビルドと完成物の置き場を決めながら、ディスク容量を整理した記録です。
既存の清掃道具を使うと、空きは25.97 GiBまで戻りました。その後、完成物の一部を外部へ保管し、未使用のビルド中間物も整理して27.15 GiBになりました。
今回考えたのは、次の作業を終えたときに何を残すかです。作り直せる中間物、使うための完成物、判断材料として残す出力を区別し、確認できた範囲だけ片付けました。数値はすべて今回の個人環境での実測です。
空き容量は3.26→25.97→27.15 GiBと変化しました。ソースや用途未確定のデータを残し、確認済みの完成物を保管し、作業を終えた専用の中間物を片付ける方針にしています。
まず空きを戻してから、中身を見直しました
最初は既存の清掃道具で、Rustのtargetを5か所、Goのビルド・依存キャッシュ、pnpmの未参照パッケージを整理しました。この段階の増加は約22.71 GiBです。
続く部分移設と整理で増えたのは約1.18 GiBでした。最初からの増加は約23.89 GiBです。後半の作業だけで23.89 GiB増えたわけではありません。
ドライブの空きはGiBで記録しています。個々の完成ファイルはbytesでも確認しましたが、ファイルの論理サイズと、ドライブで実際に増えた空きは分けて扱いました。後述する動画17本のサイズを、そのまま約1.18 GiBの回収量として説明することもできません。
空きが戻っても、用途が不明な出力を消してよいかは別の確認が必要です。そこで、次は大きさだけで選ばず、残っているものの使い道を調べました。
tmpという名前でも、用途が分からなければ残します
約20.55 GiBのローカルデータには、公開候補や受入証跡が多く含まれていました。用途を確定できない出力もあったため、このデータは保持しました。
tmpや一時出力を思わせる名前でも、それだけで削除対象にはできません。完成物を確認する材料や、採用する候補が入っていれば、容量を空ける前に使い道を確かめる必要があります。今回は、用途を確認できた完成動画と、未使用と確認したRustのtargetを次の整理対象にしました。
同期フォルダ、アプリ本体、既存のhook、採用済みの候補は変更していません。ソースも残しています。空きが大きく増えそうでも、現在使っているデータをまとめて削除する方法は取りませんでした。
ここで残った約20.55 GiBは、今回さらに回収できた容量には含めません。用途を確定するまで保持するという判断も、配置を決める作業の一部でした。
外部に置く前に、戻して使えるところまで確かめました
保管先には、リモートデスクトップ経由で見える通常のディレクトリを使いました。開始時の利用可能容量は約217.48 GiBです。ただし、容量と存在を確認しただけでは、完成物の置き場として使えるかは分かりません。
まず先行する1本をコピーし、画像でも目視しました。その後、用途を確認した完成動画17本、合計37,911,314 bytesについて、コピー先からの読み戻しと利用、復元を確認しました。
確認した内容は次のとおりです。
- 全17本で、元ファイル・外部のコピー・復元用コピーのSHA256が一致
- 外部に置いた全17本で、ffmpegによる全編デコードに成功
- 先行1本は画像でも目視
SHA256の照合に加えて、外部に置いたファイルを使う確認も入れました。ただし、全17本を人が全編目視したという意味ではありません。目視した範囲と、機械的にデコードを確認した範囲は分けています。
コピー先との一致だけなら、保存できたかを確認するところまでです。復元用コピーも照合対象に入れることで、戻す操作まで含めて確認しました。元を整理する前に、この確認を一組として済ませる順序にしています。
この確認を終えてから、元ファイルと復元用コピーを整理し、外部の17本を保持しました。ソース、ログ、フォントは残しています。先に元を消して空きを作り、後からコピーの状態を調べる順序にはしませんでした。
今回確認できたのは、この経路で書き込み、読み戻し、完成物の利用、復元ができたことです。接続の切断・再接続試験までは実施していません。
外部への直接ビルドは失敗し、Dへ切り替えました
次に、必要になったRust製CLIを1件復元しました。完成物を外部へ置けるなら、ビルド中間物も最初から外部に作れるかを試しました。
外部への直接のcargo buildは、temp-archiveを削除する段階でWindows error 87となり失敗しました。正確な原因は確定していません。この1件から、すべてのネットワーク先でCargoが使えないとは判断できません。
そこで同じソースを使い、D上の作業専用の一時targetへ切り替えると、15.38秒でビルドに成功しました。
今回の経路では外部への直接ビルドが失敗し、D上の専用targetでは成功しました。この結果を受け、ビルドはDで行い、必要な完成物を外部へコピーする配置にしました。
動画の保管と読み戻しに成功したことから、同じ場所でビルドも完了するとまでは言えませんでした。今回の試行では、完成物を置く用途と、生成途中のファイルを扱う用途を個別に確認することになりました。失敗の原因を推測で決めず、成功を確認できたD側で生成する手順を採用しています。
完成したexeは6,815,232 bytesでした。外部へ保管するとともに、Dにも普段の利用用として小さなコピーを残しました。両方のSHA256が一致し、どちらでもversionの実行に成功しています。
さらに、隔離した合成Git fixtureで検出ケースと許可ケースを試し、期待する終了値と件数に一致することを確認しました。これは用意した合成ケースでの確認です。実プロジェクトの本番利用を一通り検証した結果とは分けて扱います。
この合成検査の所要時間は、Dでは約0.1秒、外部では約2秒でした。単発の測定なので、一般的な速度比は断定しません。今回の配置は、Dにも約6.5 MiBのexeを残して普段使いできる形です。
ビルドの後は、ローカルと外部の中間物を公式のcargo cleanで片付け、対象が消えたことを確認しました。別途、未使用のRust targetを1か所整理した際も、ソースと未追跡の変更は保持しています。
Cargoの公式仕様では、cargo cleanはCargoが生成したtarget内の成果物を削除し、--target-dirで生成物のディレクトリを指定できます。オプションなしではtarget全体が対象になるため、専用targetの範囲を明確にして扱います。Cargo cleanの公式仕様
清掃する道具にも、止まる条件を用意しました
今後の配置は、Dで作業単位のビルドを行い、必要な完成物だけ外部へ保管する形にしました。動作確認後に中間物を片付け、ソースと普段使う小さなexeはDに残します。
完成物のコピー後に照合・利用・復元を確認し、確認できてから中間物の整理へ進みます。確認が済まない場合は、元データを残して確認を続ける流れです。
この配置を扱うため、配置台帳と手動のInspect/Clean道具を用意しました。finishedになった作業の専用Cargo targetをIDで指定し、まずdry-runで対象を確認してからApplyへ進みます。
誤った範囲を片付けないよう、次の場合は拒否するようにしました。
- sourceとtargetの範囲が重なる
- 共有ディレクトリを対象にしている
- リンクや稼働中のプロセスがある
- 所有マーカーが一致しない
作業単位の専用targetなら、終わった作業の中間物として範囲を指定できます。一方、共有ディレクトリまで対象にすると、その作業以外のものを巻き込むおそれがあります。IDを指定できることに加えて、指定先が本当にその作業専用なのかも止める条件に含めました。
完成物の保管領域を削除する機能はありません。見直し日も、人が確認する目安です。日付を過ぎたら自動で消す期限にはしていません。
ただし、道具を用意した段階で安全性の確認が終わったわけではありません。作業を担当した子の成功報告とは別に、親が独立してレビューしたところ、共有フォルダを誤登録した場合の清掃範囲に穴が見つかり、修正しました。
子の報告だけで合格にせず、登録を間違えた場合にどこまで触れてしまうかも見直した点は、今回の道具づくりで残しておきたいところです。
次も、作業が終わったところで片付けます
今回決めた配置と清掃は、手動の運用です。定期チェックや通知、全AIが使う共通ルールへの組込みは未設定です。普段使う全アプリの起動試験も、まだ実施していません。
空きが27.15 GiBになったことと、この先ずっと放置で容量を維持できることは別です。完成物の保管と利用を確認できた範囲、合成ケースでCLIを検査した範囲、まだ試していない範囲を残して、次の作業に使います。
保持したソースや変更があることも、全アプリの起動を確認したことにはなりません。未実施の試験は未実施のまま残し、今回の確認結果から言える範囲を広げすぎないようにしています。
単発のビルドを終えたら、必要な完成物を保管し、使えることを確かめ、専用targetを片付ける。まずは、その作業の終わりに一緒に片付ける習慣から続けます。
📎 図解版・関連リンクをまとめたページがあります:
https://ishizakahiroshi.com/articles/2026/2026-10-05_disk-build-storage/
※ ヘッダー画像とインフォグラフィックの絵は AI（画像生成）で作成しています。
※ 本文の挿絵も AI（画像生成）で作成しています。
書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア（何でも屋）
https://ishizakahiroshi.com/
https://github.com/ishizakahiroshi
X（業務委託・各種相談はこちら）：
https://x.com/ishizakahiroshi
バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。