Claude Opus 5.5×Unreal：最初のプレイ可能レベル

実践上の結論は、初日からClaude Code、Unreal、Meshy、Blenderを全部つながないことです。最初に、Claude Codeが実際に起動しているUnreal Editorを読めることを証明します。次に、歩ける、3つの物を集められる、勝利できる、再スタートできるグレーボックスを作ります。各段階を自分の手でPlay検証してください。そのループが安定してから、生成3DアセットやBlenderでの修正に手間を増やす価値があるか判断します。

これは最新の公式資料に基づくガイドであり、筆者があなたのプロジェクトを実行したという実測記事ではありません。EpicはUnreal MCPを現在も Experimental とし、機能、API、データ形式が変わる可能性を明記しています。そのため本稿では、MCPの接続、ツールの成功応答、実際に遊べる結果を別々の証拠として扱います。

この方法が自分に向いているかを先に判断する

基本的なUnrealの概念を理解し、バージョン管理を使い、小さな変更ごとにPlayできる個人開発者に向いています。Claudeは、説明できて確認もできる作業を速められます。しかし移動、カメラ、コリジョン、手触りが良いかどうかを単独で判断することはできません。

状況	推奨
プロジェクト構造を読めて、差分を確認し、Playできる	以下の最小グレーボックスから始める
ゲームループだけを検証したい	Unrealのプリミティブを使い、MeshyとBlenderは後回しにする
バックアップやロールバック手段がない	先にコピーとバージョン管理のチェックポイントを作る
1つのプロンプトで完成ゲームを期待している	目標を観測可能な小さなシステムに分ける
Actorを1つ動かす、数値を1つ変えるだけ	通常は手作業のほうが速い

AnthropicはOpus 5.5を複雑なコーディングや長時間のエージェント作業向けに位置づけています。ただし、視覚的なゲーム結果が自動で正しいと証明されるわけではありません。読み取り、計画、実行はモデルに任せても、承認、観察、Play検証は人が行います。

ツールを増やす前に最小完成条件を決める

このガイドの完成条件は4つだけです。

Player Startから開始し、明確なルートを終点まで歩ける。
目に見える3つの収集物がそれぞれ1回だけカウントされ、0から3になる。
3つすべてを集めた後に限り、終点で勝利になる。
Rを押すと、プレイヤー位置、カウント、収集物、勝利状態が初期化される。

これをプロジェクトのbriefに書き、各バッチで「変更内容、期待結果、実際の結果、合否」を記録します。connectedはプレイ可能の証明ではありません。compile成功もプレイ可能の証明ではありません。ツールが要求を受理しただけでも不十分です。各ゲートは人がPlayして初めて通過します。

ゲート1：Claude Codeと公式Unreal MCPを接続する

先に復旧地点を作る

プロジェクトを保存し、現在の状態をcommitまたはshelveします。Epicの公式プラグインは、エディタープロセス内でPythonを実行できるツールを含め、Claudeへ広いライブアクセスを与えます。公式READMEは、これをアシスタント生成の任意コード実行と同様に扱い、長いセッション前に保存し、差分を確認するよう勧めています。

重要なプロジェクトで --dangerously-skip-permissions を使わないでください。最初はコピー、sandbox、または破棄できるbranchで試します。

Unreal側で2つのプラグインを有効化する

この手順は、現在 Unreal Engine 5.8 Documentation として公開されている Epic公式Unreal MCPページを前提にしています。使用中のEngine buildに Unreal MCP（ModelContextProtocol）と All Toolsets（AllToolsets）が実際に含まれている必要があります。すべてのUE5版に同じプラグインがあるとは推測しないでください。どちらかが見つからなければ停止し、コミュニティMCPで代用せずEpic文書の対象buildを使います。

公式手順に従います。

