ゲームエンジンの選び方と開発環境｜AIゲーム開発の準備とバージョン管理

ゲームエンジンは、作れるゲームの種類、出せる機種、かかる費用、作業のしかたまで左右する、最初の大きな選択です。エンジンを決めたら、フォルダの構成、バージョン管理、バックアップ、ビルドの作り方といった「開発環境」を整えます。工程の中では、企画・プロトタイプ・仕様書・スケジュールのあと、本格的に作り始める前にあたります（プロトタイプの段階で仮に選び、ここで確定させる進め方もあります）。全体の流れは「ゲーム開発の全工程マップ」で確認できます。

本記事では、主なエンジン・ツールの向き不向きと利用条件、フォルダ構成と命名、バージョン管理とバックアップ、開発版と製品版のビルド、作業用 PC の注意を解説し、AI エージェントで作る場合の環境づくりをまとめます。エンジンの操作手順は扱いません。利用条件と料金は2026年10月時点の公式ページで確認したもので、変わることがあります。商用で使う前に、必ず最新の公式ページを確かめてください。

ゲームエンジンと開発環境とは

ひとことで：ゲームエンジンは画面・入力・音・物理などの土台をまとめた道具で、開発環境はそれに管理とビルドの仕組みを足した作業場全体です。

ゲームエンジンは、絵を画面に出す、コントローラーの入力を受け取る、音を鳴らす、物の当たりを計算する、といったどのゲームにも要る土台をまとめた道具です。エンジンを使うと、ルール・ステージ・演出といった中身づくりに集中できます。開発環境は、エンジンを中心に次の部品を組み合わせた作業場全体を指します。

部品	役割	例
エンジン・ツール	ゲームを組み立て、書き出す	Unity、Unreal Engine、Godot、RPGツクールなど
エディター	プログラムやデータを書く	エンジン付属のエディター、Visual Studio Code
バージョン管理	変更の履歴を残し、前の状態に戻す	Git、P4、SVN など
バックアップ	データを失わないよう複製を置く	外付けのディスク、クラウドの保存先
ビルドとテスト	遊べる形に書き出し、自動で確かめる	エンジンの書き出し機能、テストのスクリプト
AI エージェント	実装・調査・確認を手伝う	Claude Code、Codex

エンジンを途中で変えると、作ったものの多くを作り直すことになります。出したい機種、利用条件、チームの得意なことを確かめてから決めます。

エンジン・ツールの選び方

ひとことで：作りたいジャンル・出したい機種・チームの得意・利用条件の4つで比べ、迷ったら同じ小さな試作で試します。

主なエンジン・ツールの向き不向き

エンジン・ツール	向いているもの	注意したいこと
Unity	2D・3D の幅広いジャンル、スマホ向け	C# で書く。売上と資金調達が一定額を超えると有料プランが必要
Unreal Engine	高品質な3D、大きなステージ	C++ とブループリント（ノードをつなぐ方式）で作る。プロジェクトが大きくなりやすい
Godot	2D、軽めの3D、個人・少人数	GDScript（Python に似た言語）や C# で書く。ゲーム機へは第三者の移植サービスなどを通す
GameMaker	2D のアクションなど	独自の言語（GML）で書く。売るには有料版が必要
RPGツクール	2D の RPG	画面上の操作で作れる部分が多い。決まった形から外れるほどプラグイン（追加の仕組み）が要る
ティラノスクリプト	ノベルゲーム・アドベンチャー	独自のタグでシナリオを書く。ノベルの形から大きく外れる遊びは不向き
Web（HTML5 と JavaScript）	ブラウザで遊べる小品・試作	ストアを通さず公開できる。端末の差・読み込みの容量・音の扱いに注意

Godot は公式にはゲーム機に対応しておらず、ゲーム機には認定を受けた第三者のミドルウェアや移植会社を通して出します（Godot 公式）。ティラノスクリプトは、PC・スマホのアプリやブラウザ向けに出力できるとされています（公式サイト）。ブラウザ版は、エンジンからブラウザ向けに書き出す方法と、JavaScript で直接作る方法があります。筆者のブラウザ版の霧将棋と役満連荘麻雀は、Godot からブラウザ向けに書き出しています（ブラウザ版の注意は「ゲームの移植とマルチプラットフォーム」）。

参考までに、GDC の2026年の調査（回答2,300人超）では、開発職に限った質問で使っているエンジンは Unreal Engine 42%、Unity 30%、新しいインディースタジオでは Godot 11% でした（GDC 2026 State of the Game Industry）。使う人が多いほど情報や素材は見つけやすくなりますが、作りたいものに合うかが先です。

