はじめに
こんにちは。モバイルゲーム事業本部でクライアントリードを行っている渡辺です。
弊社では半期ごとに社内ハッカソンを開催しています。今回のテーマは「AI と業務・環境改善」で、オンライン開催・制作期間 1 週間でした。全体のレポートは 社内ハッカソンレポート にあります。その中で「PSD から Prefab 自動生成ツール」として 1 行だけ紹介されているものを、この記事では取り上げます。
作ったのは、Photoshop の PSD ファイルを渡すと Unity の uGUI Prefab を組み上げてくれる、Claude Code のスキルです。この記事では、その構成と、実際に使えるようにするために行ったことを書きたいと思います。
想定読者は、デザインから Prefab を構築しているデザイナ・エンジニアの方です。スキルの構造も解説するので、AI エージェントを構築したいと考えている方にも読んでいただけると思います。Prefab / RectTransform / LayoutGroup / アンカーといった uGUI の用語は前提として使います。
この記事で扱う範囲は、静的な画面レイアウトの組み立てまでです。実行時の挙動、アニメーション、パフォーマンスチューニングは扱いません。
Prefab 作成が抱えていた課題
弊社では、画面の Prefab をデザイナが構築しています。 デザインを作った本人がそのまま Unity 上で組むので、意図が正確に反映されるという良さがあります。一方で、ここには構造的な難しさがありました。
Prefab を組むには Unity の知識が要ります。 どこを LayoutGroup にするか、アンカーをどの基準に置くか、共通のパーツをどう使うか。デザインの技能とは別の知識で、これを全員が均等に持っているわけではありません。
チームの暗黙知が漏れます。 「このテキストは共通のコンポーネントを使う」「この色はプリセットで切り替える」といった約束は、ドキュメントに全部は書かれていません。知っている人には自明で、知らない人には見えない。結果として、レビューで指摘されて直す、という往復が発生します。
命名やヒエラルキー構造が人によって変わります。 同じような画面でも、組む人が違えば構造が変わる。これが一番効いてきます。構造がバラバラだと、後から触る人がまず「この Prefab はどういう作りなのか」を読み解くところから始めることになります。
そして最近になって、もう一つの問題が見えてきました。AI に Prefab を読ませようとしても、オブジェクトから意図が分からない場合があるのです。名前が Image (1) で、階層がフラットに並んでいる Prefab を渡されても、AI は「これはリストなのか、たまたま並んでいるだけなのか」を判断できません。人間が読みにくい構造は、AI にとっても読みにくい。Prefab の構造は、もはや人間だけの問題ではなくなっています。
何を作ったのか
PSD を渡すと、実用的な Prefab を作成するスキルです。Claude Code のスキルとして実装しました。中身にはプロジェクト固有の知見が詰まっているため、そのものを公開することはできませんが、構成と考え方はこの記事で書ける範囲で説明します。
「実用的」の定義は、今回は以下にしました。
- 共通の nested prefab が使われていること。 ボタンやテキストは、その場で新しく作るのではなく、プロジェクトの共通パーツを差し込む。
- ヒエラルキー構造から UI の意図が分かること。 どこからどこまでが 1 つの塊で、どれが並ぶものなのかが、構造を見れば読み取れる。
- LayoutGroup やアンカーが適切にセットされていること。 iPhone と iPad のような解像度違いでも破綻しない。
言い換えると、Unity の知識と、前章の暗黙知が入っているかどうかです。見た目が同じでも、そこが入っていないと実機で破綻します。
全体の流れは次のようになります。
人間が渡すのは、最初に PSD のパスと実装範囲を伝える 1 回だけです。あとは PSD と一致するまで、AI が自分で作っては確認して直す、というループを回します。
以下、これを成立させるために工夫した点を 4 つ書きます。
工夫 1：ヒエラルキーの組み立てを AI に任せる
Unity には純正の 2D PSD Importer があり、PSD を取り込んで Prefab を生成できます。ただし、生成される Prefab のヒエラルキーは、PSD のレイヤー構成がそのまま反映されたものになります。
これは当然の挙動なのですが、困ったことに PSD のレイヤー構成は、UI の構造とは別物です。デザイナが Photoshop で作業しやすいようにレイヤーを分けた結果と、Unity で画面として成立する構造は、一致しません。レイヤーの分け方は描画の都合で決まりますが、Prefab の構造は「どれが塊で、どれが並ぶか」という UI の都合で決まるからです。
並んでいる要素そのものは、左右で同じです。違うのは 構造が意味を持っているかどうかだけです。
そこで、ここを AI に任せることにしました。取り込んだ結果をそのまま使うのではなく、レイヤーの名前・位置・重なりから UI としての意図を読み取らせ、構造を組み替えさせます。 「この 3 つは同じ幅で等間隔に並んでいるから、リストとして LayoutGroup にまとめる」「この矩形は他の要素を囲んでいるから、親にして背景にする」といった判断です。
面白いのは、これが人間がやっていた判断とまったく同じだという点です。デザイナが Prefab を組むときも、頭の中で同じ変換をしています。ただそれが暗黙知だったので、人によって結果が変わっていた。AI にやらせるということは、その変換ルールを明文化するということでもあります。
工夫 2：eval で、AI が Unity Editor 上の Prefab を直接扱えるようにする
構造を決められても、それを Unity 上で組み立てられなければ意味がありません。ここで使ったのが eval です。
eval とは、任意の C# コードを、起動中の Unity Editor のプロセス内で実行する機構です。今回使ったのは UniCli という OSS の CLI です（MIT ライセンス）。
これがあると、コマンドラインから Prefab を操作できます。 つまり、AI が Unity Editor を直接触って、自分で Prefab を作れるようになります。あらかじめ用意された操作しかできない、という制約が無いのが効きます。前章のように構造を組み替えるにしても、決められた手順をなぞるのではなく、その画面に合わせた操作をその場で組み立てられます。
なお、この構成は UniCli 固有ではありません。 eval 相当の機構、つまり「任意の C# を起動中の Editor 内で実行できる」経路さえあれば、同じ設計が成立します。uloop-cli や Unity 操作系の MCP でも同様のはずです（ただし本記事で実際に検証したのは UniCli のみです）。
工夫 3：Canvas を RenderTexture で撮り、ループを回す
AI が Prefab を組めるようになっても、一発で正解が出るわけではありません。位置がずれる、スプライトを取り違える、スケールが合わない。作ったものを確認して直すという工程が要ります。
ここを人間がやると、結局これまでと同じです。そこで、AI に自分の出力を見せて、自分で採点させることにしました。
そのためにはスクリーンショットが必要ですが、撮れれば何でもいいわけではありません。 Unity の標準的なキャプチャ機能は Play Mode を要求しますし、撮れるのは Editor ウィンドウ全体です。ヒエラルキーやインスペクタが写り込んだ絵を見せても、AI は「PSD と一致しているか」を判定できません。
そこで、一時的な Camera と RenderTexture（描画結果をテクスチャに書き出す仕組み）を作る方式にしました。対象の Canvas だけを描画して PNG に落とします。 Edit Mode のまま撮れて、撮ったら即座に破棄するので非破壊です。
これで、AI のループが回るようになりました。 「作る → 撮る → PSD と見比べる → 直す」を、PSD と一致するまで AI が自分で繰り返します。
工夫 4：チームの暗黙知をスキルのリファレンスに貯める
ここが一番重要な工夫です。
ループが回るようになっても、出てくる Prefab はまだ「実用的」ではありませんでした。足りなかったのは AI の能力ではなく、このプロジェクトではどう組むのが正解なのかという情報です。冒頭に書いた、あの暗黙知です。
そこで、使ってみて出てきた知見を、その都度スキルのリファレンスに書き足していきました。 いくつか例を挙げます。
日本語が □□□（豆腐）になる。 素の TextMeshPro を置くと、日本語フォントの設定が付きません。プロジェクトには日本語フォント設定済みの共通テキスト用 Prefab があるので、それを差し込むのが正解です。これは「知っていれば 5 秒、知らなければ 30 分」の類の知識でした。
文字色が変わらない。 色を直接書き込んでも反映されません。プリセットを適用するコンポーネントが動いていて、こちらが書いた色を上書きし続けるからです。プリセット切替の API を呼ぶ以外に方法がありません。ドキュメントを読んで分かるものではなく、実際に上書きされて初めて気づく知識です。
Prefab では正しいのに実機で崩れる。 これが一番厄介でした。原因はアンカー基準のズレです。画面は実行時に親コンテナへ引き伸ばして配置されるため、コンテナの高さが編集時の想定と違うと要素がずれます。ここは画面の作りによって置き方が変わるので、プロジェクトでのアンカーの決め方をルールとして渡すことで、ルールに沿ってアンカーを設定できるようになりました。あわせて「複数の画面比率でスクリーンショットを撮って確認する」ことも書き足しています。iPhone と iPad の両対応は、ここで効いてきます。
こうした知見が積み上がるほど、出てくる Prefab は実用的なものに近づいていきました。逆に言えば、書き足す前は使えませんでした。 AI に任せれば最初から良いものが出てくる、ということはありません。チームが持っている知識を渡した分だけ、出力がチームの水準に近づく、というだけです。
そしてこれは、暗黙知を書き下す作業そのものでもありました。「なんとなくこうしている」を、AI に伝えるために言葉にする。結果として、人間が読んでも役に立つドキュメントが残りました。
この方法が向く場面・向かない場面
正直なところ、万能ではありません。
- 演出を含む特殊な画面や、場合分けが必要な UI では、ルールを明確に教えないと良い動作はしません。 定型的な画面ほどうまくいきますが、その画面固有の事情があるなら、それも渡す必要があります。
- スクリーンショット判定は「見た目が合っているか」しか見ません。 実行時の挙動やパフォーマンスは、別途担保する必要があります。
- デザイン側のレイヤー構成に一定の規約が要ります。 毎回バラバラだと、AI 以前にレイヤーの整理から始めることになります。
まとめ
PSD から Prefab を作るという作業は、絵を配置する部分よりも、意味のある構造に組み立てる部分にこそ人間の知識が必要でした。そこは暗黙知だったので、人によって結果が変わり、AI にも読み取れない Prefab が生まれていました。
このスキルでやったことは、その暗黙知を書き足せる形で外に置いたことに尽きます。AI が Editor を直接触れるようにして、自分で撮って自分で採点できるようにして、あとは「このプロジェクトではこう組む」というルールを足していく。ルールを足した分だけ、出てくる Prefab は実用的になりました。
そして、この形にしておくと面白いことが起きます。 ルールの実体は Markdown で書かれた文章なので、変えるのに Unity の内部も C# も触る必要がありません。実際、いまこのスキルを拡張しているのは私ではなく、デザイナ本人です。Photoshop の側から、レイヤーに「ここは並ぶものです」「ここは自分でも判断がつかないので確認してください」といった意図を書き添えられるようにしていて、それがそのまま AI への指示として届くようになっています。
知見を追加できる機構を作り、当事者であるデザイナの方に一次情報をフィードバックしてもらう。 そうすることで、作った人の手を離れても自立して成長が続けられるスキルになりました。ここまで来て、ようやく「作ってよかった」と思えるものになったと感じています。
参考
- 2D PSD Importer — Unity 公式ドキュメント
- UniCli — ターミナルから Unity Editor を操作する CLI（MIT）
- 社内ハッカソンレポート
図はすべて架空の画面例をもとにした模式図です。実際の開発画面ではありません。