ANTIGRAVITY LABEN
記事一覧/アプリ開発
アプリ開発/2026-04-28上級

Antigravity × Unreal Engine 5 プラグイン本番設計ガイド — AIで再利用可能なゲームシステムを複数タイトルに展開する

Unreal Engine 5のプラグイン開発をAntigravityで進めるための本番運用ガイド。モジュール設計、ビルド構成、AIと相性の良いコード分離、複数タイトルで使い回すための配布パターンを解説します。

antigravity355unreal-engine-5ue52plugingame-devcpp2production54

プレミアム記事

UE5プロジェクトを2本3本と作っていくと、毎回似たコードを書き直していることに気づきます。インベントリ、セーブ、設定画面、実績解除、UIフレーム——内容は微妙に違うのに、構造はだいたい同じです。プラグインに切り出せばいいのは分かっているのですが、.Build.csの依存関係やPublic/Privateの分割で詰まり、結局ゲームコード側にベタ書きしてしまった——そんな経験はないでしょうか。

私自身、UE5でゲームを作りながら同じ壁に何度もぶつかりました。Antigravityを使い始めてからは、エージェントがBuild.csの書き方やヘッダの公開範囲まで提案してくれるおかげで、プラグイン化の心理的ハードルがかなり下がっています。ただし、AIが提案するコードをそのまま受け入れているとビルドが通らない場面もあり、「AIが力を発揮しやすいプラグイン構造」を意識して設計する必要があると感じました。

ここではAntigravityと相性の良いUE5プラグインの設計方針を、3つのゲームシステム(インベントリ・セーブ・実績)を題材に解説します。コードはそのまま自分のプロジェクトに移植できる完全な形で示し、最後には複数タイトルで使い回すためのバージョン運用と配布パターンまで踏み込みます。

なぜ「AIと相性の良いプラグイン構造」を意識するのか

Antigravityのエージェントは、AGENTS.mdやプロジェクトのファイル構造を手がかりにコードを生成します。UE5プロジェクトをそのまま開かせると、エージェントはSource/<GameName>/配下を一塊のモジュールとして扱おうとするため、プラグイン側のヘッダを探しに行ったり、Plugins/配下のシンボルをリンクしたりする際に文脈が途切れがちです。

特につまずきやすいのが、Public/Private/の境界です。UE5ではPublic/に置いたヘッダだけが他モジュールから#includeでき、Private/は内部実装専用というルールがあります。これを無視してエージェントに「インベントリのアイテム追加処理を書いて」と頼むと、Private/の構造体を外部モジュールから直接参照するコードを書いてくれるため、UnresolvedExternalのリンクエラーが出ます。

つまり、プラグインを「APIゾーン」と「実装ゾーン」に明確に分け、Antigravityにその構造を伝えるドキュメント(後述のAGENTS.mdスニペット)を置いておくと、エージェントの提案精度が劇的に上がります。これがこの記事の出発点です。

プラグインの骨格を作る:.uplugin.Build.cs

まずは骨格を作ります。プロジェクト直下のPlugins/CommonGameSystems/にプラグインを置く想定で、最小構成は次のようになります。

Plugins/CommonGameSystems/
├── CommonGameSystems.uplugin
└── Source/
    ├── CommonGameSystemsRuntime/
    │   ├── CommonGameSystemsRuntime.Build.cs
    │   ├── Public/
    │   │   ├── Inventory/InventoryComponent.h
    │   │   ├── SaveSystem/GameSaveSubsystem.h
    │   │   └── Achievements/AchievementSubsystem.h
    │   └── Private/
    │       ├── CommonGameSystemsRuntime.cpp
    │       ├── Inventory/InventoryComponent.cpp
    │       ├── SaveSystem/GameSaveSubsystem.cpp
    │       └── Achievements/AchievementSubsystem.cpp
    └── CommonGameSystemsEditor/
        ├── CommonGameSystemsEditor.Build.cs
        ├── Public/
        └── Private/

RuntimeEditorを分けるのが本番運用の必須要件です。Editorモジュールはパッケージビルド時には組み込まれないため、エディタ専用ツールやアセットアクションを置く場所として機能します。これを最初に分けておかないと、後でゲームをパッケージングしたときに「Slateがない」「UnrealEdが解決できない」という典型的なリンクエラーに悩まされます。

