バイブコーディングで出すつもりが4か月：6年止まっていた個人ゲームを、複数のAIエージェントとストア公開するまでの実験記録

この記事は、個人開発のゲームを「AIエージェントにどこまで任せられるか」試した実験の記録です。
「AIを使えば誰でも簡単にゲームが作れる」と主張するものではありません。

この記事の下書きもAI（Claude Code）が、リポジトリの記録と各AIとの会話記録をもとに作りました。内容は私が確認し、手を入れています。

はじめに

2026年9月、スマホ向けゲーム「Lost Historia（ロストヒストリア）」をGoogle Playで公開しました（iOS版は審査中です）。

私は普段、エンジニアとして働いています。このゲームは2019年に一人で作り始め、6年ほど止まっていたものです。

2026年5月に再開したときの目論見は、いわゆる「バイブコーディング」で、AIに任せてさっとリリースしてしまおうというものでした。ところが、全然うまくいきませんでした。結局、公開までに4か月ほどかかっています。

見る人が見ればすぐ分かると思いますが、コード・画像・音の多くは生成AIで作っています。隠すつもりはありません。うまくいかなかった経験から、途中で進め方を組み立て直し、「個人開発で、AIエージェントにどこまで製品化の作業を任せられるか」を試す実験として進めてきました。再開から半月あまりたった6月上旬には、AI向けの作業規則に「この開発はAI製品化パイプラインの検証を兼ねる」と書き加えています。

この記事では、リポジトリの記録（コミット履歴・仕様書・作業メモ）と、各AIとの会話の記録をもとに、何をどの順で試し、何がうまくいき、何がうまくいかなかったかを時系列でまとめます。最後に、この4か月で私自身が学んだことを書きます。

先にお伝えしたいこと

• 実験です。 手法を試した記録であり、「この作り方が正しい」「人の仕事はいらない」と言うものではありません。
• 生成AIの利用に賛否があることは理解しています。 学習データの権利など、生成AIそのものが抱える問題に、この記事は答えを出せません。
• 絵・音・プログラムを仕事にしている方々の価値を否定する意図はありません。 むしろ今回、人間の目と判断が欠かせない場面を何度も経験しました。
• 最終判断と責任は人間（私）にあります。 何を作るかの決定、生成物の採否、実機での確認、ストアへの提出は私が行いました。
• 数字はgitや会話の記録から出したものです。 厳密な工数の比較ではありません。

この記事の読み方

長い記事なので、先に構成を書いておきます。

章の区切りは「開発環境がどう変わったか」です。使うAI、役割の分け方、マシンが変わった時点で章を分けています。各章は、次の順で書いています。

1. その時の開発環境（使っていたAI・モデル・マシン）
2. 環境が変わった契機
3. 起きたこと
4. その章で学んだこと

会話の引用には、必ず「誰が、誰に」言ったかを付けています。

• 私 → Antigravity のように書いたものは、作者の私がAIに送った言葉です。
• Codex → 私 のように書いたものは、AIが私に返した言葉です。

地の文の「私」は、すべて作者の私です。

ゲームの中の言葉は、「作ったもの」の節に表でまとめています。

全部読むのが大変な方は、「開発環境の変遷まとめ」「うまくいかなかったことの一覧」「おわりに」だけでも、だいたいの流れは分かるようにしています。

作ったもの

項目	内容
タイトル	Lost Historia - 放置×ラインバトル
ジャンル	放置型のレーンバトルRPG
世界観	異世界と混ざり合った現代。ゴミ箱や冷蔵庫、街路樹などが怪物（アノマリー）になった街で、ギルドマスターとして冒険者を育てる
対応	Android（公開中） / iOS（審査中）
エンジン	Axmol（cocos2d-x系のC++エンジン）
その他	アカウント連携（Google / Apple）、広告、アプリ内課金（検証用サーバーあり）

遊び方の流れは、ざっくり次のとおりです。

普段は見ているだけで進み、たまに介入する「放置寄り」の遊び方を目指しています。

記事に出てくるゲームの言葉

この記事では、ゲームの中の言葉がときどき出てきます。先に簡単にまとめておきます。

言葉	意味
インゲーム / アウトゲーム	インゲームは戦闘の画面。アウトゲームは、戦闘の外（街や施設で編成・育成する画面）
挟み込みパズル	一直線にスワイプして、両端の同じ色のパネルで間のパネルを挟んで消すパズル
属性エネルギー	パズルで消したパネルの色に応じて貯まる力。味方はこれを使って攻撃や技を出す
ウェーブ	1回の戦闘の中で、敵が何回かに分かれて出てくる、その1回分
職業	冒険者の職業。スラッガー、スナイパーなど16種類
立ち絵	キャラクターの全身の絵。攻撃の瞬間だけ、攻撃ポーズの絵に差し替える
技（スキル）	職業ごとの特別な攻撃や回復。例：スラッガーの「フルチャージブロウ」
演出	技や報酬の受け取りなどで再生する、キャラクターの動き・エフェクト・効果音。時間に沿って再生するデータ（タイムライン）をJSONで書いている
酒場	冒険者を雇う施設
鍛冶屋	装備を作ったり強化したりする施設
神殿	倒れてクリスタルになった冒険者を復活させる施設
ギルド拠点	放置で進む施設（ギルド派遣・牧場・研究所・食堂・商店・イベント広場）をまとめた拠点
ギルド派遣	待機中の冒険者をダンジョンへ送り出し、時間がたつと経験値や報酬を持ち帰る仕組み
牧場	倒した敵から手に入る「核」をかえしてモンスターを育て、通貨や素材を生み出す施設
地域・ステージ	ワールドマップ上の11の地域と、その中の戦場。ボーナスステージは、何度でも遊んで資金を稼げる特別なステージ
出撃	パーティーを決めて、戦闘に向かうこと
魔王復活	魔王城を初めてクリアした後に始まる、全プレイヤー共通の目標。各プレイヤーの勝利が1つの数値に積み上がっていく
有償通貨	お金で買うゲーム内の通貨

規模の目安（2026年9月末時点）:

項目	数
コミット数	1,218（2019〜2020年: 37 / 2026年: 1,181）
C++ソース	345ファイル・約10万行
画面レイアウトのJSON	259ファイル
開発・検証用のPythonツール	306ファイル
仕様書などのドキュメント	約300本

2026年の月別コミット数です。

月	コミット数
2026年5月（21日から）	26
2026年6月	133
2026年7月	337
2026年8月	344
2026年9月	341

開発環境の変遷まとめ

先に、この記事全体の流れを表にしておきます。

章	時期	主に使ったAI	役割の分け方	マシン	変わった契機
序章	2019〜2020年	なし	全部自分	—	—
第1章	2025年10月〜2026年5月上旬	Codex、Gemini CLI、Antigravity、Copilot	試しながら	M4 Mac → DGX Sparkを追加	画像生成を大量に回したい
第2章	2026年5月21日〜31日	Antigravity（Gemini 3.5 Flash / Gemini 3.1 Pro / Claude Sonnet 4.6）、ローカルLLM（Qwen3.6 27B）	Antigravityが仕様、ローカルLLMが実装	M4 Mac＋DGX Spark	トークンがすぐ尽きる
第3章	6月	Codex、Claude Code、Antigravity（＋レビューにCopilot・ChatGPT）	UIはCodex、それ以外はClaude Code、絵はAntigravity	同上。DGX SparkはSSHで作業させる	各社の得意分野が見えてきた
第4章	7月	同上（Claude Codeの主力はSonnet 5に）	同上。確認を機械に任せる	ビルド専用機（MacBook Air・Windowsミニ機）を追加	AIの「できました」を信じ切れない
第5章	8月	同上（Codexを上位プランへ）	Antigravityはメモとレビュー、作業はClaude Code	DGX Sparkが過負荷に	並行作業が混ざり始めた
第6章	9月	Codexの利用が急増、Claude CodeはOpus 5.5へ	Codexの利用上限中はClaude Codeが代行	同上	ストア提出

AIとの付き合い方の「仕組み」も、失敗するたびに1つずつ積み上がっていきました。矢印に書いたのが、次の仕組みを作るきっかけになった失敗です。

序章：2019〜2020年、手作業の時代

その時の開発環境

• エンジン：cocos2d-x（C++）
• AI：なし。すべて自分で書いていました。

起きたこと

2019年5月3日の「最初のコミット」から始まり、2020年2月までに37回コミットしています。当時のコミットメッセージを並べると、手探りで作っていた様子が分かります。

2019-05-03 最初のコミット
2019-05-04 敵と味方の仮配置
2019-05-10 パズルのルールを変更
2019-05-12 ボムの動きまで完成
2019-05-17 消えた分だけエネルギーが貯まるようにする
2019-06-21 ゲームデータ管理
2019-10-25 職業の定数を追加
2019-10-28 思考の処理
2019-10-31 ダメージ表示の決定
2019-11-06 Spineの下地
2020-02-01 iOSビルドが通るようにした
2020-02-04 バナー広告を出せるようにする

「パズルで消した分だけエネルギーが貯まり、それで戦う」という骨組みは、この時点でできていました。この骨組みは、2026年版にもそのまま残っています。

ただ、ここで手が止まり、そのまま約6年間、手を付けませんでした。

この章で学んだこと

学んだことというより、この時の記録が後で役に立ちました。2026年に再開したとき、AIに「このリポジトリは何をしようとしていたか」を読み取らせる材料になったのは、6年前の自分のコミットでした。

第1章 助走：AIツールを試していた時期（2025年10月〜2026年5月上旬）

Lost Historiaを再開する前に、私は半年ほど、いろいろなAIツールを別の小さな開発で試していました。この章は、その助走期間の話です。

その時の開発環境

時期	使っていたもの	何をしたか
2025年10月	VSCode＋Codex、Gemini CLI	趣味の朗読アプリ（VOICEVOXで配役をAIに任せる）
2026年1月〜	Antigravity	使い始め
2026年3月	Antigravity、Codex、Copilot、Gemini、ChatGPT	Godot 4＋C++でビリヤードやミステリーゲームの試作
2026年3月	Antigravity	10年前のcocos2d-x作品をAxmolへ移植する練習
2026年4月〜	M4 Mac（メモリ16GB）→ DGX Spark	ローカルでのゲーム素材の画像生成

契約の話

当時は、どのAIが一番賢いのか、まだ誰にも分からない、競争の激しい時期でした。各社のAIの特徴をつかむために、順番に契約していきました。

