エンジンネイティブAI: Summerのエージェントハーネスが本物のゲームを作る方法（プロトタイプだけではない）

「AIエージェントはプロトタイプには素晴らしいが、本格的なプロジェクトでは崩れる」。この批判は正しいです、ただし注釈付きで。エージェントがテキストファイルしか見ていないときには正しい。エージェントがエンジンそのものを操作した瞬間、失敗モードの形が変わり、扱えるプロジェクトの規模もそれに合わせて変わります。

この記事はその区別についてです。エンジンネイティブなAIエージェントハーネスとは実際に何なのか、なぜ汎用AIツールがゲーム案件で特に壁にぶつかるのか、Summerが今どこにいるのか、そしてまだ出荷すべきものについて私たちはどこで正直に書いているか。

なぜ汎用AIはゲーム案件で止まるのか

ゲーム案件は「ソースファイルがプログラムを記述する」という前提を壊します。記述していません。動作するGodotプロジェクトは複数の異なる状態システムの和集合であり、その状態の大半はAIツールが通常見るファイルの外に存在します。

午後に再現できる具体的な失敗モード。

• 多数のシーンにまたがる状態。 中規模のプロジェクトは50以上のpacked sceneを持ち、それらがPackedSceneのexport、autoload、グループルックアップを通して互いを参照します。テキストのみのエージェントは一度に一つのシーンしか読まず、ビルドに実際入るのはどのプレイヤーコントローラーなのかを見失います。
• sub-resourceと.tresの落とし穴。 .tscn内のインラインsub_resourceブロックは、独立した.tresと同じやり方では変更できません。よくある静かな失敗は、インラインsub-resourceに対してSetResourcePropertyを呼び、何も適用されないのを眺めることです。汎用エージェントはリソースがインラインか外部かを見分けられないため、これに何度も引っかかります。
• アセットのインポートパイプライン。 .glbや.pngは.importサイドカーなしでは無意味です。マテリアルスロット、メッシュLOD、コリジョン形状、再インポート設定はそこに存在します。ファイルをres://assets/に置いて立ち去るAIは、実のところ何もインポートしていません。
• Godot固有のイディオム。 signal、autoload、group、物理レイヤー、@onreadyの順序、@exportのデフォルト、_readyと_enter_treeの違い。深い秘密ではありませんが、一般的な学習データでは過小評価されており、微妙に間違いやすい点です。
• GDScriptのシグネチャの癖。 メソッドオーバーライド、型付き配列、ポイントリリース間のObject.connect構文の違い。Godot 4.3でコンパイルが通るコードが4.6では通らないかもしれません。
• エディタの状態はファイルの状態と同じくらい重要。 シーンが開いているかどうか、インスペクターが正しいノードを表示しているかどうか、2Dビューにいるか3Dビューにいるか。エディタはファイルを受動的に眺めるビューワーではありません。プログラムの一部です。

チャットウィンドウ型のエージェントはこのどれも持っていません。見せられたファイルのワーキングセットと、そこから推論できるものだけです。一つのスクリプトには十分です。50シーンのプロジェクトには通用しません。そこでは「なぜこれが壊れるのか」の答えが3つのファイルと、誰も貼り付けていないシグナル接続に分かれて存在しているからです。

エンジンネイティブ vs. チャットウィンドウ

Summerのハーネスは別の形で作られています。エージェントはファイルを読むだけではありません。localhost:6550で動作中のSummer Engineインスタンスと話し、構造化されたtool callを通じてそのインスタンスを操作します。

現在のtool surfaceは37個のtoolです。代表的なものをいくつか。

• summer_get_scene_treeは、現在開いているシーンのライブなノードツリーを型、パス、主要プロパティ付きで返します。
• summer_inspect_nodeは、シリアライズされていないランタイム状態を含むノードのプロパティ一式を読みます。
• summer_add_nodeとsummer_remove_nodeはシーンを直接変更します。
• summer_set_propはノードパスとキーでプロパティを設定します。エンジンは実際のプロパティレジストリと照合するため、タイポは壊れた.tscnを書き出さずに即座に失敗します。
• summer_create_sceneはルート型を持つ新しいシーンファイルを作成し、エンジン自身のシリアライザで保存するので、インポートメタデータは正しくなります。
• summer_playとsummer_stopはゲームを実行します。
• summer_get_debugger_errorsは直前の実行のエラーログを読みます。
• summer_generate_3d、summer_generate_audio、summer_import_assetは、生のファイルドロップではなくエンジンのインポートシステムを通じてアセットパイプラインをカバーします。

