👏

【番外編】バイオハザードは、実はエンジニアリングの教科書だった

に公開
Python
プログラミング
gamedev
architecture
beginners
tech

この記事でわかること（ミニ結論）

  • バイオハザードのゲームメカニクスはエンジニアリングの基本概念と驚くほど一致する
  • アイテムボックス・ゾンビAI・セーブシステムは共有メモリ・ステートマシン・Gitそのもの
  • 過去作から最新作レクイエムへの進化はモノリス→マイクロサービスの移行に似ている
  • 遊びながら学べるエンジニアリング概念が実はゲームの中に隠れている

はじめに：なぜバイオハザードがエンジニアリングなのか

2026年、バイオハザードRequiemが話題だ。プレイしながらふと気づいた。

「これ、現場でやってることと同じじゃないか？」

鍵を集めてドアを開ける。アイテムを管理する。敵の行動パターンを読む。
ゲームの設計思想とエンジニアリングの設計思想は、驚くほど重なっている。

番外編として、現役エンジニア目線でバイオハザードを解剖してみる。

1. アイテムボックス＝共有メモリ／クラウドストレージ

マップ上のどのアイテムボックスにアクセスしても、同じアイテムが入っている。

これはまさにグローバルな共有ストレージの概念だ。

# バイオハザードのアイテムボックスをコードで表現すると...

# ❌ 昔ながらのローカル管理（各ボックスが独立）
box_room_101 = ["ハーブ", "ショットガンの弾"]
box_room_205 = ["ナイフ"]  # 別のボックスには別のアイテム

# ✅ バイオハザードの実際の仕組み（共有参照）
# どのボックスも同じストレージを参照している
item_storage = {
    "items": ["ハーブ", "ショットガンの弾", "ナイフ"]
}

box_room_101 = item_storage  # 同じオブジェクトを参照
box_room_205 = item_storage  # 同じオブジェクトを参照

# room_101で追加したアイテムはroom_205からも見える
box_room_101["items"].append("グリーンハーブ")
print(box_room_205["items"])
# → ["ハーブ", "ショットガンの弾", "ナイフ", "グリーンハーブ"]
# room_205からもちゃんと見える！

現実のシステムで言えばAWS S3・Redis・データベースがこれに相当する。
複数のサーバーから同じストレージにアクセスして、常に最新の状態を共有する。

2. ハーブの調合＝関数の合成（Function Composition）

グリーンハーブ単体では弱い。でも組み合わせると効果が跳ね上がる。

from dataclasses import dataclass

@dataclass
class Herb:
    color: str
    heal_power: int

def mix(*herbs: Herb) -> dict:
    """ハーブを調合する関数"""
    total_power = sum(h.heal_power for h in herbs)
    colors = [h.color for h in herbs]

    # 特定の組み合わせでボーナス効果
    bonus = 1.0
    if "green" in colors and "red" in colors:
        bonus = 2.5  # 完全回復
    elif colors.count("green") == 3:
        bonus = 2.0  # 強化回復

    return {
        "heal": int(total_power * bonus),
        "components": colors
    }

green = Herb("green", 30)
red   = Herb("red",   20)
blue  = Herb("blue",  10)  # 毒消し効果

# 単体
print(mix(green))
# → {"heal": 30, "components": ["green"]}

# グリーン＋レッド＝完全回復
print(mix(green, red))
# → {"heal": 125, "components": ["green", "red"]}

# これはまさに関数合成
# f(x) = green, g(x) = red → h(x) = f(g(x)) で効果倍増

パイプライン処理・ミドルウェアの連鎖・関数型プログラミングの考え方そのものだ。
単体では小さな機能が、組み合わさることで大きな力を発揮する。

3. ゾンビのAI＝ステートマシン（有限オートマトン）

ゾンビは「ただ歩いている」ように見えて、実は状態遷移で動いている。

from enum import Enum, auto

class ZombieState(Enum):
    PATROL   = auto()  # 徘徊中
    ALERT    = auto()  # 音・気配を検知
    CHASE    = auto()  # 追跡中
    ATTACK   = auto()  # 攻撃中
    STUNNED  = auto()  # ひるみ中

