Unity向けMCP「uLoopMCP」を作った話
本記事はQualiArts Advent Calendar 2025の2日目の記事です。
AIにコードを書いてもらうのが当たり前になってきました。この記事では、私がUnity向けMCPサーバー「uLoopMCP]を作った経緯と、その開発過程について書きます。
何が出来るの？
READMEからの抜粋ですが、下記のような事が出来るようになります。
- Unity プロジェクトの「コンパイルが通るまで」「テストが緑になるまで」を、AI に任せて自律的に回し続ける
- 既存コードベースに対して、バグ修正やリファクタリングをAIに依頼し、
compile/test runnerの実行/log取得で結果を検証させる - 検証完了後、
MenuItemの実行またはコンパイル不要のC#コード実行でPlay Modeに入り、Unityウィンドウフォーカス機能でUnity Editorを最前面に表示させる - 大量のPrefab / GameObjectを
Hierarchy調査機能・Unity Search・コンパイル不要のC#コード実行でAIに調査させ、パラメータの一括修正やシーン構造の整理を行う - チーム専用のMCPツールを追加し、プロジェクト固有のチェックや自動修正をAIから呼び出せるようにする
AIを使い始めて感じた「あと一歩」な感じ
2025年2月頃から、AIにコードを書いてもらうテストを始めました。最初はChatGPTやClaudeのWeb UIで依頼し、出力されたコードをコピペするという流れです。
AIがコードを書いて修正してくれる、最初はその驚きだけで満足していました。しかし、それが当たり前になってくると、気になり始めた事があります。コンパイルエラーの修正が面倒だという事です。
当時のAIが生成したコードは、結構な頻度でコンパイルエラーを起こしました。そのたびにUnityのコンソールからエラーをコピーして、AIに伝えて、修正してもらって、またコンパイルして...。この繰り返しが煩わしくなってきました。
「勝手にUnityのコンソールからエラーを取得して、修正してほしい」
「書いたコードがちゃんと動くか、自分でコンパイルして確かめてほしい」
AIにコードを書かせているうちに、おそらく誰もがこう感じるようになるかと思います。
自作を決意したきっかけ
当時(2025/3頃)、Unity向けのMCPで私の要望を満たすものはありませんでした。
さらに、業務でMCPを使うにはセキュリティ的な懸念があり、安全が確認された一部のMCPしか利用が許可されていませんでした。サードパーティ製のMCPは検証が難しく、敷居が高い状態です。早くUnity公式のMCPが出ないかな、と思っていたものです。
そんな時、notargsさんがUnity向けMCPを自作しているというポストを見かけました。盲点でした。サードパーティ製の使用が社内NGで、公式からも出そうにない。なら自分で作れば良かったんですね〜！
その時のポスト
社内ではAtlassian製品向けMCPなどが内製されており、それらは使用が許可されていました。内製ならOKだし、AIに頼めばすぐ作れるだろう、と軽い気持ちで制作を始めました。
制作過程： 想像以上に上手くいかない！ からの、基本機能の分解からコツコツと
最初は「Unity向けのMCPを作ってください」という、超絶的に雑なプロンプトから始めました。それでもそれらしきものが数十分で作られ、驚いたものです。しかし、結果はやっぱり散々なものでした。
AIモデルを変えたり、もう少し詳細な指示を与えたりしても上手くいかない。「思ってたのとだいぶ違うな！」と思ったものです。
（当時はsonnet3.7、gpt-4.1、gemini2.5proあたりを使っていたと思います）
そこで、一気に作るのではなく、基本機能を分解していくことにしました。
- ログ取得機能：Unityのコンソールログを取得する
- コンパイル機能：コンパイルを実行して結果を返す
- テスト実行機能：挙動を保証するテストも書きたくなったので追加
まずは、これらをMenuItemから単体実行してテストできる機能から作り始めました。
当時、まだ仕様駆動開発という手法は広まっていなかったのですが、一部の方が先行して実践していた、まず仕様書を書かせる手法も途中から取り入れていきました。特に深津さんが紹介されていた「SOWを作って」という指示をよく出していました。
壁に当たる：ドメインリロードによる接続切断
MCPの通信にはSTDIOかStreamable HTTPを使います。当時、私はSTDIOでの接続しか知らず、その前提で作成していました。
（後ほど知ったのですが、当時のCursorはSTDIOしか対応しておらず、これは結果的に良い方向に働きました）
STDIOで作っていくと、ある問題にぶつかりました。コンパイルするとLLM Toolとの接続が切れるのです。
どうもドメインリロードが走ると、Unity内で動作していたMCPサーバーのコードがリセットされ、接続が切断されてしまう仕様のようでした。海外製のMCPをいくつか試しましたが、同じ問題を抱えているようでした。
そこで、おそらく一番有名なUnity向けMCPであるunity-mcpのREADMEを読んでみると、LLMツールとUnityの間にPython製のサーバーを挟んでいることが分かりました。
「この手法なら切断を回避できるかもしれない。LLMツールは常に中間サーバーと接続を保ち、中間サーバーとUnityが切断されても、自動で接続を復旧する仕組みを入れればいいはず」と思い、この方向性で再び作り始めました。
中間サーバーのTypeScriptはAI頼み
中間サーバーにはTypeScriptを選択しました。JavaScript経験があったのと、TypeScriptとC#の構文が似ていると感じたためです。
とはいえTypeScriptの知識はほぼゼロ。AIに頼りまくりました。linter、formatterなどの準備を依頼し、testも色々書かせました。
最初はSTDIOについての知識が少なく、TypeScriptサーバーにログを仕込んだだけで動かなくなる、という基本的なところでつまずきました。console.log()などの標準的なログ出力はstdout（標準出力）に書き込まれるため、LLM Toolとの通信にログが混じってしまうのです。
ログが出せないのは厳しいので、外部ファイルに出力するログライブラリを用意しました。これは深津さんが公開していたvibe-loggerを参考にしました。
node製のサーバーも同様に、下記のように機能を分解して作成していきました。
- LLMツールと接続し、文字列を返すだけの機能
- nodeサーバーとUnity側との接続
ハマりすぎて体調崩した
制作期間ですが、とりあえず動くところまでは半月、ブラッシュアップを含めて1ヶ月ほどでした。一瞬でできるだろ、と軽く見積もっていた時から振り返ると、思ったよりも時間がかかった印象です。
AIを使ったコーディングを経験した方は分かるかもしれませんが、勝手にAIがコードを書き、成果物ができていく様を見ているのは非常に新鮮で楽しいものでした。ある種の興奮状態になり、プライベートな時間はほぼすべて制作に費やしました。睡眠時間も削ってしまい、体調を崩したほどです。
完成とリリースまで
こうして、ログ取得・コンパイル・テスト実行ができて、ドメインリロードが発生しても接続が切れないMCPサーバーが完成しました。
まだバグは残っていましたが、AIが自律的にコンパイル、テストを走らせて自己修復していくのを見て、嬉しくなったものです。
「もうリリースしていいかな」と思った時、後発なのでもっとMCPとしての機能（Tool）を増やさないと使ってくれないのでは、と考えました。そこで、Unityからコンテキストを得る系のツールをいくつか追加しました。これらは業務でもバグの調査などで役に立っています。
機能追加と更なるブラッシュアップで +1ヶ月使い、そこでリリースしました。今思えばスピード重視ですぐにリリースした方が良かったのかもしれません。
中間サーバー方式の利点
現在、Cursorを含むメジャーなLLMツールはStreamable HTTPに対応しています。そのため、中間のTypeScriptサーバーを廃止することを最近になって考えました。
しかし、中間サーバー方式には利点もあります。たとえば、Unityがドメインリロード中であることを中間サーバーが把握し、専用のメッセージを返す、などです。中間サーバーを持つことで柔軟性が生まれるため、しばらくはこの構成で行こうと考えています。
uLoopMCPの特徴
特徴1: インストールとセットアップが簡単
様々なMCPの導入方法を見ていると、ターミナルからコマンド実行したり、設定ファイルを用意したりする必要があるものがほとんどです。uLoopMCPは、そういった手間がありません。
また、依存ライブラリを極力少なくしたので、uLoopMCPパッケージのみinstallすれば動く状態になり、数クリックでセットアップが完了します。
特徴2: 動的コード実行ツール
これは社内製Unity MCPの制作チームからアドバイスを受けて導入しました。アドバイスに感謝しています。
このツールを使うと、コンパイルの必要もなく、コードで実行できることならなんでもUnityを操作できます。ユーザーがUnity上で選択中ものをコンテキストとして渡す事も可能です。究極、このツールだけあれば他のツールは不要、という話にもなります(contextなど考えると非効率なのでやりませんが・・)。
例えば下記Postのような事が可能です。
このツールのもっと有用なユースケースについては、CEDEC KYUSHU2025での弊社の発表が詳しいかと思います。後ほど公開されると思いますので、楽しみにしていてください。
（ややこしいのですが、uLoopMCPが登場するわけではなく、アドバイスをくれた社内製MCPを含む発表になります。社内製MCPとuLoopMCPの 動的コード実行ツール の機能面はほぼ同等のものですので、資料のユースケースはそのまま参考になるかと思います）
（先に「uLoopMCPパッケージのみinstallすれば動く状態になる」とお伝えしたのですが、このツールを使う場合のみ、別途 Microsoft.CodeAnalysis.CSharp の導入が別途必要になります。）
特徴3: 複数Unityでの並列接続
AI Agentを使った開発では、複数のUnityインスタンスを起動し、並列で開発を進めることが多くなります。AI AgentとUnityが対になって接続できる状態は必須に思えました。それを簡単に実現できるUI・UXを目指しました。
日々進化しています
おかげさまで社内でもいくつかのプロジェクトで使ってもらえるようになりました。
私自身も業務で毎日使っているため、バグは見つけ次第すぐに対応しています。「こんなのがあれば便利だな」というツールもすぐに追加しています。
つい最近、Unity Editorを最前面に持ってくるというツールをリリースしました。「コンパイルさせる → 問題なければUnityを再生状態にさせる → Unityを最前面に持ってくる」というSlash Commandを用意すると便利です。
その他のUnity向けOSS
uLoopMCPの制作をきっかけに、Unity開発を便利にするツールをいくつか公開しています。
UnityHub CLI
claude codeやcodexの登場により、terminalで作業する機会が増えてきました。そこで下記のようなツールも作ってみました。
UnityHub CLIは、Unity Hubの内容をターミナル上で表示するCLIツールです。矢印キーやj/kで操作でき、oを押すとUnity Editorを起動できます。
最近のアップデートで、shift + oで設定しているIDEも同時に起動する事も可能になりました。
Node.js 20+が入っている環境であれば、npx unity-hub-cli で起動します。
LaunchUnityCommand
UnityHub CLIに似ているのですが、こちらはUIなしでサクッとUnityを開くCLIツールです。
私の場合、UnityHub CLIはローカルにあるプロジェクトを一覧として眺めたい時、LaunchUnityCommandは既に起動するプロジェクトが決まっている時、と使い分けています。
Node.js 20+が入っている環境であれば、npx launch-unity [/path/to/Proj] で起動します。(/path/to/Projはオプションで、記述なしでcurrent directoryにあるUnity Projectを起動します)
この2つを作ってから、公式のUnity Hubはほぼ使わなくなりました。
おわりに
軽い気持ちから始まった開発でしたが、AIの力を借りながら、自分の欲しかった機能を形にできました。
uLoopMCPが皆さんの開発体験を少しでも良くするお手伝いができれば幸いです。
Discussion