最初に契約していたのは、ChatGPT（Codex）と、Google AI Pro（Antigravity / Gemini）です。GitHub Copilotは、GitHubアカウントの支払いで使える月10ドルのプランでした。Claude Codeは、この時点ではまだ使っていません（第3章で追加します）。

起きたこと

最初はCodexで小さなアプリを作った（2025年10月）

最初にAIと本格的に作ったのは、ゲームではなく、文章を朗読するアプリでした。VSCodeにCodexの拡張機能を入れて、対話しながら作りました。

• 公式の拡張機能を使うと、APIの従量課金ではなく、契約中のプランの範囲で使えました。
• 一方で、「読み上げにGeminiも選べるようにしたい」と頼んだところで、3〜4時間はまりました。

この時の記録は、Qiitaに書いています。

• VSCodeに連携したCodexを使って趣味のVOICEVOXでの文章朗読アプリ(AIによる配役)を作ってみた

複数のAIを並べて使ってみた（2026年3月）

次に、Godot 4＋C++（GDExtension）で小さなゲームを作りながら、複数のAIを役割を分けて使ってみました。

AI	その時の役割
Gemini	アイデア出し、次にやることの提案
Antigravity	設計・実装・テスト
Copilot	細かい実装や、ピンポイントの修正
ChatGPT	コードの評価（設計は正しいか、もっと良い書き方はないか）

M4 Mac特有のビルドの問題（物理エンジンのJoltが最新CPU向けの最適化オプションで落ちる）に当たるなど、AIがいても環境の問題には人間が付き合う必要がありました。

• Godot 4 + C++ (GDExtension) で挑む！Jolt Physics を使ったビリヤード開発記
• AIエージェントと作る！Godot 4 + GDExtension(C++)による2Dミステリーゲーム開発記

古いcocos2d-x作品をAxmolへ移植する練習（2026年3月）

Lost Historiaは2019年のcocos2d-xで作られていたので、そのままでは今の開発環境で動きません。そこで、まず別の古いcocos2d-x作品を、後継エンジンのAxmolへ移植する練習をしました。

この練習のおかげで、Lost Historiaを再開したときは、エンジンの移行を初日から翌日のうちに済ませられました。

• 10年前の Cocos2d-x プロジェクトを最新の Axmol Engine へ移植して Xcode で起動するまで

DGX Sparkを買った（2026年4月）

ここが、この章で一番大きな環境の変化です。

NVIDIA DGX Spark（GB10）のOEM機を、約60万円で購入しました。 理由は2つあります。

1. ゲームでは画像を大量に作る必要が出てくる。 クラウドの画像生成は、使える回数に制限がかかります。それを見据えて、自分の手元で好きなだけ回せる環境が欲しかった。
2. ローカルLLMを使えば、AIの利用料を節約できるかもしれない。 AI専用のPCがあれば、クラウドのAIに払うお金を減らせるのでは、と考えました。

それまで使っていたM4 Mac（メモリ16GB）では、画像生成で高解像度化の処理を動かした瞬間にメモリ不足で止まる状態でした。DGX Sparkは128GBのメモリを持っていて、大きなモデルも手元で動かせます。

結果から書くと、

• 1つ目は当たりました。画像生成、画像の部分修正、3Dモデル生成、画面チェック用のVLMなど、この後の4か月でずっと働いてくれています。
• 2つ目は外れました。やりたいことが増えすぎて、AIの利用料は増える一方でした（費用の話は後の章でまとめます）。

ちなみに、同じ機種は今では約90万円に値上がりしているので、買うタイミングとしては良かったと思っています。

ローカルでの画像の量産は失敗した（2026年4月〜5月）

DGX Sparkを使って、「ゲームのキャラクター素材を、ほぼ自動で量産する仕組み」を作ろうとしました。

• Stable Diffusion系のモデルを動かし、LoRA（キャラクター専用の追加学習）も自作しました。
• 生成した画像をVLM（画像を見て判断するAI）に審査させ、ダメならプロンプトを直して作り直す、というループも組みました。

しかし、これは頓挫しました。1枚のキャラクター画像には、髪の色、瞳の色、服の模様、小物、ポーズ…と、仕様が多すぎます。プロンプトに詰め込もうとすると、1つを安定させると別の1つが崩れる、ということを繰り返しました。

このときの結論は、「AIの性能が低いからではなく、絵というものが持っている仕様の多さを甘く見ていた」でした。この「伝える情報の量」の問題は、この後、ゲーム開発全体で何度も出てきます。

• M4 Mac から Blackwell ASUS Ascent GX10 へ：自律アセット生成パイプラインの進化と挫折の記録
• AI画像生成でゲームアセット量産が失敗する理由：絵には仕様が多すぎる

この章で学んだこと

• 普段やらない技術の勉強になる。 Godot、物理エンジン、Axmolへの移植、画像生成モデル、LoRA、VLM。業務では触れない技術ばかりでした。
• 伝える情報が足りないと、AIは埋め合わせで勝手なものを作る。 画像生成での失敗は、後から振り返ると、この記事全体のテーマの入り口でした。

第2章 バイブコーディング期：Antigravity 1本でとにかく作る（2026年5月21日〜31日）

その時の開発環境

項目	内容
メインのAI	Antigravity
モデル	Gemini 3.5 Flash、Gemini 3.1 Pro、Claude Sonnet 4.6 を切り替えながら
実装の担当（5月23日〜）	ローカルLLM（Qwen3.6 27B）を、RooCode経由でDGX Spark上で動かす
マシン	M4 Mac＋DGX Spark
契約	ChatGPT（Codex）、Google AI Pro、Copilot

Antigravityの中では、1日に何度もモデルを切り替えていました。会話記録には「Gemini 3.5 Flash → Claude Sonnet 4.6 → Gemini 3.5 Flash → …」という切り替えが、10日間で数十回残っています。どのモデルが何に向いているのか、まだ手探りでした。

起きたこと

初日：「そもそもゲームの中身が決まってない」

2026年5月21日、私は開発を再開しました。

作業を始めると、Antigravityはまず、既存のコードをもとにした実装計画を出してきました。私はそれに、こう返しています。

私 → Antigravity（5月21日）

いやそもそもゲームの中身が決まってないので、ゲーム設計からです。

実は私は、ゲームの中身をほとんど決めずに再開していました。そこから、私がチャットで思いつくままに仕様を伝えていきました。初日に私が送った言葉の一部です。

私 → Antigravity（5月21日）

パズルのルールは挟み込みパズルを基本にする。バトルシステムは、パズルで貯めた属性エネルギーを使い最大4人のパーティーメンバーが自動で攻撃やスキルを発動するリアルタイムバトル

私 → Antigravity（5月21日）

バトルシステムは、ウェーブ制にして、可変ウェーブで、3ウェーブ後に中ボス、5ウェーブ後に大ボス

私 → Antigravity（5月21日）

ワールドマップがあり、マップのオブジェクトをタップすることで、ダンジョン、街、神殿などに入れる

同じ日に、エンジンのAxmolへの移行も頼み、タイトル画面の絵も生成してもらいました。タイトル画面は「魔王が小さすぎる」「プレイヤーが浮いている」「背景と手前を分けて」と何度も直しています。

最初の2日間は、確かに速かった

5月22日のコミットを並べると、バイブコーディングの手応えが分かります。

2026-05-22 feat: add attribute energy gauge bar between battle and puzzle area
2026-05-22 feat: full-width battle area, wave display, Mochiy Pop One font
2026-05-22 feat: オートプレイ機能(AUTO: ON/OFF切り替え)の実装および動作検証完了、
           BMFont廃止に伴うTTFへの完全移行とコードクリーンアップ

戦闘エリアの横幅対応、ウェーブ表示、フォントの変更、オートプレイ。言えば、その日のうちに形になりました。「このまま行けば、すぐ出せる」と思っていました。

トークンがすぐ尽きる → 実装をローカルLLMへ（5月23日）

速い代わりに、すぐにトークン（AIが使える量）を使い切りました。 そこで、第1章で買ったDGX Sparkの出番です。5月23日、Antigravityにこう伝えています。

私 → Antigravity（5月23日）

実装は、qwen3.6 27Bに対応してもらうことになりました。あなたは、実装するために仕様を決める人になってください。

役割をこう分けました。

担当	役割
Antigravity	仕様を決める人（設計・壁打ち）
ローカルLLM（Qwen3.6 27B、RooCode経由）	実装する人

実装のためのツールは、AiderとRooCodeで迷い、最終的にRooCodeにしました。高い精度が必要な「考える仕事」はクラウドのAIに、量の多い「書く仕事」は手元のAIに、という狙いです。

仕様が決まる前に、AIが実装を始めてしまう

この時期、一番困ったのは、仕様を話し合っている最中に、AIが勝手に実装を始めたり、「完了しました」と言って終わったりすることでした。

私 → Antigravity（5月25日）

イヤイヤ、まだ仕様決まってないよ。勝手に終わらないで

そこで5月25日、私はAntigravityにこう頼みました。

私 → Antigravity（5月25日）

geminiのモデルの時に勝手に実装を進めようとするので、AGENTS.mdに仕様の状態とタスクの状況を確認してから実装判断に移行すると明記しておきたい

これが、このプロジェクトの**AI向け作業規則（AGENTS.md）**の始まりです。5月26日に最初の版をコミットしました。今の規則ファイルの冒頭は、この時の考え方がそのまま残っています。

## 🔴 最重要ルール：実装前の必須確認手順

**いかなる実装（コード追加・変更・削除）も、以下の手順を経ずに開始してはならない。**

### STEP 1 — 仕様書の状態を確認する
実装対象の機能に対応する仕様書が存在し、かつ「仕様確定済み」であることを確認する。

**仕様書が存在しない・内容が不完全・「TODO」「未定」の記載がある場合 →
実装を中断し、プランナー（ユーザー）へ仕様の確定を求めること。**

### STEP 2 — タスクリストの状態を確認する
- **「未着手」「保留」「仕様検討中」ステータスのタスクは実装してはならない。**

流れにすると、次のようになります（今の規則ファイルの形です）。

AIに「待て」を教えるのに、ルールを文章にして毎回読ませる必要がありました。人間相手なら「まだだよ」の一言で済むことです。

実装が、仕様の穴を勝手に埋めていた（5月27日）

ローカルLLMに実装を任せて数日たった5月27日、私はAntigravityにこう頼んでいます。

