本記事は、Applibot Advent Calendar 2025 の13日目の記事です！
1. スマホゲーム開発におけるモックについて
スマートフォンゲームの開発の最初期には、頭の中に浮かべているゲームについて
その遊びや操作感・面白さを確かめるためにモックを作成して検証することがあります。
例えば、Unityを用いてスマホゲームのあそびを検証する場合について考えましょう。
今回はチームメンバーに遊んでもらうことを想定します。
まずは、そこまでに実施しなければならないアクションを考えてみました。
- 検証したいことを洗い出す
- Unityで実装する
- Android/iOS向けにビルドを実施する
- 成果物をFirebase App Distributionなどでチームメンバーに共有
実装は1からの制作も多く、数日かかることもあるでしょう。
Jenkinsのビルド環境やアプリのリリース環境を整えるなど、
初回のセットアップにもかなりの工数を要すると思います。
勿論モックも１種類ではないので、別パターンの検証がまた走ります。
全く別の遊びを試したいとなったら、また1から作ることもあるかと思います。
その度に数日かけて作ってはビルドして...作ってはビルドして...。
モックとして最後には捨てるため、細かい設計を考えず実装できるとはいえ
それでも時間はかかるかと思います。
2. 意外とWebでもできるのでは！
目標はスマートフォンゲームの操作感や遊びを素早く試して、
その感覚やイメージを他のメンバーに共有することです。
先ほどのUnityでのモック開発で課題となっていたのは、以下のあたりです。
- モック検証のビルドに時間がかかる
- 他メンバーに配布するまでのベースを構築しておく下準備が必要
- そもそもモックの実装に時間がかかる
これらに対して Web上でAIにモックを作らせてイテレーションを爆速で回して解決しよう！
という視点で試してみたのが本記事のテーマになります。
勿論ですが、ゲームの種類によって向き不向きがあると思います。
3Dアクションで立体感のある遊びなどは流石に検証できないですが、
2Dのアクション・パズル、UIイメージなどなら試せるかもしれません。
どう作らせるか
AI隆盛のこの時代、実装を全てAIに任せる Vibe Coding と呼ばれる
アプローチが流行しています。
プロンプトやルールで実装をするのに十分な情報を与えられてさえいれば、
それなりのクオリティの小さな成果物を素早く得ることができます。
今回はパーツ単位で検証することを想定して、
このアプローチでブラウザ上にモックを構築してみます。
ローカルサーバを立て、スマートフォンからでもブラウザで開けるようにすることで
スマートフォン独自の操作感やプレイ体験の検証が
ブラウザ上からも実行できることを期待します。
簡易的な2Dアクションゲームの例
例えば、簡易的な2Dアクションゲームを以下の要件で雑に投げてみました。
- 2D横スクロール
- ゴールエリアまで行くとクリア
- 操作
- 左手でジョイスティックを使って移動する
- 右手でタップしてジャンプする
- フィールド
- 重力がある
- 床と貫通床(下からは抜けられる床)がある
- 敵がいて当たるとゲームオーバー
これを仕様として書いた上で少しAIに整形してもらい、
ブラウザ向けゲームを作るように依頼し、得られた成果物が以下です。
ゲームらしいものが生まれてきました。
元々依頼していた要件は全て満たしており、要件的には期待通りの結果が得られました。
この間3-5分です。爆速です。
今回はとてもシンプルな例として取り上げていますが、
例えばフィールドのレベルデザインとして「貫通床」のアイデアが使えるのかであったり、
実際に操作できることで「操作イメージの共有」などが行いやすくなります。
ローカルサーバを立ち上げ、同じネットワーク上から
スマートフォンでもアクセスできるようにすることで
ページ更新のみでスマートフォンからも動作を素早く確認することができました。
新たに生まれた機能要件に素早く対応する
しかし、これをチームメンバーに触ってもらったところ、新たな要望を伝えられました。
例えば、以下のようなものです。
- 地面に高低差を持たせたい
- 時折ジャンプしてくる敵を配置してみたい
ではこれらの情報も加えて仕様書を更新し、AIに差分を読ませ、対応を任せてみましょう。
- 2D横スクロール
- ゴールエリアまで行くとクリア
- 操作
- 左手でジョイスティックを使って移動する
- 右手でタップしてジャンプする
- フィールド
- 重力がある
- 床と貫通床(下からは抜けられる床)がある
- 地面に高低差がある
- 敵がいて当たるとゲームオーバー
- 敵
- 横方向に歩く敵
- 1秒おきにジャンプする敵
実行した結果が上記の動画です。
少しばかり手応えのあるステージになりましたね。
これもものの数分で対応が完了し、かつブラウザを更新すれば
すぐに他メンバーもスマートフォン上で動作を確認することができます。
このように簡易的ではありますが、モック開発において生まれる、
「プレイしたことによって生まれた新しいアイデア」をすぐに形にすることが出来ました。
3. 手順紹介
動作環境
- Claude Code v2.0.65
- claude-sonnet-4-5-20250929
- Node.js v22.15.1
ルール
最小限ですが、複数回サイクルを回すことを考慮して以下ルールを用意しました。
概ね仕様書駆動で実装することと、プロンプトログを残すことを記しています。
## 作業場所
プロジェクトルート直下に作成されたディレクトリ単位でモック作業を実施します。
仕様書は`Specification.md`に持ちます。
``
[Project Root]
├── [作業フォルダ名1]/
│ ├── Specification.md ← 仕様書
│ ├── YYYY-MM-DD_task_log.md ← プロンプトログ
│ ├── index.html
│ ├── game.js
│ └── server.js
│
├── [作業フォルダ名2]/
│ ├── Specification.md ← 仕様書
│ └── ... (その他のファイル)
│
└── ...
``
## 実行時ルール
[必須] 作業時にプロンプトのログを以下フォーマットで残すこと
``
------------------
- 作業日: YYYY-MM-DD
- 作業フォルダ: -
------------------
## 作業概要
- 対応する内容の説明
## Step 1
**プロンプト内容**
``
ここに1回目のユーザプロンプトを記載する
``
**作業内容**
- 作業A
- 作業B
**結果**
- 結果内容
## Step 2
...
``
Agentとのラリー
基本は1セッション1作業を徹底し、仕様ドリブンで実装や修正を行わせます。
修正を行うときは仕様を修正してから実装を修正します。
4. 他の検証例紹介: マッチ3ゲームの操作感検証
先ほどは2D横スクロールアクションを題材に試しました。
次はマッチ3ゲームの操作感検証のモックを作成します。
マッチ3ゲームとは、3つ同じものを1列に揃えて消すパズルゲームです。
マッチ3ゲーム (Match 3 Games) は、コンピュータゲーム向けパズルゲームの一種である。マッチ3とは日本語で「3つ合わせ」の意味である。1
マッチ3ゲーム - Wikipedia より
本節では揃える際の操作感を決めていく段階を想定し、
どんな操作が良いか確認するために、提案に挙がったモックを全て作らせてみます。
今回は以下の3パターンを検証してみることにしました。
- スワイプで揃える
- 入れ替え元・隣の入れ替え先で２タップさせる
- タップだけで近くに揃えられるのがあったら揃える
仕様のベースとして以下を用意しました。
この「操作方法」の項目を試行ごとに切り替えていくイメージです。
# マッチ3ゲームの仕様
## 1. 画面
- 16:9で横持ち想定
- スマートフォン操作想定
- セーフエリア対応
- フォント12pt以上
## 2. ゲームルール
- 8x8の盤面, 5色(赤,橙,黄,緑,青)
- 縦横で3個同じ色が続くと消える
- 消えたマスの上のマス要素がそのまま下に落ちてくる
## 3. 操作方法
- スマートフォンのスワイプ入力
- 移動元マスから4方向にスライド可能
- スライドした方向のマスと入れ替えてマッチ判定
- マッチしたら消え、しなければ元に戻る
実行結果と考察
操作感がイメージ通りになるように何ラリーかAIとやり取りしたことで得られたのが、
以下のパターンになります。（ちょっと分かりづらいですが）
| スワイプで揃える | 入れ替え元・隣の入れ替え先で２タップさせる | タップだけで近くに揃えられるのがあったら揃える |
|---|---|---|
 |
 |
 |
