こんにちは。

今回は、番外編！
Webで見かけた、Kiro でゲームボーイソフトを開発するといったものにインスパイアを受けて、「ファミコンで動くシューティングゲーム」を目指した記録です。

この記事は、Kiro（AI搭載IDE）とAnthropic Claude Opus 4.6を用いて開発した記録です。実際にKiroと会話しながら実装し、プレイテストでバグを見つけてはその場で直す、という試行錯誤の過程をそのままお伝えしています。

なお、開発は現在進行中です。HTML5版が遊べる状態になったので、ここまでの記録を残しておきます。

開発環境

Kiro + Claude Opus 4.6

KiroはAWSが提供するAI搭載IDEです。バックエンドのLLMとしてAnthropic Claude Opus 4.6を使用しています。

今回の開発で特に活きたのはSpec駆動開発の機能です。要件定義→設計→タスク分解→実装を一貫してAIがサポートしてくれます。ゲーム開発のように「守るべきルール」が大量にあるプロジェクトでは、要件定義の段階でルールを明文化しておくとAIが逸脱しにくくなります。

テスト環境

ツール	用途
Vitest	テストランナー
fast-check	プロパティベーステスト

最終的に820件のテストが全パスする状態で開発を進めました。

なぜファミコンなのか

前述の通り、ゲームボーイを開発しているという記載を見かけたから、ことの発端。
作るなら、やっぱりファミコンだよねということで選びました。

しかし、ファミコン（NES）のゲーム開発には独特の制約があります。

解像度: 256×240ピクセル
同時表示色: 最大25色（背景13色 + スプライト12色）
スプライト: 画面上に最大64個
1スキャンラインあたり: 8スプライトまで

この制約の中でグラディウスやツインビーが動いていたと思うと、当時の開発者の技術力に頭が下がります。

「この制約を守ったゲームを、AIに作らせたらどうなるか？」

ただし、6502アセンブリをいきなり書かせるのは無理があります。
そこで2段階アプローチを取ることにしました。

HTML5 + JavaScriptでプロトタイプを作る（ファミコン制約に準拠した設計で）
動作確認後、NES ROMに移植する

つまり、まずはそれっぽいものを開発して、動かすということです。
Phase 1が完了したので、ここまでの記録です。

全体のアーキテクチャ

┌─────────────────────────────────────────────────────────┐
│              Phase 1: HTML5プロトタイプ（完了）            │
├─────────────────────────────────────────────────────────┤
│  HTML5 Canvas (256×240)                                 │
│  JavaScript (ES6 Modules)                               │
│  ファミコンPPU制約に準拠した設計                             │
│  (パレット制限、スプライト制限、8×16モード)                   │
└─────────────────────────────────────────────────────────┘
         ↓ 移植予定
┌─────────────────────────────────────────────────────────┐
│              Phase 2: NES ROM（これから）                 │
├─────────────────────────────────────────────────────────┤
│  6502 Assembly / cc65                                   │
│  CHR-ROM (スプライトデータ)                                │
│  .nes ROMファイル → エミュレータ or 実機                    │
└─────────────────────────────────────────────────────────┘

HTML5版の段階でファミコンの制約を守っておけば、移植時の手戻りを最小化できる...はずです。

ファミコン制約をSpecに落とし込む

Kiroに「ファミコン風の横スクロールシューティングを作りたい」と伝えると、Specの作成が始まります。

ここで重要なのが、ファミコンPPUの制約を要件として明示的に書かせること。

パレット制約

ファミコンPPUは64色のマスターパレットを持ちますが、画面上に同時表示できるのは最大25色。さらに各パレットは3色+透明（または共通背景色）の4色構成です。

これをコードに落とすとこうなります:

// $0Dは使用禁止（一部TVでグリッチを起こす）
export const MASTER_PALETTE = [
    [84, 84, 84],      // $00
    [0, 30, 116],       // $01
    // ... 64色分
    null,               // $0D: 使用禁止
    // ...
];