class Zombie:
    def __init__(self):
        self.state = ZombieState.PATROL
        self.health = 100

    def update(self, player_distance: float, heard_noise: bool):
        """毎フレーム状態を更新する"""

        # 状態遷移のルール
        match self.state:
            case ZombieState.PATROL:
                if player_distance < 5.0 or heard_noise:
                    self.state = ZombieState.ALERT
                    print("🧟 ウッ...（気配を感じた）")

            case ZombieState.ALERT:
                if player_distance < 3.0:
                    self.state = ZombieState.CHASE
                    print("🧟‍♂️ グァァァ！（発見）")
                elif player_distance > 8.0:
                    self.state = ZombieState.PATROL

            case ZombieState.CHASE:
                if player_distance < 1.5:
                    self.state = ZombieState.ATTACK
                elif player_distance > 10.0:
                    self.state = ZombieState.PATROL
                    print("🧟 （見失った...）")

            case ZombieState.ATTACK:
                if player_distance > 2.0:
                    self.state = ZombieState.CHASE

            case ZombieState.STUNNED:
                # スタン解除後は追跡に戻る
                self.state = ZombieState.CHASE

# 実際の動き
zombie = Zombie()
zombie.update(player_distance=4.0, heard_noise=True)
# → 🧟 ウッ...（気配を感じた）
zombie.update(player_distance=2.5, heard_noise=False)
# → 🧟‍♂️ グァァァ！（発見）

これはUIのボタン状態・通信プロトコルの状態管理・ワークフローエンジンなど、
現実のシステム設計でも至る所で使われている設計パターンだ。

4. 鍵と扉＝認証・アクセス制御（RBAC）

特定の鍵がなければドアは開かない。持っていれば開く。それだけ。

from typing import Optional

# アクセス制御の定義
DOOR_PERMISSIONS = {
    "laboratory_b2": ["key_card_lv3", "master_key"],
    "armory":        ["key_card_lv2", "key_card_lv3", "master_key"],
    "safe_room":     ["key_card_lv1", "key_card_lv2",
                      "key_card_lv3", "master_key"],
}

class Player:
    def __init__(self, name: str):
        self.name = name
        self.inventory: list[str] = []

    def try_open_door(self, door_name: str) -> bool:
        required_keys = DOOR_PERMISSIONS.get(door_name, [])

        # 所持アイテムに必要な鍵があるか確認
        for key in required_keys:
            if key in self.inventory:
                print(f"✅ {door_name} を開けた（{key} を使用）")
                return True

        print(f"🔒 {door_name} は開かない...鍵が必要だ")
        return False

# 実際の動作
player = Player("Chris")
player.inventory = ["herb", "shotgun_ammo", "key_card_lv2"]

player.try_open_door("safe_room")
# → ✅ safe_room を開けた（key_card_lv2 を使用）

player.try_open_door("laboratory_b2")
# → 🔒 laboratory_b2 は開かない...鍵が必要だ

これはそのままJWT認証・OAuth2のスコープ・AWS IAMのポリシーと同じ設計思想だ。
「正しい権限を持つ者だけがリソースにアクセスできる」という原則は変わらない。

5. セーブ＆ロード＝Gitのコミット＆ロールバック

タイプライターでセーブする。失敗したらロードして戻る。

# バイオハザードのセーブ＝Gitのコミット

# セーブ（現在の状態を記録）
git add .
git commit -m "ボス前: 回復アイテム3個、弾薬100発の状態"

# ゲームオーバー（何か壊滅的なことが起きた）
# ...💀

# ロード（セーブ地点に戻る）
git reset --hard HEAD~1
# または特定のコミットに戻る
git checkout abc1234

# 実際の開発でも同じ
git commit -m "feat: 新機能追加（テスト通過確認済み）"
# → 新機能が壊滅的にバグってた
git reset --hard HEAD~1
# → セーブ地点に戻れた

