MCP for Unity：47個のツールでUnity EditorをLLMから操作する
Unity MCP acts as a bridge between AI assistants and your Unity Editor. Give your LLM tools to manage assets, control scenes, edit scripts, and automate tasks within Unity.
ひと目でわかる
- これは何？
- Unity EditorとMCPクライアントをつなぐMITライセンスのブリッジ。シーン操作からスクリプト編集、テスト実行までを自然言語で扱えるが、導入はuv依存のPython経路とクライアント設定を経由する。
- 誰に向いている？
- Unity 2021.3 LTS以降を使い、すでにClaude CodeやCursorなどのMCPクライアントを常用している開発者には、導入の判断材料が揃っている。逆にPython 3.10+とuvを開発マシンに入れたくない場合や、MCPクライアントをまだ使っていないチームには、設定する理由が薄い。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 10 日前です。
- 何の言語で書かれている？
- 主に C# です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
誰のためのツールか：Unity Editorを操作するLLMクライアント
READMEの冒頭は「Create your Unity apps with LLMs.」と宣言し、Claude、Codex、VS Code、ローカルLLMなどをUnity Editorにつなぐと説明している。対象は、すでに何らかのMCPクライアントを日常的に使っていて、そのクライアントからUnityのプロジェクトを触りたい人だ。チャット欄で指示を書く相手が決まっていない段階では、このツールを入れても接続先がない。
操作対象はEditorそのもので、READMEは「create scenes & GameObjects, edit C# scripts, manage assets, run tests, profile, and build」と列挙している。つまりランタイムのゲームコードを書くのではなく、アセットの整理、シーンの組み立て、テストの実行といった編集作業をLLMのツール呼び出しに置き換える。プロジェクトのホームページにはツールカタログがあり、READMEはそのエントリポイント数を47としている。数が多いこと自体は機能の深さを示さないが、少なくとも単一の汎用コマンドではなく、用途別に分かれた道具立てを想定していることは読み取れる。
MCPサーバーとUnityパッケージの二層構造
リポジトリの構成から読み取れる範囲では、このプロジェクトは二つの層に分かれている。一つはMCPクライアントから見えるサーバー側で、Python 3.10+とuvを必要とする。もう一つはUnity側のパッケージで、Package Managerからgit URLで追加する。READMEのインストール手順はこの順序を前提にしている。
データの流れは、クライアントがMCPのツール呼び出しを発行し、サーバーがそれを受けてUnity Editor側のパッケージに渡す、という形になる。READMEはこれを「bridges AI assistants ... with your Unity Editor via Model Context Protocol」と表現している。アセットやシーンの状態はEditor側にあり、LLMはそれを直接読むのではなくツール経由で参照する。だからこそ、何ができるかはツール定義の粒度に依存する。
複数のUnityインスタンスを同時に立ち上げている場合の経路は別ドキュメントに分かれており、READMEのAdvanced節がMulti-Instance Routingとしてリンクを置いている。単一プロジェクトを想定した最小構成では意識する必要はないが、複数プロジェクトを並行して開くワークフローではこのルーティングの仕様を先に読むことになる。
導入はPackage Managerのgit URLから始まる
READMEが示す手順は三つだけだ。UnityのPackage ManagerでAdd from git URLを選び、次のURLを貼る。
https://github.com/CoplayDev/unity-mcp.git?path=/MCPForUnity#main
READMEはこのリリースを使う場合は#v10.0.0のようにタグを固定するよう注記し、OpenUPM経由の `openupm add com.coplaydev.unity-mcp` も併記している。デフォルトブランチがbetaである点は見落としやすい。リポジトリ情報ではdefault branchがbeta、READMEのインストール例は#mainを指しており、参照先が一致していない。再現性を重視するならタグ固定が素直な選択になる。
次にUnityのメニューからWindow → MCP for Unity → Configure All Detected Clientsを実行する。検出されたMCPクライアントの設定をまとめて書き換える操作で、READMEはこれ以上の手動設定を求めていない。以降は「Create a cube at the origin and add a Rigidbody.」のようなプロンプトを投げる流れになる。
前提条件はUnity 2021.3 LTSから6.xまで、Python 3.10+、そしてuvである。uvはPython側の実行環境を用意するために入れる。つまりUnityだけで完結せず、開発マシンにPython系のツールチェーンを一つ追加することになる。
ツールグループとRoslyn検証という二つの制御点
47というエントリポイント数をそのままクライアントに渡すと、LLMが選ぶ候補が増え、意図しないツールを呼ぶ余地も広がる。READMEのAdvanced節はTool Groups（vfx / animation / ui / testing など）を案内しており、用途別にツール群を絞る前提があると読める。何を有効にするかの判断は導入時に発生する作業だ。
もう一つの制御点がRoslyn script validationである。C#スクリプトの編集をLLMに任せる場合、壊れたコードをEditorに反映させる前に検証できるかどうかが作業の中断頻度を左右する。READMEはこの機能を独立したガイドとしてリンクしているだけで、検証がどの段階で走るか、失敗時に編集がどう扱われるかまでは本紙の材料からは確認できない。採用前に読むべき箇所としては、ツールカタログよりこちらの方が優先度が高い。
v10ではアセット生成まわりに変更があり、v10 Migrationという移行ノートが用意されている。v9系から上げる場合、このノートを読まずに更新すると、ツール名や引数の差異でプロンプトが通らなくなる可能性がある。
向かない場面：Python経路とMCPクライアント前提
このツールが不要になる条件は二つある。一つはMCPクライアントを使っていない場合で、接続先がない以上、47のツールは存在しないのと同じだ。もう一つは、開発マシンにPython 3.10+とuvを入れることを避けたい場合である。Unityのパッケージだけで完結する構成ではないため、CI環境や統制された端末ではこの依存が導入の障害になる。
もう一点、READMEにはリモートでホストしたサーバーに認証を付けるためのガイドがAdvanced節に置かれている。既定の使い方がローカル前提であることは、このガイドが別項目として存在することから推測できる。チームで共有するサーバーを立てる構成を検討しているなら、Configure All Detected Clientsによる一括設定とは別の設計を読む必要がある。
ライセンスはMITで、追加の条件は課されていない。ただしREADMEは「not affiliated with Unity Technologies」と明記しており、Unity本体のサポート対象ではない。UnityのバージョンアップでEditor側のAPIが動かなくなった場合、待つ先はUnity Technologiesではなくこのプロジェクトのリリースになる。
代替手段との違い：AuraとGodot AI
READMEは同じ運営元の商用ツールとしてAura for Unityを挙げ、MCP for UnityはMITで無償、AuraはUnity/Unreal向けのプレミアムなAIアシスタントだと説明している。違いはライセンスと提供形態で、MCP for Unityはクライアントを自分で選び、ツール群を自分で構成する前提の部品である。一方のAuraはアシスタント側まで含めて提供される。どのクライアントを使うかを自分で決めたいなら前者、決定そのものを委ねたいなら後者という住み分けになる。
もう一つ、READMEはGodot AIを「the new open source project from the makers of MCP for Unity」として紹介している。エンジンが違えば操作対象のAPIもアセットモデルも異なるため、ツールの実装をそのまま流用できるわけではない。Unityを離れる予定があるなら移行先の候補にはなるが、同じツール群が使えるという意味ではない。
MCPという共通プロトコルに乗っている点は、クライアント側の乗り換えコストを下げる。Claude DesktopからCursorへ移る場合でも、サーバーとUnityパッケージの構成は変わらない。ただしConfigure All Detected Clientsが新しいクライアントを検出するかは実行してみるまで分からない。
維持コストとバージョンの追い方
リポジトリ情報では直近のリリースがv10.2.0（2026-09-01）、その前がv10.1.2（2026-08-02）、v10.1.0（2026-07-13）で、月に一度程度の間隔で更新が続いている。デフォルトブランチがbetaであることと合わせると、mainを追う運用は常に開発中の変更を拾うことになる。安定させたいならタグ固定、最新のツールを試したいならbeta、という選び方になる。
貢献する場合の分岐先もbetaと指定されている。コントリビューションの手順はCONTRIBUTING.mdとドキュメントのContributing節に分かれている。
ライセンスはMITなので、改変や再配布の条件は比較的緩い。ただし本記事は法的助言ではない。社内で配布物に含める場合は、MITの表示義務を自組織の基準に照らして確認する必要がある。
更新時に読むべきはv10 Migrationのような移行ノートで、ツールの追加や変更はここに集約される。プロンプトを固定して運用しているチームほど、このノートの確認を更新手順に組み込む価値がある。
編集部の結論
Unity 2021.3 LTS以降を使い、すでにClaude CodeやCursorなどのMCPクライアントを常用している開発者には、導入の判断材料が揃っている。逆にPython 3.10+とuvを開発マシンに入れたくない場合や、MCPクライアントをまだ使っていないチームには、設定する理由が薄い。最初に確認すべきは、Package Managerに登録するgit URLのタグを#mainではなく#v10.0.0のような固定タグにできるか、そしてWindow → MCP for Unity → Configure All Detected Clientsが自分のクライアントを検出するかどうかである。
コミュニティノート