こんにちは、美空です！
Unity CLIとUnity Pipelineを使うと、ターミナルからUnity Editorへコマンドを送ったり、AIエージェントにシーンを編集してもらったりできます。
unity commandでEditorコマンドを呼び出したり、unity evalでC#コードを実行したりと、かなり面白いことができるようになってきました。
でも、実際にAIエージェントへ操作を任せていると、突然処理が止まってしまうことがあります。
エラーが出たわけでもない。
Unity Editorも落ちていない。
なのに、AIエージェントはずっとEditorからの応答を待っている……。
そんなときは、Unity Editorの裏側で確認ダイアログが開いていないかをチェックしてみてください。
確認ダイアログがAIエージェントを止めてしまう
例えば、AIエージェントが現在のシーンを編集したあと、別のシーンを開こうとしたとします。
編集したシーンが保存されていなければ、Unity Editorは通常、次のような確認を表示します。
- シーンを保存する
- 保存せずに移動する
- 操作をキャンセルする
人間がEditorを操作しているなら、内容を確認してボタンを押せば済みます。
ところが、Unity CLIやAIエージェントは、このようなUnity Editor上のダイアログを直接操作できない場合があります。
Unity Discussionsでも、未保存シーンの確認ダイアログが開き、エージェントが操作できずに処理が止まってしまう例が報告されています。Unityの担当者は、Unity CLIとPipelineパッケージではEditorへフォーカスを移さなくても操作できる一方、ブロッキングダイアログの制御にはEditor側の変更が必要だと説明しています。
一時的な対策が「-automated」
ブロッキングダイアログへの一時的な対策として案内されているのが、Unity Editorの起動引数である-automatedです。
-automated
Unityの担当者は、ダイアログによって処理が止まる場合、Unity Editorの起動パラメーターへ-automatedを設定するよう案内しています。
ここで間違えやすいのですが、-automatedはunity commandなどに付けるUnity CLIのオプションではありません。
Unity Editorを起動するときに、Editorへ渡すコマンドライン引数です。
Unity CLIから「-automated」を付けて起動する
Unity CLIのunity openには、Unity Editorへ追加の引数を渡すための--argsオプションが用意されています。
例えば、次のようにプロジェクトを起動します。
unity open "/path/to/MyProject" --args "-automated"
Windows PowerShellの場合は、次のようになります。
unity open "C:\Projects\MyProject" --args "-automated"
macOSの場合は、次のように指定できます。
unity open "/Users/username/Projects/MyProject" --args "-automated"
unity openは、プロジェクトの設定から対応するUnity Editorのバージョンを判断して起動します。Unity CLIのリリースノートでも、unity openから--argsをUnity Editorへ転送する機能が確認できます。
Unity CLIは現在も実験的な機能です。バージョンによってオプションが変わる可能性があるため、実際に使用する前に次のコマンドで確認してください。
unity open --help
Unity公式ドキュメントでも、インストールされているバージョンの正確なコマンドとフラグについては、CLIの--helpを正式な確認先として利用するよう案内されています。
Editorを直接起動する方法
unity openを使わず、Unity Editorの実行ファイルを直接起動しても構いません。
Windows
& "C:\Program Files\Unity\Hub\Editor\6000.5.0f1\Editor\Unity.exe" `
-projectPath "C:\Projects\MyProject" `
-automated
macOS
/Applications/Unity/Hub/Editor/6000.5.0f1/Unity.app/Contents/MacOS/Unity \
-projectPath "/Users/username/Projects/MyProject" \
-automated
Linux
~/Unity/Hub/Editor/6000.5.0f1/Editor/Unity \
-projectPath "/home/username/Projects/MyProject" \
-automated
Unity Editorのコマンドライン引数は、Unityの実行ファイルの後ろに追加します。-projectPathでは、起動するUnityプロジェクトを絶対パスまたは相対パスで指定できます。
Unity CLIでインストール済みEditorの場所を確認できるバージョンでは、次のコマンドも利用できます。
unity editors path 6000.5.0f1
ただし、利用できるサブコマンドはUnity CLIのバージョンによって異なります。
unity editors --help
こちらも併せて確認しておきましょう。
Unity Pipelineから起動中のEditorへ接続する
Unity Editorを-automated付きで起動したら、Unity Pipelineから接続します。
まだPipelineパッケージをインストールしていない場合は、プロジェクトを開いた状態で次のコマンドを実行します。
unity auth login unity pipeline install
Editor側のコンパイルが完了したら、次のコマンドでインストール状況を確認します。
unity pipeline list
起動中のEditorで利用できるコマンドを確認する場合は、プロジェクトのディレクトリで次のコマンドを実行します。
unity command
複数のUnity Editorを起動している場合は、対象プロジェクトを明示します。
unity command --project-path="C:\Projects\MyProject"
Unity Pipelineの公式ドキュメントでも、unity commandによる自動検出と、--project-pathを使った特定Editorへの接続方法が案内されています。
「-automated」が選ぶのは既定のアクション
ここはかなり重要です。
-automatedを付けても、すべてのダイアログで必ず「保存する」や「OK」が選ばれるわけではありません。
Unityの担当者によると、-automatedを指定している間は、すべてのダイアログで既定のアクションが使われます。そのため、Pipelineへ接続したEditorセッションだけで使用するよう注意が示されています。
つまり、ダイアログによっては次のような結果になる可能性があります。
- 変更内容が保存される
- 保存せずに処理が続行される
- ファイルが上書きされる
- 設定変更が確定される
- 既定側がキャンセルなら処理が中止される
どのボタンが選ばれるかは、そのダイアログの既定アクション次第です。
「ダイアログが表示されても安全に判断してくれる」という機能ではないので、そこは勘違いしないようにしましょう。
通常の作業用Editorには付けない
-automatedを普段のUnity Editorへ常時追加するのはおすすめできません。
人間がEditorを操作しているときは、確認ダイアログの内容を読んでから判断する必要があります。
ところが-automatedが有効になっていると、ダイアログが表示された時点で既定の選択肢が使われる可能性があります。
そのため、Editorの起動方法を次のように分けておくと安全です。
通常作業用 unity open "C:\Projects\MyProject" AI・Pipeline操作用 unity open "C:\Projects\MyProject" --args "-automated"
デスクトップやPowerShellに、自動操作専用の起動スクリプトを用意しておくのもよさそうです。
Gitで変更を戻せるようにしておこう
AIエージェントへUnity Editorの操作を任せるなら、Gitなどのバージョン管理はほぼ必須です。
-automatedによってダイアログで既定の操作が選ばれるだけでなく、AIエージェント自身が意図と異なるシーン編集やファイル変更を行う可能性もあります。
最低でも、操作を始める前に現在の状態をコミットしておきましょう。
git status git add . git commit -m "Before Unity CLI automated session"
AIエージェントの作業が終わったら、変更されたファイルを確認します。
git status git diff
自動化がどれだけ便利になっても、最後に変更内容を確認するのは人間の役目です。
「-batchmode」とは何が違う？
Unity Editorには、自動処理でよく使われる-batchmodeもあります。
-batchmode
-batchmodeは、テストやビルドなど、人間の操作を必要としない処理を実行するためのモードです。公式マニュアルでは、人間の操作が必要なダイアログを抑制し、自動化処理を中断せずに実行できると説明されています。
一方、Unity CLIとPipelineを使ったエージェント操作では、通常のUnity Editorを起動したまま、シーン、GameObject、コンポーネント、Play Modeなどを対話的に操作することがあります。
このような用途では、単純なバッチ処理とは目的が違います。
| 引数 | 主な用途 |
|---|---|
-automated |
通常のEditorをPipelineやAIエージェントから操作し、ダイアログによる停止を一時的に回避する |
-batchmode |
CIでのビルドやテストなど、対話操作を必要としない処理を実行する |
-nographics |
バッチモードでグラフィックスデバイスを初期化せずに処理する |
-automatedは、-batchmodeの代わりではありません。
Unity CLIで何を自動化したいのかを考えて、使い分けましょう。
「-automated」は現時点では一時的な対策
Unity Pipelineパッケージは、Editorが前面に表示されていなくても操作できるように設計されています。
しかし、Unity Editorに表示されるブロッキングダイアログをPipeline側から制御するには、Editor本体の変更と既存バージョンへのバックポートが必要になるとのことです。
そのため、-automatedは完成されたダイアログ制御機能ではなく、現時点での一時的な回避策として紹介されています。
Unity CLI自体も、2026年7月時点では実験的な機能として公開されています。今後のバージョンで、コマンド、引数、Pipelineとの接続方法が変わる可能性があります。
まとめ
Unity CLIとUnity Pipelineを使ってUnity Editorを操作する場合は、Editor起動時に-automatedを追加してみましょう。
Unity CLIから起動する場合は、次のように指定します。
unity open "/path/to/MyProject" --args "-automated"
これにより、確認ダイアログが表示されてAIエージェントが延々と待ち続ける問題を回避しやすくなります。
ただし、覚えておきたいポイントは次の3つです。
-automatedはUnity CLIではなくUnity Editorへ渡す引数- ダイアログでは既定のアクションが自動的に使われる
- 通常作業用ではなく、Pipeline接続専用のEditorセッションで使う
便利だからといって、何も考えずに通常のEditorへ付けっぱなしにするのは危険です。
Gitで変更を戻せる状態を作り、自動操作専用のセッションとして使う。
これでUnity CLIを使ったAIエージェント操作も、少し安心して任せられるようになるはずです！