そして今回の記事でも紹介したEntire CLIのCheckpointsは、
「なぜそのセーブをしたか」という思考過程まで記録する。
バイオハザードで言えば、セーブ時に「ここでセーブした理由：ボスの第2形態が怖いから」
というメモが自動で残るようなイメージだ。

6. 過去作 vs レクイエム：モノリスからマイクロサービスへ

ここからはエンジニアっぽい視点で、シリーズの進化を語る。

バイオハザード1〜3（1996〜1999年）＝モノリスアーキテクチャ

┌─────────────────────────────────┐
│         バイオハザード1          │
│                                 │
│  ・固定カメラ（単一ビューシステム） │
│  ・限られたマップ（密結合な空間）  │
│  ・決められたルート（線形フロー）  │
│  ・インクリボン必須（集中型状態管理）│
└─────────────────────────────────┘

全てが密に結合したひとつのシステム。変更しにくいが安定していて予測可能。
初代バイオの洋館はまさに「巨大なモノリシックアプリケーション」だ。

バイオハザード4〜6（2005〜2012年）＝サービス指向アーキテクチャ（SOA）

┌──────────┐  ┌──────────┐  ┌──────────┐
│ アクション │  │  カメラ   │  │   AI     │
│  システム  │  │  システム  │  │  エンジン  │
└──────────┘  └──────────┘  └──────────┘
       ↕              ↕             ↕
┌─────────────────────────────────────┐
│         共通ゲームエンジン（バス）     │
└─────────────────────────────────────┘

TPS視点の導入・アクション性の強化など、各システムが疎結合になり始めた。
ただし規模が大きくなりすぎて、バイオ6は「何でもあり」な複雑なシステムに。

バイオハザードRequiem（2026年）＝マイクロサービス＋AIネイティブ

┌───────────┐  ┌───────────┐  ┌───────────┐
│ 物理演算   │  │ AI行動     │  │ 環境破壊  │
│マイクロSVC  │  │マイクロSVC  │  │マイクロSVC │
└───────────┘  └───────────┘  └───────────┘
       ↕              ↕              ↕
┌─────────────────────────────────────────┐
│          イベントバス（非同期通信）        │
└─────────────────────────────────────────┘
       ↕              ↕              ↕
┌───────────┐  ┌───────────┐  ┌───────────┐
│ サウンド   │  │ レンダリング│  │ ネットワーク│
│マイクロSVC  │  │マイクロSVC  │  │マイクロSVC │
└───────────┘  └───────────┘  └───────────┘

各システムが独立して動作・更新可能になり、AIが敵の行動を動的に生成する。
プレイヤーの行動に応じてリアルタイムで難易度・敵配置が変化する。
これはまさにクラウドネイティブ・AIネイティブなアーキテクチャだ。

観点 旧作（1〜3） 中期（4〜6） レクイエム
アーキテクチャ モノリス SOA マイクロサービス
敵AI ルールベース ビヘイビアツリー LLMベース動的生成
セーブ インクリボン（手動・有限） チェックポイント（自動） クラウドセーブ（常時同期）
マップ 固定・線形 半オープン フルオープンワールド
デプロイ パッケージ一括 パッチ配信 ライブアップデート（ホットフィックス）

まとめ：ゲームはエンジニアリングの縮図だった

バイオハザードを通じて見えてくるエンジニアリングの概念をまとめると：

ゲームの要素 エンジニアリングの概念
アイテムボックス 共有メモリ・クラウドストレージ
ハーブの調合 関数合成・パイプライン
ゾンビのAI ステートマシン
鍵と扉 認証・アクセス制御（RBAC）
セーブ＆ロード Gitコミット＆ロールバック
シリーズの進化 モノリス→マイクロサービス

ゲームをプレイしながら、実は設計パターンを学んでいた。

エンジニアリングの概念は難しそうに見えて、実は身近なところに隠れている。
次にバイオハザードをプレイするとき、少し違う目線で楽しめるかもしれない。

この記事は番外編です。現役半導体エンジニアがゲームをエンジニア視点で解剖するシリーズです。

情報ソース：

  • バイオハザードシリーズ（カプコン）
  • 現場エンジニアの経験と妄想

Discussion