利用条件の要点（2026年10月時点）

• Unity：直近12か月の売上と資金調達の合計（個人なら Unity を使って得た金額。受託開発では依頼主の売上なども数える）が20万ドル以下なら、無料の Unity Personal を使える。超えたら Unity Pro（年 $2,310／1席）など。2023年に発表されたインストール課金（Runtime Fee）は、2024年9月に撤回された（利用規約・料金の変更）
• Unreal Engine：ゲームの売上が1本あたり生涯で100万ドルを超えるまで、ロイヤリティ（売上に応じた使用料）はかからない。超えた分の総売上（ストアの手数料を引く前）に5%。Epic Games Store での売上は対象外で、Epic Games Store に同時発売するなどの条件を満たせば3.5%（ライセンス）
• Godot：MIT ライセンスで無料、ロイヤリティなし。ただし、クレジットやライセンス一覧の画面などに Godot の著作権表示とライセンス文を入れる（ライセンス）
• GameMaker：無料版は非商用のみ。売るなら Professional（$99.99 の買い切り）。ゲーム機に出すには Enterprise（サブスクリプション）（価格）
• RPGツクール：個人や同人サークルなら商用利用できる（法人などは別途協議）。配布時は指定のロゴ（可能な限り）と権利表記を入れる。2026年6月の規約改定で、正規に購入した人は付属の素材を他のツールで作った作品にも使えるようになった（利用規約）
• ティラノスクリプト：無料・商用可・クレジット不要。ただし MIT ではなく独自の規約で、ティラノスクリプト自体の再配布は禁止（LICENCE）

よくある誤解は3つです。Unreal Engine の5%は「利益」ではなく総売上にかかり、免除の100万ドルは「年間」ではなく製品ごとの生涯の額です。Godot は無料でも表記は必要です。ティラノスクリプトは MIT ではありません。ライセンス表記の入れ方は「ゲーム開発の権利と規約」で扱います。

迷ったときの決め方

• ① 出したい機種で絞る（ゲーム機に出したいなら、その機種に書き出せるか、開発者登録が要るか）
• ② ジャンルで絞る（ノベルならティラノスクリプト、2D の RPG ならツクールのように、専用のツールが合うこともある）
• ③ 利用条件を読む（売上の見込み、法人で出すか）
• ④ 残った候補で同じ小さな試作を作って比べる（例：キャラが動いてジャンプし、敵に当たると音が鳴るだけの画面）

プロジェクトのフォルダ構成と命名

ひとことで：ゲームに入るもの・元データ・道具・文書を分けて置き、名前の付け方を最初に決めます。

フォルダ構成の一例です。

my_game/
  game/          エンジンのプロジェクト（ゲームに入るもの）
    assets/      画像・3D・音・フォント
    scenes/      画面やステージ
    scripts/     プログラム
    data/        数値の表・テキスト（CSV や JSON）
    tests/       自動テスト
  source_art/    元データ（レイヤー付きの画像、3DCG の作業ファイル。ゲームには入れない）
  tools/         書き出し・変換のスクリプト
  docs/          仕様書・決めたことの記録
  licenses/      フォントやライブラリのライセンス文

ポイントは、ゲームに入るものと元データを分けることです。Godot や Unity はプロジェクトのフォルダに置いた素材を自動で取り込む（インポートする）ので、大きな元データを混ぜると取り込みが重くなり、配布物に紛れ込む原因にもなります。数値やセリフは CSV や JSON のようなテキストにしておくと、変更の差分が見やすくなります。

名前は、半角の英数字とアンダーバーにそろえ、日本語や空白は使いません（ツールやコマンドによっては、日本語や空白を含むパスで動かないことがあります）。種類ごとの接頭辞（背景＝bg_、効果音＝se_ など）を決め、版の番号はファイル名ではなくバージョン管理で持ちます。詳しくは「アセット命名・バージョン規則」で解説しています。

バージョン管理とバックアップ

ひとことで：変更の履歴はバージョン管理で残し、それとは別に、大事なデータを3か所に置いて失わないようにします。

バージョン管理とは

バージョン管理は、ファイルの変更の履歴を残す仕組みです。変更を記録する（コミット）、2つの時点の違いを見る（差分）、前の状態に戻す、本流とは別の枝（ブランチ）で試す、ができます。

