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日時点の公式リポジトリ（最新版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優先に書き換えられました。

日付は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の解説記事で詳しく扱っています。

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 <x.y.z> を付けます。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 で始まるコマンドがサンドボックスの対象外になります。リポジトリの検証メモ（2026年7月27日、Claude Code 2.1.220・macOS）では、sandbox.network.allowUnixSockets にソケットのパスを書いても遮断は解けなかったと記録されています。権限設定の全体像はClaude Codeの使い方と権限設定の記事を参照してください。

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移行ガイドにあります。

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（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になります。主な状態と次の手は次のとおりです。

レスポンスの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の記事で扱っています。

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<TSchema, TResponse> を継承し、[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<CheckSceneSchema, CheckSceneResponse>
{
    public override string ToolName => "check-scene";

    protected override Task<CheckSceneResponse> 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エージェント開発の支援も行っています。

Coplay版などUnity向けMCPとの選び分け

Unity向けのAI連携OSSには、MCPサーバーとして動くものが複数あります。2026年10月19日にGitHub APIで取得した値（最新版はReleasesのlatest、StarはAPIの整数値）で並べると次のとおりです。

判断の軸は、使う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の解説記事で、Unity公式のAI機能はUnity AIの解説記事で扱っています。Claude CodeとCodexのどちらでループを回すかはCodexとClaude Codeの違いの記事が参考になります。

よくある質問

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の新機能に記載）。継続提供される操作は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月】
• Agent Skillsとは？SKILL.md仕様と46製品で動かす移植性の実装手順
• Claude Codeの使い方｜導入から権限とCLAUDE.md設定まで実務手順
• Unity AIとは？料金（クレジット制）・使い方・Museからの移行を解説【2026オープンベータ】