macos-cleaner

macOS クリーナー

ディスク容量を圧迫している実際の原因を特定し、承認された領域のみを解放して、クリーンアップによってユーザーデータや同居するサービスが損なわれていないことを確認します。

エントリールーター

依頼に答えられる範囲で、最も限定的な経路を選択します。

ユーザーの兆候	経路
Apple Content Caching、AssetCacheManagerUtil、CacheUsed、ActualCacheUsed、iCloud キャッシュ、または「Caching needs more space」	調査やコマンドの提案を行う前に、references/apple_content_caching.md を最後まで読んでください
Docker、OrbStack、イメージ、コンテナ、またはボリューム	references/docker_analysis.md を読んでください。すべてのオブジェクトを調査し、prune 系のコマンドは決して使用しないでください
Docker ビルドキャッシュ	docker builder du で計測してください。このスキルでは計測結果を報告しますが、削除は行いません。Docker が個々のレコードの意図に応じた操作ではなく、カテゴリ全体を対象とする prune 制御を提供しているためです
Chrome、ChromeDriver、Playwright、Codex Computer Use、Edge、または Chromium に大きな *.code_sign_clone ディレクトリがある	references/chromium_code_sign_clones.md を最後まで読んでください。付属のアナライザーを使ってアクティブ、非アクティブ、不明な各子ディレクトリを区別し、du の値を物理的な空き容量の増加と決して同一視しないでください
名前が特定されたキャッシュ、ディレクトリ、アプリケーション、またはサービスがすでに疑わしい対象になっている	まずその対象を調査し、references/cleanup_targets.md で該当する仕様を読んでください。ホームディレクトリ全体やディスク全体のスキャンから始めないでください
最近何が増加またはディスクを圧迫しているか、2 回の計測の間に空き容量が減ったか、または以前のスキャンのエクスポート（GrandPerspective のテキストエクスポート、保存済みの du 出力）があるかをユーザーが尋ねている	references/growth_attribution.md を読んでください。サイズ順ではなく、書き込み元を示す行を含む差分テーブルで回答してください
原因が本当に不明	以下の一般的な分析ワークフローを使用してください。Mole は任意であり、常に最初に使うものではありません

ユーザーが指定した対象範囲の除外は、一般的なスキャンの提案より優先されます。ユーザーが除外した場合は、個人用ディレクトリ、認証情報、データベース、アプリケーションの状態、無関係なサービスを調査しないでください。

安全性と承認に関する契約

1. 観察と変更を分けます。 まず読み取り専用の診断を完了してください。この段階では、削除、サービスの停止、設定の編集、ツールのインストールやアップグレード、状態を変更する可能性があるクリーンアップのプレビュー実行を行わないでください。

2. 対象を正確に確認します。 リモートの Mac では、ほかの作業を始める前に、現在のホストの識別情報を記録してください。IP、古い PID、ディレクトリ名、過去の報告からマシンを推測してはいけません。

3. 依頼する前に計画します。 状態を変更する前に、すべてのコマンドと、それぞれが変更する内容、回収できると見込まれる物理容量、影響、復元可能性、実行後の条件を列挙してください。その後、ユーザーが計画のみの段階を求めている場合は停止してください。

4. 依頼する前に既存の承認を確認します。 ユーザーが正確な確認フレーズを提示した場合は、そのフレーズを必須としてください。それ以外の場合は、明示されたクリーンアップ指示を、指定された範囲と条件の中で再利用してください。「安全だと証明できたものは何でもクリーンアップして」という指示の場合は、正確な対象を、検証済みの使い捨て可能な内容、非アクティブであること、保持されているソース／状態、復元コストと照らし合わせて特定し、再度確認を求めずにその対象を実行してください。内容が不明なもの、固有の作業、アクティブなリソース、またはより広い範囲には、別途判断が必要です。ほかの人が使用していないという報告は証拠にはなりますが、承認にはなりません。

5. 正確でサポートされている制御手段を使い、既知の不具合を事前に確認します。 アプリケーションがサポートするキャッシュ管理コマンド、または特定のオブジェクト ID を優先してください。「公式」や「正確」であることは安全性の証拠にはなりません。そのため、サポートされた制御コマンドを初めて実行する前に、インストール済みバージョンにおけるその正確なコマンドの既知の問題を確認してください。具体的には、ツールの課題トラッカーでコマンド名を検索し、さらにインストール済みバージョンより後のリリースで修正された問題がないか、変更履歴を確認します。バージョンに関連する未解決の不具合があるコマンドは、このスキルでサポートされた制御手段とはみなしません。次のルールで述べるカテゴリ全体を対象にするコマンドと同様に扱い、修正済みバージョンへのアップグレード、または正確なパスを指定する代替手段のいずれかを使用してください。サポートされた制御手段がない場合は、所有者を検証し、アプリケーションが停止しているか、ディレクトリが別の方法で非アクティブであることを確認し、再構築／再ダウンロードの影響を説明して承認を得た後に限り、アプリケーションが所有する特定のキャッシュディレクトリを削除できます。広範囲のキャッシュルートや、アクティブなアプリケーションの状態は対象にしてはいけません。

6. Docker の prune 系コマンドは絶対に使用しないでください。 これには image、container、volume、system、builder、buildx の prune が含まれます。カテゴリ全体を削除するコマンドでは、オブジェクトごとのユーザーの意図を反映できません。

7. 広範囲を破壊するシェル形式は避けます。 広範囲に及ぶ rm -rf や glob による削除を推奨または実行しないでください。正確に特定され、承認された一般ファイルには、Finder のゴミ箱を優先してください。付属の旧式ヘルパーは完全に削除し、以下に記載された限定的なガードしかありません。ゴミ箱と同等のものとして扱ってはいけません。

