ひとりで小さなゲームを作るとき：AI に任せること、自分で判断すること

AI で数週間コードを書き、機能は動く。ところが核となるロジックを直そうとすると、アーキテクチャが絡み合って一箇所を触ると広く崩れる——そうして AI コードをすべて捨て、ゼロから書き直した開発者がいます。一方、AI で午後いっぱいに 8 つのミニゲーム原型を通し切った人もいます。以前なら一週間はかかっていた作業です。どちらも事実ですが、導く結論はまったく違います。

GDC 2026 のデータでは、AI がゲーム業界に悪影響を与えていると考える開発者は 52%。2 年前のおよそ 3 倍です。美術職の反対率は 64% で最も高く、経営層の AI 利用率は 47%、現場の実務層は 29% にとどまります。温度差ははっきりしています。AI は万能薬でも洪水でもなく、問題は境界線です。ひとりチームのインディーズほど境界感が要ります。AI を誤る代償はそのまま身にのび、使いこなせば効率は何倍にも伸びます。

本記事は「AI に何ができるか」は扱いません。そうした記事はすでに足りています。ここでは AI に何ができないか、そしてもっと重要な いつ自分が判断しなければならないか を語ります。

個別のタスクに向き合うとき、AI に任せるか、自分でやるか。答えは「できるか」ではなく「委ねるべきか」にあります。

AI が向くこと — 反復作業を AI に任せる

まず押さえておきたいのは、ゲーム開発で AI が本当に効く領域がいくつかある、ということです。「たぶん使える」ではなく、試して時間が削れる領域です。

1 年以上使い、失敗も成功も経験しました。AI に任せられるのは一類のタスクです。標準的な答えがある、反復が強い、クリエイティブ価値が低い ものです。

コード生成と補完

プロトタイプ検証では、AI の効率は目に見えます。

NetEase の深い記事では、企画がブレインストーミングで要件を分解し初稿を書き、Bot が傍聴して会議後に実行可能なプロトタイプコードを出す、という事例が紹介されています。以前は一週間かかっていた原型が、午後で終わる、という話です。

Zhihu にも似た声があります。数学の問題やエンジン API の知識は、AI が数秒で答えてくれる、と。「Unity の Animator の使い方、URP の RenderFeature の設定など、ドキュメントを引くと半日かかるが、AI なら一言で整理してくれる」という趣旨です。

私の体験も近いです。トップダウン RPG の基本移動ロジックでは、AI が出した骨組みをそのまま使えました。操作感の調整や衝突検出は自分で足しましたが、骨格は AI 生成です。

Sohu の実測では、40 分でトップダウン RPG デモの機能の約 70% ができた、とあります。信じられます。私もだいたいそのペースです。

ただしここで言うのは「骨組み」と「原型の検証」です。本番前には AI コードを自分の目で通し、最適化・リファクタリングが要るところはやる。本番品質を AI に期待しないこと、が前提です。

テキストの一括生成

ここは AI の得意分野です。NPC 会話、クエスト説明、アイテム説明、実績名——埋め草に近いテキストで、クリエイティブ度は低いが量が多いものです。

NetEase のライターは、「荷物運び」的な埋め草を AI に投げ、数分で終わらせ、自分で校正して表現を整え、AI 出力と照らし合わせる、と共有しています。

「AI を対照組にして、自分の書きに明らかな落差がないか見る」——この発想は実用的です。AI は代替ではなく、産出の校正役です。

Sohu のガイドでは、初心者向けクエストを 10 個、トリガー条件と報酬まで含めて生成できる、とあります。構造化されたコンテンツは AI が扱いやすいタイプです。

私はアイテム説明を約 50 件、AI で書きました。15 分。自分で書けば 2 時間はかかる。品質差はほぼありません。アイテム説明は高い創作性を要さず、正確・簡潔・世界観に合っていれば足りるからです。

アートのプロトタイプ生成

美術は議論が大きい一方、デモ段階では使えます。

Zhihu では、デモで AI の仮アートを使い「見た目も悪くない」とする声があります。ただしそのまま公開は無理——人体の誤り、スタイルのブレ、粗いディテールはプロの修正が要ります。

私もデモでキャラの色ブロックと背景を AI 生成しました。友人には「まあまあ」と言われましたが、公開用ではなく玩法検証用の仮装備だと分かっていました。

インディーズの視点では、予算がなくても可視化が要る段階で AI アートを使うのは現実的な選択です。

一時利用は可、正式リリースの美術としては不可。

アイデア拡張と原型検証

ここでは AI は「参考係」に近い役割です。

