【保存版】OpenAI公式資料で学ぶ! Codex Game Studioプラグインを使ったゲーム開発入門：ブラウザで遊べる最初の1本を作る

作成者: AICU Japan｜2026/05/28 15:32:03 Z

生成AI時代に「ゲームを作ってみたい」と思ったとき、いきなりUnityやUnreal Engineを開いて挫折する必要はありません。まずは、OpenAIのコーディング支援AI「Codex」を使ってブラウザで動く小さなゲームを作ってみましょう。キー入力で動き、ルールを作り、スコアが増え、失敗して、もう一度遊べるところまで持っていく。この「ゲームとして最初に遊べる1本」をAIとともに作る体験は、入門者だけでなく、プロフェッショナルにとってもAI駆動開発の総合的な学習になり、Claude Codeだけでなく、Codexの実力やCodexの公式Game Studioプラグインを理解する良い機会にもなります。

星拾いゲーム(開発中)

https://openai.com/ja-JP/codex/

OpenAI公式のCodexユースケースでも、ゲーム開発は「コード生成だけ」の話ではなく、企画、実装、UI調整、画像アセット、実ブラウザでのプレイテスト、GitHubでのレビューまでを含む反復作業として紹介されています。特にブラウザゲームでは、Codexにまず計画を書かせ、AGENTS.mdで作法を伝え、Playwrightで実際の画面を確認しながら直していく流れが推奨されています。

この記事では初心者がCodexアプリと、Visual Studio Code (VSCode)経由のCLIの両方を使って今日そのまま手を動かせる本格的なハンズオンとして整理します。目標は、ローカルPCに小さなブラウザゲーム開発環境を作り、Codexに計画、実装、確認、修正、GitHubレビューまで伴走してもらう開発環境をつくることです。

AICUでは以前から、Pyxelを使った「大人も夢中! AIでゲーム開発」特集で、Pyxel+Geminiでテトリスを一瞬で作った話、Claude Codeゲーム開発ワークショップのレポートなどを扱ってきました。「AICU Games」や「Nehan.AI」、「Football News Hero」の開発などでClaude Codeでは月額100万円規模のトークンを消費するAICU Gamesですが、今回は、その延長線（延長戦?）として、本格的な開発のベースとなる「CodexでのWebゲーム開発入門の初手」とゲーム開発ノウハウをまとめた保存版です。

http://j.aicu.ai/MagV10

https://forest.watch.impress.co.jp/docs/serial/aistream/2110370.html

次号のアイキューマガジンでは特集「AIゲーム開発」を予定しています！

https://www.aicu.jp/post/260509

まず作るものを小さく決め、ルールを決める。

最初の題材は、2Dの「Star Picker」、"星拾いゲーム"にします。まずはゲームを構成するルールを考えましょう。プレイヤーは矢印キーまたはWASDで小さなキャラクターを画面内で動かし、画面内に出る星を取るとスコアが増えます。制限時間が0になると終了し、リトライできます。これだけです。

ここで大切なのは、最初から「壮大なRPG」や「オンライン対戦」や「3Dオープンワールド」を作ろうとしないことです。Codexはかなり広い範囲を実装できますが、ゲーム開発で最初に必要なのは、世界観よりも「遊べるループ」です。移動する、取る、点が入る、時間が減る、終わる、もう一度遊ぶ。この輪が閉じると、そこからキャラクター、敵、ステージ、音、演出を足していけます。

OpenAI公式のブラウザゲーム向けガイドでも、最初に決めるべきものとして、プレイヤーの目的、メインループ、入力、成功と失敗、難易度、見た目、技術スタック、マイルストーンが挙げられています。つまり「ゲームを作って」ではなく、「このループを、どの順番で、どう検証しながら作るか」までCodexに渡すのがコツです。

アプリ版「Codex」とCLI版をインストール

Codexはデスクトップアプリ、IDE拡張、CLI、クラウドから使えます。初心者には、まずCodexアプリかVS Code拡張がわかりやすいです。ターミナルに抵抗がなければCLIも便利です。

アプリ版のインストール

https://www.aicu.jp/post/260203

アプリ版「Codex」ではなく、より本格的なゲーム開発の環境を目指すあなたは、Visual StudioとGitHubでの開発を準備してください。

Codex CLIを使う場合は、Node.jsが入っている環境ならnpmで入れられます。Terminal (Windowsならcmd.exe) を開いて…

