技術 約13分で読めます

AIで80年代風ゲームを数日で作る、Phaser3と役割別スキル分割で回すdev.to記事

AI ゲーム Phaser TypeScript スキル AWS
いけさん目次

dev.to に Claranet の社内 AWS Summit コンテスト「INO INO Gameboy Challenge」を題材にしたポストが流れてきた。
会場ブースで10〜30秒遊べる80年代風ゲームを作り、優勝賞品は LEGO 版 Game Boy、AIツールの利用は全面的に推奨、という趣旨のコンテストだ。

著者は1982年の Irem のアーケード名作 Moon Patrol を下敷きにした「Moon Patrol Revisited」を数日で仕上げた。
ブラウザで遊ぶタイプの軽量ゲームで、技術スタックは Phaser 3 + TypeScript + Vite、ホスティングは Vercel。
個人開発の定番っぽい構成で、リッチなエンジンを使わずに80年代感を再現している。

読んでいて面白かったのは、完成物そのものよりも AIに巨大プロンプトを1発で投げず役割別の3スキルに分けた 部分の設計だった。
Claude の Skills 機能や、最近の Agent 系ツールで話題になっている構成そのもので、レトロゲーム制作は題材として分割のメリットが出やすい。

コンテストの与件

ざっと押さえておくと、制約はこんな感じ。

  • AWS Summit ブースで立ちながら遊べる、10〜30秒で1プレイが終わる短さ
  • 80年代風のビジュアル・サウンド（コンテストのテーマ）
  • AIツール使用OK、むしろ推奨
  • 作るものは社内メンバー向けの遊べるプロトタイプ

要はハッカソン寄りの「ガッツリ作る時間はないが、仕様は明確」な案件で、AIアシスト開発の相性が良い条件が揃っている。
ここで「時間短縮のために全部1つのAIエージェントに丸投げ」ではなく、スキルを分ける 選択を取ったのがこの記事の主軸だ。

80年代縛り・10秒縛りは偶然ではない

ぱっと見は懐古趣味の縛りに見えるが、ブース展示・AI解禁の文脈にきれいに噛み合った設計になっている。

ブースゲームは普通のインディーゲームと前提が違う。
Steam や itch.io に置くゲームは自分で選んで買ったプレイヤーが数時間遊ぶが、ブースで遊ばせるゲームは来場者を止めて会話のきっかけを作る ためのもので、10〜30秒というのは飾りではなく逆算された数字だ。
理解にかけられる時間はほぼゼロ、ボタン1個で遊べる必要があり、失敗してもすぐ次の人に交代する。Moon Patrol のような横スクロール1ボタンゲームが題材として選ばれたのは、ノスタルジーだけが理由ではなく、1ボタン・左→右・死んだらすぐ死ぬ という構造そのものがブース向きだからだ。
同じ10秒単位の設計は、自分が制作に加わった メシードソフトウェア「十秒奪取！」 を Steam に出した時にも軸にした発想で、短尺はゲーム性を殺す制約に見えて、むしろ設計の筋をクッキリさせる助けになる。

言われてみれば1980年代アーケードは、ゲーセンで100円硬貨を投げる通行人相手の短時間ゲームだった。
コイン投入→即プレイ、1〜2ボタン、負け条件明確、筐体側面のペラ紙でルール説明が済む。
元祖ブースゲーム と言ってよく、INO INO の「80年代風」縛りは、ピクセルアートの見た目だけでなく 設計上の型を借りてくる縛り として機能している。ゼロから10秒で終わるゲームを発明するのは難しいが、アーケードには枯れた型がある。

ビジュアル側でも80年代スタイルはAI生成と相性がいい。32x32〜64x64程度のスプライト、限られた色数、影やライティングの不在、2D矩形の当たり判定。要するに AIが破綻しやすい要素がそもそも存在しない。
3Dシェーダーや物理演算をAIに任せるとすぐ崩れるが、ピクセル+2Dスプライトは崩れない。このブログでも Qwen Image Editで写真をドット絵に変換できるか試す や Z-Image i2iでドット絵変換できるか試した で、写真からのドット絵変換がどこまで AI で実用になるかを検証した。ゲームアセットの量産までは届かないにしろ、80年代的ビジュアルは AI が扱いやすい領域 だという手応えはある。
コンテスト運営側の美的趣味だけでなく、AI使用を推奨するための現実的な範囲設定 として読むのが妥当だろう。

