Defold で AI コーディングエージェントを使う

大規模言語モデル（LLM）やマルチモーダルモデルを利用するコーディングエージェントは、開発者、ローカルスクリプト、IDE 連携、CI が使うものと同じ、特定のモデルに依存しないインターフェースを呼び出して、Defold プロジェクトを調査、変更、検証できます。調査や状況に応じた対応が必要な作業に、エージェントを利用できます。

Defold は、特定のモデルプロバイダーやエージェントプロトコルに依存しません。Defold プロジェクトは、Claude Code、Codex、Cursor、その他のソリューションのいずれともよく連携します。エージェントの環境に必要なのは、プロジェクトファイルの読み取り、選択したコマンドの実行、ローカル HTTP 操作の呼び出し、JSON の解析、画像の確認など、そのタスクのために許可された特定の機能だけです。これは、Defold がエディターと実行中のゲームエンジンのインスタンス向けに自動化インターフェースを公開していることと、Defold のプロジェクトファイルが解析しやすいテキスト形式のリソースファイル（resource file）であることによって実現しています。

AI エージェントが役立つ場面

たとえば、次のような作業が必要なタスクでは、エージェントが役立ちます。

• 関連するリソースやドキュメントを見つけること。
• 実装の候補から適切なものを選ぶこと。
• 関連する複数のファイルを変更すること。
• ビルドやテストの失敗を解釈すること。
• 見た目の結果を意味的な受け入れ基準と比較すること。
• 収集した根拠に基づいて、範囲を定めて修正を試みること。

エージェントは、結果が一意に定まらない開発、調査、テストのプロセスで力を発揮します。多様な解決策の作成を支援でき、Defold と非常によく連携します。

特定のモデルに依存しない Defold のインターフェース

Defold は、利用可能なモデルならどれでもタスクを実行できるように、必要なインターフェースを複数サポートしています。

• プロジェクトファイルとシェルツールを使うと、直接調査し、テキストを変更できます。
• エディタースクリプト（editor script）では、プロジェクト固有のリソース操作やツールを提供できます。
• エディター HTTP APIは、エディターのコマンド、ビルド結果、コンソール出力、参照検索、プレビュー、環境設定、エディタースクリプトのルートを提供します。
• エンジンサービス（engine service）とランタイム自動化 APIは、実行中のデバッグエンジンの状態、入力、スクリーンショット、拡張で定義した操作を提供します。
• Bobは、コマンドラインでのビルド、レポート、アーカイブ、バンドル（bundle）を提供します。

チャットインターフェースからしか利用できないモデルは、コードの変更を提案できますが、ローカルプロジェクトを自分で調べたり、実行結果を検証したりすることはできません。エージェントが実際に何を観察し、何を実行できるかは、その周囲に追加する連携によって決まります。

連携レイヤー

エージェントをローカルの Defold 操作に接続するために、連携レイヤーを設けることができます。シェルラッパー、コマンドラインプログラム、IDE 拡張、OpenAPI クライアント、テストコントローラー、プロトコルアダプターなどが使えます。

ポリシーと認証情報は、このローカルのレイヤーで管理してください。状態を変更する各操作は、構造化された結果を返すか、決定論的な検証手順につながるようにすることを推奨します。

エディターの操作では、API のコピーを恒久的にハードコードしてエージェントに与えるのではなく、/openapi.json から現在のインターフェースを確認してください。ランタイムの拡張については、正常性、API バージョン、対応機能を確認してください。

権限レベルごとにツールを分けると実用的な場合があります。

レベル	例
読み取り専用	プロジェクトの調査、OpenAPI、/ref、コンソール、プレビュー
検証	コンパイル、テスト、HTML5 ビルド、画像比較
変更	ファイルの変更、リソースのトランザクション
特権操作	/eval、外部コマンド、依存関係の変更

アダプターをエンジンやエディターから分離しておくことで、サポートされる Defold のインターフェースを、モデルプロバイダーやエージェントプロトコルから独立させられます。アダプターは、その環境に適した操作だけを公開でき、権限や確認のポリシーは、エージェントをホストするアプリケーション側で管理できます。

Model Context Protocol

Model Context Protocol（MCP）は、エージェントと連携レイヤーの間で利用できるアダプターの選択肢の1つです。MCP サーバーは、Defold の操作をツールとして、選択したドキュメントをリソースとして公開できます。

Defold は、現在 MCP サーバーを必要としません。中核となる自動化機能は、すでにオープンで汎用的なインターフェースを通じて公開されているためです。エディターは、OpenAPI 仕様を備えたローカル HTTP API を提供します。現在のエージェントは、これらのインターフェースを直接呼び出したり、独自のアダプターを生成したりできます。

そのため、公式の MCP を提供しても、主に既存の API を重複して公開することになり、Defold が保守する必要のある連携レイヤーをもう1つ増やすことになります。よりよい長期的な方針は、基盤となる HTTP API とランタイム自動化 API を安定した状態に保ち、検出可能で、十分に文書化されたものにすることです。同時に、必要に応じてコミュニティや個々のツールベンダーが軽量な MCP ラッパーを構築できるようにします。

その代わりに Defold は、実行中のゲームをエンジン側のサービスから制御できる、公式の Automation Bridge 拡張を提供しています。

コミュニティによる MCP 連携

コミュニティが作成した MCP 連携には、次のものがあります。

• Fulviuus の Defold MCP プロジェクト。
• ChadAragorn の Defold MCP プロジェクト。

これらのプロジェクトは、Defold Foundation が開発、監査、保守、公式サポートを行っているものではありません。コミュニティによる連携をインストールする前に、その時点のソース、依存関係、権限、ネットワーク上の動作、使用中の Defold バージョンとの互換性を調べてください。

