ClaudeとDiskSageを作り始めた日 - 容量診断の体験をOSSプロダクトに変えるまで

Macの空き容量ゼロ問題を Claude と半日かけて解剖した（前記事）。iMobie 39GB の孤児バックアップ、VM スワップ 22GB、/Library 53GB など、一般的な容量管理ツールでは指摘してくれない問題が次々に出てきた。

その途中で、こんな感覚が湧いた。

「この診断プロセス、そのままプロダクトにならないか？」

既存の CleanMyMac や DaisyDisk はルールベースで自動削除するか、サイズを可視化するだけ。AI が中身を読んで「これは何か、消していいか」を提案するツールは、意外にも存在しない。

その日のうちに企画書と MVP を作ったのでその記録を残す。

発想の種：体験そのものが仕様になる

Claude との対話で発見したパターンは、そのまま DiskSage の検出パターンに転用できた。

自分が痛い目に遭ったことを、そのまま製品仕様にできる。これが一番の差別化要素だと気付いた。

コアコンセプトを3つに絞る

• Never auto-delete. 絶対に自動削除しない。常にユーザー承認。
• Context over size. 「サイズ順」ではなく「中身を理解した上での提案」。
• OSS. コードを公開して透明性を担保。商用クロ箱への不信感に応える。

これで自分なりの差別化ポジションが見えた。

既存プロダクトとの比較

技術選定

スタックをどうするかで悩んだが、最終的にこう決めた。

Phase 1（MVP）: Bash CLI

• 依存最小、Python 3 以外不要（macOS 標準）
• ロジックを固めるフェーズは手早く書けることが最優先
• OSS リリース時も入れやすい

Phase 3 以降: Rust + Tauri

• Electron は避ける。容量管理アプリ自体が重いのは自己矛盾
• Tauri なら数 MB のバイナリ、起動も速い
• スキャンエンジンは Rust（walkdir, tokio）でパフォーマンス確保

AI 連携: Claude API（BYOK）

• ファイル名・パス・メタデータのみ送信。ファイル内容は絶対に送らない
• ユーザーの API キーを使う BYOK がデフォルト
• Pro 版（将来）でマネージド API を提供して差別化

MVP を半日で作る

Claude とペアプロで、Bash スクリプト 1 ファイル（約 500 行）を書いた。

実装した機能

disksage scan              # 既知パターンをスキャン、Markdown レポート生成
disksage snapshot          # 現在のディスク使用量を記録
disksage trend             # 時系列の変化を表示（「一瞬で埋まる」を捕まえる）
disksage help              # ヘルプ

検出パターン（v0.1）

10 個のパターンをバンドル：

• APFS スナップショット（3 個超で警告）
• iPhone バックアップ（Manifest.db 有無で破損判定つき）
• Docker.raw（10GB 超で警告）
• Ollama モデル（10GB 超で警告）
• node_modules 集計（~/Development 配下）
• macOS VM スワップ（5GB 超で再起動推奨）
• Electron キャッシュ（Claude, Dia 等を自動検出、削除推奨）
• Xcode DerivedData（削除推奨）
• Flow-type（30 日以内に作成の 500MB 超ファイル、レポート欄に表示）
• Google Updater キャッシュ

ハマりどころ：set -e

set -euo pipefail   # ❌ これで死ぬ

• find | head -1 が pipefail 下で SIGPIPE エラーを起こす
• du / stat が permission denied で non-zero 返すと即終了する
• 個別エラーを許容する設計にしないと、容量スキャナは成立しない

最終的に set -uo pipefail のみに留めて、個別の検出ロジックは失敗しても次に進むように書いた。これは後日の Rust 版でも「Result の扱い方」として同じ設計方針を継承する。

「提案方式」へのこだわり

今回の診断で、Claude から「これは消していい」と言われて、すぐ rm -rf を打つのは怖かった。実際、iMobie 39GB は自分のiPhoneバックアップが壊れた残骸だったが、壊れているかどうかを判定するまでに時間がかかった。

「怖いな」という感覚こそが市場ニーズそのものだと思う。CleanMyMac に任せると勝手に消されるのが怖い。でも手作業で du と find を叩き続けるのもしんどい。

DiskSage はその間を埋める：

• 何が検出されたかを明示する
• なぜ消していいかの根拠を示す
• 削除するかどうかは人間が決める
• 削除するならゴミ箱経由（完全削除は別ステップで明示的に）

UI のイメージは、Tinder 式のカード UI。1 件ずつ「残す / 外付けに退避 / ゴミ箱へ / 今は保留」を選ぶ。人間の判断速度に合わせる。

次のアクション

MVP はできた。OSS として公開するための残タスク：

• GitHub リポジトリ作成、実コードを push
• 実際の Mac で disksage scan を走らせて動作確認
• パターンの誤検出・見逃しを洗い出してチューニング
• CI（GitHub Actions で ShellCheck）
• CONTRIBUTING.md を書く
• Homebrew tap 対応
• AI モードの実装（Claude API、BYOK）

短期目標：

• GitHub Star 500+
• β テスター 20 名（開発者コミュニティから）
• Zenn / Hacker News / Product Hunt ローンチ

OSS コミュニティの広げ方

「fork していってね」だけでは広がらない。必要なのは：

1. ストーリーのある README — 作った人の痛みが伝わるもの
2. Good First Issue が具体的に提示されていること
3. コントリビューター向けドキュメント（パターンの追加方法など）
4. Discord / X などコミュニティハブ
5. 定期発信（Zenn, Qiita, dev.to, note）
6. 最初のローンチの勢い（Hacker News、Product Hunt）

これは自分の nuko IME プロジェクト（LLM 時代の日本語 IME）にも同じ方法論が使える。結局のところ、OSS の成長は**「作者が継続的に存在していること」**が最大要因。

今日の個人的な学び

• 自分の痛みはプロダクトの種になる。CTO を名乗ってバックアップ戦略ゼロだった恥を隠さず、それを製品価値に変換する方が健全
• AI との対話がそのまま仕様書になる。診断プロセスの記録 = 検出パターンのシード
• 技術選定は「自己矛盾を避ける」が最強（容量アプリが Electron なのは矛盾、だから Rust+Tauri）
• MVP は半日で作れる。ただし、それを「世に出せる形」にするにはその 10 倍の時間がかかる

関連記事

• 2026-04-20-Mac空き容量ゼロ事件をClaudeと一緒に解剖した話
• 2026-04-20-macOSの容量が見えないところで消えている
• 2026-03-10-LLM時代の日本語IMEを自作する
• 2026-04-17-The-Architecture-of-Everything-Claude-Code
• 2026-02-11-AIドリブンなプロジェクト管理