React on 怠惰技術ブログ

React で作る堅牢なゲームセーブシステム：localStorage と Reducer を疎結合に保つ設計

Sat, 28 Mar 2026 15:00:00 +0900

React で作る堅牢なゲームセーブシステム：localStorage と Reducer を疎結合に保つ設計

ゲーム開発において、プレイヤーの進行状況を保存する「セーブ / ロード」は最も重要な機能の一つです。Web ブラウザで動作する React アプリケーションの場合、最も手軽な保存先は localStorage です。

しかし、単純に localStorage.setItem をコードのあちこちに散りばめてしまうと、テスタビリティが低下し、データ構造の変更（スキーマ変更）に弱いシステムになってしまいます。

本記事では、架空の RPG 『React Odyssey』を例に、SavePort インターフェースと Reducer の初期化関数を組み合わせた、クリーンで堅牢なセーブ / ロードの実装方法を解説します。

1. 概要：なぜ「直接 localStorage」を避けるのか

React の useReducer を使ったゲーム開発では、ゲームの状態（State）は一つの大きなオブジェクトとして管理されます。これを JSON.stringify して localStorage に保存するのは簡単です。

しかし、以下の理由から、ロジックの中に直接 localStorage を書くべきではありません。

副作用の分離: Reducer は純粋関数であるべきです。セーブ処理（副作用）を Reducer の中に入れることはできません。
環境非依存: 将来的に保存先を IndexedDB やクラウド（Firebase 等）に変更したくなったとき、コードを大幅に書き換える必要が出てきます。
テストのしやすさ: localStorage が存在しない Node.js 環境（Vitest 等）でロジックのテストを行う際、モック化が容易である必要があります。

これらを解決するために、Dependency Inversion Principle（依存性逆転の原則） に基づいた設計を採用します。

2. SavePort 設計：抽象化の定義

まずは、ゲームエンジン側が必要とする「セーブ機能」のインターフェースを定義します。これを SavePort と呼びます。

// domain/save/save-port.ts

/** 
 * 保存されるデータの構造（スキーマ）
 * ゲームの現在の状態に加え、メタ情報を付与する
 */
export interface SaveData {
  version: number;        // セーブデータのバージョン
  timestamp: string;      // 保存日時
  state: GameState;       // 実際のゲーム状態
}

/**
 * セーブ/ロードに関する抽象インターフェース
 */
export interface SavePort {
  /** データを保存する */
  save(data: SaveData): Promise<void>;

  /** データを読み込む。存在しない場合は null を返す */
  load(): Promise<SaveData | null>;

  /** セーブデータが存在するか確認する */
  exists(): Promise<boolean>;

  /** セーブデータを削除する */
  clear(): Promise<void>;
}

なぜインターフェースにするのか？ ゲームのメインロジック（UseCase）は、この SavePort を通じて読み書きを行います。この時点では「どうやって保存するか」は知らなくてよく、「保存できる」という事実だけに依存させます。

React + Canvas 2D API で作るターン制ローグライク：論理と描画を切り離す設計

Sat, 28 Mar 2026 13:00:00 +0900

React + Canvas 2D API で作るターン制ローグライク：論理と描画を切り離す設計

React でゲームを作る際、多くの開発者が最初に直面するのが「DOM で描画するか、Canvas で描画するか」という選択です。特に数千枚のタイルや多数のユニットが登場するローグライクゲームでは、DOM 要素の管理はすぐにパフォーマンスの限界に達します。

本稿では、React の強力な状態管理（useReducer）と、Canvas 2D API の命令的な描画を組み合わせ、滑らかなアニメーションを実現しつつ堅牢なゲームロジックを維持する設計手法について解説します。

1. 概要：なぜ React と Canvas を組み合わせるのか

React は「宣言的」な UI 構築に長けていますが、毎秒 60 回の頻度で数千の DOM 要素を更新するような動的な描画には向いていません。一方で、Canvas は「命令的」であり、ピクセル単位での高速な描画が可能ですが、状態と描画の同期を自分で行う必要があります。

この二つの「いいとこ取り」をするのが、「ロジックは React（useReducer）で、描画は Canvas で」 という役割分担です。

本記事で構築するアーキテクチャ

Core Logic (useReducer): ゲームの「真実の状態（State of Truth）」を管理。ターン単位で離散的に変化する座標などを扱う。
Render Loop (requestAnimationFrame): Canvas 上で毎フレーム実行される描画処理。
Interpolation (補完): 離散的な論理座標を、滑らかな描画座標へと変換するローカル状態管理。

