議事録 / MINUTES — 計画審議
写真アーカイブ戦略 審議録
戦略提案・保管設計・実行計画の審議と質疑応答の記録
第1部 戦略提案の審議 資料①
Qこの資料は私だけが見られる状態か。公開設定にすれば誰でも見られるのか
A既定は非公開 (本人のみ)。共有メニューを使えばリンクを知っている人は誰でも閲覧できる。本件はブログ記事として公開する予定のため、共有機能は使わない方針とした
→ 資料は現状のまま固定 (以後の指摘は資料を直さず記録で管理)
A
① Google フォトは無効 — 無料枠15GBのうち約11GB使用中で、有効化すると溢れるため。「googleフォトは考えてません」。→ 原本バックアップ層の想定を修正
② スマホの事情 — #76 で Xperia から Pixel に買い替え済み。旧機はSDカード保存だったが Pixel にSDスロットがない (128GB中63GB使用)。ブログ用写真は退避したい・家族写真は残したい・両用もある
③ PC 容量の訂正 — 資料の「空き897GB」に対し
237GBのストレージで、93.5GBの空き容量となっております。900GBもないですよ。(どこを見たのか気になります。WSLの設定が間違ってるのかも?!)— プロジェクトオーナー
Claude Code が誤りを認めて訂正: 897GB は WSL 仮想ディスク (既定最大1TB・シンプロビジョニング) の見かけ値で、実制約は Windows 物理空き93.5GB。設定ミスではなく AI の読み違い。仮想ディスクは自動縮小しないため、圧縮工程を Phase 2 に追加した
→ 資料5・12頁の「空き897GB」は誤りとして扱う (訂正は決定記録に記載)
| 決定 | 内容 | 結果 |
|---|
| D2 | repo 内写真の上限 = 長辺2400px・品質85 | 承認 |
| D3 | 過去分の履歴書き換えを実施 | 承認 |
| D4 | 未追跡496MBは退避し縮小版のみコミット | 承認 |
| D1 | 原本の repo 外分離 | 承認 (保存先 L1/L2 は再考) |
追加情報: 1TB の USB ドライブを保有 (のちの実測で 460GB と判明)。
第2部 保管設計の再審議 L1/L2 の置き場
QUSB の実態共有と、家まわり整理の切り出し・重複の懸念
A
オーナーより: USB は
常時挿しに変更済み (D: として認識・実容量460GB・空き166GB。旧PCからの移行データが同居しており「データの整理も合わせてしたい」)。ブログ専用写真の削除運用は了承 —
提案してもらって、まずいやつだけ削除しないようにする— プロジェクトオーナー
家族写真・旧Xperia・旧PCデータは一括の別 issue とする案に加え、重複の指摘:
ブログ用のを吸い上げるものとかぶりませんかね？Pixelに入ってるものは定期的にUSBに吸い上げる運用でよさそうな気もするのですが。— プロジェクトオーナー
Claude Code の再設計 (v2): この直感を軸に採用し、
定期吸い上げ先 D:\PhotoArchive がブログ原本庫を兼ねる一本化へ変更。ブログ個別の原本フォルダは作らず、記事との対応は images.md のファイル名参照 (Pixel のファイル名は撮影日時入り)。常時接続になったためステージング層は廃止。#142=道具の整備 / 別issue=中身の整理、という分担で重複を解消
→ 「それでOKです」— v2 で確定 (一本化 / ステージング廃止 / 同期はまず手動+吸い上げ時 / home issue 起票)
第3部 実行計画書の審議 資料②・実行前の最終確認
| 確認 | 内容 | 判断 |
|---|
| C1 | リスク管理表の網羅性 | 「問題なし」 |
| C2 | 履歴書き換えの帰結 (旧コミットに写真が残らない等) | 「問題なし」 |
| C3 | Phase 2 の実施日 | Phase 0-1 完了後に判断 (「随時執筆中なので決められない」) |
| C4 | スマホ削除の初回タイミング | 急がず Phase 1 後に「タイミングを見計らって」 |
Q追加質問1: checkpoint ref を削除したら、当該セッションは困らないか
A公式ドキュメントに削除影響の明記はない (専門エージェントで確認)。チェックポイントは30日で自動掃除される性質のもので、削除対象の中身 (未追跡写真496MB・当時の追跡状態) はすべて別所に保全してから消す。最悪ケースでも「その旧時点への巻き戻しが使えない」まで — セッションの継続・新規チェックポイントには影響しない。実行は他セッション非稼働時に行う
→ 了承
Q追加質問2: 未追跡写真を退避したら、執筆中のブログセッションは困らないか
A全記事・全ドラフトの import を走査した結果、notes/ を参照するものはゼロ (採用画像は退避対象外の src/assets にある) — ビルド・プレビューへの影響なし。残る影響は images.md 記載との一時的な不整合のみで、縮小版が同名・同位置に戻る。Phase 0→1 を連続実施して間隙を最短にし、該当 issue へ退避の通知コメントを残す
→ 了承
Q追加質問3: USB の WSL マウントは大変ではないか (過去に苦労した記憶がある)
A苦労の記憶は usbipd (USBデバイスのパススルー・adb等で使用) の可能性が高い。今回は Windows が既に D: と認識しているストレージを見るだけなので drvfs の1コマンドで済み、fstab に1行足せば以後は自動。スクリプト側も未マウント時は検知して安全に中断し、修復コマンドを表示する設計
→ 了承 (実施はまず PC を再起動し、自動マウントの検証を兼ねてから開始することとした)
決定事項一覧
| # | 決定 |
|---|
| 1 | 方針 = 軽量作業コピー方式 (D1〜D4 承認)。対抗案 Git LFS は不採用 (条件変化時に再比較) |
| 2 | 原本庫は D:\PhotoArchive に一本化 (媒体別・年月構造)。ブログ個別フォルダなし・images.md 参照方式 |
| 3 | ステージング層は廃止 (USB 常時接続)。同期は「記事の吸い上げ時+手動」で開始 |
| 4 | スマホ削除は承認制 (候補提示 → 残すものを指定 → 明示 GO) |
| 5 | 家族写真・旧Xperia・旧PCデータの整理は別 issue ([scope] home) に切り出し |
| 6 | 実行は Phase 0 から着手。Phase 2 の日程のみ後日判断 |
記録上の特記: 審議を通じて資料の前提が3点修正された (Google フォト無効・PC 実容量・USB 実容量)。とくに「空き897GB」は AI が WSL 仮想ディスクの見かけ値を実容量と誤読したもので、オーナーの指摘により発覚した。資料は修正せず固定し、訂正は決定記録・実行計画書 (2頁) に明記した。