mkdir codex-game-lab
cd codex-game-lab
npm install -g @openai/codex

macOSでHomebrewを使っている人はbrewでも入れられます。

brew install codex

インストール後、作業したいフォルダで「codex」で起動します。簡単！

codex

サインインはChatGPTアカウントまたはOpenAI APIキーで行います。単にローカルのゲームを作るだけなら、まずはChatGPTアカウントで問題ありません。OpenAI APIキーが必要になるのは、ゲーム内にOpenAI API機能を組み込む場合や、画像生成をAPIで実行する場合です。APIキーを使うときは、コードやGitHubに直接書かず、`.env.local` のような環境変数ファイルに置きます。

作業前にGitも初期化しておきます。Codexはファイルを書き換えるため、いつでも戻れるようにしておくと安心です。

git init

gitがインストールされていない場合は、インストールしておきましょう！
https://git-scm.com/

MCPを入れる

MCPはModel Context Protocolの略で、Codexが外部のツールやドキュメント、ブラウザ、Figma、GitHubなどに接続するための仕組みです。OpenAI公式ドキュメントでは、MCPは「必要な文脈がリポジトリの外にあるとき」に使うものとして説明されています。たとえば、PhaserやThree.jsの最新仕様を調べたい、ブラウザを開いて実画面を確認したい、GitHubのIssueやPRを読みたい、といった場面でAIが連続した会話を行うための通信規格です。

まず入れておくと便利なのは、OpenAI Docs MCP、Context7、Playwright MCPです。OpenAI Docs MCPはOpenAI公式情報をCodexが確認するため、Context7はPhaserやViteなど外部ライブラリのドキュメント確認に使うため、Playwright MCPは実ブラウザでゲームを起動して、スクリーンショットや操作確認を行うために使います。

Codex CLIでは、MCPサーバーを `codex mcp add` で登録できます。HTTP型のMCPは `--url`、ローカルで起動するstdio型のMCPは `--` のあとに起動コマンドを書きます。3つのMCPを1行づつインストールしていきましょう。

codex mcp add openaiDeveloperDocs --url https://developers.openai.com/mcp
codex mcp add context7 -- npx -y @upstash/context7-mcp
codex mcp add playwright -- npx -y @playwright/mcp@latest

登録できたか確認するときは、CLIなら次を実行します。

codex mcp list

CodexのターミナルUI内では、`/mcp` と入力すると有効なMCPサーバーを確認できます。OAuthが必要なMCPサーバーでは、次の形でログインします。

codex mcp login <server-name>

MCP設定は通常 `~/.codex/config.toml` に保存されます。プロジェクト単位で設定したい場合は `.codex/config.toml` を使うこともできますが、Codexがそのプロジェクトを信頼している必要があります。初心者のうちは、まずユーザー設定に入れておけば十分です。

ここで注意したいのは、MCPを入れすぎないことです。公式ドキュメントも、最初から使う全ツールを接続するのではなく、手作業を明らかに減らす1つか2つから始める考え方を勧めています。ゲーム制作なら、最初は「公式ドキュメントを見る」「ブラウザで実際に遊ぶ」の2つが効きます。

Game Studioプラグインを使う

今回のハンズオンでは、まずGame Studioプラグインを使う前提にします。Codexのプラグインは、スキル、アプリ連携、MCPサーバーをまとめた再利用可能なワークフローです。OpenAI公式の「Get from idea to proof of concept」でも、ブラウザゲームのPoCではGame Studioを使い、プレイヤーの行動、最初に遊べるループ、エンジン、アセットワークフロー、HUD、操作、ブラウザテストを決める流れが紹介されています。

ただし、Game StudioはCodex本体に常に組み込まれている予約機能で
はなく、OpenAI curated marketplaceにあるプラグインです。公式ド
キュメントでは、Codexアプリならプラグイン詳細画面で追加し、CLI
なら `/plugins` からインストールする流れが説明されています。コ
マンドラインに慣れている人は、現在のインストール状態を次で確認
できます。

codex plugin list

一覧に `game-studio@openai-curated` があり、`not installed` と出ている場合は、いちどCodexを /quit で終了し、次のコマンドで追加します。

codex plugin add game-studio@openai-curated

インストール後、Codexを再起動すると、プロンプト内で $game-studio を使えるようになります。CLIをVSCodeのターミナルで使っている場合は、/plugins からGame Studioを探して Install plugin を選びます。インストール後、新しいスレッドを開くかCodexを再起動すると、プロンプト内で $game-studio を使えるようになります。