CommonGameSystems.upluginの中身は次の通りです。

{
  "FileVersion": 3,
  "Version": 1,
  "VersionName": "1.0.0",
  "FriendlyName": "Common Game Systems",
  "Description": "Reusable runtime systems (inventory, save, achievements) for UE5 indie titles.",
  "Category": "Gameplay",
  "CreatedBy": "Your Studio",
  "EnabledByDefault": true,
  "CanContainContent": true,
  "Installed": false,
  "Modules": [
    {
      "Name": "CommonGameSystemsRuntime",
      "Type": "Runtime",
      "LoadingPhase": "Default"
    },
    {
      "Name": "CommonGameSystemsEditor",
      "Type": "Editor",
      "LoadingPhase": "PostEngineInit"
    }
  ]
}

LoadingPhaseDefaultにしておくと、UGameInstanceの初期化と前後してモジュールがロードされます。PreDefaultにしてしまうとエンジンサブシステムにアクセスできず、Antigravityの提案コードがUAssetManager::Get()でクラッシュするケースが頻発するので注意してください。

CommonGameSystemsRuntime.Build.csはAntigravityがもっとも提案を間違えやすいファイルです。以下を雛形として置いておくと、エージェントが余計な依存を足したときに差分でレビューしやすくなります。

// Copyright (c) Your Studio. All Rights Reserved.
using UnrealBuildTool;
 
public class CommonGameSystemsRuntime : ModuleRules
{
    public CommonGameSystemsRuntime(ReadOnlyTargetRules Target) : base(Target)
    {
        PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs;
        bUseUnity = false; // 単独ファイルのビルド速度を優先(プラグイン開発時に重要)
 
        PublicIncludePaths.AddRange(new[] { "CommonGameSystemsRuntime/Public" });
        PrivateIncludePaths.AddRange(new[] { "CommonGameSystemsRuntime/Private" });
 
        PublicDependencyModuleNames.AddRange(new[]
        {
            "Core", "CoreUObject", "Engine",
            "GameplayTags",          // タグでアイテム種別を識別
            "DeveloperSettings",     // 設定値のデータドリブン化
        });
 
        PrivateDependencyModuleNames.AddRange(new[]
        {
            "Json", "JsonUtilities", // セーブデータの直列化
            "OnlineSubsystem",       // 実績連携
        });
    }
}

bUseUnity = falseは本番では好みが分かれますが、プラグイン開発初期は単一ファイル単位の差分でビルドされるため、AIが書いたコードの問題箇所を絞り込みやすくなります。完成後にtrueに戻して全体の最適化を測る、という流れがおすすめです。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
UE5プラグインの「Public/Private境界」をAntigravityが正しく理解できる構造に整え、エージェントの提案ミスに振り回されなくなる
インベントリ・セーブ・実績の3システムを動くC++コードと.uplugin/.Build.cs付きで習得し、自分のプロジェクトに持ち込める
1つのプラグインを複数タイトルで再利用するためのバージョン管理・ビルド分離・モジュール依存解決を本番想定で設計できるようになる
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

アプリ開発2026-05-03
Antigravity × TypeScript で作る冪等性キーと重複排除ストア本番設計ガイド
Stripe Webhook の二重課金や Temporal ワークフローの再実行で起きる重複処理を、冪等性キーと重複排除ストアで止める本番設計を、Antigravity を伴走者にして TypeScript で組み上げる実践ガイドです。
アプリ開発2026-05-01
Antigravity で実装するゼロダウンタイム DB マイグレーション:Expand-Contract パターンと AI 駆動の安全策
本番DBの型変更・カラム名変更・テーブル分割を、ユーザー影響ゼロで遂行するための Expand-Contract パターンを Antigravity の AI 支援とともに完全実装する本番運用ガイドです。
アプリ開発2026-04-26
Antigravity × Cloudflare エッジSaaS設計ガイド: D1・Workers・R2・Workers AIを統合した本番アーキテクチャ
Antigravityを使ってCloudflare D1・Workers・R2・Workers AIを統合したエッジSaaSを本番で動かすための完全設計ガイド。N+1問題・CPU制限・コスト管理など実際の落とし穴と解決策を網羅します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →