インディーズゲーム開発：AIに任せるべきタスクと自分で判断すべきこと

Redditで印象的な投稿がありました。ある開発者がAIで数週間コードを書き、機能はすべて動いていました。しかし、核心ロジックを変更しようとした時、アーキテクチャ全体が絡み合っており、一箇所変えると一面が壊れる状態だと気づきました。結局、すべてのAIコードを削除し、ゼロから書き直しました。

一方で、Mediumでは、AIで午後に8つのミニゲームプロトタイプを完成させたという報告がありました。以前ならこの作業量には少なくとも1週間はかかっていたはずです。

この2つの体験はどちらも真実ですが、全く異なる結論を示しています。

GDC 2026のデータはさらに衝撃的です。52%の開発者がAIがゲーム業界にネガティブな影響を与えると考えており、2年前の3倍近くに増加しています。アーティスト職の反対率が最も高く、64%です。一方、NetEaseの調査では、経営層のAI使用率は47%ですが、現場の実務層は29%のみ。この温度差は明確です。

これは何を示しているのでしょうか？AIはゲーム開発において万能薬でもなければ、洪水猛獣でもありません。問題は境界線にあります。

インディーズ開発では特に境界感覚が必要です。一人チームには冗長な人員がおらず、AIを間違って使う代償は現実的です。時間の浪費、アーキテクチャの崩壊、スタイルの制御不能。しかし、正しく使えば効率は数倍に跳ね上がります。

この記事では、AIが何をできるかは語りません。その種の記事はすでに十分あります。私が語るのは、AIが何をできないか、そしてより重要なことに、いつ自分で判断しなければならないかです。

核心的な問いはシンプルです：具体的なタスクに直面した時、AIに任せるべきか、自分でやるべきか？答えは「できるか」ではなく「べきか」にあります。

AIができること — 反復的な作業をAIに任せる

まず明確にしておきましょう：ゲーム開発においてAIが本当に使いやすい分野がいくつかあります。「もしかしたら使えるかも」ではなく、実際にテストして時間を節約できるものです。

1年ほど使って、失敗も成功も経験しました。結論として、AIに任せられるのは1つのタイプのタスクです。標準的な答えがある、反復性が高い、クリエイティブ価値が低いものです。

コード生成と補完

プロトタイプ検証において、AIの効率は目に見えて向上します。

NetEaseの深い記事で紹介されたケース：企画がブレインストーミング会議で要件を分解し、初稿を書き、Botが傍聴して会議後に実行可能なプロトタイプコードを出力。以前ならこの種のプロトタイプに1週間かかっていたのが、今では午後1つで完了します。

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のガイドには、AIは初心者向けステージのクエストを10個生成でき、トリガー条件と報酬メカニズムを含めるとあります。この種の構造化されたコンテンツは、AIが非常にスムーズに処理します。

私はAIでアイテム説明を1セット書きました。約50個。所要時間：15分。自分で書くなら少なくとも2時間。品質の差：ほとんどありません。アイテム説明自体が高いクリエイティブ性を必要とせず、正確で簡潔で、世界観に合っていればいいからです。

アートプロトタイプ生成

アート分野は最も議論が多いですが、デモ段階では実際に使えます。

Zhihuのある開発者がシェアしてくれました：デモ段階ではAIで一時的なアートを生成し、「見た目も悪くない」。重要なのは、そのままリリースすることを期待してはいけないことです。人体構造のエラー、スタイルの不一致、ディテールの粗さ。これらはすべてプロのアーティストが修正する必要があります。

私はあるデモを作り、AIでキャラクターの色ブロックとシーン背景を生成しました。友人に見せると「まあまあ」と言われました。しかし、これはあくまで一時的なソリューションだと分かっており、本当にリリースするならアーティストに描いてもらう必要があります。

インディーズ開発者の視点から見ると、デモ段階でAIアートを使うのは現実的な選択です。アーティストを雇う予算がなく、ゲームプレイを検証するための可視化が必要だからです。

重要なのは：一時的に使うのはいいが、正式リリースではだめ。

アイデア拡張とプロトタイプ検証

この分野でAIの役割は「参考アシスタント」に近いです。

SohuのガイドではLudo.aiが紹介されており、SteamやTapTapのデータを分析してゲームコンセプトを生成できるとあります。この種の市場調査的な出力は、AIの方が人間より速いです。データ量が多く、次元が多く、人力分析が遅すぎるからです。

ACMの論文も触れています：AIはクリエイティブプロセスをサポートできるが、クリエイティブな意思決定を置き換えるべきではない。要するに、AIは選択肢をたくさん出せるが、どれを選ぶかは自分で決めることです。

私はAIでGDDフレームワークを生成したことがあります。核心的なゲームプレイの説明を与えると、AIは5つの可能な拡張方向を出力します。その中から2つを選んで深く考えました。AIの仕事は「考えを広げる」ことで、「決定する」ことではありません。

AIができないこと — これらは自分で判断する必要がある

前節ではAIに任せられることを話しましたが、今度は任せられないことを話します。

こちらの方が重要です。AIを間違って使う代償は、使わないよりも高いことが多いからです。

クリエイティブな意思決定とゲームフィール

核心的なゲームプレイ、世界観、感情体験。これらはAIには本当にできません。

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

Mediumの記事はもっと直截的です：ゲームの魔法はコードにではなく、「フィール」にあります。操作感、リズム、感情の流れ。これらは開発者が自分で体験し、調整する必要があります。

Stardew Valleyの作者Eric BaroneのAIに対する態度は、業界の反対派の代表です。彼は「人間の創造性は魂のない機械より優先されるべきだ」と言いました。少し極端に聞こえますが、クリエイターの視点からは正しいです。農場ゲームのリズム感、村人との交流の温かさ、収穫時の満足感。これらはコードで表現できるものではなく、デザイナーが繰り返し磨き上げた体験です。

私はバウンスボールゲームを作ったことがあります。AIが提供する物理パラメータは最初から動きました。しかし「操作感」が違いました。ボールの反発が硬すぎ、リズムが速すぎ、プレイヤーにコントロール感がありませんでした。3日間調整し、無数のパラメータを変え、「爽快だがコントロールを失わない」感覚を見つけました。

AIはコードを提供できますが、「操作感」は提供できません。

アートスタイルの管理

アートは最も議論が多い分野であり、AIが最も問題を起こしやすい分野でもあります。

Zhihuのフィードバックでは、AIが生成する人体構造のエラーはプロのアーティストが修正する必要があるとあります。指の数が違う、パース関係が混乱している、光と影の調和が取れていない。これらはAIによくある問題で、プレイヤーは一目で気づきます。

Redditでは、AIアートは「既定のアート方向に従えない」という不満があります。ピクセルスタイルが欲しいのに、AIはカートゥーンスタイルをくれる。寒色系が欲しいのに、AIは暖色系にする。スタイルの一貫性はゲームアートの核心であり、AIはこの点でほぼ壊滅的です。

現場のアーティストはAIを使った後、AIが提供するものは信頼できず、修正する方が描くより疲れると気づきました。

私はあるデモでAIでキャラクターのアバターを生成しました。結果、5人のキャラクターのスタイルが全く一致していません。カートゥーン、リアル、ピクセル、アニメ、何スタイルか分からないのがそれぞれ1つずつ。最後は削除してアーティストに描き直してもらいました。

スタイルの一貫性はAIの弱点で、現在解決策はありません。

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

ここはRedditで「すべてのコードを削除してゼロから書いた」ケースの核心的な問題です。

AIが提供するコードは動きますが、アーキテクチャは絡み合っています。機能間の結合が深刻で、一箇所変えると一面に影響します。この種のコードを「アーキテクチャの悪夢」と呼びます。

ACM論文はAIを「情報不足の同僚」と表現しています。技術能力はあるが、深い理解が欠けている。機能の実装方法は知っているが、なぜそのように実装するのか、その実装が将来にどう影響するかは知りません。

Zhihuの開発者がうまくまとめています：「考え方の問題は、AIは助けにならない。」

考え方の問題とは何か？例えば：

• ゲームの核心メカニズムは何か？
• 各システム間でどう相互作用するか？
• 今後の拡張方向は何か？
• パフォーマンスのボトルネックはどこか？

これらの質問に標準的な答えはなく、開発者が自分で考える必要があります。AIは補助できますが、決定はできません。

Redditの元記事にこうあります：「AIを使うと、ロールバックと調整の能力が著しく制限される。」アーキテクチャが明確でないため、あるロジックを変えようとすると、影響範囲が大きすぎて変えられなくなります。

セキュリティとメンテナンスの管理

SonarSourceの分析では、AIコードにはセキュリティの脆弱性が隠れている可能性があると指摘しています。入力検証の欠如、パーミッションチェックの遺漏、機密データの露出。AIが見落としがちなこれらのディテールは、リリース後に致命的な問題になります。

ドイツ連邦情報セキュリティ局の推奨は、AIコードアシスタントには経験豊富な開発者の監督が必要だというものです。完全に使わないのではなく、使った後に人力でレビューする必要があります。

長期的なメンテナンスの視点から見ると、AIコードの問題はより隠れています。提供されるコードにはコメント、ドキュメント、設計説明がないことが多いからです。3ヶ月後に修正しようとすると、どう書いたのか自分でも分からなくなります。

私はこの失敗を経験しました。AIが生成したモジュールは、リリース後正常に動作していました。半年後に新機能を追加しようとコードを開くと、完全に見知らぬものでした。変数名が混乱し、ロジックのジャンプが奇妙で、コメントがない。結局2日かけてリファクタリングし、当初自分で書くより遅かったです。

AIは開発時間を節約できますが、メンテナンス時間を節約できるとは限りません。多くの人がこれを見落としています。

判断フレームワーク — いつ委譲し、いつ自分でやるか

前の2つのセクションで「できること」と「できないこと」を話しましたが、実際の開発で遭遇するタスクは両者の間にあることが多いです。

そんな時、判断フレームワークが必要です。

知識タイプの問題 vs 考え方の問題

Zhihuの開発者が実用的な判断方法をまとめてくれました：「知識タイプの問題はAIに、考え方の問題は自分で。」

知識タイプの問題とは何か？絶対的な正解があるものです。例えば：

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

これらの質問はAIが正確に答えを提供できます。答えが唯一で、検証可能だからです。

考え方の問題とは何か？絶対的な正解がなく、美的感覚と経験の判断が必要なものです。例えば：

• 核心的なゲームプレイは面白いか？
• 世界観は一貫しているか？
• 操作感は滑らかか？

これらの質問にはAIは答えられません。答えはあなたの美的感覚、ターゲットオーディエンス、設計哲学に依存するからです。

私自身の判断習慣は、問題に遭遇したらまず自分に問いかけることです。「この問題に標準的な答えがあるか？」

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

例えばジャンプロジックを書く場合、AIはコードフレームワークを提供できます。しかし、ジャンプの高さはどれくらいが適切か？空中滞在時間はどれくらいか？着地のフィードバックはどうするか？これらは自分で調整する必要があります。「操作感」に標準的な答えがないからです。

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

段階の判断も重要です。

プロトタイプ段階では、目標はアイデアの実現可能性を検証することであり、リリース品質ではありません。この時は大胆にAIを使えます。コードは動けばいい、アートは色ブロックで代用、文案は適当に書く。

本番段階では、プレイヤーに向けて、完全な体験を追求します。この時は人力で管理する必要があります。コードはリファクタリング、アートは修正、文案は磨き上げ。

Sohuの実測データ：40分でRPGデモの70%の機能を完了。これはプロトタイプ段階での話です。このデモを正式リリース製品にするには、40分では遠く及びません。残り30%の核心機能を完成させ、アーキテクチャをリファクタリングし、アートを置き換え、文案を校正する必要があります。

NetEaseのケースも同様です。企画がAIで午後にプロトタイプを走らせましたが、その後の正式開発は自分で管理しました。

私はバウンスボールゲームのデモを作り、AIが提供するコードは20分で動きました。しかし、リリース可能なバージョンにするには、さらに2週間かかりました。操作感を調整し、パフォーマンスを最適化し、ステージを設計し、UIを完成させるためです。

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

反復的なタスク vs 核心的なクリエイティブ

この判断基準はより直感的です。

反復的なタスク：クリエイティブ価値が低い、時間がかかり手間がかかる、反復性が高い。例えばNPC会話のバッチ生成、アイテム説明の埋め草、実績名の生成。

核心的なクリエイティブ：クリエイティブ価値が高い、ゲームの魂を決める。例えばストーリーブランチの設計、核心メカニズムの革新、キャラクターの性格形成。

反復的なタスクはAIに任せ、時間を節約し、品質に影響しない。
核心的なクリエイティブは自分で管理し、ゲームの核心競争力を決める。

