乱数を interface で抽象化してゲームロジックをテスタブルにする

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

乱数を interface で抽象化してゲームロジックをテスタブルにする

概要

ゲーム開発において、「運」の要素は面白さを生む不可欠なスパイスです。クリティカルヒット、レアアイテムのドロップ、ダンジョンの自動生成など、多くの場面で乱数が使われます。

しかし、プログラミングの文脈において、乱数は「不確実性」そのものであり、ユニットテストの天敵です。本記事では、TypeScript を用いて乱数をインターフェースで抽象化し、テスト時に決定論的な（結果が予測可能な）挙動をさせる設計パターンについて解説します。

課題：`Math.random()` がもたらす「テスト不能」という病

もっとも素浦に実装すると、ゲームロジックの中で直接 Math.random() を呼び出すことになります。

// 直接 Math.random() を使う例
export class CombatService {
  calculateDamage(baseDamage: number, critRate: number): number {
    // 運が悪ければテストが落ちる
    if (Math.random() < critRate) {
      return baseDamage * 2;
    }
    return baseDamage;
  }
}

このコードをテストしようとすると、以下の問題に直面します。

非決定的 (Non-deterministic) なテスト: 同じ入力に対して、実行するたびに結果が変わる可能性があります。
境界値のテストが困難: 「クリティカル率 5% のとき、0.049 を引いたらクリティカル、0.051 を引いたら通常攻撃」という境界値の検証が運任せになります。
モックの乱立: vi.spyOn(Math, 'random') などでグローバルなオブジェクトを書き換える手法もありますが、並列テストで干渉したり、クリーンアップを忘れると他のテストに影響を与えたりと、脆いテストになりがちです。

設計：Port / Adapter パターンによる抽象化

この問題を解決するために、Dependency Inversion Principle (依存性逆転の原則) を適用します。

ロジックが「具体的な乱数生成器」に依存するのではなく、抽象的な「乱数提供インターフェース」に依存するように設計を変更します。

1. Port (Interface) の定義

ロジックが必要とする「乱数を得るための窓口」を定義します。

2. Adapter (Implementation) の実装

Production Adapter: 本番環境では Math.random() を使う。
Test Adapter: テスト環境では、事前に定義した値を返したり、シード値に基づいた再現性のある乱数を返す。

この設計にすることで、ロジック側は「誰がどうやって乱数を作っているか」を気にせず、「乱数がもらえること」だけを約束された状態になります。

TypeScript npm workspaces でゲームロジックを UI から完全分離する

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

TypeScript npm workspaces でゲームロジックを UI から完全分離する

概要

モダンなフロントエンド開発、特にゲーム開発において、「ロジック」と「表示（UI）」の分離は永遠の課題です。React や Vue などのフレームワークにロジックが密結合してしまうと、テストが困難になり、将来的に別のプラットフォーム（例えば Web から React Native や CLI ツールへ）に展開する際の大きな障害となります。

本記事では、TypeScript npm workspaces を活用して、ゲームロジックを独立したパッケージ (packages/core) として切り出し、React UI (apps/client) から完全に分離する設計手法を解説します。また、外部 I/O や非決定的な処理（乱数など）を抽象化する Port / Adapter パターンについても触れます。

課題：なぜロジックが UI に染み出すのか？

多くのプロジェクトでは、気づかないうちにロジックが React コンポーネントや Hooks の中に漏れ出していきます。

// 密結合な例
const PlayerStats = () => {
  const [hp, setHp] = useState(100);

  const handleAttack = () => {
    // UI の中で計算ロジックが動いている
    const damage = Math.floor(Math.random() * 10) + 5;
    setHp(prev => Math.max(0, prev - damage));
  };

  return <button onClick={handleAttack}>攻撃を受ける</button>;
};

このような設計には以下の課題があります：

テストの困難さ: Math.random() が直接使われているため、結果が不安定でユニットテストが書きにくい。
再利用性の欠如: この「ダメージ計算ロジック」を、サーバーサイドや別の UI フレームワークで使い回すことができない。
依存の混入: ロジックを動かすために React の実行環境（レンダリングサイクル）が必要になる。

設計：npm workspaces による物理的隔離

ロジックを「物理的に」隔離するために、以下の monorepo 構成を採用します。

Port/Adapter on 怠惰技術ブログ

乱数を interface で抽象化してゲームロジックをテスタブルにする

乱数を interface で抽象化してゲームロジックをテスタブルにする

概要

課題：Math.random() がもたらす「テスト不能」という病

設計：Port / Adapter パターンによる抽象化

1. Port (Interface) の定義

2. Adapter (Implementation) の実装

TypeScript npm workspaces でゲームロジックを UI から完全分離する

TypeScript npm workspaces でゲームロジックを UI から完全分離する

概要

課題：なぜロジックが UI に染み出すのか？

設計：npm workspaces による物理的隔離

課題：`Math.random()` がもたらす「テスト不能」という病