Codex のゲーム開発のためのプロンプトまとめ

以下の記事が面白かったので、簡単にまとめました。

1. ブラウザゲームの作成

1-1. はじめに

ゲーム開発は、Codexがコード生成以上の役割を果たす最も分かりやすい例の1つです。実際のゲーム開発には、通常、コンセプトの記述、レンダリングレイヤー、フロントエンドのシェル開発、バックエンドの状態管理、アセット制作、継続的なビジュアル調整が必要です。

このユースケースでは、Codexはまずゲームの動作内容を明確に記述することから始め、その後「Playwright」を使ってブラウザ上でゲームをテストするという反復的なプロセスで最大限の効果を発揮します。

1-2. スキルとプラグイン

1-3. スタータープロンプト

Use $playwright-interactive, $imagegen, and $openai-docs to plan and build a browser game in this repo.
Implement PLAN.md, and log your work under `.logs/`.

1-4. 計画からはじめる

Codex にいきなり実装を始めさせず、まずゲーム内容を具体的に定義した PLAN.md を作らせてください。その PLAN.md には、以下の項目を含めてください。

「ゲームを開発する」だけでは漠然としすぎているため、このプランは重要です。Codexはゲームの各部分をどのように実装するかを知る必要があり、開発中に実装の詳細を参照することがよくあります。

「/plan」でプランモードを起動できます。出力結果を「PLAN.md」に保存してください。

1-5. AGENTS.md で Codex の動作を制御

Codex が計画に従い、作業を検証し、適切なツールを使用するようにするには、次のような「AGENTS.md」を定義します。

# Game name

<Type of game>

Tech Stack:

- NextJS for frontend (hosted on Vercel)
- <insert technology> for rendering
- Fastify for backend, websockets (hosted on <hosting platform>)
- Postgres for database (hosted on <hosting platform>)
- Redis for caching and pub/sub (hosted on <hosting platform>)
- OpenAI for generative AI features

Tips:

- Use build and test commands to verify your work as soon as you complete a feature or task
- Use the PLAN.md file to guide your work when building new features
- Log your work under .logs (create new log files as you see fit) to record your thought process and decisions, and reference them when iterating on features
- Use playwright to test the visual output of your work, and iterate if it doesn't look right or fit the vibe
- Use imagegen to generate visual assets for your work, and every time you generate a collection of assets, save the prompts you used to be able to continue generating more of the same assets later (create files in .prompts)
- Use Context7 MCP to fetch <rendering framework> docs

これにより、Codexは長時間独立して動作し、必要に応じて関連スキルを利用できるようになります。

1-6. Codexに作業を任せて改善を繰り返す

Codexは、初期計画に基づいてゲームの最初のバージョンを生成します。

生成する必要のある画像アセットが多い場合、この最初のバージョンには時間がかかることがあり、場合によっては数時間かかることもあります。Codexは作業内容をテストし、ブラウザでゲームをテストできるため、入力なしで長時間処理を続けることができます。計画が明確であればあるほど、最初の繰り返し後の最終出力はより良いものになります。

テストを行いながら、スクリーンショットを提供したり、ゲームプレイの変更やビジュアルアセットの更新を依頼したりして、結果に満足できるまで繰り返し改善を重ねます。

2. UIの調整

2-1. はじめに

Codex を使用すると、既存のアプリで一度に小さなUI調整を1つずつ行い、ブラウザで検証し、プレビューの近くにポップアップ表示されるチャットウィンドウから迅速に反復作業を続けることができます。

2-2. スキルとプラグイン

2-3. スタータープロンプト

Make this UI change in the existing app:
[describe the exact spacing, alignment, color, copy, responsive, or component-state adjustment]

Constraints:
- Change only the files needed for this UI adjustment.
- Reuse existing components, tokens, icons, and layout patterns.
- Keep behavior, data flow, and routing unchanged unless I explicitly ask for it.
- Start or reuse the dev server, inspect the current UI in the browser, make the smallest patch, and verify the result visually.