NetEaseのライターのアプローチは、埋め草の文案をAIに投げ、核心的なナラティブは自分で書く。こうすることで時間を節約しながら、クリエイティブを犠牲にしません。

私はNPC会話システムを書いたことがあります。約100個。日常会話、立ち話、ストーリーと無関係なツッコミ。これらはAIで生成し、15分で完了。しかし、メインストーリー、主要キャラクターのセリフ、感情の転換点。これらは自分で書き、2日かかりました。

反復的な作業はAIに、核心的なクリエイティブは自分で。この分担が効率を最大化する。

簡単な判断表を使えます：

タスクタイプ	AIが処理	自分が処理	理由
知識タイプの問題	✅	❌	標準的な答えがある
考え方の問題	❌	✅	美的判断が必要
プロトタイプ段階	✅ 補助	✅ 管理	実現可能性の検証
本番段階	❌	✅	品質の追求
反復的なタスク	✅	❌	クリエイティブ価値が低い
核心的なクリエイティブ	❌	✅	クリエイティブ価値が高い

あるタスクに直面するたび、自分に3つの質問をしてください：

1. このタスクに絶対的な正解があるか？
2. このタスクに私の美的判断が必要か？
3. このタスクはプロトタイプ段階か本番段階か？

3つの質問で、答えはほぼ明確になります。

実践ケース — 異なる職種のAI使用境界

前節では判断フレームワークを話しましたが、今度は具体的な職種でどう適用するか見てみましょう。

職種によってタスクの性質が異なり、AI使用の境界も異なります。

企画職

企画の仕事範囲は広く、AI使用シーンも多いです。

NetEaseのケース：企画がブレインストーミング会議で要件を分解し、初稿を書き、Botが傍聴して記録し、会議後に実行可能なプロトタイプコードを出力。これは企画職におけるAIの最も典型的な使い方です。アイデアを素早く検証可能なものに変える。

しかし企画の核心的な仕事はクリエイティブな意思決定です。世界観設計、核心的なゲームプレイ、ストーリー構造。これらはAIにはできず、自分で管理する必要があります。

ある企画がAIで10個のゲームプレイ案を生成し、その中から3つを選んで深く考えたのを見たことがあります。AIの役割は「考えを広げる」ことで、「決定する」ことではありません。

企画職のAI使用境界：

• AIがやる：要件分解、初稿作成、ブレインストーミング記録、プロトタイプコード出力
• 自分がやる：世界観設計、核心的なゲームプレイ、クリエイティブな意思決定、ストーリー構造

ライター職

ライター職のAI使用は比較的明確です。

NetEaseのライターがシェアしてくれました：埋め草の文案をAIに投げ、核心的なナラティブは自分で書く。その後、AIの出力を基準に自分の産出を校正する。

具体的には：

• AIがやる：NPCの日常会話、アイテム説明、実績名、クエスト説明
• 自分がやる：メインストーリー、主要キャラクターのセリフ、世界観文案、感情の転換点

私はあるゲームのNPC会話システムを書いたことがあります。日常の立ち話、ストーリーと無関係なコンテンツはAIで生成しました。「今日はいい天気だね」「最近、商売がうまくいかない」など。しかし、メインストーリー、悪役の重要なセリフ、キャラクターの性格を形成する会話。これらは自分で書きました。すべての文字が感情を乗せる必要があるからです。

AIが提供する埋め草の文案は時間を節約しますが、感情を乗せません。文案の核心的な価値は感情にあり、この部分は自分で管理する必要があります。

プログラマー職

プログラマーはAI使用が最も頻繁な職種であり、最も議論が多い職種でもあります。

GDCデータでは、36%がAIを使用していますが、大部分はコードとワークフローに使われ、アセット生成ではありません。これはプログラマーのAI受容度が比較的高いことを示していますが、使用範囲にも境界があります。

ACM論文の推奨：経験豊富な開発者はAIコードを監督し、セキュリティの脆弱性を防ぐ必要があります。完全に使わないのではなく、使った後にレビューする必要があります。

プログラマー職のAI使用境界：

• AIがやる：コード補完、API知識の回答、数学計算、プロトタイプ検証
• 自分がやる：アーキテクチャ設計、複雑なロジック、パフォーマンス最適化、セキュリティ管理、長期メンテナンス