私 → Antigravity（5月27日）

0〜8までの中で仕様と乖離してないか、あるいは、仕様不足で勝手に補填した実装があれば、仕様書に記載か改善するか判断したい。まずはチェックして、問題点の箇条書きをしてほしい

実装するAIは、仕様に書いていないところを、黙って「それっぽく」埋めていました。動くけれど、誰も決めていない仕様が、コードの中にだけ存在する状態です。

ここから、「実装で決めたことは、必ず仕様書にも書き戻す」というルールが加わりました。後に規則ファイルの「コードを変えたら仕様書も同時に直す」になります。

ローカルLLMが止まる（5月26日〜29日）

ローカルLLMでの実装は、長くは続きませんでした。

• 5月26日：会話が長くなると応答が遅くなり、会話をリセットして回復。
• 5月28日：RooCodeの応答が止まる。
• 5月29日：RooCodeのアップデートでバグが出て、復旧に時間がかかることが分かる。

5月29日の朝、私はAntigravityにこう頼んでいます。

私 → Antigravity（5月29日）

本来実装はRooCodeに任せたいが、フリーズしてしまって動かない、現状の進捗を把握し、代わりにタスクを進めてくれ。これは一時的な対応だ。

結果として、この「一時的な対応」がそのまま続き、ローカルLLMで実装する体制はここで終わりました。ローカルLLMは、この後「画面をチェックする目」として別の役割で生き残ります（第3章）。

「成功」と言ったのに、違う画像だった（5月29日）

UIの作業で、AIが「確認してsuccess（成功）」と報告してきたスクリーンショットが、明らかに違う画面だったことがあります。

私 → Antigravity（5月29日）

ねぇ、これ確認してsuccessで通したの？どうみても違う画像だけど

AIの「確認しました」「成功しました」は、そのまま信じられない。この経験が、後の「確認を機械に任せる」仕組み（第4章）につながります。

UIは自作のエディタとJSONで作る方針に（5月28日〜31日）

画面のレイアウトを、C++のコードに座標を直接書くのではなく、JSONで定義して読み込む方式にしました。JSONを編集・確認するための自作のUIエディタとビューアーも、AIに作ってもらいました。

ただ、ここでもつまずいています。

• エディタで保存して読み直すと、レイヤー構造が崩れる。
• 保存すると、各要素の名前が勝手に初期値に戻る。
• 縦画面は正しいのに、横画面のレイアウトが崩れる。

5月30日には、私はAntigravityにこんな質問もしています。

私 → Antigravity（5月30日）

Antigravityが UIの設計を失敗しているのは、目の役割のVLMが弱いからですか？

AIは画面を「見て」確かめるのが苦手で、JSONの数字だけで配置を決めると、見た目が崩れていても気づけません。この問題は、最後の9月まで形を変えて続きました。

消したはずのルールが残っている（5月21日・6月1日）

別のプロジェクト用のルールが、このプロジェクトに紛れ込んでいたこともありました。初日に私は、

私 → Antigravity（5月21日）

いや、画像生成は［DGX Spark］を使わずnanobananaで生成できないかこのルールはこのプロジェクトのルールじゃないはずだ

と伝えています。nanobananaは、Googleのクラウドの画像生成AI（Nano Banana）のことです。引用中の［ ］は、機種名を記事の表記にそろえたものです。さらに6月1日には、「DGX Sparkが届くまでM4 Macでの画像生成は禁止」という、もう役目を終えたルールがまだ残っていました。

私 → Antigravity（6月1日）

おい、以前（中略）のルールは消せって伝えて、消したんじゃないのか

AIに渡すルールは、書いたら終わりではなく、古くなったら消す手入れが必要でした。

10日間で作ったもの

5月の10日間で、次のものができました。

• ゲームの基本仕様（パズル、バトル、施設、課金の考え方）
• ギルド拠点と、放置系の施設6つ（派遣、牧場、研究所、食堂、商店、イベント広場）の骨組み
• 課金画面の骨組み
• ソースコードのMVC構成への整理
• 全画面のレイアウトJSON（ただし、この後何度も作り直すことになります）

量だけ見ると、確かに進みました。ただ、ここで作ったものの多くは、この後の4か月で作り直すことになります。

この章で学んだこと

• 詳細を端折らずに伝える。 「ゲームの中身が決まってない」状態で始めたので、AIは空白を自分で埋めて進みました。人間のチームでも、仕様が決まらないまま手を動かせば同じことが起きます。
• 記録の大切さ。 「待て」「仕様書に書き戻せ」を毎回口で言う代わりに、規則ファイルに書いて毎回読ませるようにしました。
• 速さと引き換えのものがある。 最初の2日間の速さは本物でした。ただ、その速さは「決めていないことをAIが決めてくれる」ことから来ていて、後で必ず手戻りになりました。

第3章 複数AIの分業期：得意分野で担当を分ける（2026年6月）

その時の開発環境

項目	内容
UIの実装	Codex
UI以外の実装（戦闘ロジック、敵や味方の動き、ツール、レビュー）	Claude Code（6月10日に追加）
絵・3D・素材の研究	Antigravity
レビュー役	Copilot、ChatGPT、ほかのAI同士
ローカルAI	DGX Spark：画面チェック用のVLM、画像生成、3Dモデル生成。SSHで作業を任せる
契約	ChatGPT（Codex）、Google AI Pro、Copilot、Claude Code（年間220ドルのプラン）を追加

環境が変わった契機

Codexが実装に加わる（6月2日〜）

6月2日の会話記録から、Codexの作業が本格的に出てきます。

私 → Antigravity（6月2日）

codex君がui_layout_draft.mdを作ったので確認だけしてください。

私 → Antigravity（6月2日）

codexがgamesceneを変更したみたいなので、仕様書とともにチェックして欲しいです。実装もされてるが、途中でリミットが来てしまったので中途半端に実装していないか確認もしてほしい

ここで早くも「利用上限（リミット）」が出てきます。上限で作業が途中で止まり、別のAIに「中途半端になっていないか」を確認させる、という流れは、この後も何度も繰り返しました。

6月5日には、私はCodexに、Antigravityの実装計画をレビューさせています。Codexからは、こんな指摘が返ってきました。

Codex → 私（6月5日、Antigravityの計画へのレビュー）

Antigravityの計画は、先頭ではChatGPTの提案を反映できていますが、implementation_plan.md全体としてはまだ危険です。理由は「最新MVP方針」と「過去の全機能実装計画」が同じ文書内に混在しているためです。

AIが書いた計画を、別のAIが読んで「古い方針と新しい方針が混ざっている」と指摘する。人間のチームでよくあるレビューの形が、AI同士でも成り立ちました。

同じ日に、私はこう書いています。

私 → Antigravity（6月5日）

Antigravityの得意分野と、codexの得意分野は違うと思うが、実装面はcodexの方が頼りになる。画像作成など、アセットの作成はAntigravityの方が良い

Claude Codeを追加（6月10日）

この時点で契約していたのは、ChatGPT（Codex）とGoogle AI Pro（Antigravity）だけでした。どちらもすぐにトークンが枯渇するうえ、ほかの会社のAIも試してみたかったので、6月10日にClaude Codeを追加しました。

Claude Codeに最初のころ頼んでいたのは、ゲーム本体ではなく、敵キャラクターをSpineや3Dモデルで動かす実験でした（後述）。

担当を文書にする（6月12日〜16日）

AIが3つになると、同じファイルを別々のAIが直してぶつかる、ということが起き始めます。そこで6月12日に、担当範囲を文書にしました（docs/ai_agent_ownership.md）。文書の最初に、理由をこう書いています。

担当表の文書（docs/ai_agent_ownership.md）より

AIは会話履歴や作業文脈の継続性が弱い。そのため、担当範囲は口頭ではなく、タスクチケットと本ドキュメントに残す。

担当の表は、次のとおりです（抜粋）。

担当ID	主担当	主な責務
Codex-UI	Codex	画面の実装、UIレイアウトのJSON、HUD・ゲージ・ボタン・ダイアログ
Claude-Code	Claude Code	UI以外の実装全般（敵や味方の動き、戦闘演出のロジック、素材パイプラインの接続、ドキュメント整理、レビュー）
Antigravity-Art	Antigravity	AIアート、敵のコンセプト画像、3D生成の評価、素材生成の研究
Claude-Review	Claudeなど	コードレビュー、設計レビュー、品質の観点の洗い出し
Planner-Human	私	仕様決定、優先順位、最終の採否判断

図にすると、次のとおりです。矢印の「担当: …」が、タスク表の各行に書く担当IDです。

さらに、タスク表の各行に「担当: Codex-UI」のように書き、担当が書かれていないタスクには、どのAIも手を付けないというルールにしました。6月16日には、私からClaude Codeにも「UIはCodexに任せるので、そこ以外を担当してほしい」と伝えています。

ローカルLLMは「書く係」から「見る係」へ

5月に実装係として使ったローカルLLMは、6月から役割が変わりました。画面のスクリーンショットを見て、崩れがないかを判定する**VLM（画像を見て判断するAI）**としての役割です。

私 → Antigravity（6月6日）

いや、geminiじゃなくて、qwenなどのローカルLLMのVLM特化型にやらせて

私 → Antigravity（6月8日）

別のLLMで同じことができるか知るために、qwenのVLMに同じチェックをさせたら同じ結果が出るか知りたい

画面チェックは回数が多いので、クラウドのAIで回すとすぐに上限に届きます。手元のDGX Sparkで回せば、回数を気にせずに済みます。DGX Sparkを買った2つ目の理由（費用の節約）が、ここで少しだけ生きました。

また、DGX Sparkの前に私が座らなくても作業が進むように、私はAIにSSHで接続させて、DGX Spark上の作業を任せるようにしました。

私 → Antigravity（6月18日）

［DGX Spark］は直接さわれないので、SSHで代わりにやってくれませんか

起きたこと

敵を動かしたい：Spine → 3D → 凍結

この月に一番時間を使ったのは、「1枚絵の敵キャラクターを、どうやって動かすか」でした。

1. Spine（2Dのボーンアニメーション）の自動化を試す

1枚絵をAIで部位ごとに切り分けて、Spineのデータにする仕組みを作りました。部位の切り分けにはDGX Spark上のセグメンテーションモデルを使っています。ゴブリン1体はSpineの書き出しまで通りました。