Edit → Plugins で Unreal MCP を有効化する。
All Toolsets も有効化する。これがないとserverがあっても実用toolsが公開されない場合があります。
Editorを再起動する。
Editor PreferencesでAuto Start Serverを有効にするか、consoleで実行する。

ModelContextProtocol.StartServer

既定のlocal endpointは http://127.0.0.1:8000/mcp です。既定では認証がなく、remote公開向けではありません。Internetへport forwardせず、共有端末でも使わないでください。

Claude Code用の設定を生成する

Unrealのコンソールで実行します。

ModelContextProtocol.GenerateClientConfig ClaudeCode

Launcher版は通常 .mcp.json を .uproject の隣に書きます。ソースbuildでは Engine/ と同じworkspace rootに書かれる場合があります。port変更後は再生成してください。生成された設定があるrootからClaude Codeを起動します。

Epic公式のClaude Codeプラグインを入れます。

/plugin install unreal-engine-skills-for-claude-code@claude-plugins-official

公式marketplaceがない場合は先に追加します。

/plugin marketplace add anthropics/claude-plugins-official

モデル接続、Unreal、アセットサービスを分ける

Claude CodeはAnthropicアカウントでも互換モデルAPIでも利用できます。BetterTokenを使う場合、現行のClaude Code接続ガイドでは ANTHROPIC_BASE_URL を https://bettertoken.ai にし、/v1を付けず、ANTHROPIC_AUTH_TOKEN をローカルで設定します。実API Keyをチャット、repository、資料パッケージへ貼らないでください。

Anthropicの公式model IDは claude-opus-5-5 です。BetterToken経由では、その時点のModel Plazaから正確なIDをコピーし、選択したKey groupで利用可能か確認します。起動後は /model とproviderのrequest記録で実際のroutingを検証し、古い設定を流用しないでください。

緑の表示だけでなく、実際のread-only呼び出しを確認する

4層すべてを確認します。

/plugin に公式Unrealプラグインが表示される。
/mcp に unreal-mcp が表示される。
UnrealのOutput Logにportや依存関係のエラーがない。
read-only promptで、実際のlevel名、主要Actor、Player Startの有無が返る。

最後の確認が、今のエディターへ届いている証拠です。Epicは、proxyがconnectedでも、cacheにツールが見えても、ライブのUnreal呼び出しが成功する証明にはならないと明記しています。

ゲート2：歩けるグレーボックスだけを作る

まずすでに操作できるthird-person基盤を用意します。Player Start はspawn位置を示すだけで、単独では操作可能character、GameMode、input、cameraを提供しません。新規projectならUnrealの Third Person templateを使います。既存projectなら、active GameModeが操作可能なthird-person pawnをspawnし、移動inputとfollow cameraが動作し、levelに Player Start があることを確認します。

MCPでgeometryを変える前に、Simulateではなく Play を押します。characterが実際にspawnし、WASD で移動し、mouseでcameraを操作できることを確認してからPIEを停止します。どれか失敗したら、greybox promptで隠さず基盤を先に直します。

合格後、Claudeにはcurrent level、GameMode、player character、利用可能toolsetsをread-onlyで確認させ、計画と変更assetを先に列挙させます。tool不足なら停止します。境界は次のようにします。

Play確認済みのthird-person基盤を使い、current levelに最小greyboxを作成する。既存player character、GameMode、input mappings、cameraは保持し、置換・再構築しない。primitiveで床、境界、明確なroute、goal markerを作る。enemy、art asset、複雑なUIは追加しない。作成・変更した全assetを報告する。必要toolがない、compileに失敗した、明示的successでない場合は停止する。

実行時のルール：

同じassetやeditor stateに依存する変更は直列化する。
C++、Blueprint、shaderのcompile完了を待つ。request acceptedはcompile完了ではありません。
各結果statusを読み、明示的success以外では停止する。

Play確認A： もう一度Playし、Player Start でspawnしたcharacterからroute全体を歩きます。境界外へ出る、狭い隙間で止まる、見えない障害をjumpする必要がある状態は失敗です。観測した問題だけを直し、camera、material、routeをついでに変更しません。