8. 価値ある状態を保持します。 報告上の節約容量を増やすためだけに、ユーザーのドキュメント、認証情報、SSH 関連データ、アクティブなデータベース、アプリケーション設定、稼働中のサービスの状態を対象にしてはいけません。ファイルを削除する前に references/safety_rules.md を読んでください。

9. 実行はユーザーの承認に従います。 ユーザーが分析のみを求めている場合や、コマンドを自分で実行したい場合は、コマンドを引き渡してください。既存の明示的な承認が検証済みの対象を網羅している場合は、承認された操作を正確に実行し、その結果を検証してください。無人で定期的に削除する仕組みは、作成または有効化する前に別途承認が必要です。

10. 影響を受ける対象では、異常時に速やかに中止します。 コマンドが予期せず非ゼロの終了コードを返した場合、実行後の条件が一致しない場合、予期しない対象が見つかった場合、または依存関係が変化した場合は、その操作を停止してください。lsof の終了コード 1 と出力なしのような、文書化されたプローブのステータスは、失敗と判断する前に解釈してください。未解決の状態は保持し、独立した承認済みの対象については続行してください。任意のバックアップに失敗した場合は、転送ツールを変更したり再試行したりする前に、バックアップが必要かどうかを再評価してください。

11. 削除によって物理容量が解放されると約束する前に、その仕組みを特定し、推測ではなく作成時のコマンドから確認してください。 名目上の du の合計値と、実際に回収された容量との間に df 上の差がある場合、考えられる仕組みの一つが働いています。そして、最も強い証拠は、そのフォルダーを作成したコマンドの原文です。 空間の意味を決めるのは、コピー動作そのものだからです。推測を始める前に、セッション履歴からそのコマンドを探してください。フォルダー名やサイズに基づく推測は、仕組みを特定したことにはなりません。コマンドが見つからない場合に限り、その差は unknown のままにしてください。実証できる仕組みの代わりに、もっともらしく聞こえる仕組みを当てはめてはいけません。 du の報告内容と、削除によって解放される容量の違いで判別できる仕組みです（いずれも 2026-09-19 に、ドリフトを制御した 1 GiB のソースで測定）。

    作成方法	du の表示上の容量	コピーを削除すると解放される容量	判別の手がかり
    cp（オプションなし）／cp -a	全容量。パスごとに計上	全容量	inode とエクステントが独立
    cp -c / cp -cR（clonefile）	全容量。パスごとに計上	≈0	inode は異なる、nlink=1、エクステントを共有
    ln / cp -l（ハードリンク）	一度だけ計上 — 同じデータを指す別パスでは 0	≈0	同じ inode、nlink=2
    ローカル APFS スナップショット	全容量	スナップショットが間引かれるまでは ≈0	tmutil listlocalsnapshots /

    この表が解消するべき落とし穴は 2 つあります。clonefile とハードリンクの行は、du では正反対ですが、削除時の挙動は同じです。どちらも解放される容量は ≈0 なので、「削除しても何も空かなかった」だけでは区別できませんが、du なら区別できます。ハードリンクされた別パスは一度だけ（または 0 と）計上され、clonefile のコピーは全容量が計上されます。また、異なるコピー方法で調べても、何も証明できません。フォルダーの作成に cp -cR を使ったのに、調査にオプションなしの cp を使ったため、98 GiB の差を誤った仕組みに二度も帰属させていました。何かを削除する前に、作成時のコマンドと同じフラグで調査してください。clonefile はよく使われるため、注意が必要です。macOS の cp は -c を指定するとデフォルトでこれを使い、納品用やキット用にコピーしたディレクトリーにも頻繁に含まれています。

フェーズの規約

あらゆるクリーンアップで、次の状態機械を使用してください。

1. 観察 — 読み取り専用。 ID、ディスクのベースライン、対象サブシステムの状態と構成、物理的な割り当て、重要なサービスの健全性を記録します。 1b. 避けられない場合は、状態を変更する調査の承認を得る。 一時コンテナーの作成、イメージのプル、ボリュームのマウント、スナップショットの書き込みが追加の証拠の取得に必要な場合は、まずメタデータのみの観察を完了し、調査コマンドとその副作用を正確に列挙して、個別に承認を得てください。調査の承認は、クリーンアップの承認ではありません。
2. 計画 — 変更なし。 Phase 2 の開始条件を最初に満たしてから、調査結果、コマンド、影響、復旧方法、予想される解放容量、成功条件を説明します。承認がない場合、またはユーザーが計画のみのフェーズを求めている場合は、確認ゲートで停止します。
3. 実行 — 承認された範囲のみ。 実行直前に現在の状態を読み直し、承認されたコマンドを 1 つずつ実行して、それぞれの終了ステータスと事後条件を確認します。
4. 検証 — 独立した読み取り確認。 ディスク容量とサブシステムの状態を再測定し、保護対象のサービスを再確認して、すぐに容量が再び埋まる兆候がないか十分な時間観察します。

承認がない場合は、フェーズ 2 と 3 の間で停止してください。計画を提示しても承認を得たことにはなりません。既存の指示ですでに検証済みの対象と影響がカバーされている場合は、同じ許可を改めて確認せず、ゲートの通過後に進めてください。

バックアップを作成する前に削除の基準を選定する

