| D1 | 原本は repo 外へ分離 | 承認 |
| D2 | repo 内写真は長辺2400px・品質85 | 承認 |
| D3 | 過去分の履歴書き換えを実施 | 承認 |
| D4 | 未追跡496MBは退避→縮小版のみコミット | 承認 |
| 項目 | 戦略提案時 | 確定値 |
|---|---|---|
| PC 空き容量 | 897GB (誤り) | 93.5GB (物理237GB。897GBはWSL仮想ディスクの見かけ値) |
| Google フォト | 要確認 | 無効 (11/15GB使用・有効化しない方針) |
| 原本庫の媒体 | PC内を想定 | USB (D:) 460GB・空き166GB。旧PC移行データが同居 (整理は home issue) |
| スマホ | — | Pixel 128GB・63GB使用。SDなし。ブログ専用写真は同期後に削除して空きを回復 |
WSL2 の仮想ディスクは既定で最大1TBまで膨らめる設定のため、内部の df は実容量より大きく見える。実制約は Windows 物理ディスクの空き (93.5GB)。また WSL 内でファイルを消しても仮想ディスクは自動では縮まないため、Phase 2 の削減後に仮想ディスクの圧縮工程を追加した。
記事の区切りで、同期検証済みのブログ専用写真の削除候補リストを提示 → 残したいものだけ指定いただく → 明示のGOで削除実行。家族写真を兼ねるものはスマホに残す (スマホ+D: の二重保管になる)。
本計画が整備するのは PhotoArchive の構造・同期・縮小の道具一式。それを使って中身を移す作業 (旧PC移行データの整理・Xperia写真の取り込み・家族写真の冗長化方針) は home issue が担当。D: 上の既存データには本計画では触れない。
| 区分 | 成果物 | 内容 |
|---|---|---|
| 新規 | tools/bin/photo-sync | Pixel→D: の増分同期 (状態ファイルで前回同期以降のみ)。汎用ツールとして tools リポで版管理 |
| blog scripts/photo-ingest.mjs | アーカイブ→縮小→notes 配置→images.md 追記。ブログ専用のため blog リポに置く | |
| blog scripts/check-media-size.mjs + pre-commit | 原寸コミットの再発防止ガード (1.5MB超 or 長辺2400px超の新規画像を停止) | |
| blog docs/photos.md | 写真運用の手順書 (アーカイブ構造・同期・縮小・スマホ削除・トラブル対応) | |
| home issue (新規起票) | [scope] home — D:整理・Xperia取込・家族写真の冗長化方針 | |
| 変更 | blog CLAUDE.md | ドキュメント目次に photos.md を追加・厳守事項に媒体ファイルの扱いを1行 |
| tools README (置き場ガイドライン表) | 「写真・動画の原本 → D:\PhotoArchive」「セッションを跨ぐ中間生成物 → ~/projects/scratch/<issue>-<slug>/」を追記 | |
| ~/.claude/CLAUDE.md (全セッション共通) | scratch の issue 別フォルダ運用+「巨大媒体を作業ツリーに未追跡のまま放置しない」を追記 | |
| 定期棚卸し項目 (daily task セッションへ依頼) | repo サイズ・checkpoint ref・scratch 掃除・同期/移送漏れ・D: 空き容量の点検 | |
| 投書 | notes/README.md の写真手順変更 → #134 へ | 編集権限は #134 専任のため、変更内容と経緯を投書 (直接編集しない) |
| フェーズ | 内容 | 工数 | 性質 | 実施条件 |
|---|---|---|---|---|
| Phase 0 基盤準備・応急 | D: マウント・PhotoArchive 構造作成・未追跡496MB退避・checkpoint ref 掃除・home issue 起票 | 30〜45分 | 完全に可逆 | 即日可 |
| Phase 1 パイプライン | photo-sync / photo-ingest / pre-commit ガード実装 → canary 1件検証 → 退避分を縮小版でコミット | 半日 | 可逆 | Phase 0 完了後 |
| Phase 2 履歴書き換え | バックアップ→予行演習→filter-repo→force push→環境再構築→公開チェック→仮想ディスク圧縮 | 半日〜1日 | 破壊的 (Gate 制御) | 執筆停止日の調整が必要 (#141 が並行執筆中) |
| Phase 3 標準化 | 文書化一式・#134 投書・棚卸し項目追加・scratch 構造化・効果記録 | 1〜2時間 | 可逆 | Phase 2 完了後 |
Phase 0 = 承認後すぐ / Phase 1 = 同日〜翌日 / Phase 2 = 別日で日程調整 (当日は他セッションの執筆・公開を止める) / Phase 3 = Phase 2 直後。その後、本件の検討過程をブログ記事化 (Status=Writing で継続)。
リスクの小さい順。Phase 0-1 完了時点で肥大の進行は止まるため、Phase 2 を急がず日程調整できる。Phase 2 を延期しても Phase 0-1 の価値は独立に成立する。
| # | タスク | 完了条件・検証方法 |
|---|---|---|
| 0-1 | D: を WSL にマウント (sudo mount -t drvfs D: /mnt/d)。常時接続なら次回 WSL 起動以降は自動マウント | /mnt/d の読み書き確認・ファイルシステム種別を記録 |
| 0-2 | D:\PhotoArchive\{pixel,pc,xperia} を作成。D: 直下の既存フォルダ (旧PC移行データ) には触れない | 構造作成のみ・既存データへの書き込みゼロ |
| 0-3 | 未追跡496MB (0107/0124/0131 の写真・動画) を退避: コピー → sha256 照合 → 作業ツリーから削除。撮影日をファイル名から読んで pixel\年\月\ へ振り分け。PNG スクショ (小型) は対象外で残す | 件数・バイト数・ハッシュの三重照合が全件一致してから削除 |
| 0-4 | checkpoint ref (refs/claude/checkpoint-213c6be4) を削除し git gc --prune=now。0-3 完了後・他セッションの非稼働時間帯に実施 | .git が約1.4GiBへ縮小・refs/claude/* が空 |
| 0-5 | 効果測定の基準値を記録 (du・count-objects・GitHub 側サイズ → notes へ) | notes に基準値表を追記 |
| 0-6 | home issue を起票 (次頁スコープ・#142 と相互リンク・[scope] home) | issue URL を #142 にコメント |
削除は必ず「コピー+照合の完了後」。checkpoint ref の削除は退避完了後なので、消える情報は「昨日時点の作業状態スナップショット」のみ (対象ファイルの実体は D: と作業ツリー履歴に保全済み)。
| 素材 | 処理 |
|---|---|
| 写真 (JPEG・モーション写真) | sharp で再エンコード: 長辺2400px以内 (拡大なし)・品質85。再エンコードにより末尾の埋め込み動画は自動的に除去される (JPEGデータ外のため) — 剥離処理の個別実装は不要 |
| EXIF メタデータ | 回転情報は画素に焼き込んだうえで全削除 (GPS等の位置情報を repo に持ち込まない)。撮影日時はファイル名が保持し、完全な EXIF は D: の原本に残る |
| スクリーンショット (PNG) | 原則そのまま (文字の鮮明さ優先)。幅2400px超のみ縮小 |
| 動画 (MP4) | repo へは記事採用分のみ。ffmpeg (要導入) で 1080p/H.264 に圧縮 — 既存前例: 0081 は原本25.6MBを0.68MBに圧縮して public/media/ から配信中 |
| ファイル名 | 元の名前を維持 (原本との対応が自明・既存の images.md 参照も壊れない) |
| images.md 連携 | 取り込み時に「原本: PhotoArchive\pixel\年\月\」の参照行を自動追記 |
Node スクリプト+repo 同梱の sharp (追加インストール不要)。入力はスマホからではなく D: のアーカイブから — 必ず photo-sync (同期) が先に走る構成にし、「原本が D: にない写真が repo に入る」状態を作らない。
canary (9頁) で再エンコード後の色味・向き・精細さをユーザーの目で確認してから全体展開する。
まず「記事の写真吸い上げ時+手動」で開始。定期自動化 (cron 等) は数記事分の運用が回ったことを確認してから検討する。
adb の削除はゴミ箱を経由しない完全削除のため、一覧の目視確認を必須とする。誤削除時は D: から adb push で書き戻せる (メタデータの一部は戻らない)。
初回は少数 (1記事分) で実施し、削除後のスマホ側表示 (Google フォトのライブラリ等) に不自然がないか確認してから通常運用に組み込む。
縮小版は同じファイル名で同じ場所に戻るため、執筆中の 0107/0124/0131 の images.md や参照は壊れない。
git filter-repo で過去の全コミットから対象媒体を除去し、最新状態に縮小版を再コミットする。
「全履歴の画像バイトを縮小版に差し替える」方式 (旧コミットもビルド可能なまま残る) は、blob 単位の対応表作成など工程が複雑で検証コストが高い。旧版の完全再現の需要は低く、必要時は bundle から参照できるため、単純で検証しやすい除去方式を採る。
① bundle バックアップ = 全履歴・全 ref の完全保存 (いつでも完全復元可能) ② 現行媒体のエクスポート = 追跡中の全写真・動画を D:\PhotoArchive へファイルとして書き出し (日常の参照用)。両方が揃ってから書き換えに入る。
GitHub 側の表示サイズはすぐには縮まないことがある (旧オブジェクトの掃除は GitHub 側の処理待ち)。1ヶ月後の棚卸しで確認し、残る場合はサポートへ依頼。
| 関門 | 通過条件 |
|---|---|
| Gate 1 着手前 | bundle 検証合格 / 予行演習で削減後サイズとビルドを確認 / 媒体エクスポート照合済み / 並行セッション停止を確認 / ユーザーの実施GO |
| Gate 2 force push 前 | 書き換え結果の検証チェックリスト全項目合格。不合格なら push せず破棄 — この時点まで origin は無傷 |
| Gate 3 完了判定 | 公開チェック合格 + worktree からのデプロイ成功 + 全記事の表示確認 |
手順の途中で予期しない状態に遭遇したら、先へ進めず停止してユーザーへ報告する (原状は Gate 2 までいつでも無傷で戻せるため、粘るより止まる方が安い)。
| 作業 | 内容 |
|---|---|
| docs/photos.md 新設 | アーカイブ構造・同期・縮小・スマホ削除・履歴書き換えの記録とトラブル対応 |
| CLAUDE.md 更新 (blog / global) | 目次追加・媒体ファイルの扱い・scratch の issue 別フォルダ運用 |
| tools README 更新 | 置き場ガイドライン表に「原本 → D:\PhotoArchive」等を追記 |
| #134 へ投書 | notes/README.md の写真手順変更 (吸い上げ→同期→縮小の新フロー)。直接編集はしない |
| 棚卸し項目の追加依頼 | repo サイズ・checkpoint ref・scratch 掃除・同期/移送漏れ・D: 空き (daily task セッションへ) |
| scratch 構造化 | ~/projects/scratch/<issue>-<slug>/ 化と、4月から残る既存ファイルの整理 |
実装完了後も #142 は close しない — 検討過程のブログ記事化が控えるため Status=Writing で維持し、記事公開をもって close する (運用ルールどおり)。
| リスク | 影響 | 予防 | 検知 | 復旧 |
|---|---|---|---|---|
| 書き換え失敗・履歴の消失 | 大 | bundle+.git 複製の二重バックアップ・予行演習・Gate 2 まで origin 無傷 | 検証チェックリスト | bundle から完全復元 |
| 並行セッションの push と衝突 | 中 | 凍結宣言・実施日調整 (#141 執筆中) | push 前の fetch 確認 | 凍結からやり直し |
| 環境の再構築漏れ (worktree・deployed・.deploy-snapshot・hooksPath・node_modules) | 中 | 再構築チェックリストを手順書化 | 試験デプロイ (Gate 3) | 項目別に個別再作成 |
| GitHub 側の表示サイズが縮まない | 小 | — (GitHub 側処理待ちの仕様) | 1ヶ月後の棚卸し | サポート依頼 (最終手段はリポジトリ再作成) |
| 旧 commit hash の参照切れ (issue コメント・notes 内) | 小 | 事前に了承事項として明示 (10頁) | — | bundle 内で参照可能 |
| 書き換え中の WSL 容量不足 (一時的にクローン2つ分+5GB程度) | 小 | 実施前に物理空き確認 (現在93.5GB — 十分) | df 監視 | 中断しても Gate 2 までは無傷 |
| リスク | 影響 | 予防 | 検知 | 復旧 |
|---|---|---|---|---|
| D: ドライブの故障 (原本喪失) | 中 | ブログ分は repo の2400px版が残るため許容。家族写真の冗長化方針が決まるまでスマホ側を消さない | 棚卸しで読み出し確認 | ブログ用途は縮小版で継続可 |
| スマホ写真の誤削除 | 大 | ハッシュ検証+一覧の目視+ユーザー承認+初回は少数 (8頁の5段安全弁) | 削除ログ | D: から adb push で書き戻し |
| 縮小画質が後で不足 (印刷・大きな切り抜き) | 小 | canary 検証+2400px の余裕設計 | ユーザーの目視確認 | D: の原本から再生成 (可逆) |
| D: の取り外し・未マウント | 小 | スクリプトが検知して中断 (中途半端な状態を作らない) | 実行時チェック | 再マウントして再実行 (冪等) |
| D: の空き逼迫 (現在166GB・旧PCデータ同居) | 小 | home issue でデータ整理・写真の増加は原寸でも年4GB弱 | 棚卸しで空き監視 (目安: 50GB切りで対処) | 整理・媒体増設 |
| 運用のすり抜け (原寸を直接コミット) | 中 | pre-commit ガード+手順書+新フローの方が手間が少ない設計 | 棚卸しのサイズ点検 | 縮小版で上書き・必要なら直近履歴のみ処置 |
| checkpoint 肥大の再発 (本 repo・他 repo) | 小 | 原寸が作業ツリーに入らない構造で解消 | 棚卸しで refs/claude/* を全 repo 点検 | ref 削除+gc (今回と同手順) |
「写真・データ資産の整理 — 旧PC移行データ・Xperia写真・家族写真の保管方針」: D: の既存データ棚卸し / Xperia (SD) 写真の PhotoArchive 取り込み / 家族写真の冗長化方針 (単一保管の解消) / Pixel 容量の中期運用。#142 と相互リンク。
| # | 条件 | 検証方法 |
|---|---|---|
| 1 | .git が 0.4GB 以下 | du -sh .git |
| 2 | 作業ツリーに未追跡の大型媒体ゼロ | git status + du |
| 3 | 全記事の表示OK+公開チェック合格 | 疎通/OGP/W3C/Lighthouse |
| 4 | worktree からのデプロイ成功 | 試験デプロイ |
| 5 | 新運用の文書化+ガード導入済み | docs/photos.md・hook 動作 |
| 6 | 全原本が D: で参照可能 | 照合スクリプト |
| 7 | home issue 起票・#134 投書済み | issue URL |
| 8 | 効果数値を #142 に記録 | before/after 表 |
| 現状 | 完了後 | |
|---|---|---|
| .git | 1.9 GiB | 約 0.3 GB |
| 増加ペース | 約 300 MB/月 | 約 20 MB/月 |
| Pixel の空き | 65 GB | ブログ専用分を随時回復 |
| Windows 物理空き | 93.5 GB | 仮想ディスク圧縮で +1.5GB 程度回復 |
1ヶ月後・3ヶ月後の棚卸しで増加ペースと GitHub 側サイズを実測。期待値から大きく外れたら「技術的に問題ない」で流さず原因を特定する。
「時間がきたらその日の作業は途中でも終わる」働き方を前提に、どのステップも中断点で状態が壊れないように組んでいる。特に Phase 2 は「予行演習まで」「本適用〜push」「環境再構築」の3ブロックに分けられ、ブロック間で日をまたげる (push 前なら origin は無傷のまま)。中間生成物は scratch の issue 別フォルダに置き、再起動で消えない。
2枚のスライド資料と notes の実測記録が記事の素材になる。実装完了後に Status=Writing とし、記事は別の区切りで執筆する。
| # | 確認事項 | 補足 |
|---|---|---|
| C1 | リスク表 (14〜16頁) に漏れがないか | 特に「スマホ削除の安全弁」と「D: 単一保管の割り切り (家族写真はスマホ併存で担保)」の2点 |
| C2 | 履歴書き換え方式の帰結 (10頁) の了承 | 旧コミットに写真が残らない・旧ハッシュ参照切れ。必要時は bundle で参照可能 |
| C3 | Phase 2 の実施日 | 執筆停止が必要 (#141 が並行執筆中)。半日+検証。Phase 0-1 完了後であればいつでも |
| C4 | スマホ削除の初回タイミング | Phase 1 完了後の任意時点・少数から。急がなくてよい |
Phase 0 (30〜45分・完全可逆) から即着手 → 完了報告 → Phase 1 へ。Phase 2 のみ C3 の日程調整を待って実施する。
| 操作 | コマンドの骨子 |
|---|---|
| D: マウント (Phase 0) | sudo mount -t drvfs D: /mnt/d |
| checkpoint 掃除 (Phase 0) | git update-ref -d refs/claude/checkpoint-213c6be4 && git gc --prune=now |
| バックアップ (Phase 2) | git bundle create /mnt/d/Backups/blog-source-YYYYMMDD.bundle --all && git bundle verify … |
| 履歴書き換え (Phase 2) | git filter-repo --invert-paths --paths-from-file media-paths.txt (対象パス一覧は予行演習で確定) |
| worktree 再作成 (Phase 2) | git worktree add ~/projects/blog-deploy (docs/deploy.md の手順に従う) |
| 仮想ディスク圧縮 (Phase 2) | wsl --shutdown 後に Windows 側で圧縮 (実施はユーザーと時間調整) |
| 縮小 (Phase 1・sharp) | sharp: rotate() → resize(2400, 2400, fit:'inside', withoutEnlargement) → jpeg(quality:85, mozjpeg) |
| スマホ削除 (運用) | adb shell rm (候補承認後) → メディアDB再スキャン → 削除ログ記録 |
いずれも本番実行前に予行演習またはドライラン相当の確認を挟む。破壊的操作 (履歴書き換え・スマホ削除) はユーザーの明示 GO を必須とする。
| 項目 | 値 |
|---|---|
| .git (ローカル) | 1.9 GiB |
| うち checkpoint ref 分 | 497 MB |
| 追跡媒体 (notes 1,248MB / src 207MB) | 約 1.46 GB |
| 未追跡媒体 | 496 MB |
| 増加ペース | 約 300 MB/月 |
| Windows 物理ディスク | 237 GB (空き 93.5 GB) |
| USB (D:) | 460 GB (空き 166 GB) |
| Pixel | 128 GB (使用 63 GB) |
| Google フォト | 無効 (11/15 GB・使わない方針) |
承認済みの戦略 (決定1〜4+保管設計v2) を実行に落とした設計書。Claude Code が作成し、実行前の最終確認 (19頁の C1〜C4) を経て着手する。