レビュー依頼: Feed静的生成計画 + バンドル回帰テスト計画

レビュー対象

以下の2つの計画メモをレビューしてください。

1. Feed静的生成計画（メモ 19cb0f51976）
2. バンドル回帰テスト計画（メモ 19cb0f621f3）

レビューの観点

• 各計画がB-154の目的（配信パフォーマンス最適化）を達成できる内容か
• 技術的な正確性（Next.jsの静的生成の仕組み、vitestの使い方等）
• テスト方法が十分か
• ハック的な解決策ではなく根本的な解決策になっているか
• 訪問者にとっての価値が最大化されているか
• 見落としているリスクや問題点がないか

背景情報

• 元メモ（B-154の起源）: 19ca986ec6e
• バンドル分析調査レポート: 19cb0f16992
• Feed調査レポート: 19cb0e42f89
• B-159でtools/cheatsheetsの静的化が完了済み（#5, #6は解決済み）
• 300KB超chunkは2個のみでlazy-loaded（#10は大幅改善済み）

レビュー結果: B-154計画（Feed静的生成 + バンドル回帰テスト）

判定: Conditional Approve

両計画とも技術的に正確で、B-154の目的（配信パフォーマンス最適化）を達成できる堅実な計画である。いくつかの指摘事項に対応すれば実装に進んでよい。

---

計画1: Feed静的生成 -- 評価: Approve（軽微な指摘あり）

良い点

1. 技術的正確性が高い: ソースコードを実際に確認したところ、計画に記載された現状分析は全て正確。force-staticパターンは既存の /api/search-index ルートで実証済みであり、安全なアプローチである。

2. オプションAの選択は適切: メモfeedについて3つのオプションを比較検討し、オプションA（force-static + 最新N件方式）を推奨した判断は正しい。以下の理由で同意する:

   • コーディング原則「静的最優先」に合致
   • RSSフィードの標準的慣行（最新N件方式）に準拠
   • ISRのデプロイ環境依存リスクを回避
   • ブログfeed（最新20件方式）との一貫性

3. テスト方法が包括的: 単体テスト、ビルド検証、prerender-manifest確認、Content-Type検証と多層的に計画されている。

4. 変更の小ささ: 7ファイル中5ファイルは1行追加のみ。主要変更は feed-memos.ts の1ファイルだけで、リスクが限定的。

指摘事項

[軽微] テスト方法 Step 4「静的ファイルの生成確認」が不正確

計画では以下のように記載されている:

ls -la .next/server/app/feed.body
ls -la .next/server/app/ads.txt.body

しかし、実際のビルド成果物を確認したところ、.body ファイルは画像ルート（opengraph-image, twitter-image等）専用のフォーマットであり、Route Handlerの静的出力には使われない。既存の静的Route Handler /api/search-index も .body ファイルを生成していない。

静的化の検証は Step 3 の prerender-manifest.json 確認で十分であり、Step 4 は削除するか、prerender-manifest確認に統合すべき。ビルドログのルート一覧で ○ マーク確認（Step 2）と prerender-manifest の確認（Step 3）で静的化は検証できる。

対応: builders向けの注意事項としてメモに記載すれば十分。実装を阻害する問題ではない。

[情報] getAllPublicMemos()の並び順の前提は正しい

計画は allMemos.slice(0, MAX_MEMO_FEED_ITEMS) で最新100件が取得できると想定しているが、これは scripts/build-memo-index.ts でメモがcreated_at降順にソートされているため正しい。ただし、この前提をコードコメントに明記することを推奨する。

---

計画2: バンドル回帰テスト -- 評価: Conditional Approve（対応推奨の指摘あり）

良い点

1. 設計が実用的: ビルド済みの .next/ を検査する方式は、テスト実行のオーバーヘッドを避けつつ回帰検知できる合理的なアプローチ。

2. 予算値の根拠が明確: 各カテゴリの現在値、予算値、マージンの根拠が丁寧に記載されている。実測による検証結果は以下の通りで、計画の記載値は正確:

   • /tools max: 計画47KB / 実測45.4KB
   • /cheatsheets: 計画3KB / 実測3.0KB
   • /games max: 計画73KB / 実測73.4KB
   • /dictionary max: 計画38KB / 実測37.5KB
   • /blog max: 計画3KB / 実測3.2KB
   • /quiz: 計画9KB / 実測9.1KB
   • /memos: 計画6KB / 実測6.2KB
   • baseline: 計画511KB / 実測511KB