• 固有のソース編集、ローカルの Git 状態、認証情報、データベース、ユーザーレコードを保護してください。ディレクトリ名、経過時間、または lsof の結果が空であることだけでは、削除してよいとは判断できません。バックアップを取っても、正当な根拠のない削除が正当化されるわけではありません。
• 休止中で再現可能な依存関係ディレクトリ、ビルドキャッシュ、または提供終了したパッケージ済みテスト App については、そのソース／ロックファイルまたは現在のインストールと、再構築にかかるコストを明記してください。ユーザーからその成果物の保持を明示的に求められていない限り、2つ目の完全なコピーをアーカイブ、複製、展開、またはハッシュ化しないでください。手作業による編集、入手不能なプライベートパッケージ、または埋め込まれた固有の状態を示す証拠があれば分類は変わりますが、想像上の可能性では変わりません。
• 「安全」とは、固有の作業を失わず、稼働中の使用を妨げず、復元コストが把握されている状態を指します。使い捨て可能なすべての成果物をバイト単位で完全に復元できることを、この条件の代わりにしないでください。ユーザーが破棄すると明示的に選択した提供終了済みバイナリについて、完全な再現性を求めないでください。
• 保持候補ごとに、処理を妨げている具体的な事実と、次に行う最小限の確認事項を示してください。タスク内でそれらの確認を解決してください。「不確か」であることも、空き容量が多少改善することも、既知の候補を未確認のままにして、許可されたクリーンアップを完了したことにはなりません。
• 必要なバックアップ、コピー、展開を行う前に、コピー先ホストで既存のプランチェッカーを --copy-budget <manifest.json> とともに実行してください。圧縮前のソースサイズを基準として、同時に保持されるすべてのアーカイブ、展開済みツリー、検証用コピー、再試行時の部分ファイルを計上してください。圧縮や APFS の共有によって容量を節約できると想定しないでください。各段階の前にコピー先の空き容量を再確認し、申告した予備容量を維持できない場合はそのコピーを停止してください。独立したクリーンアップは続行してください。マニフェストの仕様と制限については references/safety_rules.md を参照してください。

フェーズ 1：読み取り専用の診断

ベースラインを確認する

最低限、次の情報を取得してください。

/bin/date "+%F %T %Z %z"
/usr/sbin/scutil --get ComputerName
/usr/sbin/scutil --get LocalHostName
/usr/bin/sw_vers
/usr/sbin/sysctl kern.boottime vm.swapusage
/bin/df -k /System/Volumes/Data
/bin/df -h /System/Volumes/Data

計算には df -k を使用し、人が読みやすいレポートには df -h を使用してください。拡張子、ラベル、古いレポートは、実行中のコマンドで確認できるまでは手掛かりとして扱ってください。

ユーザーから提示された空き容量または容量の目標は、そのまま正確に転記してください。読み取り専用のインベントリは、目標が提示されていなくても実施できます。現在の値を報告し、許可された読み取り範囲内で容量を最も多く占めているものを特定してください。クリーンアップの目標を尋ねるために、診断を遅らせないでください。明示的な目標のないクリーンアップでは、ユーザーの容量目標を達成したと主張できません。代わりに、測定した空き容量の増加と残りの候補を報告してください。

この最初のフェーズでは、読み取り専用の操作に限定してください。scripts/cleanup_report.py はローカルの状態ディレクトリとスナップショットファイルを作成するため、まだ実行しないでください。代わりに、コマンド出力をレポートに記録してください。リモートの対象では、必ずそのホスト上で直接 df コマンドを実行してください。ローカルのヘルパーが誤ってコントローラーの Mac を測定しないようにしてください。

名指しされた疑わしい対象を、広範なスキャンより先に調べる

• サブシステム独自の状態と設定を確認します。
• 権限とユーザーの範囲が許す場合に限り、正確なデータパスに対して範囲を限定した du を実行し、物理的な割り当て量を測定します。
• 論理コンテンツサイズ、スパースファイルの見かけ上のサイズ、パージ可能な容量、物理的に割り当てられたバイト数を区別します。
• APFS クローンの場合、du の値には物理サイズではなく、パスごとの計上値または名目サイズというラベルを付けてください。共有エクステントは各パスに計上される場合があるため、実際に削減される容量は削除後の df の読み取りまで不明です。
• ログの増大が疑われる場合は、正確なファイルサイズを2つ以上の時点で記録してください。ファイルが1つ大きいことや、mtime が最近であることだけでは、継続的な増大の証拠になりません。
• ユーザーが重要と指定した同居サービスについて、現在のプロセス、リスナー、起動方法、サポートされているヘルスチェックを記録してください。各チェックポイントで PID を再解決してください。

既知の疑わしい対象だけでユーザーの空き容量目標を達成できる場合は、「念のため」と称して無関係な個人用ディレクトリや開発用ディレクトリをスキャンしないでください。

発生源が不明な場合の一般的な分析

まず、占有状況の調査とクリーンアップ対象の選定を分離します。承認された各ルート内で、1回の浅いサイズ内訳（たとえば du -x -k -d 1 "<approved-root>"）を取得します。隠し子要素も含め、アクセスできないパスは不明として記録し、完了した測定は再利用します。保持しなければならないものであっても、最大の占有者を表示します。小さいキャッシュにもう一度パスを費やす前に、最大の未解明のブランチを深掘りします。状態が変わっていない限り、完了した兄弟要素を再スキャンしないでください。これは読み取り専用のサイズ測定であり、ファイル内容の読み取りや何かの削除の許可ではありません。以下に示す承認済みパス契約は、コンテンツを含むルートに引き続き適用されます。

次に、関連する占有者を分類できる、以下の中で最小の順序付きシーケンスを実行します。クリーンアップ対象については、候補がそれを満たすには、サポートされた正確なアクションと、正当化できる予想物理解放量が必要です。生の割り当て合計、論理キャッシュサイズ、共有 Docker レイヤー、Trash への移動、検証されていない「削減可能量」は、停止条件を満たしません。インベントリのみのリクエストの場合、承認されたルートの最大占有者とカバレッジのギャップが説明された時点で停止します。削除は承認待ちのままにします。

