計画した Phase 0〜3 (基盤準備・パイプライン・履歴書き換え・標準化) を当日中に完遂。破壊的操作は全 Gate を通過し、本番サイト・執筆環境とも正常。追加費用ゼロ。
仮想ディスク圧縮の方式変更 (安全性判断) と点検体制の変更 (前提誤りの訂正)。実施中に git の仕様に起因する取りこぼしを2度検出し、方式を改良して完全除去した (8-9頁)。
スマホ全量 1,103件の吸い上げに成功。別セッションによる新フローの実運用テスト (取り込み〜スマホ削除) も完走し、標準として定着可能なことを確認した。
| 移行前 (8/20 朝) | 移行後 (8/20 夜) | |
|---|---|---|
| .git (ローカル) | 1.9 GiB | 288 MB |
| 作業ツリーの未追跡メディア | 495 MB | 0 |
| 増加ペース | 約 300 MB/月 | 約 20 MB/月 (見込み・実測で追跡) |
| WSL 仮想ディスク | 66.5 GB | 62.8 GB (Windows 空き約97GBへ) |
| 本番ビルド (dist) | — (原寸混在) | 35 MB・26ページ |
| 原本の保全 | repo 単一保管 | D: に多重保全 (原本7.8GB+完全バックアップ1.5GB×2形式) |
| スマホ容量の回復手段 | なし | 承認制の削除フロー確立 (初回実運用済み) |
| GitHub 側表示サイズ | 約 1.38 GB | 同左 — 旧オブジェクト掃除待ち (9月に確認) |
| フェーズ | 計画工数 | 実績 | 結果 |
|---|---|---|---|
| Phase 0 基盤準備・応急 | 30〜45分 | 約20分 | D:マウント恒久化・退避76件 (sha256全一致)・checkpoint掃除 (−0.5GiB)・#144起票 |
| Phase 1 パイプライン | 半日 | 約40分 | photo-ingest / ガード / photo-sync 実装・canary 承認・74枚復元 (281→32MB) |
| Phase 2 履歴書き換え | 半日〜1日 | 約50分 | Gate 1〜3 全通過・force push・環境再構築・公開チェック全200 |
| Phase 3 標準化 | 1〜2時間 | 約30分 | 手順書新設・4文書へ反映・#134投書・AIメモリ整備 |
| 追加: 仮想ディスク圧縮 | — | 約10分 | 方式変更のうえ実施 (8頁)・−3.7GB |
| 追加: 全量吸い上げ・他セッション実証 | — | 約40分 | 1,103件5.9GB 全件一致・別セッションで新フロー完走 |
実働短縮の主因: 事前の実測・予行設計に時間を投じたこと (戦略・計画2本の資料作成時に検証を先行)、および各フェーズが独立して中断可能な構成にしたことで手戻りがなかったこと。時間帯: 計画審議 13:20〜16:30 / 実施 16:40〜22:30 (待ち時間含む)。
未追跡だった動画1本が 106MB で GitHub の1ファイル上限 (100MB) を超過していた。旧運用のままコミットしていれば push 不能に陥っていた — 新ルール (動画素材は repo 外) の必要性が実データで裏付けられた。
全記事・全ドラフトの import を走査し、退避対象への参照が無いことを事前検証。縮小版は同名・同位置に復帰するため、進行中の記事 (0107/0124/0131) の参照も維持。該当 issue へは退避の通知コメントを残した。
| ステップ | 実績 |
|---|---|
| 凍結 | 執筆中記事ゼロを確認 (#141 は公開済み)・稼働セッションなし |
| バックアップ | bundle+.git 複製 (1.48GB) — 件数・バイト完全一致・テストクローン成功 |
| 原本エクスポート | 追跡中の全対象 511件/1.36GB を D: へ (バイト一致検証) |
| filter-repo | 3パスで完全除去 (9頁) → .git 109MB |
| 縮小版の再コミット | 356件再エンコード+154件等倍コピー (再劣化なし)・1,354→186MB |
| force push | 全ブランチ+全タグ (Gate 2 合格後) |
| 環境再構築 | 作業コピー入替 (未コミット変更・設定を引継ぎ)・worktree/deployed 再作成・ガード再設定 |
| デプロイ・公開チェック | 変更アセット161件配信・記事/画像/動画すべて 200・URL不変 |
force push (Gate 2) までは origin 無傷の構成としたため、実施中に発見した取りこぼし2件 (9頁) をやり直しではなく追加パスで安全に是正できた。切戻し手段 (bundle) は最後まで温存。
なし。URL・記事内容・見た目は不変で、画像ファイル名 (ハッシュ) のみ変化。配信は軽くなる方向 (旧記事の原寸配信 4032px→最大2400px)。
| 反映先 | 内容 |
|---|---|
| blog docs/photos.md (新設) | 三層の置き場・日常フロー・サイズルール・スマホ削除の5段安全弁・定期点検チェックリスト・トラブル対応・運用FAQ |
| blog CLAUDE.md / tools README / 全セッション共通 CLAUDE.md | 「原寸を repo に置かない」ルールと scratch の issue 別フォルダ運用を明記 |
| 執筆フロー文書 (notes/README.md) | 管轄セッション (#134) へ変更5点を投書 (直接編集はせず・原文と経緯つき) |
| ~/projects/scratch/README.md (新設) | セッションを跨ぐ中間生成物の置き場を構造化 — 派生課題「PC再起動でファイル消失」を解消 |
| AI メモリ | 新運用を保存 — どのセッションでも「◯日の◯◯の写真を取り込んで」の一言で正しいフローに到達 |
| 定期点検 ops issue #145 (新設) | 月1・5分。repo サイズ / checkpoint ref / scratch / D: 空きの監視+日付つきスポット2件 |
計画: WSL の sparse 化 (--set-sparse true)
実際: 実行時にエラー — 現行 WSL ではデータ破損報告により既定無効化されていた。強制オプション (--allow-unsafe) は「大移行の直後に破損リスクを取らない」判断で不採用とし、fstrim + diskpart compact 方式 (非破壊・オフライン圧縮) に変更。
結果: 66.5→62.8GB (−3.7GB)。当初見込み1.6GBの倍以上を回収 (過去の未回収領域も戻った)。
計画: 既存の「daily task セッション」へ棚卸し項目を依頼
実際: オーナーから「明確な daily task セッションは存在しない」(毎日の運用は閲覧状況モニタリングのみ) との指摘 — AI の記憶が実運用とずれていた。記憶を訂正のうえ、月1の点検専用 ops issue #145 を新設して解決。
教訓: 依頼先・運用体制はメモリでなく現在の実態で確認する。
除去対象リストを git rev-list --objects から生成したところ、1パス目の後に対象画像が残存。調査の結果、rev-list は同一内容 (blob) の別名パスを1つしか表示しない仕様と判明 — 記事採用時に「notes→src へ同一バイトのままリネームコピー」した写真が対で存在し、片側がリストから漏れていた (25件・80MB、対称形でさらに13件)。
リスト生成をコミット単位の全パス列挙 (git log --all --name-only) に切り替えて完全除去。是正後の監査で、残存する大型 blob が意図した2種 (採用動画・PNGスクショ) のみであることを確認した。
| パス | .git | 内容 |
|---|---|---|
| 1 | 226MB | 当初リスト (506パス) で除去 |
| 2 | 148MB | 別名複製 25件を追加除去 |
| 3 | 109MB | 完全列挙リストで13件除去・監査クリア |
| +再コミット | 288MB | 縮小版511件 (186MB) を追加して完成 |
origin 無傷の段階で検出・是正できたため影響なし。取りこぼし分の原本も除去前に D: へ追加エクスポート済み。
Claude Code が利用制限到達時に作る checkpoint ref が未追跡の原寸496MBを .git に取り込んでいた (一晩で+0.5GiB)。「コミットしなければ安全」ではない — 原寸を作業ツリーに置かない構造で根治。
未追跡動画1本が106MB。旧運用の延長線上には「push 不能」の障害が待っていた。容量問題は「遅い」だけでなく「止まる」リスクだった。
sudo がパスワード入力端末を取れない場面でも wsl.exe -u root -- <cmd> なら実行できる (WSL の仕様)。マウント作業のユーザー負担がゼロになった。
D: へのコピーはタイムスタンプ保持が Operation not permitted になるが内容は正常。検証は件数+バイト+sha256 で行う設計にした (全工程で採用・不一致ゼロ)。
| 検証 | 方法 | 結果 |
|---|---|---|
| バックアップの健全性 | bundle verify + バックアップからのテストクローン + .git 複製の件数/バイト照合 | 合格 (完全一致) |
| 原本エクスポート (511+76件) | 件数・バイト・sha256 の照合 | 全件一致 |
| 縮小の品質 | canary 5枚 — AI 検品 (文字可読性・向き・色) + オーナー目視承認 | 承認 |
| 書き換え結果 (Gate 2) | コミット数・追跡ファイル数・タグ/ブランチ追従・テキスト履歴・残存大 blob 監査・本番ビルド | 合格 |
| 本番公開 (Gate 3) | デプロイ成功・トップ/記事/画像/動画の疎通 (全200)・URL 不変確認 | 合格 |
| 環境復旧 | 未コミット変更の引継ぎ確認・worktree からの再デプロイ・ガード自己テスト | 合格 |
| 全量吸い上げ | デバイス 1,103件 vs D: 1,103件 (新規1,027+既存skip76) | 全件一致 |
完了の定義 (実行計画17頁・8条件) はすべて達成。未達扱いの継続項目は「GitHub 側サイズの反映」のみ (仕様上の遅延・9月に確認)。
Pixel の全写真 1,103件・5.9GB (2026/07=429件・08=674件) を D: へ同期。増分検出・重複スキップ・日付振り分けが実データで機能。以後の同期は差分のみで数分以内。
本件を知らない記事セッションが、手順書と AI メモリだけを頼りに「同期 → 3枚選定 → 縮小取り込み (6.82→1.34MB) → images.md 記録 → 承認制スマホ削除 → ログ・コミット」を初見で完走。他作業の未コミット変更の巻き込み回避も適切だった。
「◯日の◯◯の写真を取り込んで」— photo-sync の導入・PATH 設定などの事前準備は全セッションで完了済み。
| 成果 | 内容 |
|---|---|
| 派生課題の解消 | 「PC 再起動で scratchpad 消失」問題 — セッションを跨ぐ中間生成物の置き場 (~/projects/scratch/<issue>-<slug>/) を標準化して解決 |
| スマホ容量の回復手段 | ブログ専用写真の承認制削除フロー (初回で3枚実施済み)。今後は記事の区切りごとに回復できる |
| 旧記事の配信軽量化 | widths 未指定の12記事で原寸級 (最大4032px) 配信が最大2400pxに自動改善 (完全対応は別途) |
| 関連 issue の整備 | #144 (家の資産整理: D:・Xperia・家族写真冗長化)・#145 (月1点検) を新設し、恒久運用の受け皿を確保 |
| Windows 空き容量 | 約93.5GB → 約97GB (仮想ディスク圧縮) |
| ブログ記事の材料 | 検討スライド2本+議事録2本+実測記録4本 — 検討過程が一次資料として揃った状態 |
| 時期 | タスク | 担当 |
|---|---|---|
| 8/27〜 | 旧作業コピーの削除 (バックアップは D: に恒久保管) | #145 8月末回 |
| 9月 | GitHub 側サイズの反映確認 (減っていなければサポート依頼) | #145 9月回 |
| 毎月 | 定期点検 (repo サイズ・checkpoint・scratch・D: 空き) | #145 |
| 随時 | ffmpeg 導入 (動画を記事採用する最初の機会に) | 該当記事セッション |
| 随時 | ブログ記事化 (本報告・議事録・実測記録が素材) | #142 (Writing) |
1ヶ月後・3ヶ月後に増加ペースを実測。期待値 (約20MB/月) から大きく外れた場合は「問題ない」で流さず原因を特定する (反証条件)。
当初の問い「repo をどう軽くするか」を「データの種類ごとに置き場を定める」に置き直したことで、repo 肥大・チェックポイント肥大・scratchpad 消失・スマホ容量という別々に見えていた4つの問題が同じ1つの標準で解決した。個々の対症療法では、この同時解決には届かなかった。
バックアップ二重化・Gate 構成・ハッシュ検証・canary 承認は一見過剰だが、実施中に2度の取りこぼし検出があっても無傷でやり直せる余地を保ち続けた。破壊的操作の工数は「作業」より「検証」に割くのが正しかった。
現行方針のまま運用を継続し、見直しは反証条件 (14頁) の成立時のみとする。次の投資対象は #144 (家族写真の冗長化) — D: 単一保管の解消が残る最大のリスク。
| ファイル | 内容 |
|---|---|
| proposal-slides.html | 戦略提案 (全21枚) — 現状分析・選択肢比較・推奨案 |
| execution-plan-slides.html | 実行計画書 (全21枚) — 詳細設計・手順・リスク管理 |
| minutes-planning-2026-08-20.html | 審議録 — 戦略・保管設計・実行計画の質疑応答と決定 |
| minutes-execution-2026-08-20.html | 実施録 — 実施中の判断・方式変更・運用確定の質疑 |
| completion-report-slides.html | 完了報告 (本資料) |
| investigation-2026-08-20.md / decisions-2026-08-20.md | 実測記録・決定記録 |
| phase0〜3-record-2026-08-20.md | フェーズ別実施記録 (コマンド・数値・学び) |
| evacuation-manifest-2026-08-20.csv | 退避76件の対応表 (repoパス⇔D:パス⇔sha256) |
| 運用手順書 | blog docs/photos.md (正) ・ 関連 issue: #142 / #144 / #145 / #134投書 |