デスクトップ版のCodexアプリを使っている場合は、Plugins画面でGame Studioを探し、追加ボタン、または Add to Codex を押します。

それぞれのCodexを起動し、日本語を希望する場合は日本語で応対してもらえるように、1行プロンプトを入力してみましょう。

英語で考えて、日本語で応答お願いします

AGENTS.mdを書く

Codexに長く作業してもらうなら、最初にAGENTS.mdを書きます。AGENTS.mdは、そのリポジトリにおけるCodexへの継続的な指示書です。OpenAI公式ドキュメントでも、AGENTS.mdはビルドコマンド、テストコマンド、レビュー方針、リポジトリ固有のルールを置く場所として紹介されています。今回は、プロジェクト直下に `AGENTS.md` を作り、次を入れます。

# Codex Game Lab

This is a beginner-friendly browser game prototype.

Tech stack:

- Vite
- TypeScript
- Phaser for the 2D gameplay layer
- DOM for HUD, menus, and instructions
- No backend for the first version

Development rules:

- Use PLAN.md as the source of truth for scope and milestone order.
- Keep the first playable loop small: move, collect, score, timer, game over, retry.
- Keep game state serializable and separate from Phaser display objects.
- Use Phaser for rendering and input, but do not hide all UI inside canvas.
- Use DOM for HUD and menus when text matters.
- Start or reuse the dev server and verify the game in a browser.
- Use Playwright when available to inspect the page and capture screenshots.
- Run build or test commands after meaningful changes.
- Log major decisions under .logs/.

Definition of done:

- The game launches locally.
- The player can move.
- The player can collect a star.
- Score changes visibly.
- Timer or fail state works.
- Retry works.
- README includes setup and controls.

# Codex Game Lab
これは初心者にやさしいブラウザゲームのプロトタイプです。

## 技術スタック
- Vite
- TypeScript
- 2D ゲームプレイ層には Phaser を使う
- HUD、メニュー、説明文には DOM を使う
- 最初のバージョンではバックエンドを持たない

## 開発ルール
- スコープとマイルストーン順序の正本として `PLAN.md` を使う。
- 最初のプレイ可能ループは小さく保つ: 移動、収集、スコア、タイマー、ゲームオーバー、リトライ。
- ゲーム状態はシリアライズ可能にし、Phaser の表示オブジェクトから分離する。
- レンダリングと入力には Phaser を使う。ただし、すべての UI を canvas 内に隠さない。
- テキストが重要な HUD やメニューには DOM を使う。
- 開発サーバーを起動または再利用し、ブラウザでゲームを検証する。
- 利用できる場合は Playwright を使ってページを確認し、スクリーンショットを取得する。
- 意味のある変更のあとには build または test コマンドを実行する。
- 主要な判断は `.logs/` 配下に記録する。

## 完了条件
- ゲームがローカルで起動する。
- プレイヤーが移動できる。
- プレイヤーが星を収集できる。
- スコアの変化が目に見える。
- タイマーまたは失敗状態が機能する。
- リトライが機能する。
- README にセットアップ方法と操作方法が含まれている。

このファイルは、Codexへの「毎回の口頭説明」を減らすためのものです。たとえば「UIは全部Canvasに描かない」「ゲーム状態はPhaserのSpriteそのものに持たせない」「実ブラウザで確認する」といったルールは、ゲーム制作ではあとから効いてきます。

AICU国際ゲーム開発事業部「Legendsチーム」はゲーム開発に30年以上関わってきた開発者によって構成されています。ゲーム開発はコードだけでは完結しません。ルール、見た目、入力、説明、リトライ、配布方法、マネタイズといったユーザー体験まで含めて「遊べる」状態になります。そこまでは全体の7割です、動くゲームが完成した先の「磨き上げ」においても、AGENTS.mdは、その全体像をCodexに忘れさせないための足場として非常に重要になります。チーム開発の場合も、そのルールを明確に記載し、合意の上で更新をしていきましょう。これはバイブコーディングから「AI駆動開発」にレベルを上げて行く上で非常に重要なテクニックになります。

https://www.aicu.jp/post/260131

PLAN.mdをCodexに書かせる

次に、CodexにPLAN.mdを書いてもらいます。まだ実装はさせません。いきなりコードを書かせると、画面は出てもゲームとして弱くなりがちです。