// スプライトパレット4種（各3色＋透明）
export const SPRITE_PALETTES = [
    [null, 0x30, 0x0F, 0x16],  // SP0: プレイヤー（白、黒、赤）
    [null, 0x2C, 0x0F, 0x11],  // SP1: 分身（水色、黒、青）
    [null, 0x27, 0x17, 0x07],  // SP2: 敵（オレンジ、茶、暗赤）
    [null, 0x12, 0x16, 0x30],  // SP3: ボス（青、赤、白）
];

$0Dをnullにしているのは、nesdev.orgに記載されている実機の既知問題への対応です。HTML5版では見た目に影響しませんが、NES移植時にこのまま使えるようにしておきます。

スプライトバジェット

ファミコンは画面上に最大64スプライトしか表示できません。8×16モードでは1キャラクター（16×16px）に4スプライトを消費します。

設計書でバジェットを定義し、EnemyManagerがランタイムで管理します:

通常ステージ時:
  プレイヤー: 4スプライト
  分身(Option_Clone): 最大8（4×2体）
  弾丸: 最大20
  敵: 最大24（16×16敵6体分）
  パワーアップ: 最大2
  シールド: 4
  合計: 最大62（上限64以内）

コード上では:

const MAX_ENEMY_SPRITES = 24;

spawnEnemy(typeName, isColorVariant, speedMultiplier) {
    const spriteCost = def.size <= 8 ? 1 : 4;
    if (this._currentSpriteCount + spriteCost > MAX_ENEMY_SPRITES) {
        return null;  // バジェット超過 → 生成しない
    }
    // ...
}

上限を超える敵は生成しない。シンプルですが、これでファミコンの制約を守れます。

プロパティベーステストで仕様を形式化する

Kiroが生成したテストの中で特に面白かったのが、fast-checkを使ったプロパティベーステスト（PBT）です。

通常のユニットテストが「この入力に対してこの出力」を検証するのに対し、PBTは「任意の入力に対してこの性質が常に成り立つ」を検証します。

例えば衝突判定:

it('任意の2つの矩形に対して、checkAABBの結果が幾何学的な重なり判定と一致する', () => {
    fc.assert(
        fc.property(arbRect, arbRect, (rectA, rectB) => {
            const actual = CollisionDetector.checkAABB(rectA, rectB);
            const expected = geometricOverlap(rectA, rectB);  // リファレンス実装
            expect(actual).toBe(expected);
        })
    );
});

ランダムな矩形を100回生成して、実装がリファレンス実装と常に一致することを検証します。手書きでは思いつかないエッジケース（幅0の矩形、座標が負の矩形など）も自動的にカバーされます。

パレットの検証もPBTで:

it('isValidPaletteIndex が有効範囲（0〜63、$0D除外）の整数に対してのみ true を返す', () => {
    fc.assert(
        fc.property(fc.integer({ min: -10, max: 73 }), (index) => {
            const result = isValidPaletteIndex(index);
            const expected = index >= 0 && index <= 63 && index !== 0x0D;
            expect(result).toBe(expected);
        })
    );
});

最終的に34個のプロパティを定義しました。テストが仕様書を兼ねる、という感覚です。

プレイテストで見つかったバグたち

テストが全パスしていても、実際にプレイすると問題は見つかります。以下はKiroとの会話で解決したバグの一部です。

ボスが倒せない

症状: ボスのHPゲージが0になっても撃破されない。

原因: CollisionDetectorがboss.hp -= damageと直接HPを減算していて、Boss.takeDamage()を経由していなかった。HPが0になってもstateがDEFEATEDに遷移しない。

修正: boss.takeDamage(damage)を呼ぶように変更。

CollisionDetectorは汎用的な衝突判定クラスなので、状態遷移のロジックを持つべきではありませんでした。

弾がKiroの頭から出る

症状: 横スクロールシューティングなのに、レーザービームが上方向に飛ぶ。

原因: LaserBeamのコンストラクタにsuper(x, y, 0, -4, 'player', 2)（上方向）がハードコードされていた。横シュー化の際に漏れた箇所。

修正: super(x, y, 4, 0, 'player', 2)（右方向）に変更。

もともと縦シューとして実装されていたものを横シューに方針転換した際の取りこぼしでした。

ボスに安全地帯がある

症状: ボスが上下にサイン波で動くだけなので、画面端に張り付けば被弾しない。

