ブログ source repo の .git が 1.9GiB。原因はスマホ原寸写真 (1枚3〜7MB・モーション写真は動画埋め込み) をそのままコミットする運用で、増加は約300MB/月。GitHub の推奨上限 5GB には約1年で到達する見込み。
① 写真は取り込み時に長辺2400px へ縮小してからコミット ② 原寸の原本は repo 外の原本庫へ (スマホ+Google フォトを一次バックアップとして活用) ③ 過去分も履歴書き換えで縮小版に差し替え。追加費用ゼロ・原本は失わない。
本件を「repo の容量問題」でなく「データの種類ごとに置き場が未定義」という構造の問題として解決する。scratchpad 消失問題 (派生課題) も同じ標準で解消する。
| 01 | 現状分析 | 実測数値と、本検討で新たに判明した事実 |
| 02 | 課題の本質 | なぜ肥大するのか — 「版管理」と「原本保管」の役割混在 |
| 03 | 推奨案 | 軽量作業コピー方式 (3本柱) と効果試算 |
| 04 | 対抗案と比較 | Git LFS 全面移行との比較評価 |
| 05 | 実行とガバナンス | リスク対策・個人開発全体のデータ配置標準・実行計画 |
| 06 | ご判断事項 | 決定 4点 + 事前確認 1点 |
表記ルール: 実測 = 本セッションまたは #142 起票時に検証済みの事実 / 推定 = 計算・見込み (前提を併記) / 要確認 = 実施前に確認が必要な前提
| 項目 | 値 |
|---|---|
| .git サイズ (ローカル) 実測 | 1.9 GiB |
| GitHub 側 repo サイズ (8/19) 実測 | 約 1.27 GiB |
| 追跡ファイル合計 (notes 1,248MB / src 207MB) | 約 1.5 GB |
| うち画像・動画の占める割合 | 93% |
| モーション写真 (.MP.jpg・動画埋め込み) | 233 枚 |
| 未追跡の写真・動画 (コミット判断待ち) | 496 MB |
| コミット数 / 運用期間 | 562 / 134日 |
| 増加ペース 実測 | 約 300 MB/月 |
右の497MBは Claude Code のチェックポイント (次頁)。ごみや重複はほぼなく、中身は既に圧縮済みの JPEG/MP4 のため git gc では減らない (#142 起票時に検証済み)。
GitHub の公式ガイダンスは「理想 1GB 未満・5GB 未満を強く推奨」。理想値は既に超過し、現ペースでは 5GB に約1年で到達 (未追跡分をコミットするとさらに前倒し)。
8/19 のセッションが利用制限到達時に作業状態を退避した checkpoint ref (refs/claude/*) が、未追跡の写真496MBを .git 内に取り込んでいた (一晩で+0.5GiB)。巨大な未追跡ファイルを置いたままセッションを回すだけで .git が膨らむ — 「コミットしなければ安全」ではない。
新しい記事はレスポンシブ配信 (上限1680px・本文幅720px) 済みだが、テンプレ改善前の12本は widths 未指定で原寸級 (最大4032px) が配信されている。素材を縮小すれば、これらの配信も自動的に軽くなる (副次効果)。
repo の写真はスマホ (Pixel) から吸い上げたコピーであり、撮影原本は端末+Google フォト (バックアップ有効なら) に残っている見込み。つまり「repo が唯一の原本置き場」という前提は成立していない可能性が高い。バックアップ設定と画質モードの確認が実施の前提。
作業マシンの空き容量は 897GB。repo 外にローカル原本庫を設けるうえで容量制約はない。制約があるのは GitHub 側 (推奨5GB) と、git の仕組み上「一度コミットした容量は履歴に残り続ける」点。
コミットを保留した未追跡写真も、Claude Code のチェックポイント経由で .git に複製される (前頁1)。つまり現行フローでは、原寸を repo の作業ツリーに置いた時点で容量問題が始まる。
配信に必要な画素数に対して素材は面積比で約6〜9倍。モーション写真は容量の約半分が「記事では使わない埋め込み動画」。保存している容量の9割超は、ブログ用途では一度も使われない。
「repo をどう軽くするか」ではなく「データの種類ごとに、どこに置き・いつ掃除するかの標準を定める」。写真の原本・執筆用の作業コピー・セッションを跨ぐ中間生成物 (scratchpad 派生課題)・一時ファイル — それぞれに適所を与えれば、repo 肥大もファイル消失も同じ枠組みで解消する。
5GB は即遮断の閾値ではなく推奨値。日々の執筆への体感影響も現時点では限定的。緊急対応ではなく、コストが最小の今のうちに構造を直す提案である。
| 案 | 評価 | 判定 |
|---|---|---|
| A. 今後の写真だけ縮小 | 増加は止まるが既存1.9GiBとチェックポイント問題が残る。単独では不足、部品としては必須 | 採用 (柱①) |
| B. photos を git 管理外に | 「別マシンで写真がない」以前に、縮小版すら repo に無いと執筆・レビューの一次資料が分散する | 不採用 |
| C. Git LFS へ移行 | 成立する。ただし約2年で無料枠に達し、履歴書き換えはどのみち必要 (詳細は対抗案として後述) | 対抗案 |
| D. 写真を別リポジトリへ | 総量は変わらず置き場が移るだけ。2リポジトリ運用の手間が純増 | 不採用 |
| E. 履歴書き換えで過去分も縮小 | 既存1.9GiBを実際に減らせる唯一の手段。対象が少ない今が最安。A と組みで再発防止 | 採用 (柱③) |
| F. 現状維持 | チェックポイント二次肥大の判明により、起票時の想定より悪化が速い | 不採用 |
| +G. 原本庫の分離 (新) | 「原本はスマホ+Google フォト+PC 原本庫、repo は縮小版」— B の弱点 (一次資料の喪失) を縮小版の常置で解消する新しい柱 | 採用 (柱②) |
推奨案 = A + G + E の組み合わせ。単独案の比較では決まらず、「取り込み・保管・過去分」の3点を同時に押さえる必要がある。
写真を repo に入れる前に縮小する自動処理。増加ペースを約1/15に。
スマホ+Google フォト / PC 原本庫 / repo 作業コピー。原寸・モーション動画は失わない。
既存の原寸を原本庫へ退避し、履歴書き換えで縮小版に差し替え。1.9GiB→約0.3GB。
配信上の必要幅は最大1680px (本文720px × 高精細画面)。2400px はその1.4倍で、将来のデザイン変更や切り抜きに耐える余裕を持ちつつ削減率89%を確保できる。1600px との差は月あたり約10MB — 絞り込む価値より余裕を優先する。
| 素材 | ルール |
|---|---|
| 写真 (JPEG) | モーション動画を剥離 → 長辺2400px・q85 で再エンコード |
| スクリーンショット (PNG) | 原則そのまま (元々小さく、文字の鮮明さが重要) |
| 動画 (MP4) | 記事採用分のみ repo へ。1080p 目安・素材段階は原本庫のみ |
| ファイル名 | 元の名前を維持 (原本との対応を自明に) |
既存の写真吸い上げフローに Node スクリプトを組み込む。画像処理は Astro 同梱の sharp を利用でき、追加インストールなしで実装できる見込み。適用は1件で検証してから全体へ展開する。
| 層 | 置き場 | 役割 |
|---|---|---|
| L1 | スマホ + Google フォト 要確認 | 撮影原本の一次バックアップ。モーション写真の再生・アルバム・検索など、写真としての価値はここで守るのが最も自然 |
| L2 | PC 原本庫 ~/projects/blog-originals/<issue>-<slug>/ | 吸い上げ時に原寸+モーションを全量保存 (git 外・空き897GB)。縮小のやり直し・履歴整理時の退避先。ローカルのみでクラウドには置かない |
| L3 | repo 作業コピー notes/<issue>-<slug>/photos/ | 縮小版のみコミット。執筆・レビュー・セッション間の受け渡しはこれまで通り repo 内で完結 |
notes/ の一次情報の本体は発言メモと画像インベントリ (テキスト) であり、これは従来どおり repo に残る。写真も縮小版が常に repo にあるため、執筆に必要な一次資料は分散しない。失うのは「原寸が repo にあること」だけで、原寸自体は L1/L2 に残る。
スマホの Google フォト バックアップが有効か・画質モードはどちらか (元の画質 / 保存容量の節約)。無効または節約画質の場合でも L2 原本庫が受け皿になるため方式は変わらないが、L1 に期待できる範囲を確定してから過去分の整理に入る。
書き換えコストは履歴の量に比例する。現在は562コミット・影響する常設環境も worktree 1つで、今後のどの時点より安く・検証しやすい。
notes 写真 1,248MB→約140MB、src 207MB→約40MB、テキスト等 約20MB。合計 約0.2〜0.3GB (削減実測89%を既存分に適用した試算)。
| 現状 | 推奨案 実施後 推定 | |
|---|---|---|
| .git サイズ | 1.9 GiB | 約 0.3 GB |
| 増加ペース | 約 300 MB/月 | 約 20 MB/月 |
| GitHub 推奨上限 5GB までの猶予 | 約 1 年 | 15 年超 |
| チェックポイント経由の二次肥大 | 発生する (実測+0.5GiB) | 構造的に解消 |
| 原寸・モーション動画の保全 | repo のみ (単一保管) | スマホ+Google フォト / PC 原本庫の多重化 |
| 旧記事12本の画像配信 | 原寸級 (最大4032px) | 最大2400pxに自動改善 (完全対応は別課題) |
| ランニング費用 | ¥0 | ¥0 |
| 執筆フローの変化 | — | なし (吸い上げ処理の内部が変わるのみ) |
試算前提: 記事ペースと写真量が直近134日と同水準 / 縮小率は 0141 実測 (89%) を適用 / 動画の大量利用が始まった場合は再検討 (17頁)。
画像・動画を Git LFS 管理に切り替え、実体は GitHub の LFS ストレージへ。repo 本体は軽量なポインタのみになる。既存分の移行には履歴書き換え (git lfs migrate) を伴う。
「原寸を必ず repo 内で管理したい」「クラウド写真サービスに依存したくない」が要件になる場合。または動画中心の運用に変わり、縮小の効果が薄れる場合。
| 評価軸 | 推奨案 (軽量作業コピー) | 対抗案 (Git LFS) | 現状維持 |
|---|---|---|---|
| 初期工数 | 約2人日 (履歴整理含む) | 約1〜1.5人日 (履歴書き換え含む) | 0 |
| 継続の運用負荷 | 低 (取り込みが自動化される分、現状より下がる) | 中 (lfs 導入・枠残量の監視) | 低 |
| 費用 | ¥0 | 約2年後から月額発生 | ¥0 |
| GitHub 上限への耐性 | 15年超 | 枠10GiBまで約2年、以後は課金で延命 | 約1年 |
| 原本の保全 | 多重化 (スマホ+フォト+原本庫) | repo 内に単一保管のまま | repo 内に単一保管のまま |
| 破壊的操作 | 履歴書き換え1回 (予行演習つき) | 履歴書き換え1回 (同左) | なし |
| チェックポイント二次肥大 | 解消 | 解消 (ポインタ化されるため) | 再発し続ける |
| 個人開発全体への波及 | データ配置標準として他領域にも展開できる | ブログ repo 個別の対処に留まる | — |
総合: 費用・持続性・全体最適の3点で推奨案が優位。LFS は「原寸の repo 内管理」を要件とする場合の確かな次点。
| リスク | 対策 |
|---|---|
| 履歴書き換えの失敗・データ消失 | 実施前フルバックアップ (bundle) + 複製リポでの予行演習。失敗時は完全復元 |
| 縮小が足りなかったと後で判明 (印刷・大きな切り抜き等) | 原本庫から原寸を再取得して差し替え可能 (可逆) |
| モーション写真の動画価値の喪失 | 剥離前の原本を L1/L2 に保持。repo から消えるだけで失われない |
| worktree・デプロイ環境の再構築漏れ | デプロイ文書の手順に沿って再構築 → 公開チェック (疎通・表示) で検証 |
| Google フォト前提の不成立 | 実施前に確認 (12頁)。不成立でも PC 原本庫が受け皿となり方式は不変 |
| WSL 環境ごと消えて原本庫を失う | 写真原本は L1 (スマホ+フォト) と二重。PC 起点のスクショ類は喪失影響が小さい。必要なら外部同期を追加 (任意) |
| データの種類 | 置き場 | 掃除・保全 |
|---|---|---|
| コード・記事・メモ・設定 | git repo | 恒久 (版管理) |
| 記事用写真の作業コピー (縮小版) | git repo notes/・src/assets/ | 恒久 (取り込み時に縮小) |
| 写真・動画の原本 (原寸) | スマホ+Google フォト / PC 原本庫 ~/projects/blog-originals/ | 恒久 (repo に入れない) |
| セッションを跨ぐ中間生成物 (受け渡し文書・検証スクショ等 — 派生課題) | ~/projects/scratch/<issue>-<slug>/ (git 外・再起動で消えない) | issue クローズ時に削除 + 定期棚卸しで回収 |
| そのターン限りの一時ファイル | セッション scratchpad (/tmp) | 自動消滅を許容 |
| ビルド産物・デプロイスナップショット | deployed ブランチ / 配信基盤 | デプロイスクリプト管理 |
写真は「縮小版を repo に常置」で決着するため、意向どおり案1+案2の併用で確定できる。中間生成物は scratch の issue 別フォルダへ、リポがある作業はリポ内へ。
定期棚卸しに「repo サイズ点検・チェックポイント ref の掃除・scratch の残骸回収」を追加し、標準からの逸脱を仕組みで検出する。
| フェーズ | 内容 | 工数目安 | 性質 |
|---|---|---|---|
| Phase 0 応急処置 | チェックポイント ref の掃除 (−0.5GiB)・未追跡496MBを原本庫へ退避・Google フォト設定の確認 | 30分 | 完全に可逆 |
| Phase 1 パイプライン | 取り込みスクリプト実装 (縮小+動画剥離+原本庫保存)。1案件で先行検証 → 退避済み496MB分を縮小版でコミット | 半日 | 可逆 |
| Phase 2 履歴整理 | バックアップ → 複製で予行演習 → filter-repo 本適用 → force push → worktree/deployed 再構築 → 公開チェック | 半日〜1日 | 破壊的 (安全弁つき) |
| Phase 3 標準化 | 運用文書へ反映 (グローバル設定・ツール置き場ガイド・執筆フロー文書は担当セッションへ投書)・棚卸し項目の追加・scratch のフォルダ構造化 | 1〜2時間 | 可逆 |
効果の大きい順ではなくリスクの小さい順。Phase 0-1 だけでも増加は止まり (1.9GiBは残る)、Phase 2 を後日に切り離す判断も可能。Phase 2 実施日は他セッションの執筆・公開を止めて臨む。
スマホの Google フォト バックアップの有効/無効と画質モード。ご承認いただければ Phase 0 から着手し、Phase 2 のみ実施日を別途調整する。
| du -sh .git | ディスク上のサイズ (1.9GiB) |
| git count-objects -vH | オブジェクト数と loose/pack 内訳 |
| git rev-list --objects … | cat-file --batch-check | ref 別の到達可能 blob 実サイズ集計 |
| git for-each-ref | チェックポイント ref の発見 (refs/claude/*) |
| git ls-tree -r -l main | 追跡ファイルの最大サイズ (25.6MB) 確認 |
Claude Code が issue #142 の実測データと本セッションの追加検証をもとに作成した意思決定用資料。数値ラベル (実測/推定/要確認) の定義は3頁を参照。