しかし、VLMで見た目を評価すると、1枚絵には「腕の後ろに隠れている体」などの情報が存在しないため、部位を動かすと穴が開きます。手で直す量も多く、6月11日に凍結しました。

• ゲーム開発で1枚絵の敵キャラをAIで自動分割・Spineアニメ化しようとして限界を感じ、3Dに方針転換した話

2. 3Dモデルにして動かす

次に、1枚絵から3Dモデルを作り、骨を入れて動かし、2Dの連番画像に焼き出す方法を試しました。これはClaude Codeの最初の大きな仕事です。

• 3Dモデル生成は、Hunyuan3Dでうまくいかず、TRELLIS.2に切り替えて成功しました（6月12日）。

• ゴブリン1体を、実際のゲームの森ステージで動かすところまで行きました（6月13日）。

• 骨の配置を「予想 → 配置 → 評価 → 修正」のループで自動で直す仕組みも作りました（6月14日）。

• ローカル3D生成の覇権交代？Hunyuan3Dを諦めてMicrosoftの「Trellis.2 4B」に乗り換えた話

ここで、この記事の最後に書く「知識の破片」の話が1つ出てきます。3Dモデルを曲げると、表面が砂のように崩れる問題が起きました。AIは、モデル全体を作り直す重い方法（ボクセルリメッシュ）を試していましたが、細かい部分が潰れて穴が開きます。そこで私が聞きました。

私 → Claude Code（6月15日）

remeshって近くのポイントを纏めて、纏めた部分のUVとポイントを削除するやり方では？

実際に必要だったのは、近い頂点を溶接する処理（Blenderの「Merge by Distance」）でした。テクスチャもそのまま残り、穴も開きません。私は3Dの専門家ではありません。ただ「そういう処理があるはず」という知識の破片が、AIの向かう方向を変えました。

3. 凍結

それでも、ひじやひざを深く曲げると、関節の継ぎ目がゴムのように伸びる問題が消えませんでした。6月15日、私は「今の技術だと無理だ」と判断して、3Dで動かす方法を凍結しました。翌日、私はClaude Codeにこう伝えています。

私 → Claude Code（6月16日）

仕方ないので静止画前提でこのゲームは作っていきましょう

敵は静止画のまま、揺れ・突進・ノックバック・点滅などのプログラム演出で動きを出すことにしました。結果的に、当時の敵127体のうち126体はもともと静止画で動いていたので、ゲーム本体はほとんど壊れずに済みました。

凍結したものの、作った仕組みは捨てていません。骨の自動配置やメッシュの前処理は、再開するときにそのまま使えるように記録を残してあります。

エフェクトは「絵だけAI、動きはデータ」（6月16日）

スキルのエフェクトも同じ時期に方針を決めました。

• 動画生成AIでエフェクトを作る方法は、時間の流れが崩れやすく、重いため採用しませんでした。
• 代わりに、魔法陣・オーラ・光の柱・パーティクルなどの「部品」を、JSONのレシピで時間順に組み合わせる仕組みを作りました。絵（テクスチャ）だけをAIやプログラムで作ります。

レシピは、こんな形です（抜粋）。

{
  "id": "skill_holy_circle",
  "duration": 1.6,
  "anchor": "feet",
  "layers": [
    { "type": "magic_circle", "at": 0.0, "duration": 1.4,
      "params": { "radius": 110, "rotSpeed": 120, "tiltDeg": 62, "blend": "add" } },
    { "type": "aura_column",  "at": 0.2, "duration": 1.0,
      "params": { "rate": 120, "speed": 220, "life": 0.8, "blend": "add" } },
    { "type": "light_pillar", "at": 0.3, "duration": 1.0,
      "params": { "height": 340, "width": 90, "blend": "add" } }
  ]
}

昔のcocos2d-xには、CocosStudioやCocosBuilderという演出を作るツールがありましたが、もう開発が終わっています。その代わりになるものを、自分で作ることになりました。数字で書いたレシピなら、AIにも「魔法陣の傾きを62度に」「0.3秒後に光の柱」と、正確に伝えられます。

立ち絵16枚の描き直し（6月17日）

味方の冒険者は16種類の職業があり、それぞれ立ち絵を用意していました。1枚ずつ見ると悪くないのですが、並べると画風がバラバラでした。ある職業はすっきりしたドット絵風、別の職業は描き込みの多い絵、という具合です。

原因は、描いてもらうときに「画風をそろえる条件」を伝えていなかったことでした。そこで、条件をまとめた作画指示書を作り、描き直してもらいました。

項目	指示
タッチ	16職で統一
頭身	6.5〜7頭身
光源	左上
体の向き	右向きの半身
サイズ	1024px
足元	足元の高さ（ベースライン）をそろえる
背景	透過。影を絵に焼き込まない

第1章の「絵には仕様が多すぎる」と同じ話です。言わなかったことは、AIが毎回ちがう形で埋めてきます。

制作のルールが増えていく（6月19日〜26日）

この月の後半は、4か月の土台になるルールや仕組みが次々にできました。

日付	できたもの
6月19日	アカウント（Firebase Authentication）とサーバーの設計
6月24日	素材置き場（Content/）の配置規約と、違反を検出するチェッカー
6月24日	自動テスト（E2E）の整備
6月26日	効果音の生成環境（AudioCraft）。日本語の指示をローカルLLMで英語に訳してから生成する

利用上限でCodexが止まる（6月24日〜26日）

6月24日、Codexが利用上限に達し、26日の17時まで使えなくなりました。この間は、UIの作業もClaude Codeが代わりに担当しました。担当表のおかげで、「どこまでが一時的な代行か」をはっきり書き残せました。

この章で学んだこと

• 作業の流れで、何が効率化になるかを探す訓練になった。 どのAIに何を任せるかを、実際に使いながら決めていきました。人を配置するのと似ていますが、AIは会話が変わると前のことを忘れるので、全部を文書にする必要がありました。
• 技術の深さより、知識の破片が効く。 3Dの継ぎ目の問題で、専門知識がなくても「近い頂点をまとめる処理があるはず」という一言が、AIの方向を変えました。
• 詳細を端折らずに伝える。 立ち絵の画風は、条件を表にして渡すまでそろいませんでした。

第4章 検証の自動化期：「できました」を機械で確かめる（2026年7月）

その時の開発環境

項目	内容
AIの分担	6月と同じ（UIはCodex、それ以外はClaude Code、絵はAntigravity）
Claude Codeのモデル	Opus 4.8 → Sonnet 4.6 → Fable 5 と移り、7月3日からは Sonnet 5 が主力に
ローカルAI	DGX Spark：画面チェック用のVLM（Ollama＋Qwen系のVLM）
追加したマシン	ビルド専用機（MacBook Air）とWindowsのミニPCを、GitHub Actionsのセルフホストランナーに
配信	Firebase App Distributionでテスト版を配る

モデルの移り変わりは、コミットに付いている共同作成者の記載（Co-Authored-By）から読み取れます。

モデル（Claude Code）	記載があった期間	件数
Claude Opus 4.8	6月19日〜6月26日	27
Claude Sonnet 4.6	6月30日〜7月1日	12
Claude Fable 5	7月2日〜7月8日	24
Claude Sonnet 5	7月3日〜9月25日	401
Claude Opus 5	9月13日〜9月14日	3
Claude Opus 5.5	9月25日〜	49

環境が変わった契機

第2章の「成功と言ったのに違う画像だった」のように、AIの「確認しました」「完了しました」は、そのままでは信じられません。しかし、毎回私が画面を開いて確かめていては、AIに任せる意味が薄れます。

そこで7月は、確認そのものを機械に任せる仕組みを増やしました。規則ファイルには、6月上旬に次のルールを加えていました。7月は、このルールを実際に回せるように道具をそろえた月です。

### AIパイプライン・自動検証ルール
実装タスク（UIやロジック変更）を行う場合、**「1タスク ＝ 1機能 ＝ 1自動検証」** の原則を必ず守ってください。

1. 明確な完了条件を持つタスクのみを実行し、推測で勝手に仕様を膨らませない。
2. C++やJSONを変更した場合、必ずコマンドラインでビルドを実行し、成功させること。
3. UIや画面レイアウトの変更を行った場合、必ず対象画面のスクリーンショットを撮影し、
   VLMチェックスクリプトを用いて「画面崩れがないか」「ボタンがはみ出ていないか」を自動目視確認すること。

7月に整えた確認の流れは、次のとおりです。点線は、ダメだったときにAIが直しに戻る流れです。

起きたこと

E2Eテストと、安全な画面撮影

ゲームを決まった画面から起動し、決まった操作をして、画面を保存する。この「E2Eスモークテスト」を、画面ごとに設定ファイル1つで回せるようにしました。

画面の保存は、OSの画面撮影機能ではなく、ゲーム自身に保存させる方式にしました。OSの機能だと、ゲーム以外のウィンドウが写り込むおそれがあるからです。AIが自分でスクリーンショットを撮るようになると、この手の事故は人間が見ていないところで起きます。

AIが迷わずにこれらの道具を使えるように、7月15日に「開発ツールの使い方ガイド」も書きました（起動の方法、安全な撮影、ビューアー、Androidでの確認手順）。道具を作っても、使い方を書いておかないと、次の会話のAIは知らないまま別の方法を試し始めます。

VLMで画面をチェックする

保存した画面を、DGX Spark上のVLMに見せて「崩れていないか」「ボタンがはみ出していないか」を判定させました。

使ってみて分かったことがあります。

• 同じ画像を何度か判定させると、結果が変わることがある。設定で揺らぎ（temperature）を0にしても、完全には安定しない。
• 1文の要約に収まらない複数の問題を、取りこぼす。
• 「ボタンがはみ出している」のような、はっきりした問題は見つけやすい。
• 「この画面は世界観に合っているか」のような印象の問題は、判定がぶれる。

特に最後の点は、UIのトーン＆マナー（見た目の統一感）の話でした。VLMにローカルLLMを組み合わせて、UIのJSONを自動で直すループも試しましたが、うまくいきませんでした。このときの私の結論です。

私 → Claude Code（7月上旬）

UIの要素については設計を任せれるけど、トンマナの統一感を文字で表現するのが難しい

私 → Claude Code（7月上旬）

共通パーツをたくさん作るとかで統一していくしかない

「統一感がない画面を見つけて直す」のではなく、「そもそも統一感がくずれない作り方をする」方向に切り替えました。ボタンや見出しのフォント・色を共通部品に焼き込み、画面ごとに個別で上書きさせない、という方法です。