修正: プレイヤーY座標への追従 + 2周波数のサイン波重ね合わせ + X方向の揺れを追加。

// プレイヤーに向かってゆっくり追従（安全地帯を潰す）
const diffY = playerY - (this.y + this.height / 2);
if (Math.abs(diffY) > 4) {
    this.y += Math.sign(diffY) * trackingSpeed;
}
// 2つの周波数を重ねて予測しにくくする
this.y += Math.sin(this._elapsedTime * 2.0) * moveSpeed * 0.5;
this.y += Math.sin(this._elapsedTime * 3.7) * moveSpeed * 0.3;

これらはすべて「Kiroに症状を伝える → 原因特定 → 修正」のサイクルで解決しています。テストが820件あるおかげで、修正が他の箇所を壊していないことをすぐ確認できます。

ゲームの概要

タイトルは「Kiro のだいぼうけん！」。お化けのキャラクター「Kiro」を操作する横スクロールシューティングです。
今の所、キャラクターは、Kiro以外は代償様々な箱型のオブジェクトです。そのうち、いつか、きっとドット絵を描いて取り込みます。

全6ステージ（お家 → オフィス → データセンター → お空 → 宇宙 → 人工衛星）
各ステージにテーマ別の敵とボス
7種類のパワーアップ
レーザービームはプログラミング言語の関数テキストが弾として飛ぶ（console.log("Kiro!") とか fmt.Println("Boo!") とか）
エンディング後に2周目（難易度上昇）

ステージ6のボス「AI大型コンピュータ」は、発狂モード（HP30%以下）になるとcodeRain弾24発を間隔10フレームで撃ってきます。かなり厳しい。

プレイURL:
http://kiro-ghost-shooter-game.s3-website-ap-northeast-1.amazonaws.com
※期間限定なので、気がついたら消えてるかも。

操作: 矢印キー/WASD で移動、スペースで発射。

今後の予定: NES ROM移植

Phase 2として、このHTML5版をNES ROMに移植する予定です。

移植に向けて、HTML5版の段階で以下の準備が整っています:

項目	ファミコン制約	HTML5版での対応
解像度	256×240	Canvas解像度を256×240に固定
パレット	4色×8パレット	`Palette.js`で厳密に管理
スプライト数	最大64個	`EnemyManager`でバジェット管理
スプライトモード	8×16	16×16キャラ = 4スプライト構成
タイル	8×8グリッド	背景を8×8タイルで構成
$0D禁止	TVグリッチ防止	`isValidPaletteIndex`で検証

移植にはcc65（6502向けCコンパイラ）を使う予定です。ゲームロジックの大部分はCで書き、パフォーマンスクリティカルな部分（スクロール処理、スプライトDMA転送など）のみアセンブリで書く方針です。

Kiroがどこまで6502アセンブリを書けるか...続報をお待ちください。
ゲームボーイソフトをKiroと開発されている方は、割とサクッと作られているようなので、案外いけるのかも・・・？

学び

Spec駆動開発はゲーム開発と相性が良い。ファミコンの制約のような「守るべきルール」が多い開発では、要件定義段階で制約を明文化しておくとAIが逸脱しにくい
プロパティベーステストは仕様の形式化。「任意の入力に対してこの性質が成り立つ」という記述は、仕様そのもの
プレイテストからのフィードバックが速い。「ボスが弱い」「安全地帯がある」といった感覚的なフィードバックを、その場でKiroに伝えて調整できる
テストが多いと方針転換が怖くない。縦シュー→横シューの変更でも、壊れた箇所をすぐ検出できた
ファミコン制約を先に決めておくと移植が楽になる（はず）。これはPhase 2で検証予定

まとめ

「ファミコンで動くゲームをAIに作ってもらう」という無茶振りから始まったこのプロジェクト、HTML5版は一通り遊べる状態になりました。

Kiro + Claude Opusの組み合わせは、ゲーム開発においても十分に実用的です。特にSpec駆動開発による要件の明文化と、プロパティベーステストによる仕様の形式検証は、ゲームのような「正しさの定義が難しい」ドメインでも有効でした。

次はNES ROM移植。6502との格闘が待っています。

記載されている会社名、製品名、サービス名、ロゴ等は各社の商標または登録商標です。

参考リンク