ある夜、UE5のキャラクター挙動が想定と違っていて、AntigravityのチャットにBlueprintファイル（BP_PlayerCharacter.uasset）をドラッグして「このBlueprintのジャンプ処理を読んで」とお願いしたところ、返ってきたのは「このファイルはバイナリ形式で、内容を読み取れません」という素っ気ない返事でした。当然といえば当然なのですが、初めてUE5プロジェクトでAntigravityを使い始めたときの私は、半日その現実を受け入れられませんでした。
個人開発者の廣川政樹です。Unityに比べてUE5のAI支援情報は驚くほど少なく、Blueprintを軸にプロトタイプを回している人ほど「AI IDEは結局C++専用なのではないか」と感じやすいと思います。けれども、ここ数か月インディーゲームのプロトタイプを2本回す中で、Antigravityの位置取りが少しずつ見えてきました。ここではBlueprintを直接読めないという制約を踏まえた上で、私が実プロジェクトで採用しているワークフローを共有します。
なぜAntigravityはBlueprintを直接読めないのか
UE5のBlueprintアセット（.uasset）は、Unreal Editorが内部で利用する独自のバイナリシリアライズ形式です。テキストではなくノードグラフのバイト列なので、AntigravityのようなコードIDEから見ると git diff も差分が「Binary files differ」としか表示されません。
つまりAIが読めないのは設計上の必然で、Antigravityに限らずCursorでもCopilotでも同じです。ローカルのGemma 4で頑張っても変わりません。「Blueprintをそのままチャットに貼って質問する」という発想は、まず手放したほうが早いと感じています。
ただし、これはAIがUE5開発で役に立たないという意味ではありません。Blueprintというビジュアル層の 下にあるC++層・周辺Pythonツール・ビルド構成 こそ、Antigravityが最も得意な領域だからです。
それでもAntigravityがUE5開発で頼れる4つの場面
私の手元では、Antigravityは次の4つの場面で確実に時間を生み出してくれています。
1. Blueprint Function Library を C++ で書く
Blueprintから呼び出す共通関数群（UBlueprintFunctionLibrary 継承クラス）は、AntigravityにC++で書かせると明確に速いです。Blueprint側はノードを置くだけになるので、Blueprintを汚さずに複雑なロジックをまとめられます。
// Source/MyGame/Public/MathHelpers.h
// Blueprintから呼び出せる「角度を0-360に正規化する」ユーティリティ
#pragma once
#include "CoreMinimal.h"
#include "Kismet/BlueprintFunctionLibrary.h"
#include "MathHelpers.generated.h"
UCLASS()
class MYGAME_API UMathHelpers : public UBlueprintFunctionLibrary
{
GENERATED_BODY()
public:
UFUNCTION(BlueprintPure, Category="Math|Angle", meta=(DisplayName="Normalize Angle (0-360)"))
static float NormalizeAngle360(float InAngle);
};BlueprintPure を付けるかどうか、meta=(DisplayName=...) でBlueprint上の表示名をどうするかなどは、Antigravityに「この関数をBlueprintから呼びやすい形に整えて」と頼むと一発で揃います。私はこのパターンで、ドメイン特化のヘルパーライブラリを4つほど自動生成して回しています。
2. 親クラスとなる UObject / UActorComponent の生成
Blueprintは「親クラスを継承して、その上にノードを足す」という構造なので、親クラスをC++で堅牢に書いておくほどBlueprint側がシンプルになります。これはAntigravityが一番輝く領域だと感じています。
たとえば「インベントリの増減と保存だけをC++で実装し、UI連動はBlueprintでやる」という分担にすれば、AIにロジックを任せつつ、ビジュアル調整は自分の手で素早く回せます。
3. UE5 Editor Utility（Python）でBlueprint側を半自動編集する
意外と知られていませんが、UE5にはエディタ拡張用のPython APIがあり、 これを介すればBlueprintのプロパティをスクリプトで一括変更できます 。
# tools/rename_socket_attachment.py
# 大量のスケルタルメッシュアクターのソケットアタッチメントを一括変更する
import unreal
asset_paths = unreal.EditorAssetLibrary.list_assets("/Game/Characters", recursive=True)
for path in asset_paths:
asset = unreal.EditorAssetLibrary.load_asset(path)
if isinstance(asset, unreal.SkeletalMeshActor):
comp = asset.get_editor_property("skeletal_mesh_component")
comp.set_editor_property("attach_socket_name", "weapon_r_socket")
unreal.EditorAssetLibrary.save_asset(path)
unreal.log(f"Updated: {path}")このPythonスクリプトは普通のテキストファイルなので、Antigravityが完璧に読めますし、書けます。Blueprint本体を直接いじれなくても、 「Blueprintの集合に対する一括操作」 はAIに任せる対象として最適です。私はリファクタや命名統一の作業を、ほぼこの方式に置き換えました。
4. .Build.cs と .uplugin のメンテナンス
UE5プロジェクトに新しいモジュールを足すたびに .Build.cs の PublicDependencyModuleNames を更新する作業は、地味に間違えやすい箇所です。Antigravityは「このモジュールにOnlineSubsystemUtilsを追加して」と頼めば、依存関係の上下関係まで踏まえた差分を出してくれます。
私の実プロジェクトで採用しているハイブリッド構成
何度か試行錯誤して、現在は次のような分担に落ち着いています。
- C++層（AIが書く） — Gameplay Ability System、AIController、データテーブル定義、Saveシステム、Online連携、ヘルパーライブラリ
- Blueprint層（人間が組む） — UMG（UIアニメーション）、レベル固有のシーケンサー連携、敵スポーン演出、プレイヤー操作の最終チューニング
- Pythonツール層（AIが書く） — 一括リネーム、アセット監査、ビルド前のサニティチェック
この分担にしてから、AIに頼んでよい範囲が明確になり、Blueprintを開いてフリーズする時間が減りました。重要なのは、 「Blueprintで完結させたい場所をはっきり線引きする」 ことだと考えています。境界が曖昧なままだと、Antigravityが「親クラスにロジックを移しましょう」と提案しすぎて、Blueprint側の見通しが悪くなる経験を何度かしました。
AntigravityにUE5プロジェクトを正しく理解させる AGENTS.md
UE5プロジェクトでAntigravityの精度を上げるために、私はリポジトリ直下に次のような AGENTS.md を置いています。
# このプロジェクトについて
UE5.5 で開発中のインディー1人称アクションです。
## ディレクトリ構成
- `Source/MyGame/` — ゲームプレイC++（Blueprintの親クラスはここ）
- `Content/` — Blueprint・アセット（バイナリ。AIは読み取れません）
- `tools/` — Python製のエディタユーティリティ
- `Plugins/` — 自作プラグイン
## AIへのお願い
- `Content/` 配下の `.uasset` は読めません。Blueprint固有の質問が来たら
「Blueprintの内容を見ずに答えられない」と素直に伝えてください
- 新しいゲームプレイロジックは、まずC++のヘルパーライブラリ・コンポーネント・
Subsystem として実装する案を提示してください
- `tools/` のPythonスクリプトは UE5 Editor Python API で実行されます
- C++のクラス名は `UMyGame` プレフィックス、ヘッダーは Public/Private 分離AGENTS.md を置くようになってから、「Blueprintの中身を勝手に推測した擬似コード」を返してくる頻度が大幅に減りました。AIに「読めないことは読めないと言っていい」と教えるだけで、回答の正確さが上がる感覚があります。
うまくいかなかったパターン
参考までに、私が遠回りした使い方も共有します。
- Blueprintのスクリーンショットを貼って質問する — Antigravityはマルチモーダルに対応していますが、Blueprintのノードグラフは情報密度が高すぎて、変数名やピン接続を読み違えることが多々ありました。短い区間でも誤読のコストが大きいので、私は採用をやめました
.uassetをテキストエディタで開かせる — シリアライズされたバイナリなので意味のある情報は得られません- C++とBlueprintの両方を一気に書かせる — 結局Blueprint側は人間がノードを置くしかないので、AIには「C++層だけ完成させて、Blueprintで使う想定の関数シグネチャをコメントで列挙して」と頼むほうが速いです
次に試すと変わるかもしれない一歩
もしあなたがUE5プロジェクトでAntigravityを使い始めるところなら、まず AGENTS.md に「Blueprintは読めない」と書き、次に Source/ 配下の小さな UBlueprintFunctionLibrary を1つAntigravityに実装させてみてください。それだけで、AIに任せる範囲と人間が手を動かす範囲の境界が、自分の感覚としてはっきりします。
UE5のAI支援情報がもう少し増えるまでは、Blueprintというビジュアル層を尊重したまま、その下のC++・Pythonにだけ静かにAIを走らせる、というのが私の現時点での結論です。同じようにUE5でAIを試しているインディー開発者の方の参考になれば嬉しく思います。お読みいただきありがとうございました。
関連記事として Antigravity × UE5：プラグインの本番設計ガイド と Antigravity × UE5でAI NPCを動かすインディーゲームガイド も、合わせて読んでいただくと全体像が見えやすいかと思います。