はじめに
AIを使えば、一人でもゲームが作れるのではないか。
半信半疑で始めた検証が、35日後には App Store の審査に出ていました。
作ったのは『ことづての庭』という、砂と石で日本庭園を作るモバイルゲームです。ただ、この記事で書きたいのはゲームの中身ではなく、どういう工程で作ったかです。特徴は次の一点に尽きます。
プログラムもシナリオも絵も音楽も3Dモデルも、人は一行も一枚も作っていない。
結論: 良い要件仕様に勝るものはない
しょーじき、この記事もAIが書いてるのでunity周りは何言ってるかさっぱり
isddは使っていない。ops5は特に工夫しなくてもコードは壊さない。
そして書いている本人は、いまも Unity のコードや仕組みを理解していません。それでも動くものが出来て、審査に出せました。何がそれを可能にしたのかを、git のコミットと会話ログという実データから起こします。
数字で先に示します。
| 項目 | 値 |
|---|---|
| 着手から審査提出まで | 35日(2026-07-18 → 2026-08-22) |
| 人の実働(推定) | 60〜76時間 ≒ 8人日 |
| コミット | 291件 / 36日稼働 |
| C# | 310ファイル・71,216行 |
| サーバー(TypeScript) | 2,137行 |
| テスト | Core 302件(全通過) |
| TestFlight ビルド | 27本 |
| 人が書いたコード・絵・音 | 0 |
全体像:4つの工程すべてをAIとの往復で回す
人がやったのは 指示と、出てきたものの採否だけです。以下、工程ごとに見ていきます。
1. 企画:広く出させて、人が選ぶ
作りたいものが先にあったのではありません。「AIで一人でも作れるか」を確かめる入口として始まっています。作るものは後から決めました。
最初の一言に、条件がそのまま入っています。
個人で作れそうな switch用のゲーム開発をしたい。まずは開発キットについて調べて
— 2026-07-18 01:23 UTC
ここから企画が決まるまでの流れです。
要点は 案を出させる役と、選ぶ役を分けていることです。
1,3,4,5,7の全ての組み合わせ毎にどの様なゲームが考えられるか検討して、有望そうなものを16個出してみて
— 01:32 UTC
選んだのは最初の一言から1時間13分後。
B-2で、砂をリアルタイムに流し続けて、綺麗な庭を作る企画はどうでしょうか？
発生源とシンクを作って流れを制御、模様という静止した概念ではなく、移ろいゆく庭を作るイメージです。
— 02:37 / 02:43 UTC
決めた直後、進め方まで指定しています。
ゲーム企画を仕上げるのに必要な情報や検討事項があったら、一つづつヒアリングして
以後は AI が論点を1つ出し、人が答える形。7月18日だけで89往復(01:23〜22:47)でした。
この日の決定が、35日後まで覆らなかった
これが工程として一番効いた点です。手戻りが無い。
| その日に決めたこと | いまの実装 |
|---|---|
| お題を置く | 本編14本・寄り道9本 |
| オンラインは最初から | 公開・訪問・クラウド保存 |
| 訪問は非同期で、1つだけ置く | いまも同時編集ではない |
| 差分はオーナーが採否を決める | レビュー画面そのもの |
| 痕跡は組み合わせ型(定型フレーズ) | 自由入力の文章は存在しない |
| 庭はメイン1つ＋複数 | 庭の枠3〜5 |
なお、「作れるか」への疑いは最後まで残っていて、ログには 「現実的ですか？」が繰り返し現れます。格子を3Dにするのは現実的か、全プラットフォームで同じ庭を編集できるか、陰解法で1分前の状態を計算する計算量はどれくらいか、砂の色を保存できるか。行けるところまで確かめながら進んだ記録になっています。
2. 実装:Unityを人の手から切り離す
翌 7月19日、仕様書がコミットされ、その夜に最初の実装指示が出ます。
sand_simulation_spec.md を元に砂のシミュレーションを仮実装してみて。地形データはランダムで、石などのテクスチャは不要で単色で表現して。本格的にゲーム企画を進める前に、最低限どのように見えるかだけ確認できる様にすることが目的なので、出来るだけシンプルに。
— 2026-07-19 22:49 UTC
続く指示は「地形の量子化をやめてみてみたい」「表示時間をリアルタイムにして」、そして「unityで3dにして」。見え方の確認のつもりで作ったものが、そのまま製品の土台になりました。
頼んでいないのに、テストと画面確認が付いてきた
ここが一番驚いた点です。単体テストも、Unity上でのキャプチャによる確認も、こちらから指示していません。
2026年7月21日のコミット「一旦実装してみて動いたバージョン」を開けると、実装と一緒に次が入っていました。
- テストファイル17本
-
AutoCapture.cs— Playモードを自動で進めて画面を撮る仕組み -
SceneBuilder.cs— 画面をコードで組み立てる仕組み
ログを遡ると、こちらが「テスト」という語を初めて口にしたのはその翌日で、しかも
「Coreの SetDigRect API は現存・テスト済みだが…」という、すでに在るものを指しての言及でした。
つまりテストは、頼む前から書かれていたことになります。
最終的にこの層はこう育ちました。
テストファイルは17本 → 66本、Core のテストは 302件になりました。
Unity を理解していない人間が判断できたのは、この層があったからです。「動いている」「テストが通っている」「画面が正しい」の3つを見て採否を決められる。もし出力されたコードを読んで妥当性を判断しろと言われていたら、この日数では無理でした。
第3日に、Unityが手から離れた
Unity を理解しないまま作り切れた理由はここにあります。
キモは シーンが手で編集されないことです。Main.unity は Git 管理外にして、SceneBuilder.Build がゼロから組み直す生成物にしてあります。だから Unity の GUI でシーンを触る場面がそもそもありません。
SceneBuilder.cs と AutoCapture.cs が入ったのは 2026年7月21日 — 着手から3日目でした。
確認もすべてコマンドから回ります。
UNITY="/Applications/Unity/Hub/Editor/6000.5.4f1/Unity.app/Contents/MacOS/Unity"
PROJ="/path/to/game"
# シーン再構築(コンパイルエラーの門番も兼ねる)
"$UNITY" -batchmode -nographics -quit -projectPath "$PROJ" \
-executeMethod Kotozute.Unity.EditorTools.SceneBuilder.Build -logFile /tmp/build.log
# Playモードで自動操作 → スクリーンショット
"$UNITY" -batchmode -projectPath "$PROJ" \
-executeMethod Kotozute.Unity.EditorTools.AutoCapture.Run -logFile /tmp/capture.log
Editor 専用ツールは最終的に 82ファイル、うち 73 がコマンドかメニューの入口を持っています。すべて Assets/Editor/ 配下で、製品のビルドには一切入りません。
Blender も同じ週に載りました。7月24日にヘッドレスで原点を直して書き出すスクリプト、7月25日に対話的な操作経路。以後、間引き・法線の焼き込み・葉と幹の分解・UV密度の検査・全周レンダーまで人の手を介さず回ります。
3. 素材:AIにアセットパイプラインを作らせる
ここが一番この作り方らしい部分です。アセット生成の仕組み自体もAIが書いています。
効いた設計
一発で出ないことを前提にしたのが最大の工夫です。
ほかに効いた仕掛け:
-
費用に見張りを付けた —
cost_guard.pyが上限を持ち、1回ごとにcost_log.csvへ記録。記録のある期間で 109回・38.98ドル -
ポリゴンに予算を持たせた —
poly_budget.pyが種別ごとの上限を握り、低ポリで頼むか後で落とすかを決める - 由来を申告しないと通らない — ビルドに載る素材は台帳に無いと検査で落ちる。「手元にあったから入れた」を仕組みで塞いだ
つまずいたところ
| 症状 | 原因と対処 |
|---|---|
| 竹筒32体が全部横倒し | Blenderの書き出しで bake_space_transform が効いていなかった。32体を一括で作り直し |
| 生成モデルが重すぎる | 61メッシュ合計 2,534万三角形。間引き・葉と幹の分解・板ポリ化で 37.0万 へ。ただし松は間引くと房が塊になるので針葉を描き直す工程を別に用意 |
| 岩に苔が塗れない | 生成モデルのUVが重なっていた。塗るまで気づけないので、UV重なり検査を通す決まりにした |
| 採否の判断を2回外した | 寄りの絵とポリゴン数で決めていた。ゲーム内に置いて遊ぶ距離から見るのが正解 |
Blender を対話的に操作する経路にも癖があり、軸を取り違える、Editモードでスクリーンショットが更新されないという罠がありました。見た目を信じると静かに間違うので、数値で確かめる手順に切り替えています。
いまマニフェストには162件が並び、うち110件が実際にゲーム内へ配置済みです。
4. 申請:訊きながら通す
App Store の申請は、この工程でいちばん難解でした。用語が独特で、どの画面に何があるか名前から分からず、依存関係が表に出ていません。
実際に詰まった箇所です。
| 詰まり | 実態 |
|---|---|
| Small Business Program が見つからない | 申し込みは App Store Connect ではなく Apple Developer サイト側 |
| ビルドが選択肢に出てこない | バージョンが 1.0.1、ビルドの版が 1.0.0。一致するビルドしか選べない |
| 課金が審査されない懸念 | 初回のIAPはアプリのバージョンと同じ提出に含める必要がある |
| iPadのスクリーンショットを要求される | ビルド設定の targetDevice が iPhone+iPad だった |
| プライバシーポリシー / サポートURL が必須 | 存在しなかったので、APIと同じ Worker から即日で配信 |
詰まるたびに App Store Connect の API で実際の値を読んで原因を特定しました。画面の文言だけを頼りに当てずっぽうで触っていたら、この日数では抜けられなかったと思います。
唯一、AIで速くならなかったところ
住所ひとつが、その先の全部を止めていました。途中で米国の W-8BEN(租税条約の軽減税率には外国の納税者番号が要る)、さらに台湾の税務情報まで現れて免税の証明書類を求められます。
契約が「処理中」から「有効」に変わったのは、気づいてからおよそ39時間後。手を動かす作業ではないので、待つ以外にできることがありません。この工程だけは、AIに任せても速くなりませんでした。
進み方:仕組みが先、中身が後
コミット数は作業量の指標になりません(最終日は詰めの調整で刻みが細かくなっただけで25コミットあります)。そこで 最後に残ったものを母数にして、その何割がその日までに存在したかを数えました。途中で作って捨てたものは母数に入りません。
3つを並べると、伸び方がまるで違います。
C#ファイルだけが斜めに伸び、あとの2つは終盤で垂直に立ち上がります。
| 日付 | C#ファイル (母数310) |
素材 (母数435) |
オブジェクト種別 (母数44) |
|---|---|---|---|
| 7/21 | 23% | 1% | 11% |
| 7/28 | 30% | 25% | 16% |
| 8/06 | 43% | 34% | 16% |
| 8/12 | 59% | 38% | 16% |
| 8/13 | 63% | 43% | 20% |
| 8/14 | 64% | 64% | 61% |
| 8/15 | 66% | 84% | 100% |
| 8/16 | 70% | 93% | 100% |
| 8/19 | 84% | 99% | 100% |
| 8/20 | 97% | 99% | 100% |
| 8/22 | 100% | 100% | 100% |
読み取れることは明確です。
- C#ファイルは初日から終盤まで均して伸び続ける
- 置けるオブジェクト種別は3週間ずっと16%のまま動かない。それが 8/13→8/15 のわずか3日で 20% → 100%
- 素材も 8/14→8/16 に 43% → 93% へ跳ねる
つまり 前半3週間は、中身を受け入れる器を作っていた。器ができてからは、AIが作ったものを流し込む速さでゲームが埋まっていきました。アセットパイプラインを早く作った効果がここに出ています。
人の作業時間をどう測ったか
「実質8人日」の根拠です。会話ログには発話ごとに秒単位の時刻が入っているので、そこから推定しました。
-
人間の発話だけを選り分ける(ツールの実行結果やシステムの注記が
userとして混ざっているため) - 直前の出来事から発話までの間隔を全部測る(読む → 考える → 打つ の時間)
- 5分未満はそのまま数える(その間ずっと画面の前にいた)
- 5分以上は離席とみなす。中身は捨て、「戻って読んで打つ」ぶんだけを1回1.5〜3分で加える
結果:
| 値 | |
|---|---|
| 発話 | 2,911回 |
| 5分未満の間隔 | 2,251回・合計 43.0時間(中央値 0.5分) |
| 5分以上(離席) | 660回(全体の23%) |
| 合計 | 60〜76時間 ≒ 8人日 |
**発話の23%は、指示を出してその場を離れています。**待っている間に別のことをしていられる作り方でした。
なお、この数字は控えめです。もう1台のマシンのセッションと、企画段階の会話(4.8〜6.5時間)が含まれていません。
制約・注意点
正直に書いておきます。
- **審査はまだ通っていません。**2026-08-22 に提出し、この記事を書いている時点では審査待ちです。「審査に出せた」までが確認できている事実です
- Unity を理解しないままなので、AIが出した設計の妥当性を人が判断できていません。動いている・テストが通っている・画面が正しい、で判断しています
- テストと検査の仕組みに強く依存しています。Core テスト302件、縦画面の文字サイズ検査、生成物の検査、素材の由来台帳。**「Unityがビルド成功と言っても信用しない」**類の門番を随所に置いてようやく回っています
- BGM だけは手作業が残っています(提供側にAPIが無いため)
- 実測できているのは iOS のみです。Android は配布経路まで、Switch は未着手です
おわりに
やってみて分かったのは、AIに任せられるかどうかは工程によってはっきり違うということでした。
企画・実装・素材は、人が判断する場面を残したまま、作業そのものは丸ごと渡せました。一方で申請の事務は、AIが手順を全部教えてくれても待ち時間は1秒も縮みません。
もうひとつ効いたのは、早い段階で仕組みを作ったことです。3日目に Unity のバッチ操作、6日目にアセットパイプライン。この2つが無ければ、後半の「3日でオブジェクト種別が0→100%」は起きなかったはずです。急いで中身を作るより、中身を受け入れる器を先に作るほうが速い、というのが一番の学びでした。
半信半疑で始めた検証としては、「作れる」で結論です。売り出すところまで行けたのは、正直なところ自分でも驚いています。
結局、最初の要件定義大事ってこと。
繰り返すが、isddは使っていない。
ops4.7以降は特に工夫しなくとも、コードはほぼ壊さなくなった。
今回、fable5が2割、ops5が8割な感じてコーディングさせてましたが、一度たりともコードが壊れた事もなく、設計書も書かせてましたが、特に指定せぶとも勝手に更新してるしで、isdd使わんで良い場面が多すぎ。要件定義だけしっかりしてればよい。