2. 設計判断：論理座標と描画座標の分離

ローグライクゲームは基本的に「ターン制」です。プレイヤーが右に移動したとき、内部データ（Core State）では x: 10 から x: 11 へと一瞬で書き換わります。しかし、これをそのまま描画すると、キャラクターがワープしたように見えてしまいます。

滑らかな移動（アニメーション）を実現するためには、以下の二種類の状態を明確に分ける必要があります。

なぜ分離が必要か

種類	管理場所	特徴	役割
論理座標 (Logical Position)	`useReducer` (Global)	整数（タイル単位）。	当たり判定、AI、クエスト進行など。
描画座標 (Visual Position)	Canvas 内の Actor クラス (Local)	小数点を含むピクセル単位。	滑らかな移動、揺れ、エフェクト。

判断理由： Core State にアニメーションの「途中経過（x: 10.2 など）」を持たせてしまうと、ゲームロジックが描画の都合に汚染されます。例えば、「まだ移動アニメーション中だから攻撃はできない」といった判定をロジック層で書く必要が出てき、コードが複雑化します。ロジック層は常に「今は（論理的に）どこにいるか」だけを知っていれば良いのです。

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリその5

Thu, 05 Mar 2026 01:30:00 +0900

はじめに

Part4 でカスタム例外クラスと残りのエンドポイントを実装し、APIが完成した。

Part5では src/app/page.tsx に簡易UIを実装する。バックエンドのロジックやテストには一切触れない。フロントエンドからAPIを叩いて動くものを作るだけだ。

実装方針

page.tsx をClient Componentにする。

Server Componentでfetchする方法もあるが、ボタン操作のたびにstateを更新して再描画する必要がある。今回のUIは「ボタンを押す → APIを叩く → 一覧を再取得して画面を更新する」という流れが中心なので、 useState + useEffect で管理するClient Componentのほうがシンプルだ。

"use client";

ファイル先頭にこの1行を追加する。

実装するUI

本の追加フォーム（id / title / isbn）
本棚（Unread / Reading / Completed のグループ表示）
各本へのアクションボタン
- Unread → 「読み始める」ボタン
- Reading → 評価入力（1〜5）＋「読了にする」ボタン
- 全ステータス → 削除ボタン

型定義

APIレスポンスの型を定義する。

type BookStatus = "Unread" | "Reading" | "Completed";

type Book = {
  id: string;
  title: string;
  isbn: string;
  status: BookStatus;
  rating: number | null;
};

バックエンドの ReadingStatus は as const で定義した文字列リテラルなので、そのまま使える。

データ取得

async function fetchBooks() {
  try {
    const res = await fetch("/api/books");
    if (!res.ok) throw new Error("取得失敗");
    const data: Book[] = await res.json();
    setBooks(data);
  } catch (e) {
    setError(e instanceof Error ? e.message : "不明なエラー");
  } finally {
    setLoading(false);
  }
}

useEffect(() => {
  fetchBooks();
}, []);

fetchBooks は追加・ステータス変更・削除の後にも呼ぶ。サーバーの状態を正として再取得するシンプルな方針だ。楽観的更新（Optimistic Update）は今回やらない。

歴史地図アプリを雑にk3sへデプロイした

Wed, 25 Feb 2026 22:00:00 +0900

React+Vite+MapLibreで作った歴史地図アプリをk3sにデプロイした話。hostPathマウント、Viteの罠、ngrokとTailscaleを駆使したファイル転送など泥臭い記録。

React on 怠惰技術ブログ

React で作る堅牢なゲームセーブシステム：localStorage と Reducer を疎結合に保つ設計

React で作る堅牢なゲームセーブシステム：localStorage と Reducer を疎結合に保つ設計

1. 概要：なぜ「直接 localStorage」を避けるのか

2. SavePort 設計：抽象化の定義

React + Canvas 2D API で作るターン制ローグライク：論理と描画を切り離す設計

React + Canvas 2D API で作るターン制ローグライク：論理と描画を切り離す設計

1. 概要：なぜ React と Canvas を組み合わせるのか

本記事で構築するアーキテクチャ

2. 設計判断：論理座標と描画座標の分離

なぜ分離が必要か

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリ その5

はじめに

実装方針

実装するUI

型定義

データ取得

歴史地図アプリを雑にk3sへデプロイした

テスト前提で設計したWebアプリのハンズオン - 読書管理アプリその5