Sohu のガイドは Ludo.ai を挙げ、Steam や TapTap のデータからコンセプトを出す、と書いています。市場調査的な出力はデータ量・次元が多く、人力だけでは遅い領域です。

ACM の論文も、AI は創造プロセスを支えられるが創造の決定を置き換えるべきではない、と述べます。要するに選択肢を広げるのは AI、選ぶのは自分です。

私は GDD の骨子を AI に出させたことがあります。核となる玩法の説明を渡すと、5 つの拡張案が返ってきました。そこから 2 つを深掘りしました。AI の仕事は「幅を出す」ことで、「決める」ことではありません。

AI に任せられないこと — 自分で判断する領域

向くことを述べたうえで、任せてはいけない領域を述べます。こちらの方が重要です。AI を誤る代償は、使わないより高くなることが多いからです。

クリエイティブ判断とゲームフィール

核となる玩法、世界観、感情体験——ここは AI には届きません。

ACM の論文には、「AI にはゲームへの理解がない」とあります。コードの書き方は知っていても、「面白い」の感覚は知りません。

Medium の記事はもっと直截的で、ゲームの魔法はコードではなくフィールにある、と書きます。操作感、リズム、感情の流れは、開発者が体験しながら調整する領域です。

Stardew Valley の Eric Barone は、AI への懐疑を代表する声のひとつです。「人間の創造性は魂のない機械より上にあるべきだ」——極端に聞こえても、作者の立場では筋が通ります。農作業のリズム、村人との温かさ、収穫の満足感は、コードではなく設計者が磨き上げた体験です。

私は弾球ゲームを作りました。AI の物理パラメータは最初から動きました。しかしフィールが違いました。反発が硬すぎ、テンポが速すぎ、プレイヤーにコントロール感がありません。3 日かけ、パラメータを何度も変え、「気持ちいいが暴走しない」感覚を見つけました。

AI はコードをくれますが、フィールはくれません。

画風とビジュアルの統制

美術は議論が最大で、AI が最も事故りやすい領域です。

Zhihu では、人体構造の誤りはプロの修正が要る、とあります。指の本数、パース、光と影——プレイヤーはすぐ気づきます。

Reddit では、AI アートは「既定のアート方向に従えない」との不満があります。ピクセルが欲しいのにカートゥーン、寒色が欲しいのに暖色——スタイルの一貫性はゲーム美術の核で、AI はここが弱いです。

現場の美術は、AI 出力を直す方が描くより疲れる、と気づくことがあります。

私はデモでキャラ头像を AI 生成しました。5 人でスタイルがバラバラ——カートゥーン、リアル、ピクセル、アニメ、判別不能。結局削除し、美術に描き直してもらいました。

スタイルの一貫性は AI の弱点で、今のところ決定的な解はありません。

アーキテクチャ設計と問題の理解

ここが Reddit の「全部消して書き直した」話の核心です。

AI のコードは動きますが、アーキテクチャは絡みやすい。結合が強く、一箇所の変更が広く波及する——いわゆるアーキテクチャの悪夢です。

ACM は AI を「情報不足の同僚（Ill-Informed Co-Worker）」と呼びます。技術はあるが深い理解がない。実装方法は知っていても、なぜそうするか、将来どう効くかは分かりません。

Zhihu の開発者のまとめも的確です。「考え方の問題は、AI は助けにならない」。

考え方の問題とは、例えば次のようなものです。

• ゲームの核となるメカニクスは何か？
• 各システムはどう相互作用するか？
• 将来の拡張はどこに向かうか？
• 性能のボトルネックはどこか？

標準的な答えがなく、開発者が考える領域です。AI は補助に留まり、決定はできません。

Reddit の元スレには、「AI を使うとロールバックや調整の自由度が大きく下がる」とあります。設計が曖昧だと、直したいロジックの影響範囲が大きすぎて動かせなくなります。

セキュリティと保守のコントロール

SonarSource の分析では、AI コードに脆弱性が潜む可能性がある、と指摘しています。入力検証の欠落、権限チェックの抜け、機密データの露出——AI が見落としがちな細部が、公開後に致命傷になります。

ドイツ連邦情報セキュリティ局は、AI コードアシスタントには経験ある開発者の監督が要る、と勧めています。使わないのではなく、使ったあと人がレビューする、という立場です。

長期保守の視点では、問題はさらに隠れます。コメントもドキュメントも設計メモもないコードが多いからです。3 か月後に直そうとしても、当時の自分が読めない、となりがちです。