物理的信頼度のランキングで、ユーザーの最大の可視ホットスポットを隠さないでください。名目上/パスで計上された候補が推奨アクションより大きい場合は、両方の数値を示し、その物理解放量が不確実である理由を説明します。正当化できる物理解放量、安全性、労力でランク付けし、名目サイズは、暗黙にゼロまたは完全に回収可能として扱うのではなく、別の列として報告します。

順序 / シグナル	読み取り専用アクション	停止または続行
1. 常に	識別情報と df -k/-h を取得し、ユーザーの除外項目をインベントリ化	ターゲット不一致で停止
2. キャッシュ/ログの圧迫があり、~/Library/Caches、~/Library/Logs、および XDG 開発キャッシュが読み取りスコープとして承認されている	uv run scripts/analyze_caches.py --user-only --include-dev	測定された候補がターゲットを満たせる場合に停止
3. 開発者ツールが存在し、スクリプトの固定スコープが承認されている	uv run scripts/analyze_dev_env.py は Docker/パッケージマネージャー、および既存の ~/Projects、~/workspace、~/dev、~/src、~/code ルートを読み取る	Docker/OrbStack の検出事項は専用のリファレンスに振り分ける。固定ルートのいずれかがスコープ外の場合はこのヘルパーをスキップする
4. アンインストール済みアプリの残留物が考えられ、その固定ルートが承認されている	uv run scripts/find_app_remnants.py は /Applications、~/Applications、および文書化された4つの ~/Library アプリケーション状態ルートを読み取る	すべての結果を候補として扱い、放棄の証明とは決して見なさない。そのスコープが承認されていない場合はスキップする
5. コンテンツを含むパスが明示的に承認されている	uv run scripts/analyze_large_files.py --threshold 100MB --path "<approved-path>"	パスが承認されていない場合、~、Downloads、Documents、またはデータボリュームルートで代用しない
6. 境界のあるチェック後も依然として不明で、ユーザーが Mole の固定された広範なスキャンルートを明示的に承認している	references/mole_integration.md を読み、TTY 経由で mo analyze を使用する	Mole は任意のパススコープを受け入れられない。承認がその文書化されたルートより狭い場合はスキップする

<approved-path> とは、ユーザーが指定した、またはそのスコープが説明された後に明示的に受け入れた正確なパスです。存在しない場合は、大容量ファイルおよび重複コンテンツのスキャンをスキップし、この証拠ブランチは承認されなかったと述べ、コンテンツを含まない証拠で続行します。ユーザーがその変更を別途承認しない限り、読み取り専用フェーズ中に Mole をインストールまたはアップグレードしないでください。

Mole のアナライザーは、ホームディレクトリ、アプリケーションデータ、システムライブラリ、アプリケーション、およびボリュームを含む固定セットをスキャンします。結果内をナビゲートしても、基になるスキャンがパススコープになるわけではありません。その広範な読み取りスコープが承認されていない場合は、Mole を実行しないでください。すでに収集された境界のある証拠で停止するか、計画内で不足しているスキャン承認を求めてください。 明示的に承認された重複ファイル調査については、references/cleanup_targets.md の「Optional duplicate files」セクションをお読みください。読み取り専用で、自動削除オプションは決して使用しません。

大きなデータフォルダーはキャッシュではありません。削除を提案するには、サイズ順ではなく証拠の連鎖が必要です。 調査で大きなプロジェクトアセット／メディア／データセットのディレクトリ（キャッシュでもアプリの残骸でもないもの）が見つかった場合、サイズだけを根拠にアクション対象へ入れてはいけません。references/proving-redundancy-before-deletion.md を読み、その段階を順に進めてください（ファイルレベルの重複 → 作成元 → 参照の確認 → セッション履歴のツール呼び出し調査 → .DS_Store による手動使用状況の追跡 → プロジェクト独自の判断記録）。何かを提案する前に、これらを確認してください。成果物は証拠の表です。立証できない項目（完全に手動で使用されているもの）はユーザーに提示し、曖昧に処理してはいけません。

調査をサブエージェントに分担させる場合、各サブエージェントが返すのは候補と測定値のみです。分類、採用判断、提案は、Phase 2 のエントリーゲートを実行するセッションで行います。サブエージェントのインベントリは分類表への入力であり、計画そのものではありません。

Docker と OrbStack

Docker の削減量を報告する前に、references/docker_analysis.md をお読みください。イメージ、コンテナ、ボリュームをすべて個別に列挙し、参照先とデータベースのような内容を調査し、見かけのサイズではなく実際のスパースファイルの割り当て量を使用してください。「dangling」と報告されたリソースであっても、そのデータに価値がない証拠にはなりません。ビルドキャッシュの測定はサポートされていますが、利用可能な Docker の制御が prune 系の操作であるため、ビルドキャッシュの削除は意図的に対象外としています。

Phase 2：報告と承認の確認

Phase 2 のエントリーゲート

実際の 2026-09-19 の実行では、Phase 1 の手順に忠実に従ったにもかかわらず、問題のある計画が 3 つ作られました。ルールが references/cleanup_targets.md にあるため、調査ワークフローで一度も開かれないそのファイルのルールを見落とし、デフォルトで保持するキャッシュ（npm _cacache、Playwright ブラウザー、Homebrew）を「低リスクの組み合わせ」として提案しました。また、--help の記述とサイズ比だけを根拠に、セマンティクスもインストール済みバージョンも確認せず、uv cache prune を影響ゼロとして提案しました。さらに、空き容量の目標が設定されていなかったため、91 GB の候補と並べて 2 GB の項目を先に提示しました。この 3 つすべてを防げるルールは、すでにこのスキル内に存在していました。しかし、その手順では開かれない参考資料に書かれていたため、実際にはルールとして機能していませんでした。文章によるチェックリストは、要約対象の参考資料よりわずかに優れているにすぎません。このゲートの初稿に対する独立レビューでは、重大な欠陥が 13 件見つかり、最も根本的な問題は、ゲート自体に機械的な強制手段がなかったことです。そのため、ステップ 4 は約束ではなくスクリプトです。これを実行しなければ、計画は存在しません。

