ディスクを整理するとき、大きなディレクトリを見つけても、どこから手をつければよいか調べるのが面倒でした。キャッシュなのか、作業に必要なデータなのかを一つずつ確認する前に、ある程度の見当をつけてもらいたいと思い、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件は要確認でした。パスと容量だけでは判断しにくい項目も多く、今回は「消してよいものを確定する」よりも、「先に確認する候補を絞る」という使い方に合いそうです。今回の分類は正解ラベルと照合していないので、精度を測った結果ではありません。次は要確認の項目を自分で見て、この分類が確認する順番を考えるのに役立つかを確かめたいです。