B-156 計画レビュー結果

総合評価: A（承認・実装可）

計画は正確で、根本原因を正しく特定し、最小限の変更で問題を解決する適切なアプローチです。

1. 目的達成: OK

一覧ページのISRペイロードから contentHtml を除外することで、約30MB → 約1MB への削減が見込まれます。Vercelの上限19.07MBを大幅に下回るため、デプロイ失敗は解消されます。

2. 根本的解決: OK

ハック的回避ではありません。一覧ページが表示に不要な contentHtml（全メモ3,138件分のHTML本文）をクライアントに渡していたことが直接原因であり、それを型レベルで除外するのは正統的な解決策です。既存の PublicMemo 型・関数は一切変更せず、新しい軽量型（PublicMemoSummary）と関数（getAllPublicMemoSummaries）を追加する設計は、後方互換性を完全に維持しています。

3. 影響範囲の分析: OK（1件補足あり）

計画の影響範囲分析をコードレベルで検証しました。

contentHtml を使う箇所: MemoDetail.tsx (L49), MemoThreadView.tsx (L55), feed-memos.ts (L66, L75) — 全て計画通り「変更不要」で正しい
MemoFilter.tsx: PublicMemo を memos-shared.ts から直接import — 計画のStep 3の変更で正しく対応可能
MemoCard.tsx: 同上 — contentHtml を一切参照していないことを確認済み。Step 4は正しい
getAllMemoRoles / getAllMemoTags: page.tsxで呼ばれているが、内部で getAllPublicMemos() を使う。これらの戻り値（string[]）はISRペイロードに含まれるが微小サイズのため問題なし

補足: sitemap.ts について

計画では「sitemapはSSGで個別にレンダリングされるため一覧ページのペイロードには含まれない」としてスコープ外としています。技術的にはこれは正しいです。ただし、sitemap.ts（L96）も getAllPublicMemos() を呼んでおり、contentHtml込みの全データをメモリにロードしています。直ちに問題にはなりませんが、もしビルダーの工数に余裕があれば、sitemap.tsも getAllPublicMemoSummaries() に切り替えることを推奨します（sitemap.tsは id と created_at しか使っていないため）。これは任意の改善であり、必須ではありません。

4. 既存機能の維持: OK

フィルタ機能: MemoFilter は from, to, tags でフィルタリングしており、これらは PublicMemoSummary にも含まれる
ページネーション: paginate() は配列を受け取るだけなので型変更の影響なし
個別メモページ / スレッドページ: 変更対象外。引き続き PublicMemo（contentHtml含む）を使用
RSS/Atom フィード: feed-memos.ts は引き続き getAllPublicMemos() を使用。変更なし
cross-links.ts: getPublicMemoById() を使用。変更なし

5. テスト方針: OK（1件推奨あり）

計画のテスト方針（新規テストで getAllPublicMemoSummaries() が contentHtml を含まないことを確認）は適切です。

推奨追加: ビルダーへの指示として、npm run build の成功確認に加えて、ビルド出力から /memos ページのペイロードサイズを確認する具体的な方法を明記すると良いでしょう。計画には npx next experimental-analyze の記載がありますが、より確実な方法として .next/server/app/memos.html のファイルサイズ確認（存在する場合）を併記することを推奨します。

まとめ

計画は十分な品質です。そのまま実装に進めて問題ありません。