ゲームでは、画像・3D・音のような大きなバイナリのファイル（テキストではないファイル）が多いのが特徴です。バイナリは2人の変更を自動でまとめる（マージする）ことができず、Unreal Engine の公式ドキュメントも、アセットのファイル（.uasset・.umap）はバイナリなのでテキストとして開いたりマージしたりできないと説明しています（Unreal Engine 5.8）。そのため、編集中のファイルを他の人が触れないようにする「ロック」が大事になり、P4・SVN・Git LFS にはその機能があります。

主な選択肢（2026年10月時点）

仕組み	特徴	無料で使える範囲
Git（GitHub など）	コードの管理で広く使われる。大きなファイルは苦手	GitHub は、通常のファイルは 50 MiB を超えると警告、100 MiB を超えると送れない（push できない）
Git LFS	大きなファイルを Git の外に置き、Git では目印だけを管理する	GitHub の Free・Pro は保存 10 GiB・転送 月10 GiB。1ファイル最大 2 GB
P4（旧 Helix Core）	大きなバイナリとロックに強い。Unreal Engine の公式ドキュメントに手引きがある	5ユーザー・20ワークスペースまで無料
Unity Version Control	Unity に組み込まれたバージョン管理	2026年3月1日から席数無制限・保存 25 GB・転送 月100 GB まで無料
SVN（Subversion）	1台のサーバーに履歴を集める方式。ロックが使える	ソフトは無料（Apache License 2.0）。サーバーは自分で用意する

GitHub では、リポジトリ（履歴の置き場）は 1 GB 未満が理想、5 GB 未満が強く推奨とされています。Git LFS の無料枠を、支払い方法を登録せずに超えると、新しいファイルを送れなくなるなどの制限がかかります。個人でコード中心なら Git（大きな素材は Git LFS）、素材が多く数人で同じファイルを触るならロックが使える仕組み、と選びます。

エンジンが自動で作り直せるファイルは管理から外します。Godot は .godot/ フォルダ（キャッシュ）を外し、プロジェクトを作るときに Git を選ぶと .gitignore と .gitattributes が作られます（Godot ドキュメント）。Unity は Library・Temp・UserSettings を外し、Assets・Packages・ProjectSettings を入れます（Unity マニュアル）。

バックアップは3か所に

バージョン管理はバックアップの代わりになりません。履歴の置き場所が1か所なら、そこが壊れれば一緒に失われます。US-CERT 向けに作られた資料（Data Backup Options、2012年）は、次の「3-2-1 ルール」を勧めています。

• 3：大事なファイルは3つ持つ（元のファイル1つ＋バックアップ2つ）
• 2：2種類の異なる媒体に置く（例：PC の内蔵ディスクと外付けのディスク）
• 1：1つは別の場所に置く（例：クラウドの保存先、別の建物）

同じ資料は、自動で上書きしていくバックアップが、壊れたファイルやマルウェアまで黙って複製してしまうことがあると注意しています。古い版も残る形にし、ときどき本当に戻せるかを試します。

ビルドの作り方（開発版と製品版）

ひとことで：ビルドは遊べる形に書き出したもので、確認用の開発版と配布用の製品版を分け、同じ手順でいつでも作れるようにします。

ビルドは、プロジェクトをエンジンなしで遊べる形（実行ファイルやブラウザ用のファイル）に書き出したものです。テストプレイ、審査への提出、配信のたびに作ります。

項目	開発版（デバッグビルド）	製品版（リリースビルド）
使い道	自分やテスターの確認	配布・販売・審査
入れるもの	開発用のメニュー、ログ、確認用の近道（チート）	遊ぶ人に必要なものだけ
Godot の場合	デバッグ用のテンプレートで書き出す	リリース用のテンプレートで書き出す

Godot の OS.is_debug_build() は、エディターとデバッグ用の書き出しでは真、リリース用の書き出しでは偽を返します。筆者の「つみこめ！イカサマ魔法麻雀」では、開発中の機能を「開発用デバッグ」ボタンにまとめ、この判定で製品版の書き出しから自動で消えるようにしています。

• 同じ手順で作る：書き出しをスクリプトにして、1つのコマンドで作れるようにする（Godot は --export-release で、エディターを開かずに書き出せる。書き出し用のテンプレートと書き出しの設定が必要）
• 版番号を付ける：ゲーム内やログに表示し、どの版の不具合報告かを分かるようにする
• 提出・配布したビルドは保管する（「マスターアップとは」）
• エンジンの版を固定する：上げるときは別のブランチで試してから
• 書き出した後に中身を確かめる：開発用のファイルが紛れ込んでいないか、容量が急に増えていないか