自動プレイのエージェント（7月7日）

ゲームを起動してから、チュートリアル、街、ダンジョン、ボス戦、クリアまでを自動で遊ばせ、途中の不具合や違和感を記録する「プレイテスト用エージェント」を作りました。

最初はAntigravityが作った版があったのですが、「画面にこのボタンがあれば押す」という決め打ちの仕組みで、無限ループを起こして止まっていました。そこで、遊ぶ手順をJSONで明示的に書く方式に作り直しました。

{
  "milestoneId": "forest_golden_path",
  "displayName": "初回起動→チュートリアル→街→森ダンジョン→ボス→クリア",
  "saveMode": "preset",
  "steps": [
    { "type": "wait_scene", "scene": "TitleScene", "timeoutSec": 30 },
    { "type": "click_if_present", "target": "BtnGuestStart", "timeoutSec": 15 },
    { "type": "wait_dialogue_and_advance", "timeoutSec": 200, "maxAdvances": 150 },
    { "type": "wait_scene", "scene": "GameScene", "timeoutSec": 60 },
    { "type": "vlm_checkpoint", "prompt": "battle_staging", "onScene": "GameScene" }
  ]
}

想定外の状態になったら、1回だけVLMに「どうすれば進めるか」を相談し、それでもダメなら記録して次へ進みます。見つけた問題は「不具合」「使いにくさ」「演出のずれ」「難易度のメモ」に分類して残します。

最初のシナリオを通すのに、4回作り直しました。チュートリアルの後は街ではなく酒場に行く、出撃の前に確認ダイアログが出る、全滅するとコンティニュー画面が出る。動かしてみないと分からない想定漏れが、毎回見つかりました。8月6日には、全11地域とギルド派遣の自動プレイが最後まで通るようになりました。

数字は先に計算してから変える（7月12日〜24日）

敵の強さや報酬の数字を、勘で決めて遊んで直す、を繰り返すと、AIに任せたときに収拾がつかなくなります。そこで、先に計算してから数字を変える方法を取りました。

• 戦闘シミュレーター：味方の強さから、敵の体力や攻撃力を逆算して、勝てるかどうかを先に確かめる。
• プレイ時間の試算モデル：想定プレイ時間を「広告あり約10時間、なし約20時間」に調整しました。

試算で分かったこともあります。当初は「広告ありで5時間、なしで20時間」を狙いましたが、このゲームの広告の効果は報酬（ポイントや素材）にだけ効き、経験値には効きません。そのため、報酬の配分をどういじっても、差は広告の倍率（2倍）がほぼ上限になります。「広告を見ると4倍速く進む」は、仕組み上できないと分かり、目標を変えました。

• ゲームバランスの考慮漏れが起きても1分で全ステージ再調整完了：AIとシミュレータで実現する手戻りゼロのレベルデザイン
• AIを活用した個人開発ダークファンタジーRPGのレベルデザイン法：自動検証パイプラインとゲーム開始〜魔王討伐までのメイン導線設計

製品に必要なもの：広告・課金・アカウント

7月は、ゲームを「製品」にするための部品も一気に作りました。

日付	できたもの
7月7日	広告（AdMob）とアプリ内課金の組み込み開始
7月8日	多言語化のための文言の切り出し開始
7月14日	Androidのビルドが最後まで通る
7月15日	アカウントサーバーとの連携（ゲストログイン、セーブの同期、有償通貨の残高の台帳）
7月16日	アプリアイコン、App Storeの準備
7月19日	ビルド専用機でのCIと、テスト版の配信
7月24日	機種変更用の引継ぎコード。Google / Appleログインは、Firebase Authenticationを使う方針に決定
7月26日	課金の検証サーバー（ストアの購入記録をサーバー側で確かめる）

サーバーはPHPとMySQLで、レンタルサーバーに置いています。ここでも「作ったけど、つながっていない」ものが見つかりました。たとえば、引継ぎコードのサーバー側の処理は以前から作ってあったのに、ゲーム側から呼ばれていませんでした。また、テスト用のデータベースには、課金の記録用のテーブルが丸ごと欠けていました。

Codexが再び上限に（7月8日〜9日）

7月8日、Codexがまた利用上限に達しました。翌日の夜に復活するまでの間、Claude CodeがUIの作業を代わりに進めています。この代行中に、アウトゲーム画面の「共通の基本レイアウト」を決めて、それを機械で検査するツールも作りました。このときの作業メモの要点は、次のとおりです。

• 文字で書いた仕様は、AIに読まれないことがある。
• 画像で渡した見本は、VLMを使わないAIには見えない。
• だから再発を防ぐには、検査ツールで機械的に弾くのが確実。

この章で学んだこと

• 作業の流れで、何が効率化になるかを探す訓練になった。 「AIに確認させる」のではなく、「確認する仕組みをAIに作らせて、それを毎回回す」ほうが、結果として速くなりました。
• 見つけて直すより、崩れない作り方にする。 印象の問題（統一感）は、検出ではなく共通部品で防ぐしかありませんでした。人間のチームのデザインシステムと同じ考え方です。
• 普段やらない技術の勉強になった。 広告SDK、ストアの課金、課金の検証、OAuth、CI。業務で担当していない領域ばかりでした。

第5章 並行作業の混線と品質改善：AIが増えると「つなぎ目」が壊れる（2026年8月）

その時の開発環境

項目	内容
Codex	8月に、10ドルのプランから100ドルのプランへ上げた
Antigravity	改善点のメモとレビュー役に寄せる
Claude Code	実装（Sonnet 5）
作業の進め方	3つのAIが、同じリポジトリで並行して、あるいは数日おきに作業する
ローカルAI	DGX Spark：VLM、画像生成、音声生成を同時に回し始めて過負荷に

環境が変わった契機

Codexを上位プランへ

7月までに、Codexは少なくとも3回、利用上限で止まっていました（6月2日、6月24〜26日、7月8〜9日）。UIの作業はCodexに集中していたので、Codexが止まるとUIの作業が全部止まります。8月、Codexを月10ドルのプランから月100ドルのプランに上げました。

第1章で「ローカルLLMでAIの費用を節約できるかも」と書きましたが、実際はこのとおり、費用は増える一方でした。

「メモとレビュー」と「作業」を分ける（8月1日）

AIが3つになると、「誰が何をやったか」「このタスクはどこに書いたか」が分からなくなってきます。7月30日に、私がAntigravityに送った言葉です。

私 → Antigravity（7月30日）

03(神殿長押し確定)…とcodexから言われたのだが、そんな改善タスクあったか？

私 → Antigravity（7月30日）

演出追加のタスクってどこに記載した？codexが認識してくれない

あるAIに頼んだタスクが、別のAIには見えていない。人間のチームで言えば、口頭で頼んだ仕事が、チケットに書かれていなかった状態です。

そこで8月1日、私はAntigravityにこう伝えました。

私 → Antigravity（8月1日）

これは、仕様書の更新と依頼書を作ってください。あなたは、改善点とやるべき内容をだけをメモして、作業はclaudeCodeに依頼します。終わったらあなたがレビューしてください。

「考えて書く係」「作る係」「確かめる係」を分けて、その間を**依頼書（ファイル）**でつなぐ形です。会話ではなくファイルでつなぐので、どのAIが読んでも同じ内容が伝わります。

ただ、それでも混乱は起きました。8月24日と26日に、私がAntigravityに送った言葉です。

私 → Antigravity（8月24日）

会話が辿れなかった。動画を添付して、演出についてcodex経由でレビューしてもらったはずなんだが

私 → Antigravity（8月26日）

はい、これは、あなたがcodexから依頼されてレビューした内容ですか？

AIがAIに依頼し、別のAIがレビューする。この連鎖が長くなると、人間の私が「どこで誰が何を言ったか」を追えなくなります。結論は、ここでも記録でした。レビュー結果は日付付きのファイルに残し、会話の中だけで済ませないようにしました。

起きたこと

技の演出データが、最初から一度も読み込まれていなかった（8月14日）

この4か月で一番怖かった不具合です。

きっかけは、私の違和感でした。

私 → Claude Code（8月14日）

フルチャージブロウ（スラッガーのスキル1）、以前調整したはずなのに全然違う動作になっている、定義ファイルが点在してないか

フルチャージブロウは、職業「スラッガー」の1つ目の技です。技を出したときの動き（演出）が、前に調整したものと違っていました。

調べると、3つの原因が重なっていました。

層	原因
1	スキルのデータに「どの演出を再生するか」の項目があるのに、読み込むコードがその項目を読んでいなかった
2	スキルを実行する処理に、演出を再生する経路そのものがなかった
3	演出データのファイルを読み込むパスが、開発の最初期から間違っていた

3つ目が決定的でした。アプリの中では、データファイルは data/ の下に入ります。ところが、このファイルだけ、開発用フォルダの Content/data/ を直接指定していました。開発中のツールでは、たまたま別の探し方で見つかってしまうため、誰も気づきません。ビルドは通る、開発機では動く、でも実際のアプリでは一度も読み込まれていない。 その状態のまま、開発の最初期からこの日まで、演出を「調整」していたことになります。

私はこのとき、「他にもバグが埋まっていそうで怖い」と書いています。そして実際に、埋まっていました。

• パスを直して演出が本当に再生されるようになると、今度は、演出の終わりを待つ間に、すでに消えた変数を参照してアプリが落ちるようになりました。
• さらに、この日の修正そのものが、新しい不具合を生んでいました。 攻撃スキルのダメージが、2回入るようになっていたのです。これが見つかったのは1か月以上後の9月26日で、それまでに実機で調整したバランスは「2倍ダメージ」を前提にしていた可能性があります。
• 同じ9月26日には、回復が本業の職業が敵に向けて放つ攻撃が、なぜか敵を回復していた、という不具合も見つかりました。

AIが書いたコードを、AIがテストし、AIが「直りました」と報告する。どの段階も、それぞれの範囲では正しく見えます。それでも、つなぎ目で壊れていました。

自動化ツールが、調整済みの値を静かに上書きしていた（8月16日に発覚）

第4章で作った戦闘シミュレーターには、「計算上の理想値で全ステージの敵の強さを書き換える」機能がありました。7月30日、この機能が実行され、実際に遊んで調整した値が、計算上の値で上書きされていました。

• ある地域では、敵の強さが約2.7倍に
• 別の地域では約9.2倍に
• 何度でも遊んで資金を稼げるボーナスステージでは約20倍に