私も踏みました。AI 生成モジュールは公開後しばらく正常でした。半年後に機能追加でコードを開くと、変数名が乱れ、分岐が不自然で、コメントゼロ。結局 2 日かけてリファクタし、最初から自分で書いた方が早かった、という結末です。

AI は開発時間を短くしても、保守時間を短くするとは限りません。見落とされがちな点です。

判断フレームワーク — 委譲と自分でやる境界

「向く／向かない」を述べても、実務のタスクはそのあいだにあります。そのとき判断の枠組みが要ります。

知識系の問いと設計・感性系の問い

Zhihu では実用的な切り分けが紹介されています。「知識系は AI、考え方は自分」。

知識系とは、絶対的な正解がある問いです。例えば次のようなものです。

• Unity の Animator でステートマシンをどう組むか？
• Cocos Creator で衝突検出をどう実装するか？
• この数式はどう計算するか？

答えが一意で検証できるので、AI が正確に答えられます。

設計・感性系とは、正解が一つに定まらず、美的感覚と経験が要る問いです。例えば次のようなものです。

• 核となる玩法は面白いか？
• 世界観は一貫しているか？
• 操作感は心地よいか？

答えはあなたの感性、想定プレイヤー、設計思想に依存します。AI には答えられません。

私の習慣は、まず「この問いに標準的な答えがあるか？」と自分に聞くことです。

あれば AI に聞く。なければ自分で考える。

ジャンプの実装なら、AI はコードの骨組みを出せます。しかし高さ、滞空時間、着地のフィードバックは自分で詰めます。フィールに標準答えはないからです。

プロトタイプ段階と本番段階

段階の切り分けも効きます。

プロトタイプでは、アイデアが成立するかを見るのが目的で、公開品質ではありません。コードは動けばよい、アートは色塊でよい、テキストは粗くてよい——この段階では AI を大胆に使えます。

本番ではプレイヤー向けの完成体験を追います。コードの整理、美術の精緻化、テキストの推敲——人の目で握る領域が増えます。

Sohu の「40 分で RPG デモの 70%」はプロトタイプの話です。同じものを製品化するなら、残り 30% の核機能、アーキテクチャの整理、美術差し替え、テキスト校正で 40 分どころでは済みません。

NetEase の事例も同型で、午後に原型を走らせ、本番開発は自分で握る、という流れです。

私の弾球デモは、AI コードで 20 分で動きました。公開可能にするのにさらに 2 週間——フィール調整、性能、ステージ、UI です。

プロトタイプでの AI は加速、本番での AI は慎重に。

反復作業と核となるクリエイティブ

もっと直感的な軸もあります。

反復作業は、クリエイティブ価値が低く、時間がかかり、パターンが繰り返されるもの。NPC 会話の量産、アイテム説明の埋め草、実績名などです。

核となるクリエイティブは、ゲームの魂を決めるもの。分岐設計、核メカニクスの革新、キャラの性格づけなどです。

反復は AI に任せて時間を節約し、品質の芯は損なわない。核は自分が握り、競争力の源泉を守る。

NetEase のライターは、埋め草は AI、物語の芯は自分、という分担です。

私は NPC 会話を約 100 件書きました。日常の雑談やツッコミは AI で 15 分。メインストーリー、悪役の重要な台詞、感情の転換——ここは 2 日かけて自分で書きました。

反復は AI、核は自分。この分担が効率と品質のバランスを取ります。

簡単な判断表です。

タスクの種類	AI	自分	理由
知識系の問い	✅	❌	標準的な答えがある
設計・感性系	❌	✅	美的判断が要る
プロトタイプ段階	✅ 補助	✅ 統制	成立性の検証
本番段階	❌	✅	品質の追求
反復作業	✅	❌	クリエイティブ価値が低い
核となるクリエイティブ	❌	✅	クリエイティブ価値が高い

タスクごとに 3 問です。

1. 絶対的な正解があるか？
2. 自分の美的判断が要るか？
3. プロトタイプか本番か？

この 3 つで、だいたい答えは出ます。

実践 — 職種ごとの AI の境界

枠組みを職種に当てはめます。仕事の性質が違えば、AI の境界も違います。

企画

企画は領域が広く、AI の使いどころも多いです。

NetEase では、ブレインストーミングで要件分解と初稿、Bot の傍聴記録、会後の実行可能な原型コード——企画職で典型的な使い方です。考えを素早く検証可能な形にする。

一方、世界観、核玩法、ストーリー骨格といったクリエイティブ判断は AI には任せられません。