もう1つ、INO INO は AI ツールの使用が「許可」ではなく「推奨」だった点も今っぽい。
2023〜2024年頃の社内ハッカソンは「AI使用可/不可」のルール明示がデフォルトだったが、2026年のいま、AIを禁じるルールを作るほうが不自然 になりつつある。イベント運用の側にも「AIを前提にした設計」が降りてきた、という1例として読める。

1つの大きなプロンプトにしない、3つのスキルに割る

著者が組んだのは3つのカスタムスキル。
Claude の Skills のような仕組みで、それぞれ独立したシステムプロンプト＋参考資料＋出力フォーマット を持つ専門ロールとして定義されている。

スキル名役割
retrogame-designer-expertゲームデザイン文書（GDD）作成。ビジュアル仕様、色パレット、スクロール速度、スコアリングルールなど「デザイナーの判断」を担当
phaser3-expert実装担当。Phaser 3 + TypeScript + Vite でパフォーマンスを気にしながらコードを書く
8bit-music-creator-expertサウンド担当。8bit系のBGMと効果音を作る

この分け方のポイントは、職能で割っているところだ。
「1つのAIにデザインも実装も作曲も全部考えさせる」と、プロンプトが肥大化した上に、どれかの品質が必ず犠牲になる。
著者の言い分は単純で、デザイナーは感覚で考え、開発者はパフォーマンスを気にし、作曲家は音を思考するので、混ぜない方が出力が良い。

もう1つの理由として「再利用」が挙げられている。
phaser3-expert は別のゲームプロジェクトでもそのまま使える資産になる。
1発モノの超巨大プロンプトは次のプロジェクトでは捨てる羽目になるが、スキル単位なら積み上がる。

flowchart LR
  A[retrogame-designer-expert<br/>GDDを書く] --> D[ゲームデザイン文書]
  D --> B[phaser3-expert<br/>実装する]
  D --> C[8bit-music-creator-expert<br/>音を作る]
  B --> G[Moon Patrol Revisited]
  C --> G

図にすると当たり前っぽく見えるが、「デザインが先に文書として固まる」→「実装と音楽が並行して走る」→「最後に統合する」という流れを、AI相手にきっちり守らせている点が効いている。

6イテレーションで、毎回「遊べるもの」を出す

もう1つ参考になるのが、反復の切り方だ。
著者は6イテレーションに分けて開発したが、毎回のゴールを「このビルドで何かしら遊べる状態にする」と決めている。

記事で具体的に挙げられているマイルストーンは2つだけ。

  • Iteration 1: スクロールする地面の上をバギーが走る
  • Iteration 6: ポリッシュと AWS ブランディングの適用

中間のイテレーションは本文では詳述されていないが、「プレイ可能なものを毎回出す」という制約が AI に丸投げ気味でも破綻しにくい のはよくわかる。
なぜなら、スキル分割で生成されたコードを最後に一気に結合するのではなく、毎ラウンドで実機確認 → 次のスキルに差分依頼、という短いフィードバックループに持ち込めるから。
AIコーディング系の本番運用でも同じことが言われていて、このブログでも AIコーディングエージェントを本番に載せるための設計原則 で、compaction や本番事故を踏まえた「短い反復」の話を書いた。
個人開発の規模でも、原則は変わらない。実際このブログの そば食いゲーム進捗 でも、毎回「この形ならどう？」と遊べる段階でビルドを出していて、AI を使わなくても結局は同じ切り方に収束していた。

技術スタックは軽量寄り

ゲームエンジンは Phaser 3、言語は TypeScript、バンドラは Vite、ホスティングは Vercel。
デプロイ先が Vercel なのは、コンテストという性質上「URL を共有して会場端末で開けば即プレイ」できる手軽さが効いているのだろう。
Unity / Godot のような本格エンジンを持ち出さない判断は、会場で動かす10〜30秒ゲームとしては妥当だ。

