Unity CLIとAIエージェント連携：Editorを観測・操作・検証する実践ガイド

Unity は 2026 年 7 月 20 日に新しい CLI と com.unity.pipeline を公開した。これまで Unity 開発は Editor を GUI で開いて、コード変更・再コンパイル・テスト・スクリーンショット確認という流れを人間が回していた。AI コーディングエージェントがコードを書けても、結果確認は人間のタスクのままだった。新しいツールセットはそこを変える。CLI から起動中の Editor に接続して、Scene、Prefab、Console、テスト、Play Mode の状態を構造化データとして取得・操作できる。つまり AI が「修正案を出す人」から「検証まで自分でやる人」へ変わるということだ。構成は単純だ。AI エージェントが unity コマンドを実行するか、MCP クライアント経由で接続する。unity status / list でスキーマを確認し、unity command で登録済みコマンドを呼び出す。結果は JSON で返る。操作と引数は事前に定義でき、危険な処理には dry_run や confirm を要求できる。重要なのは Unity API を無制限に直接触らせるのではなく「チームがレビュー可能な操作面を定義して、その中で AI を動かす」という設計になっていることだ。AIの鬼が警戒すべきはここ。com.unity.pipeline は 2026 年 8 月 10 日時点で実験版（0.4.0-exp.1）だ。Unity CLI も beta だ。つまり「動く」と「本番対応」は別だということだ。最小構成で始める際は、読み取り専用の project_health だけ実装して、書き込みや Package 操作は許可しない。そしてバージョン固定の厳格さが信頼性を左右する。Editor / CLI / Pipeline の版を記録し、CI で無条件にアップグレードしない。検証済みバイナリを社内キャッシュに置く。これが後々の「なぜか動かない」を防ぐ唯一の手段だ。中小企業の実務には、次のような合理性がある。Unity 開発でコード生成を AI に任せるなら、検証ループも自動化しないと意味がない。ローカルは Pipeline で高速に 100 回回して、Pull Request だけクリーン環境でヘッドレス検証する。この分け方ができれば、人間の確認は差分レベルだけになり、「AI 出力を信頼できるか」という判断が明確になる。ただし「実験版を本番で使う」という一時的な選択肢がある。その時は必ずバージョン固定と事後検証を組み込んで、後から「あの時の判断は何だったのか」と説明できる設計にする。