最近、Unreal Engine 5.5 で組んでいるインスタレーション作品の Blueprint と C++ の往復作業を Antigravity に任せるようになってから、検証サイクルが目に見えて短くなりました。私が取り組んでいるのは、来場者のいる空間でセンサー入力に応じて描画がリアルタイムに変わる展示作品で、実装の中心はゲームエンジン上のリアルタイム描画と、入力に対する振る舞いの設計です。表現そのものは自分の手で詰めますが、その土台となるコードの往復には、個人開発でアプリを作り続けてきた延長で Antigravity を組み込むようになりました。私自身、展示の現場で実際に動かす機材を相手にしながら、この分業のかたちを少しずつ調整してきました。
Antigravity 2.0 をエージェントとして導入してから、Unreal プロジェクトに対する操作の射程が一段広がりました。ただし、ゲームエンジン特有のアセット構造・Blueprint バイナリ・コンパイル時間の壁があり、純粋なウェブ開発と同じ感覚で投げると詰まります。私が実際の展示作品の制作で踏んだ失敗と、現時点で安定して回せている実装パターンを、エージェント側のプロンプト設計とプロジェクト構成の両面から書きます。
まず、Antigravity が Unreal プロジェクトで触れる範囲を正確に把握する
Antigravity は基本的にテキストファイルベースでプロジェクトを操作します。Unreal Engine のプロジェクトに含まれるファイルは、テキストで触れるものとバイナリのものに分かれており、エージェントに任せられる範囲はこの構造に縛られます。
触れる側に入るのは、.uproject ファイル（JSON）、Config/ 配下の .ini ファイル、Source/ 配下の C++ ソース（.h / .cpp / .Build.cs）、Plugins/ 内のメタデータ、Shaders/ 内のシェーダコード（USF / HLSL）、.gitignore などの管理ファイル群です。これらはエージェントが直接読み書きしてコミットできます。
触れない側に入るのは、.uasset と .umap（マップ）、Blueprint のバイナリ部分、テクスチャ・サウンド・モーションキャプチャ等のメディアアセットです。Antigravity から直接編集はできません。これらに対しては、Editor 内での操作を前提とした「指示書」を出させて、私がエディタで反映する分業になります。
この線引きを最初にプロジェクトルートの AGENT_SCOPE.md に書いておくと、エージェントが暴走して .uasset を書き換えようとする事故を防げます。私の運用では、.antigravityignore で .uasset と .umap を明示的に除外し、Antigravity に「これらは触らない、変更が必要なら指示書を _agent_instructions/ に出力する」と宣言させています。
# .antigravityignore — Unreal プロジェクト向け推奨設定 *.uasset *.umap Content/** Saved/ Intermediate/ DerivedDataCache/ Binaries/ *.pdb
# Antigravity が無視せず編集してよいテキスト資産 !Source/** !Config/** !Shaders/** !*.uproject !.gitignore !AGENT_SCOPE.md Content/ 全体を除外したうえで、Source/ Config/ Shaders/ を ! で復活させる構成です。バイナリアセットに触れさせない一方、コードと設定は自由に編集できる状態を維持できます。
Blueprint と C++ の使い分けをエージェント側に指示する
Unreal の作法として、ゲーム挙動の試作は Blueprint で素早く、安定したコアロジックは C++ で実装する、という二層構造が一般的です。Antigravity に作業を任せる場合、この使い分けをプロンプトで明示しないと、安易に Blueprint Function Library を呼び出す手抜き実装が混ざります。
私は、AGENT_SCOPE.md の中で次のような役割分担をエージェントに明文化しています。
新規アクター・新規コンポーネントの「骨格」は C++ で書き起こす。Blueprint からは C++ の関数を呼び出す形にします。一時的な数値調整・マテリアルパラメータの実験は Blueprint 側で行う想定で、C++ には UPROPERTY(EditAnywhere) を多めに張る。マルチプレイ同期や保存処理など、後から差し替えにくいロジックは必ず C++ で実装させる。
このルールを徹底するために、エージェントに新規クラスを生成させるときのプロンプトテンプレートを _agent_prompts/new_actor.md に置いています。
# 新規アクター生成プロンプト
役割: あなたは Unreal Engine 5.5 プロジェクトの C++ 実装担当エージェントです。
## 必須ルール 1. アクターは C++ クラスとして `Source/<ProjectName>/Public/` と `Private/` に作成する 2. 公開すべきプロパティには必ず `UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Installation")` を付与 3. Blueprint から呼び出される関数には `UFUNCTION(BlueprintCallable)` を付与 4. ヘッダのインクルードは前方宣言を優先し、 `.cpp` 側で `#include` する 5. 新規 `.h` / `.cpp` を追加した後、 `<ProjectName>.Build.cs` の依存モジュールに追加が必要かを必ず確認する
## 出力 - 生成したファイルの diff - Editor 側で必要な操作（ブループリント派生クラスの作成、コンポーネント配置等）の手順書 このテンプレートを通すと、エージェントが C++ で骨格を作って、Editor 側でやるべき操作を _agent_instructions/ に手順書として落とす、という流れが安定します。私の今期の作品では、新規アクターを 12 種類追加しましたが、すべてこのテンプレート経由で進めて、後から「Blueprint と C++ の責務が混ざっている」と作り直したケースはゼロでした。
コンパイル時間とエージェントの再試行ループを切り離す
Unreal の C++ ビルドは大型プロジェクトだと 1 分以上かかります。Antigravity に「ビルドして動作確認しろ」と命じると、ビルドの待ち時間ごと再試行ループに巻き込まれて、エージェントのクレジットが急速に消費されます。
私は次の運用に落ち着きました。Antigravity 側にはコンパイルを命じず、コードの diff だけを生成させて停止させます。私が手動でエディタの Live Coding か Build.bat Development Win64 を回し、ビルド結果をエージェントに「成功した」「Foo.cpp:42 で error C2065」と短いテキストで返します。
この「人間を間に挟む」運用は、一見すると効率が悪く見えますが、エージェントのトークン消費が大きく下がります。私の計測では、フルコンパイルを含めてエージェントに任せていた頃と比べて、AgentKit のトークン使用量が 41% 減りました。クレジットが月 25 ドル枠で運用しているなら、これは無視できない差です。
# 私が運用しているローカルビルドスクリプト（macOS の場合） # Antigravity は呼ばない。手元で実行してエラー文だけエージェントに返す "/Users/Shared/Epic Games/UE_5.5/Engine/Build/BatchFiles/Mac/Build.sh" \ MyInstallationGame Mac Development \ "${ PWD }/MyInstallationGame.uproject" -waitmutex 2>&1 | \ tee /tmp/ue_build.log | tail -40 ビルドログの最後 40 行だけを切り出してエージェントに渡すのが要点です。フルログを渡すとコンテキストを圧迫しますし、警告に引きずられて修正が暴走します。エラーが起きた箇所だけを抽出する grep -E 'error C[0-9]+' のような前処理を挟む運用も有効でした。
アート展示の現場で再現性を担保するプロジェクト構成
インスタレーション作品は、展示会場の現場で初めて動かす機材構成が多く、ローカルでは動いても会場の Windows マシンで起動しないというトラブルが起きやすい領域です。Antigravity 経由でコードを編集するようになってから、再現性確保のために守っているルールがいくつかあります。
Git の運用は、本番ブランチ（展示会場で動かす版）と試作ブランチを必ず分けています。Antigravity に作業を依頼する時は、必ず試作ブランチを切らせてから着手させ、本番ブランチへのマージは私が手動で行います。これは、エージェントの判断ミスで本番ブランチを直接更新してしまうと、リハーサル前夜にビルドが通らなくなった経験から来ています。本番運用と試作の境界を意識的に設けることが、現場での即興対処を支えてくれます。
Config/DefaultEngine.ini などの設定ファイルも、本番用と検証用を分けて、起動引数で切り替える構成にしています。Antigravity に依頼するときも、「設定変更は DefaultEngine.ini ではなく _Production.ini 側に書け」と AGENT_SCOPE.md で明示してあります。
; Config/_Production.ini — 展示会場用の設定オーバーレイ [/Script/Engine.GameUserSettings] ResolutionSizeX =3840 ResolutionSizeY =2160 FullscreenMode =0 ; 0 = Fullscreen, 1 = Windowed Fullscreen, 2 = Windowed
[/Script/Engine.RendererSettings] r.VSync =1 r.FrameRateLimit =60 エージェントに「展示会場での 4K / 60fps を維持するための設定を提案して」と頼むと、_Production.ini だけを書き換える形で diff が返ってきます。検証環境を壊さずに本番設定を更新できるので、リハーサルから本番までの差分管理が楽になりました。
センサー入力との接続は手動で確認するレイヤを残す
インスタレーション作品はセンサー（深度カメラ、人感センサ、Arduino 経由のフィジカル入力）からの値で表現が変わります。Antigravity にこの種のコードを書かせる時に注意したいのは、エージェントは実物のセンサー出力を見ていないので、想定値の範囲を間違えやすい点です。
私の運用では、センサー読み取りクラスは C++ で骨格だけ書き、実値の範囲は Blueprint からの注入で確定させる構造にしています。Antigravity には「センサー値の正規化処理は書くな、Blueprint 側で SetSensorRange(min, max) を呼ぶ前提でコードを書け」と AGENT_SCOPE.md で指示しています。
// Source/Public/SensorInputComponent.h UCLASS () class MYINSTALLATION_API USensorInputComponent : public UActorComponent { GENERATED_BODY () public: UFUNCTION (BlueprintCallable, Category = "Installation|Sensor" ) void SetSensorRange ( float InMin , float InMax );
UFUNCTION ( BlueprintCallable , Category = "Installation|Sensor" ) float GetNormalizedValue () const ;
protected: UPROPERTY () float MinValue = 0.0 f ;
UPROPERTY () float MaxValue = 1.0 f ;
UPROPERTY () float RawValue = 0.0 f ; }; センサー固有の値域を Blueprint 側に逃がしておくと、現場で測定し直して数値を入れ替える作業がエディタで完結します。Antigravity に再依頼する必要がないので、現場での即興対応がぐっと楽になります。
何を諦め、何を任せるかの線引き
5 ヶ月ほど運用してきた感触として、Antigravity に任せて成果が出るのは「C++ の骨格生成」「Build.cs の依存追加」「シェーダの試行錯誤」「Config ファイルの整理」「Git ブランチ運用の補助」の 5 領域です。逆に、Blueprint の細部・テクスチャ調整・アクター配置・カメラワークは、エディタで自分の目で確かめながら詰めた方が早く、エージェントに渡しても付加価値が出ません。
この線引きが見えてからは、Antigravity に対するプロンプトが短くなりました。「やってほしいこと」が絞られているので、エージェントの推測の幅も小さくなり、的外れな提案がほぼ消えます。逆に、最初の数週間は「とりあえず全部任せたい」という気持ちで依頼を出していたため、エディタ側で結局やり直す作業が頻発しました。
展示作品の制作という、納期と表現の両方に厳しい現場では、エージェントに何を任せ、何を自分の手で詰めるかの判断そのものが作品の輪郭を決めます。Antigravity は強力な相棒ですが、現場の感覚と分業を設計するのは依然として人間の役割だと感じています。
次に試すこと
Unreal Engine × Antigravity のワークフローを始めるなら、まずプロジェクトルートに .antigravityignore と AGENT_SCOPE.md を置く 30 分の作業から始めるのが効きます。バイナリアセットを保護した上で、C++ と Config だけ任せる構成にすると、初日からエージェントの暴走を防げます。コンパイル待ちをエージェントから切り離す運用は、トークン消費を抑える効果が大きく、特にクレジット制プランで動いている方には強くお勧めします。個人的には、この分離だけでひと月あたり 10 ドル以上の節約になりました。お読みいただきありがとうございました。