これが見つかったのは3週間近く後です。便利な一括処理は、止める仕組みがないと、人間が気づかないうちに正しいものを壊します。

DGX Sparkが過負荷で止まる（8月19日〜24日）

この頃には、DGX Sparkで画面チェックのVLM、画像生成、音声生成を同時に動かすようになっていました。

• 音声生成モデル（Stable Audio Open）をDGX Sparkに入れて動かしたところ、GPUのメモリ不足で失敗。
• 画面チェック用のVLM（Ollama）が、使い終わったモデルをGPUのメモリに載せたままにしていたのが一因でした。
• 8月23日と24日、DGX Sparkが2回ハングアップしました。SSHもつながらず、物理的に電源ボタンを押して復旧しました。DGX Sparkは、ネットワーク越しに電源を入れる機能（Wake-on-LAN）に対応していないため、落ちると離れた場所からは戻せません。

対策として、Ollamaがモデルをメモリに置いておく時間を10分に制限しました。

1台のマシンに何でも載せると、1つの処理の暴走で全部止まります。DGX Sparkはこの後も止まることがあり、そのたびにDGX Sparkを使う自動チェックも一緒に止まりました。

道具を作らないと効率化しない（8月14日）

別のプロジェクトでLost Historiaの仕組みを参考にしようとしたとき、私はAntigravityにこう書いています。

私 → Antigravity（8月14日）

losthistoriaのプロジェクトをする中で、cocosbuilderの代わりやcocosstudioの代わりになるものを作らないと効率的にならないことがわかった

AIは、コードを書くのは速いのですが、「画面の配置を目で見て微調整する」「演出のタイミングを見ながら詰める」のは苦手です。そこを支えるのは、昔ながらのGUIのエディタやビューアーでした。この4か月で、UIのビューアー、演出のタイムラインのビューアー、効果音の試聴ビューアーなど、確認用の道具をいくつも作りました。

ストアの準備で、知らないことだらけだった（8月25日〜26日）

8月25日から、初めてストアの提出準備を始めました。数年前と比べて、設定の項目がずいぶん増えていました。

ストア	増えていた・重くなっていた項目（抜粋）
App Store	App Privacy（同梱した広告SDKが集めるデータまで申告が必要）、トラッキング許可のダイアログ、課金商品ごとの審査用スクリーンショット（サイズが厳密一致）、年齢レーティング（ランダム要素のある課金を「あり」にすると確率表示の画面が必要）
Google Play	データセーフティ、コンテンツレーティング、新規の個人アカウントは、12人以上のテスターが14日間続けて参加するクローズドテストが必須
両方	広告の同意画面（GUIでしか作れない）、本番と開発のサーバーの分離

一番痛かったのは、Google Playのクローズドテストの義務を、この時まで知らなかったことです。12人のテスターに14日間参加してもらわないと、本番の提出ボタン自体が押せません。気づいたのが提出の直前だったので、ここで公開が約3週間遅れることが確定しました。

もう1つ、本番と開発の環境の分離でも見落としがありました。コードの上では、本番と開発で接続先のURLを切り替えていました。ところが、サーバー側の設定を見ると、本番と開発が同じデータベースを使っていました。URLの切り替えだけを確認して、「分離できている」と思い込んでいたのです。

このときの記録は、次の提出で同じ失敗をしないように、振り返りの文書として残しました。

この章で学んだこと

• 記録の大切さ。 AIが増えるほど、会話ではなくファイル（依頼書、レビュー結果、タスク表）でつながないと、誰が何をしたか分からなくなりました。
• 詳細を端折らずに伝える。 「演出を調整して」と頼めば、AIは調整します。でも「実際のアプリで読み込まれているか」は、誰かが確かめる手順を決めないと、誰も確かめません。
• 技術の深さより、知識の破片。 クローズドテストの義務を知らなかっただけで、3週間遅れました。深い技術よりも、「そういう決まりがある」と知っているかどうかが効きました。

第6章 提出・却下・公開：最後の1か月（2026年9月）

その時の開発環境

項目	内容
Codex	利用が急増。セッション数は7月37、8月38に対して、9月は252
Claude Code	9月13日にOpus 5、9月25日からOpus 5.5
Codexの上限中	9月28日から5日間、Codexが上限で使えず、UIの作業もClaude Codeが代行
ローカルAI	DGX Spark：画像の部分修正（ComfyUI＋Qwen-Image-Edit）、VLM
ストア作業	App Store ConnectとGoogle PlayのAPIを叩くスクリプトで、できるところは自動化

環境が変わった契機

9月は、公開に向けて同時に進める作業が一気に増えました。UIの細かい直しをCodexで並行して大量に回し、Claude Codeは不具合の修正、効果音、ストアの提出まわりを担当しました。Codexのセッション数が8月の約6倍になっているのは、そのためです。

100ドルのプランに上げたCodexも、9月28日にはまた上限に達しました。上限が来るたびに、担当表に「この期間だけClaude CodeがUIを代行」と書いて、作業をつないでいます。

起きたこと

サーバーの負荷試験（9月4日）

公開前に、サーバーのプログラムが「1秒間に1000件」の処理に耐えられるかを試しました。本番のレンタルサーバーに負荷をかけるわけにはいかないので、手元のDocker環境にPHPとMySQLのサーバーを立て、負荷試験ツール（k6）で実測しています。

• ログインは、1秒間に1000件をクリアしました（95%の応答が19ミリ秒以内、失敗0%）。1秒間に1500件にすると、約半分が失敗し始めました。
• 一方、「魔王復活」（全プレイヤーの勝利を1つの数値に積み上げていく共通目標）への勝利の登録は、1秒間に300件で約16%が失敗しました。全員が同じ1行のデータを更新する作りになっていて、処理が1列に並んでいたのが原因です。この作りを直し、失敗を0%にしました。

マシンを強くしても解決しない、作りの問題でした。AIに「この処理を作って」と頼むと、機能としては正しいものが出てきます。ただ、「大勢が同時に使ったらどうなるか」は、頼まない限り考えてくれません。

英語対応：見積もりは4倍に外れた（9月7日〜8日）

このゲームは、広告と少額の課金が中心です。言葉の壁で、届けられる人を狭めたくない。そう考えて、私は9月上旬に英語対応を決めました。

7月末の調査では、画面の文言の直書きは342か所という見積もりでした。ところが、実際に全部のファイルを機械的に調べると、**1,428か所（244ファイル）**でした。最初の調査は、画面のファイル30個だけを見て数えていたのです。

見積もりは、対象の一部だけを見て出すと外れます。AIが出した数字でも、どこまでを数えたのかを確かめないといけません。

画面全体の「つなぎ忘れ」の監査（9月14日）

アウトゲームの演出（施設で何かを受け取ったときのアニメーションなど）について、仕様書と実装を1段ずつ照合しました。対象は10施設・87個のアニメーションで、アニメーションの中の1つ1つの動き（段）に分けると408段です。

結果は、**段の単位で仕様と実装が一致していたのは32%**でした。

特に堪えたのは、8月24日のレビューで見つかっていた「JSONでは定義されているのに、一度も再生されていない演出」10件が、3週間以上手付かずのまま、14件に増えていたことです。レビューの文書には「こう直すべき」と書いてありました。しかし、担当も、完了の条件も、機械での検査もないまま、文章の中に置かれていただけでした。

ここから、次のように変えました。

• 1つのアニメーションを1枚のチケットにし、担当と完了条件を書く。
• 「定義はあるのに再生されない演出」を検出するツールを作り、push前のチェックに入れる。

「文章に書いた」は「誰かがやる」ではありませんでした。

効果音は、また作り直した（9月11日〜25日）

効果音は、この4か月で何度も作り直しています。

時期	作り方	結果
6月〜7月	音声生成AI（Stable Audio Open）	短いクリック音では、どんな指示でもノイズしか出ない
7月	音声生成AI（AudioGen、ジングルはMusicGen）	音にはなったが、音量がばらばらで、実機ではほとんど聞こえない
9月	Web Audio APIでプログラム合成	同じ設定からいつでも同じ音を作れる。作り方も数字で残る
9月25日	商用利用可の効果音素材を切り出して加工（12件）	足音・扉・金づちなど「実物の音」は合成だとノイズに聞こえたため

合成に切り替えてからも、失敗しています。

• 試聴の条件が、実機と違っていた。 候補を選ぶための試聴ツールが、実機とは違う音量・加工なしの状態で再生していました。そのため、試聴では良く聞こえたのに、実機では聞こえない音を採用してしまいました。
• 「掃除機のような音」を作っていた。 牧場で、モンスターをかえす前の「核」がうなる音を、平らに続く音＋一定のノイズ＋完全に固定の音程で作っていました。これは、機械の音の特徴そのものです。私が聞いて「掃除機みたい」と指摘して、音程をゆらし、ふくらんで沈む音に作り直しました。

さらに、9月中旬に全108件の効果音を調べ直すと、合成で作り直したのは15件だけで、残り93件は音量を上げただけの古い素材でした。そのうち36件は、音量を上げても基準に届いていませんでした。一部を直して「効果音は直った」と思い込みかけていたことになります。ここでも、施設ごとにチケットを切り直し、効果音の台帳と実物が食い違っていないかを検査するツールを、push前のチェックに加えました。

push前のチェックは、最終的にこうなりました。

[pre-push]
  1. UIレイアウトの構造と余白
  2. UIの重なり・はみ出しの悪化
  3. ダイアログに「押すべきボタン」がはっきりあるか
  4. UIタイムライン（演出）の構造と長さ
  5. 実機で聞こえない効果音が増えていないか
  6. 定義はあるのに再生されない演出が増えていないか
  7. 効果音の台帳と実物が一致しているか
  8. C++から文字を入れるラベルに、はみ出し時の扱いが指定されているか

どれも、一度失敗したことを、二度と人間の注意力に頼らずに済むようにしたものです。

ストアへの提出（9月16日〜19日）

9月16日、Google Playのクローズドテストが承認されました。いよいよ提出です。

iOS（9月17日〜18日）

• App Store ConnectのAPIを直接叩くスクリプトを作り、ビルドの割り当てや説明文の入力を自動化しました。
• ここで、第5章でも書いた「書いた」と「入力した」の違いに当たりました。ストアの説明文は8月の時点でリポジトリに書いてあったのに、実際の管理画面では空のままでした。
• 管理画面の「審査用に追加」ボタンを押すと、足りない項目の一覧が出ます。全部を先に埋めようとするより、一度押して一覧を見るほうが確実でした。
• 価格の設定と、審査への提出そのものは、Claude Codeの安全機能が「実世界に影響する操作」として止めました。ここは、私が自分で押しています。