合格後に保存、commitし、復旧地点を作ります。

ゲート3：3つの収集物を追加する

次のbatchは収集ルールだけを追加し、合格済みのrouteを保護します。

route上に、見やすく離れた3つのcollectibleを追加する。接触は各1回だけ発火し、その後objectを非表示または削除し、読めるcounterを0から3へ増やす。Player Start、route、boundary、endpointは動かさない。関係するBlueprint、variable、event、UI assetを報告し、Play checklistを出す。

PlayゲートB： 通常順と逆順で集める。各objectは1回だけ加算。表示は1、2、3。元の場所を再通過しても増えない。新しいPlay sessionは0から始まる。

Claudeが完了と報告しても、Playでcounterが変わらなければ不合格です。実際の挙動とOutput Logを記録し、まず原因を調査させ、その後に1つの限定修正だけを依頼します。

ゲート4：勝利と再スタートを追加する

最後のgameplay batchは終了とresetだけを追加します。

counterが3のときだけendpointで勝利を表示する。3未満では勝利しない。Rでlevelを再スタートし、player位置、3つのcollectible、counter、勝利UIを初期状態へ戻す。既存routeとinputは維持する。変更点と5段階のPlay checklistを報告する。

PlayゲートC：

2つだけで終点へ行く：勝利しない。
3つ集めて到達：勝利が表示される。
途中で R：全状態が戻る。
勝利後に R：全状態が戻る。
別順序で収集：同じ正しい結果になる。

ここで初めて「最初のプレイ可能level」です。保存、commitし、外部artに依存しない安定greyboxを残します。

Greybox合格後にだけMeshyまたはBlenderを追加する

どちらも任意の分岐であり、最初の必須条件ではありません。

独自性のある小物が必要なときだけMeshyを使う

これは引き続き任意branchです。Meshy公式MCP serverには有効な MESHY_API_KEY が必要です。API keyには対象のpaid planが必要で、API requestはprepaid API creditsを使います。Web appのplanやworkspace残高表示だけではAPI accessやAPI balanceの証明になりません。生成前に meshy_check_balance を呼びます。

Bash上のClaude Codeでは次のlocal setupを使います。keyは非表示で入力し、chatへ貼らず、生成されたlocal configをcommitしないでください。

read -rs MESHY_API_KEY && export MESHY_API_KEY
claude mcp add-json meshy "{\"command\":\"npx\",\"args\":[\"-y\",\"@meshy-ai/meshy-mcp-server\"],\"env\":{\"MESHY_API_KEY\":\"${MESHY_API_KEY}\"}}"
unset MESHY_API_KEY

その後 /mcp で meshy 接続を確認し、利用可能なMeshy toolsを列挙させ、meshy_check_balance を呼びます。これらの確認はgeneration taskを作りません。key、plan、API balanceが使えなければここで停止します。

まず1個のcollectibleを単純なtext-to-3Dで作ります。

短く具体的な prompt と target_formats: ["glb"] を指定して meshy_text_to_3d を呼びます。これはtextureなしpreviewです。textureが別taskに値する場合だけ、preview成功後に meshy_text_to_3d_refine を使います。Refineは新しいtask IDを返すため、previewとrefineの両IDを保存し、textured resultのstatus確認とdownloadにはrefine IDをtask type text-to-3dで使います。
返されたtask IDとtask type text-to-3d を記録します。自然言語のchat結果だけを残してはいけません。
同じID/typeで meshy_get_task_status を呼びます。PENDING、IN_PROGRESS、tool側の TIMEOUT は失敗ではありません。status確認中のnetwork切断、429、5xx も FAILED ではありません。同じtask IDを後で再確認し、重複課金になり得る新taskを作りません。
SUCCEEDED 後だけdownloadします。FAILED では task_error を読み、CANCELED では停止します。明確なlocal source asset pathへ保存します。

