--- title: "uLoopMCPとは？現Unity CLI Loop V3の導入手順とMCP廃止後の使い方" url: "https://www.issoh.co.jp/tech/details/11004/" published: 2026-02-17 updated: 2026-10-19 categories: ["AIエージェント・MCP"] publisher: "株式会社一創" --- # uLoopMCPとは？現Unity CLI Loop V3の導入手順とMCP廃止後の使い方 uLoopMCPは、Claude CodeやCodexなどのAIエージェントにUnity Editorのコンパイル、テスト実行、ログ確認、シーン操作を任せるためのOSSです。作者はhatayama氏で、ライセンスはMITです。2026年3月の1.0.0で名称が「Unity CLI Loop」に変わり、8月31日に公開されたV3ではMCP接続そのものが削除されました。いまは `uloop` というCLIと、AIエージェント向けのSkillsで連携します。 「uLoopMCP」で検索して見つかる導入記事の多くは、MCPサーバーとして `mcp.json` に登録する手順やNode.jsの準備を前提にしています。その手順はV3では使えません。この記事では、改称とMCP廃止の経緯、V3の導入手順、V2からの移行、主要ツールの使い方、Editorが応答しないときの切り分け、他のUnity向けMCPとの選び分けを、2026年10月19日時点の[公式リポジトリ](https://github.com/hatayama/unity-cli-loop)（最新版3.17.0）をもとに整理します。 ## まとめ：uLoopMCP（Unity CLI Loop）の現状と導入の要点 - **名称**：uLoopMCPは1.0.0（2026年3月15日）でUnity CLI Loopに改称しました。リポジトリは `hatayama/unity-cli-loop` に移り、パッケージ名は旧名の `io.github.hatayama.uloopmcp` のままです。 - **MCPは削除済み**：V3（2026年8月31日）でMCP接続は削除され、継続提供される操作は `uloop` コマンドから使う形になりましたが、削除されたコマンドや別の操作方法への移行が必要な機能もあります。MCPクライアントの設定ファイルに登録する使い方はできません。 - **導入**：CLIを入れ、Unityプロジェクトで `uloop package install`、使うAIツールに合わせて `uloop skills install --claude` などを実行します。Unity側のメニュー（`Window > Unity CLI Loop > Settings`）からも同じ作業ができます。 - **動作条件**：Unity 2022.3以降。V3のプロジェクトだけならNode.jsは不要で、TCPポートも使いません。 - **3.6.0以降の主な追加**：`hot-reload` は3.6.0で新しい型の導入に対応し、3.9.0ではinternalまたはアクセス修飾子のない型にも対応しました。その後、Editorの状態を見る `uloop status`、実行中のコマンドに停止を要求する `uloop cancel`、Unityを起動せずに.metaとGUIDを検査する `uloop verify-project`、失敗テストだけを再実行する `run-tests --rerun-failed` が加わりました。 - **Claude Codeの注意**：サンドボックスを有効にした環境でUnityとの接続が遮断される場合は、`sandbox.excludedCommands` に `uloop *` を追加します。 - **選び分け**：シェルを実行できるエージェントで開発ループを回すならUnity CLI Loop、MCPしか話せないクライアントから使うならCoplay版などのUnity MCPが向いています。 ## uLoopMCPからUnity CLI Loopへの改称とV3でのMCP廃止 uLoopMCPは2025年6月16日（日本時間）にv0.1.0が公開されました。当初はUnity Editor内のサーバーとAIツールの間に中継サーバーを置く、MCPサーバーとしての構成です。その後CLIからの利用が主になり、1.0.0のリリースノートには「Rebrand from uLoopMCP to Unity CLI Loop」とあり、READMEもCLI優先に書き換えられました。 | 版 | 公開日（日本時間） | 主な変更 | | ------- | ---------- | -------------------------------------- | | v0.1.0 | 2025-06-16 | uLoopMCPとして初版公開 | | v1.0.0 | 2026-03-15 | Unity CLI Loopへ改称、Node.js 22以上が必須に | | v2.0.0 | 2026-04-21 | 設定画面でMCPの非推奨を表示 | | v3.0.0 | 2026-08-31 | MCP接続を削除、CLIをネイティブバイナリ化 | | v3.9.0 | 2026-09-28 | hot-reloadでinternal・修飾子なしの新しい型に対応 | | v3.12.0 | 2026-10-06 | status・verify-project・–rerun-failedを追加 | | v3.16.0 | 2026-10-13 | cancelを追加 | | v3.17.0 | 2026-10-14 | UI Toolkitのクリック・ドラッグに対応（最新） | 日付はGitHub Releasesの公開時刻を日本時間に換算したものです（CHANGELOGはUTC基準のため、v2.0.0は2026-04-20と記載されています）。V3公開後は数日おきにリリースが出ており、9月26日の3.8.0から10月14日の3.17.0までの約2週間半でマイナー版が9つ上がりました。版番号を固定して使う場合は、後述の `project-runner-pin.json` と `uloop package install --version` で揃えます。 MCPをやめた理由について、READMEの設計思想の節は「ツールを増やしすぎると、AIがどのツールを使うべきか適切に判断できなくなります」と書き、各ツールの説明文がコンテキストウィンドウを消費する点も挙げています。そのため専用ツールは、コンパイルやログ取得のように何度も呼ばれる操作と、フレームをまたぐ入力シミュレーションやスクリーンショットのようにC#の動的実行では代わりにならない操作に絞っています。残りの大半のEditor操作は `execute-dynamic-code` で書く方針です。 V3公開（2026年8月31日）より前の解説には、MCP登録手順と旧npm版CLIの導入手順が混在しています。記事の日付がそれより古ければ、V2までの手順として読んでください。 ## uloop CLIとSkillsで動く仕組み V3の `uloop` コマンドは、次の3つの部品を経由してUnityに届きます。 - **dispatcher**：PATH上に1つだけ置く `uloop` 本体です。コマンドを受け取り、対象プロジェクト用のrunnerへ渡します。 - **uloop-project-runner**：プロジェクトごとのrunnerです。使う版は `.uloop/project-runner-pin.json` で決まり、自動でダウンロードされます。そのため、パッケージの版が違う複数プロジェクトを1台で開いてもCLIを切り替える必要がありません。 - **Unity Editor内のIPCサーバー**：macOSとLinuxではUnixドメインソケット、Windowsでは名前付きパイプで接続を受けます。TCPポートを使わないので、V2まであったポート設定やEditor同士のポート衝突は起きません。 AIエージェントはこのCLIを直接覚えるのではなく、同梱のSkills（READMEの一覧で21個）を読み込んで使います。「コンパイルエラーを直して」と指示すれば `/uloop-compile`、「テストを実行して失敗原因を教えて」なら `/uloop-run-tests` と `/uloop-get-logs`、「この修正をコンパイルせずに今すぐ反映して」なら `/uloop-hot-reload` が選ばれます。Skillsの本文は必要になったときに読まれるため、MCPのように全ツールの説明を毎回コンテキストに載せずに済みます。SKILL.mdの仕様は[Agent Skillsの解説記事](/tech/details/17685/)で詳しく扱っています。 ## Unity CLI Loop V3の導入手順 必要なのはUnity 2022.3以降のプロジェクトと、Skillsを読み込めるAIツール（Claude Code、Codex、Cursor、GitHub Copilot、Antigravityなど）です。導入はCLI、Unityパッケージ、Skillsの3つを入れる作業で、ターミナルとUnityのメニューのどちらからでもできます。 ### ターミナル経由のCLI・パッケージ・Skillsの導入手順 macOS、Linux（x86\_64）、Windows Git Bashではインストールスクリプト、macOSではHomebrewも使えます。 ``` # CLIのインストール（macOS・Linux・Git Bash） curl -fsSL https://raw.githubusercontent.com/hatayama/unity-cli-loop/main/scripts/install.sh | sh # Homebrewの場合 brew install hatayama/tap/uloop uloop -v # Unityプロジェクトのルートで実行 uloop package install uloop launch uloop skills install --claude # Claude Code uloop skills install --agents # Codexなど .agents/skills を読むツール ``` Windows PowerShellでは `irm https://raw.githubusercontent.com/hatayama/unity-cli-loop/main/scripts/install.ps1 | iex` を実行します。`uloop package install` はOpenUPMのscoped registryと依存を `Packages/manifest.json` に追加するコマンドで、版を固定したいときは `--version ` を付けます。`uloop launch` はプロジェクトに合った版のUnityを起動し、起動済みならそのEditorを前面に出します。Skillsをプロジェクトではなく全体に入れたいときは `uloop skills install --claude --global` です。 ### Unityメニュー経由のパッケージ・CLI・Skillsの導入手順 Package Managerの「+」から「Add package from git URL」を選び、`https://github.com/hatayama/unity-cli-loop.git?path=/Packages/src` を入力します。OpenUPMを使う場合は、Project SettingsのScoped Registriesに URL `https://package.openupm.com`、Scope `io.github.hatayama.uloopmcp` を登録します。改称後もscopeは旧名のままです。登録後はPackage ManagerのMy RegistriesでOpenUPMを選び、Unity CLI Loopをインストールします。 パッケージが入ったら `Window > Unity CLI Loop > Settings` を開き、Install CLIを押します。CLIのバージョンが表示され、ボタンがUninstall CLIに変われば成功です。続けて同じ画面で対象（Claude Code、または `.agents` 共通）を選び、Install Skillsを押します。 ### Claude Codeのサンドボックスで接続できないときの設定 Claude Codeでサンドボックスを有効にしている場合、Unixドメインソケットへの接続が遮断されることがあります。この状態では、Unityが正常に動いていても `uloop compile` などが `UNITY_NOT_REACHABLE`（`connect: operation not permitted`）で失敗します。`uloop --version` のようにEditorへつながないコマンドだけは通るのが見分け方です。 ``` { "sandbox": { "excludedCommands": ["uloop *"] } } ``` この設定を `~/.claude/settings.json` に追加すると、`uloop` で始まるコマンドがサンドボックスの対象外になります。リポジトリの[検証メモ](https://github.com/hatayama/unity-cli-loop/blob/main/docs/claude-code-sandbox.md)（2026年7月27日、Claude Code 2.1.220・macOS）では、`sandbox.network.allowUnixSockets` にソケットのパスを書いても遮断は解けなかったと記録されています。権限設定の全体像は[Claude Codeの使い方と権限設定の記事](/tech/details/17375/)を参照してください。 ## uLoopMCP・V2の設定からV3へ移行する手順 カスタムツールや自作スクリプトが無ければ、移行はパッケージの版を上げ、Settings画面でInstall CLI（またはUpdate CLI）とInstall Skills（またはUpdate Skills）を押すだけです。インストーラは古いnpm版CLIを `npm uninstall -g uloop-cli` で消そうとし、失敗したときは手動で実行するコマンドを表示します。 MCP時代の設定を使っていた場合は、次の3点を見直します。 - **MCPクライアントの設定**：Cursorの `.cursor/mcp.json` や、Claude Codeのプロジェクト共有設定 `.mcp.json`、個人設定 `~/.claude.json` に登録したuLoopMCPのエントリは、V3では接続先が存在しません。削除してSkillsの導入に置き換えます。 - **自作スクリプトとSKILL.md**：booleanオプションが値を取らなくなりました。`uloop compile --wait-for-domain-reload false` は `--no-wait-for-domain-reload` に書き換えます。`get-version`、`get-project-info`、`record-input` は削除されたので、代わりに `uloop --version`、`execute-dynamic-code`、Recordingsウィンドウを使います。 - **C#のカスタムツール**：名前空間が `io.github.hatayama.UnityCliLoop.ToolContracts` に変わり、V3に上げると必ずコンパイルエラーになります。手で直さず、起動時のSafe Mode確認で `Ignore` を選び、自動で開く移行ウィンドウ（`Window > Unity CLI Loop > Custom Tool Migration`）でMigrateを押します。ウィザードはファイルをその場で書き換えるので、先にcommitしておきます。詳しい手順は公式の[V3移行ガイド](https://github.com/hatayama/unity-cli-loop/blob/main/Packages/src/Documentation~/migration-v2-to-v3%5Fja.md)にあります。 V2のプロジェクトとV3のプロジェクトは同じマシンで併用できます。V3のdispatcherがV2プロジェクトを検出すると、対応するV2のCLIを取得して処理を委譲します。ただしV2側を動かす間はnpm経由になるため、Node.js 22以降が必要です。V2プロジェクトで `npm install -g uloop-cli` を入れ直すと、古いnpm版がV3のCLIを隠してしまうので避けてください。 ## 主要ツールで回す自律開発ループ ツールは用途別に3系統あります。どのツールが有効かは `uloop list` で確認できます。 - **開発ループ**：compile、get-logs、run-tests、hot-reload、pause-point、clear-console - **Editor操作**：execute-dynamic-code、get-hierarchy、find-game-objects、screenshot、control-play-mode、record-video、set-game-view-size、focus-window - **PlayModeテスト**：simulate-mouse-ui、simulate-mouse-input、simulate-keyboard、replay-input このほか、Editorの状態確認と復旧に使う `launch`、`status`、`cancel`、`verify-project` があります（次の章で扱います）。 ### compile・get-logs・run-testsによる修正ループ `compile` は `AssetDatabase.Refresh()` のあとDomain Reloadの完了まで待ち、エラーと警告を返します。IDEの静的解析では出ないUnity側のエラーを拾えるのが利点です。`get-logs` はConsoleの内容を種類や文字列、正規表現で絞り込み、新しい順に指定件数だけ返すため、ログ全体をAIのコンテキストに流し込まずに済みます。 `run-tests` はEditModeとPlayModeのテストをクラス名や正規表現で絞って実行し、結果XMLのパスを返します。3.12.0で加わった `--rerun-failed` は、同じテストモードで直近に完了した実行のうち、失敗またはinconclusiveだったテストだけを再実行します（`--filter-type` とは併用できません）。修正のたびに全テストを流さずに済むので、テスト数の多いプロジェクトほど往復が短くなります。 ``` uloop compile uloop get-logs --max-count 10 uloop run-tests --filter-type all # 修正後、失敗したテストだけを再実行 uloop run-tests --rerun-failed ``` `run-tests` は既定で未保存のScene・Prefab Stageの変更を保存します。保存を避けたい場合は `--unsaved-changes fail` を指定してください。また、PlayModeテストでは既定でDomain Reloadが無効になり、static変数がリセットされません。プロジェクトの設定を尊重する場合は `--respect-enter-play-mode-settings` を指定します。なお `uloop` は1つのEditorにつき同時に1コマンドしか受け付けず、実行中に送った2本目は短い再試行のあとBUSYエラーで返ります。サブエージェントに並列でテストを流させても、同じEditorでは重なりません。 ### hot-reloadとpause-pointによる再コンパイル不要の動作確認 V3で追加された2つのツールは、コンパイル待ちを減らすためのものです。`hot-reload` は編集した `.cs` のメソッド本体を、再コンパイルもDomain Reloadも挟まずに実行中のEditorへ反映します。private・internalメンバー、staticメソッド、asyncメソッド、イテレータにも効き、メソッドやフィールドの追加も反映できます。 反映できる範囲は3.6.0以降で広がりました。同梱の[hot-reloadのSKILL.md](https://github.com/hatayama/unity-cli-loop/blob/v3.17.0/Packages/src/Editor/FirstPartyTools/HotReload/Skill/SKILL.md)（3.17.0）では、編集したファイルで宣言したトップレベルのclass・struct・enum・interfaceも、そのリロードで導入されると書かれています。ツールリファレンス（`tools_ja.md`）にはまだ「新しい型の追加には `compile` が必要」とあり、こちらはCHANGELOGに追随していません。SKILL.mdに残っている制約は次のとおりです。 - 導入した型や追加したメンバーを、別アセンブリやリロード対象外のファイルから使う場合、リフレクション・シリアライズ・プロキシ転送に対応しないUnityメッセージ（`Awake` など）として呼ばせる場合は `uloop compile` が必要です。 - コンストラクタ、演算子、structのメソッド、setter・indexerのアクセサは `Skipped` になります。 - `Awake` や `Start` のように一度しか呼ばれないメソッドは、パッチは当たっても実行済みの呼び出しには効きません。 - 反映はファイル単位の全か無かで、メソッドのコンパイル・検証が失敗すると、そのファイルは反映されません。型の導入が失敗した場合は同じアセンブリ全体が反映されず、パッチ適用途中のエンジンエラーでは部分適用になる例外があります。 反映できずに残った変更は、`--compile-on-skip` の既定値 `auto` により、EditModeのときだけ自動で `compile` に切り替わります（PlayModeは止めません）。コンパイルが走るとhot-reloadで当てた変更はすべて解除されます。公式の「What’s New in V3」がhot reloadを探索フェーズ、compileを着地フェーズと位置付けているのはこのためです。 ``` uloop hot-reload --files Assets/Scripts/Enemy.cs uloop hot-reload --status # 適用中のパッチ・追加メンバー・導入した型を一覧 uloop hot-reload --revert-all # パッチをすべて外す ``` `pause-point` は、ソースを書き換えずに `ファイル:行` の位置でPlayModeを止め、その時点のローカル変数・引数・フィールドを `CapturedVariables` として返します。`Debug.Log` を仕込んで再コンパイルする往復が要りません。3.14.0からはパッケージ内のスクリプトにも仕掛けられます。ただしEditorのCode OptimizationがDebugになっている必要があり、Releaseのままだと有効化が拒否されます。 ### PlayModeの入力シミュレーションと画面確認 UIのボタン操作は `simulate-mouse-ui`（EventSystem経由）、`Mouse.current` を直接読むゲームロジックには `simulate-mouse-input` を使います。後者はInput Systemパッケージが入っていて、Active Input Handlingが「Input System Package (New)」か「Both」のときだけ使えます。3.17.0からは `screenshot` の要素注釈がUI Toolkitのコントロールも列挙し、`simulate-mouse-ui` のクリック・長押し・ドラッグがEventSystem無しでUI Toolkitに届くようになりました。`screenshot` でGame Viewを撮ってAIに見せ、`record-video` でPlay Mode中の操作を録画できます（LinuxではWebM）。Linuxでは `focus-window` が使えません。 ## Editorが応答しないときのstatus・cancelでの切り分け AIエージェントに長時間ループを回させると、コマンドが返ってこない、すべてのコマンドが `UNITY_SERVER_BUSY` で弾かれる、といった詰まりが起きます。3.12.0の `status` と3.16.0の `cancel` は、この状態を人がUnityの画面を見ずに判断するためのコマンドです。 `uloop status` は副作用なしでEditorの状態を1つ返し、`Ready` のときだけ終了コード0になります。主な状態と次の手は次のとおりです。 | State | 意味 | 次の手 | | ----------------- | ----------------------- | -------------------- | | Ready | コマンドを受け付けられる | そのまま実行 | | Busy | 別のuloopコマンドが実行中 | 終了を待つ（続けば cancel） | | Compiling | スクリプトのコンパイル中 | 終わるまで待つ | | ImportingAssets | アセットのインポート中 | 終わるまで待つ | | MainThreadBlocked | メインスレッドが5秒以上止まっている | uloop launch -r で再起動 | | NotRunning | このプロジェクトのEditorが起動していない | uloop launch | レスポンスのJSONには、実行中のコマンド名（`RunningToolName`）と経過秒数、次に取るべき操作（`NextActions`）も入ります。AIエージェントのSkillにも `/uloop-status` として入っているので、「Unityが起動中かもしれない」「コンパイル中かもしれない」場面では、コマンドを投げる前にエージェント自身が確認します。 `uloop cancel` は、Editorのコマンド枠を握っている実行中のコマンドに停止を要求します。`execute-dynamic-code` のスニペットが完了しない処理を `await` している、といったケースが典型です。別のターミナルから実行でき、結果は `Cancelled`（停止を要求した）、`NothingRunning`（何も実行中でない）、`NotCancellable`（止められない）のいずれかです。止められないのは、Domain Reloadを待つ既定の `compile`、`--respect-enter-play-mode-settings` 付きのPlayModeテスト、CLIではなくEditor内の拡張コードやウィンドウから開始したツールの3つです。 `Cancelled` は停止の完了を意味しません。キャンセルトークンを無視するツールは自分で終わるまで枠を握り続け、`ct` を無視する動的コードのスニペットはバックグラウンドで動き続けます。次のコマンドを送る前に `uloop status` が `Ready` になるのを確認してください。 ``` uloop status # Busyが続き、実行中のコマンドが終わる気配がないとき uloop cancel ``` Busyが出たらすぐcancelする運用は勧めません。リポジトリの`AGENTS.md`は、BUSYを見たら実行中のコマンドの終了を待って1回だけ送り直し、ループで再試行しないよう指示しています。`RunningToolElapsedSeconds` を見て、普段の所要時間を明らかに超えたときだけ `cancel` を使い、それでも `uloop` に応答しないほどEditorが固まったときは `uloop launch -r` で再起動します。例外は `hot-reload` で、実行中のコマンドが終わるのを最大10分待ってから送られます。 ### verify-projectによるcommit前の.meta・GUID検査 `uloop verify-project` はUnityを起動せずに、.metaファイルの欠落・孤立、GUIDの重複・不正、マージのコンフリクトマーカーの残り、`Packages/manifest.json` の破損を検査します。SKILL.mdによると、Unityはこうした問題のあるプロジェクトを開くと、黙ってアセットに新しいGUIDを振り直し、孤立した.metaを削除します。元の.metaを失い、バージョン管理やバックアップにも残っていなければGUIDの復元が難しくなるため、Unityを開く前に検査し、問題を修正します。 スクリプトによるアセットの移動・改名やブランチのマージでは、対応する.metaが一緒に移動・統合されているかを確認します。アセットを動かす作業のあとと、commitの前に `verify-project` を挟むようSkillかCLAUDE.mdに書いておくと、参照切れにつながる.metaやGUIDの問題を検出できます。検出後はレポートに従って修正し、再検査します。問題が無ければ終了コード0、見つかれば1で、レポートは標準出力に出ます。Unityのバージョン管理全般は[Unity Version Controlの記事](/tech/details/18089/)で扱っています。 ## execute-dynamic-codeの権限とチーム運用の設定 `execute-dynamic-code` はUnity Editorのプロセス権限で任意のC#を実行し、Unity API、.NET API、プロジェクトのアセンブリをすべて呼べます。V3の既定では無効化するツールの一覧（`ToolSettingsData.disabledTools`）が空で、このツールも最初から有効です。旧uLoopMCPの解説にある「動的コード実行は既定で無効」「Security LevelをRestrictedとFullAccessから選ぶ」といった前提はV3には当てはまりません。AIに任意のコードを実行させたくないプロジェクトでは、Settings画面のTool Settingsでこのツールを無効にします。 ツールの有効・無効は `.uloop/settings.tools.json` に保存されます。チームでそろえるなら、runnerの版を固定する `project-runner-pin.json` と一緒にgitで管理します。READMEの推奨 `.gitignore` は次のとおりです。 ``` **/.uloop/* !**/.uloop/project-runner-pin.json !**/.uloop/settings.tools.json ``` プロジェクト固有の処理は、コアパッケージを変えずにカスタムツールとして追加できます。以下は登録形式を示す最小例で、受け取ったSceneNameを文字列として返すだけです。シーンの存在確認や内容の検査は実装していません。V3では `UnityCliLoopTool` を継承し、`[UnityCliLoopTool]` 属性を付けます。 ``` using System.Threading; using System.Threading.Tasks; using io.github.hatayama.UnityCliLoop.ToolContracts; public class CheckSceneSchema : UnityCliLoopToolSchema { public string SceneName { get; set; } = "Main"; } public class CheckSceneResponse : UnityCliLoopToolResponse { public string Result { get; set; } public CheckSceneResponse() { } } [UnityCliLoopTool] public class CheckSceneTool : UnityCliLoopTool { public override string ToolName => "check-scene"; protected override Task ExecuteAsync(CheckSceneSchema parameters, CancellationToken ct) { ct.ThrowIfCancellationRequested(); return Task.FromResult(new CheckSceneResponse { Result = "checked: " + parameters.SceneName }); } } ``` ツールと同じ場所に `Skill/SKILL.md` を置き、対象エージェント向けに `uloop skills install --claude` などを再実行すると、そのSkillがインストールされます。C#ファイルは `Assets/Editor/CustomTools` 配下など、Editor用の場所に配置します。READMEは、定型の操作ならカスタムツールを作らず、手順やC#スニペットをSkillとして書いておくだけで足りることが多いとしています。社内のUnity開発にAIエージェントを組み込む設計から相談したい場合は、[AIエージェント開発の支援](/service/ai/agent/)も行っています。 ## Coplay版などUnity向けMCPとの選び分け Unity向けのAI連携OSSには、MCPサーバーとして動くものが複数あります。2026年10月19日にGitHub APIで取得した値（最新版はReleasesのlatest、StarはAPIの整数値）で並べると次のとおりです。 | リポジトリ | 連携方式 | ライセンス | 最新版 | Star | | ----------------------- | ------------------ | ---------- | ------ | ------ | | hatayama/unity-cli-loop | CLI + Skills | MIT | 3.17.0 | 582 | | CoplayDev/unity-mcp | MCP | MIT | 10.3.0 | 15,126 | | IvanMurzak/Unity-MCP | MCP + CLI + Skills | Apache-2.0 | 1.2.0 | 4,497 | | CoderGamester/mcp-unity | MCP | MIT | 1.5.0 | 1,936 | 判断の軸は、使うAIクライアントがシェルコマンドを実行できるかどうかです。Claude Code、Codex、Cursorのエージェントのようにターミナルを操作できるツールで、コンパイルとテストの往復を任せたいならUnity CLI Loopが合います。専用ツールを絞る設計で、hot-reload・pause-pointによる再コンパイル待ちの短縮と、status・cancel・verify-projectによる詰まりと破損の予防まで1つのCLIで揃います。hot-reloadを当てにするなら、コンストラクタやstructのメソッドの変更、プロキシ転送に対応しない新しいUnityメッセージ（Awakeなど）にはcompileが要る点がプロジェクトの作り方に合うかを確認してください。 一方、シェルを持たずMCPサーバーにしか接続できないクライアントからUnityを操作したい場合、Unity CLI Loopは選択肢になりません。V3にはMCPの受け口が無いためです。その場合はCoplay版などのMCPサーバーを使います。Unity 2022.3より古いEditorもUnity CLI Loopの対象外です。 名前が紛らわしいのが、Unity公式の「Unity CLI」（`unity` コマンド）です。Unity CLI Loop（`uloop`）とは別の製品で、Unity公式はエディタ内のMCPサーバーをAI Assistantパッケージのドキュメント2.18.0-pre.2（2026年8月）から非推奨とし、後継としてUnity CLIの `unity mcp` を案内しています。「unity cli mcp」で検索して出てくる `unity mcp configure` などの手順は公式Unity CLIのもので、`uloop` には当てはまりません。Unity公式のMCPサーバーを含めた比較は[UnityMCPの解説記事](/tech/details/6890/)で、Unity公式のAI機能は[Unity AIの解説記事](/tech/details/8536/)で扱っています。Claude CodeとCodexのどちらでループを回すかは[CodexとClaude Codeの違いの記事](/tech/details/17627/)が参考になります。 ## よくある質問 ### uLoopMCPとUnity CLI Loopは別のツールですか？ 同じツールです。2026年3月の1.0.0でuLoopMCPからUnity CLI Loopに改称しました。GitHubの旧URL（`hatayama/uLoopMCP`）は `hatayama/unity-cli-loop` に転送され、パッケージ名は `io.github.hatayama.uloopmcp` のままです。 ### uLoopMCPは今もMCPサーバーとして使えますか？ V3（2026年8月31日以降）では使えません。MCP接続は削除され、`uloop` CLIとSkillsだけが連携方法です（公式の[V3の新機能](https://github.com/hatayama/unity-cli-loop/blob/main/Packages/src/Documentation~/whats-new-v3%5Fja.md)に記載）。継続提供される操作はCLIから呼べますが、削除されたコマンドは移行が必要です。たとえば入力録画はRecordingsウィンドウで行います。 ### Unity CLI Loopの導入（インストール）方法は？ CLIをインストールスクリプトかHomebrew（`brew install hatayama/tap/uloop`）で入れ、Unityプロジェクトのルートで `uloop package install` と `uloop skills install --claude` などを実行します。Unityの `Window > Unity CLI Loop > Settings` からInstall CLIとInstall Skillsを押す方法もあります。 ### uLoopMCPは無料で使えますか？ MITライセンスのOSSで、ツール自体は無料です。料金がかかるのは、組み合わせて使うClaude CodeやCodexなどAIツールの利用料です。 ### 対応しているUnityのバージョンとOSは？ Unity 2022.3以降です。CLIはmacOS、Linux（x86\_64）、Windowsに対応しています。Linuxでは `focus-window` が使えず、`record-video` の出力はWebMになります。 ## 関連記事 - [UnityMCPとは？公式MCPサーバーの非推奨とUnity CLIでの接続手順・OSS版比較【2026年10月】](/tech/details/6890/) - [Agent Skillsとは？SKILL.md仕様と46製品で動かす移植性の実装手順](/tech/details/17685/) - [Claude Codeの使い方｜導入から権限とCLAUDE.md設定まで実務手順](/tech/details/17375/) - [Unity AIとは？料金（クレジット制）・使い方・Museからの移行を解説【2026オープンベータ】](/tech/details/8536/) --- 出典: [uLoopMCPとは？現Unity CLI Loop V3の導入手順とMCP廃止後の使い方]()（株式会社一創）