Android（9月18日）

• 本番トラックへの最初の提出が、「配信国が設定されていない」というエラーで失敗し続けました。
• APIのパラメータを変えて回避しようとすると、「国の指定は段階公開でしか使えない」「最初の公開は段階公開にできない」と、三すくみになりました。
• 本当の原因は、アプリ自体の配信国が、管理画面で一度も設定されていなかったことでした。テスト用のトラックでは配信国が不要なので、それまで気づきませんでした。管理画面で配信国を設定すると、失敗していたのとまったく同じコマンドが、そのまま通りました。

9月19日、バージョン1.0.0として区切りました。

テスト配信の実機で見つかった2つの不具合（9月下旬）

審査に提出したあとも、私はiOSのテスト配信（TestFlight）で実機の確認を続けていました。そこで、2つの不具合を見つけました。どちらも、Macでの自動テストは通っていました。

1. 出撃ボタンが反応しない（build 13〜16）

戦闘に向かう前にパーティーを確かめる「出撃準備」のダイアログで、「出撃」「キャンセル」「酒場へ」のボタンを押しても、何も起きませんでした。

• ボタンの押した感触（押下時の見た目の変化）を共通部品に載せ替えたとき、その部品は「見た目用の部品がないと、何も登録せずに黙って終わる」作りでした。
• Macの自動テストは、ボタンの処理を直接呼び出して確かめていたので、「タッチがボタンに届くか」は一度も確かめていませんでした。

修正後、実際のタッチと同じ経路を通して確かめる自己テストを追加しました。

2. 攻撃ポーズだけ、キャラクターが約2.8倍に（build 14〜17）

味方のキャラクターは、攻撃の瞬間だけ、立ち絵を攻撃ポーズの絵に差し替えています。その攻撃の瞬間だけ、味方が大きく表示されていました。

• 原因は、別のAIが作業中だった素材の変更（新しいサイズの素材を前提にしたコード）が、素材より先に混ざってコミットされていたことでした。
• 同じ作業場所で複数のAIが並行して作業していると、他人の「作業途中」を自分のコミットに巻き込むことがあります。

出荷用のビルドは、確認済みのコミットだけを集めた専用のブランチから作り直しました（build 17、18）。

文字のはみ出し：デザインで受け止める（9月28日〜29日）

公開直前、タブレットや英語で、文字が枠からはみ出す箇所がたくさん見つかりました。Codexが上限で止まっていたので、Claude Codeが代わりに対応しました。

最初は、はみ出した箇所を1つずつ直していました。そこで、私はこう伝えています。

私 → Claude Code（9月28日）

文字が複数行に跨るなら、最初からそれを想定してスクロールビューなどにしてデザインで耐えれるようにした方がいいかもしれない

そこで、文字の種類ごとに「受け止め方」を決めました。

実行中に「はみ出していないか」を検査する仕組みと、「C++から文字を入れるラベルに、はみ出し時の扱いが指定されているか」を検査するpush前のチェックも作りました。最後に、日本語と英語それぞれ573の画面状態をすべて確かめて、はみ出しがないことを確認しました。

1つずつ直すのではなく、「長い文字が来ても崩れない作り方」を決める。第4章の「統一感は共通部品で守る」と同じ考え方です。

Appleの審査で却下された（9月29日）

9月29日、Appleの審査で、**ガイドライン1.1.4（あからさまに性的な表現）**を理由に却下されました。同じ問題で再提出を繰り返すと、審査が長引いたり、アカウントに影響したりするおそれがあるという警告付きです。

調べると、原因は神殿（倒れた冒険者を復活させる施設）にいるシスターの絵1枚だけでした。胸元・腰・太ももの露出が大きく、ストアの画像、公式サイト、ゲーム内の神殿画面に登場していました。念のため、ほかの人物（NPC16枚、16職業の女性版の立ち絵16枚、敵98枚（今の素材の数））も確認しましたが、同じような問題は見当たりませんでした。

直し方は、私が決めました。

私 → Claude Code（9月29日）

肌色を減らすだけで、ポーズはそのままが良い

全身を描き直す案もありましたが、ポーズが変わってしまうので採用しませんでした。代わりに、DGX Spark上の画像編集モデル（Qwen-Image-Edit）で、肌が見えている部分だけをマスクして描き直す方法をとりました。1回目は腰の後ろに肌が残ったので、マスクを広げてやり直しています。

そのうえで、

• ストアの神殿のスクリーンショットを、iPhone・iPad・Androidの全サイズで撮り直し、App StoreとGoogle PlayそれぞれのAPIで差し替え
• 公式サイトの画像と動画も差し替え
• 修正版をbuild 19としてアップロードし、再提出

まで行いました。元の絵は、アプリには入れない前提で別の場所に保管しています。

ここで、AIの「忘れる」問題にも当たりました。ストアのスクリーンショットの差し替えは、以前の提出で何度もAIにやってもらっていた作業です。ところが今回、Claude Codeは最初「APIではできない」と答えました。私が「いつもやってくれてるけど、今回はやれなかった？」と聞いて、ようやく以前の方法を思い出しています。APIの認証に使うIDも、前回伝えたのに記録されていませんでした。

このシスターの絵は、露出も含めてキャラクターの魅力として、狙って作ったものでした。見落としではありません。本当はその価値をプレイヤーに届けたかったのですが、ストアで配信する以上、審査の基準という制約には従うしかなく、今回はその表現をあきらめました。配信する場所の基準を守るのは、配信する側の責任です。

どこまでが許されるかの線引きは、実際に審査に出すまで分かりませんでした。表現したいことと、配信する場所の基準との折り合いをどこで付けるか。これも、公開してみて初めて分かったことの1つです。

Android版の公開（9月末）

9月末、Android版が公開されました。

公開後の修正からは、「1.0.1」のようにバージョン番号を毎回上げる運用にしました。ビルドの仕組みも、バージョン番号を指定しないと作れないように変えています。Android 1.0.1は、テスト用のトラックと本番のトラックの両方に出しました。

iOS版は、この記事を書いている時点で、再審査を待っています。

この章で学んだこと

• 技術の深さより、知識の破片。 配信国の設定、審査の基準、ストアのAPIの癖。どれも「知っていれば数分、知らなければ半日」でした。
• 記録の大切さ。 「文章に書いた」だけの改善は放置されました。担当・完了条件・機械の検査が付いて、初めて進みました。そして、AIは前回できたことを忘れます。
• 詳細を端折らずに伝える。 「ポーズはそのまま、肌色だけ減らす」まで言えば、AIはそのとおりに直せました。

生成AIをどこに使ったか

改めて、生成AIをどこに、どう使ったかをまとめます。

分野	使い方
プログラム	2026年以降は、ほぼAIエージェントが実装。人間は仕様の決定、レビュー、採否を担当
仕様書・ドキュメント	AIが下書きし、人間が決定事項を伝えて直す。約300本
画像（キャラクター・敵・背景・UI素材など）	生成AIで作成し、人間が採否を判断。一部はマスクを使った部分修正
エフェクト	動きはJSONのレシピ（数字）で組み立て、絵（テクスチャ）だけをAIやプログラムで作る
BGM	Geminiの音楽生成で作成し、人間が選定（12曲）
効果音	大半はWeb Audio APIでのプログラム合成。一部（12件）は商用利用可の効果音素材を切り出して加工
画面の文言・英訳	AIが下書き・翻訳（英語の表現は改善中）
テスト・検証	自動プレイ、画面チェック（VLM）、戦闘シミュレーター、push前チェックなどの仕組みを、AIが作ってAIが回す
フォント	商用利用できるオープンライセンスのフォント

気をつけていること:

• 生成物をそのまま出さず、必ず人間が見てから採用する。
• 素材の出どころ（どのツールで、どう作ったか）を記録しておく。
• 規約や審査の基準に照らして、人間が最終判断する。
• 表現の狙いがあっても、ストアの審査基準には合わせる（第6章）。

費用のまとめ

AIの利用料と、マシンの費用です。

項目	プラン・金額	備考
ChatGPT（Codex）	月10ドル → 8月から月100ドル	UIの作業が集中し、利用上限で何度も止まったため
Claude Code	年間220ドルのプラン	6月10日に追加
Google AI Pro（Antigravity / Gemini）	月2,900円
GitHub Copilot	月10ドル	GitHubアカウントの支払いで
DGX Spark（GB10）のOEM機	約60万円（買い切り）	今は約90万円に値上がり

8月以降の月額は、ざっくり「100ドル＋10ドル＋Claude Codeの月割り約18ドル＋2,900円」です。

DGX Sparkを買った理由の1つは、「ローカルLLMでAIの費用を節約できるかもしれない」でした。実際には、第2章のとおりローカルLLMでの実装は1週間で終わり、そのあとはやりたいことが増えるたびに、クラウドのAIの費用も増えていきました。

一方で、DGX Sparkそのものは、画像生成、画像の部分修正、3Dモデル生成、画面チェックのVLMと、4か月ずっと働いてくれました。クラウドで同じだけ回していたら、利用上限か費用のどちらかで止まっていたと思います。「節約」にはなりませんでしたが、「回数を気にせず試せる」ことには大きな価値がありました。

数字で見る4か月

項目	数
再開からAndroid公開まで	約4か月（2026年5月21日〜9月末）
2026年のコミット数	1,181
Codexのセッション数（7月 / 8月 / 9月）	37 / 38 / 252
Claude Codeの共同作成者の記載	516件（モデル別の内訳は第4章）
Codexの共同作成者の記載	11件（Codexは記載を付けないことが多く、実際の作業量はもっと多い）
使ったAIの種類（Lost Historia）	Antigravity、Codex、Claude Code、Copilot、ChatGPT、ローカルLLM（Qwen系）
凍結した方式	Spineの自動化、3Dモデルで敵を動かす方法、ローカルLLMでの実装
push前の自動チェック	8種類
日本語・英語で確認した画面状態	それぞれ573

うまくいかなかったことの一覧

各章に散らばった失敗を、一覧にしておきます。自分用の反省でもあります。