具体的なワークフロー。プロンプトを「プレイヤーのHPを追跡し、ダメージを受けたら赤く点滅するヘルスバーを追加して」とします。

1. エージェントはsummer_get_scene_treeを呼び、公開されたhealthプロパティを持つPlayerノードがあることを確認します。
2. このコードベースにおけるスタックされたCanvasLayerオーバーレイの規約をエンコードしたui-health-barskillをロードします。
3. CanvasLayerをルートに持つ新しいHealthBar.tscnについてsummer_create_sceneを呼びます。
4. summer_add_nodeを使ってフラッシュ効果用のProgressBarとColorRectを追加します。
5. たった今書いたGDScriptファイルを指すscriptプロパティに対し、summer_set_propでスクリプトを書き込みます。
6. プレイヤーのhealth_changedシグナルをバーの更新メソッドに接続します。
7. summer_playを呼び、エンジンの実行を見守り、summer_get_debugger_errorsを読みます。シグナル名が間違っていれば、同じターン内でエラーを見て修正します。

それぞれのステップは、チャットウィンドウのフローでは説明の段落とコピペの繰り返しになります。ここではプロンプト一つとtool loopひとつです。さらに重要なのは、各ステップがエージェントの願う通りに現実と一致しているはずのファイルではなく、ライブのエンジンに対して検証される点です。

規律ガイドとしてのskill

tool surfaceは「エージェントは何ができるか」に答えます。skillライブラリは「エージェントはどうすれば、毎回うまくやれるか」に答えます。

SummerのCLIはsummer-engine@1.3.0で20カテゴリにわたる62のskillを提供しており、すべてMITライセンスです。カテゴリは次のとおりです。2d-assets、3d-assets、ai-and-npcs、animation、asset-pipeline、audio、character-controllers、debugging、deployment、gameplay-mechanics、input-and-controls、level-design、multiplayer-and-networking、performance、physics、post-processing、rendering-and-lighting、scene-and-project、scripting-patterns、shaders。

各skillはYAMLフロントマターヘッダー付きのMarkdownファイルです。ヘッダーは名前、トリガーの記述、ロード順を持ちます。本文は規律ガイドです。skillをいつ適用するか、正しい出力の形は何か、避けるべき失敗モードは何か、そして少数の作り込まれた例です。代表的なskillをいくつか。

• character-controllers/third-person-3dは、CharacterBody3Dのセットアップ、入力マップキー、coyote-timeとjump-bufferの猶予、そしてこのコードベースがすでに使っているカメラリグパターンをカバーします。
• asset-pipeline/standalone-tres-materialsは、インラインsub-resourceよりも独立した.tresマテリアルのパターンを強制します。実際に適用されるSetPropの呼び出し形と、避けるべき静かな失敗の罠を含みます。
• multiplayer-and-networking/rpc-channelsは、reliable対unreliableのチャンネル選択、順序保証、後から参加するプレイヤーへの対応を説明します。

skillはjust in timeでロードされます。エージェントがターンの意図を認識すると、対応するskillをコンテキストに引き込みます。ライブラリ全体が一度にプロンプトに乗ることはなく、これが長期プロジェクトを手頃かつ集中した状態に保ちます。プロジェクトが大きくなるほどこれが効いてきます。ジャムゲームは5つのskillしか呼ばないかもしれません。50シーンのアクションゲームは寿命のうちにライブラリの半分に触れますが、単一ターンでその全てに触れることはありません。

skillはAnthropicのオープンなAgent Skills標準に従い、agentskills.ioに文書化されています。フォーマットはポータブルです。Summerのskillライブラリは一つの実装です。誰でもskillを書き、配布し、あるいは私たちのものを自分のエンジン向けにフォークできます。完全なオープンソースCLIはgithub.com/SummerEngine/summerにあります。

