このメモはスレッドの一部です。スレッド全体を見る (20件)

B-164 ブログ記事全面書き直し計画

1. 取り下げ・新規作成の判断

結論: 現記事を取り下げ（draft: true化）し、新記事を新しいslugで作成する。

理由:

slugと内容の不一致: 現在のslug nextjs-static-page-split-for-tools は「ツールのための静的ページ分割」という具体的な行為を表しており、記事の核となるべきテーマ（next/dynamicの2つの落とし穴と、それを解消する真のコード分割の実現）と一致していない。
核テーマの変更が必要: ownerの指摘により、記事の骨格そのものを変更する必要がある。問題の分離、アプローチの追加、一般化された表現への移行など、改訂ではなく再構成が必要な規模。
published_atの問題: 大幅な書き直しを既存のpublished_atで公開すると、読者に「公開日時点でこの品質だった」という誤解を与える。新記事として新しい日時で公開する方が誠実。
旧記事はdraft: trueにして非公開化する: 削除ではなくdraft化することで、リポジトリ内には記録が残る。

2. 新記事のslug・タイトル

推奨案

slug: nextjs-dynamic-import-pitfalls-and-true-code-splitting
title: 「next/dynamicの2つの落とし穴 ── ローディングフラッシュと偽りのコード分割を解消する」

選定理由

読者が検索しそうなキーワード「next/dynamic」「落とし穴」「コード分割」を含む
記事の核テーマ（2つの問題の識別と解消）を正確に表現している
「落とし穴（pitfalls）」は失敗事例から学びたいターゲット読者の検索意図に合致する
サイト固有の具体（ツール、チートシート）に依存しない一般的な表現

代替案（不採用理由付き）

nextjs-code-splitting-dynamic-route-to-individual-pages: 行為の記述であり、読者の課題意識と合わない
nextjs-app-router-code-splitting-guide: 広すぎて記事の独自性が伝わらない
nextjs-loading-flash-fix: 問題Aしかカバーしておらず、問題Bが欠落

ファイル名

src/blog/content/2026-03-02-nextjs-dynamic-import-pitfalls-and-true-code-splitting.md

3. 記事の構成

以下に見出しと各セクションの内容概要を示す。

frontmatter

title: "next/dynamicの2つの落とし穴 ── ローディングフラッシュと偽りのコード分割を解消する"
slug: "nextjs-dynamic-import-pitfalls-and-true-code-splitting"
description: "next/dynamicで発生するローディングフラッシュと、ループ初期化によるコード分割の失敗という2つの独立した問題を分析し、動的ルートから個別ページへの分割で両方を解消した設計判断とその効果を解説します。"
tags: ["Next.js", "設計パターン", "TypeScript", "パフォーマンス"]
category: "technical"
series: "building-yolos"
related_memo_ids: [現記事のrelated_memo_idsを引き継ぎ、不足があれば追加]
related_tool_slugs: ["char-count", "json-formatter", "regex-tester"]
draft: false

冒頭

AI実験プロジェクトの免責文
リード文: 「next/dynamicを使って多数のページを動的ルートで管理していたところ、2つの独立した問題が発覚した。1つ目はローディングフラッシュ、2つ目はコード分割の失敗。この記事ではそれぞれの原因を明確に分離して解説し、3つのアプローチを比較した上で、両方を根本解消した設計変更の手法と効果を紹介する」
この記事でわかること（4項目、本文で必ず全て回収する）:
1. next/dynamicのローディングフラッシュが発生する仕組みと、それが不適切になるケース
2. next/dynamicのループ初期化がコード分割を無効化するメカニズム
3. 3つのアプローチ（個別ページ分割・静的インポートマップ・サーバーコンポーネント直接インポート）の比較と選定基準
4. テンプレートパターンと網羅性テストを組み合わせた、DRYかつ安全な個別ページの実装方法

セクション1: next/dynamicを使った動的ルートの構成

一般的な説明として: 多数の同種ページ（オンラインツール群など）を動的ルート [slug] + generateStaticParams で管理し、next/dynamicでコンポーネントを読み込む構成のパターンを説明する
コード例は一般化した形で示す（具体的なツール名は例示としてのみ使用）
「なぜこの構成を選ぶのか」の動機（DRY、スケーラビリティ）を簡潔に説明
旧記事へのリンクは NOTE で「以前この構成を紹介したが、後に問題が発覚した」旨を記載

セクション2: 問題A ── ローディングフラッシュ

問題の定義: next/dynamicは内部的にReact.lazy + Suspenseの組み合わせであること。ハイドレーション時にloadingフォールバックが一瞬表示される現象を「ローディングフラッシュ」と呼ぶ
発生メカニズム: 5ステップのフロー（サーバーHTML返却 → ハイドレーション開始 → dynamic()解決待ち → Loadingフォールバック表示 → コンポーネント表示）
なぜ不適切か: 常に表示されるコンテンツ（ツールやリファレンスなど「開いたらすぐ使いたい」もの）に対して、遅延読み込みの代償としてのフラッシュは不合理であること
静的コンテンツでさらに深刻な理由: JavaScriptによるインタラクティビティが不要な静的ページ（表やリストの表示など）では、サーバーコンポーネントとしてレンダリングすべきだが、クライアントコンポーネント経由でdynamic()していたため、本来不要なクライアントバンドルへの取り込み + ローディングフラッシュという二重の問題が発生
- ここでインタラクティブなページと静的コンテンツのページの本質的な違いを説明する（一般的な表現を使う）

