OG Worker リファクタリング計画

現状

src/index.ts に全ての処理が集約されており、ファイルが肥大化している（約565行）。 機能追加・修正時にファイル全体を把握する必要があり、メンテナンス性が低い。

目標構造

apps/workers/og/src/
├── index.ts                 # エントリーポイント（ルーティングのみ）
├── types.ts                 # 共通型定義
├── handlers/
│   ├── blog.ts              # ブログOGP
│   ├── japanese-quiz.ts     # 日本語クイズOGP（シェアページ含む）
│   ├── coding-standards.ts  # コーディング規約OGP
│   ├── jleague.ts           # JリーグOGP
│   ├── general.ts           # 汎用ページOGP
│   └── design-principles.ts # デザイン原則OGP ✅ 完了
└── utils/
    ├── signature.ts         # 署名生成・検証
    ├── sanitize.ts          # テキストサニタイズ
    └── font.ts              # フォント読み込み・キャッシュ

完了済み

• handlers/design-principles.ts - デザイン原則OGP（2026-01-10）
• types.ts - Envインターフェース（2026-01-10）
• utils/signature.ts - 署名生成・検証（2026-01-10）
• utils/sanitize.ts - テキストサニタイズ（2026-01-10）
• utils/font.ts - フォントキャッシュ（2026-01-10）
• handlers/blog.ts - ブログOGP（2026-01-10）
• handlers/japanese-quiz.ts - 日本語クイズOGP（2026-01-10）
• handlers/coding-standards.ts - コーディング規約OGP（2026-01-10）
• handlers/jleague.ts - JリーグOGP（2026-01-10）
• handlers/general.ts - 汎用ページOGP（2026-01-10）
• index.ts - ルーティングのみに簡素化（48行）（2026-01-10）

未着手

なし - 全フェーズ完了

実装時の注意点

1. 署名検証の整合性
   • Worker側とNuxt側 (usePageOgSignature.ts) で同じロジックを使用
   • テスト (apps/web/tests/og-signature.test.ts) で整合性を検証
2. フォントキャッシュ
   • フォントデータのPromiseキャッシュは共有が必要
   • シングルトンパターンで実装
3. 型定義
   • Env インターフェースは複数ファイルで使用
   • types.ts で一元管理

優先度

1. 高: utils/signature.ts - セキュリティ関連で重要
2. 中: handlers/blog.ts - 最も使用頻度が高い
3. 低: その他のハンドラー - 必要に応じて順次対応