1. 報告する結果を明示します。 クリーンアップ対象については、ユーザーが指定した値をそのまま使用します。指定がない場合は、占有状況のインベントリまたは優先順位付きの判断リストを提示します。容量目標を勝手に設定したり、目標を達成したと主張したりしてはいけません。

2. references/cleanup_targets.md を開き、調査で得られたすべての候補を次の表に分類し、ファイルに書き出します（ステップ 4 で解析されます）。

   対象	公称サイズ	物理的な確実性	分類	適用ルール（原文の引用）	予想される実際の解放容量と根拠	復元コスト	判定
   正確な対象：パス、サービス設定（例：AssetCacheManagerUtil や plist キー）、またはサポート対象のコントロール（例：chrome://settings/clearBrowserData）	du の出力	path-accounted（Phase 1 で APFS 共有または公称 du を示すラベル）／sparse-aware／engine-reported（Docker の system df など、サブシステム独自の集計）／unknown — 公称値を解放容量として入力しないこと	PRESERVE／PROPOSABLE／REBUILDABLE／USER-DATA／USER-DECISION	cleanup_targets.md、経路専用のリファレンス、またはこのスキル自体の SKILL.md からの引用（チェッカーはバンドル全体に対して各引用を検証し、ファイルごとの出典を出力するため、SKILL.md だけからの引用も確認できます）。「ルールが見つからない」も、それ自体が所見です	推定値と算出根拠。unknown も許容される値です	再ダウンロード／再構築のコスト、または n/a	アクション対象／アクション対象外／ユーザーの判断で解除（方針を引用）

   • PRESERVE — cleanup_targets.md の「デフォルトで保持」テーブルにあるすべての行（このステップで開き、テーブルに引用します。ステップ 4 で引用を検証するため、捏造した引用は失敗します）。次のいずれかに該当しない限り、アクション対象外です。（a）対象が一度も使われていないことを示す証拠が検証済みである、または（b）コストを承知したうえで、ユーザーがその対象を明示的に削除対象として指定する。提示されたコストを受け入れることは（b）に該当しません。ユーザー自身が対象を指定する必要があります。
   • PROPOSABLE — 一度も使われていないことを示す証拠が検証済みである（使われなくなったプロジェクト、ユーザーの明示的な発言、アーティファクトの確認）。サイズの比率は証拠になりません。「キャッシュには 586 個の環境があり、プロジェクトの venv は 28 個存在する」ことは、残りの 558 個について何の証明にもなりません。
   • REBUILDABLE — 「デフォルトで保持」テーブルにはなく、サポート対象の管理コマンドまたは低コストの再構築方法（Homebrew、pip）があり、復元コストが行に記載されています。
   • USER-DATA — アクション対象に含めることはありません。場所を報告し、コマンドは提示しません。
   • USER-DECISION — ユーザーのワークフローや所有状況に関する知識に基づいて判断します。提案せず、質問してください。また、どのリファレンスにも記載のない対象（「ルールが見つからない」）もここに分類します。計画では、それらを提案する前に確認を求めます。

   どのリファレンスにも対象に関する記載がない場合は、「ルールが見つからない」と伝え、USER-DECISION に分類します。無関係なルールを無理に当てはめてはいけません。

3. ゲートルールを適用します。 ステップ4のチェッカーは各ルールを機械的に適用します。これによって、ルールは単なる注意事項ではなくなります。

   • アクションセットには、「アクションセットに含める」と記された行と、「ユーザーの指示で解除」と記された行のうち、ユーザーの指示を引用した行だけを含めます。状態を変更するコマンドで、表にない対象を指定してはなりません。PRESERVE 行がアクションセットに入るのは、「未使用」を示す証拠、または明示的なユーザーの指示がある場合に限られます（ステップ2）。
   • 計画では、予測される物理的な解放量が最大のアクションセット内の行を最初に扱います。ただし、表に別の行が、理由を明記したうえで、ユーザーに見えるホットスポットまたはボトルネック（実際にディスク容量の圧迫に関係するもの）として示されている場合は除きます。それ以外の行を最初に扱うと、このゲートに違反します。これは慎重すぎるのではなく、小物にばかり手を付ける失敗です。名目上のサイズだけで順位を決めてはなりません。名目上のサイズは解放量ではなく、共有エクステントの候補は、削除して df の読み取り結果を確認するまで解放量が不明です（ステップ2のラベルを参照）。
   • 破壊的なコマンドごとに、所有ツールのインストール済みバージョン（アプリケーションの制御コマンドやサービスコマンドの場合は、所有するアプリケーションまたはサービスのバージョン）、セマンティクスの情報源（ツール自身のヘルプまたはドキュメント。利用可能な情報源がこのスキルによる書き起こししかない場合は、その旨を記し、実際のツールで手軽に検証します）、およびカテゴリ全体に適用されるコマンド（オブジェクト単位で選択せず、オブジェクトのクラス全体を対象とするコマンド。スキル内で使われている用語は prune-family です）の場合は既知の問題の確認を記録します。uv cache prune、npm cache clean、brew cleanup --prune、Docker の prune ファミリーは、定義上、カテゴリ全体に適用されるコマンドです。
   • スキルで未承認とされているコマンド（uv cache prune、npm cache clean、Docker の prune ファミリー）は、ほかのすべてのルールを満たしていても、サイズやバージョンを問わずアクションセットに含めてはなりません。npm cache clean は、デフォルトで保持する _cacache を全体的に消去するため、このリストに含まれます。該当するコマンドそのものを明示的にユーザーが指示した場合に限り、アクションセットに加えることができます。その場合は提案としてではなく、指示された操作としてフェーズ3で実行します。
   • アクションセットに含まれる行がゼロでも、正当な結果です。順位付けした判断リスト（PRESERVE 行と USER-DECISION 行、それぞれの解除コストと根拠を含む）を提示し、どの項目を解除するかユーザーに尋ねます。判断リストを添えた空のアクションセットは合格です。行を捏造したり、アクションセットを埋めるために PRESERVE の指定を格下げしたりしてはなりません。

