ディスクを整理するとき、大きなディレクトリを見つけても、どこから手をつければよいか調べるのが面倒でした。キャッシュなのか、作業に必要なデータなのかを一つずつ確認する前に、ある程度の見当をつけてもらいたいと思い、Jevで試してみました。

容量を調べる部分にはgduを使い、その結果をJevへ渡します。「掃除候補」「保持推奨」「要確認」を表示し、実際に整理するかどうかは人間が判断する想定です。今回はこの流れを確認するためのPoCとして作りました。

gduで容量をJSONとして取得する

gduは、ディレクトリやファイルのディスク使用量を調べるGo製のCLIです。計測結果をJSONで取得できるので、この出力をJevへの入力の元にしました。

macOSではHomebrewからインストールできます。

brew install gdu

GNU coreutilsのgduとの衝突を回避するため、Homebrewではgdu-goという名前でインストールされます。

ホームディレクトリの計測結果をJSONに保存するコマンドは、次のとおりです。

gdu-go --no-progress --no-cross --output-file scan.json -- ~/

出力は、形式のバージョン、メタデータ、ディレクトリツリーを並べたJSON配列になっています。ディレクトリは「自身の情報と子要素を並べた配列」、ファイルは情報オブジェクトとして表現されます。

[
  1,
  2,
  { "progname": "gdu", "progver": "v5.37.0" },
  [
    { "name": "/Users/demo/projects/example", "dsize": 4294967296, "asize": 4294967296 },
    { "name": "package.json", "dsize": 4096, "asize": 512 },
    { "name": "package-lock.json", "dsize": 4096, "asize": 2048 },
    [
      { "name": "node_modules", "dsize": 4294959104, "asize": 4294964736, "items": 6000, "mtime": 1787000000 }
    ]
  ]
]

容量の大きな項目を選び、1件ずつのデータにする

このツリーを全部Jevに渡すと、容量の小さな項目まで大量に入ってしまいます。そこでローカルで、100 MiB以上の項目から容量の大きい順に最大50件を選びます。

ホームやプロジェクト全体のような大きな親ディレクトリは、子へ分解して見ます。node_modulesやCaches、DerivedDataなどは、ひとまとまりの候補として扱います。

選んだ項目について、親子関係からフルパスを組み立てます。Jevに渡す情報は、そのパスとディスク使用量だけにしました。

Jevへ渡すstateは、候補1件についてのJSONオブジェクトです。

{
  "path": "/Users/demo/projects/example/node_modules",
  "disk_bytes": 4294959104
}

Jevには用途と再生成可能性を聞く

Jevは、状態と型の決まった質問を入力すると、判定を返すモデルです。今回は固定の選択肢から選ぶChoiceを使いました。

同じ候補に対して、次の2つを聞きます。

質問	選択肢
この項目の用途は何か	キャッシュ、ビルド成果物、依存関係、個人データ、設定・認証情報、その他、不明
この項目は再生成できそうか	再生成可能、固有データ、不明

候補1件を1回のAPIリクエストにし、その中に2問をまとめました。リクエストには、入力データのstate、質問のquestions、使用モデルのmodelを含めます。

questionsには、質問の種類を表すtype、質問文のinstructions、選択肢と説明のcriteriaを入れます。説明には、キャッシュとアプリの永続データを区別することや、古い・大きいという理由だけで不要と判断しないことを書いています。判断材料が足りない場合に選べるよう、両方の質問に「不明」も用意しました。

返ってくるのは、選んだchoice、選択肢別のprobabilities、confidenceです。

回答を整理の目安として表示する

2つの回答を、次の条件で表示へ変換します。

条件	表示
どちらかのconfidenceが0.85未満	要確認
個人データ・設定、または固有データと分類	保持推奨
キャッシュ・成果物・依存関係で、再生成可能と分類	掃除候補
その他・不明	要確認

0.85は今回のPoCで置いた閾値です。

用途と再生成可能性を分けておくと、「キャッシュには見えるが、再生成できるかは判断が弱い」といった結果も表示に反映できます。説明文は分類から組み立てた定型文です。

実際に動かしてみた

パスとディスク使用量だけを入力にして、実機で試しました。

ホームディレクトリを対象に、まず容量計測とJevへの入力プレビューを確認しました。

実機では約534万項目、ディスク使用量約386 GiBを計測し、50件の入力データを作成できました。容量計測と入力データの作成には約48.0秒かかりました。

指定モデルはjev-latest、応答のモデル名はjev-1.13.0でした。結果は次のとおりです。

表示	件数
掃除候補	15
保持推奨	3
要確認	32

代表的な項目を抜き出すと、以下のようになりました。記事ではパスの末尾だけを掲載していますが、APIには元のフルパスを渡しています。分類とconfidenceは実際の応答の値です。

項目	用途とconfidence	再生成可能性とconfidence	表示
`Caches`	キャッシュ：1.00	再生成可能：0.96	掃除候補
`node_modules`	依存関係：1.00	再生成可能：1.00	掃除候補
`.venv`	依存関係：0.99	再生成可能：0.99	掃除候補
`写真`	個人データ：1.00	固有データ：0.85	保持推奨
`Backup`	個人データ：1.00	固有データ：0.91	保持推奨
`.gradle`	キャッシュ：0.87	再生成可能：1.00	掃除候補
`data.img.raw`	個人データ：0.44	再生成可能：0.66	要確認

.gradleはキャッシュかつ再生成可能と分類され、両方のconfidenceが閾値以上だったため掃除候補になりました。一方、大きなディスクイメージのdata.img.rawは、用途と再生成可能性のどちらもconfidenceが低く、要確認になっています。

この試行では50件の候補に対して100問を送り、50件すべてでAPIの回答を取得できました。応答のusageの合計は、入力トークン34,589、出力トークン5,645でした。

保存済み入力の評価は3並列で行い、約3.1秒でした。これはgduの計測時間を含まず、APIへの問い合わせと表示用データの作成にかかった時間です。

試してみた感想

今回やったことは、gduのツリーから容量の大きい項目を取り出して、パスと容量を1件の状態にまとめ、Jevで用途と再生成可能性を分類する、というものです。

「大きい順」の一覧に用途の見当が加わると、自分で確認する順番を考える材料になりそうだと感じました。実データでも、キャッシュやnode_modulesは掃除候補、写真やバックアップは保持推奨という分類が返りました。

一方で、50件中32件は要確認でした。パスと容量だけでは判断しにくい項目も多く、今回は「消してよいものを確定する」よりも、「先に確認する候補を絞る」という使い方に合いそうです。今回の分類は正解ラベルと照合していないので、精度を測った結果ではありません。次は要確認の項目を自分で見て、この分類が確認する順番を考えるのに役立つかを確かめたいです。