プログラミング経験ゼロの人が、3Dの戦闘機ゲームを作れると思いますか？
しかも、たった4日でです。
普通に考えれば無理でしょう。
フライト物理、ミサイルの挙動、敵AI。
どれか一つでも、初心者には高いハードルです。
ところが最近、海外の掲示板Redditである投稿が大きな話題を集めました。
「Claudeと一緒に戦闘機ゲームを作っている」という内容です。
どんなゲームが作られたのか
投稿者が公開したのは、ローポリスタイルの戦闘機ゲームです。
動画では、ジェット機が空母から発艦します。
そして、広大なマップを飛び回り、ミサイルや爆弾で敵と戦います。
しかも、単に飛べるだけではありません。
複数の機体を選べる格納庫があります。
敵とのドッグファイトを制御するAIも実装済みです。
さらに、戦闘後に映画のようなアングルで見返せるリプレイシステムまで備えています。
これを見たコメント欄は騒然としました。
「魔法だ」「10年前にこの光景を想像できたか」といった驚きの声が並びます。
また、往年のフライトシューティングゲームを懐かしむ人も多くいました。
ちなみに、コメント欄で最も突っ込まれたのは技術面ではありません。
「F-16は空母艦載機じゃないぞ」という航空ファンからの指摘です。
投稿者いわく、空母はテスト用に置いているだけとのこと。
こういうやり取りで盛り上がるのも、コミュニティの面白いところですね。
驚くべきは投稿者の経歴
この事例で本当に注目すべきは、ゲームの出来栄えではありません。
投稿者の経歴です。
本人の説明によれば、これまで一度もコードを書いたことがないそうです。
それどころか、使用したゲームエンジンの名前すら聞いたことがなかったといいます。
ゲーム制作自体、これが人生で初めてだと語っています。
その状態から、4日間の集中作業でここまで到達しました。
もちろん、疑いの声もありました。
「これくらいのコードは数行で書ける。経験者なら1日でできる」と冷ややかに評するコメントもあります。
ただ、それに対しては反論も出ています。
飛行制御、UI、マップ上の位置表示など、複数のシステムが連携している点を評価する意見です。
「プロのチームでも、もっと時間がかかることがある」とも述べられていました。
どちらの見方にも一理あるでしょう。
しかし、未経験者が4日でここまで形にできる時代になった。
この事実自体は否定できません。
開発の進め方：投稿者は「監督」に徹した
では、具体的にどう作ったのでしょうか。
コメント欄での質疑応答から、開発スタイルが見えてきます。
使用したのは、無料のゲームエンジンGodotです。
コードはGDScriptで書かれています。
そして、その記述とデバッグをClaude Codeが担当しました。
利用上限に達したときは、別のClaudeモデルに切り替えて作業を続けたそうです。
3Dモデルは自作していません。
飛行機やミサイルのモデルは、Sketchfabなどで配布されている無料アセットを利用しました。
そして投稿者は、こう指示します。
「ここに機体のモデルがある。これをゲームに組み込んで」と。
つまり、投稿者はコードを書く人ではなく「監督」なのです。
アイデアを出し、AIに指示し、動作を確認する。
この役割分担が、未経験者でも開発を成立させた鍵と言えます。
もう一つ重要なのが、進め方の順序です。
投稿者は、一度に全部を作ろうとしませんでした。
具体的には、次の順番で進めています。
- まずフライト物理だけに集中し、納得いくまで調整する
- それが終わってから、マップに取りかかる
- 最後に、グラフィックへ進む
一つずつ潰していくスタイルです。
「大量のプロンプトとデバッグの繰り返しだった」と本人も認めています。
ゲームにはまだバグが山ほどあり、完璧には程遠いそうです。
つまり、魔法の一発プロンプトで完成したわけではありません。
なお、プロンプト作成にはChatGPTを併用していたという裏話も明かされました。
コメント欄に埋もれた実践テクニック
このスレッドで見逃せないのは、経験者たちが書き込んだ実践的なノウハウです。
むしろ、本文より価値があるかもしれません。
あるコメントは、GodotでClaudeを使う際の工夫を具体的に共有していました。
ポイントは二つあります。
一つ目は、GDScriptで厳格な型付けを使うようClaudeに徹底させることです。
規律を持たせないと、コードの品質が安定しないようです。
二つ目は、使用中のバージョンのGodot公式ドキュメントを手元に保存すること。
そして、それを「唯一の正しい情報源」として参照させることです。
なぜ、こんな手間をかけるのでしょうか。
理由は、AIの学習データにあります。
AIは古いバージョンの知識を含んでいます。
そのため、何も指定しないと昔の書き方を混ぜてくるのです。
しかし、ローカルのドキュメントを基準にすれば、この問題を防げます。
この工夫をした結果はどうだったのか。
「キャラクターモデルを渡して、三人称視点のコントローラーにして、と頼むだけで一発で動いた」とのこと。
使いこなしている人は、環境の整備から違います。
また、Unityで思うような結果が出ないと嘆く人もいました。
その人には、GitHubで公開されているUnity用のMCPパッケージを勧めるコメントが付いています。
エンジンとAIをつなぐMCPの活用は、今後さらに広がりそうです。
「AIスロップ」批判と、その先にある問い
スレッドには、こんな問いを投げかけるコメントもありました。
「AIだけで作った個人プロジェクトに、誇りを感じられるのか？」と。
一方で、別のコメントはこう線を引きます。
これは「雰囲気だけのコーディング」とは違う。
AIの支援を受けた開発であり、Claudeの本来の使い方だ、という主張です。
あなたはどう考えますか？
私は、この事例が示すのは役割の変化だと捉えています。
たしかに、投稿者はコードを1行も書いていません。
しかし、何を作るか決めたのは投稿者です。
優先順位をつけ、動作を検証し、改善の方向を指示したのも投稿者自身でした。
つまり、作品の方向性を決める判断は、すべて人間側にあったのです。
映画監督はカメラを回さなくても監督です。
同じことが、ソフトウェア開発でも起こり始めているのかもしれません。
まとめ
今回のRedditの事例から学べるポイントを整理します。
未経験者でも、AIを使えば数日で動くゲームを作れる時代になりました。
ただし、一発で完成する魔法ではありません。
大量のプロンプトとデバッグの往復が必要です。
そして、完成品にはバグも残ります。
成功の鍵は進め方にありました。
一度に全部を作らず、フライト物理、マップ、グラフィックと一つずつ仕上げていく。
人間は監督役に徹し、アセットは既存のものを活用する。
この割り切りが効いています。
経験者のテクニックも参考になります。
型付けの規律をAIに守らせる。
正しいバージョンのドキュメントを情報源として与える。
こうした地味な工夫が、出力の品質を大きく左右するのです。
「自分には無理」と思っているなら、まず小さく試してみてください。
投稿者も、数日前までは何も知らない一人でした。
続ければどこまで行けるか。
それは、あなた自身で確かめる価値があるはずです。