4. 計画をファイルに書き込み、送信前にチェッカーを実行します。

   uv run scripts/check_gate_plan.py --table <gate-table.md> --plan <plan.md>
   

   終了コード0は必要条件ですが、認識されないコマンドを認証するものではありません。検査したコマンドの数と、すべての網羅性診断を確認してください。削除を提案しているのに検査されたコマンドが0件なら、その提案は未検査です。認識される正確な形式を使うか、実行前にそのコマンドの対象範囲とセマンティクスを独自に特定してください。「網羅性が不完全」という診断の横に PASS が表示されていても、承認とみなしてはなりません。チェッカーは、表の分類、ルールからの逐語的な引用、認識された破壊的コマンドの対象、アクションのクラスと解除ルール、デフォルトで保持する対象の保護、カテゴリ全体に適用されるコマンドの除外、解放量に基づく順位付け、ツールの検証を確認します。uv run と、相対パスまたは絶対パスでスクリプトを指定する safe_delete.py の Python 呼び出しを認識し、各リテラルの対象を個別に確認します。解決されていないバッチファイルとシェル展開は、網羅性の検査に合格しません。実行に失敗すると、違反したルールが示されます。計画を修正してください。チェッカーを弱めてはなりません。 チェッカーが確実に検出する 5 つの失敗パターン。実際の 18 ターゲットのプランを終了コード 0 で終わらせる過程で測定したものです。5 つすべてがプラン側の修正であり、チェッカー側の修正は決して必要ありません:

   • パス形式の不一致 (target_coverage): テーブルには、コマンドが使用するのと同じ完全な絶対パスを記載する必要があります。~/ の省略形の行は、/Users/… を指定するコマンドとは一致しません。
   • 1 行に 2 つのターゲット: ペアになった 2 つのターゲットを記載した行は解析に失敗します。ターゲットごとに 1 行に分割してください。
   • リリース列の「du nominal」 は名目値として読み取られ、拒否されます。代わりに期待リリースをどのように導出したかを記述するか、unknown と入力してください。
   • テーブルセル内の 1 行の osascript はパイプ区切りのチャンクに分割され、コマンドマッチャーが再結合できません。正規の複数行 osascript はテーブル行ではなく、プランのコードブロックに記載してください。
   • コマンド名を地の文に書く (osascript に言及した導入文) と、一致する行のないコマンド開始として解析されます。コマンド名は地の文に書かず、テーブル行はラベルではなくパスで始めてください (OrbStack で始まる行は失敗します)。

推測されたプロパティではなく、観測された値を報告してください。長文形式のレイアウトには references/report_templates.md を使用し、提案するすべてのアクションに以下のフィールドを含めてください:

フィールド	必須の内容
現在の状態	タイムスタンプ、ターゲットの識別情報、ディスクの使用量/空き容量/容量、およびサブシステムのステータス
根拠	コマンドと観測値。その数値が論理値か物理値かを明記する
正確なコマンド	状態を変更するコマンド。正確なターゲットまたはオブジェクト ID を含める
変更	コマンドが変更または削除する内容
復元可能性	可逆コマンド、ゴミ箱からの復元、バックアップからの復元、または再ダウンロードのみ
期待リリース	単位と前提条件を含む物理空間の見積もり
サービスへの影響	ユーザーに表示される影響と保護対象サービスの不変条件
事後条件	アクションが成功したと見なされる前に真でなければならない値

数値の魅力度ではなく、結果に基づいて検出項目を分類してください:

• 再構築可能なキャッシュ: 削除で失われるのはローカルコピーのみですが、再ダウンロードまたは再構築のコストを記述してください。再構築可能であることは、デフォルトで提案可能であることを意味しません: references/cleanup_targets.md のデフォルトで保持するテーブル (フェーズ 2 のエントリーゲートで開かれ引用される) が決定します。これらのターゲットは、未使用の証拠または明示的なユーザーの指示によって移動されるまで、アクションセットから除外されます。
• ユーザーの判断が必要: 価値がユーザーのワークフローまたは所有権に関する知識に依存するもの。
• 保持: ユーザーデータ、認証情報、データベースの状態、アクティブな設定、またはその役割が不明確なもの。

ソフトウェアが再生成できるという理由だけで、キャッシュを「絶対に安全」と呼んではいけません。再生成時間、帯域幅、認証、オフラインでの可用性は現実のコストです。

フェーズ 3: 確認済みプランの実行

最初の状態変更コマンドの直前に:

1. ターゲットの識別情報と現在のディスク状態を再確認します。
2. オブジェクトまたはサブシステムのステータスを再クエリします。クリーンアッププランはライブ状態が変化すると失効します。
3. 保護対象サービスの健全性を再確認します。
4. 承認されたコマンドと正確なターゲットセットを、これから実行するコマンドと比較します。より広い、または異なるターゲットセットには新たな承認が必要です。別途保持された項目が非アクティブになっても、それが明示的に除外されたままであり、承認されたターゲットセットのハッシュが依然として一致する場合、プランは無効になりません。 承認対象と除外対象は、元のインベントリに紐付けたままにしてください。「これらを削除し、残りは保持する」という指示で承認されるのは、指定された対象のみです。「調査を続けて」という指示の場合は、読み取り専用の検出を再開します。承認されたパスの一部が見つからない場合は、バッチを停止し、当初の数、残っている数、見つからない数を報告してください。より少ない対象で続行できるのは、それらがインベントリの一部であり、識別情報／内容と影響に変更がないことを証明した後だけです。既存の承認は、検証済みの残りの対象にも適用できます。同じパスに新しく生成された代替物は、対象が変更されたことになります。同僚の「操作なし」という報告をユーザー承認の代わりにしたり、すでに存在しないパスをこの実行で削除したと報告したりしないでください。従来のヘルパーは対象が見つからないと処理を停止します。再び実行する前に、計画を調整してください。