Stop after this one change and summarize the files changed plus the browser check you ran.

2-4. モデルの選択

高速なUIイテレーションを実現するには、「gpt-5.3-codex-spark」が利用可能であれば、まずこのモデルから始めてください。汎用モデルに比べて機能は劣りますが、リアルタイムのコーディングイテレーション向けに設計されています。利用できない場合は、Reasoning負荷がMiddleまたはLowの最新のモデルを使用してください。

このトレードオフは、きめ細かなUI作業に適しています。ボタンの移動、ブレークポイントの調整、コンポーネントの状態変更などには、通常、最も高度なモデルは必要ありません。必要なのは、迅速に応答し、ローカルコードを理解し、適切なファイルを編集し、イテレーションが重く感じることなくループを繰り返せるモデルです。

2-5. 開発フロー

2-6. 簡潔なプロンプトを作成

UIプロンプトは、直接的かつ具体的であるべきです。優れたプロンプトは、対象とする画面、変更対象、そして期待される検証結果を明示します。

結果が近いものの、完全に正しくない場合は、フォローアップも同様に具体的に記述してください。

The change is close. Keep the implementation, but adjust only this detail:
[describe the remaining mismatch]

Verify the same route and viewport again before you stop.

2-7. ペースを落とすべきタイミング

タスクの粒度が小さくなってきたら、高速ループを使い続けるのはやめます。大規模なリファクタリング、新しいデザインシステムの基本要素、複雑なアクセシビリティ動作、複数の画面に影響を与える製品決定など、変更に何らかの課題が生じた場合は、より強力なモデルと、より慎重な手順に切り替えます。

高速UIイテレーションは、Codexが既に理解されているインターフェースを調整する場合に最も効果を発揮し、アプリをゼロから再設計する場合には適していません。

3. 難しいゲームロジックの改善

3-1. はじめに

タスクの中には、ビルドが成功し、テストが通れば完了と判断できるような、1回の検証で十分なものもあります。
一方で、解決が難しく、厳密な評価ループを通じて何度も反復する必要がある最適化タスクもあります。このようなタスクでは、Codex が現在の出力を検査し、評価スコアを付け、次に行う変更を判断し、結果が実際に改善されるまでこのプロセスを繰り返す必要があります。

こうしたユースケースでは、カスタム UI が非常に有効です。Codex が各反復で生成した出力や成果物をログとして記録することで、進捗を視覚的に確認できます。アプリ内で Codex が作業を続ける様子を、目標とする成果物、モデルの出力、生成されたアセットの改善状況とあわせて確認できます。
重要なのは、評価指標を算出し、検査対象となる成果物を生成するためのスクリプトを、あらかじめ Codex に提供しておくことです。

3-2. スタータープロンプト

I have a difficult task in this workspace and I want you to run it as an eval-driven improvement loop.

Before changing anything:
- Read `AGENTS.md`.
- Find the script or command that scores the current output.

Iteration loop:
- Make one focused improvement at a time.
- Re-run the eval command after each meaningful change.
- Log the scores and what changed.
- Inspect generated artifacts directly. If the output is visual, use `view_image`.
- Keep going until both the overall score and the LLM average are above 90%.

Constraints:
- Do not stop at the first acceptable result.
- Do not revert to an earlier version unless the new result is clearly worse in scores or artifacts.
- If the eval improves but is still below target, explain the bottleneck and continue.

Output:
- current best scores
- log of major iterations
- remaining risks or weak spots

3-3. 評価からはじめる

タスクを開始する前に、成功をどのように測定するかを定義してください。最適な設定は通常、以下の要素を組み合わせたものです。

主観的な要素が重要な場合は、例えばResponses APIを使用してモデルを呼び出し、構造化されたスコアを返すスクリプトをCodexに渡してください。重要なのは、決定論的チェックを置き換えることではなく、人間が目視で評価する部分を、一貫性のある評価ツールで補完することです。

ループは、評価出力が機械可読で、実行ごとに保存され、経時的に比較しやすい場合に最も効果的に機能します。

