株式会社CAENのロゴ

Love2D × AI駆動開発で Steam に出すインディーゲームを作っている話｜SwingByByBy 開発記

この記事で分かること

  • Love2D は「ゲームジャムやプロトタイプ用」と思われがちだが、本気で作れば Steam で売るインディーゲームの土台に十分なる。
  • 僕（大森翔吾）が Love2D × AI駆動開発で作っているスコアアタック型アクションゲーム 『SwingByByBy』 は、Steam Coming Soon ページ公開済み・東京ゲームダンジョン12（2026/5/3）出展予定。
  • 鍵は 「設計ドキュメントを先に書き、AI に基準から外れない実装だけをさせる」 スペック駆動の運用。main.lua 一枚のプロト構造ではなく、entities / states / systems / ui / utils / tests まで分割した本格プロジェクトとして組んでいる。

プロトタイプの Love2D と本気の Love2D は、同じ道具で別ゲームになる。AI駆動ならその両方をひとりで往復できる。

SwingByByBy とは何か

『SwingByByBy』は、中央の地球をマウスで操作するスコアアタック型アクションゲーム です。

  • 画面外から飛翔体（現スキンは猫）が自動で飛来する
  • プレイヤーは地球を動かし、地球の重力で飛翔体の軌道を曲げる
  • 曲げた軌道で惑星（target）にぶつけてスコアを稼ぐ
  • 地球と飛翔体が衝突するとゲームオーバー
  • モードは Score Attack（120秒の制限時間） と Endless（時間無制限） の2種類

ぱっと見は宇宙アーケードですが、自分の中で核に置いている設計コンセプトはこれです。

このゲームは、危険を避けるゲームではない。危険を手放さないゲームである。

飛翔体を画面内に留めてコンボを伸ばすには、地球の近くを通し続ける必要がある。でも近づけすぎたら自分が死ぬ。離しすぎたら画面外へ抜けてコンボが切れる。プレイヤーは安全地帯ではなく、破綻しないギリギリの危険域に居続けることを強制されるゲーム設計です。

感情の構造としては『Getting Over It』『Jump King』に近い。操作系は全く違うのですが、「長時間積み上げた進捗が一瞬で消える緊張」を中心に置いているところが共通しています。

なぜ Love2D を選んだのか

Godot を AI駆動で触った話 も以前書きましたが、SwingByByBy は Godot ではなく Love2D（ラブツーディー） を選びました。Love2D は、Lua で書ける軽量な 2D ゲームフレームワークです。エディタを持たず、love . と打てば即起動する潔さが特徴。

Love2D を選んだ理由は3つ。

  1. 2D の物理表現を自分でフルコントロールしたかった：このゲームは「重力場の中で軌道が曲がる」という独自挙動が肝で、エンジン任せではなく systems/physics.lua に逆二乗則の重力計算を自分で書きたかった。Love2D はそういう「素手で殴る」スタイルと相性がいい。
  2. プロジェクト全体がテキストファイル：これは Godot を選んだ時と同じ理由。GUI のポチポチ操作がほぼ発生しないので、Claude Code や Codex といった AI エージェントがそのままコードを書ける。
  3. Lua は AI が書きやすい：シンプルな文法で、AI が生成したコードのレビュー難度も低い。.gd でも C# でもなく Lua という選択は、人間と AI の両方にとってのコスト最小化 という意味があった。

「プロトタイプ用」の Love2D と「本気で出す」Love2D は別物

ここが今日いちばん書きたかった話です。

Love2D で検索すると、main.lua 一枚に全部書いてあるサンプルや、ゲームジャムで2日で作られた作品の紹介が大量に出てきます。それを見ると「Love2D は手軽な実験ツール」というイメージで止まりがちです。

でも、SwingByByBy のディレクトリ構造はこうなっています。

swingbybyby/
├── main.lua            # FSM のエントリーポイント
├── settings.lua        # 全ゲーム定数の集約
├── entities/           # player / projectile / target
├── states/             # title / main_menu / playing / paused / gameover ...
├── systems/            # physics / audio / particles / arcade_effects ...
├── ui/                 # hud / button / modal / slider ...
├── utils/              # run_config / save / ranking ...
├── vendor/             # push.lua（解像度非依存）/ lume / lurker
├── tests/              # Lua テスト群
├── docs/               # 改善案・アセット台帳・実装計画
└── references/         # 「このゲームの本質的な面白さについて.md」など設計の正本

main.lua 一枚構成とは別物です。状態遷移は FSM（有限状態機械） に分離、物理は systems に切り出し、UI は ui に閉じ込め、テストもちゃんと書く。Love2D で Steam に出すなら、これくらいの分割は当たり前にやる必要がある、というのが個人的な結論でした。

