投稿する
マガジン
著者：アソバース編集部公開：更新：約8分で読めます

GodotとAIの相性：GDScriptをAIに書かせるときの注意

遊びをつくる

執筆にClaudeを使用しています。

会話しながらアイデアを試し、作られた小さなゲームを自分の手で確かめる制作机。
記事のテーマをもとに制作したAI生成イラスト。

GDScriptはGodot専用のスクリプト言語です。Pythonに似た文法を持ちながら、Godotのノードシステムやシグナルといった独自の概念を前提に設計されています。ChatGPTやClaudeといった汎用AIを使ってGDScriptを書かせようとすると、「動かないコードが返ってくる」「Godot 4のコードを頼んだのにGodot 3の書き方で返ってくる」という失敗がよく起きます。 これはAIの能力の問題というより、GDScriptという言語の特性とAIへの伝え方のミスマッチが原因です。AIはGDScriptを大量に学習していますが、Godot 3からGodot 4への移行で多くの記法が変わったため、バージョンを明示しないと古い書き方と新しい書き方が混在したコードを生成しがちです。この記事では、その失敗を避けるための判断基準と、実際にAIへ依頼するときの手順を整理します。

この記事の目次
  1. なぜGDScriptはAIと相性が難しいのか
  2. バージョンとコンテキストを先に渡す
  3. 返ってきたコードの確認ポイント
  4. 「うまく動かない」を解決する聞き方
  5. AIが不得意な部分を自分で補う
  6. 次の行動
  7. 参考資料

なぜGDScriptはAIと相性が難しいのか

AIが学習しているGDScriptの情報は、Godot 3時代のものが相当量含まれています。Godot 4ではonreadyが@onreadyになり、exportが@exportになるなど、アノテーション記法が変わりました。yield()は廃止され、非同期処理はawaitを使います。connect()の書き方もシグナルの渡し方も変わっています。

AIはバージョンを指定されなければ、確率的にどちらかの書き方を返します。結果として、Godot 4プロジェクトに貼り付けると赤いエラーが並ぶ、という状況になります。これがGDScript特有のハマりポイントです。JavaScriptやPythonはバージョン間の差異があっても基本構文は安定していますが、GDScriptはGodot 4移行の断絶が大きく、バージョンの明示が必須になります。

加えて、Godotのシーンツリーやノードパスへのアクセス（$Node名やget_node()）は、プロジェクト固有の構造に依存します。AIはその構造を知らないまま推測でコードを書くため、パスが合わず実行時にエラーになることがあります。

バージョンとコンテキストを先に渡す

AIにGDScriptを依頼するときの基本ルールは「バージョン・ノード構成・目的」の三点セットを最初に書くことです。

依頼文に含める三点セット

  1. Godotのバージョン：「Godot 4.3で動くコードを書いてください」と明示します。マイナーバージョンまで書くと精度が上がります。
  2. ノード構成：「CharacterBody2Dの下にSprite2DとCollisionShape2Dがあります」のように、関係するノードの親子関係を書きます。コードの中でどのノードにアクセスするかをAIが把握できれば、$Sprite2Dのようなパスの推測ミスが減ります。
  3. やりたいこと：「左右キーで移動し、ジャンプボタンで跳ぶ」のように動作を具体的に書きます。「プレイヤーを作って」のような抽象的な依頼はAIの解釈が広がり、期待と違うコードが返りやすくなります。

この三点を渡すだけで、生成されるコードの精度は大きく変わります。特にバージョン明示は最優先です。

返ってきたコードの確認ポイント

AIが生成したGDScriptをそのまま貼り付ける前に、次の点を目視で確認する習慣をつけると時間を節約できます。

Godot 4かどうかを見分ける記法チェック

  • @onreadyや@exportのアノテーション形式になっているか（onready varやexport varはGodot 3の書き方）
  • awaitを使った非同期処理になっているか（yield()が残っていればGodot 3の残骸）
  • func _ready():やfunc _process(delta):のインデントがスペース統一になっているか（タブとスペースの混在はGodotでエラーになります）
  • connect()の書き方：Godot 4ではsignal_name.connect(callable)の形が推奨されています

ノードパスの確認

$で始まるパスはすべて自分のシーンツリーと照合します。AIが推測で書いたパス名（$Playerや$Enemyなど）がシーン上の実際のノード名と一致しているかを確認します。一致していなければ実行時にnull参照エラーになります。

シグナルの接続先

シグナルのコールバック関数名がAIの生成コードと、実際にエディタ上で接続した関数名と一致しているかも確認が必要です。AIはよく_on_button_pressedのような名前を使いますが、エディタ経由で接続するとGodotが自動生成する名前（_on_Button_pressedなど）と大文字小文字が違うことがあります。

「うまく動かない」を解決する聞き方

コードを貼り付けてもうまく動かないとき、そのエラーメッセージをそのままAIに貼り付けて聞くのが最短です。Godotのエラーはスタックトレースが明確なので、「○行目でnullを参照している」「関数が見つからない」といった情報が得られます。このエラーテキストをAIに渡すと、原因の見当をつけやすくなります。

聞き方の例として「Godot 4.3で以下のコードを実行したらこのエラーが出ました。修正してください。（コード）（エラーメッセージ）」という形式は実用的です。エラーなしに「動きません」とだけ聞いても、AIは推測で複数の可能性を並べるだけになります。

もう一つ有効なのは「このコードを日本語で説明してください」という使い方です。生成されたコードの意味をAI自身に説明させることで、意図しないロジックが混入していないかを確認できます。コードを読む力がまだついていない段階でも、説明文を読むことで「自分がやりたいこととズレている」と気づきやすくなります。

AIが不得意な部分を自分で補う

AIにGDScriptを書かせるときに任せてよい部分と、自分で設計すべき部分を分けて考えると、作業全体がスムーズになります。

AIが比較的得意なのは、移動・当たり判定・アニメーション切り替えといった定型的な処理パターンです。「CharacterBody2Dで8方向移動」「AnimationPlayerで状態に応じてアニメーションを切り替える」のような、Godotのチュートリアルに登場するパターンはデータが豊富で、精度が高いコードが返りやすいです。

一方、ゲーム固有のルール（スコアの計算式・ステージ遷移の条件・AIの行動パターンなど）はプロジェクト固有の設計が必要です。ここをAIに丸投げすると、動くが意図しない挙動のコードができあがります。「ロジックの骨格は自分で設計し、定型パターンの実装をAIに任せる」という役割分担が現実的です。

また、GodotのシグナルやResourceの継承構造のような設計レベルの判断は、AIが提案するコードがプロジェクトの規模に対して過剰になりがちです。小さなゲームには複雑な設計より、シンプルで自分が読めるコードの方が価値があります。AIが「きれいなアーキテクチャ」として提案するパターンが、必ずしも自分のプロジェクトに必要とは限りません。

次の行動

Godotで試す場合は、まず「Godot 4.○（自分のバージョン）」「使っているノードの親子関係」「やりたい動作」の三点を整理してからAIに依頼してみてください。返ってきたコードはアノテーション記法とノードパスの二点を優先的に確認します。ゲームが完成したら、アソバースのZIPアップロード機能を使ってHTML書き出しファイルをそのまま公開できます。

参考資料

  • Godot Engine 公式ドキュメント（GDScript リファレンス、Godot 3から4への移行ガイド）
  • Godot 公式GitHub リポジトリ（CHANGELOG）
マガジン一覧に戻る