meshy_download_model
task_id: <same task ID>
task_type: "text-to-3d"
format: "glb"
save_to: "<absolute-project-path>/SourceAssets/Props/CollectibleMarker/marker.glb"

BlenderまたはUnrealへ進む前にfileの存在を確認します。Asset Retentionでは、非Enterprise customerのAPI assetは最大3日保持です。download URLだけを残さないでください。

Asset確認D（Meshyを選んだ場合のみ）： local GLBを繰り返し開け、task ID、task type、prompt、final status、local pathを記録済みであること。まだUnreal向け完成assetの証明ではありません。

明確な修正作業があるときだけBlenderを使う

手動cleanupで十分であり、全員に別MCPを求めません。ClaudeでBlenderを操作すると決めた場合だけ、Blender公式MCPページから公式add-on、LLM client、MCP serverを導入し、編集前にscene objectのread-only inventoryを行います。community版 ahujasid/blender-mcp のport、tool名、setupを混ぜないでください。公式MCPはdata guardなしでLLM生成codeを実行するため、機密dataのないsystemまたはVMを使います。

static collectibleには次の最小routeを使います。

Blenderで File → Import → glTF 2.0 (.glb/.gltf) を選び marker.glb を開きます。対象propだけを残し、余分なgeometryを手動削除し、scale、orientation、origin、name、materialを確認します。
editable sourceを残すため <absolute-project-path>/SourceAssets/Props/CollectibleMarker/marker-clean.blend として保存します。
cleanup済みstatic propだけを選択し、File → Export → glTF 2.0 を選び、formatを glTF Binary (.glb) に設定し、Selected Objects と Apply Modifiers を有効化して .blend と同じ場所へ marker-clean.glb を保存します。
Unreal Content Browserで /Game/Assets/Props/Collectibles/ を作成または開き、marker-clean.glb をimportします。Interchangeのimport previewで対象entryが Static Mesh であることを確認し、そのstatic propだけをimportしてassetを保存します。Static Mesh Editorでsizeを確認し、必要な場合だけsimple collisionを追加します。既存overlap triggerを置換・妨害しないでください。
Play合格済みcollectible Blueprint/Actorを開き、visible Static Mesh componentのmesh referenceだけを置換します。trigger volume、one-shot collect event、counter、win/restart logic、配置instanceは保持します。compile、save後に再度Playします。

Asset確認E（Blender/import branchを選んだ場合のみ）： .blend、cleanup済み .glb、Unreal Static Meshが開け、scale、orientation、origin、collisionを説明でき、visible meshだけが変わり、Play確認A–Cが引き続き合格すること。

証拠の層ごとにトラブルを切り分ける

症状	最初に確認	誤認してはいけないもの
`/mcp`はconnectedだがlevelを読めない	editor起動、Output Log、実read-only call	ゲーム接続完了
serverは起動するがtoolがない	`AllToolsets`、必要なら `ModelContextProtocol.RefreshTools`	モデル能力不足
callが止まる、errorになる	compile、level loading、active PIE	必ずnetwork問題
Blueprint toolは返るがgameplayが壊れる	status、compile、Output Log、手動Play	完了
Meshy status確認がtimeout、切断、`429`、`5xx`	task ID/typeを保持し同じtaskを後で確認	`FAILED` または新しいpaid taskが必要という意味
download URLが失効	local copy、task ID、retention	永続URL
import後のscale/collisionが不正	unit、origin、export、Unreal collision	生成modelが必ず悪い

同じ症状への修正が2回失敗したら、最後に合格したcheckpointへ戻り、taskを小さくします。未検証の2修正の上に3つ目を重ねないでください。

利用量は3つの帳簿に分ける