Redditで「すべてのコードを削除してゼロから書いた」ケースは、プログラマーがAIに過度に依存した反面教師です。AIが提供するコードは動きますが、アーキテクチャが絡み合っており、後で変更できません。

私自身のコードを書く習慣は、AIにフレームワークを与えさせ、自分で核心ロジックとアーキテクチャ設計を補完する。単純な関数、反復的なコード、ドキュメント検索。これらはAIを使う。しかし、システムアーキテクチャ、パフォーマンスの重要なパス、セキュリティ関連のコード。これらは自分で書く。

アーティスト職

アーティストはAI使用が最も慎重な職種です。

Redditのフィードバック：AIアートは「既定のアート方向に従えない」。

Zhihuのフィードバック：AIが生成する人体構造のエラーは、プロのアーティストが修正する必要がある。

アーティスト職のAI使用境界：

• AIがやる：プロトタイプ段階の一時的なアート、デモ展示素材、色ブロックの代用
• 自分がやる：人体構造の修正、スタイル一貫性の管理、ビジュアル品質、リリース用アート

私はあるデモでAIでキャラクターのアバターを生成しました。結果、スタイルが一致せず、最後は削除してアーティストに描き直してもらいました。この教訓で私は理解しました：AIアートはデモ段階では使えるが、正式リリースではだめ。

アートの核心的な価値はスタイルの一貫性にあります。AIが提供するものはスタイルが混乱しており、修正する方が描くより疲れる。この点は現在解決策がありません。

職種比較表を使えます：

職種	AI使用率	AIが処理	自分が処理	反対率/議論
企画	中高	要件分解、プロトタイプコード	世界観、核心的なゲームプレイ	較低
ライター	中高	埋め草文案、NPC会話	メインストーリー、キャラクターセリフ	較低
プログラマー	最高	コード補完、APIクエリ	アーキテクチャ設計、セキュリティ管理	中等
アーティスト	最低	デモ一時アート	スタイル管理、人体修正	最高

この表から分かること：クリエイティブ性が低い職種ほど、AI受容度が高い。クリエイティブ性が高い職種ほど、AIに対する警戒が強い。

NetEaseの経営層AI使用率は47%、現場の実務層はわずか29%。この温度差の背後には、現場の社員がAIの限界をよりよく理解していることがあります。彼らは毎日使って、何が信頼できて何が信頼できないかを知っています。

結論

最初のReddit開発者の物語に戻りましょう。彼はすべてのAIコードを削除し、ゼロから書き直しました。これはAIを否定しているのではなく、正しい境界を見つけたのです。

Sealosブログにはこうあります：AIは「道具」であり、「建築家」ではない。道具は敷居を下げるが、建築家が方向を決める。インディーズ開発者は依然としてクリエイティブディレクターであり、AIは単なる加速器です。

最も成功するパターンは何か？GDCデータとNetEaseのケースは同じ答えを指しています：AIが反復的なタスクを処理 + 自分が核心的なクリエイティブを管理。

これは「すべてをAIに任せる」または「AIを全く使わない」の二者択一ではありません。分担です。AIに任せるべきものは任せ、任せるべきでないものは自分で守る。

3つの判断習慣：

1. 「知識タイプ vs 考え方」の意識を持つ。問題に遭遇したら最初に問いかける：これに標準的な答えがあるか？なければ、自分で考える。

2. 「プロトタイプ段階 vs 本番段階」を区別する。プロトタイプでは大胆にAIを使い、本番では慎重に管理する。

3. 毎回AIを使う時に自分に問いかける：このタスクのクリエイティブ価値は高いか？私の美的判断が必要か？長期メンテナンスに影響するか？

これらの質問にはAIは答えられません。それらはインディーズ開発者の核心的な能力である判断力です。

判断力は経験から来ます。AIを使っても判断力は積み重ならず、依存だけが積み重なります。判断の中でだけ判断力が積み重なります。

AIは良い道具ですが、あなたの代わりに判断させないでください。

---

具体的なAIの使い方を知りたいですか？本シリーズ第13回『AIでCocosミニゲーム開発を補助：私の完全なワークフローと効率比較』をご覧ください。詳細な方法が記載されています。AIに要件をどう書くか学びたいですか？第14回『AIにミニゲーム開発の要件を書く：シーン、ノード、コンポーネント、インタラクションの説明方法』をご覧ください。この記事は判断フレームワークを提供し、以降の記事は具体的な実践を提供します。