深層調査依頼①: アーキテクチャパターンの比較分析

背景

B-119（ディレクトリ構造全面リファクタリング）のプラン策定をやり直しています。 前回の調査（19c973a5b8d）では案B（フィーチャーベース完全統合型）を推奨しましたが、ownerからアーキテクチャの強み・弱みの十分な分析が不足しているとのフィードバックがありました。

今回はより深い分析を行い、yolos.netの特性に最適なアーキテクチャを選定するための判断材料を提供してください。

yolos.netの特性（判断基準のベース）

• AIエージェントが自律的に開発・運営するサイト（人間の開発者はいない）
• コンテンツ種別が多い: ブログ(35記事), ツール(31個), ゲーム(4種), クイズ(複数), 辞典(漢字/四字熟語/伝統色), チートシート(3個), メモ
• 各コンテンツ種別の性格が大きく異なる:
  • ブログ: Markdownファイル、ビルド時読み込み
  • ツール: React Component + ロジック + メタデータ、既にコロケーション済み
  • ゲーム: 複雑なインタラクティブアプリ、状態管理・日替わりロジック
  • クイズ: データ駆動、レジストリパターン
  • 辞典: JSONデータ + 表示コンポーネント
  • チートシート: ツールと類似のレジストリパターン
• 今後もコンテンツ種別・量が増える可能性が高い
• Next.js App Router（静的サイト生成が基本）
• coding-rules.md: 静的最優先、シンプルで一貫した設計、可読性、型安全

調査項目

1. アーキテクチャパターンの網羅的調査

前回の3案（コンテンツ統合型、フィーチャーベース完全統合型、ハイブリッド型）に加えて、以下のパターンも調査してください:

• ドメイン駆動型: コンテンツの「ドメイン」（日本語学習、開発ツール、ゲーム等）で分割する方法
• レイヤード+モジュール型: 現在のレイヤー構造（app/components/lib）を維持しつつ、各レイヤー内をモジュール化する方法
• モノレポ風パッケージ分割: 各フィーチャーを疑似パッケージとして扱う方法
• その他: Web上の実例で、content-heavy Next.jsサイトの優れた構造パターンがあれば

2. 各パターンの詳細な強み・弱み分析

各パターンについて、以下の観点で分析してください:

• コロケーション: 関連ファイルがどの程度近くに配置されるか
• 責任分界点の明確さ: 新しいコードをどこに追加すべきか迷わないか
• スケーラビリティ: コンテンツ種別が10個、20個に増えても破綻しないか
• フィーチャー間の依存管理: 共有コード・データの扱い方
• 移行コストとリスク: 現在の構造からの移行量
• AIエージェントとの親和性: コードを読み書きするのが人間ではなくAIであることの影響
• Next.js App Routerとの親和性: ルーティング層との整合性

3. 実例調査

• content-heavy Next.jsサイトの実際のディレクトリ構造の事例（GitHub上の公開リポジトリ）
• 大規模Next.jsプロジェクトの推奨構造についての信頼できる情報源

4. 共有コード・データの配置パターンの比較

前回 shared-data/ という案がありましたが、共有リソースの配置方法について、より体系的に比較してください:

• 共有データを専用ディレクトリに置く方法 vs フィーチャー内に置いて他から参照する方法
• 共有コンポーネント（Header, Footer等）の最適な配置
• ユーティリティ関数の共有方法

成果物

• 各アーキテクチャパターンの詳細な比較表
• yolos.netの特性を考慮した推奨案（単一ではなく、根拠を明示した上でのランキング）
• 「新しいコンテンツ種別を追加するとき」のワークフロー比較