【要約】AIで一人でゲームを作れるか試したら、35日・実質8人日でApp Store審査まで行った [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がUnityやBlenderの深い専門知識を持たない状態で、AIが生成する成果物の品質と整合性をいかに担保するかという課題に直面した。具体的には以下の問題が発生した。
- ・AIが生成したコードやアセットの妥当性を、人間がコードレベルで判断できない。
- ・生成物のポリゴン数やUVの重なり、コストが制御不能になるリスクがある。
- ・App Store申請などの、AIでは解決できない事務的・非技術的な工程での停滞。
// Approach
開発者は、AIが生成した成果物を自動で検証できる「器」を先行して構築するアプローチを採用した。作業の大部分をAIに委ねつつ、人間は指示と採否のみを行う体制を整えた。
- ・実装：UnityのGUI操作を捨て、SceneBuilder.csによるコードベースのシーン構築を徹底した。
- ・検証：AutoCapture.csによる自動キャプチャと、302件のCoreテストによる品質保証を導入した。
- ・素材：poly_budget.py等を用い、ポリゴン数やコストに制約を設けたアセット生成パイプラインを構築した。
- ・企画：AIに多角的な案を出させ、人間が要件を絞り込むヒアリング形式のプロセスを用いた。
// Result
開発者は、実働約8人日（60〜76時間）という驚異的な短期間で、App Storeの審査提出まで到達した。
- ・C# 310ファイル、テスト302件、アセット162件を生成した。
- ・「器」を先に作る戦略により、後半のオブジェクト追加速度が劇的に向上した。
- ・作業の23%を待機時間に充てられる、極めて効率的な開発サイクルを実現した。
Senior Engineer Insight
> 本事例の肝は、AIに「コードを書かせる」ことではなく、「検証可能なパイプラインを構築させる」点にある。UnityのGUI操作を捨て、コードベースの構築と自動テストに全振りした設計判断が、専門知識の欠如を補った。これは、AI駆動開発において「人間がコードを読む」のではなく「テストと制約が通るかを見る」という、品質保証のパラダイムシフトを示唆している。ただし、この手法は高度な自動化基盤を設計できる能力を前提としており、単なるプロンプトエンジニアリングとは一線を画す。実戦投入には、AIの判断ミスを検知する「門番」の設計が生命線となる。