AI駆動開発で Love2D を運用する具体的な作法

ここからが本題。この規模のプロジェクトを一人で回せているのは AI 駆動開発のおかげ です。僕がやっていることは大きく3つ。

1. 設計ドキュメントを先に書き、AI に「この基準から外れない実装だけしろ」と指示する

このゲームの「危険を手放さない」というコア体験は、僕が references/このゲームの本質的な面白さについて.md に文章として書き切っています。README.md にも、機能追加の判断基準としてこう明記しています。

「この追加は緊張の質を強めるか、それともただ派手にするだけか」で判断する。

AI に新機能を頼むときは、必ずこのドキュメントを読ませてから「この基準を満たす実装だけ提案して」と前置きします。これが スペック駆動開発 の本懐で、AI が暴走して「派手だけど核を壊す機能」を提案してくる事故を構造的に防げます。

2. フォルダ分割を AI 側のコンテキスト境界として使う

entities/ を触るときは entities/ 周辺だけ、systems/physics.lua を直すときは物理レイヤーだけ、というふうに AI に渡すコンテキストをフォルダ単位で絞ります。

main.lua 一枚構成だと「全部読まないと変更できない」状態になりがちで、AI のトークン消費とミスがどちらも増える。本気で長く保守するつもりなら、最初から関心ごとを分割しておく方が AI 駆動開発と相性がいい。これは Web 開発で features/ ディレクトリを切るのと同じ発想です。

3. テストを書く

tests/ には Lua のテスト群を置いています。ゲーム開発でテストを書くやつは少数派ですが、AI に直してもらうたびに「コア挙動が壊れていないこと」を機械的に検証できる安心感は、想像以上に効きます。

嘘MBTI 失敗談で書いた ように、「AI が作ったから大丈夫でしょ」で検証を飛ばすのは AI 駆動開発の最大の落とし穴。Web サービスでもゲームでも、原則は変わりません。

Steam 配信に向けて：Steamworks 統合も AI に投げる

『SwingByByBy』は Steam Coming Soon ページを公開済みで、現在は Steamworks 統合作業の真っ最中です。具体的には、

  • 実績（Achievements）の登録
  • リーダーボード
  • ストアページ素材（カプセル画像・ストア説明文）
  • ビルドアップロード周りの自動化

これらの作業も、別の worktree（swingbybyby-steam-ops）を切って AI に任せています。ゲーム本体のロジックを触っているブランチと、Steam 周りの設定を触っているブランチを分離することで、リリース前の試行錯誤が本体コードを汚さない設計です。

worktree を活用した並行作業は、AI駆動開発の爆速フローの記事 で書いた手法そのまま。Web もゲームも同じやり方が通用するのが面白いところです。

東京ゲームダンジョン12（2026/5/3）に出展予定

『SwingByByBy』は、2026年5月3日開催の東京ゲームダンジョン12 に出展予定です。インディーゲーム制作者が自作を持ち寄って試遊してもらう、僕にとっては初めての対面イベント出展。

このイベントに照準を合わせて開発スコープを切っているのも、AI駆動開発の独立論で書いた 「公開先と公開基準を先に決める」という個人開発の鉄則どおりです。締め切りがある方が、AI 駆動開発はテンポが出る。

結論：AI駆動開発は「個人 × Love2D × Steam」を成立させる

ここまでの話をまとめます。

  • Love2D は本気で作れば Steam インディーゲームの土台になる
  • そのためには main.lua 一枚構成を脱して、本格プロジェクト構造を最初から組む
  • 設計ドキュメントを先に書き、AI に「核から外れない実装」だけを書かせる
  • テスト・worktree・スペック駆動を Web 開発と同じ作法でゲームにも適用する

『SwingByByBy』はまだリリース前で、これから Steam 公開と東京ゲームダンジョン12 出展という勝負が控えています。個人開発者が AI と Love2D だけで Steam に到達できるという実証を、自分の手で1本通したい。それが今の僕のいちばん大きなプロジェクトです。

関連する記事

AI駆動開発のご相談・お仕事のご依頼

株式会社CAEN（代表：大森翔吾）では、Love2D / Godot を含むインディーゲームの AI駆動開発支援、スペック駆動の設計レビュー、Steam リリースに向けたワークフロー設計のご相談を承ります。

「AI駆動でインディーゲームを Steam に出したい」「Love2D の本格プロジェクト構造を相談したい」「個人開発のリリース戦略を一緒に考えてほしい」など、お気軽にご連絡ください。あわせて、『SwingByByBy』の Steam ウィッシュリスト追加と僕の SNS フォローも、よろしくお願いします。