Phaser 3 は HTML5 Canvas ベースの2Dゲームエンジンで、Canvas と WebGL を切り替え可能。
8bit風のドット絵を動かすだけなら軽量で、モバイルブラウザでも割とまともに動く。
TypeScript 化されていて、phaser3-expert のような特化AIにはコードベースが読みやすい（シンボル名や型がはっきりしている）。
AI補助の実装と相性が良い理由の1つは、既存コードの型情報をLLMが利用しやすい 点にある。

ブラウザで動く自作ゲームという文脈では、このブログでも そば食いゲーム プロトタイプ作成、ADVのゲームエンジンを自作、カードゲーム プロトタイプ仕様書 などプロト寄りの話を散発的に書いてきた。
どれも最小限のランタイムで遊べる形まで素早く持っていく方針で、Moon Patrol Revisited の Phaser 3 + Vite + Vercel 構成もその延長線上だ。
AI にゲーム側のデータを作らせる切り口だと、ローカルVLMでキャラ画像からRPGパラメータを抽出 で画像を食わせて HP・攻撃力・アビリティを JSON で出させる実験も書いた。retrogame-designer-expert が 職能としての AI だとすれば、あちらは 素材としての AI で、ゲーム × AI の役割分担はだいたいこの2系統に分かれる。

一番しんどかったのは音楽

記事で正直に書かれていて共感したのが、音楽生成の難しさだ。
著者は A-ha の「Take On Me」の8bitアレンジ風トラックを狙ったが、生成AIは理想通りのものを出してくれず、「得られたものを採用した」と書いている。
見た目とコードは AI で比較的すんなり出るが、耳の合格ライン は画より遥かに厳しいのが現実だ。

ここは個人開発者にもよくある落とし穴で、8bitサウンドは一見シンプルに見えて、

  • 参考曲のメロディ解析（耳コピ相当）
  • 音色（矩形波・三角波・ノイズ等）の選定
  • テンポ・尺の調整
  • ゲームの効果音との音量バランス

と工程が意外と多い。
AIに任せるなら、8bit-music-creator-expert の中でさらに「曲のスケッチ」「音色選定」「ミックスノート」くらいの内訳を持たせた方が、一発で完パケを狙うより現実的だろう。
記事の構成から見ると、音楽スキルだけ抽象度が高く、細かく詰め切れなかった印象がある。

そもそも音楽生成AI自体は何もないわけじゃなく、近年いくつか実用レベルのものが出ている。

ツール特徴
Suno / Udioテキストプロンプトから歌入り含む完パケ楽曲を生成する商用サービス
MusicGen（Meta AudioCraft）オープンソースの楽曲生成モデル。ローカル実行可能
Stable Audio（Stability AI）Stability 系のオーディオ生成。SFX 寄りの短尺にも向く

ただし、どれも8bit（チップチューン）との相性がそれほど良くない。
出力は 44.1kHz のステレオで、リバーブや複数パート重ね前提の「現代的にミックスされたレトロ風」にはなる。耳だけで「レトロゲームっぽい」判定ならクリアするが、本物のチップチューンが持つ「矩形波・三角波・ノイズの3〜4チャンネル制約」「サンプリング非使用」のような ハードウェア由来の制約そのものは再現してくれない。
現実的には AI でメロディやコード進行の着想を得て、最終の音はトラッカー（FamiStudio / FamiTracker / Deflemask など）で打ち直す2段構成が素直だ。

なぜ「スキル分割」が効くのかを、ブログ内の他の事例と並べる

この記事で一番価値があるのは「AIに巨大プロンプトを1発で投げない」という原則を、ゲーム開発という具体例で示したことだ。
同じ発想は、このブログでも別の切り口で何度か扱ってきた。

まず UI UX Pro Max Skill：AIのUI生成を改善するスキルを過去記事と比較してみた で取り上げたのは、UI/UX の意思決定を AI に任せるためのスキルだった。
あれもスタイル・色・フォント・業界別ルールを、データベースに持ち込んで専門ロールに切り出す 構成で、今回の retrogame-designer-expert と発想は同じだ。
違うのは、UI スキルが既存データベースの参照主体なのに対し、レトロゲームの GDD は毎回生成主体だという点。

