2026年9月28日のAstraゲーム制作週報では、方向性の異なる2件を取り上げます。
ひとつは、1回の利用者入力から約21分で公開版まで仕上げた小規模ゲーム「Mosswing」。もうひとつは、GodotとBlenderを組み合わせ、変形メカや破壊可能なロボットなどの機構を数晩かけて試した技術実験です。
前者は規模を絞って完成度を優先する方法、後者は観察と修正を繰り返して複雑な3D機構を育てる方法として参考になります。
この記事でいうone-shotは「利用者からの入力が1回」という作者の説明を指します。Astra内部の計画、ツール実行、自己検査まで1回だったという意味ではありません。
夕宮たいだふぁ……みんな〜、今週は21分で公開まで進んだ小さなゲームと、GodotとBlenderで作った変形メカの実験だよぉ。
今週の2事例を比較
ひとことで：Mosswingは小さく完成させた公開作品、Godot・Blenderのほうはゲームループのない技術実験です。
| 観点 | Mosswing | Godot・Blenderメカニクス実験 |
|---|---|---|
| 公開状態 | ブラウザで遊べるゲーム。ソースと単一HTMLを公開 | 作者の動画・工程説明・変形メカのプロンプトを公開 |
| 完成度 | 小規模ながら開始、得点、ゲームオーバー、再挑戦を備える | 作者自身が粗さ、未調整、ゲームループなしと説明 |
| 主な技術 | HTML、JavaScript、Three.js | Godot 4.5、C#、Blender Python、GLB |
| 制作方法 | Astra xHigh、one-shot、作者申告21分 | スクリプト生成、複数角度レンダー、自己観察、修正を反復 |
| 人間の役割 | 固定ルール、配布形式、素材制約、品質基準を1回の依頼にまとめる | 要件の具体化、GLBの配置、秒数・角度・効果による追加指示 |
| 独立確認の限界 | 実機モバイル操作、検査スクリプト再実行、素材全体の監査は未実施 | プロジェクト、実行版、性能・LOD・接地テストは未確認 |
Mosswing――21分で公開版まで到達した小さなゲーム
ひとことで：守る条件を人が固定し、表現はAstraに任せて、作者申告21分で公開版まで進んだ事例です。
出典：Mosswing 公開版／公開プロンプト・ソース・制作条件（GitHub）
「Mosswing」は、画面をタップして小さな生き物を浮かせ、流れてくる隙間を通過して得点を伸ばす3Dブラウザゲームです。
作者Ayi1337氏は、GPT-6 Astra xHighを使ったone-shot試験として公開しています。作者申告の制作時間は21分です。専用ゲームエンジンは使わず、Three.jsでブラウザ3Dを実装。ゲームコード、単一HTML、ビルドと検査に使うスクリプトが公開されています。
「固定する部分」と「委ねる部分」を分ける
公開プロンプトでは、ゲームとして成立する条件が先に固定されています。
- モバイルブラウザで即座に遊べる
index.htmlひとつで配布できる- タップで上昇し、重力で下降する
- 隙間がプレイヤーへ流れてくる
- 一度接触したらゲームオーバー
- 隙間を通過すると得点
- 外部アセットは使わず、CDNライブラリだけを許可
- 追加質問をせずに進める
一方、キャラクター、世界、カメラ、演出、操作感の方向性はAstraへ委ねています。
さらに、「機能を多くすることより、小さくても完成度が高いことを評価する」という品質基準が明記されています。中心ループと配布条件を人間が固定し、表現の自由度をAIへ渡す構造です。
夕宮たいだ真ん中のルールと配り方は人が決めて、見た目や演出はAIに任せる……分担がはっきりしてるねぇ。
one-shotを過大評価しない
one-shotは、作者が追加入力をしなかったという意味です。Astraが内部で何回ツールを使い、実行結果を確認し、自己修正したかは公開記録から分かりません。21分も作者申告で、同条件を第三者が再現した値ではありません。
「短い一文で完成した」と読むより、完成条件、禁止事項、自由に決めてよい範囲、評価軸を含む詳細な依頼を1回渡した事例として見るのが適切です。
夕宮たいだone-shot……って、人が1回しか頼んでないって意味で、AIの中で1回きりって意味じゃないんだねぇ。むずかしいねぇ。
公開ページでは、開始導線、タップまたはSpaceキーの操作説明、スコア、個人ベスト、再挑戦、WebGL非対応表示を確認しました。ただし、今回の調査では実際の操作、実機スマートフォン、検査スクリプトの再実行を行っていません。
アセットについても、外部アセット禁止はプロンプト上の条件です。公開ソースにはThree.js本体とそのライセンスが含まれていますが、リポジトリ全体のライセンスと、画像・音声・フォントを含む全ファイルの監査は未確認です。閲覧できることと、自由に再利用できることは分けて考える必要があります。
GodotとBlenderで複雑な機構を育てる
ひとことで：Blender用スクリプトで作り、画像で見て、直す、をくり返して3D機構を育てた技術実験です。
idlerunner00氏は、GPT-6 Astra、Godot 4.5、Blenderを組み合わせた複数の3D機構を公開しています。
作者が挙げた内容には、動的な移動とグラップル、LOD付きボクセル世界、物理破壊、部位を壊せるロボット、搭乗可能な大型ロボット、変形するペット、スキーモードなどがあります。
ただし、作者自身が「粗い部分が多い」「バランスが取れていない」「ゲームループがない」と明記しています。見栄えのする映像があっても、完成ゲームではなく、複数メカニクスを集めた技術実験として扱うべき事例です。
Blender用スクリプトを作り、画像で自己検査する
作者が説明した制作フローは次のとおりです。
- AstraがBlender用Pythonスクリプトでモデルを作る
- ヘッドレス実行し、複数角度から画像をレンダリングする
- Astraが比率、干渉、形状を観察する
- 問題を見つけてスクリプトを修正する
- 歩行、待機、攻撃、変形などのアニメーションを作る
- フレーム画像で動きを確認し、再び修正する
- GLBへ書き出す
- 人間がGodotへ配置し、C#側の実装を進める
中心にあるのは「生成」ではなく、「作る、見る、問題を特定する、直す」という観察反復です。3D形状をコードで作っても、実際のシルエットや部品の食い込みは画像で確かめなければ分かりません。
変形メカのプロンプトは仕様書に近い
ひとことで：作るものだけでなく、避ける失敗・測る項目・残す成果物まで書いた依頼です。
同作者が公開した変形メカの依頼では、四脚歩行、車輪走行、飛行の3形態を指定しています。さらに、見た目だけでなく、次のような評価条件まで含めています。
- 関節、可動域、装甲、変形経路を詳細造形より先に設計する
- 既存部品を使って3形態へ変形する
- 変形中に装甲を交差させない
- 部品を突然消さず、不自然に伸縮させない
- 変形を途中で中断、逆再生できるようにする
- 接地した足を滑らせない
- 脚同士の衝突を避ける
- 接地、コリジョン、LOD、UV、PBR、GLB出力を検証する
- 平地、段差、坂、壁、天井で動作を確認する
- 1体時と複数体時の性能を測る
これらは「何を作るか」だけでなく、「どの失敗を避けるか」「何を測るか」「何を成果物として残すか」を定めています。
夕宮たいだほえ〜、「変形中に装甲を交差させない」まで書いてあるんだねぇ。ほとんど仕様書だよぉ。
ただし、プロンプトに書かれた要件がすべて実装され、検証を通ったことを示す資料は公開されていません。LOD、接地、変形中断、性能測定などは、確認済みの成果ではなく依頼条件として読む必要があります。
作者によると、変形メカ単体は追加指示を含めて約5時間、途中の離席を含み、利用量は約5%でした。周辺のメカニクス集全体は数晩かけて作られています。いずれも作者の概算です。
ポリッシュは「もっと良く」ではなく測れる言葉にする
ひとことで：「気持ちよく」を時間・距離・角度などの測れる値に分けて伝えると、比べて直しやすくなります。
この事例で特に再利用しやすいのが、磨き込みの伝え方です。
「もっと気持ちよくして」ではなく、作者は次のような観測可能な値へ分解しました。
- 着地時に0.1秒の潰れを入れる
- 足元へ砂ぼこりを出す
- 着地に合わせてカメラを3度下げる
時間、距離、角度、速度、回数へ分けると、Astraが実装し、前後を比較しやすくなります。この方法はアニメーションだけでなく、ヒットストップ、画面振動、UI遷移、効果音にも応用できます。
夕宮たいだ0.1秒、3度……って数字で頼むと、前と後を比べやすいんだよぉ。ほら、便利でしょ？
2事例から分かる依頼の基本形
ひとことで：完成物の境界、任せる範囲、合否の言葉、観察と修正、完成と実験の区別の5つを依頼に入れます。
1. 完成物の境界を決める
対応環境、ファイル構成、操作、ゲームオーバー、再挑戦など、成立に必要な条件を固定します。
2. AIへ委ねる範囲を書く
世界観、キャラクター、色、カメラ、演出など、自由に決めてよい部分を明示します。
3. 評価軸を合否で判断できる言葉へ変える
「小さくても完成している」「接地した足が滑らない」「変形中に部品が交差しない」のように、結果を観察できる基準を使います。
4. 観察と修正のループを依頼する
生成して終わらせず、複数角度の画像、フレーム画像、デバッグ表示、実行結果、エラーログを確認して直すよう求めます。
5. 完成ゲームと技術実験を分ける
公開映像の見栄えだけで判断せず、ゲームループ、バランス、配布形態、テスト、ソース、再現性を別々に確認します。
まとめ
ひとことで：小さく完成させる方法も、観察しながら育てる方法も、条件と評価軸は人が設計しています。
Mosswingは、ゲームの核と配布条件を固定し、表現をAIへ委ね、完成度を優先する評価基準を与えたことで、小さな公開作品へ短時間で到達した事例です。
GodotとBlenderの実験は、複雑な3D制作ではスクリプト生成、レンダリング、自己観察、修正、エンジン上での検証を繰り返す方法が有効だと示しています。
重要なのはプロンプトの長さではありません。人間が「守る条件」「自由に決めてよい範囲」「成功と失敗を分ける評価軸」を設計し、AIが結果を観察して修正できる工程まで渡すことです。
参考リンク
※制作時間、モデル設定、利用量、作業分担には作者本人の申告を含みます。プロンプトに書かれた依頼条件と、実装済みとして独立確認できた機能を区別して記載しています。
夕宮たいだふぁ……小さく完成させるのも、見ながら育てるのも、決めるのは人なんだねぇ。今週もおつかれさま〜。
次に読む記事
- GPT-6 Astraゲーム制作週報 9月22日｜4日・39時間・195分の3事例：前の週の3作品
- GPT-6 Astraゲーム制作週報 9月14日｜2作品に学ぶ反復開発：週報の1回目・2作品
- GPT-6 Astraのゲーム制作活用事例｜エンジン・アセット・プロンプトを調査：公開事例から、うまくいった作り方の共通点をまとめた記事
- Claude Code × 3DCG活用ガイド｜Blender・Maya・Houdini・Substance連携：AIエージェントとBlenderなどの3DCGツールの連携
- Codexプロンプト設計｜Goal・Context・Done whenの書き方：守る条件と完了条件の書き方
