インストール
"command": "npx",
"args": ["-y", "ue-mcp@latest", "C:/path/to/MyGame.uproject"]向いている人
Windows（UE 5.4-5.8）または Linux/macOS（UE 5.6+）で Unreal Engine プロジェクトを開発していて、MCP クライアントから自然言語でエディタを操作したい開発者とテクニカルアーティスト。公式の説明では、ブループリント、マテリアル、レベル、アクター、アニメーション、VFX、ランドスケープ、PCG、フォリッジ、オーディオ、UI、物理、ナビゲーション、AI、ネットワーク、シーケンサー、ビルドパイプラインなどをカバーする 29 のツールカテゴリと 2040 以上のアクションに加え、複数ステップのワークフロー向け YAML フローエンジンを備えるとしている。エディタ内での繰り返しの多いシーン構築やアセット調整が日常だったり、AI にエディタ作業の一部を任せたい場合に最も合う。エディタを開かないオフラインパイプラインでは出番がない。判断は簡単で、日常業務の大半をエディタ内で行っているか、モデルにプロジェクトアセットを直接変更させてよいか、両方が「はい」のときに先へ進めばよい。
前提となるのはローカルのツールチェーンが揃っていることだ。Node.js 18 以上。エンジン付属の PythonScriptPlugin（エンジンに同梱され、init が必要な他のプラグインを有効化してくれる）。そして必須の C++ ツールチェーン——Windows では C++ ワークロード入り Visual Studio、macOS では Xcode コマンドラインツール。ブリッジプラグインがエディタの初回起動時にコンパイルされるためだ。C++ ツールチェーンがない、あるいはプロジェクトへの C++ プラグイン導入を望まないマシンには向かない。epic カテゴリの機能には UE 5.8+ が要る。もう一点、プラグインの導入はプロジェクト単位で行われる。プロジェクトを切り替えるときは、新しいプロジェクトで対話型 init をやり直してブリッジプラグインを導入し、そのプロジェクトのエディタ初回起動時のコンパイルを待つ必要がある。切り替え全体の完全な手順は証拠に記載がなく、未確認だ。ライセンスや費用、プロジェクト規模への追加要件も証拠に触れられていないため、自分で確認すること。
3 分で最初の試行
推奨される主な手順は、MCP クライアントの設定で npx によりサーバーを起動し、自分の .uproject を指すこと。前提：上記の UE、Node.js 18+、C++ ツールチェーンが導入済みであること。
クライアントの設定に公式スニペットを追加する：
"command": "npx",
"args": ["-y", "ue-mcp@latest", "C:/path/to/MyGame.uproject"]
C:/path/to/MyGame.uproject を自分のプロジェクトファイルのパスに置き換える。初回実行では対話型セットアップが始まり、カレントディレクトリの .uproject を自動検出し、有効にするツールカテゴリを選ばせ、C++ ブリッジプラグインをプロジェクトに導入し、必要な UE プラグイン（Niagara、PCG、GAS など）を有効化し、MCP クライアントを検出して設定する。
成功のサイン：エディタの初回起動によるプラグインのコンパイルが済むと、クライアント側にこのサーバーのツールカテゴリが現れる。開いているエディタに自然言語で 1 つの指示を出し、エディタ内で実際の反応が観察できるか。カテゴリがなかなか現れないときは、設定内のプロジェクトパスが正しいかを先に確認し、それから初回コンパイルの完了を待つ。
注意：公式はこれを、AI アシスタントにエディタへの深い読み書きアクセスを与えるものと位置づけており、書き込み操作はプロジェクトの内容を直接変更する。証拠には個々のツール名と読み書きの区別が記載されていないため、特定の読み取り専用ツールを最初の呼び出しに指定することはできない。まずバージョン管理下かバックアップのあるプロジェクトで試し、AI には実行前にどんな操作を行うか説明させること。
使用例
例 1：自然言語でレベルとアクターを調整する。エディタを開いた状態で、クライアントにやりたいシーンの変更を一文で伝えると、サーバーがレベル・アクターカテゴリのツールを呼び出してエディタ内で実行する。期待できる範囲：この 2 つの領域は公式が自然言語プログラミング可能と謳う範囲内。個別のツール名とパラメータは証拠に記載がなく、クライアントに実際に現れるツール一覧を基準にしてほしい。不安なら先にテストプロジェクトで通し、それから本番へ。
例 2：YAML フローエンジンで複数ステップのワークフローを実行する。一文の指示では足りず、エディタ操作を固定の連続手順にしたいときは、内蔵の YAML フローエンジンで複数ステップのフローを記述し、サーバーに実行させられる。確認できているのは、このエンジンが存在し複数ステップのワークフロー向けだということ。YAML の具体的な形式や例は証拠にないため、着手前に公式ドキュメントを確認すること。フローが書けないときは、まず一文ずつの指示で検証し、それからフローにまとめる。
使う上での境界
読み書きの性質：公式に示されているのは読み書きアクセスであり、読み取り専用サービスではない。取り消し手段も提供されていないため、書き込み操作を取り消せる前提で扱わないこと。AI に動かさせる前に、プロジェクトのどこを変更するのかを確認すること。ローカルへの影響：導入するとプロジェクト内に C++ ブリッジプラグインが配置され、UE プラグインが有効化される。実行時はクライアントが stdio でサーバーに接続し、サーバーが WebSocket JSON-RPC でエディタ内のプラグインに接続する。どのカテゴリを有効化するかはセットアップ時に自分で決めるもので、当面不要なカテゴリは無効のままにすれば露出面は小さくなる。外部ネットワークへのアクセス、テレメトリやデータ収集の有無、資格情報の要否、同じプロジェクトに複数クライアントが接続したときの動作は、いずれも証拠に説明がなく未確認。説明が見つからないことをリスクがないことと同一視せず、これらの境界を使う全員に事前に共有しておくことを勧める。