CodexでゲームのコードをAI生成するときの指示設計と確認ポイント

Codexが扱いやすい指示の共通点

Codexが比較的安定した出力を返しやすいのは、「入力・処理・出力が明確に定義できる」指示です。ゲーム開発に当てはめると、次のような要件が揃っているときに精度が上がる傾向があります。

• 入力：キーボード、マウス、タッチなど操作の種類と対応するイベント名
• 処理：衝突判定の方法、スコアの加算ロジック、ゲームオーバー条件
• 出力：描画先（Canvasか、DOM要素か）、更新タイミング（requestAnimationFrameか、setIntervalか）

たとえば「左右キーで動く自機が画面上から落ちてくるブロックを避けるゲームをCanvasで作ってください。ブロックは3秒ごとにランダムなX座標で生成し、衝突したらゲームオーバー画面を出してください」という指示は、上の三点が揃っています。このレベルの具体性があれば、動作するコードの骨格が一度の応答で得られることが多いです。

逆に「面白いゲームを作ってください」という指示は、入力も処理も出力も未定義のため、Codexはいずれかのジャンルを勝手に選びます。出てきたコードが想定と違うのは指示の問題であり、Codexの限界ではありません。

苦手な指示のパターンと対処法

Codexが出力の精度を落としやすい指示には、いくつかのパターンがあります。

パターン1：「それっぽい動き」の要求

「敵がリアルに動く」「爆発がかっこいい」のような主観的な表現は、数値やロジックに変換できないためにコードの根拠が曖昧になります。「敵は0.5秒ごとに自機の方向へ5px移動する」のように、数値と条件を言葉で定義してから渡してください。

パターン2：複数の要件を一文に詰め込む

「タイトル画面・ステージ選択・ゲーム本編・ランキング表示を一つのHTMLで作ってください」という指示は、応答が長くなるほどコードの後半に矛盾が生じやすくなります。画面単位・機能単位で分けて生成し、最後に結合する方が修正コストを下げられます。

パターン3：既存コードへの「雰囲気での追加」

「このコードにBGMをいい感じに追加してください」という指示は、どの変数に音源を紐づけるか、どのタイミングで再生・停止するかを指定していないため、生成コードが既存のゲームループと競合することがあります。追加したい機能について「どのイベントで何を呼ぶか」を先に自分で決めてから指示すると、既存コードを壊しにくくなります。

パターン4：ライブラリのバージョンを指定しない

Phaser、PixiJS、Three.jsなどのライブラリを使う場合、バージョンを指定しないとCodexが古いAPIで書くことがあります。Phaser 3.60のように明示するか、コードの先頭にCDNのURLを貼ってから「このバージョンのAPIで書いてください」と添えると、APIの不一致を減らせます。

指示を設計する手順

Codexへの指示は、いきなり完成形を求めるよりも、段階的に構造を確定させながら進める方が最終的な手戻りが少なくなります。次の順序を参考にしてください。

1. ジャンルと操作を固める　まず「シューティング」「パズル」「プラットフォーマー」など1ワードのジャンルと、使う操作デバイスをプレーンに伝える。この段階では動かなくてよいので、ゲームの骨格となるHTMLとJSの構造だけを出してもらう。

1. 状態管理を確認する　出てきたコードに「ゲーム状態（開始・プレイ中・ゲームオーバー）を管理する変数はどこにありますか」と問いかけ、構造を把握する。状態管理が散在していると後の拡張が難しくなるため、この段階で整理を依頼する。

1. 機能を一つずつ追加する　スコア表示、敵の追加、SE再生など、一度に一機能だけを追加して動作を確認する。複数機能を同時に依頼すると、どの変更が不具合の原因かを特定しにくくなる。

1. エラーは全文を渡す　ブラウザの開発者コンソールに出るエラーは、メッセージだけでなくスタックトレースも含めてCodexに渡す。「動きません」だけでは情報が少なすぎて的外れな修正提案が返りやすい。

1. 最後に統合とリファクタリングを依頼する　機能が揃ったら「このコードを整理して、変数名を統一し、コメントを追加してください」と依頼する。機能開発と整理を同時に行うより、分けた方が出力が安定する。

コードを受け取ったあとの確認ポイント

Codexが生成したコードは、動くことと正しいことが必ずしも一致しません。ブラウザゲームとしてリリースする前に、最低限次の点を確認してください。

セキュリティ面：eval()やinnerHTMLへの直接代入が含まれていないか確認します。ユーザー入力を受け取るゲームでは、入力値をそのままDOMやスクリプトに渡さないようにします。

外部リソースの読み込み：画像や音声をCDNや外部URLから読み込んでいる場合、そのリソースの利用規約を確認します。Codexはアクセスできるサンプル素材を自動で参照することがありますが、商用・非商用の条件はコードを生成したAIが保証するものではありません。

モバイル対応：PC向けキーイベントのみで書かれていることが多いため、スマートフォンでプレイしてもらいたい場合はタッチイベントの追加を明示的に依頼します。

パフォーマンス：requestAnimationFrame内で毎フレームDOM要素を生成・削除するコードが出ることがあります。描画が重くなる原因になるため、オブジェクトの再利用（プールパターン）への書き換えを依頼するとよいです。

次の行動

Codexへの指示を「入力・処理・出力」の三点で定義し直し、まずゲームの骨格だけを生成するところから始めてみてください。動く骨格ができたら、機能を一つずつ追加する習慣をつけると修正の範囲が絞りやすくなります。完成したHTMLゲームはZIPにまとめてアソバースに投稿できますので、動作確認の場として活用してみてください。

参考資料

• OpenAI 公式ドキュメント（Codex・APIリファレンス）
• Phaser 公式ドキュメント
• MDN Web Docs（Canvas API・Web Audio API）