Apple Silicon クラウド Mac Runner のディスクと inode ガバナンス：Derived Data、コンテナレイヤ、統合ログとキャッシュ——割当アラート、段階的クリーンアップとプラン SSD 境界のキャパシティプランニング

1. 二つの天井：ブロックと inode

APFS で「まだ数十 GB ある」のに No space left on device になるのは、多くの場合inode やメタデータ圧力が原因です。Runner で典型な犯人は、ジョブごとの Xcode DerivedData、ローテーションされていない統合ログ、npm / pip / Maven のローカルキャッシュ、リポジトリを bind マウントしたコンテナ内の大量小ファイルです。アラートは disk > 85% と inode > 85%（またはファイル数プロキシ）の二系統に分け、ダッシュボード上の色分けも分けると、当番が容量バーだけを見て inode を見落とす事故を減らせます。

2. 段階的クリーンアップ：順序がポリシーになる

第一段階は再ダウンロード・再ビルドで復元できるパスだけ：パッケージキャッシュ、ジョブ用 /tmp、期限の切れた .xcresult アーカイブなど。第二段階は再生成は高コストだが許容できる領域：DerivedData、Docker BuildKit キャッシュ、宙に浮いたイメージ。コマンドとプラン境界は前述の Docker 記事と揃えるとレビューが楽です。第三段階は変更管理が必要な永続ボリュームと監査ログ。受信実行チェーンに関わる保持期間は、OpenClaw Runner 記事の監査フィールド設計と突き合わせ、「ディスク確保のために証跡だけ消す」ことを防ぎます。

3. コンテナ層、統合ログ、プラン境界

Docker イメージ層は SSD 上で積み上げ書き込みになり、並列ビルドが多いと IOPS と空きブロックを同時に削ります。統合ログにサイズ上限がないと、数ヶ月で単一 Runner でも数 GB 単位に膨らみます。プラン内の 256 GB / 512 GB を「システム + ツールチェーン + 二週間ローリング成果物 + 15% バッファ」としてモデル化し、バッファが尽きると CI 失敗だけでなく Spotlight やキーチェーン保守まで遅くなる、と説明できるようにしておくと調達と合意が取りやすいです。log config の max-size とホスト側 newsyslog / aslmanager をベースイメージに焼き込む方が、事後の rm -rf より安上がりです。

Xcode とコンテナ手順を同居させるマシンでは、週次の短い「読み取り専用体检」ウィンドウを推奨します：df -h、df -ih、上位の du -sh *、docker system df。結果を追記専用のオブジェクトストレージやチケットに残すと、「先週から何が肥大化したか」が比較でき、ディスクが真っ赤になってから全員で grep する羽目を避けられます。

4. まとめ

健全な Runner 運用は割当が観測でき、掃除が繰り返し可能で、境界が説明できることです。同じ数字を SRE のアラートと調達資料の双方に使えると、「なぜ次のティアでディスクを上げるのか」が一貫して伝わります。本稿の層分け表をオンボーディングに貼れば、初当番でも inode の地雷を踏みにくくなります。