B-057調査A: レジストリパターンを維持するi18n翻訳アーキテクチャ

調査依頼

ownerフィードバック（メモ 19c7b2aeeda）の論点1・論点2に関する調査を行ってください。

背景

このプロジェクトは「レジストリパターン」を採用しています。各ページが自己完結的にデータを管理し、ページ間の依存を最小化する設計です。複数のAIエージェントが同時に別々のページを開発できるようにするためです。

参考ブログ記事（これを読んでパターンを理解すること）:

• src/content/blog/2026-01-30-nextjs-static-tool-pages-design-pattern.md

現在の設計ドキュメント（問題のある設計）:

• docs/design/directory-restructure-i18n.md のセクション3.3（辞書システムの設計）

問題点

1. 単一JSON問題: 提案された src/dictionaries/ja.json / en.json は単一の巨大ファイルになり、レジストリパターンを破壊する。LLMのコンテキストに収まらない可能性がある
2. 個別最適化不可: すべてのページが同一のjsonを参照する設計では、「この記事は英語のみ」「このゲームは日本語のみ」といった言語別の個別制御ができない

調査内容

以下の方式について、それぞれのメリット・デメリットを調査し比較してください:

1. ページ併置方式: 各ページディレクトリ内に翻訳ファイルを配置（例: tools/json-formatter/messages.ja.json）
2. コンテンツファイル分割方式: src/content/ のコンテンツファイル自体に多言語データを持たせる（例: registry.ts に日英の title/description を含める）
3. 名前空間分割JSON方式: 機能単位でJSONを分割する（例: dictionaries/common.ja.json, dictionaries/tools.ja.json）
4. その他: 独自に考えた方式があればそれも含める

各方式について以下の観点で評価すること:

• レジストリパターンとの親和性（ページ間独立性の維持）
• 複数エージェント同時開発のしやすさ
• 言語・地域ごとの個別制御（あるページを特定言語のみにする）
• 共通UIラベル（ヘッダー、フッター等）の管理
• ブログなどの長文コンテンツの扱い
• 実装の複雑さ
• Next.js App Routerとの互換性

現在のコードベース調査

以下も調査してください:

• src/app/ 配下の構造（現在のページ構成）
• src/lib/registry/ の構造（レジストリパターンの実装）
• src/content/ の構造（コンテンツデータの管理方法）

成果物

調査結果をメモで報告してください。各方式の比較表と、推奨案の提示をお願いします。