「スワイプで揃える」アプローチは、馴染みのある操作感でしたが
スワイプする時に相互のマスの入れ替えアニメーションがなく違和感がありました。
ここからマスを入れ替えようとするアニメーション演出が重要であることが分かったり、
その速度が指の入力に沿っていないと違和感を感じることにも気づけました。
「入れ替え元・隣の入れ替え先で２タップさせる」アプローチは検証前、
タップ数が増えることから操作的に手間に感じるのではという懸念がありました。
しかし、実際に触ってみるとそこまで違和感がなく、
むしろマスの入れ替えアニメーションで遊べる表現の幅が生まれたようにも感じました。
「タップだけで近くに揃えられるのがあったら揃える」アプローチは、
簡単操作でできるかもというアイデアから試してみました。
しかし、想定しないマッチができたり、感覚が追いつかないなど
プレイ的には反対に不満が生まれるようなものでした。
ここまでの検証をものの30分で、かつスマートフォン上で実施することができました。
また、ここまででかなり多くの発見があり、これを共有できる環境を構築できました。
すごい。
もちろんお任せ実装なので、細かい部分で表示的に怪しい部分はいくつもありますが
操作感など別の観点を見ている以上、そこまで気にする必要がありませんでした。
コンテキスト管理
ちなみに3つ目の操作を検証する際、コンテキストが溢れかける状態になりました。
ここで、3つ目の操作を検証する前に一度作業環境をクリーンにした上で、
ここまで書き残してきたプロンプトログを読ませることで
作業をより引き継ぎやすいようにしています。
5. まとめ・使い所
本記事では、スマートフォンゲームのモック制作に対して、
AIによるVibe Codingでブラウザ上にゲームを構築することで
イテレーションの高速化を試みました。
今回はモックで部分検証が目的なので、端から端まで作り切る必要はなく、
検証したい箇所に絞ってAIに実装させるアプローチは
高速でかなり効果的だったと実感しています。
いくつかパターンをみてみたいと要望があるなら、
そのパターンをすべてAIに実装させることもできました。
スマホ操作の検証ができるのはかなり良い
今回はローカルサーバを立ち上げて、同じネットワーク上で
スマートフォンのブラウザから接続することで
手元での検証ができるようにしました。
スマートフォンゲーム特有の指で隠れる部分や、スワイプによる操作感など
ユニークな操作は多いので、手触りの検証をするならぜひ試してみてもらいたいです。
更新すればすぐに反映されるのも非常に強みだと感じられました。
また、チームメンバーへの共有を前提とするなら、
GitHub Pagesなどの静的サイト上にデプロイを行い
スマートフォン上からリポジトリにアクセスするのも良いと思います。
作りづらいもの
ゲーム性によって作りづらいのは前述の通りですが、
作った成果物Aと成果物Bを統合したり、大きいものを作るのは
Vibe Codingでは厳しい印象でした。
もちろんしっかり仕様を切ったり、堅牢な設計や制約のもとに実装すれば
いくらかは改善できるかもしれませんが、
それは元々重視していたイテレーションの高速化を無視することになります。
ある程度パーツ単位で試していき、
「この方針でいってみよう！」となるなら
それはもうUnityなどに持っていき、
統合して試してみるのが良いのかもしれません。
まだ十分に試しきれたわけではないので、
より良いアプローチなどあればぜひご教示ください！
株式会社アプリボットでは、 エンジニアをはじめ全職種で積極採用中 です。
記事を読んで少しでも興味を持たれた方やお話を聞きたい方は、是非お気軽にご連絡ください！
明日は @shoma3571 さんになります。
お楽しみに！
-
Wikipedia, マッチ3ゲーム, https://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%83%E3%83%813%E3%82%B2%E3%83%BC%E3%83%A0 , 2025/12/11 ↩