ADR-002: フロントエンド技術スタック選定¶

ステータス¶

採用

背景¶

ぷよぷよゲームの開発において、フロントエンド技術スタックを選定する必要がある。ゲームという特性上、高いパフォーマンス、リアルタイム性、複雑な状態管理が求められる。また、TypeScript対応、保守性、開発効率も重要な選定基準である。

検討事項¶

選定基準¶

パフォーマンス要件: 60FPS以上での動作
TypeScript対応: 型安全性によるバグ削減
エコシステム: 豊富なライブラリとツール
学習コスト: チームの習熟度と今後の学習容易性
保守性: 長期間の開発・運用への対応
コミュニティサポート: 活発な開発・サポート体制

フレームワーク候補比較¶

React 18+¶

メリット:
最大のエコシステムとコミュニティ
Concurrent Featuresによる高パフォーマンス
TypeScript完全対応
豊富なゲーム開発事例
Hooks APIによる状態管理
デメリット:
バンドルサイズやや大きめ
学習コストは中程度

Vue.js 3¶

メリット:
学習コストが低い
Composition API
TypeScript対応改善
デメリット:
ゲーム開発事例が少ない
エコシステムがReactより小規模
企業採用実績でReactに劣る

Svelte/SvelteKit¶

メリット:
軽量なバンドル
優れたパフォーマンス
学習コストが低い
デメリット:
エコシステムが未成熟
ゲーム開発ライブラリが少ない
企業採用実績が少ない

Angular 16+¶

メリット:
TypeScriptファースト
豊富な機能セット
デメリット:
学習コストが高い
ゲーム開発には機能過多
バンドルサイズが大きい

状態管理ライブラリ候補¶

Zustand¶

メリット:
軽量（2KB）
TypeScriptファースト設計
ボイラープレートなし
React 18対応
デメリット:
新しいライブラリのため事例少

Redux Toolkit¶

メリット:
事実上の標準
豊富なdevtools
大規模アプリ対応
デメリット:
学習コストが高い
ボイラープレートが多い
小規模プロジェクトには重い

Context API + useReducer¶

メリット:
React標準機能
追加依存なし
デメリット:
複雑な状態管理に不向き
パフォーマンス課題

決定¶

コアフレームワーク¶

React 18+ + TypeScript 5.0+を採用する

状態管理¶

Zustandを採用する

ビルドツール¶

Viteを採用する

テストフレームワーク¶

Jest + React Testing Libraryを採用する

理由¶

React 18+選定理由¶

パフォーマンス:
Concurrent Featuresによる効率的なレンダリング
自動バッチング機能
Suspenseによる非同期処理最適化
エコシステム:
ゲーム開発に適したライブラリ（Framer Motion等）
豊富なCanvas/WebGL統合事例
充実したコミュニティ
TypeScript統合:
完全な型サポート
JSXでの型推論
開発ツールサポート
保守性:
長期サポート保証
後方互換性への配慮
段階的アップグレード可能

Zustand選定理由¶

シンプルさ:

const useGameStore = create<GameState>((set) => ({
  game: initialGame,
  updateGame: (game) => set({ game }),
}))

TypeScript親和性:
型推論が効く
インターフェース定義が簡潔
ランタイム型チェック不要
パフォーマンス:
必要な部分のみ再レンダリング
セレクター関数による最適化
軽量なランタイム

Vite選定理由¶

開発体験:
高速なHMR（Hot Module Replacement）
ESMネイティブ
TypeScript内蔵サポート
ビルドパフォーマンス:
Rollupベースの最適化
効率的な依存関係解決
Tree Shaking

設定の簡潔さ:

export default defineConfig({
  plugins: [react()],
  // 最小限の設定
})

技術スタック構成¶

┌─────────────────────────────────────┐
│           Development               │
├─────────────────────────────────────┤
│ TypeScript 5.0+ │ ESLint + Prettier │
├─────────────────────────────────────┤
│           Frontend                  │
├─────────────────────────────────────┤
│ React 18+       │ Zustand           │
├─────────────────────────────────────┤
│           Styling                   │
├─────────────────────────────────────┤
│ Tailwind CSS    │ Framer Motion     │
├─────────────────────────────────────┤
│           Build & Test              │
├─────────────────────────────────────┤
│ Vite            │ Jest + RTL        │
└─────────────────────────────────────┘

結果¶

期待される効果¶

開発速度向上:
TypeScriptによる早期エラー検出
Viteによる高速リロード
Zustandによる簡潔な状態管理
品質向上:
型安全性による実行時エラー削減
React DevToolsによるデバッグ効率化
豊富なテスティングツール
保守性:
標準的な技術スタックによる引き継ぎ容易性
長期サポートによる安定性
活発なコミュニティサポート

パフォーマンス目標¶

初期ロード時間: 3秒以下
フレームレート: 60FPS以上
バンドルサイズ: 500KB以下（gzip圧縮後）
メモリ使用量: 100MB以下

移行・アップグレード戦略¶

段階的導入:
コアライブラリから順次導入
既存コードとの互換性確保
機能単位での移行
定期アップデート:
月次でのマイナーアップデート
四半期でのメジャーアップデート検討
セキュリティアップデートの即時適用
代替技術への備え:
Next.js、Nuxt.jsへの移行可能性を維持
Server Componentsの将来的検討
WebAssemblyとの統合可能性

注意点¶

学習コスト:
React Concurrent Featuresの理解が必要
Zustandの状態管理パターン習得
バンドルサイズ管理:
Tree Shakingの効果的活用
Code Splittingによる最適化
技術負債の蓄積回避:
定期的なライブラリアップデート
非推奨APIの早期対応