承認済みの計画にローカルの実行前／実行後レポートファイルの作成が含まれる場合は、最初のクリーンアップコマンドを実行する前に、承認後のこの時点で実行前のスナップショットを取得してください。

uv run scripts/cleanup_report.py --snapshot before

これは ~/.macos-cleaner 内に書き込むため、計画に記載してください。これは任意で、ローカルの対象に限られます。直接取得した df -k/-h の読み取り値を、引き続き信頼できる情報源としてください。リモートの対象を測定する代わりに、コントローラー Mac でこれを実行してはいけません。

状態を変更するコマンドは、一度に1つだけ実行してください。次のコマンドを送る前に、結果を確認してください。コマンドを実行するたびに、成功と部分的な成功を区別できる事後条件を確認してください。

ユーザーデータ、アプリケーションの状態、データベース、保護対象のパスではない通常のファイルについては、ユーザーが正確なパスを確認した後、元に戻せる Finder のゴミ箱への移動を優先してください。

/usr/bin/osascript \
  -e 'on run argv' \
  -e 'tell application "Finder" to delete (POSIX file (item 1 of argv))' \
  -e 'end run' -- "<exact-path>"

通常、ゴミ箱を空にするまでは物理的な空き容量は増えません。その旨を計画に記載してください。

リモートおよびヘッドレスの対象では、Finder 経由の操作にオートメーションの許可が必要です。許可がないと、ssh 経由の AppleEvents はハングします。 2026-10-07 にヘッドレスワーカーで測定したところ、osascript で上記のゴミ箱への移動を実行した ssh セッションは、無期限にブロックしました。9つの対象を処理した後も、最初の対象が残ったままで、ゴミ箱にも変化はなく、無害な Finder の確認 (count of items) さえ戻りませんでした。捕捉できるエラーはありません。無反応であることが、その兆候です。ssh 経由で Finder の操作に頼る前に、まずタイムアウトを設定したプローブを実行し、ハングした場合は Finder の動作が遅いのではなく、チャネルが閉じていると判断してください。標準の macOS には timeout(1) がないため、AppleScript 内でタイムアウトを設定します。

/usr/bin/osascript \
  -e 'with timeout of 1 second' \
  -e 'tell application "Finder" to count of items of trash' \
  -e 'end timeout'

同じボリューム内での代替手段は、ゴミ箱ではなく隔離場所への移動です。承認された各対象を同じボリューム上のディレクトリ (<approved-dir>/_quarantine-<date>/) に mv し、その隣に MANIFEST（元のパス、サイズ、タイムスタンプ）を書き込みます。mv で元に戻す際に必要なのは元のパスです。この方法にはゴミ箱と同じ安全性があります。同じボリューム上の mv はメタデータのみを変更し、完全に復元可能で、別途承認された恒久削除の段階を実行するまで空き容量は増えません。また、オートメーションの許可も不要です。ゴミ箱の場合と同様に、2つの段階を明確に分けてください。隔離場所への移動と、その後の恒久削除は別々の承認を必要とします。計画には隔離場所と MANIFEST を明記してください。Phase 2 の計画チェッカーは、隔離形式を特定して認識します（先頭が mv で、コマンド表のセルにあるバッククォートは許容されます。最初の引数は引用符で囲まれたトークン、またはパスらしいトークンで、コマンドには _quarantine- マーカーが含まれます）。この形式の各コマンドは、osascript のゴミ箱への移動と同様に、表の該当行に紐付けられます。通常の mv、git mv、sudo mv、隔離を伴わない名前変更、または単に「mv」という語で始まる文章は認識されません。そのため、隔離コマンドでも表内に各対象を明示してください。

scripts/safe_delete.py は、対話型プロンプトと限定的なシステム／認証情報の拒否リストを備えた、従来の恒久削除ヘルパーです。ゴミ箱には移動せず、すべてのユーザーデータのルートを確認することも、開いているファイルを検出することも、解放されたバイト数を独自に証明することもしません。正確に特定されたユーザーデータ以外の対象について、取り消せない削除が明示的に承認されている場合に限り使用してください。

uv run scripts/safe_delete.py <exact-path> [<exact-path> ...]

ユーザードキュメント、Apple Content Caching などのアプリケーションが管理するキャッシュ、データベース、認証情報、または役割が不明確なターゲットには、このヘルパーを使用しないでください。

これらの除外を弱めることなく、限定的な Finder のゴミ箱に関する 2 つの分岐が引き続き利用可能です：

• 検証済みのサポート対象の管理制御が存在しない、正確に非アクティブなアプリケーションキャッシュについては、references/cleanup_targets.md にある名前付きキャッシュの検出/使用中プロトコルに従い、再構築コストを説明し、その正確なキャッシュパスに対して明示的な承認を得てください。
• 正確に承認されたユーザーデータルート内の重複ファイルについては、まず各重複セットのサイズ/ハッシュとすべてのパスを提示してください。ユーザーは保持するコピーと削除する各コピーを指定する必要があります。確認されたファイルのみを Finder のゴミ箱に移動してください。恒久的なヘルパー、自動重複選択フラグ、all、グロブ、ディレクトリレベルのターゲットは決して使用しないでください。移動したソースパスがゴミ箱に移動されたことを検証し、ゴミ箱が別途確認されて空にされるまで物理的な容量が解放されないことを明記してください。

