設計はFable 5、実装はOpus 4.8。コードを1行も書かずにiPhoneゲームをApp Storeで公開するまで
こんにちは、Keiichi.Hayama です。
農場で作物を育てて、加工して、自分のお店で売る——経営シミュレーションゲーム「まいにち農園」をApp Storeで公開しました。
現在ゲームはApp Storeでダウンロード可能です。
このプロジェクトには、ちょっと変わった特徴が3つあります。
人間（私）はコードを1行も書いていない
開発機にMacが無い（Windows機のみ。Xcodeは一度も起動していない）
AIを2モデル使い分けた（高いモデルに設計、速いモデルに実装）
実働約12日。私がやったのは要件を伝えること、アセットを準備する事、実機で遊んで確認すること、そしてお金と名前にまつわる意思決定だけです。この記事は、その役割分担と、つまずきと、お金の話を、実測データ付きで残す開発記です。
作ったもの
「まいにち農園」は、実った作物の上を歩いて収穫し、加工機でパンやジュースにして、棚に並べ、レジでお会計する——全部を自分の足で回すタイプの経営シムです。品種改良（★システム）、変異種図鑑、大口契約の連鎖コンボ、のれん分けによる周回要素まで入っています。
技術スタック: HTML5 Canvas（生JS・バンドラ無し）+ Capacitor 6 + StoreKit 2 + AWS
12言語対応、買い切り型のアプリ内課金8製品、広告なし
サーバはLambda + DynamoDBのサーバレス構成（課金レシート検証とApp Attestによる不正対策）
体制: 高いモデルに「設計」、速いモデルに「実装」
今回の中核となる工夫です。Claude Codeで、トークン単価の高い Fable 5を「設計担当」、単価を抑えられる Opus 4.8を「実装担当」 に固定しました。
運用はシンプルで、私が「◯◯したい」と伝えると、まずFable 5が設計書（game-design.md）に「§10.xx」として実装仕様を書き起こします。レビューして納得したら、モデルを切り替えて「§10.xxを実装して」の一言。あとはOpus 4.8が実装・テスト・ブラウザでの視覚検証まで進めます。
これが想像以上に効きました。実測では:
ターン数の比率は Fable 5 : Opus 4.8 ≒ 4 : 6。実装・検証・ビルドは手数が多い工程なので、そこが安いモデルに寄る
1ターンあたりの出力トークンはFable 5が約1,660、Opus 4.8が約1,320。設計担当のほうが長文を書く（設計書は最終的に18.6万字）
全期間の合計で、人間の発話はわずか492回。対してAIのターンは9,258回、ツール実行（ファイル編集・ビルド・AWS操作・ブラウザ検証）は4,514回
つまり私が1回何かを言うと、AIが平均19ターン・ツール9回ぶん自律的に働いた計算になります。
もうひとつの発見は、設計書がモデル間の引き継ぎドキュメントを兼ねること。コンテキストが切れても、次のセッションのモデルは設計書の§を読むだけで作業を再開できます。設計書駆動（IDD）はAIの記憶対策としても機能しました。
Unityを捨てて、Webフロント+Capacitorにした
最初はUnity（C#）で作り始めました。グレーボックスまでは動いたのですが、生成されるコードの品質に差があり——同じAIでも、WebフロントエンドのコードのほうがUnityのコードより明らかに質が高かったのです。
理由は推測ですが、LLMの学習コーパスにはJS/HTML/Canvasのコードが圧倒的に多く、Unity特有のシーン構造やエディタ操作はテキストで表現しにくいからだと思います。
そこで方針転換。ゲームはHTML5 Canvasで作り、Capacitorでネイティブアプリにラップする構成にしました。結果としてゲーム本体はJS/HTML 7ファイル・4,832行に収まっています。
面白い副産物もありました。Unity用に書いたC#のゲームロジックを捨てずに、JSと1:1対応の「検算機」として存続させたことです。JS側の数式を変更するたびC#側も同期し、回帰テスト（最終91件）を回す。エンジンとしてのUnityは消えましたが、C#は品質保証として最後まで働きました。
教訓: AIに作らせるなら、AIが得意な技術スタックに寄せる。フレームワークの好みより、学習量の多さで選ぶ価値があります。
キャラアニメは「画像生成AI」ではなく「動画生成AI」から切り出した
ゲームの見た目を決めるキャラクターアニメーション。最初は画像生成AIでスプライトシートを直接作らせましたが、これは失敗でした。コマ間の一貫性が保てないのです。服の柄、顔、体型がコマごとに微妙に別人になり、並べて再生すると破綻します。
うまくいったのは、動画生成AIで「8方向に歩くキャラ」の動画を作り、そこからフレームを切り出す方法でした。動画生成AIは時間方向の一貫性を持っているので、切り出したコマは当然つながって見えます。
動画生成サービスは Adobe Fireflyを利用し、モデルはKling3.0を使いました。
キャラクターの元絵を用意して、これをプロンプトでその場固定で走らせるわけですが、確率生成になるので、ある時は画面内のキャラクター同士が一か所に集まってしまったり、ある時は画面外に走り去ってしまったり(笑)と、一筋縄ではいかないアセット生成の苦労がありました。
ようやく動画アセットが作成できると、その後の切り出しはAIがPowerShell作成した自動化パイプラインに流すことになります。（計18本・3,696行）:
ffmpegでフレーム抽出（必要に応じて72fpsへ補間）
自己相関で歩行周期を自動検出し、等間隔リサンプル
クロマキー処理（緑背景を境界フラッドフィルで除去。衣装の緑色は保護する適応処理）
連結成分解析で切り抜き、足元を揃えて8方向スプライトへ
この方式で、主人公3衣装＋お客さん2種＋スタッフ3種、計2,972枚のスプライトを全自動生成しました。
ただしここも一発では決まりませんでした。周期の誤検出、補間によるゴースト、持ち物（台車）がクロマキーで消える……試行錯誤の結果、退避された「作り直し前」のスプライトが1,745枚残っています。現行の約37%相当のやり直し。この物量が、動画→スプライト方式の生々しい現実です。
Macが無くてもApp Storeに出せる
私の開発機はWindowsで、Mac実機はバッテリーの上がったMac Book Airしか持っていません。iOSアプリのビルドはどうしたか。
答えは AWS CodeBuildのmacOSリザーブドフリートです。ソース一式をS3にzipで置き、buildspecが「Capacitorプロジェクト生成 → ネイティブコード組み込み → fastlaneで署名 → TestFlightへアップロード」まで全自動で実行します。署名もApp Store Connect APIキーによるクラウド完結。手元でXcodeを開いたことは一度もありません。
ウォーム状態のフリートなら1ビルド約3分でTestFlightまで到達します。TestFlightへのアップロードは計10回ほど行いました。
想定外だったお金の話
ここで注意喚起です。
macOSフリートは、Appleのライセンス上「起動から24時間」が最低利用時間です。「ビルドが終わったら即削除すれば数ドルで済む」という私（とAI）の当初の想定は崩れ、1回の起動で約41ドルかかりました。
ただし逆手に取る運用も学びました。フリートは削除予約中（PENDING_DELETION）でもビルドに使えるので、24時間の窓に修正ビルドを詰め込むのです。実際、提出直前は「モック表記の削除」「アイコン差し替え」「言語選択UIの修正」など5回のビルドを同じ窓内に収め、追加費用ゼロで乗り切りました。
コスト全体で見ると、サーバ側はLambda+DynamoDBオンデマンドで月数ドル規模。最大の変動費はビルドという、個人開発らしからぬ構造になりました。
「実装が終わってから」が長い——審査申請までフルサポート
個人的に一番助かったのは、コードではなく申請作業そのものの伴走でした。App Storeへの提出は、実装完了からの距離が想像以上に長いのです。
AIがやってくれたこと:
アプリ内課金8製品のメタデータ作成（表示名・説明のja/en、ASCの文字数制限内に調整済み）
プライバシーポリシーとサポートページの本文作成から、自社ドメインでのURL公開まで（Lambdaで配信）
Appプライバシー申告——フォームの分類（ユーザID／購入／ゲームプレイコンテンツ）と自アプリの実データの対応付け
審査メモ（Review Notes）の英文、輸出コンプライアンス、年齢レーティングの回答案
スクリーンショットの規定サイズ変換(1242×2688)——実機スクショを渡すだけで日英10枚が揃った
そして却下リスクの事前検出。提出直前の点検で「実機の購入完了トーストに『（モック決済）』の文言が残っている」(ガイドライン2.3.1リスク)、「アプリアイコンがCapacitorのデフォルトのまま」(2.3.8リスク)の2件を発見し、どちらも提出前の修正ビルドで潰しました
余談ですが、アプリ名も一悶着ありました。当初の「Harvest Market」は米国で使用済み。その場で代替案を検討し、「まいにち農園（Mainichi Farm: Grow & Sell）」に改名。ストア文言・プライバシーページ・審査メモの名称同期までAIが一括で処理しました。
うまくいかなかったこと・人間がやったこと
公平のために、綺麗に進まなかった部分も書いておきます。
実機でしか出ないバグに苦しみました。課金がモック判定になる問題、App Attestの登録が謎に失敗し続ける問題(原因はASN.1のOID定義の1バイトの誤り)。いずれも「人間が実機で試す→AIがログを仕込んで診断する」の往復で解決
TestFlightの「処理中」に気づかず、修正前の旧ビルドを検証して「直ってない！」と騒いだこともありました（アップロード直後の数分はインストールできません。アプリを消して入れ直すのが確実）
12言語対応の言語選択画面が画面からあふれるバグは、提出前夜の実機確認で発見。国旗が「undefined」と表示される豪快な画面でした
人間の仕事は最終的にこう整理できます: 要件と好みの言語化、(現時点では)AIが用意しきれないアセットやデザインの用意、実機での確認、AppleとAWSの初期のアカウント操作、そして意思決定（名前をどうするか、EUに配信するか、いくら払うか）。
コードとドキュメントをAIが書くぶん、こうした仕事にじっくり取り組む事ができました。
数字のまとめ
12日間の成果物（最終リビジョンの実測）:
出荷コード: 8,159行（ゲーム本体4,832 / サーバ2,770 / ネイティブ302 / ビルド定義255）
設計・提出ドキュメント: 約22.6万字（原稿用紙565枚相当）
スプライト: 2,972枚（＋作り直しで退避された1,745枚）
翻訳文字列: 328キー×12言語 ≒ 3,936本
開発専用の道具: アセットパイプラインPS1 3,696行、C#検算機2,178行・回帰テスト91件
やり取りの規模:
人間の発話: 492回
AIターン: 9,258回（Fable 5が3,565 / Opus 4.8が5,678）
ツール実行: 4,514回
総トークン数: 591万
おわりに
「高いモデルに設計、速いモデルに実装」という分業は、費用面でも品質面でも手応えがありました。設計書という単一の真実があることで、モデルを跨いでも文脈が壊れない——これはコスト最適化というより、AI、AI Agents開発のプロジェクト管理手法として汎用性がある気がしています。
最後にもう一度、App Storeのリンクを置いて起きます。
「まいにち農園」、IOS端末をお持ちの方はぜひ遊んでみてください。
そして、楽しんでいただけた方はフィードバックもよろしくお願いします。
