要約

いまよくある Unity Codex の工程はこう進む。Codex CLI に Unity 公式のプラグイン unity-agent-plugin を入れ、MCP で開いている Unity 6 エディタにつなぎ、コーディングツールに Unity の現行ドキュメントどおりの URP、UI Toolkit、アプリ内課金のコードを書かせる。

この区間は実際に使える。プラグインを入れたことが示すのは、自動化されたコーディングがますます滑らかになっている、ということだけである。気になるのはやはりアートの扱いだ。アートの一括処理と、一括生成とコードロジックのあいだの同期である。

公式プラグインが提供するもの

リポジトリは Unity-Technologies/unity-agent-plugin で、Claude Code と Codex は同じものから入れる。OpenAI の Eric Provencher が 9 月 10 日に「Codex now has a Unity plugin!」と一行だけ書き、そこからコミュニティの解説が大量に出た。

公式ドキュメント Unity’s plugin for Codex の書き方は明確で、大げさでもない。これは Asset Store のアセットではなく、Package Manager（パッケージマネージャー） からも入れられない。README は Unity 6+ 向けと明記し、状態表示の例は unity@unity-agent-plugin installed, enabled 0.1.0-beta である。

Codex 側のインストールコマンド：

codex plugin marketplace add Unity-Technologies/unity-agent-plugin
codex plugin add unity@unity-agent-plugin

Codex のセッションを新しく開いて /unity: と入力すると、この Skills が並ぶ。更新は codex plugin marketplace upgrade unity-agent-plugin で行う。Claude Code も同じリポジトリを使い、セッション内では /plugin install unity@unity-agent-plugin になる。

MCP がつなぐのは開いているエディタ

Unity 6 では、Edit（編集）→ Project Settings（プロジェクト設定）→ AI → Unity MCP で Bridge が Running（実行中） かどうかを確認できる。最初の接続は Pending Connections（承認待ちの接続） に入り、エディタ内で Accept（承認） を押さないと通らない。ドキュメントでは通信はローカルの IPC で、そのためにプロジェクトのソースを送る必要はない、とされている。

ここで二つの画面が混ざりやすい。公式プラグインが使うのは、Unity エディタに内蔵されたこの MCP Bridge である。このサイトで書いた Unity MCP は別のサービス画面で、既定ポートは 6594、Cursor や Codex にワンクリックで設定するためのものだ。どちらもローカルで動くが、同じパネルではない。通信そのものの仕組みは MCP で AI コーディングツールをゲームエンジンにつなぐ にある。

通信が通ったあとは、いまのシーン、ゲームオブジェクト、Console（コンソール） のログを読めるし変更もできる。前提は変わらない。切り出しがエンジンのフォルダ構成で書き出してあり、名前がノードと揃っていることだ。

Skills が覆うのはプロジェクト内の書き方

skills ディレクトリにはいま 31 のモジュールがある。UI と画像に関わるのは ui、ui-uitk、ui-ugui、ui-imgui、manage-sprite-atlas、sprite-editor、sprite-segment-3x3grid である。残りは Tilemap、Pixel Perfect カメラ、URP Render Graph、Shader Graph、Built-in から URP への移行、さらにアプリ内課金、LevelPlay、マルチプレイヤーサービス、ボイス、TextMeshPro のフォントフォールバック、WebGL、Unity CLI でのビルドを覆う。

README の例文も同じ層で止まっている。設定画面を一枚つくる、カメラが動くとピクセル画像が揺れる、TextMeshPro で日本語や中国語が空の四角になる、ScriptableRendererFeature の Render Graph を調べる。どれもプロジェクトを開いたあと、エディタの中でする作業である。

言い換えると、プラグインが解くのは「十年前の書き方をもう出さない」ことだ。プラグインの目標は、AI で Unity の既存コード資産を最新の標準と実装まで作り直すことにあるように見える。

UI 画像の一括処理はまだプラグインの外にある

ui-uitk が答えるのは、この画面を UI Toolkit にするか uGUI にするかである。manage-sprite-atlas が答えるのは、プロジェクトにすでにある画像をどうアトラスにまとめるかである。手元でより多いのはその前の段だ。AI が出したストア画像、イベントのポップアップ、HUD は、どれも一枚の合成図である。

この画像は検出したエッジから切り出し、意味のある名前の画像ファイルとして書き出し、Assets/Textures や Assets/Prefabs に書き込み、そのうえで元のレイヤーの文脈も保持して同期させる必要がある。一枚か二枚なら手でも終わる。同じ画面をもう一度生成するとき、祭りで一セットまるごと差し替えるときは、枚数が増える。この段は README にも Skills の一覧にも入っていない。

整理されておらず、構造もない大量の切り出し画像と、プログラムのプロジェクトとのリアルタイムな対応づけは、重視すべき一環である。コーディングツール側で扱えるのはファイル名とノード名だ。その塊がボタンかどうかはその文脈に入っておらず、あとの AI コーディングはイベントを揃えられない。

画像を切り分けること自体は、いまはもう時間を取らない。Unity に読み込んだあと、元の位置と操作の情報が復元できるかどうかが、見ておくところである。関連する記録は Figma から Unity へ と 自動レイヤー分割：画像を複数レイヤーに にある。

すでに通っていて、いまも使っているやり方：アート素材を一括生成し、単独で管理する

コーディングは Codex に任せる。公式プラグインを足すと、開いている Unity 6 に向けてコードを書く区間は手数が減る。現行ドキュメントのやり方で生成され、コンソールのエラーも MCP 経由で読み戻して直せる。

UI 画像の一括生成と処理は VberAI Studio で済ませ、それから Unity に読み込む。デザインファイルを直すときは、VberAI Studio に戻ってもう一度書き出す。プロジェクト内の階層は、元のレイヤー構造とまだ揃えられる。開いているプロジェクトは Unity MCP で同期する。アート素材の同期とコードロジックの同期は一緒に進める。

まとめ

ゲーム開発における並行作業の処理は、既存コードの更新という一区間だけではない。

デモ動画

Unity Codex プラグインはエンジン側のコード向け。UI 画像の一括処理は別工程が要る。