フェーズ 4：検証と観察

検証は承認された計画のすべての条項を網羅する必要があります：

• df -k と df -h を再読み取りし、測定ウィンドウ全体の正味の変化を、削除されたパスで説明できるサイズとは別に報告してください。タイムスタンプと kern.boottime を確認してください：再起動、スワップの解放、または同時書き込みは、これを混合ウィンドウにし、削除が変化全体を引き起こした証拠にはなりません。説明できない残りをディレクトリに押し付けず、報告してください。
• クリーンアップされたサブシステムのアクティベーション、構成、物理使用量を再クエリしてください。
• 保護された各サービスの PID、リスナー、起動メカニズム、ヘルスプローブを再解決してください。健全なディスクはサービスが存続したことを証明しません。不変条件の失敗を報告し、影響を受けるアクションを停止してください。ディスクのクリーンアップは、サービスの再起動、他のセッションの終了、または無関係なアプリケーションの修復を承認するものではありません。
• APFS のアカウンティングが遅延する場合、またはソースが再充填される可能性がある場合は、限られた間隔で観察してください。各タイムスタンプと値を記録してください。
• 空き容量の目標が達成されなかった場合は、すべての削除を停止してください。2 回目の読み取り専用分析を開始し、残りのソースを測定された物理割り当て順にランク付けしてください。

コマンドの終了コードのみが判明している場合に「修正済み」と報告しないでください。クリーンアップの成功には、意図された状態と保護された不変条件の両方が必要です。

ビフォアスナップショットがヘルパーによってキャプチャされたローカルターゲットについては、以下を使用して比較を生成してください：

uv run scripts/cleanup_report.py --snapshot after --compare

リソース

現在のタスクに関連するブランチのみを読み込んでください。

• references/apple_content_caching.md — Apple Content Caching の診断、単位の解釈、サポートされているリモート操作、確認計画、クリーンアップ後の検証。
• references/chromium_code_sign_clones.md — Chrome／Chromium／Edge のコード署名クローンの意味、名目上のサイズと物理サイズの報告、正確な非アクティブ対象マニフェスト、クリーンアップの検証、再発防止。
• references/cleanup_targets.md — キャッシュ、ログ、アプリケーション、開発者、大容量ファイル、Time Machine の対象に関する意味。
• references/proving-redundancy-before-deletion.md — 大容量データフォルダーに関する証拠の段階（重複 → 作成元 → 参照 → セッション履歴の調査 → .DS_Store → プロジェクトの意思決定記録）。大きなプロジェクトアセット／メディア／データセットのディレクトリの削除を提案する前に読み込んでください。サイズの順位は証拠になりません。
• references/growth_attribution.md — 「最近何が増えたか」という質問への対応：ベースラインのエクスポートの検索と調整、未スキャンの落とし穴、「以降に追加されたもの」を判定するファイルのタイムスタンプ、パスごとに集計した差分と df の照合（スワップ、スナップショット、短期間だけ存在するコピー）、書き込み元の特定。
• references/docker_analysis.md — Docker と OrbStack のオブジェクト単位の分析、データベースボリュームの保護策、再補充の根本原因の診断。
• references/mole_integration.md — Mole の対話型分析とプレビューに関する TTY ワークフロー。
• references/report_templates.md — 一般向けおよび Docker 向けの詳細レポートテンプレート。
• references/safety_rules.md — ブロック対象のパス、確認、復旧、ファイル削除の安全性チェック。
• scripts/analyze_caches.py — 範囲を限定したキャッシュのインベントリ。unknown の測定値と診断情報を保持し、不完全な小計は既知の下限として扱ってください。終了コード 1 は、使用量ゼロではなく、測定が不完全か、開発者パスが未解決であることを示します。
• scripts/check_gate_plan.py — Phase 2 開始ゲートのチェッカー。分類テーブルと計画を解析し、参照先に対する準拠ルールの引用、破壊的コマンドの対象網羅性（認識できないコマンド形式もカウントして報告）、アクションセットのクラスと解除ルール、デフォルトで保持するための格下げクロスチェック、カテゴリ全体の除外、先頭行の順位付けルール、ツールの検証を確認します。計画を送信する前に終了コード 0 が必要です。コマンドのホワイトリストには明示された制限があり、リスト外の形式は無視されず、認識できない形式として報告されます。
• scripts/analyze_code_sign_clones.py — 読み取り専用の現在のユーザー向けコード署名クローンのインベントリ。承認後に、正確な候補 SHA を再検証し、上書きしないバッチマニフェストを作成できます。
• scripts/find_app_remnants.py — アプリケーションの残存物候補。固定の Applications と ~/Library のルートを読み取るため、最初にその範囲の承認が必要です。
• scripts/analyze_large_files.py — 承認済みパス内の大容量ファイルを検索します。
• scripts/analyze_dev_env.py — Docker／パッケージマネージャーのインベントリに加え、固定された共通プロジェクトルート内の .git サイズを調べます。まず、その読み取り範囲全体の承認が必要です。
• scripts/safe_delete.py — 正確に承認されたユーザーデータ以外の対象を完全削除する、旧式の保護付き削除機能です。ゴミ箱への移動や復旧のためのツールではありません。
• scripts/cleanup_report.py — デフォルトでは /System/Volumes/Data を対象に、ローカル対象の削除前後をレポートします。--volume で明示的に対象ボリュームを指定できます。

このスキルを使用しない場合

• 対象が Windows または Linux の場合。
• 要求された操作に SIP の無効化または macOS の保護の回避が必要な場合。
• 監査可能な範囲と確認ゲートなしで、ユーザーが無通知または自動の削除を求めている場合。
• タスクがアプリケーションの動作調整のみで、ディスク容量の診断や復旧を目的としていない場合。