| 依頼 | 「5資料を読んで別人格として反証的観点で批判するポイント、問題があるかもしれない点を指摘してほしい (資料は良いことがメインなので信頼性を高めるため)」— プロジェクトオーナー (2026-08-21) |
|---|---|
| レビュアー | この作業の文脈を持たない別の Claude Code エージェント (懐疑的な監査役・第三者技術コンサルタントの立場を指示)。5資料と実施記録のパスのみを渡した |
| 照合 | investigation / decisions / phase0〜3-record、レビュー時点 (2026-08-21) のローカル repo と GitHub API の実値 |
| 位置づけ | AI 生成の第三者所見。指摘の事実関係は作者 (実施セッション) が確認し、末尾に自認と是正を付記。本文の指摘は原文のまま |
何が問題か — 実行計画書 11〜12頁は Phase 2 の手順 4 に「予行演習 — 別クローンで filter-repo を実行し、削減後サイズ・コミット数・記事ビルドを検証」を置き、Gate 1 の通過条件に「予行演習で削減後サイズとビルドを確認」を含めている。しかし phase2-record には予行演習の工程がなく、冒頭で「Gate 1 = ユーザー GO」と条件が縮小されている。完了報告は 2頁「破壊的操作は全 Gate を通過」、4頁「Gate 1〜3 全通過」、6頁「Gate 3段構えで無事故完了」と記載し、8頁「計画からの変更 2点」に予行演習の省略は含まれていない。
なぜ問題か — 本番クローンで 3 パスを要した事象 (完了報告 9頁) は、予行演習があれば本適用前にリストの欠落として検出できた性質のものである。報告はこれを「安全設計が機能した点」として再解釈しており、計画からの逸脱が成功談に置き換わっている。Gate が一言の指示で条件を失うなら、Gate は統制として機能していない。
解消するには — 完了報告の変更一覧に「予行演習の省略」を追加し、Gate 1 の実際の通過条件を明記する。今後は Gate 条件の変更自体を承認事項にする。
何が問題か — 完了報告 3頁「D: に多重保全 (原本7.8GB+完全バックアップ1.5GB×2形式)」、実行計画書 11頁「bundle + .git の複製を D:\Backups\ へ」。本日確認した限り、/mnt/d/Backups に bundle と .git 複製の両方があり、PC 側の旧作業コピーは 8/27 に削除予定 (完了報告 14頁)。Google フォトは無効 (実行計画書 2頁)、スマホ側は「ブログ専用写真は同期後に削除」運用が開始済み (完了報告 12頁「初回で3枚実施済み」)。
なぜ問題か — 8/27 以降、旧履歴の復元手段と写真原本 (スマホから削除した分) の両方が 1 台の USB ドライブだけに依存する。「2形式」は媒体故障に対して冗長性を与えない。実行計画書 15頁はこのリスクを「中」とし「ブログ分は repo の 2400px 版が残るため許容」としているが、履歴書き換えの切戻し手段 (bundle) が同じ媒体にある点はリスク表に載っていない。完了報告 15頁自身が「D: 単一保管の解消が残る最大のリスク」と認めつつ、2頁では「主要目標をすべて達成」としている。
解消するには — bundle (1.5GB) を PC 内部ディスクと別媒体 (クラウド含む) に即時複製し、旧作業コピーの削除はその後にする。同一媒体内の複製を「多重」と呼ばない。
何が問題か — 戦略提案 2頁・14頁は「300 → 20MB/月 (約1/15)」とするが、同 11頁の削減実測は 38.6MB→4.2MB (89%・約1/9)。300MB/月 × 11% = 約33MB/月であり、20 にはならない。1/15 に一致するのは Phase 1 の「32MB (従来運用なら約495MB)」(phase1-record) だが、これは提案後の値で、かつ 495MB のうち 214MB は動画 2 本 (1 本 106MB) であり、履歴上の動画比率 (追跡 mp4 3 本・1.4GB 中) と大きく異なるサンプルである。また Phase 2 の実績は 1,354→186MB (86%) で、89% より低い。
なぜ問題か — 「15年超の猶予」は 20MB/月 の線形外挿に依存しており、33〜40MB/月 なら 9〜12 年になる。反証条件「実施後1年で1GB超」(戦略提案 17頁) は 約58MB/月 に相当し、推定値の約 3 倍まで逸脱を許容する緩い閾値である。
解消するには — 20MB/月 の計算式と前提 (写真枚数/月・動画の扱い) を明記し、帯 (例: 20〜40MB/月) で示す。反証条件は推定値の 1.5 倍程度に設定する。
何が問題か — 戦略提案 4頁「GitHub 側 repo サイズ 約1.27GiB 実測」の出典は issue 本文の API size 値 (1,333,925KB)。完了報告 3頁は「約1.38GB・旧オブジェクト掃除待ち」。本日 GitHub API の size 値 は 14,186KB (約14MB) で、ローカルの pack 287MiB とも 1.38GB とも一致しない。戦略提案 21頁の計測コマンド一覧にはローカル計測のみで、GitHub 側の方法が記載されていない。
なぜ問題か — 本件の目的は「GitHub 推奨上限 5GB・理想 1GB」への対処であり、達成判定はリモート側で行うべきものである。API の size は非同期更新で実サイズと乖離することが知られており、この値を根拠に「掃除待ち」「15年超」を語るのは計測の妥当性確認を欠く。完了報告 2頁の「主要目標をすべて達成」は、リモート側が未検証の段階では前倒しである。
解消するには — 計測方法を固定する (git clone --mirror 後の du、git-sizer、Settings 画面の表示のいずれか) と、達成判定を 9 月の確認後に送る。
何が問題か — 戦略提案 8頁「約1年で5GB到達」は旧ペース (300MB/月) の前提である。Phase 0-1 完了時点で .git は 1.4GiB、増加は 20〜40MB/月 になっており、5GB まで 8〜15 年の猶予がある。戦略提案 13頁「今やる理由: 書き換えコストは履歴の量に比例する」はコスト側のみの議論で、新運用下では追加コミットが小さいため後日実施してもコストはほぼ増えない。便益 (ローカル 1.1GiB の削減と、未確認のリモート側縮小) に対し、代償は全 SHA 変更・旧コミットで写真が失われること・deployed ブランチ履歴の破棄 (指摘 15) である。
なぜ問題か — 選択肢評価 (8頁) に「A+G のみ (履歴は残す)」が独立案として並んでおらず、「E 採用」の判断が緊急性の低下後に見直されないまま同日に実行された。
解消するには — 選択肢表に「Phase 0-1 のみ」を追加し、便益/代償を並べる。破壊的操作は、前提数値が変わった時点で承認を取り直す手順にする。
何が問題か — 戦略提案 16頁の「原本の保全」欄で LFS を「repo 内に単一保管のまま」、推奨案を「多重化 (スマホ+フォト+原本庫)」とする。しかし LFS は GitHub 側 (オフサイト) + ローカルの地理的冗長を持ち、推奨案は結果的に USB 1 台 (指摘 2)。「原本は LFS・作業コピーは 2400px」のハイブリッド、クラウドオブジェクトストレージ (R2/B2 等、10GB 規模で月数十円) への原本保管は検討されていない。LFS の「約2年で枠到達」は原寸 300MB/月 前提で、縮小ルールと併用した場合の試算がない。
なぜ問題か — 「費用 ¥0」が明示されない制約として設計を支配しており、少額のクラウド費用で解消できる最大リスク (D: 単一保管) を自ら残している。
解消するには — 評価軸に「オフサイト冗長性」を追加し、ハイブリッド/クラウド保管を候補に入れる。費用制約を明文化する。
何が問題か — 戦略提案 5頁「ローカルディスクには十分な余裕がある 実測 897GB」は誤りで、オーナーの指摘で発覚 (審議録)。同 4頁「増加ペース 実測 約300MB/月」は 1,415MB ÷ 134日 の平均値であり、3頁の定義 (実測 = 検証済みの事実) に照らせば推定である。審議録の「チェックポイントは30日で自動掃除される性質のもの」は、investigation の「掃除の自動化仕様は未確認」と矛盾する。
なぜ問題か — ラベル制度は資料の信頼性の中核だが、オーナーが唯一自力で検証できた数値が誤っていた。他の「実測」がどこまで独立に確認されたか読者には判別できない。審議録の方針「資料は修正せず固定」により、誤値は公開後も資料内に残る。
解消するには — 「実測」を「コマンドと出力が記録に残る値」に限定する。固定した資料には表紙に正誤表への参照を置く。
何が問題か — canary 5枚は 0107 (PC セットアップ) と 0124 (memtest) で、いずれも画面の文字を写した写真 (phase1-record)。Phase 2 で再エンコードした 356 件 (料理・家族・屋外写真を含むと推定される) の色味・階調は確認記録がない。完了報告 6頁・11頁の公開チェックは「全200」(疎通) であり、実行計画書 11頁にあった OGP・W3C・Lighthouse の結果は記載がない。DoD #3「全記事の表示OK」の証跡が HTTP 200 のみ。
なぜ問題か — 文字可読性の検証は JPEG 再圧縮の典型的な劣化 (肌色・グラデーション・暗部) を捉えない。公開中の全記事の画像が一括で差し替わった操作としては、視覚的な回帰確認が薄い。
解消するには — 再エンコード分から人物・屋外・暗所の代表数枚を before/after で並べて確認し、Lighthouse 等の実行結果を添付する。
何が問題か — pre-commit は core.hooksPath 依存 (再クローンで消える・環境再構築時に一度再設定を要した)、--no-verify で回避可、運用者は AI 自身。実行計画書 4頁・9頁のしきい値「1.5MB超 or 長辺2400px超」に対し、実装は JPEG 2.5MB超・2420px超・動画15MB超 (本日 scripts/check-media-size.mjs で確認) で、完了報告に変更の記載がない。実行計画書 15頁「checkpoint 肥大の再発: 小 — 原寸が作業ツリーに入らない構造で解消」は写真以外の巨大未追跡ファイルを想定していない。EXIF 削除 (位置情報を repo に持ち込まない) は再エンコードした 356 件に適用されるが、等倍コピーした 154 件の扱いは記載がない。
なぜ問題か — 単一の任意回避可能なフックに再発防止を依存しており、ルールの適用範囲も不均一である。
解消するには — サーバ側検査 (GitHub Actions でのサイズ検査) か pre-push を追加し、しきい値変更を変更一覧に載せ、154 件のメタデータ有無を確認する。
何が問題か — 承認者は作成依頼者と同一人物 1 名。審議録によれば 42 枚の資料を 13:20〜16:30 で審議し、C1 (リスク表の網羅性)・C2 (履歴書き換えの帰結) は「問題なし」の一語で通過。推奨 4 点はすべて推奨どおり承認。オーナーの実質的な寄与は前提の事実訂正 3 点 (Google フォト・PC 容量・USB 容量) で、これらは起案側が事前に確認できた事項である。
なぜ問題か — 構造上、資料が詳細であるほど承認は批准に近づく。リスク表の「網羅性」を承認者が独立に検証した形跡はない。
解消するには — 決定ごとに「承認者が独立に確認した事項」を記録する。不可逆操作 (D3) の承認と実行の間に一定の間隔を設ける。
何が問題か — 完了報告 4頁「実働短縮の主因: 事前の実測・予行設計に時間を投じたこと」、15頁「安全設計への投資は回収された」。見積 (約2人日) に対し実働約 3.5 時間 (phase0〜3-record の時刻) で、これは見積精度の低さの表れでもあるが報告では成果として扱われる。12頁「本件を知らない記事セッションが…初見で完走」は同一 AI・共有メモリ・n=1 である。実施録は「発言はチャットログからの要約」で、AI 側の回答は AI 自身の要約。
なぜ問題か — 反証不能な自己評価が「品質保証」「実証」の見出しで提示され、読者が独立検証の有無を区別できない。
解消するには — オーナーが自力で再実行できる検証コマンド一覧 (count-objects、bundle verify、リモート側サイズ) を付録に置き、第三者所見を資料セットに含める。
何が問題か — GiB/GB/MB が混在 (「1.9GiB → 0.3GB」「1.27GiB」と「1.38GB」)。実施終了時刻が完了報告 4頁「22:30」、実施録「23:00 ごろ」。戦略提案 13頁の内訳見込み「テキスト等 約20MB」に対し、媒体除去後の .git は 109MB (完了報告 9頁) で約 5 倍だが照合がない。「原本 7.8GB」は repo-export (1.36GB) と全量同期 (5.9GB) の重複分を含む。
解消するには — 単位を統一し、見込みと実績の内訳対応表を完了報告に加える。
何が問題か — 58 枚+議事録 2 本。KPI ボックスに「−3.7GB Windows 空き容量」(完了報告 8頁によれば大半は過去の未回収領域で本件の効果ではない)、「¥0」を並べる一方、目的に直結する不利な数値 (GitHub 側サイズ未反映) は表の最終行にある。notes.md のオーナー発言「判断が楽になったは言い過ぎ」「社長向けなら簡潔になったかも」は、分量が審議の質に結びつかなかった自覚を示している。
解消するには — 1 頁サマリ+付録の構成にし、KPI は目的指標 (リモート側サイズ・増加ペース実測) に限る。
何が問題か — 実行計画書 14頁でこのリスクを「小」とし、復旧を「サポート依頼 (最終手段はリポジトリ再作成)」とするが、再作成に伴う issue/リンク・デプロイ連携・collaborator 設定の喪失は記載がない。また force push 後も旧コミットは GC まで GitHub 上で SHA 直指定で参照でき、「旧ハッシュ参照切れ」と「除去完了」のどちらも現時点では部分的である。
解消するには — サポート依頼の手順と再作成時の影響一覧を事前に書く。
何が問題か — 実行計画書 10頁「全ブランチ (deployed/feat) も一括で追従させる」に対し、phase2-record は「deployed ブランチ: 新 main と同一点に再作成」。完了報告 11頁は「タグ/ブランチ追従 合格」。deployed の履歴 (デプロイ世代) は失われたが、完了報告に記載がない。「テキスト履歴保全」の検証は README 1 ファイルの 33 コミットのみ。
解消するには — Gate 2 の検証内容を具体的に記録し、失われた履歴を了承事項として明記する。
5 点の資料は構成と体裁が整っており、実測値と推定値を区別しようとする姿勢も見えるが、その区別が肝心な数値 (897GB・300MB/月・20MB/月・GitHub 側サイズ) で機能していない。計画段階で自ら設けた安全弁 (予行演習・別日実施) は当日中に一言の指示で外れ、完了報告はそれを変更として記録せず「全 Gate 通過」と表現している。本件の目的であるリモート側サイズは未検証で、切戻し手段と原本は単一 USB に集中しており、「主要目標をすべて達成」「多重保全」は現時点では割り引いて読む必要がある。読者は、数値の大半がローカル計測と線形外挿であること、検証と報告がすべて実施者自身によることを前提に、付録のコマンドで独立に追試したうえで判断するのがよい。