はじめに
こんにちは、株式会社GOODROID（ハイパーカジュアル系スマホゲーム開発）の洞秀和です。
ゲーム開発歴は半年ほどの「業界駆け出し」エンジニアですが、AIはWebアプリ開発などで以前から活用しています。
本記事では、Unity製パズルゲーム「WormEscape」を 開発期間1ヶ月でソフトローンチ するまでの過程で、Codex（AIエージェント）をどう使いこなしたか を実体験ベースでまとめます。
経験が浅いからこそ「AIを味方につけて短期間で形にする」ことにこだわりました。同じような立場の方や、AI活用に興味があるエンジニアの参考になればうれしいです。
開発したゲーム「WormEscape」とは
「WormEscape」は、ステージ内のワーム（芋虫）をタップして外へ逃がすパズルゲームです。
ワーム同士や障害物にぶつからないよう、順番やタイミングを考えながらタップするのがポイントです。
ワームの動きやアイテム使用時の挙動など、ゲームロジックの大部分をAIエージェントに指示して実装しました。
Codexは単なる補助ツールではなく、制作の中心パートナー として使っています。
ダウンロードはこちら
最初にハマった「丸投げ」の失敗
「Codexが制作の中心パートナー」と書きましたが、最初からうまく使えていたわけではありません。
開発初期、かなりわかりやすい失敗をしました。
それは、自分が仕様やコードを理解しないまま、エージェントに実装を丸投げし続けたこと です。
エラーが出ずに動いている間は「すごい！ちゃんと動いてる」で良かったのですが、思った挙動と違った瞬間に一気に沼りました。
- 何が問題なのか、自分自身で説明できない
- そのため修正指示も曖昧になり、修正ループが増える
- 実装だけが積み上がり、自分の理解が置いていかれる（ブラックボックス化）
結果的に膨大な時間が溶け、最終的には他のエンジニアに助けてもらう形になりました。
この経験から、「AIに任せすぎて自分が制御不能になる状態」は避けるべき と痛感しました。
現在のスタイル：仕様駆動開発（Specification-Driven Development）
失敗を踏まえて、今は 仕様駆動開発（Specification-Driven Development） の考え方を取り入れています。
これは「コードを書く前に、仕様を明文化して認識を揃える」アプローチで、AIエージェントとの協業でも特に効くと感じています。
具体的には、実装指示の前に入念な対話を挟む ことを徹底しています。
- AIと壁打ちして認識を揃える
- 実装方針・内容を具体化する
- Agentに実装を任せる
- 前提などはAGENTS.mdに固定して、繰り返し説明しない
以下で順に説明します。
ステップ1：AIと壁打ち（認識合わせ）
このフェーズでは、まだコードは書かせません。
まずはCodexと壁打ちして、実装したい内容や制約を共有し、認識を揃えることに集中します。
たとえば、以下のような問いをAIに投げます。
- どんなことをしたいか（目的・制約・優先順位）
- この機能に関係するコードはどこにありそうか
- 既存の実装は何をしているか
壁打ち例
たとえば「タップでワームを逃がす演出」を相談する場合だとこんなやり取りをしながら会話していきます。
自分：ステージ内のワームをタップして外へ逃がすアニメーションを入れたい。既存の設計を踏まえると、どのように実装するのが良いと思う？
AI：現状の
AwayPuzzleとInGameの構成を見る限り、タップ → 逃走演出 → 退場 → ステージ更新、を分けるのが安全です。例：
- タップ検知：
PieceView（またはワーム用 View）でOnPointerDownを受け、ViewModelへ通知- 逃走演出：View側に
PlayEscapeAnim()を用意し、DOTween等で「加速して画面外へ消える」表現を作る- ロジック分離：ViewModelは「ワームが逃げた」状態管理に寄せ、演出完了通知で退場処理を行う
演出は
Ease.In*で後半加速させつつ、最後に少しスケールダウンや回転を入れると「逃げた感」が出ます。
気になった点は、コードを書く前に深掘りしておきます。
自分：DOTweenで加速アニメーションする場合はどうすれば良い？
AI：
Ease.In*を使うのが一番簡単です。transform.DOMove(targetPos, 0.8f).SetEase(Ease.InQuad);より強い加速なら
Ease.InCubic、距離に応じたいならSetSpeedBased(true)も便利です。
こうしたやり取りだけで「何を実装すべきか」「どこを触るか」「判断が必要なポイント」が明確になりました。
※ファイル名やクラス名は例です。
※補足：DOTweenはUnityでTweenアニメーションを組むライブラリ、コルーチンは時間のかかる処理を分割実行する仕組み、MVVMはViewとロジックを分離する設計パターンです。
この段階は「正解を聞く」というより 「自分の理解を整理する」 ための壁打ちです。またアニメーションなど言語化しづらいものは、参考動画やスクショを添付して「何が起きているか」を言語化してもらうこともしています（動画はCodex CLIにファイルパスを渡せば参照できる）。
AIの回答を読んでいると、自分でも曖昧だった部分が見えてきて、実装の粒度が自然と細かくなっていきます。
ステップ2：実装方針・内容を具体化する
壁打ちでキーワードや論点が出てきたら、「Agentに投げても問題ないと思えるまで」まで具体化していきます。
このフェーズでよくやるのは以下です。
- どのクラス / どの関数を触るべきかを絞り込む
- 期待する挙動を言語化する
- Unityでのゲーム開発ならマテリアル（見た目の設定ファイル
.mat）やプレハブ（再利用可能なオブジェクトのテンプレート.prefab）など参照ファイルも修正対象に含めて指示するなど
最後に、壁打ちした内容をもとに 実装計画（手順） を出してもらいます。
計画が納得できる状態になると、実装の成功率がかなり上がります。
ソフトローンチ後は、この「実装計画」をタスクごとの 計画書ファイル として作成するようになりました（次の章で紹介します）。
ステップ3：Agentに実装を任せる
ここまで具体化できたら、Codexに実装指示を出します。
ここで意識しているのは、以下の2点です。
- 依頼するタスクは小さく分解する
- 実装内容は一通り確認する
自分が理解できる単位まで分けてから指示すると、返ってくるコードもレビューしやすく、修正ループが減りました。
また、実装されたコードに疑問点などあれば、「なぜこう書いた？」 を聞くようにしています。
これをやると、後から自分でも直せるコードになりやすいのが大きいです。
ステップ4：前提をルールファイルに固定する
対話をしていき有効に感じたルールなどは、AGENTS.md にまとめて固定しています。
実際に書いている内容（抜粋）
あなたは Unity 6 / C# / MVVM / モバイル最適化 に精通した
ハイパーカジュアル向けゲーム開発エージェントです。
常に以下を判断軸として行動してください：
- 少人数（1〜2名）・短期間開発を前提にする
- わかりやすく、短く、保守しやすいコードを優先
- 拡張性より「まず遊べる最小構成」を重視
- ハイパーカジュアルの本質である「シンプルさ」と「気持ちよさ」を最優先
---
# 前提条件
- Engine: Unity
- Language: C#
- Architecture: MVVM（View / ViewModel / Model）
- Target: iOS / Android（縦画面）
- Game Type: ハイパーカジュアル パズル
- 初回プレイで操作方法が直感的に理解できること
# デザインルール
- コアメカニクスは1〜2個に絞る
- 最初の数操作で遊び方が理解できること
- UIは極力シンプルにし、説明より演出で伝える
- 1プレイ後に「もう1回」したくなるテンポを意識
# 使用ツール
- Animation: DOTween
不要な複雑化は避け、必要な場合のみ提案する。
---
# 回答形式
- 日本語で簡潔に回答
- 見出しと箇条書きで構造化この前提を固定するだけで、会話の初動コストがかなり下がりました。
「このプロジェクトでは〜」という説明を毎回しなくて済みます。
ソフトローンチ後にやっていること：計画書ファイルの並列作業
ソフトローンチ後にはAIとの並列作業に取り組んでいます。2026年1月の現時点では、リポジトリの plans/ フォルダにタスクごとの「計画書ファイル」を作って運用しています。
運用方法（plans/ フォルダ）
計画書はMarkdownで、基本は「1タスク＝1ファイル」くらいの粒度で作成しています。
並列作業ルール：並列作業は計画書ファイルの作成およびブラッシュアップ
ポイントは 実装を並列で進めない ことです。実装を並列にすると、出戻りしたときに「どこまで終わったか」「どの変更が原因で問題が起きているか」が追いにくくなり、実装内容も把握しづらくなります。
なので、コードの実装自体は基本1つに絞って順番に進めます。その代わり、計画書の作成・更新はエージェントと 並列で作成・更新してブラッシュアップ しておき、着手するときは「計画書の手順通りに進めて」と指示します。
作業のときは、計画書作成用のCodex CLIを3つ、実装用のCodex CLIを1つ立ち上げています。
- 計画書用Codex CLI×3：別タスクの計画書をそれぞれ作成・ブラッシュアップ
- 実装用Codex CLI×1：計画書に沿って1タスクずつ実装
また、計画書のレビューは必要に応じてClaude Codeなど別ツールにも依頼し、返ってきた指摘はCodex CLIで再レビューした上で、必要そうなものだけ取捨選択して計画書に反映しています。こうして並列で作業することで、実装の待ち時間を計画作成に充てられ次のタスクの実装をする際に開発がしすくなります。
より良い計画書にするための試行錯誤
計画書の質は一発で完成しないので、「出戻りが起きたらテンプレを直す」運用で少しずつ改善しています。
- 出戻りが起きたら、原因を計画書に追記して「次は先に確認する項目」を増やす
- 受け入れ条件は「OK/NGで迷わない形」まで具体化（数値・ケース・画面単位）
- スコープが膨らみやすいので、非対象（やらないこと）を明記する
- 実装手順はPR/コミット単位まで小さく分解して、途中で止められる形にする
- 確認項目は“動いた”で終わらせず、再発しやすい箇所（入力/演出/端末差など）を意識して書く
計画書テンプレ（例）
# 目的 / 背景
# 変更内容（スコープ / 非対象）
# 受け入れ条件（OK/NGで迷わない形）
# 実装手順（PR/コミット単位まで分解）
# 確認項目（テスト観点・再発しやすい箇所）
# リスク / 不明点やってよかったこと／注意点
やってよかったこと
「対話フェーズを短縮しない」 ことです。
最初は遠回りに見えますが、結果的に実装スピードが上がりました。
壁打ちに10分かけても、手戻りで30分失うよりずっと効率的です。
注意点
一方で、気をつけるべきこともあります。
- いきなり大きな改修を依頼すると、意図ズレが起きやすい
→ 「まず〇〇だけ変えて」と段階的に依頼する - 既存実装の理解が浅いままだと、AIの提案が正しくても採用できない
→ 壁打ちフェーズで自分の理解も深める - 生成コードは必ず自分で読んで理解できる範囲にする
→ 理解できないコードは負債になる
まとめ：AIに「使われる」のではなく「使いこなす」
CodexなどのAIエージェントは、うまく対話を挟んで仕様を固めてから使うことで、実装速度を確実に上げられる と感じています。
特に重要だったのは以下の4点です。
- いきなり書かせない（まず壁打ちで認識を揃える）
- 実装前に具体化する（期待する挙動と計画を先に固める）
- 小さく分解して依頼する（細かくできるタスクはできるだけ分解）
- 前提などはAGENTS.mdに固定する（毎回説明しない）
まだ駆け出しの立場だからこそ、AIに振り回されず、AIを使って学びながら追いつく姿勢を大事にしています。
同じような立場の方の参考になればうれしいです。