私たちがギャップについて正直に書く場所

二つのことをはっきり分けて考える必要があります。実質の面では、私たちのskillライブラリとtool surfaceはCursorとClaude CodeがIDE側で持ち込むものに匹敵します。ハーネスのアーキテクチャ面では、より深いリファクタリングは仕様化され、部分的に出荷されていますが、完了はしていません。私たちは獲得していないパリティを主張するのではなく、文書化されたギャップを埋めています。

私たちが積極的に埋めているギャップは、計画フォルダにある9つのspecから成るリファクタリングから来ています。

• 長時間のターンが中間状態を失わないように、tool resultをディスクに永続化する。
• 単一のうるさいtoolがコンテキストウィンドウを吹き飛ばさないように、tool単位のmaxResultSizeCharsキャップ。
• エージェントが1ループ内で同じシーンを3回読み直さないように、ターン内のread dedup。
• ENOENT時のあいまいなパス提案。惜しいファイル名が硬いfailではなく役立つ「もしかして」を得られるように。

これらのいくつかはすでに出荷済みです。残りは進行中です。

IDE側にはない、エンジンパートナーを必要とするためのSummer固有の要素。

• string replaceに対するエンジン側のSHAゲート。 すべての編集は、エージェントが編集していると思っているファイルのハッシュを携えます。ライブのファイルが動いていれば、編集は適用を拒否し、エージェントは読み直します。ユーザーがターンの合間に行った作業を静かに上書きすることはありません。
• .summer/plans/にファイル永続化されたプラン。 マルチターンのプランは会話に保持されるだけでなくディスクに書かれます。ユーザーは読めます。エージェントはセッションをまたいで再開できます。
• SummerGitによるターン単位のrewind。 各ターンはスナップショットです。1ターン戻せば、トラックされていないエンジン状態も含めてプロジェクト状態が正確に戻ります。これがエージェントの積極的な行動を許容可能にする安全網です。
• BullMQとRailwayによるエキスパートキュー。 3D生成、リターゲット、シーン全体のアセットパスなど長時間の操作は、ユーザーのマシンではなくワーカーキューで動きます。デスクトップは結果が用意でき次第受け取ります。

私たちは「実質では匹敵、アーキテクチャではギャップを埋め中、文書化された独自の優位性あり」と言い続けます。これが正確な一文です。

大きなプロジェクトにとってこれが意味すること

この全ての要点は、AIがプロトタイプの壁を越えても役に立ち続けることです。

小さなプロジェクトはずさんなエージェントに耐えます。50シーンのゲームは耐えません。ハーネスは次を提供しなければなりません。

• 監査可能な出力。 すべてのtool callはログに残ります。発火したすべてのskillはトレースに残ります。ターンをリプレイして、エージェントが何をしたか、なぜそうしたかを正確に確認できます。
• 本物のGodotのシーンとスクリプト。 提案だけのチャットウィンドウでも、擬似コードでも、システムを記述したMarkdownファイルでもありません。シーンを開いてください。ノードがそこにあります。
• プランの永続化。 インベントリシステムを作ったプランはまだディスク上にあります。来週それを引き継ぐエージェントは、先週の火曜日のぼんやりした記憶ではなくプランを読みます。
• エラーリカバリ。 ゲームがランタイムでエラーを投げたら、エージェントはそれを読みます。シグナル接続が間違っていれば、エージェントは直します。プロパティの型が一致しなければ、エンジンは設定を拒否し、エージェントは引き下がります。

これがシーン12で倒れるのではなく、シーン51でもAIワークフローを出荷し続ける方法です。ハーネス、skill、エンジンブリッジは、同じ問いに対する同じ答えです。プロジェクトがチャットウィンドウに収まる大きさを超えたとき、AIはどうすれば役に立ち続けるのか。

試してみる

同じエンジン、同じGodot 4互換、3つの入り口。