玩法案を AI に 10 個出させ、3 つを深掘りした企画も見ました。AI は幅を出す役で、決めるのは自分です。

企画の境界：

• AI：要件分解、初稿、ブレスト記録、原型コード
• 自分：世界観、核玩法、クリエイティブ判断、ストーリー構造

ライター

ライター職は比較的切り分けやすいです。

NetEase では、埋め草は AI、物語の芯は自分。AI 出力で自分の文を校正する、という流れです。

具体的には次のとおりです。

• AI：NPC の日常会話、アイテム説明、実績名、クエスト説明
• 自分：メインストーリー、主要キャラの台詞、世界観テキスト、感情の転換

あるゲームでは、天気の話や商売の愚痴は AI、悪役の決め台詞や性格を示す会話は自分で書きました。言葉一つひとつに感情を載せるからです。

AI の埋め草は時間を節約しますが、感情の芯は自分が握ります。

プログラマー

プログラマーは AI 利用が最も多く、議論も大きい職種です。

GDC では 36% が AI を使うが、主にコードとワークフローで、資産生成ではない、とあります。受容は比較的高い一方、範囲には境界があります。

ACM は、経験ある開発者が AI コードを監督し脆弱性を防ぐべきだ、と勧めます。

プログラマーの境界：

• AI：補完、API の説明、数学、原型検証
• 自分：アーキテクチャ、複雑ロジック、性能、セキュリティ、長期保守

Reddit の「全部消して書き直し」は、過度な依存の反面教師です。動くが絡み合い、後から直せない、というパターンです。

私は、AI に骨組み、自分に核ロジックと設計、という分担です。単純関数・反復・ドキュメント調べは AI。システム設計、性能クリティカル、セキュリティは自分です。

美術

美術は最も慎重な職種です。

Reddit：AI アートは既定のアート方向に従いにくい。Zhihu：人体の誤りはプロ修正が要る。

美術の境界：

• AI：プロトタイプの仮アート、デモ用素材、色塊の代用
• 自分：人体修正、スタイル統制、ビジュアル品質、本番アセット

私もデモ头像を AI で作り、スタイルが揃わず削除して描き直しました。デモでは使えても、本番美術としては無理、という教訓です。

美術の価値は一貫性にあります。AI 出力はスタイルが散り、直す方が描くより重い——現状、決定的な解はありません。

職種比較表です。

職種	AI 利用率	AI が担う	自分が担う	反対・議論
企画	中高	要件分解、原型コード	世界観、核玩法	低め
ライター	中高	埋め草、NPC 会話	メインストーリー、台詞	低め
プログラマー	最高	補完、API 照会	設計、セキュリティ	中程度
美術	最低	デモ仮アート	スタイル、人体修正	最高

クリエイティブ度が低い職種ほど AI 受容が高く、高い職種ほど警戒が強い、という傾向が読み取れます。

NetEase で経営層 47%、現場 29%——現場は毎日使い、何が信頼でき何がダメかを知っているから、温度差が出やすい、という見方もできます。

まとめ

冒頭の Reddit の話に戻ります。AI コードを捨てて書き直したのは、AI 否定ではなく境界を見つけた、という意味に近いです。

Sealos のブログには、AI は道具であって建築家ではない、とあります。道具は敷居を下げ、方向は建築家——インディーズ開発者——が決める。AI は加速器にすぎません。

GDC のデータと NetEase の事例は、同じ答えを指します。反復は AI、核となるクリエイティブは自分。

「全部 AI」か「全部自分」ではなく、分担です。任せるものは任せ、守るものは守る。

3 つの習慣です。

1. 知識系か設計・感性系か を意識する。標準答えがなければ、まず自分で考える。
2. プロトタイプか本番か を区別する。原型は大胆に、本番は慎重に。
3. AI を使うたびに問う：クリエイティブ価値は高いか？美的判断が要るか？長期保守に効くか？

これらの問いに AI は答えられません。インディーズ開発者の核となる能力——判断力——への問いです。

判断力は経験から来ます。AI を使うだけでは判断力は育たず、依存だけが増えます。判断力は、判断を重ねたなかでしか育ちません。

AI は良い道具です。でも、判断まで代わりにさせないでください。

---

具体的な AI の使い方は、本シリーズ第 13 篇『AI で Cocos ミニゲーム開発を補助：私のワークフローと効率比較』を参照してください。AI への要件の書き方は第 14 篇『AI にミニゲーム開発要件を書く：シーン・ノード・コンポーネント・インタラクションの説明』が扱います。本記事は判断の枠組み、続編は実践の手順です。