ドラクエ風RPGをAIで作ろうとしたら30年前の人類が神だった話

Last updated at 2026-04-30Posted at 2026-04-30

育成ゲームの息抜きに新作を試したら、ドラクエの偉大さに気づいた

「ワールドマップ、AIで1日で作れるでしょ」

そう思っていました。

育成ゲームの開発がひと段落ついて、息抜きに新作RPGの構想を練っていた週末のこと。雲の上の浮島群を舞台にした、ドラクエ風ターンバトルRPG。子猫の勇者ミルクが、魔王を倒す物語です。

設計書はだいたい固まっていました。あとはタイル画像をAIで作って、並べるだけ。

AIで草・山・町のタイル画像を作る
　↓
並べる
　↓
完成

この甘い見積もりが、地獄の入り口でした。

第1の試練：AIは「ドラクエ風」を知らない

最初に作ったのは、草地のタイル。シンプルなプロンプトで投げました。

A grass tile for a JRPG world map, top-down view

返ってきたのは、国営放送のドキュメンタリー番組に出てきそうな、リアルな草原の航空写真でしたw

「いや、ピクセルアートで」と書き直します。今度は3DCGで作った草原が来ました。立体感がすごい。フラットじゃない。これじゃない。

以下のような禁止事項を足してみます。

flat 2D pixel art, NO 3D rendering, NO photorealistic

ようやく、それっぽい絵が出てきました。

1枚目で気づいたことがあります。

AIに「ドラクエ風」を作らせるには、「これは違う」を山のように書かないといけない。

「こうしてほしい」より「こうしないでほしい」の方が長い。これが、最初の違和感でした。

第2の試練：ドラクエを観察し始めて、2時間が消える

タイルが何種類必要か考えていて、ふと気になりました。

「ドラクエって、実際どんなタイル構成なんだろう？」

実機画像を開きました。眺め始めました。次にスマホを見たら、2時間が経っていました。

そしてこの2時間で、最初の設計が完全に間違っていたことに気づきました。

私はこう思っていました：

「山のタイル」=「草地に山が描かれた1枚の画像」

ドラクエは違いました。

「草地のベース」+「山のシルエット」を別々のレイヤーで重ねている

つまり、山のタイルは山だけが描かれていて、その下に草地ベースが敷かれている。だから「砂漠の山」も「草地の山」も、同じ山タイルを使い回せる。

これに気づいた瞬間、背筋が凍りました。

設計書、全部書き直しです。

第3の試練：「ベースはベースだ」をAIに理解させる戦い

設計を直して、「ベース地面」と「オブジェクト」を分離しました。ベース地面は純粋な地面のテクスチャだけ。山も木も建物も乗せない。

簡単な指示だと思いました。

草地タイルを生成してください。純粋な草の地面テクスチャだけ。
何も乗せないでください。

→ 出力：草地の上に色々な草がのっている

花も肉球もダメです。本当に草だけ。

→ 出力：草地の上に小さなクローバー

クローバーもダメです。装飾物は一切なし。

→ 出力：草地の上に葉っぱの装飾

…葉っぱ？それは草の一部？それとも別物？

AIに「葉っぱは草地の表現か、別オブジェクトか」を区別させるのに、何往復したかわかりません。最終的にプロンプトはこうなりました。

NO clovers, NO flowers, NO paw prints, NO mountains, 
NO trees, NO buildings, NO decorations of any kind.
ONLY pure grass texture.

禁止事項リストの方が、本文より長い。

第4の試練：マップエディタの存在

ここまで散々苦労した後、息抜きに別の開発者の動画を見ていました。Godot Engineの画面が映っていました。

タイルパレットから選んで、マウスで並べていく。マップエディタでした。

時が止まりました。

「…これがあれば、AI生成のブレに苦しまずに済むんじゃ？」

調べたら、Tiledという無料のマップエディタが定番でした。しかも、今使っているフレームワーク（Bonfire）と公式連携しています。

もっと早く知りたかった。

しかも、Tiledには「Terrain Brush」という機能があり、海岸線タイルの配置を自動でやってくれる。私が苦労して書いた「配置ロジックの設計書」、全部不要になりました。

振り返り：4つの学び

ここまでの試行錯誤を振り返って、本気で残った学びを書きます。

学び1：「簡単に作れる」と思った瞬間が、罠の入り口