ここでの PLAN.md は、Codexが自動的に特別扱いする予約ファイル名ではありません。Codexが標準で探索するプロジェクト指示ファイルは AGENTS.md や AGENTS.override.md です。一方、Claude Codeでは CLAUDE.md など、ツールによって異なります。OpenAI公式のブラウザゲーム向けユースケースでは PLAN.md を作る流れが紹介されており、長時間の実装計画を扱うCookbookでは PLANS.md を AGENTS.md で定義して使う例もあります。つまり重要なのは、ファイル名そのものではなく、Codexに「この計画書を読んで、その範囲で実装して」と明示することです。このハンズオンでは「1本のゲームを作るための実装計画」なので、公式ブラウザゲーム記事に合わせて単数の PLAN.md に統一します。
Codexにこう依頼しましょう。

Use $game-studio, $playwright-interactive, $imagegen, and $openai-docs.
Read AGENTS.md.

Before writing code, use Game Studio to choose the implementation route and create PLAN.md for a beginner-friendly browser game called "Star Picker".

The game should be a tiny 2D browser game:
- player moves with arrow keys and WASD
- collect stars to increase score
- timer counts down
- game over when time reaches zero
- retry button starts a new run

Assume Vite + TypeScript + Phaser unless Game Studio identifies a better route.
Keep the first version small.

PLAN.md should define:
player goal, core loop, inputs, win/fail states, milestones, file structure, visual direction, test plan, and what not to build yet.
Stop after writing PLAN.md.

$game-studio、$playwright-interactive、$imagegen、$openai-docs を使用してください。
AGENTS.md を読んでください。
コードを記述する前に、Game Studio を使用して実装方法を選択し、「Star Picker」という初心者向けのブラウザゲームの PLAN.md を作成してください。

ゲームは、以下の機能を備えた小さな 2D ブラウザゲームである必要があります。
- プレイヤーは矢印キーと WASD キーで移動します。
- 星を集めてスコアを上げます。
- タイマーがカウントダウンします。
- 時間がゼロになるとゲームオーバーです。
- リトライボタンで新しい実行を開始します。

Game Studio がより良い方法を提示しない限り、Vite + TypeScript + Phaser を使用するものとします。

最初のバージョンは小規模にしてください。

PLAN.md には、以下の項目を定義する必要があります。
プレイヤーの目標、コアループ、入力、勝敗状態、マイルストーン、ファイル構造、ビジュアルの方向性、テスト計画、そしてまだ実装しない項目。

PLAN.md の作成が完了したら、作業を終了してください。

できあがったPLAN.mdを読み、人間の目で「これは遊べそうか」を確認します。ここで「敵を出したい」「スマホ対応したい」「画像生成でキャラを作りたい」と思っても、最初の実装には入れません。PLAN.mdに「あとでやる」と書いておくくらいで十分です。

最初の実装を頼む

PLAN.mdができたら、次にCodexへ実装を頼みます。ここでも、一気に完成版を求めないほうが成功します。

Implement milestone 1 from PLAN.md.

Create the Vite + TypeScript + Phaser app in this repo.
Build only the first playable loop:
launch screen, player movement, star collection, score, timer, game over, retry.

Use simple placeholder shapes first.
Do not generate final art yet.

After implementation:
run the build command,
start or reuse the dev server,
inspect the game in the browser if Playwright is available,
and summarize what works and what remains.

PLAN.md のマイルストーン 1 を実装してください。
このリポジトリに Vite + TypeScript + Phaser アプリケーションを作成してください。
最初のプレイ可能なループのみをビルドしてください。
起動画面、プレイヤーの移動、スター収集、スコア、タイマー、ゲームオーバー、リトライ。
最初はシンプルなプレースホルダー図形を使用してください。
最終的なアートワークはまだ生成しないでください。
実装後：
ビルドコマンドを実行し、
開発サーバーを起動または再利用し、
Playwright が利用可能な場合はブラウザでゲームを検証し、
動作している部分と未実装の部分をまとめてください。

手動で(=人間主導で)進める場合は、以下のようなコマンドが基礎になります。Codexに実行してもらっても、ターミナルをもう一つ開いて、自分で実行しても構いません。

npm create vite@latest . -- --template vanilla-ts
npm install
npm install phaser
npm run dev

これでlocalhost:5173に最初のゲームらしきものが現れます、Star Pickerです。

