前回の「GPT-6 Astraのゲーム制作活用事例」では、公開例を横断し、うまくいった制作の共通点を整理しました。今回から、追加で確認できた事例を週ごとに紹介します。
2026年9月14日分は、ブラウザ向け弾幕シューティング「THUNDERFALL」と、ジャングルを舞台にしたプラットフォームゲーム「Barrelbound: The Lost Cargo」です。
2作品から見えてきたのは、一度の指示で完成品を出させることより、完成条件を確認できる形にし、人間が試遊や評価を挟みながら反復することの大切さです。
この記事でいう「成功例」は、一般に触れられる公開版まで到達し、制作工程をある程度確認できる事例を指します。売上や継続率を含む商業的成功を意味するものではありません。
夕宮たいだふぁ……みんな〜、今週から Astra のゲーム制作を週ごとに追いかけるよぉ。今回は、弾幕シューティングと、ジャングルが舞台のプラットフォームゲームの2本だよぉ。
今週の2作品を比較
ひとことで：THUNDERFALLは素のJavaScript、BarrelboundはPhaser 3で作られ、どちらも人の評価や試遊を挟んで仕上げています。
| 作品 | ジャンル | エンジン・ツール | アセット | 制作方法 | 確認できた範囲 |
|---|---|---|---|---|---|
| THUNDERFALL | 縦スクロール弾幕シューティング | ネイティブJavaScript、Canvas 2D、Web Audio | 機体・敵・地形・エフェクトをプログラム描画。音声はリアルタイム合成 | 初回要求から実装し、機体造形への人間の追加フィードバックを受けて反復 | 公開ページ、ソース、依頼記録を確認。記載されたテストは未再実行 |
| Barrelbound | ジャングル・プラットフォーマー | Phaser 3、Vite、Web Audio | アートは別の画像生成工程。音楽・効果音はコード合成 | Astraが実装・ゲーム機構・反復・テストを支援し、人間が方向づけと試遊 | 公開URLの応答と作者説明を確認。全編の操作・完走は未検証 |
THUNDERFALL――会話的な依頼を、検証可能な仕様へ変える
ひとことで：会話的な依頼にも確認できる条件が入っており、人の指摘で作り直しながら仕上げた事例です。
出典：THUNDERFALL 公開版／制作・検証・ライセンス記録（GitHub）／実際の依頼と再利用用仕様（GitHub）
「THUNDERFALL」は、3種類の戦闘機から1機を選び、5つの空域を攻略する縦スクロール型の弾幕シューティングです。作者jackroc氏は、制作にGPT-6 Astra ultraを使ったと説明しています。モデル名と推論設定は作者申告であり、実行ログによる独立確認ではありません。
専用ゲームエンジンは使わず、ネイティブJavaScriptとCanvas 2Dで実装されています。戦闘機はコードで組み立てた立体的なメッシュをCanvas 2Dへ投影し、敵、地形、エフェクトもプログラムで描画。音楽と効果音にはWeb Audioのリアルタイム合成を使っています。作者の制作記録では、外部画像、外部音声、商用モデル、テクスチャ、第三者ランタイムへの依存はないとされています。
最初から完璧なプロンプトだったわけではない
公開記録では、「実際の初回依頼」と「完成後に整理した再利用用仕様」が分けて掲載されています。
初回依頼に含まれていた主な条件は次のとおりです。
- スマートフォンでも遊べる
- 3種類の戦闘機を選べる
- 5ステージ以上
- 通しプレイが10分以上
- レーザーや軌道の変化する弾を出す
- 4色の武器をドロップさせる
- 武器アイテムを画面内で約10秒漂わせる
文章は会話的でも、ステージ数、想定プレイ時間、武器数、対応端末など、完成後に確認できる条件が入っています。
最初の生成後、人間が戦闘機の造形を弱点として挙げ、より格好良く機械的な形へ作り直す反復が行われました。完成後に公開された詳細仕様は、最初から渡された長大なプロンプトではなく、成果物から整理した再利用用資料です。
この区別は重要です。完成版の仕様だけを見ると一度の完璧な指示で作られたように見えますが、実際には生成結果への具体的な評価と修正が挟まっています。
夕宮たいだほえ〜、完成後の仕様だけ見ると、一発で作ったように見えちゃうんだねぇ。途中の「ここが弱い」って指摘が大事なんだぁ。
テスト記録は具体的。ただし作者記録として読む
制作記録には、次の検証を実施したとあります。
- エンジン単体テスト27項目
- 固定フレームで5ステージの進行を検証
- 6回の自動操作による通し進行
- 縦画面・横画面を含む複数サイズでのブラウザ確認
- 選機、移動、射撃、武器取得、爆弾、停止、結果画面の動作確認
自動操作の有効戦闘時間は、約10分35秒から12分10秒だったと報告されています。
ただし、これらのテストは今回の調査で再実行していません。自動操作による完走を、人間が10分以上楽しく遊べた証拠として扱うこともできません。実機スマートフォンでの操作性と性能も未検証です。
それでも、何をテストし、何を確認していないかが記録されている点は、再現性のあるAIゲーム制作に役立ちます。
夕宮たいだ自動操作で最後まで進めても、人が10分以上楽しく遊べるかは別なんだよぉ。気をつけてねぇ。
Barrelbound――コードとアートを別工程に分ける
ひとことで：実装はAstra、アートは別の画像生成、方向づけと試遊は人、と役割を分けた事例です。
出典：Barrelbound 公開版／作者による制作説明（GitHub）
「Barrelbound: The Lost Cargo」は、RoccoまたはPipを操作し、3つのジャングルコースを進むプラットフォームゲームです。二段ジャンプ、樽を持って投げる操作、トロッコ、最終ボスなどが実装されていると作者は説明しています。
技術構成はPhaser 3とVite。音楽と効果音はWeb Audioによるコード合成で、アートは別の画像生成工程で用意されています。
作者のEmile du Toit氏による役割分担は次のとおりです。
- Astra: 実装、ゲームメカニクス、反復、テスト支援
- 画像生成工程: アート素材
- 人間: 企画の方向づけ、プレイテスト、改善判断
「Astraがゲームを作った」という表現だけでは、コード、画像、音声をどの工程で作ったのか分かりません。この事例では、言語モデルによる実装と、別の画像生成工程、Web Audioによる音声合成が区別されています。
一方、ソースコード、制作時間、初回プロンプト、推論設定、詳しいテスト内容、画像生成ツールと素材の権利条件は公開情報から確認できませんでした。ブラウザ版は公開されていますが、今回の調査ではゲーム全編の通しプレイを行っていません。
THUNDERFALLより再現に必要な情報は少ないものの、人とAI、コードとアートの役割を分ける実例として参考になります。
2作品から学べる4つのこと
ひとことで：確認できる条件を書く、弱点を具体的に返す、素材の出所を残す、自動テストと試遊を分ける、の4つです。
1. プレイヤーが確認できる条件を書く
「面白いゲームを作って」だけでは完成判定ができません。ステージ数、想定プレイ時間、対応端末、操作方法、武器やキャラクターの数、ボス、クリア条件まで書くと、AI自身の検査と人間の検収を設計しやすくなります。
2. 見た目の弱点は人間が具体的に返す
THUNDERFALLでは、最初の機体造形への評価が再設計の起点になりました。「もっと良く」ではなく、どこが弱く、どの方向へ寄せたいかを返すことが反復の質を上げています。
夕宮たいだ「もっと良く」じゃなくて、どこが弱いかを具体的に返すと、直す側も迷わないんだねぇ。
3. アセットは種類ごとに出所を残す
画像、3Dモデル、音楽、効果音、フォントを一括して「AI製」と表現せず、種類ごとの出所、生成ツール、外部ダウンロードの有無、ライセンスを記録する必要があります。
4. 自動テストと人間の試遊を分ける
自動操作は進行不能や数値条件の検査に役立ちます。操作感、難易度、読みやすさ、面白さの評価には人間の試遊が必要です。両方を別の検査として計画するのが安全です。
96件のコミュニティ一覧は「発見用」に使う
ひとことで：96件という数は検証済みの成功例の数ではないので、事例を探す入口として使います。
出典：Awesome GPT-6 Astra（GitHub）
2026年9月14日の調査時点で、コミュニティ運営の「Awesome GPT-6 Astra」には96件のゲームやインタラクティブ作品が整理されていました。
この一覧は、プレイ可能版、ソース、プロンプト、作者説明へ移動できる便利な入口です。ただし、OpenAIの公式資料や、統一条件で測ったベンチマークではありません。各作品でAstra使用の根拠、ソース公開、制作時間、人間の修正量、テスト範囲、完成度は揃っていません。
件数をそのまま「検証済み成功例の数」と読まず、候補発見に使い、重要な事例を作者の投稿、公開リポジトリ、プレイ可能版で個別に確認するのがよいでしょう。
夕宮たいだ96件もあると、全部すごく見えちゃうねぇ……。件数と完成度は別だから、一つずつ確かめるのがいいんだぁ。
まとめ
ひとことで：結果を左右したのはAstraの能力だけでなく、確認できる要件と人の試遊を組み込んだ制作工程です。
9月14日分の2例では、Astraの能力そのものに加え、制作工程の設計が結果を左右していました。
THUNDERFALLでは、確認可能な要件、具体的な人間のフィードバック、反復実装、テスト記録が揃っています。Barrelboundでは、Astraによる実装、別工程の画像生成、人間のプレイテストという役割分担が確認できました。
要件を決め、動くものを作り、人間が見て、直す場所を伝え、再度テストする。この循環が、公開できるゲームへ近づく基本形です。
参考リンク
- THUNDERFALL 公開版
- THUNDERFALL 制作・検証・ライセンス記録
- THUNDERFALL 実際の依頼と再利用用仕様
- Barrelbound 公開版
- Barrelbound 作者による制作説明
- Awesome GPT-6 Astra
※制作時間、モデル設定、作業分担、テスト結果には作者本人の申告を含みます。今回再実行した検証と区別して記載しています。
夕宮たいだふぁ……今週はここまでだよぉ。決めて、作って、遊んで、直す。このくり返しが大事なんだねぇ。
次に読む記事
- GPT-6 Astraゲーム制作週報 9月22日｜4日・39時間・195分の3事例：次の週の3作品
- GPT-6 Astraゲーム制作週報 9月28日｜21分のゲームと変形メカ実験：その次の週の2事例
- GPT-6 Astraのゲーム制作活用事例｜エンジン・アセット・プロンプトを調査：公開事例から、うまくいった作り方の共通点をまとめた記事
- Codexプロンプト設計｜Goal・Context・Done whenの書き方：確認できる完成条件の書き方
- レビュー・QAの設計｜人と自動の役割分担を決めるガイド：自動の検査と人の確認を分ける考え方
- Codex実践ワークフロー集｜調査・修正・レビューの依頼文例：直してもらうときの依頼文の例