作業用 PC の注意

ひとことで：容量・メモリ・熱と電源に余裕を持たせ、OS・ドライバー・エンジンの更新は区切りのよいときに行います。

項目	注意すること
保存領域	エンジンのキャッシュ、書き出したビルド、バックアップで容量はすぐ埋まる
メモリ	エンジン・素材のツール・ブラウザ・AI のツールを同時に開くと足りなくなりやすい
熱と電源	長い書き出しや大量の自動テストは PC に負荷をかけ続ける。同時に走らせる数に上限を決める
更新の時期	OS・グラフィックのドライバー・エンジンの更新は、締め切りの直前を避ける
パスと文字コード	フォルダ名に日本語や空白を使わない。文字コードは UTF-8 にそろえる
秘密の情報	ストアの管理画面のパスワードや、サービスの鍵（API キー）をプロジェクトのフォルダに置かない

AIゲーム開発での開発環境

ひとことで：AI エージェントが読めて・動かせて・確かめられる環境を作り、AI が作業する前に、いつでも戻せる状態にしておきます。

AI が扱いやすい環境の条件

AI エージェントは、ファイルを読んで書き換え、コマンドを実行して結果を確かめながら作業します。次の条件がそろうほど、AI が自分で確かめながら進められます。

条件	理由	例
シーンや設定がテキストで保存される	AI が中身を読んで直接書き換えられ、人も差分で確かめられる	Godot のシーンファイル（.tscn）は、公式ドキュメントで、ほぼ人が読めてバージョン管理しやすい形式と説明されている。Unity も既定でシーンをテキスト形式で保存する
コマンドで書き出し・テストができる	エディターを操作しなくても、AI が結果を確かめられる	Godot の --headless（画面を出さない起動）、Unity の -batchmode
テストがある	「直したら別の所が壊れた」を AI 自身が見つけられる	画面を出さずに走るテスト
ログがファイルに残る	エラーの中身を AI が読める	実行ログ、テスト結果のファイル
決まりが文書になっている	毎回の説明が要らず、作業がぶれない	CLAUDE.md や AGENTS.md の指示ファイル

逆に、Unreal Engine のアセットのようにバイナリで保存されるものは、AI がファイルを直接読み書きしにくく、エディターを通した操作（エディター内のスクリプトなど）が要ります。何をテキストで持てるかは、エンジンの設定や作り方で変わります。

AI に任せやすい環境づくりの作業

• エンジンに合わせた .gitignore（管理から外すファイルの一覧）の作成
• 書き出しとテストを1つのコマンドで走らせるスクリプトの作成
• 命名の規則に合わないファイルや、ゲームのフォルダに紛れた元データの洗い出し
• 使っているライブラリ・フォントと、そのライセンス文の一覧づくり
• エラーログを読んで、原因の候補と確かめ方をまとめる

筆者の環境と、エンジンとのつなぎ方

筆者の開発環境は、Godot 4、自前のヘッドレステスト（画面を出さずに走らせるテスト）、PowerShell と Python の道具で、コミットは筆者が行います。画面を出さないテストがあると、AI は変更のたびに自分でテストを走らせ、結果を確かめてから報告できます。

エディターやツールを AI から直接操作する方法として、MCP（AI と外部のツールをつなぐ共通の仕組み）もあります（「Claude Code MCP・Hooks活用ガイド」）。ただし、起動中のソフトを外から操作するライブ接続は、操作が多いと不安定になることがあります。筆者が 3DCG ソフトの Houdini で動く自作ツールを作ったときも、ライブ接続で大量に操作したらソフトが落ちたため、画面を出さない実行に切り替えました。重い作業はコマンドで動かすのが基本です。

戻せる状態と権限

• 戻せる状態にする：AI が作業を始める前に、今の状態をコミットしておく。大きな変更は別のブランチで行う
• 権限を決める：AI が自由に実行してよいコマンドと、確認を求めるコマンドを設定する（「Claude Code パーミッションと安全設定ガイド」「Codexの権限と安全設定」）
• 秘密を置かない：パスワードや API キーを、AI が読むフォルダに置かない