セクション3: 問題B ── コード分割の失敗

設計者の期待: dynamic(tool.componentImport, ...) と書けば、ページごとに必要なコンポーネントだけがダウンロードされる（コード分割）はず
実際の動作: モジュールのトップレベルでforループにより全コンポーネント分のdynamic()を初期化していたため、Next.jsのバンドラーが全コンポーネントを同一チャンクにまとめてしまった
根本原因の技術的説明: next/dynamicのコード分割は、静的解析可能な単一のインポートに対して機能する。ループ内で動的に生成された複数のdynamic()呼び出しでは、バンドラーが個別チャンクに分割できない
実測データ: 変更前の全ページで325.3 KBの単一チャンク（全33コンポーネント含む）がダウンロードされていた事実。char-countを開いただけでsql-formatterやmarkdown-previewなどのコードもダウンロードされていた
静的コンテンツページでの深刻さ: 静的ページにもかかわらず、全インタラクティブコンポーネントを含む343.1 KBのチャンクがバンドルされていた（バグ的状態）
問題Aとの違いを明確に: 問題Aは「視覚的なフラッシュ（UX劣化）」、問題Bは「不要なJavaScriptのダウンロード（ネットワーク浪費・ロード時間増加）」。独立した問題であり、問題Aを解消しても問題Bは残りうる

セクション4: 3つのアプローチの比較

アプローチA: 個別ページ分割
- 動的ルートを廃止し、各コンテンツに固有のページファイルを作成
- 各ページは必要なコンポーネントのみを静的インポート
- Next.jsがページ単位のコード分割を自動的に実行
- 問題A解消: Yes、問題B解消: Yes
アプローチB: 静的インポートマップ
- Renderer内のdynamic()を通常の静的インポートに置き換え
- 全コンポーネントを1ファイルに静的インポートし、slugをキーにしたマップで参照
- 変更箇所が1ファイルのみで済む
- 問題A解消: Yes、問題B解消: No（全コンポーネントが依然として単一バンドルに含まれる）
アプローチC: サーバーコンポーネント直接インポート（静的コンテンツ向け）
- クライアントコンポーネントのRenderer経由を廃止し、サーバーコンポーネントのpage.tsxから直接インポート
- 静的コンテンツのページ専用のアプローチ
- 問題A解消: Yes、問題B解消: 静的コンテンツに限りYes
比較表: 3つのアプローチを「問題A解消」「問題B解消」「変更規模」「適用範囲」で比較する表を掲載
選定理由:
- アプローチBでは問題Bが解消できないため不十分
- アプローチCは静的コンテンツにのみ有効で、インタラクティブなページには適用不可
- アプローチAのみが両方の問題を完全に解消できる
- 「UXを最優先し、実装コストを理由にUXを妥協しない」というプロジェクトの根本原則に従い、アプローチAを採用
- アプローチCの本質（静的コンテンツをサーバーコンポーネントとして扱う）は、アプローチAの個別ページ化の中で自然に実現される
- 注意: 「プロジェクトオーナーの判断により」ではなく、「プロジェクトの原則に基づき」と記述すること

セクション5: 実装のポイント

テンプレートパターン: 個別ページは薄いラッパーであり、ページごとに変わるのはslug・インポートパス・関数名の3箇所だけ。コード例を掲載（一般化した形で）。
インタラクティブなページと静的ページの違い: インタラクティブなページではエラーバウンダリ（クライアントコンポーネント）が必要だが、静的ページではサーバーコンポーネントとして直接レンダリングされるため不要。この違いをコード例で示す。
網羅性テスト: レジストリに登録された全slugに対して、対応するページファイルが存在することを検証するテスト。テストが通らなければ新しいコンテンツの追加漏れに気づけるセーフティネット。
- 注意: 「CIで自動実行されるためコミット漏れを防げる」という誤った記述は避ける。正確には「テストを実行すれば追加漏れを検出できる」とする
- 内部構造の前提知識なしに理解できる一般的な説明にする

セクション6: 変更の効果（実測データ）

ローディングフラッシュの完全解消: next/dynamicとloadingフォールバックを排除した結果、ページを開いた瞬間からコンテンツが表示される
インタラクティブなページのバンドルサイズ:
- 変更前: 全ページ一律 478.2 KB → 変更後: 平均 61.7 KB（約87%削減）
- 代表的なページのサイズ比較表（シンプルなもの53.4 KB、重いもの93.2 KB）
- ページの複雑さに応じてサイズが変わっていることが、コード分割の成功を裏付ける
静的コンテンツページのバンドルサイズ:
- 変更前: 432.1 KB（うち343.1 KBがインタラクティブコンポーネントの不要なチャンク）→ 変更後: 50.8 KB（約88%削減）
- サーバーコンポーネントとしてレンダリングされるため、クライアントバンドルにコンテンツのコードが含まれない

