GodotのAIプラグインでは不十分な理由（そしてAIネイティブとは何か）
GodotのAIプラグインはコード生成には役立ちますが、シーンを操作したり、実行中のゲームを検査したり、エンジンレベルでアセットを作成することはできません。AIネイティブが実際に意味することをご紹介します。
Godotエコシステムにはかつてないほど多くのAIツールが存在します。MCPサーバー、エディタープラグイン、コードジェネレーター。これらはすべて同じ根本的な制約を共有しています。すなわち、エンジンの外側から後付けで組み込まれているということです。ファイルを読み、コードを書くことはできますが、ゲームが実行されている様子を見ることも、シーン階層を理解することも、エンジンシステムを直接操作することもできません。
そのギャップは見た目以上に重要です。それは、AIによる支援と真のAIゲームエンジンとの境界線なのです。
プラグインにできること
明確にしておくと、GodotのAIプラグインは有用です。コードを書く速度を上げ、ボイラープレートの作成を助け、自然言語のプロンプトからGDScriptを生成できます。ZivaやAI Assistant Hubのような一部のプラグインは、プロジェクトファイルを読み取って文脈に応じた提案ができます。さまざまなMCPサーバーが、Claude、Cursor、その他のAIツールをGodotプロジェクトに直接接続します。
個人開発者にとって、基本的なコード生成だけでも数時間を節約できます。シグナル接続のボイラープレートの記述、ステートマシンのセットアップ、適切な型を持つエクスポート変数の生成。これらは実際の生産性の向上であり、それらを提供するプラグインは使う価値があります。
AIプラグインが悪いと主張する人はいません。問題は、それで十分かどうかです。
プラグインにできないこと
ここが議論の核心です。プラグインの背後にあるAIモデルがどれほど洗練されていても、プラグインが達成できることには厳しい限界があります。
プラグインはエンジンレベルでシーンを操作できない
AIプラグインはテキストを生成します。GDScriptを書き、.tscnスニペットを生成したり、設定ファイルを作成したりします。しかし、ノードを作成したり、トランスフォームを設定したり、物理ボディを構成したり、実際のエンジンAPIを通じてシグナルを接続したりはしません。この違いは微妙ですが重要です。.tscnファイルを生成してエディターが正しくパースしてくれることを期待するのは、エンジン自身を通してadd_child()を呼ぶのと同じではありません。
プラグインがノードパスにエラーを含むシーンファイルを生成すると、壊れたシーンができあがります。エンジン自身がノードを作成すれば、定義上、パスは正しくなります。
プラグインは実行中のゲームを見ることができない
AIプラグインは静的ファイルで動作します。.gdスクリプトと.tscnシーンをテキストとして読み取ります。ライブのゲーム状態にはアクセスできません。
「キャラクターが壁をすり抜ける」と伝えた場合、プラグインはコードを読んで問題を推測します。衝突レイヤーを変更するか、キャラクターコントローラーのマージンを調整するよう提案するかもしれません。エンジンレベルで統合されたAIシステムなら、衝突レイヤーを直接検査し、特定のボディの物理設定を確認し、シェイプの範囲を調べて、問題が衝突レイヤーの欠落なのか、シェイプのサイズ不足なのか、物理ティックレートの問題なのかを特定できます。
コードの静的解析はいくつかのバグを捕らえます。ランタイムの把握は残りを捕らえます。
プラグインはエンジン内でアセットを生成できない
AIプラグインは外部APIを呼び出して画像や3Dモデルを生成できます。結果をダウンロードしてプロジェクトフォルダに配置できます。しかし、StandardMaterial3Dを作成したり、そのラフネスとメタリック値を設定したり、UVマッピングを設定したり、エンジン自身のシステムを通じてインポート設定を調整したりはできません。
「プロジェクトフォルダに.glbファイルがあります」と「マテリアル、衝突シェイプ、LOD設定が完全に構成され、すぐに使用可能なメッシュがあります」との間のギャップは大きいのです。前者は手動のセットアップを必要とします。後者はすぐに遊べる状態です。
プラグインは摩擦を増やす
各AIプラグインには独自のセットアッププロセスがあります。アドオンのインストール、APIキーの設定、モデルの選択、インターフェースの学習。アップデートはエンジンではなくプラグインのスケジュールで提供されます。認証トークンは期限切れになります。モデルのバージョンによって挙動が変わります。
AIは常に作業から一層離れたところにあります。あなたはプラグインと話し、プラグインはモデルと話し、モデルはテキストを生成し、プラグインはそれをディスクに書き込み、エンジンはそれを読み取ります。それぞれの層がコンテキストが失われる場所となります。
AIネイティブとは何か
Summer Engineでは、AIはアドオンではありません。エンジンとやり取りする方法そのものです。AIはエンジンエディターと同じアクセス権を持っています。エディターが使用するのと同じAPIを呼び出してシーンを作成します。テキストファイルを編集するのではなく、インスペクターを通じて物理を構成します。ファイルレベルではなくエンジンレベルで動作するため、RigidBody3DとCharacterBody3Dの違いを理解しています。
AIネイティブは、実際には3つのことを意味します。
AIはエンジンを迂回するのではなく、エンジンを通じて動作します。 AIがノードを作成するとき、エンジンのシーンツリーAPIを使用します。プロパティを設定するときは、インスペクターシステムを使用します。書式エラーや無効な参照を導入する可能性のある中間的なテキスト生成ステップはありません。
AIはエンジンが見るものを見ます。 実行中のシーンツリー、現在の物理状態、ロードされたリソースにアクセスできます。ファイルの内容からゲームを再構築するのではなく、実際の状態を読み取ります。
AIとエディターは同じツールです。 「エディターモード」と「AIモード」を切り替える必要はありません。会話と手動編集が共存します。AIによる変更は、あなた自身の編集と同じように、インスペクターとシーンツリーに即座に反映されます。
実用上の違い
抽象的なアーキテクチャの議論よりも、具体的な例の方が役に立ちます。実際にどのような違いがあるかを示します。
「プレイヤーが青い鍵を持っているときに開くドアを追加して。」
プラグインは、鍵の変数をチェックする_on_body_entered関数を持つGDScriptファイルを生成します。ドアノードの作成、配置、AnimationPlayerの追加、鍵アイテムの作成、インタラクションエリアの設定、シグナルの接続は、自分で行う必要があります。
Summer EngineはStaticBody3Dと衝突シェイプを持つドアノードを作成し、開閉アニメーションを持つAnimationPlayerを追加し、鍵を取得可能なArea3Dとして作成し、インタラクション検出を設定し、解錠ロジックを記述し、すべてを接続します。動作するドアが手に入ります。
「敵をもっと賢くして。」
プラグインはあなたの敵スクリプトを読み、ステートマシンの追加や追跡ロジックの改善を提案します。提案は良いかもしれませんが、実装は自分で行います。
Summer Engineは現在の振る舞いの実装を読み、敵がプレイヤーや環境とどのように相互作用するかを分析し、特定の弱点（敵が角で引っかかる、側面から攻めない、障害物の後ろでプレイヤーを見失う）を特定し、システムを直接修正します。
「ジャンプがふわふわした感じがする。」
プラグインはあなたのジャンプを体感できません。一般的なプラットフォーマーの設定に基づいて重力値を提案できるだけです。
Summer Engineは現在の重力、ジャンプ速度、落下乗数を読み取ります。それらをゲームタイプに対して知られている良好な値と比較します。パラメータを調整してすぐにテストできるようにし、あなたのフィードバックに基づいて反復します。
どちらのアプローチにも居場所がある
あなたが愛用しているGodotプロジェクトがあり、AIにコードを速く書く手助けをしてほしいなら、プラグインは堅実な選択肢です。既存のワークフローに馴染みます。エンジンを変更する必要もありません。Ziva、GDAI MCP、そして増えつつあるコミュニティツールは探求する価値があります。
しかし、エディター自身と同じレベルで動作しながら、AIをゲーム制作の一等市民にしたいなら、エンジンの内側に必要です。それがAIネイティブの意味であり、Summer Engineが提供するものです。
Summer EngineはGodot 4 互換なので、既存のプロジェクト、プラグイン、知識がそのまま引き継がれます。違いは、AIがもはや外から覗き込む存在ではない、ということです。
Godot互換によるAIゲーム開発について詳しく見る、またはSummer Engineをダウンロードしてご自身で試してみてください。