最初のこのプレイアブルバージョンは、画像がリッチでなくても構いません。プレイヤーが四角形、星が黄色い丸でもいいです。ゲーム制作の初期段階では、アートより先に「入力に反応するか」「スコアが変わるか」「失敗とリトライがあるか」を見ます。

OpenAI公式のブラウザゲームユースケースでも、CodexとImageGenを組み合わせると、コンセプトアート、スプライト、背景、UIアセットを生成できると説明されています。ただし、最初から大量の絵を作ると、ゲームの本質が見えにくくなります。

AIがブラウザで遊んで動作確認

ゲームは、ビルドが通っただけでは完成ではありません。実際にブラウザで開き、キーを押し、点が入り、ゲームオーバーになり、リトライできるかを見ます。Playwright MCPが使えるなら、Codexにこう頼みます。

Use Playwright if available.
Open the local dev server.
Play the game for 20 seconds.
Verify movement, star collection, score update, timer, game over, and retry.
Capture screenshots for launch, gameplay, and game over.
Fix only issues that block the first playable loop.

Playwrightが利用可能であれば使用してください。
ローカル開発サーバーを起動してください。
ゲームを20秒間プレイしてください。
移動、星の収集、スコアの更新、タイマー、ゲームオーバー、リトライの動作を確認してください。
起動時、ゲームプレイ時、ゲームオーバー時のスクリーンショットを撮影してください。
最初のプレイ可能なループを妨げる問題のみを修正してください。

Playwrightがゲームをプレイします。これでゲームのE2EテストがAIによって実行可能になります。E2E（エンドツーエンド）テストとは、実際のユーザーの操作を模倣し、画面（フロントエンド）、サーバー（バックエンド）、データベースに至るシステム全体が意図通りに連携して動作するかを検証するテスト手法です。

撮影されたスクリーンショットです。

Playwrightだけに任せるのではなく、自分でブラウザを開いて（この場合は localhost:5173 で起動しています）プレイし、スクリーンショットをCodexに渡します。そのときの指示は以下のように細かくするのがコツです。以下はHUD（Head-up Displayの略）の修正例です。ゲームにおけるHUD（ハッド）とは、プレイヤーの体力、残り時間、マップ、残弾数など、画面の最前面に常に表示される情報やインターフェースの総称です。

The game runs, but the score text overlaps the timer on mobile width.
Change only the HUD layout.
Keep gameplay behavior unchanged.
Verify the same route again after the edit.

ゲームは起動しましたが、モバイル画面ではスコア表示がタイマーと重なって表示されます。
HUDレイアウトのみを変更してください。
ゲームプレイの動作は変更しないでください。
編集後、同じルートで再度動作を確認してください。

OpenAI公式の「Make granular UI changes」では、既存アプリのUI修正は「1つの視覚的な指摘、1つの小さな編集、1つのブラウザ確認」のループが向いていると説明されています。ゲームUIでも同じです。「なんとなく全体をかっこよく」ではなく、「スコア表示を右上から左上に」「リトライボタンを中央下に」「スマホ幅で説明文を短く」といった粒度で頼むと、Codexは余計な改造をしにくくなります。

以下はOpenAI公式のプロンプトの例です。ゲームのUIを改善する際に「変更しないでください」を明確に指定しています。

既存のアプリで、この UI 変更を実施してください: [正確な間隔、配置、色、コピー、レスポンシブ、またはコンポーネントの状態調整について説明してください] 制約: - この UI 調整に必要なファイルのみを変更します。 - 既存のコンポーネント、トークン、アイコン、およびレイアウトパターンを再利用します。 - 私が明示的に要求しない限り、動作、データフロー、およびルーティングは変更しないでください。 - 開発サーバーを起動または再利用し、ブラウザで現在の UI を検査し、最小限のパッチを作成し、結果を視覚的に確認します。この 1 つの変更で作業を終了し、変更したファイルと実行したブラウザチェックの概要をまとめます。

画像生成を使ってアセットを作る

最初のループが動いたら、ImageGenでアセットを作る段階に入れます。ここで重要なのは、画像生成プロンプトを保存することです。OpenAI公式ガイドでも、後から同じ雰囲気のアセットを追加できるよう、生成プロンプトをファイルに残すことが勧められています。

プロジェクトに `.prompts/` を作り、たとえば `.prompts/star-picker-assets.md` に次のように残します。

# Star Picker asset prompts

Style:
small 2D browser game, readable silhouettes, warm arcade palette, simple shapes, no text, transparent background when possible.

