Godot 4 のプロジェクトに「Antigravity を持ち込む」と決めた最初の一週間、私はずっとGDScriptの生成精度に半信半疑でした。Unity や Unreal に比べて学習データが少ないのではないか、AI が生成するコードがそのままでは動かないのではないか、と疑っていたわけです。ところが実際に毎日触ってみると、Godot 4 の素直な構文と Antigravity のコンテキスト理解が想像以上にかみ合い、シェーダーやノード設計の試行錯誤が以前の半分以下の時間で済むようになりました。
ここでは私が個人インディー開発で実際に使っている「Godot 4 × Antigravity」のワークフローと、つまずきやすいポイントを共有します。Unity や Unreal Engine のガイドはすでに数多く存在しますが、Godot 4 については日本語の実践記事がまだ少ないので、これから始める方のヒントになればうれしいです。
なぜ Godot 4 を Antigravity で書くと相性が良いのか
Godot 4 が AI コーディングと相性が良い理由は、シーン・ノード・スクリプトという3層構造が単純で、AI に渡すコンテキストが小さく済むことにあります。Unity のように MonoBehaviour の継承関係を辿らせる必要がなく、Node2D や CharacterBody2D を継承した GDScript ファイル1枚で完結する場面が多いのです。
Antigravity の Manager Surface でルートシーンと該当スクリプトを開いておけば、@onready 変数とシグナルの命名規則を自動で揃えてくれますし、func _physics_process(delta) の中で move_and_slide() を呼ぶ典型パターンもよく学習されています。Unity 連携の感触については Unity を Antigravity で高速開発する実践ノート でも触れていますが、Godot は「AI に渡すべき情報量がさらに少ない」ぶん、生成精度が安定しやすい印象です。
最初に整えたい3つのプロジェクト設定
Godot 4 のプロジェクトを新規作成したら、Antigravity が文脈を把握しやすいように次の3点を最初に整えます。
project.godotの[input]セクションを先に書く: キーマップを先に定義しておくと、AI がInput.is_action_pressed("move_left")のようなコードを正確に生成しますaddons/以下のプラグインは最小限に: GodotSteam や Phantom Camera などの大型プラグインを最初から入れると、AI がプラグイン側のメソッドを誤って提案することがあります。コアが固まってから足すのが安全ですglobals.gd(AutoLoad) を最初に1つ作る: ゲーム状態・スコア・サウンドマネージャを集約した AutoLoad があるかないかで、AI の生成が「グローバル変数を雑に作る」か「既存の Globals に乗せる」かの分岐になります
特に AutoLoad は、Antigravity に「このプロジェクトでは状態を Globals に集約している」と暗黙に伝える実用的のシグナルになります。
プレイヤーキャラクターを Antigravity で書くときの定型
私が実際に使っているプロンプトの骨格は次のとおりです。Antigravity のチャットに @CharacterBody2D のシーンと該当 .gd ファイルを添付して、こう投げます。
このCharacterBody2Dに、以下の挙動を持つPlatformerコントローラを書いてください。
- 重力は ProjectSettings の default_gravity を使用
- 左右移動: 加速・減速付き、空中での制御は地上の60%
- ジャンプ: 短押し・長押しで高さが変わる可変ジャンプ
- コヨーテタイム 0.1秒、ジャンプバッファ 0.1秒
- 値はすべて @export で外から調整できるように
返ってくるコードはほぼそのまま使えますが、私は必ず以下のように手を加えます。
extends CharacterBody2D
# プレイヤーの動きを @export で外部調整可能にする
# Antigravity が生成した値を、シーンエディタから即座に試せるようにするためです
@export var move_speed: float = 220.0
@export var jump_velocity: float = -380.0
@export var air_control: float = 0.6
@export var coyote_time: float = 0.1
@export var jump_buffer_time: float = 0.1
# プロジェクト設定の重力を取得（ハードコードを避ける）
var gravity: float = ProjectSettings.get_setting("physics/2d/default_gravity")
# タイマー値（コヨーテ・ジャンプバッファ）を内部状態として保持
var coyote_counter: float = 0.0
var jump_buffer_counter: float = 0.0
func _physics_process(delta: float) -> void:
# --- 重力 ---
if not is_on_floor():
velocity.y += gravity * delta
coyote_counter -= delta
else:
coyote_counter = coyote_time
# --- 入力 ---
var direction := Input.get_axis("move_left", "move_right")
var control := 1.0 if is_on_floor() else air_control
velocity.x = move_toward(velocity.x, direction * move_speed, move_speed * control * 4 * delta)
# --- ジャンプバッファ ---
if Input.is_action_just_pressed("jump"):
jump_buffer_counter = jump_buffer_time
jump_buffer_counter -= delta
if jump_buffer_counter > 0 and coyote_counter > 0:
velocity.y = jump_velocity
coyote_counter = 0
jump_buffer_counter = 0
# --- 可変ジャンプ（短押しで頭打ち） ---
if Input.is_action_just_released("jump") and velocity.y < jump_velocity * 0.5:
velocity.y = jump_velocity * 0.5
move_and_slide()ポイントは、ProjectSettings.get_setting() で重力を取り出している部分です。AI に任せると var gravity: float = 980.0 のようにハードコードされがちですが、ここは必ずプロジェクト設定から拾うように指示します。シーンごとに重力を変えたい場合に大きな差が出るからです。
シェーダーは「自然言語 → GLSL」で素早く試す
Godot 4 の Visual Shader を AI に書かせるのは難しいのですが、shader_type canvas_item; から始まる通常のシェーダーコードは Antigravity が驚くほどよく生成します。私がよく使うのは「ピクセルアートの色を保ったまま、ヒット時に白く点滅させるシェーダー」です。
shader_type canvas_item;
// 0.0〜1.0 の白フラッシュ強度。GDScript側から一時的に上げる
uniform float flash_strength : hint_range(0.0, 1.0) = 0.0;
void fragment() {
vec4 tex_color = texture(TEXTURE, UV);
// アルファを保ったまま、RGBだけ白に近づける
vec3 flashed = mix(tex_color.rgb, vec3(1.0), flash_strength);
COLOR = vec4(flashed, tex_color.a);
}GDScript 側で material.set_shader_parameter("flash_strength", 1.0) を呼び、Tween で 0.1 秒かけて 0.0 に戻すだけで、被弾エフェクトが完成します。Antigravity に「このシェーダーを使う Tween 付きの被弾演出を Sprite2D に追加して」と頼めば、GDScript 部分も即座に生成してくれます。
シェーダーやアセット作成の自動化を含めた個人開発の全体像については、個人開発でアートアプリをiOS/Androidに公開した実体験記 でも触れていますので、興味があれば併せてご覧ください。
つまずきやすいポイントと対処
私が実際にハマって、検索しても日本語情報がほとんど出なかったポイントを共有します。
@onreadyのタイミング問題: 子ノードを_ready()で動的に生成すると@onready varの取得タイミングと前後し、null参照になります。Antigravity は気を利かせてawait get_tree().process_frameを入れてくれることがありますが、原則としては動的生成の参照は@onreadyではなく明示的な変数代入にしましょう- TileMap から TileMapLayer への移行: Godot 4.3 以降は
TileMapが非推奨でTileMapLayer推奨に変わりました。AI が古いチュートリアルを参考にしてしまうことがあるので、プロンプトに「Godot 4.3+ のTileMapLayerAPI を使ってください」と明示します - C# プロジェクトと混在させない: GDScript と C# を1プロジェクトに混ぜると、Antigravity が両方の API を混同したコードを出すことがあります。個人開発では GDScript 一本に絞るのが、結果的に最速です
ビルドとモバイル書き出しまでの一気通貫
Godot 4 のエクスポートテンプレートを設定すると、Antigravity のターミナルから次のコマンドだけで Android APK までビルドできます。CI に乗せやすいのも個人開発の追い風です。
# Android APK を CLI からエクスポート（プロジェクトルートで実行）
godot --headless --export-release "Android" build/game.apkこのコマンドを tasks.json 相当の場所に登録しておけば、AI に「ビルドして APK を build/ に出して」と頼むだけで実行してくれます。App Store 側の作業の流れは 個人インディーゲームをApp Storeに出す90日ロードマップ にまとめています。
書籍で体系的に
次の一歩
Godot 4 と Antigravity の組み合わせは、まだ事例が少ないぶん、自分のワークフローを言語化して残しておく価値があります。今日試すなら、まずは小さな AutoLoad（Globals.gd）を1つ作って、Antigravity に「このプロジェクトはここに状態を集約しています」と伝える土台を整えてみてください。それだけで、明日からの生成精度がはっきり変わるはずです。