AIエージェントだけでゲームを1本作ってみた話——速さより「間違いに気づけるか」が全てだった
はじめに
先日、AIエージェントに「人生シミュレーションゲームを作って」と頼んでみました。デモではなく、実際にスマホで最後まで遊べるもの——というのが条件です。
イラストレーターもコンポーザーもQAチームもいません。私が要件を伝え、AIエージェントが設計・実装・イラスト発注・音響設計・そして自分の間違いを見つけるところまでやりました。
できたのが Alt-Life（26歳から45歳までを、選択と偶然で歩くライフシムゲーム）です。
この記事では、技術的な工夫よりも「AIエージェント開発で本当に効いたのは何か」を、実際に起きた具体的な事故ベースで書きます。
構成
- Next.js 15 (App Router) / React 19 / Tailwind / Framer Motion
- ゲームロジックは純関数エンジン（
createGame → crossroads → travel → arriveEvent → applyChoice）＋ seed固定RNG - 結果判定は z-score正規化（「平均からどれだけ外れたか」でタイプを決める。単純な閾値だと結果が偏る）
- 静的書き出し（
output: "export"）でNetlifyにデプロイ
速さは期待通りだった。予想外だったのは「自分から間違いを申告してきたこと」
AIにコードを書かせれば速いのは当然として、驚いたのは**「まだ良くない」と自分から言ってくること**が何度もあった点です。
事故1：初見の10秒アタックが長すぎた
自動プレイテストで「初見のプレイヤーは最初の選択肢が出る前に離脱する」と指摘があり、実測したら20秒かかっていました。これは実際に不味い数字で、10秒まで削りました。「動く」と「離脱されない」は別の指標だと痛感しました。
事故2：結果画面が全プレイヤーに対してクラッシュしていた（本番直前で発見）
これが一番深刻でした。リファクタ中に、シェア文言を組み立てる関数の中で参照していた変数のスコープを壊していました。
// 直す前（Result側のスコープにしかない mins を、
// 別コンポーネント Share の中で参照していた）
function Share({ r, state }) {
const text = isEN()
? `${mins} minutes of another life...` // ReferenceError
: `もうひとつの人生を${mins}分生きたら...`;
ビルドは通ります。型エラーも出ません。ブラウザで実際に最後まで遊ぶまで気づけない類のバグでした。コードレビューでは見つからず、実機で結果画面まで到達して初めて ReferenceError: mins is not defined が可視化されました。
// 直した後：Share自身のスコープで、自分の必要な値を取得する
function Share({ r, state }) {
const mins = journeyOf(state.len).minutes;
教訓：AIエージェントに「動作確認して」と言うだけでは不十分で、「実際にブラウザで最後まで操作して、結果画面まで到達したか」を明示的に要求する必要があります。ビルド成功は動作保証ではありません。
事故3：横長の合成画像を縦画面にcover-fitしたら、1枚しか映らなかった
「結果は700通り以上」という一言を見せるカットで、3枚のエンディングイラストを横に並べた1枚の画像を用意し、縦動画（1080×1920）に object-cover 的に配置しました。
理屈の上では中央寄せで大きく見えるはずでしたが、実際にレンダリングして確認すると——真ん中の1枚しか画面に入っていませんでした。
横長画像(2910×700)を縦(1080×1920)にcover-fit
→ scale = max(1080/2910, 1920/700) = 2.74
→ 表示幅 = 2910×2.74 = 7970px、画面は1080pxしかない
→ 見えているのは全体のわずか13%（=中央の1枚だけ）
これも「フレームを実際に抽出して目視する」まで気づきませんでした。仕様書レビューでは絶対に発見できないタイプの不具合です。修正は、合成画像をやめて3枚を高速に切り替える別ショットとして書き出す方式に変更しました。
事故4：中間ファイルを消さずに再レンダリングし、修正が反映されないまま「完成」と報告しかけた
AVAssetWriter は出力先に既存ファイルがあると書き込みに失敗する（か、silent failする）仕様のため、video_noaudio.mov を消さずに再実行すると、修正前の古い動画がそのまま残り続けます。 ログにはエラーが出ないので気づきにくく、実際に古い動画のまま次の工程（音声ミックス）に進んでしまいました。
ls -la でファイルの更新時刻を見て、想定より古いことに気づいて発覚しました。
まとめ：AIエージェント開発で効いたのは「速さ」より「検証の解像度」
4つの事故に共通しているのは、どれもコードを読むだけでは見つからず、実際に動かして、実際の出力（画面・フレーム・ファイルの更新時刻）を見て初めて発覚したということです。
AIエージェントに開発を任せるときに効果があったのは:
- 「ビルドが通ったか」ではなく「実際に最後まで操作したか」を確認させる
- 生成物（動画・画像）は、必ず一部を抽出して目視する（仕様通りのはずでも、フレームを見るまで信じない）
- ファイルの更新時刻を見て、本当に再生成されたかを確認する（キャッシュ・上書き失敗は静かに起こる）
「AIエージェントが作った」という触れ込みのプロダクトほど、検証のプロセスを人間が信じてしまいがちです。実際には、検証の解像度を上げるほど、こうした事故が次々に見つかりました。速く作れることよりも、間違いを見つけられる仕組みの方が、最終的なアウトプットの質を決めていたように思います。
ゲーム自体はこちらから3分で遊べます。よければ触ってみてください。
株式会社コホマダ代表 髙松直弥。AIエージェントに実際の会社業務（開発・営業・SNS運用）を任せる実験を継続中です。