AI はエンジンの設定ファイルやプロジェクトの設定まで書き換えることがあるので、コードだけでなく設定の差分も確かめます。人が決めるのは、どのエンジンをどの条件で使うか、AI に触らせてよい範囲（フォルダ・コマンド・外部サービス）、変更を取り込むか（差分を見て、遊んで確かめてからコミットする）です。AI を使うと、コードを打つ時間は減る代わりに、「AI が自分で確かめられる仕組み」と「戻せる仕組み」を設計する仕事の比重が上がります。テストが無く戻せない環境では、AI が速く作っても、人が全部を確かめることになるからです。

実際に踏んだ罠

罠	中身	対策
ヒアドキュメント（コマンドの中に複数行の文章を直接書く書き方）	シェルの中に書いたスクリプトで、日本語や \\ が壊れた	スクリプトはファイルに書いてから実行する
文字コード	PowerShell のスクリプト（.ps1）とバッチファイル（.bat）で、求められる文字コードが違う	.ps1 は UTF-8 の BOM（先頭に付ける文字コードの印）付き、.bat は Shift-JIS で保存する
再インポート	Godot でクラス名を足した直後、全体がエラーになった	クラス名を足したら、読み込み直し（再インポート）をしてから走らせる
名前の衝突	静的関数に reload と名付けたら組み込みの関数に化け、状態が黙って消えた	エンジンの組み込みと同じ名前を避ける
並列の計測	計測を32本同時に走らせたら、PC がブルースクリーンで止まった	同時16本までにし、途中から再開できる計測に作り直した

依頼文の例

Goal・Context・Done when の書き方は「Claude Code プロンプト設計」で解説しています。

Goal: 画面を出さずに全テストを走らせ、結果をファイルに残すスクリプトを tools/ に作る
Context: Godot 4 のプロジェクトは game/、テストは game/tests/。Windows の PowerShell で動かす。
  日本語を含むスクリプトはファイルに書いてから実行する
Done when: 1つのコマンドで全テストが走り、失敗が1件でもあれば終了コードが0以外になる。
  結果は logs/test_result.txt に残る。わざと1件失敗させ、失敗として報告されることを確かめた

よくある失敗と対処

ひとことで：多くは「条件を確かめずに選ぶ」「戻せない・1か所にしかない」「開発版と製品版が混ざる」から起きます。

失敗	原因	対処
途中でエンジンを変えることになった	出したい機種や利用条件を確かめずに選んだ	機種と条件を確かめ、小さな試作で比べてから決める
売上が伸びて利用条件が変わった	条件を読まずに使い始めた	確かめた日付つきで条件を記録し、売上が増えたら読み直す
リポジトリが重くて登録できない	大きな素材を通常の Git に入れた	大きなファイルは Git LFS などで管理し、元データは別に保管する
2人で同じ素材を直して片方が消えた	バイナリはマージできない	ロックを使い、編集中のファイルを知らせる
PC が壊れて作業が消えた	データが1か所にしかなかった	3か所に置き、戻せるか試す
製品版に開発用のメニューが残った	開発版と製品版を分けていない	デバッグビルドの判定で囲み、書き出し後に中身を確かめる
AI の変更で全体が壊れて戻せない	作業の前にコミットしていなかった	AI の作業の前にコミットし、大きな変更はブランチで行う

チェックリスト

ひとことで：開発環境を整えたら確かめる9つの項目です。

• [ ] 出したい機種・ジャンル・チームの得意・利用条件でエンジンを比べた
• [ ] 利用条件を公式ページで読み、確かめた日付と一緒に記録した
• [ ] ゲームに入るもの・元データ・道具・文書のフォルダを分けた
• [ ] ファイル名の規則（半角英数字・日本語と空白なし）を決めた
• [ ] バージョン管理を入れ、エンジンが作り直せるファイルを管理から外した
• [ ] 大きなファイルの扱いとロックの方法を決めた
• [ ] 大事なデータを3か所に置き、戻せるかを試した
• [ ] 開発版と製品版を分け、1つのコマンドでビルドできるようにした
• [ ] AI が作業する前にコミットし、AI の権限を設定した

次に読む記事

ひとことで：整えた環境で作り始める工程と、環境に関わる記事です。

• ゲームのプロトタイプとは：決めたエンジンで面白さを最速で確かめる
• グレーボクシングとは：ステージを仮組みして大きさと遊びを確かめる
• ゲームのデバッグとQA：自動テストとバグ報告の進め方
• ゲームの移植とマルチプラットフォーム：ゲーム機・スマホ・ブラウザへの展開
• Claude Code インストールガイド：AI エージェントを開発環境に入れる