「タイル並べるだけでしょ」と思った瞬間、私は何も理解していませんでした。

ドラクエが30年積み上げてきた設計思想を、無料で借りようとしていたんです。当然、AIは「ドラクエ風」を知りません。「ドラクエとは何か」を自分で言語化しないと、AIには通じない。

仕事でも同じだと思います。「これくらい簡単だろう」と思った案件ほど、深掘りすると根本設計が間違っている。最初の感覚を疑うことから始まる、と感じました。

学び2：AIは「何を作るか」を教えてくれない

AIは「言われたものを作る」のは得意です。でも「何を作るべきか」は教えてくれません。

ベースとオブジェクトを分離する2層構造
凹角を発生させないマップ設計ルール
海岸線タイルの最適な種類数

これらの設計思想は、ドラクエの開発者が考案したもの。私はそれを観察して理解することしかできませんでした。

AI時代になっても、「何を作るか」の解像度を上げるのは、結局人間の仕事です。これはマネジメントでも同じで、AIに丸投げすると、平凡なものしか出てきません。

学び3：適材適所、また同じ結論

前回の記事で「ツールは適材適所」と書きました。今回もまったく同じ結論にたどり着きました。

・設計の議論：Claude.ai
・コード実装：Claude Code
・タイル画像生成：gpt-image-2
・マップ作成：Tiled

「全部AIで完結」は幻想でした。ツールを組み合わせて、人間が設計する。これが現時点の正解です。

学び4：先人の制約を、リスペクトすること

ドラクエ初期作のROM容量は64KB。今のスマホアプリの数千分の1です。その中に、地形タイル・遷移タイル・マップ・キャラ・戦闘・ストーリー、全部詰め込んでいます。

制約があったからこそ、洗練された設計が生まれたんだと思います。

ベースとオブジェクトの分離は、容量を節約するため。海岸線タイルの最適化も、ROMに収めるため。「凹角を出さない」という美学も、結果的に少ないリソースで美しい世界を見せるための工夫だったのかもしれません。

AI時代の私たちは、容量の制約から解放されています。だからこそ、先人の設計思想を意識的に学ばないと、すぐに膨らんで破綻する。

「制約がない」ことは、「設計の腕が試される」ということでした。

結論：ドラクエは、神

息抜きに始めたはずが、設計書のページ数だけが膨れ上がっていきました。気づけば、ドラクエへのリスペクトが5倍くらいになっていました。

「個人開発でドラクエ風RPGを作りたい」と思っている人へ、最後に伝えたいことがあります。

ドラクエは神。リスペクトを持って、徹底的に観察してから始めてください。

次回：実装が動いたら、また書きます

ここまでで、設計書はv0.3まで進化しました（最初の数倍の厚みになりました）。

次は実装フェーズです。Claude Codeに渡して、19種類のタイル生成 → Tiledでマップ作成 → ゲームエンジンで描画 → 移動制御、と進めていきます。

実装が動いたら、また書きます。「ドラクエ風RPGを作る」というテーマは、想像以上に学びの宝庫でした。

おまけ：こんな奮闘を経て、開発してるアプリがこちらです！

コードが書けない非エンジニアが、AIと格闘しながら完全バイブコーディングでアプリを作っています。

第一弾：もふふミルクとにゃんこ脱出ゲーム 🐾

動画に登場している白い猫のミルクが主人公。ふわふわの謎を解いて、ミルクと一緒に脱出するゲームです。

📱 アプリはこちらからダウンロードできます 👉

次回作：もふふミルクのにゃんこ図鑑、開発中 🌱

今回の記事で書いた"引き継ぎ書"の仕組みを最初から適用して作っているのが、この育成ゲームです。ミルクと一緒にふわふわ島で暮らしながら、いろんな猫たちと出会って、育てていくゲーム。

▲ 開発中の画面（2026年4月時点）。ミルクを育てるコアループ部分が動いている状態。

その次：もふふミルクのにゃんこクエストふわふわ島と勇者の扉（構想中）

引き継ぎ書を置いて開発したおかげで、脱出ゲームのときより明らかに順調です。リリース時期が近づいてきたらまたお知らせします。

興味ある方はフォローしてもらえると嬉しいです！

これまでのシリーズ

※本記事はnoteからの転載です：https://note.com/natty_yarrow1907/n/ne296d8988392

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up