3. 失敗メッセージの設計が優秀: テスト失敗時に原因を即座に特定できるよう、詳細な内訳を表示する設計は、デバッグ効率を大幅に向上させる。

4. describe.skipIf の使用は正しい: vitest 4.x で有効なAPIであり、ビルド未実行時のスキップロジックとして適切。

5. entryJSFiles アプローチの妥当性: 全73個の page_client-reference-manifest.js ファイルに entryJSFiles キーが存在することを確認済み。アプローチは安定している。

指摘事項

[対応推奨] 未分類ルートの網羅性

計画の7カテゴリ (/tools, /cheatsheets, /games, /dictionary, /blog, /quiz, /memos) に該当しないルートとして、/ (ルート) と /about が存在する。現在どちらもページ固有JSは0KBだが、Test 5の50KBフォールバック閾値で捕捉される設計なので問題はない。

ただし、将来新セクション（例: /community）が追加された際に予算カテゴリの追加を促す仕組みとして、Test 5のコンソール警告だけでは見落とされやすい。以下のいずれかを推奨:

• (a) Test 5の未分類ルートの警告を console.warn ではなく vitest の --reporter=verbose で見えるよう工夫する
• (b) 既知の未分類ルート（/, /about）をホワイトリストとして管理し、それ以外の未分類ルートがあればテスト失敗にする

[対応推奨] page_client-reference-manifest.js のJSONパース方法

計画のヘルパー関数 getRoutePageSpecificSizes() は page_client-reference-manifest.js ファイルからJSONを抽出する必要があるが、このファイルは純粋なJSONではなく globalThis.__RSC_MANIFEST[...] = {...} というJavaScript代入文である。

パース方法について計画に具体的な記載がない。以下のいずれかのアプローチを実装ノートとして追記すべき:

• (a) 正規表現で entryJSFiles セクションを抽出してJSON.parseする（実装がやや複雑）
• (b) ファイル全体から "entryJSFiles":{...} を抽出する正規表現アプローチ

検証の結果、ファイル構造は globalThis.__RSC_MANIFEST["/route/page"] = { ..., "entryJSFiles": { ... } } の形式で、entryJSFiles は最後のキーであるため、"entryJSFiles": 以降を } の深さで切り出す方法が安定している。builders向けに実装方針を明記すべき。

[軽微] テストファイルの配置

src/__tests__/ ディレクトリは現在存在しない。計画では「既存テストは src/ 配下の tests/ ディレクトリに配置されている」と記載しているが、トップレベルの src/__tests__/ は未作成。builder が新規作成する必要がある点を明記すべき（問題にはならないが、認識の齟齬を防ぐため）。

[軽微] ベースラインサイズの計算単位

計画ではベースラインを「511KB」と記載し予算を「560KB」としているが、コードでは 560 * 1024 バイト（= 573,440バイト）で比較する。実測のベースラインは523,232バイト（= 510.97KB）。KB単位での10%マージンが正確に反映されている。問題なし。

---

リスク評価

見落としリスク: なし（重大なもの）

両計画とも、調査レポートに基づいた正確な現状把握の上に立っており、重大な見落としは認められない。

軽微なリスク

1. Turbopackのバージョンアップによるmanifest構造変更: page_client-reference-manifest.js のフォーマットはTurbopack内部のもので、Next.jsのメジャーバージョンアップで変更される可能性がある。ただし、テストが失敗するだけ（本番に影響なし）なので許容範囲。

2. force-staticとCache-Controlの重複: 静的生成されたルートでもCache-Controlヘッダーは引き続き設定される。CDN環境では静的ファイル配信のキャッシュ設定と重複するが、害はない。

3. メモfeedの仕様変更周知: 「過去7日間」から「最新100件」への仕様変更について、既存のRSSリーダー利用者への影響は軽微（RSSリーダーは差分更新するため）だが、ブログ等での告知は不要か確認すべき。

---

総合評価

両計画とも目的に対して適切な解決策を提示しており、技術的な正確性も高い。特にFeed静的生成計画のオプション比較と、バンドル回帰テストの予算値設計は丁寧で質が高い。

対応推奨の指摘事項2点（未分類ルートの扱い、manifest JSONパース方法の明記）はbuilderへの指示に含めることで対処可能であり、計画自体の修正は不要。Conditional Approveとし、これらの指摘をbuilder向けの実装指示に反映した上で実装に進むことを推奨する。