Mole CLI と Mole for Mac の使い分け

Mole はふたつのプログラムとして提供されています。mo は Homebrew で入れる無料のオープンソース CLI で、ライセンスは GPL-3.0 です。Mole for Mac は有料のネイティブアプリで、5 つのタブとメニューバー表示を持ちます。トライアル版と Pro 版の関係ではありません。仕事が重なる別実装であり、ディスク上にわずかな共有レイヤーがあるだけなので、どちらかを選んでももう一方が使えなくなることはありません。この記事は、いまの作業スタイルに合う方を選ぶためのガイドであり、両方使うとどうなるかについても書きます。

共通していること

CLI のコマンドのうち 5 つは、アプリの 5 タブにそのまま対応します。mo clean、 mo uninstall、mo optimize、mo analyze、mo status が Clean、 Software、Optimize、Analyze、Status に対応します。カテゴリは両方で認識しやすいものです。 ユーザー／開発者／ブラウザ／システムまわりのキャッシュ群、アプリ一覧と 残骸の発見、ディスク分析、ヘルス指標。ただし実装と候補の正確な集合は 同一ではありません。

スキャン自体はどちらも無料です。アプリが課金するのは破壊的な操作だけであり、各 破壊ツールはライセンス不要で 2 回まで使えるので、同じ Mac 上でアプリの スキャンと CLI の結果を、お金を払わずに比べられます。

より興味深い重なりはディスク上にあります。どちらも ~/.config/mole/whitelist と ~/.config/mole/whitelist_optimize に書き込み、どちらも ~/Library/Logs/mole/operations.log に追記します。片方のフロントエンドで保護した キャッシュはもう一方でも保護され、どちらかで行った削除は同じファイルに 記録が残ります。実行時に互いを意識しているわけではありませんが、完全に 独立でもありません。

ターミナルだけができること

アプリに相当機能がない、大きめの CLI ワークフローが 3 つあります。mo history、 mo update、mo completion、mo remove などの補助コマンドは、追加のメンテ 面というよりターミナル管理用です。

mo purge

プロジェクトディレクトリを走査し、重いビルド成果物の削除を提案します。対象 リストは広めです。target、build、dist、.next、DerivedData、__pycache__、 coverage、ほかおよそ 30 種類。パッケージマネージャが再ダウンロードする 依存ディレクトリも含みます。Purge はゴミ箱へ移さず完全削除し、直近 7 日以内に 触ったプロジェクトは recent としてマークして未選択のままにします。開発機から 数十 GB を一気に取り戻す直接的な手段であり、いちばん先に --dry-run を 使うべきコマンドでもあります。

mo installer

Downloads、Desktop、Homebrew のキャッシュ、iCloud、Mail から DMG、PKG、 アーカイブ系のインストーラを掃除し、それぞれがどこから来たかをラベル付けします。

mo touchid

sudo 用の Touch ID を設定します。クリーンアップというよりシェル設定の 作業です。

コマンド以外にも、ウィンドウでは得にくいものが 3 つあります。破壊的な コマンドはすべて --dry-run を受け付け、削除対象をそのまま表示して何も 消しません。mo analyze、mo status、mo history は --json を受け付け、 mo status は出力がパイプされたとき自分で JSON に切り替わるので、ヘルス チェックをスクリプトに渡せます。読み取り専用と構造化出力の経路は ssh 越し、 ヘッドレス Mac、スクリプト内でも動きます。定期削除には対話なしの明示的な ポリシーが必要です。確認画面は cron から起動しただけでは安全になりません。

アプリだけができること

アプリの追加機能は、ターミナルが苦手な 2 点、つまり継続表示と特権付きの システム制御のまわりに集まっています。

表示面では、Analyze はドリルダウンできる treemap を描き、Status は sparkline と ピン留め可能なプロセス付きのライブ bento ダッシュボードを描き、メニューバーの HUD は別アプリで作業中でも CPU、メモリ、ネットワークを見せ続けます。Uninstall は 何かを動かす前に、パス・所有者・サイズ付きの確認プランを出し、削除は完全削除ではなく ゴミ箱へ移します。