Player:
a small friendly explorer icon, top-down 2D sprite, simple readable silhouette, 64x64, transparent background, no text.

Star:
bright collectible star, 32x32, high contrast, transparent background, no text.

Background:
soft night-sky tile background, subtle grid, not too busy, readable playfield, no text.

# スターピッカーのアセットに関する指示
スタイル：小型2Dブラウザゲーム、読みやすいシルエット、温かみのあるアーケード調の配色、シンプルな形状、テキストなし、可能な限り背景透過。
プレイヤー：親しみやすい小さな探検家アイコン、トップダウン視点の2Dスプライト、シンプルで読みやすいシルエット、64x64ピクセル、背景透過、テキストなし。
スター：明るい収集可能な星、32x32ピクセル、高コントラスト、背景透過、テキストなし。
背景：柔らかな夜空のタイル背景、控えめなグリッド、ごちゃごちゃしすぎず、読みやすいプレイフィールド、テキストなし。

Codexにはこう頼みます。

Use imagegen if available to generate placeholder game assets for Star Picker.
Save every prompt under .prompts/.
Put final assets under public/assets/star-picker/.
Do not change gameplay until assets are saved.
After replacing placeholder shapes, verify that assets load in the browser.

Star Pickerのプレースホルダーゲームアセットを生成するには、可能であればimagegenを使用してください。
すべてのプロンプトを.prompts/ディレクトリに保存してください。
最終的なアセットをpublic/assets/star-picker/ディレクトリに配置してください。
アセットを保存するまでは、ゲームプレイを変更しないでください。
プレースホルダーの形状を置き換えた後、ブラウザでアセットが正しく読み込まれることを確認してください。

なお、このプロンプトはOpenAIとしては公式の初手ですが、改善の余地があります。しかしこの時点では、画像フォーマットとして見通しが出たら、仮のスプライトシートをゲーム開発側に渡してイテレーションを回しながら（具体的には、アプリ版Codexで繰り返し生成して改善した画像をVSCodeのプロジェクトに渡しつつ）画像生成を行いながら並列でゲームループを改善していきます。

Star Pickerのプレースホルダーゲームアセットを置き換える最終的なアセットと仕様をこのディレクトリに配置しました。
アセットを表示できるように再配置するまでは、ゲームプレイを変更しないでください。プレースホルダーのサイズを置き換えた後、ブラウザでアセットが正しく読み込まれることを確認してください。

仕様では 256x256 セル、row order は up/down/left/right、歩行は4フレーム10fpsです。spritesheet.json は既存 public コピーと一致していますが、表示用に指定ディレクトリから runtime asset と仕様を改めて同期します。

せっかく表情も加えたので、ここで実装しておきましょう。

時間切れ(gameover)と、星を取った時(get)のスプライトを表示してください。表示アニメーションのdurationは調整できるように変数にしてください。

なお、画像生成コストや時間的問題で画像生成が使えない環境なら、最初はCSSやPhaserの図形描画で進めて構いません。ゲームとして面白いかどうかは、まず操作とループで決まります。グラフィックスをリッチにする前に、まずはゲームプレイとしての面白さを磨いていきましょう。

https://www.aicu.jp/post/260527

難しいゲームロジックは評価ループにする

敵の出現、当たり判定、難易度調整、カード効果、パズル生成のような部分は、スプライトシートと同様に、Codexに一発で完璧に作らせるより、評価ループを作るほうが安定します。たとえば「星がプレイヤーの近くに出すぎる」「制限時間内に平均5個くらい取れる難易度にしたい」という調整なら、簡単なシミュレーションテストを作ることができます。

Create a small deterministic simulation test for star spawning.
Run 100 seeded trials.
Report average collected stars, minimum distance from player spawn, and whether any star spawns outside the playfield.
Do not change visuals in this task.

星の出現に関する、小規模な決定論的シミュレーションテストを作成してください。シード値を与えて100回の試行を実行してください。収集した星の平均数、プレイヤーのスポーン地点からの最小距離、およびプレイフィールド外に星が出現したかどうかを報告してください。このタスクでは、ビジュアルを変更しないでください。

[AICU解説]決定論的シミュレーションテストとは

