Unity-MCP 評判：C# の1行でメソッドを AI ツール化する Unity 開発プラグイン
AI Skills, MCP Tools, and CLI for Unity Engine. Full AI develop and test loop. Use cli for quick setup. Efficient token usage, advanced tools. Any C# method may be turned into a tool by a single line. Works with Claude Code, Gemini, Copilot, Cursor and any other absolutely for free.
ひと目でわかる
- これは何？
- Unity Editor とランタイムの両方から MCP 経由で LLM を接続するプラグイン。任意の C# メソッドを1行でツール化できる点が最大の特徴で、CLI によるセットアップと OAuth ログインも用意されている。
- 誰に向いている？
- Editor 上の反復作業を LLM に任せたい個人開発者や小規模チームには導入の価値がある。逆に、ビルド済みゲームに LLM を組み込む用途や、外部への送信を避けたいプロジェクトには向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 2 日前です。
- 何の言語で書かれている？
- 主に C# です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Unity の Editor 操作を LLM の手に渡すという発想
Unity でゲームを作っていると、シーンへのオブジェクト配置、コンポーネントの追加、アセットの参照設定といった作業が延々と続く。これらはコードを書く作業ではなく、Editor の GUI をクリックして回る作業だ。Unity-MCP が解こうとしているのはこの部分で、LLM に対して Unity Editor を操作するためのツール群を MCP（Model Context Protocol）越しに公開する。README は「Automate workflows, generate code」と表現しており、コード生成だけでなく Editor 上の操作そのものを対象にしている点が、単なるコード補完ツールとの違いになる。
対象読者は Unity で開発する個人や小規模チームだ。README が対応クライアントとして挙げているのは Claude、Cursor、Windsurf、GitHub Copilot、Gemini、Codex、VS Code、Rider、Visual Studio、Cline、Kilo Code、Open Code などで、特定ベンダーに寄せない方針が読み取れる。MCP はクライアント側の実装が共通化されているため、ツール側を1つ作れば複数のクライアントから使える。
Editor とランタイムの二重構造が意味するもの
このプロジェクトの構成で目を引くのは、Editor 用と Runtime 用の両方で動くと明記されている点だ。README には「Unlike other tools, this plugin works inside your compiled game」とあり、ビルド後のゲーム内から LLM を呼べることを差別化要素として挙げている。用途としては NPC の動的な振る舞いや、プレイ中のデバッグが想定されている。
ここは用途を分けて考える必要がある。Editor 側は開発中の自動化、ランタイム側は出荷物に近いコードに LLM 呼び出しが入る。後者はネットワーク越しの推論呼び出しがゲームの実行経路に入るということで、レイテンシやオフライン時の挙動を自分で設計しなければならない。README はこの点の具体的なフォールバックには触れていない。ランタイム機能は魅力的に見えるが、ドキュメントの厚みは Editor 側に比べて薄く、採用判断は Editor 用途を主軸に置いたほうが安全だ。
C# メソッドを1行でツール化する仕組み
README の説明で最も具体的なのが「Any C# method may be turned into a tool by a single line」という記述だ。プロジェクト内の C# メソッドに属性を1つ付けると、それが MCP ツールとして LLM から呼び出せるようになる。独自のツールを追加するための節も README 内に用意されている。
この設計の利点は、既存のゲームロジックをそのまま LLM の操作対象にできることにある。たとえば敵の生成、レベルデータの読み込み、テストの実行といった処理を、別途 API を設計し直すことなくツールとして公開できる。ツールの一覧はプロジェクトのコードから決まるので、汎用ツールを大量に並べた MCP サーバーよりも、コンテキストに載るツール定義を絞りやすい。README が「Efficient token usage」を掲げているのはこの構造と整合する。
ただし、属性を付けたメソッドがそのまま外部から到達可能になるということは、引数の検証や副作用の範囲を自分で管理する必要があるということでもある。README には権限やサンドボックスに関する記述は見当たらない。
CLI による導入手順と設定の実体
README が示す導入手順は2通りある。1つはリリースページから AI-Game-Dev-Installer.unitypackage をダウンロードして Unity プロジェクトに取り込む方法。もう1つが CLI で、こちらはコマンドが明示されている。
npm install -g unity-mcp-cli で CLI を入れ、unity-mcp-cli install-plugin ./MyUnityProject でプロジェクトにプラグインを導入する。続いて unity-mcp-cli login を実行すると、OAuth のデバイスフローでブラウザが開き ai-game.dev にサインインする。README の抜粋はここで途切れているため、ログイン後に何が起こるかは確認できない。
配布経路は複数ある。OpenUPM のパッケージ com.ivanmurzak.unity.mcp として公開されており、Docker イメージ aigamedeveloper/mcp-server も用意されている。接続方式は README によればローカルの stdio とリモートの http の両方に対応し、設定で切り替える。CI やコンテナ環境で動かしたい場合は Docker 側、日常の開発は stdio 側という住み分けが自然だろう。
スキル生成がプロジェクト構成に依存するという制約
README は機能として Skills を挙げ、「Generate skills for AI based on operating system, Unity version, plugins in the project」と説明している。OS、Unity のバージョン、プロジェクトに入っているプラグインを入力にして、AI 向けのスキルを生成するという仕組みだ。
これは裏を返せば、生成結果が環境に強く依存するということでもある。Unity のバージョンが上がった、あるいはプラグインを追加した場合、生成済みのスキルは前提がずれる。再生成のタイミングを自分で決める必要があり、README にはこの更新フローについての記述が見当たらない。プラグイン構成が頻繁に変わるプロジェクトでは、スキルと実環境の乖離がそのまま AI の誤操作につながる。
もう1つ、カスタムツールを追加した場合のビルドへの影響も確認したい点だ。ランタイム対応を謳う以上、Editor 専用のコードとビルドに含まれるコードの境界を意識してツールを置く必要がある。
向かないケースと、代わりに検討できる選択肢
Unity-MCP が向かないのは、まず外部通信を避けたいプロジェクトだ。MCP サーバーを介して LLM に操作させる構造上、プロジェクトの情報がモデル側に渡る。README にはデータの取り扱いに関する記述はない。社内の未公開アセットやライセンス上の制約がある素材を扱う場合、この点は導入前に自分で確認するしかない。
もう1つ、Editor の自動化だけが目的なら、MCP を挟まず Unity のエディタ拡張やコマンドラインビルドで足りる場面も多い。決まった手順を再現したいだけなら、LLM の判断を挟む分だけ不確実性が増える。
代替として挙げられるのは、Unity の公式が提供するエディタ拡張の仕組みや、MCP を介さず LLM の API を直接呼ぶ自前実装だ。違いは明確で、自前実装はツール定義もプロンプトもすべて自分で書き、対象を自分のゲームロジックに限定できる。Unity-MCP は汎用のツール群とスキル生成を最初から用意する代わりに、その抽象化レイヤの挙動を理解して付き合う必要がある。どちらが優れているという話ではなく、抽象化を買うか自分で持つかの差だ。
ライセンスと更新コストの見積もり
ライセンスは Apache-2.0。商用利用を含めて使いやすい条件で、変更を加えた場合の扱いもこのライセンスの範囲で決まる。ただし、同梱される依存パッケージや Docker イメージ内のコンポーネントが同じライセンスとは限らないため、配布物としてまとめる場合は依存関係を自分で確認する必要がある。ここは法的判断ではなく、確認作業としての指摘だ。
更新の頻度は低くない。リリースは 0.90.0 が 2026-08-24、0.89.0 が 2026-08-19、0.88.0 が 2026-08-16 と、おおよそ週次のペースで版が上がっている。バージョン番号が 0.x の段階であり、破壊的変更が入る前提で付き合うべきだ。Unity プロジェクトはパッケージのバージョンを固定して管理するのが基本なので、更新するときは必ずプロジェクトをバージョン管理下に置いた状態で行いたい。
OpenUPM 経由で入れている場合、更新は Unity の Package Manager から行うことになる。CLI で導入した場合は unity-mcp-cli 側の更新も別途必要になる。導入経路を途中で変えると、どちらの管理下にあるのか分からなくなるので、最初に決めた経路を維持したほうがよい。
編集部の結論
Editor 上の反復作業を LLM に任せたい個人開発者や小規模チームには導入の価値がある。逆に、ビルド済みゲームに LLM を組み込む用途や、外部への送信を避けたいプロジェクトには向かない。導入前に確認すべきは、自分の Unity バージョンとプロジェクトのプラグイン構成でスキル生成が通るか、そしてカスタムツールを追加したときにビルドが壊れないか。README の CLI 手順は npm install -g unity-mcp-cli から unity-mcp-cli install-plugin ./MyUnityProject、unity-mcp-cli login の3ステップで、ここが最初の検証ポイントになる。
コミュニティノート