• Summer Engineをダウンロードして、既存の.godotプロジェクトを開いてください。エージェントは初回起動時から接続されています。
• github.com/SummerEngine/summerのオープンソースCLIとMCPを使って、skillライブラリとtool surfaceを既存のIDEに持ち込んでください。
• 周辺コンテキストとしてMCPページ、Godot AIエージェントページ、より広いGodot AI連携ページもどうぞ。

今週の関連記事。Godot AIスイートのまとめとGodot AIプラグインガイドはより広いツール環境をカバーし、テンプレートページはハーネスが調整対象とするスタータープロジェクトを示します。

売り文句は短いです。インディーもプロもスタジオも使う同じエンジン。AIが各レイヤーをそれぞれ別の形で加速する。あなたと共にスケールし、ゼロからやり直すことはありません。

よくある質問

エンジンネイティブAIエージェントとは何ですか？

エンジンネイティブAIエージェントとは、テキストファイルを読み書きするだけではなく、構造化されたtool callを通じて動作中のゲームエンジンインスタンスを操作するエージェントです。ライブのscene treeを読み、ノードのプロパティを設定し、ゲームを実行し、エラーを読み戻します。Summer Engineではエージェントはポート6550でローカルエンジンと話します。

なぜ汎用AIエージェントは大きなゲームプロジェクトで失敗するのですか？

ゲームプロジェクトはソースファイルの外に状態を抱えます。scene tree、sub-resource、シグナル接続、autoload、packed scene、アセットインポートのサイドカー、エディタ設定です。テキストのみのエージェントはその大半を見られないので、推測し、バインディングを壊し、コンパイルは通るが動かないスクリプトを書きます。

Summerのエージェントハーネスはいくつのskillを含みますか？

20カテゴリにわたる62のskillで、オープンソースのsummer-engine CLIバージョン1.3.0に同梱されています。カテゴリはキャラクターコントローラーやアニメーションから、シェーダー、マルチプレイヤー、ポストプロセッシングまでカバーします。skillは一度にすべてではなく、ユーザーの意図に基づいてjust in timeでロードされます。

この文脈におけるskillとは何ですか？

skillは、特定の種類のタスクをどう扱うかをエージェントに伝えるYAMLフロントマター付きのMarkdownの規律ガイドです。Anthropicのオープンなagentskills.ioに文書化されたAgent Skills標準に従います。skillはバージョン管理され、監査可能で、すべてのプロンプトを膨らませることなくエキスパートの実践をループに持ち込みます。

CursorやClaude Codeとはどう違いますか？

実質の面では、skillライブラリとtool surfaceは匹敵します。Summerが独自なのはエンジンネイティブなブリッジングです。エージェントはファイルだけを操作するのではなく、動作中のGodot互換エンジンを操作します。私たちはまたハーネスアーキテクチャの文書化された数件のギャップも埋めており、リファクタリングは仕様化され部分的に出荷されています。

エージェントは自分だけで完全なゲームを作れますか？

いいえ。エージェントはシーン、スクリプト、アセット、システムを作ります。人間がデザインの決定を下し、フィールを調整し、何が楽しいかを判断します。ハーネスは機械的な層を圧縮するために存在し、それによって人間はクリエイティブな層に留まれます。

エージェントはオープンソースですか？

CLIとskillライブラリはgithub.com/SummerEngine/summerでMITライセンスのオープンソースです。エンジンランタイムは無料でダウンロードできます。AIの使用料は原価に重めの生成への小さなマークアップを加えた金額で請求されます。

エージェントがミスをするとどうなりますか？

プランは.summer/plans/フォルダに永続化されます。SummerGitがターン単位のスナップショットを取るため、単一のターンを巻き戻すことができます。エンジンはSHAゲートで編集を検証するので、古いエージェント状態が実際には読んでいないファイルを上書きすることはできません。エラーはデバッガーtool経由で戻り、エージェントは次のターンで回復します。

既存のGodot 4プロジェクトで動きますか？

はい。Summer EngineはGodot 4互換です。Summerで.godotプロジェクトを開けば、エージェントはすでに持っている同じシーン、スクリプト、リソースを読みます。エディタはエージェントと並行して使い続けられます。