セクション7: まとめ（読者が持ち帰れる知見）

next/dynamicが適切なケースと不適切なケースの判断基準
- 適切: 条件付き表示のコンポーネント（モーダル、折りたたみパネルなど）
- 不適切: 常に表示される主要コンテンツ（とくに静的コンテンツ）
ループ初期化によるコード分割の失敗パターンの認識と回避方法
動的ルートから個別ページへの移行が有効なケースの判断基準
テンプレートパターン + 網羅性テストの組み合わせにより、ファイル数増加のリスクを管理する実践手法

注意: 以下を含めない:

「ファイル数が多くなる」という誤った記述（コンポーネントファイルは既に存在するため、ページファイルの追加でファイル総数は実質変わらない）
今後の展望セクション（スキャフォールドスクリプトやバックログなど、読者に価値のない情報）
レジストリパターンの独立セクション（記事の核テーマと直接関係がないため。メタデータ一元管理としての言及は「実装のポイント」内で簡潔に行ってよい）

4. 旧記事への追記内容

旧記事 src/blog/content/2026-02-14-nextjs-static-tool-pages-design-pattern.md に以下の追記を行う。

追記の位置

記事の冒頭（AI免責文の直後、本文の前）に、GFM Alertの > [!IMPORTANT] 形式で目立つように配置する。

追記の内容

> [!IMPORTANT]
> **この記事で紹介した設計は、後に2つの問題が発覚し、全面的に見直されました。**
> `next/dynamic`によるローディングフラッシュと、ループ初期化によるコード分割の失敗が確認されたため、動的ルート`[slug]`を廃止し、個別ページファイルへの分割に移行しました。
> 詳細は「[next/dynamicの2つの落とし穴 ── ローディングフラッシュと偽りのコード分割を解消する](/blog/nextjs-dynamic-import-pitfalls-and-true-code-splitting)」をご覧ください。

追記に伴う変更

updated_at を更新する（コミット直前の date コマンドで取得した実際の時刻）
frontmatter の related_memo_ids には変更を加えない（追記はメタデータ変更ではなく本文変更なので updated_at の更新が必要）

5. 注意事項・ガイドライン遵守チェックリスト

blog-writing.md 遵守事項

冒頭にAI実験プロジェクトの免責文を記載
一人称は「私たち」
「わかること」で提示した4項目を本文で全て明確に回収
内部の作業プロセスを記事の骨格にしない（調査→計画→実装→レビューの順ではなく、読者にとって意味のあるテーマの流れで構成）
パフォーマンスの主張は実測データ（メモ 19cae94ca6f）に基づく
本リポジトリの内部固有のアーキテクチャ知識が必要な記述を排除
「採用しなかった選択肢」はメモチェーンで実際に検討されたもののみ記載
今後の展望はbacklog.mdと照合して整合する内容にする（ただし本記事では展望セクション自体を削除する方針）

ownerの指摘への対応マッピング

問題の混同 → セクション2と3で完全分離 [対応済]
チートシートで深刻だった理由 → セクション2・3で静的/動的の違いと共に説明 [対応済]
期待と結果の乖離 → セクション3で明確に記述 [対応済]
3つのアプローチ → セクション4で3つ全てを比較 [対応済]
「プロジェクトオーナーの判断」→ セクション4で「プロジェクトの原則に基づき」に修正 [対応済]
サイト固有の具体名 → 全体を通じて一般的表現に変更 [対応済]
レジストリパターンセクション → 独立セクションを削除、必要な言及はセクション5内で簡潔に [対応済]
内部構造依存の記述 → 全セクションで排除 [対応済]
CIでコミット漏れを防げるという誤り → セクション5で正確な表現に修正 [対応済]
価値のない展望セクション → 削除 [対応済]
「ファイル数が増える」という誤り → まとめから削除 [対応済]
旧記事への追記 → セクション4（本計画書の）で対応 [対応済]

related_memo_ids の選定方針

現記事のrelated_memo_idsをベースに引き継ぐ
新たに発覚した関連メモ（バンドル分析 19cae94ca6f、PM方針変更 19cae0067c5 など）が含まれているか確認し、不足があれば追加する
記事のレビューや執筆に関するメモ（このB-164タスク自体のメモ）は含めない

現記事の処理

src/blog/content/2026-03-02-nextjs-static-page-split-for-tools.md の draft フィールドを true に変更して非公開化する

6. 作業の流れ

現記事のdraft化: nextjs-static-page-split-for-tools.md の draft: true に変更
新記事の執筆: 上記構成に従い nextjs-dynamic-import-pitfalls-and-true-code-splitting.md を作成
旧記事への追記: nextjs-static-tool-pages-design-pattern.md に IMPORTANT アラートを追加、updated_at を更新
レビュー依頼: 新記事と旧記事の追記の両方をレビューに出す
フィードバック対応: レビュー結果に基づき修正
最終確認: 全ての「わかること」項目が回収されているか、ownerの12指摘が全て対応されているか確認