ゲームの世界地図を作りたい。けれど素材を一枚ずつ手で描いて並べるのは、考えただけで気が遠くなる。AI生成のスケッチを「使える透過アセット」に変えて、回遊できるマップに仕立てる。その量産フローを公開する。
▶ 完成したこのゲームを、ブラウザで今すぐ遊ぶ（インストール不要・セーブ対応）。AIで「どこまで作れるのか」を、まず手で触って確かめてほしい。
📚 詳しい作り方（連載・全6回）— 実コードで順を追って再現する
この記事は全体像のまとめです。「実際に作るには情報が足りない」という声を受け、約1万行の本体をシステムごとに分け、再現できる粒度で連載化しました。
- ① 無ビルドの土台と全体設計（公開中）
- ② データ駆動設計（敵・職業・スキルをデータ追記だけで増やす）（公開中）
- ③ CTB戦闘コアをDOM非依存で書く（公開中）
- ④ ワールドマップ・シーン・セーブ（公開中）
- ⑤ AIアセット量産フロー（生成→透過→配置）（公開中）
- ⑥ ヘッドレス検証と静的デプロイ（公開中）
目次
このガイドで作るもの
AIで生成したスケッチシートからゲーム用アセットを透過切り出しし、それを敷いた「レベルセレクト」マップ（HTML）を作る。44ノードが蛇行するパスを進み、クリアでロックが解放され、進行は localStorage に保存される。素材づくりから遊べるマップまでを一本のパイプラインにする。
設計の起点：生成は楽だが、そのままでは使えない
AI画像生成は素材を量産できる。だが背景付き・矩形のままではゲームに置けない。鍵は「生成 → 透過切り出し → 配置」を流れ作業にすること。被写体を BiRefNet で抜き、足りないシームレスタイル（海・草・砂）は手続き生成で補う。「生成物を整える工程」を自動化できるかどうかで、量産の速度が決まる。
作り方の要点
1. スケッチシートを透過PNGに抜く
ChatGPT / OpenRouter で生成したアセットシートを、BiRefNet で1点ずつ透過PNG化する。暗い被写体は「黒背景が残った」と誤判定しやすいので、見た目でなくアルファ値で抜けを確認するのがコツだ。
2. 足りないタイルは手続き生成で作る
海・草・砂のように「繋いで敷く」タイルは、AIに頼るより FFT ノイズで手続き生成した方がシームレスに繋がる。生成（被写体）と手続き（地形）を使い分ける。
3. マニフェストからマップを自動生成する
マップのノード配置を手で書くと破綻する。アセットのマニフェストから build_map.py が stages.js を自動生成し、44ノードのパス・ロック解放・情報パネルを map.js が描く。進行は localStorage に保存する。データを直せばマップが再生成される形にしておくと、ステージ追加が一瞬で済む。
例えば、素材1点はこう流れる
「スライムの立ち絵」1点で、パイプラインを通しで見るとこうなる。①画像生成AIに「単一の浮いた被写体・背後に何も無い」を明示したプロンプトで複数枚生成する。②HTMLの一覧（市松模様背景）で目視し、一番良い1枚を選ぶ。③BiRefNet で背景を抜き、隅のアルファ値が0であることを機械的に確認する。④enemy_slime.png という「データが参照している名前」で本番ディレクトリに置く。これで戦闘にも図鑑にも自動で出る。1点あたりの手作業は「選ぶ」だけで、残りは全部スクリプトが同じ手順を繰り返す。99体の敵も、この流れの99周にすぎない。
この流れはJRPG専用ではない。カードゲームのカード絵、シミュレーションのユニットアイコン、ノベルゲームの立ち絵。「同じ規格の画像が大量に要る」ジャンルなら、生成→選別→透過→検証→命名配置の5工程はそのまま移植できる。変わるのはプロンプトの中身と画像の規格だけで、パイプラインの骨は使い回せる。一度組んだ流れ作業は、次の作品の資産になる。
なぜゲームエンジンを使わなかったのか
Unity やツクール系を選ばなかった理由も書いておく。第一に、このゲームの中身は「データと計算」が主で、物理演算も3Dも要らない。第二に、ブラウザ完結ならプレイヤーはインストール不要で、配布はファイルを置くだけ。第三に、エンジンの学習コストとビルドの複雑さが、個人開発の完走率を下げる。逆に、アクション性の高いゲームや3Dを作るならエンジン一択で、この構成は「ターン制・データ駆動・ブラウザ配布」という条件が揃ったときの選択肢だ。道具は題材で選ぶ。
マップの先にある「遊べる JRPG」の作り方
レベルセレクトマップは入口にすぎない。実際の Archipelago Saga は、6地域・49ステージ・9職業・81スキル・99体の敵（ボス6体を含む）を持つ、ブラウザで通しクリアできる CTB（FFX風）JRPG だ。ここからは、その本体がどう組まれているかを開く。
無ビルド・クラシックスクリプト：file:// で動く潔さ
バンドラを使わない。index.html が js/** を順に読み込み、すべてを単一のグローバル名前空間 window.G に載せる（G.CLASSES / G.ENEMIES / G.STAGES / G.STORY / G.state / G.createBattle / G.audio …）。webpack も npm run build も無い。file:// でダブルクリックすれば動く。配布もホスティングも、静的ファイルを置くだけで済む。小〜中規模のゲームでは、これが一番事故らない。
データ駆動：コンテンツ追加は「データ追記」だけ
ステージ・敵・装備・ストーリーはすべて純データ（js/data/）に分離する。新しい敵やステージを足すとき、シーン側（worldmap / battle / story）のコードは一切触らない。さらに「拡張ファイル方式」を使い、enemies_ext.js（敵30体＋新ボス3体）や class_equipment.js（職業専用装備63）を本体データの後に読み込んで Object.assign で合流させる。コンテンツとロジックを分けておくと、ボリュームを後からいくらでも盛れる。
戦闘ロジックは DOM 非依存で書く
ここが設計の要だ。CTB（チャージタイム）戦闘の純ロジックを engine/battle-core.js にDOM非依存で実装し、UI（scenes/battle.js）から分離する。beginTurn → performAuto | performHero → endTurn のループをシーンが駆動する形。ロジックが画面に依存しないので、テストもヘッドレス検証も自動化できるし、後で見た目を変えても戦闘の挙動は壊れない。属性の弱点/耐性・会心・状態異常・ボスのテレグラフ（予兆ターン）も、すべてこのコア側に閉じている。
シーンマネージャと進行
画面遷移は main.js のシーンマネージャ（G.game.show）が握る。title → party → story(intro) → worldmap →（stage）→ battle → result →（最終ボスのみ）story(ending)。ステータス・ショップ・図鑑は worldmap から開く。各シーンは独立しているので、1画面ずつ作って差し込める。
AIアセット量産フローの全体像
前半の透過切り出しは、量産フローの1工程にすぎない。実際は用途別にディレクトリを分けて量産する。主人公9クラス×男女（均一キャンバスに正規化）・敵93＋ボス6（透過立ち絵）・職業装備63＋アイテム34（アイコン）・戦闘背景67（ランダム）・地図ノード（浮島）。生成原画は _raw / cand にバックアップし、採用版だけを本番ディレクトリへ。「生成 → 正規化 → 透過 → 配置」を型にすると、絵が描けなくても世界観の揃った素材が揃う。
「動いている」をヘッドレスで証明する
ゲームは手で全クリアして確認していられない。puppeteer で shot_game.js（タイトル→編成→戦闘→リザルト→ステータスの通しプレイ）/ shot_boss.js（ボス戦のテレグラフ→勝利→レベルアップ）を回し、「コンソールエラー0・画像/音声の404ゼロ」を完了条件にする。DOM非依存のコア設計が、この自動検証を可能にしている。
正直なまとめ
このゲームの作り方は「無ビルド＋グローバル G ＋データ駆動＋DOM非依存の戦闘コア」に尽きる。派手な技術ではないが、小規模で完成させ切るには最も現実的な構成だ。素材は AI で量産し、ロジックはデータと分離する。そうすれば、絵が描けなくてもゲームは完成する。細部の作り方は、上の連載6回で全部開いている。
※ AI生成コンテンツの開示：本作の BGM・効果音・キャラクター画像・ボイスは、すべて生成AIの出力物です（BGM＝ACE-Step 1.5〈MIT・出力の商用利用可を配布元モデルカードで確認済み〉 ／ ボイス＝Irodori-TTS 系の合成設計音声・実在人物の複製ではありません ／ 効果音＝数値合成 ／ 画像＝画像生成AI〈各サービスの利用条件で出力の商用利用可を確認のうえ使用。透過処理は BiRefNet〈MIT〉を rembg 経由で使用〉）。第三者の著作物は同梱していません。© 2026 Cooliris（本作のコード・構成・データの権利は作者に帰属します）。
この制作で使ったもの PR
🖥 サーバ/ドメイン
🤖 使ったAIツール（公式）
- Claude（Anthropic） 公式
- ChatGPT（OpenAI） 公式
- OpenRouter 公式
📚 技術書（Amazon）