ここでいう決定論的シミュレーションテスト(deterministic simulation test)とは、「同じ初期条件と同じ乱数シードを与えたら、毎回同じ結果になるゲームロジックのテスト」です。長年のゲーム開発者の経験によって生まれたテクニックでもあります。ブラウザ画面を開かずに、星の出現位置、スコア加算、制限時間、当たり判定、失敗条件などをコードだけで動かして確認します。乱数のシードは固定されているので毎回のランダムの結果は変わりませんので、Codexも「どの変更で良くなったか、悪くなったか」を追いやすくなります。一方で、乱数で制御した星の出現位置は毎回同じになるので、難易度調整には使えますが、注意が必要です。

大事なのは、「1つの固定シードだけで面白さを判断しないこと」です。シード42ではちょうどよくても、シード17では星が偏り、シード91では簡単すぎるかもしれません。そこで、テストでは1つのシードだけでなく、100個くらいのシードを順番に走らせ、平均値、最小値、最大値、失敗したシード番号を記録するシミュレーションを実行して評価します。決定論的であることの価値は、ランダム性を消すことではありません。問題が起きたランダム条件を、あとから何度でも再現できることにあります。たとえば「シード37のときだけ星が壁の中に出る」と分かれば、Codexにそのシードを指定して修正させられます。これは、人間がブラウザで何度も遊んで「なんとなく変だった」と伝えるより、はるかに強いフィードバックです。ゲームの面白さは最終的に人間が遊んで判断しますが、出現位置、当たり判定、スコア、時間、失敗条件のような土台は、こうした再現可能なテストで固めておくと開発が速くなります。

OpenAI公式の「Iterate on difficult problems」では、難しい問題にはスコア化できる評価コマンド、ログ、生成物の確認を組み合わせ、1回ずつ改善する流れが紹介されています。ゲーム開発でもこれはそのまま使えます。感覚だけで「もっと面白く」と書いても『面白さの定義』は多様なのでハルシネーションや潜在バグを生む原因になります。「平均スコア」「被弾率」「リトライまでの秒数」「初回プレイで迷った操作」といった物理的に測定可能な尺度や評価関数を使って測れる状態になると、Codexも改善の方向を外しにくくなります。

`.logs/` には、Codexにこう記録させます。

Log each iteration under .logs/playtest.md.
For each run, record what changed, what was tested, what improved, and what still feels weak.

各イテレーションのログを.logs/playtest.mdに記録してください。
各実行ごとに、変更点、テスト内容、改善点、そして依然として不十分だと感じる点を記録してください。

長時間の制作では、このログが次回の引き継ぎになります。AICUのマガジン制作でも、ビルド、レビュー、修正、告知のような繰り返し作業は記録が効きます。ゲーム制作も同じです。OpenAI公式では「.logs」に保存していますが、「./docs/YYYY-MM-DD-Slug.md に改善レポートを書いて」といった形で長期記憶と技術レポート、開発ブログを同時に執筆することも良い方法かもしれません。

GitHubに置いて、PRでレビューする

ローカルで動いたらGitHubに置きます。最初はprivateリポジトリで十分です。GitHub CLIを使うなら、次のように作れます。

git add .
git commit -m "Create first playable Star Picker prototype"
gh repo create codex-game-lab --private --source=. --remote=origin --push

GitHub CLIを使わない場合は、GitHubのWeb画面で新規リポジトリを作り、表示される手順に沿ってpushしてください。

CodexのGitHub連携が使える環境では、PR上で `@codex review` と頼めます。公式ドキュメントでは、AGENTS.md内のレビュー方針をCodexが参照し、PRコメントで特定の観点を指定できると説明されています。

ゲームPRなら、たとえばこう書きます。

@codex review for gameplay regressions, missing tests, broken mobile layout, and risky state-management changes.

もしCodexが問題を見つけたら、すぐに「全部直して」ではなく、まず内容を読みます。レビューコメントが妥当なら、次のように焦点を絞って依頼します。

@codex fix the retry-state bug only. Keep visuals unchanged.

これも、ゲーム開発を壊さないための重要な習慣です。Codexは大きく直せますが、ゲームは入力、表示、状態、タイミングが絡むため、修正は小さく切るほうが安全です。

バグトリアージをCodexに頼む

遊んでもらえるようになると、バグ報告が出ます。「スマホでボタンが押せない」「Safariだけ音が出ない」「星が壁に埋まる」「ゲームオーバー後にスコアが増える」などです。

この段階では、Codexにいきなりパッチを書かせる前に、報告を整理させます。

Run a bug triage sweep for this game.

Inputs:
GitHub issues in this repo,
recent failing checks,
README known issues,
and .logs/playtest.md.