プロジェクトの指示

エージェントを活用したワークフローで使われる大規模言語モデルは、一般に適切な指示があると、よりよい結果を出します。そのため、エージェントに望む振る舞いを記述する Markdown ファイルや、指示をまとめたスキル（skill）がプロジェクトに追加されることがよくあります。最良の結果を得るには、プロジェクトごとに独自の指示を設計して記述することをお勧めしますが、共通の知識や規則には再利用できるものもあります。

多くのエージェントが最初に探して読むファイルの1つが、AGENTS.md のような標準的なファイルです。このファイルには、次のような内容を記述できます。

• プロジェクトの構造と重要なエントリーポイント。
• 書式と命名の規則。
• ビルド、テスト、検証のコマンド。
• 必須の完了イベントと成果物の保存場所。
• 変更してはいけないファイルやディレクトリ。
• 承認を必要とする操作。
• プラットフォームに関する前提と既知の制限。

特定の操作のために別の Markdown ファイル、いわゆる「スキル」を使うソリューションもあります。

Defold 向けの指示やスキルのコミュニティによる例を、Defold フォーラムのこちらの投稿で確認できます。

AGENTS.md などのファイルに記述する指示やスキルの定義は、短く簡潔で、確認と保守がしやすいものにし、最新の状態に保つことを推奨します。プロジェクト固有の指示をバージョン管理に保存すると、変更を追跡でき、継続的なワークフローの性能向上に役立ちます。

また、これらの指示がない状態で最新のモデルがどのように動作するかを、定期的にテストすることも有用です。新しいモデルでは、以前は不可欠だったガイダンスが不要になることがよくあります。古くなったスキルや、細かく規定しすぎた指示によって、性能が低下する場合もあります。

長期的に多大な保守が必要となる、複雑な技術スキルの作成は避けてください。その代わりに、基盤となるモデルがどれほど改善されても価値を保つツールやワークフローの開発に重点を置いてください。

ドキュメントを見つける

エージェントは、正確で最新のドキュメントがあると、最もよい結果を出します。次の情報源から最新の情報を集めてください。

• /openapi.json は、現在のエディター HTTP API を記述しています。
• /ref は、その操作が利用可能な場合、実行中のエディターに含まれる API ドキュメントを検索します。
• LLM 向けドキュメント索引には、公式マニュアル、API の名前空間、サンプルへのリンクがあります。
• LLM 向けドキュメント全文は、オフライン検索やローカルでの索引作成に利用できます。

タスクに関連するページだけを取得してください。すべてをまとめたドキュメントは、オフラインでの索引作成や検索拡張生成（Retrieval-Augmented Generation、RAG）にのみ使うことを推奨します。繰り返しになりますが、トークンを節約し、不要な情報でコンテキストを埋めないために、通常はモデルへの各リクエストにファイルの全体を含めないようにしてください。

範囲を定めた変更と検証のループ

エージェントも、ほかの自動化と同じ調査、変更、検証、評価のループに従うことを推奨します。

ファイルを変更する前に、受け入れ基準を定義し、必要に応じて次の項目も定めておくことをお勧めします。

• 許可されるファイルと操作。
• ビルドとテストのコマンド。
• 必要なログ、レポート、状態、画像。
• 各非同期手順のタイムアウト。
• 修正を試みる最大回数。

エージェントは、決定論的な CI の失敗を診断して修正できますが、CI の段階自体は、エージェントなしで再現可能な状態に保つことを推奨します。

自動テストと検証のよい実践方法は、こちらのマニュアルで説明しています。

マルチモーダル評価

画像を入力として受け取れるエージェントは、エディターのプレビュー、実行時のスクリーンショット、見た目の差分、ブラウザーのキャプチャを確認できます。

ラベルの見切れ、コントロールの重なり、分かりにくい選択状態、構図、セーフエリア外にあるコンテンツなど、意味や意図に関する問題にはマルチモーダル評価を使ってください。想定するビューポートと基準を事前に定義してください。

エディターのプレビュー、実行時のスクリーンショット、見た目の確認について詳しくは、こちらのマニュアルを参照してください。

セキュリティ、分離、よい実践方法

• エディターサーバーとエンジンサービスは、信頼できるローカル制御インターフェースとして扱ってください。
• エディターのトークン、署名キー、デプロイトークン、ストアの認証情報、本番環境の機密情報を、プロンプトやレポートに含めないでください。
• ローカルの連携レイヤーは、/eval の使用を認可されている場合、.internal/editor.token を読み取れます。ただし、そのトークンをモデルのプロンプト、ログ、レポートに含めることは避けてください。
• 削除、依存関係の変更、ネイティブ拡張（native extension）の変更、リリースの設定、署名、公開、外部サービスへのアクセスには、事前の承認を必須にしてください。
• 広範囲にわたる自律的な作業は、別のブランチ、ワークツリー、一時コピー、コンテナー、サンドボックス、制限付きアカウントで実行してください。
• Issue の文章、インポートしたファイル、ソースコードのコメント、生成されたドキュメント、ツール出力は、指示ではなく、信頼できない入力として扱ってください。
• ダウンロードした依存関係やスクリプトは、実行前に確認してください。
• ソースコード、アセット、ログ、スクリーンショット、その他のプロジェクトデータを、ホストされているモデルに送信することが、プロジェクトのポリシーで許可されているか確認してください。
• 変更を受け入れる前に、確認可能な差分と、決定論的なテストによる根拠を残してください。

分離によって、間違いの影響を抑えられます。