3-4. Codexに停止ルールを設定

難しいタスクは、「改善を続けてください」という指示だけで停止のタイミングが示されないため、しばしば行き詰まってしまいます。停止ルールを明確に設定します。

具体的な手順は以下のとおりです。

例えば、高品質な成果物を作成することが目標であれば、総合スコアとLLM評価者の平均スコアの両方が90%を超えるまで作業を続けるようにCodexに指示します。こうすることで、タスクの内容が明確になります。Codexは、目標値にまだ達していないか、その差はどこにあるのか、そして最新の変更が効果があったかどうかを判断できます。

3-5. ループの実行ログを継続的に記録

長時間実行される処理は、Codexがスレッドのすべてを記憶しようとするよりも、ループに関するメモを記録しておく方がはるかに信頼性が高くなります。

実行ログには、以下の項目を記録する必要があります。

これは、タスクの実行時間が長い場合に特に重要です。ログは次のセッションへの引き継ぎポイントとなり、現在のセッションの自己評価記録となります。

3-6. ログだけでなく、成果物も検証

難しいタスクの場合、コードの差分やメトリックの出力だけでは不十分です。Codexは生成された成果物を確認する必要があります。

出力が生成された画像、レイアウト、レンダリングされた状態など、視覚的なものである場合は、Codexにその成果物を直接検証させます。例えば、出力がディスク上に画像として保存されている場合、Codexは現在の結果を以前の最高結果や、意図した評価基準と比較します。

これにより、ループがより強力になります。

この組み合わせは、実行の合間にコードを盲目的に変更するよりもはるかに効果的です。

3-7. すべてのイテレーションを明確にする

Codexに毎回同じループを実行するように指示してください。

この手順は重要です。各イテレーションで一度に多くの変更を加えると、どのアイデアがスコア向上に貢献したかをCodexが判断できなくなります。ログ記録を省略すると、セッションの信頼性が低下し、再開が困難になります。

4. バグトリアージの自動化

4-1. はじめに

Codexに最近のアラート、問題、失敗したチェック、ログ、チャットレポートを確認するように依頼し、リストを1つのスレッドで調整してから、そのスキャンをスケジュールに基づいて実行します。

4-2. スキルとプラグイン

4-3. スタータープロンプト

Run a bug triage sweep for [repo/service/team] covering the last [time window].

Use these plugins: [@Sentry / @Slack / @Linear / @GitHub / none]

Input sources:
- Sentry: [project / alert link / none]
- Slack: [channel / thread links / none]
- Linear: [team / project / view / issue query / none]
- GitHub: [repo / issue query / PR checks / none]
- Other: [logs / support tickets / deploy link / dashboard / attached file / none]

Output format:
First, name any input source you could not access.
Then return a prioritized list of bugs, sorted from P0 to P3.
If you find no bugs, say: No qualifying bugs found.

For each bug, include:
- Priority: P0, P1, P2, or P3
- Title
- Evidence (links or short citations)
- Recommended next action

Rules:
- Do not post, create, assign, label, close, rerun, or edit anything.
- Group duplicate reports under one bug.
- Keep observed evidence separate from guesses.

4-4. 使用方法

Codexに、バグが既に発生している箇所（Sentryアラート、Linearイシュー、GitHubイシュー、プルリクエストチェック、デプロイログ、サポートチケット、Slackスレッドなど）をチェックさせます。まずは手動で1回スキャンを実行し、スレッド内でレポートを調整してから、スケジュール設定で実行します。
トリアージループ全体を1つのCodexスレッドで実行します。

開始する前に、Sentry、Slack、Linear、GitHubなど、Codexに必要なプラグインをインストールしてください。起動プロンプトで、括弧で囲まれたプラグインリストを実際の@プラグインチップに置き換えてください。次に、括弧で囲まれた各ソースを、検索する正確な場所に置き換えます。Sentry プロジェクトまたはアラート URL、Slack チャンネルまたはスレッド、Linear チーム、ビュー、クエリ、GitHub リポジトリ、課題クエリ、または PR チェック、デプロイ リンク、ログ ファイル、サポート キュー、またはダッシュボードです。