Do not edit files yet.
Return a prioritized list from P0 to P3.
For each bug, include evidence, likely affected files, and the smallest next action.
Keep observed facts separate from guesses.

OpenAI公式の「Automate bug triage」でも、複数の報告源を見て、重複をまとめ、証拠と推測を分け、優先順位を付けてから修正する流れが紹介されています。ゲーム制作では特に、プレイヤーの報告、スクリーンショット、CI、ブラウザ差分が混ざるため、まず整理が効きます。

2Dか3Dかで迷ったら

最初の一本は2Dで始めるのが無難です。Phaserは、スプライト、タイル、カメラ、当たり判定、シーン遷移のような2Dゲームで必要な要素が揃っています。AICUのPyxel特集でも、制約のある2D環境が初心者に向いていることを何度も扱ってきました。制約があると、作るものを小さく保ちやすいのです。

3Dを作りたい場合は、Reactではない単体の3DプロトタイプならThree.js、Reactアプリの中に3D体験を入れたいならReact Three Fiberが自然です。ただし3Dは、カメラ、ライト、奥行き、アセット読み込み、GPU負荷、スマホ表示まで考えることが増えます。最初から3Dにするなら、「歩ける部屋を1つ」「拾えるアイテムを1つ」くらいに絞るのがおすすめです。

UIは、ゲーム画面そのものはCanvasやWebGLで描き、文字が多いHUD、メニュー、設定、チュートリアルはDOMに置くのが扱いやすいです。これはGame Studio系の考え方とも一致します。Canvasにすべてを押し込むと、最初は楽でも、レスポンシブ対応やアクセシビリティ、ボタン状態の調整が難しくなります。

今日の完成条件

この記事のハンズオンで目指す完成は、派手なゲームではありません。ローカルで起動し、ブラウザで遊べて、プレイヤーが動き、星が取れて、スコアが増え、時間切れで終わり、リトライできることです。READMEに起動方法と操作方法が書かれ、GitHubにpushされ、CodexにPRレビューを頼める状態まで来れば十分です。

最後にCodexへこう頼んで、仕上げを確認します。

Review the current game against AGENTS.md and PLAN.md.

Do not add new features.
Check:
local setup,
build,
first playable loop,
keyboard controls,
HUD readability,
game over,
retry,
README,
and obvious mobile layout problems.

If something is broken, make the smallest fix and verify again.
Stop when the first playable loop is solid.

この「新機能を足さずに、最初のループを固める」という停止条件が大切です。AIコーディングでは、思いついた機能をどんどん足せてしまいます。しかしゲーム開発の入門で一番価値があるのは、「完成した小さな遊び」を持つことです。完成した小さな遊びは、次の1本の土台になります。

https://note.com/o_ob/n/n440bd9b45e0c

GitHub Pagesを使って公開する

最後に、GitHubを使って公開しましょう。

ghとgithub pagesを使って https://github.com/aicuai/codex-game-lab で公開します

こんなふうに作ったWebゲームを遊べるようになります。

展示場所はGitHub Pagesだけではありません
AICU Gamesではみなさんの素晴らしい作品を募集します！
詳しくはこちらをチェック！ https://aicu.ai/game

AICUマガジン Vol.25はゲーム開発特集！

AICUでは、AI時代のゲーム開発を何度も扱っています。今回のCodexハンズオンと合わせて読むなら、まずはAICUマガジンVol.10「Pyxel - 大人も夢中! AIでゲーム開発」が近い内容です。PyxelはPython向けのレトロゲームエンジンで、初心者が「ゲームが動く」体験を得るにはとてもよい題材です。

「ゲーム開発少年の30年が30分に凝縮」では、Pyxel開発者の北尾崇さんを招いたAICU Creators Talkのレポートを掲載しています。ゲーム作りを学習や創作の入口にする感覚がつかめます。「AI時代にレトロゲーム開発、が新しい。」では、Pyxelの歴史、Web対応、教育との関係、MMLなどを通して、制約のあるゲームエンジンがなぜ今も新しいのかを紹介しています。「科学とゲームの融合！サイエンティフィック・ゲームジャム東京2024」も、ゲームジャムの考え方を知る入口になります。Codexを使う場合でも、短時間で小さく作って発表するゲームジャム的な進め方は相性がよいです。

そしていよいよ次号アイキューマガジンVol.25は特集「AIゲーム開発」です

https://www.aicu.jp/post/260509