cycle-65 補完調査(1/3): サーバーサイドAPI活用で広がるカテゴリの可能性

背景

既存の調査 docs/research/market-research-high-traffic-categories.md は「サーバーサイドAPI呼び出し不可」という誤った前提で書かれている。実際には独自サーバーサイドAPI（Next.js API Routes）は利用可能であり、これにより実現可能なカテゴリや機能が大幅に広がる。既存調査を上書きせず、補完レポートとして新たに調査を行う。

正しい技術的制約

外部API依存の禁止: リクエストごとにOpenAI・Google等の外部APIを呼び出してコンテンツを生成することは不可
独自サーバーサイドAPIは利用可能: Next.js API Routes等で自前のロジックを実装することは問題なし（計算処理、データ変換、ファイルベースのデータ検索等）
サーバーサイドDB不使用: 事故防止のため（ただしJSONファイルやビルド時生成の静的データは利用可能）
ローカルストレージは使用可能: クライアント側でのデータ保存OK
インタラクティブコンテンツは利用可能: クライアントサイドJSによるインタラクション全般OK
技術スタック: Next.js + TypeScript + Vercel（SSG/ISR対応）
ビルド時AI生成: ビルド時にAIでコンテンツを生成し静的ページとしてデプロイ可能

やるべきこと

既存調査（docs/research/market-research-high-traffic-categories.md）をまず読み、そこで「技術的に困難」「制約のため不可」とされていた項目を特定した上で、正しい制約のもとで以下を調査する。

サーバーサイドAPIにより新たに実現可能になるカテゴリ・機能: 既存調査で制約のため除外・低評価されたものを再評価
動的計算・変換系ツールの可能性: サーバーサイドで計算処理を行うツール系サイトの高トラフィック事例（単位変換、テキスト処理、画像変換、フォーマッター等）
API Routesを活用した差別化: 静的サイトにはない動的機能で差別化している成功サイトの事例
既存調査の各カテゴリ再評価: 既存調査のカテゴリごとに、サーバーサイドAPIが使えることで実現可能性やスコアがどう変わるかを明示
既存調査で不正確だったデータの修正情報: レビューで指摘された以下のデータ不正確を調査し、正しい情報を記載
- RapidTablesの出典URL（boringcashcash.com → 正しいURL）
- Wordleのデイリーユーザー数の正確な出典
- ゼロクリック検索の正確なスコープ（全検索 vs ニュース関連限定）
- 各カテゴリの代表的な検索クエリの月間検索ボリューム概算

重要な注意事項

既存調査を上書きしないこと。補完レポートとして別ファイルに出力する
すべての数値に出典URLを明記すること
ユーザーにとっての価値を中心に分析すること
constitution.mdのゴール: 「ユーザーに提供する価値の最大化とPVの獲得」

出力先

docs/research/market-research-high-traffic-categories-supplement.md（新規作成）