もう1つ、「同僚をAIに蒸留する」OSSを見て、自分の蒸留方法を調べた では、人間の仕事の仕方をスキルに落とす方向のOSSを紹介した。
今回の Claranet 記事の3スキルは、「職能」を蒸留したものと見れば親戚だ。
スキルという単位が、人ベースでも役割ベースでも定義できる のが Claude Skills や類似フレームの面白い特性になっている。

少しズレる比較だが、tmuxでClaude CodeとCodexを連携させて一晩放置でゲームを作らせる（実践編） では、別々のエージェントを対戦させて一晩ゲームを生成させる実験を書いた。
あれは、同じロールを2つのAIで回す自動化。
今回は、異なるロールを3つに分けて順に動かす工程設計。
目的は似ていても、片方が「時間を賭けて量を稼ぐ」のに対し、もう片方は「工程を切って質を稼ぐ」で、打ち手の性格が真逆なのが面白い。
個人でAIに何かを作らせる時、どちらを選ぶかは ゴールが動く完成品1本か、大量の試行か でだいたい決まる。

真似するときの勘所

この手の記事は真似しようとすると意外と地雷があるので、気になる点をいくつか。

勘所詳細
GDD を先に固めるretrogame-designer-expert 相当の役を最初の数時間は独立して回す。あとで仕様を変えると実装と音の手戻りが二重に効く
Phaser 3 は型定義が AI フレンドリーTypeScript とセットで使うと実装スキルの再現性が高い。JS 素のまま AI に投げるとハルシネーションの温床になりやすい
音楽は独立プロジェクトと割り切るゲームビルドに組み込む前段階として、単体で差し替え可能なアセットにしておく。生成が気に入らなければサウンドだけ丸ごと差し替えられる構造にする
イテレーションごとに必ずプレイAIのビルドをテストせずに積むと、3イテレーション後に物理挙動が壊れていることがザラ。毎ラウンド30秒でいいから触る
Vercel デプロイ前提だと共有が速いハッカソン用途なら特にプレビューURL運用が強い

自分ならこう組む

ここまで書いておいて、実際に自分でもやりたくなってきた。過去記事と手元ツールを並べると、このやり方はかなり再現できそうに見える。

このブログにある下敷きを棚卸しするとこれくらい揃っている。

これらを Claude Code の Skills 用参考資料として食わせれば、Claranet の3スキル構成に自前の重みを乗せられる。手元ツール（Codex・Claude Code・Gemini CLI・ローカルLLM・生成AI）との役割分担はだいたいこうなるはず。

工程担当ツール狙い
GDD 作成（デザイナー役）Claude Code + Skills過去の GDD を食わせて参照させる。10秒ループ設計は十秒奪取の知見を呼び出す
実装（Phaser or 自作エンジン）Codexコード生成密度が高い。TypeScript 型定義を食わせるとハルシネーションが減る
ドット絵・アセット生成ローカル生成AI過去のドット絵変換実験をそのままパイプラインに乗せる
8bit音楽・SFXローカルLLM + 手持ち素材原典でも詰め切れなかった領域。完パケ生成は諦めて手作業寄り
全体レビュー・統合Gemini CLI長コンテキストで全コード + GDD + アセットを一気に読ませる

題材は自然に 進行中のそば食いゲームをこのワークフローで回し直す のが一番近い。
GDD とプロトタイプが進捗記事に溜まっていて、3スキル構成に食わせる素材として使えるほうが、ゼロから別ゲームを発明するより早い。

最初から全ツールを使い分けようとすると、どの工程を誰に回すか考える時間のほうが長くなる 罠がある。
まずは Claude Code 単独で GDD + 実装を一気通貫で回して動くビルドまで持っていき、質を上げる段階でツールを分ける、くらいが現実的だろう。

記事の締めで著者が言っているのは、AIはエンジニアリングを置き換えない、増幅する という定番フレーズだ。
言い回しとしてはありがちで、AI本のお約束になりつつあるが、Moon Patrol Revisited のケースに限って言えば嘘ではない。
実装だけ速くしてもゲームデザインと音がボトルネックで詰む、という状況は実際あって、スキル分割はそこを正面から設計している。

個人的には「コンテスト景品がLEGOのゲームボーイ」というのが一番欲しい。