失敗	章	原因	分類	今の対策
仕様が決まる前にAIが実装を始める	2	決めていないことをAIが埋める	伝えていなかった	規則ファイルで「仕様確定→タスク確認→実装」を強制
実装が仕様の穴を勝手に埋める	2	仕様書に書いていない部分がある	伝えていなかった	実装で決めたことは仕様書に書き戻す
「成功」の報告が違っていた	2	AIの確認を信じた	確かめる手順がなかった	確認を機械に任せる（E2E、VLM、push前チェック）
ローカルLLMでの実装が止まる	2	ツールの不安定さ、会話が長くなると遅くなる	AIやツールの限界	実装はクラウドのAI、ローカルは画面チェック係に
消したはずのルールが残る	2	ルールの手入れをしていなかった	記録の手入れをしていなかった	古くなった記述に気づいたら、その場で直す
敵のアニメーション（Spine、3D）	3	1枚絵に情報がない、関節の継ぎ目が伸びる	AIやツールの限界	凍結。静止画＋プログラム演出
立ち絵の画風がバラバラ	3	画風の条件を伝えていなかった	伝えていなかった	作画指示書を表にして渡す
画面の統一感が崩れる	4	印象の問題は検出できない	伝えていなかった	共通部品に焼き込む
技の演出が一度も読み込まれていなかった	5	開発機でだけ見つかるパス	確かめる手順がなかった	実際のアプリでの確認、読み込み方の統一
修正そのものが別の不具合を生んだ	5	修正の確認が狭い範囲だけだった	確かめる手順がなかった	回帰テストの追加
一括処理が調整済みの値を上書き	5	便利な機能に止める仕組みがなかった	確かめる手順がなかった	実測で調整した値を戻し、一括処理の使い方を見直した
DGX Sparkのハングアップ	5	1台に処理を詰め込みすぎ	知らなかった	モデルのメモリ保持時間を制限
AI同士の依頼・レビューが追えない	5	会話の中だけでやり取りしていた	記録の手入れをしていなかった	依頼書・レビュー結果をファイルに残す
クローズドテストの義務を知らなかった	5	知識がなかった	知らなかった	次回は開発の早い段階で始める
本番と開発が同じデータベース	5	URLの切り替えだけで分離できたと思った	確かめる手順がなかった	サーバー側の設定まで確かめる
英語対応の見積もりが4倍外れた	6	一部のファイルだけで数えた	確かめる手順がなかった	全体を機械的に走査してから見積もる
文章に書いた改善が放置された	6	担当・完了条件・検査がなかった	記録の手入れをしていなかった	1アニメーション＝1チケット＋検出ツール
聞こえない効果音を採用した	6	試聴の条件が実機と違った	確かめる手順がなかった	実機と同じ条件で試聴、音量の自動チェック
「書いた」説明文が「入力」されていなかった	6	ドキュメントがあることで思い込んだ	確かめる手順がなかった	管理画面の実際の値を確かめる
配信国の未設定	6	テスト用トラックでは不要だった	知らなかった	最初の本番提出の前に管理画面を確認
実機で出撃ボタンが反応しない	6	自動テストがタッチの経路を通っていなかった	確かめる手順がなかった	実際のタッチと同じ経路の自己テスト
他のAIの作業途中がコミットに混ざる	6	同じ作業場所で並行作業	確かめる手順がなかった	出荷用は確認済みのコミットだけでビルド
Appleの審査で却下	6	狙って作った人物画の表現が、審査基準の線を越えていた	知らなかった	審査基準に合わせて表現を調整。元の絵は保管
AIが前回できたことを忘れる	6	会話をまたぐと記憶が消える	記録の手入れをしていなかった	作業メモ（記憶ファイル）に残す

原因を、私なりに5つに分類してみました。

こうして並べると、「AIやツールの限界」に分類できたのは24件中2件だけでした。残りは、確かめる手順を決めていなかった、伝えていなかった、記録の手入れをしていなかった、知らなかった、のどれかです。一番多いのは「確かめる手順がなかった」の10件で、AIの「できました」をそのまま受け取っていた場面の多さが表れています。

おわりに：AIと4か月開発して学んだこと

バイブコーディングでさっと出すつもりが、4か月かかりました。

振り返ると、AIがうまく動いてくれなかった場面の多くは、AIの性能の問題ではありませんでした。私の伝え方が悪かったか、私が詳細な設計や技術的な解決方法を知らなかったか、のどちらかでした。

エンジニアとして働いている身としては、耳の痛い話です。AIにうまく伝わらないということは、普段の業務でも、他の人とのコミュニケーションが雑だったり、下手だったりすることの証明でした。AIは、それをごまかさずに結果で返してきます。人間の同僚なら、察して補ってくれたり、「これってどういう意味ですか」と聞き返してくれたりします。AIは、黙って自分なりに埋めて、自信を持って「できました」と言います。

それでも、AIと一緒に開発したことで、次のことを学べました。

左が本文で書いた出来事、右がそこから学んだことです。

普段やらない技術の勉強になる

Godot、Axmol、画像生成、LoRA、3Dモデルの骨入れ、Web Audioでの音の合成、VLMによる画面チェック、広告SDK、ストアの課金、課金の検証サーバー、OAuth、CI、ストアのAPI。業務では触れない技術に、AIと一緒に次々と手を出すことになりました。

AIが書いたものを理解して、採るか捨てるかを判断するには、自分も学ぶしかありません。AIは、新しい技術の入り口を、ものすごく低くしてくれました。

作業の流れで、何が効率化になるかを探す訓練になる

「1タスク＝1機能＝1自動検証」、push前の自動チェック、AIごとの担当分け、依頼書でつなぐ分担。どれも最初からあったわけではなく、うまくいかなかった作業を見直すたびに作り足したものです。

どこを機械に任せ、どこを人が見るか。どのAIに何を任せ、何を任せないか。これを4か月考え続けたことは、普段の仕事の段取りを考えるうえでも、良い訓練になりました。

詳細を端折らずに伝えるようになる

「いい感じに」は伝わりません。

• 立ち絵16枚の画風がバラバラだったのは、頭身や光の向きを伝えていなかったからでした。
• 演出の手直しも、「もっさりしている」ではなく、「何秒で、どう加速して、何倍に」と数字で伝えるようにしました。
• 何も言わなければ、世界観に合わないサイバーパンク調にも寄っていきます。
• 「ポーズはそのまま、肌色だけ減らす」まで言えば、そのとおりに直ります。

言わなかったことは、AIが毎回ちがう形で埋めてきます。

記録の大切さを知る

AIは会話をまたぐと前のことを忘れます。仕様書、タスク表、担当表、依頼書、作業メモを残さないと、同じ説明や同じ失敗を何度も繰り返します。

そして、記録はAIのためだけのものではありませんでした。数か月前に何を、なぜ決めたのか、私自身も記録がなければ思い出せません。この記事自体も、4か月分のコミットと会話の記録がなければ書けませんでした。

技術の深さより、知識の破片をたくさん持つ方が有利

AIに正しい方向を示すには、深い専門知識より、「そういうやり方があるはず」という知識の破片が役に立ちました。

• 3Dモデルの継ぎ目が崩れる問題で、AIが重い作り直しの方法を試していたとき、「近い頂点をまとめる処理のことでは？」と聞いたのが正解につながりました。
• 逆に、Googleのクローズドテストの義務を知らなかったことで、公開が3週間遅れました。

深く知らなくても、「ある」と知っていれば、AIに聞けます。知らなければ、聞くことすらできません。広く浅くでも、知っているかどうかで結果が大きく変わりました。

5つの学びは、1つの輪になっていた

振り返ると、5つの学びはばらばらではなく、1つの輪になっていました。新しい技術に触れると知識の破片が増え、何を頼めばいいかが分かるので、端折らずに伝えられる。伝わればAIは正しく作り、確かめる仕組みも作れる。その記録を次の会話のAIが読み、私自身も振り返れる。

家事や子育てと両立しやすくなった

最後に、もう1つ伝えたいことがあります。

これまでの個人開発は、まとまった時間、集中して手を動かさないと進みませんでした。子育て中の既婚者にとって、これはかなり高いハードルです。家事や子どもの世話をしていると、まとまった時間はなかなか取れません。

AIとの開発は違いました。方針を伝えれば、作業そのものはAIが進めてくれます。私がやるのは、方針を決めて伝えることと、上がってきたものを確かめることです。家事や子育ての合間に指示を出し、手が空いたら結果を見る。この進め方なら、家事や子育てとの両立がずっとしやすくなります。

結婚したら、こういう趣味の開発はあきらめるもの。そんな風潮があったと思います。AIとの開発で、個人開発はとても取り組みやすいものになりました。同じように、時間が取れずに手を止めている人に、この記事が届けばうれしいです。

---

このゲームが良いものかどうかは、遊んでくださる方に判断していただくことだと思っています。ご意見やご指摘をいただけるとうれしいです。

関連記事

この4か月の間に、個別のテーマで書いた記事です。

時期	記事
2025年10月	VSCodeに連携したCodexを使って趣味のVOICEVOXでの文章朗読アプリ(AIによる配役)を作ってみた
2026年3月	Godot 4 + C++ (GDExtension) で挑む！Jolt Physics を使ったビリヤード開発記
2026年3月	AIエージェントと作る！Godot 4 + GDExtension(C++)による2Dミステリーゲーム開発記
2026年3月	10年前の Cocos2d-x プロジェクトを最新の Axmol Engine へ移植して Xcode で起動するまで
2026年4月	M4 Mac から Blackwell ASUS Ascent GX10 へ：自律アセット生成パイプラインの進化と挫折の記録
2026年5月	AI画像生成でゲームアセット量産が失敗する理由：絵には仕様が多すぎる
2026年6月	ゲーム開発で1枚絵の敵キャラをAIで自動分割・Spineアニメ化しようとして限界を感じ、3Dに方針転換した話
2026年6月	ローカル3D生成の覇権交代？Hunyuan3Dを諦めてMicrosoftの「Trellis.2 4B」に乗り換えた話
2026年7月	ゲームバランスの考慮漏れが起きても1分で全ステージ再調整完了：AIとシミュレータで実現する手戻りゼロのレベルデザイン
2026年7月	AIを活用した個人開発ダークファンタジーRPGのレベルデザイン法：自動検証パイプラインとゲーム開始〜魔王討伐までのメイン導線設計
2026年8月	AI駆動ゲーム開発におけるエンジン別トークン効率・自己完結性の比較 〜 Unity vs Godot vs Axmol 〜