4-5. フェーズ1：スイープの実行

ローカルコンテキスト（テスト、リポジトリツール、ビルドチェック、CI失敗など）が役立つ場合は、バグが発生したリポジトリからCodexを起動してください。プラグイン、コネクタ、MCPサーバー、リンク、エクスポート、貼り付けログ、添付ファイルなどを通じてバグソースが利用可能な場合は、どのリポジトリからでもスイープを実行できます。

まず、上記の起動プロンプトを実行してください。スイープ対象のプラグインとソースのみを残してください。

例えば、入力済みのプロンプトには、スイープ対象とするプラグイン、キュー、チャネル、リポジトリを指定できます。

4-6. フェーズ2：レポートを役立つものにする

自動化する前に、レポートが毎日読むに値するほど役立つものであることを確認してください。

役立つ初回実行レポートには、以下の要素が含まれている必要があります。

自動化する前に、同じスレッドでレポートを調整してください。Codexに以下のことを依頼できます。

4-7. フェーズ3：自動化

オンデマンドレポートが役立つようになったら、同じスレッド内で作業を続行し、自動化プロセスを作成します。Codexは、スレッド内で調整した内容に基づいて、定期的な自動化プロンプトを作成できます。

・自動化プロセスを作成

Create a bug triage automation from the workflow we refined in this thread.

Schedule: [every hour / every weekday morning / daily]

Use the same sources, priority rules, duplicate grouping, evidence style, and P0-P3 report format from this thread.

When you write the automation prompt, include the plugin mentions or connected-source instructions the scheduled run needs to read those sources again.

Keep the automation draft-only. Do not post, create, assign, label, close, rerun, start fixes, or edit code.

Before you create it, show me the automation prompt, schedule, sources, and action policy.

4-8. フェーズ4：ルートフォローアップ

スケジュールされたレポートが役立ったら、次の作業の進め方を決定します。Codexは、チームチャンネル用のSlackアップデートの作成、追跡したいバグに関するLinear課題の作成、失敗したプルリクエストに対するGitHubコメントの作成、または担当者への引き継ぎ資料の作成などを行うことができます。

Update this bug triage automation.

After each run, draft the follow-up I need:

- Slack update for [channel]
- Linear issues for [which bugs should become issues]
- GitHub comment for [issue / PR / failing check]
- Handoff note for [team / on-call / owner]

Rules:

- Draft the follow-up in Codex first.
- Do not post to Slack, create Linear issues, or comment on GitHub until I explicitly approve that action.
- Include links to existing Linear, GitHub, Slack, or alert sources when available.
- Keep draft-only behavior for any action not explicitly approved.

5. プルリクエスト前のコードレビュー

5-1. はじめに

GitHubの「Codex code review」を使用すると、プルリクエスト上で回帰バグ、テストの欠落、ドキュメントの問題を自動的に検出できます。

5-2. スキルとプラグイン

5-3. スタータープロンプト

@codex review for security regressions, missing tests, and risky behavior changes.

5-4. 使用方法

まず、GitHub組織またはリポジトリに「Codex code review」を追加してください。詳しくは「Codex code review in GitHub」を参照してください。

Codexはすべてのプルリクエストを自動的にレビューするように設定することも、プルリクエストのコメントに「@codex review」と記述してレビューを依頼することもできます。

Codexがリグレッションや潜在的な問題を検出した場合、プルリクエストに「@codex fix it」のようにコメントを追加することで、修正を依頼できます。

これにより、問題を修正してプルリクエストを更新する新しいクラウドタスクが開始されます。

5-5. レビューガイドラインの定義

Codesのレビュー対象をカスタマイズするには、最上位の「AGENTS.md」に以下のようなセクションを追加または更新します。

## Review guidelines

- Flag typos and grammar issues as P0 issues.
- Flag potential missing documentation as P1 issues.
- Flag missing tests as P1 issues.
  ...

関連