「weekly Maxの19%」をAPI tokenへ換算しないでください。あるコミュニティ作者は、最初の完全buildに約4時間とweekly Max planのおよそ19%を使ったと報告しました。これは1人、1project、1設定の体験であり、時間、価格、quotaの保証ではありません。

経路	個別に確認すべき必須項目	含まれないもの	証拠
Claude subscriptionでClaude Code	plan、session/weekly limit、active model	Meshy credits、モデルAPI請求	Claude Codeのmodel/usage画面
モデルAPIでClaude Code	API key、実model ID、input/output/cache token、残高	Claude Max週次枠、Meshy	providerのrequest/請求記録。BetterTokenではmodelとtoken記録
任意のMeshy asset	`MESHY_API_KEY`、対象paid plan/API access、prepaid API balance、taskごとの使用量	model API token。Web app枠はAPI balanceの証明にならない	`meshy_check_balance`、task/billing記録
Unreal、Blender、plugin、content	現行license、hardware、marketplace asset、third-party plugin	全部無料という推測	各公式条件と購入記録

拡張前に1 levelでprompt回数、retry、model request、任意のMeshy task ID、download file、人手Play時間を記録します。coreはPlay確認A–Cを安定して繰り返す必要があります。DはMeshy選択時だけ、EはBlender/import branch選択時だけ必要です。実際に使うbranchが安定してから増やします。

最終チェックリスト

session前と各合格gate後にrollback地点がある。
/mcp表示だけでなく、実際のread-only Unreal callが成功した。
Playでrouteを歩き、3つだけ収集し、正しく勝利し、任意状態から再スタートできる。
asset変更前にPIEを停止し、compile完了後に次へ進んだ。
MeshyとBlenderはgreybox合格まで任意のままにした。
Meshyを使った場合、outputをlocal保存し、task ID、task type、final statusを記録した。
external assetでprimitiveを置換した場合、Play確認A–Cを再実行した。
実model、モデルtoken、Claude subscription枠、Meshy creditsを別々に確認した。

これで得られるのは、見栄えの良いAIデモだけではありません。何が本当に動くかを見失わず、復旧でき、観測でき、段階的に広げられる制作手順です。

Claude Opus 5.5で最初のUnrealプレイ可能レベルを作る

この方法が自分に向いているかを先に判断する

ツールを増やす前に最小完成条件を決める

ゲート1：Claude Codeと公式Unreal MCPを接続する

先に復旧地点を作る

Unreal側で2つのプラグインを有効化する

Claude Code用の設定を生成する

モデル接続、Unreal、アセットサービスを分ける

緑の表示だけでなく、実際のread-only呼び出しを確認する

ゲート2：歩けるグレーボックスだけを作る

ゲート3：3つの収集物を追加する

ゲート4：勝利と再スタートを追加する

Greybox合格後にだけMeshyまたはBlenderを追加する

独自性のある小物が必要なときだけMeshyを使う

明確な修正作業があるときだけBlenderを使う

証拠の層ごとにトラブルを切り分ける

利用量は3つの帳簿に分ける

最終チェックリスト

LLM ワークフローを最適化しませんか？

この方法が自分に向いているかを先に判断する

ツールを増やす前に最小完成条件を決める

ゲート1：Claude Codeと公式Unreal MCPを接続する

先に復旧地点を作る

Unreal側で2つのプラグインを有効化する

Claude Code用の設定を生成する

モデル接続、Unreal、アセットサービスを分ける

緑の表示だけでなく、実際のread-only呼び出しを確認する

ゲート2：歩けるグレーボックスだけを作る

ゲート3：3つの収集物を追加する

ゲート4：勝利と再スタートを追加する

Greybox合格後にだけMeshyまたはBlenderを追加する

独自性のある小物が必要なときだけMeshyを使う

明確な修正作業があるときだけBlenderを使う

証拠の層ごとにトラブルを切り分ける

利用量は3つの帳簿に分ける

最終チェックリスト

すべての記事

LLM ワークフローを最適化しませんか？