システム制御では、アプリはファンと対応するバッテリー書き込み用に、SMJobBless 経由の 狭いスコープの root ヘルパーを入れます。起動項目の管理は別の境界に従います。 検証済みの launchd ジョブと対応する Service Management 項目は切り替えでき、 一致しないバックグラウンド項目は推測せず System Settings を開きます。アプリは 常駐してこそ意味がある面も持っています。カメラとマイクの利用をライブ報告する Privacy Check、対応 Mac で充電をおよそ 75 から 80 パーセント付近に保つ Battery Care、Keep Screen On、キーボード拭き用の Clean Screen、そして issue に 貼れる診断レポートをまとめる読み取り専用の Doctor です。

アプリ専用でいちばん大きい面は、他アプリの更新です。複数の更新チャネルを検出し、 Sparkle、Homebrew の cask と formula、Mac App Store、Electron のフィード向けに アプリ内パスを持ちます。GitHub Releases とウェブサイトのメタデータで追加の バージョンを特定できることもあり、バンドルを安全に検証して置き換えられないときは、 別のインストーラを発明せず、対象アプリかベンダーのページを開きます。ライセンスは 2 台分の一回買い切りで、ライフタイム更新、14 日間の返金、macOS 14 以降に対応します。 どちらのプログラムもテレメトリは送りません。

内部：ひとつの安全モデルがふたつのフロントエンドを支える

アプリは mo をシェルで叩くラッパーではありません。Swift による再実装であり、 ふたつのコードベースが共有しているのはプロセスではなく、パスと安全判断です。 Analyze は CLI のパスタクソノミーと並列サイズ計測の知見を踏まえつつ、独自の スキャナ、タイムアウト、部分結果の状態、キャッシュ、フォールバックを持ちます。 したがって片方の合計値は有用なクロスチェックであり、バイト単位の一致を 約束するものではありません。

両者を揃えるためにリポジトリに書かれた原則は、CLI との parity は同じか それより安全、という意味であり、削除の幅が同一であることではない、という ものです。アプリが出す候補は、あなたに届く前に分類されます。既定で選択可能、 既定で未チェックの review-only、あるいは何かが要求しても拒否される blocked です。CLI の振る舞いとこの分類が食い違うとき、アプリは狭い方を取ります。

いちばん分かりやすい例が mo purge です。その掃き出しの Mac 移植は、CLI が 消すダウンロード依存ディレクトリを意図的にすべて落としています。node_modules、 Pods、venv、vendor などです。理由は復元性です。コンパイル済みの target はローカルビルドで戻りますが、依存ツリーはネットワークが必要で、インストール時と 違うものに解決されることがあります。アプリは純粋なローカルコンパイルで 作り直せるものだけを出し、しかも既定選択ではなく review-only の行として出します。 同じ非対称は他にもあります。アプリはアプリデータのスキャンを Full Disk Access の後ろに置き、スキャン時ではなく削除の瞬間にすべてのパスを再検証し、通常の 削除をゴミ箱経由にします。

つまり攻撃性は対等ではなく、差は一貫した方向にあります。CLI がより多く取り戻せるのは、 一覧を読むユーザーを前提にしているからです。アプリがより少なく取り戻すのは、 一覧がすでに安全であってほしいユーザーを前提にしているからです。

両方使う

両方入れても壊れません。共有ファイルがあるので、組み合わせは筋が通っています。 アプリの Settings でキャッシュを保護すれば、mo clean もそれをスキップします。 mo clean --whitelist でパスを足せば、アプリもそれに従います。どちらも削除記録を 同じログに残します。

知っておくべき注意が 2 つあります。実行中は調整し合わないので、同時に両方で クリーンを始めないでください。またアプリは意図的に狭いので、mo clean にあって アプリにないカテゴリが見えても、欠けた機能ではなく想定どおりの振る舞いです。

選び方

ターミナルで仕事している、--dry-run で事前確認したい、スクリプトに --json が要る、プロジェクト成果物やインストーラの掃き出しが欲しい、あるいは 単にお金を使いたくないなら、CLI を入れてください。開発機なら、それで足りることが 多く、無料なのもそのためです。

ディスクマップとライブダッシュボードが欲しい、ファン制御や起動項目の管理や サードパーティアプリの更新が本題である、あるいは Terminal を開かない人に 入れたいなら、アプリを買ってください。最後のケースこそ、アプリが生まれた もともとの理由で、その話は Mole の物語 にあります。

まだ決められないなら、先に CLI を入れて mo clean --dry-run を走らせてください。 費用はかからず、何も削除せず、その出力を読むことが、Mac にそもそもツールが要る 問題があるかどうかを知るいちばん速い方法です。その問い自体、 クリーナーを入れる前に聞く価値があります。