Figma / PSD 引き継ぎチェックリスト：ゲームUIデザインが手戻りを避ける方法

エンジニアがUIをやり直すとき、その半分は見た目の問題ではありません。引き継ぎがエンジンの要件を満たしていないことが原因です。FigmaやPhotoshopでフレームを修正しても、エンジニアはスライスをやり直し、Canvasを再構築し、アンカーを再調整しなければなりません。スケジュールは延び、しかもそれはどのAI画像ツールを使ったかとは無関係です。

以下は、Figma export Unity、PSD import Unity UI、game UI slicing、イベントのリスキン、多言語UIといった関心の高いシナリオをカバーする引き継ぎ前チェックリストです。最後のセクションでは「PNGだけ」と構造化書き出しのギャップを説明します。ツールはあくまで参考であり、特定製品の宣伝ではありません。

---

エンジニアが実際に必要としているもの

必要なもの	そうではないもの
名前付きの階層（ボタン、パネル、リスト項目）	全画面のJPG1枚
ボタンの normal / pressed / disabled	「クリックできそうに見える」画像1枚
差し替え可能なテキストレイヤー	すべて表示用テキストとしてラスタライズ
相対位置とアンカーの意味付け	レイアウト参考画像＋バラバラのPNG20枚
再利用可能なプレハブ構造	イベントごとにゼロから再構築

一行の合格基準：Unity UGUI / Godot Control / Cocos UI にインポートした後、文言の変更やリスキンでツリー全体を再構築する必要がないこと。

---

引き継ぎ前の12項目チェック

構造と命名

#	チェック項目	補足
1	意味のあるFrame / グループ名	Panel_Shop、Btn_Buy——Group 12は不可
2	インタラクティブ層と装飾層の分離	背景、枠、アイコン、テキスト
3	リスト項目を再利用可能なグループに	List_Itemを複製できる
4	下書きや不要なFrameを非表示に	書き出しのノイズを減らす

状態と仕様

#	チェック項目	補足
5	ボタンの全状態	normal / pressed / disabled（またはチームの命名規則）
6	9スライス / 伸縮領域の指定	パネルや入力欄はハードスケールすべきでない
7	目標解像度とセーフエリア	縦持ちモバイル：ノッチと下部バー
8	フォント戦略	ローカライズ用はテキストレイヤー、表示用テキストは別途明記

ライブ運用とローカライズ

#	チェック項目	補足
9	文言の長さの余裕	ドイツ語 / スペイン語は英語より30%以上長くなることが多い
10	リスキン＝見た目のみ	イベントスキン：同じレイアウト、新しいアートと色
11	ローカライズ：文言とレイアウト	理想は同じ構造で複数の言語ファイル
12	書き出し形式の文書化	レイヤー付きPSD / Figmaリンク、または合意したスライス命名

Figmaの準備：Figma → Unity ワークフロー。PSDの準備：PSDを5分でUnity UIにインポート。

---

3つの引き継ぎパス（客観的な比較）

パス	アプローチ	向いているケース	課題
A. 手動スライス	PNG＋レイアウトのスクリーンショットを書き出し、エンジニアが手作業で構築	最小限のUI、単発のデモ	修正のたびにスライスと再構築
B. エンジンプラグイン	Figma Converter、Psd-Exporter など	仕様が固定されたチーム	複数エンジンでは作り直しになりがち、プラグインの品質にばらつき
C. 構造化キャンバス	レイヤーファイル → ゲームキャンバス → その場で分割 → プレハブ書き出し	多画面UI、頻繁なリスキン / グローバル展開	ゲーム向けの書き出しフローを採用する必要がある

パスCはVberAI Studioのような製品で一般的です：PSD / Figmaを解析 → レイアウトを保ったUI分割 → Unity / Godot / Cocosへ書き出し（ゲームUIをエンジンに分割を参照）。デザイナーは引き続きFigmaで作業でき、承認後は修正のたびに手動でPNGを20枚書き出すのではなく、構造化書き出しを使います。

---

デザイナーのよくあるシナリオ

ゲームUIのスライス / その場での分割

全画面のコンセプトがPNGだけの場合、エンジニアはボタンの境界を推測します。より安全なフローは、画面をキャンバスに配置 → コントロールをその場で分割（その場でのスライス）です。これにより位置データが分割と一緒に引き継がれ、「スライスは正しいのにエンジンで全部ずれる」を避けられます。

FigmaからUnity / Godotへの書き出し

プラグインがフラットなスプライトパックしか出力しない場合、エンジニアは依然としてRectTransform / Controlツリーを再構築します。評価する際に確認すべきは、成果物がプレハブ / 階層なのか、バラバラの画像のzipなのかという点です。Godotの比較：Figma → Godot 手動 vs AIワークフロー。

ゲームUIのリスキン（季節 / イベント）

ハロウィン、クリスマスなど：同じレイアウト、新しいテーマ素材。リスキンのたびにスライスと再構築が必要なら、ライブ運用のペースが落ちます。リスキンツールはノード構造を変えないものであるべきです（UIリスキンとテーマバリアント）。

ゲームUIの翻訳 / Figma多言語

グローバル展開の落とし穴：翻訳された文言がレイアウトからはみ出します。理想的なフローは、文字列だけを差し替え、Frameを再フローしないことです（ワンクリックUI翻訳）。Figmaでは、余裕を持たせるために最小/最大幅を設定したAuto Layoutを使います。

アイコンと半透明素材

スキルアイコンやVFX UIは、インポート前に背景除去が必要なことがよくあります（髪、透明、グロー）。汎用のマッティングはエッジをぼかしますが、ゲーム向けツールはアルファを重視します（グロー / VFXマッティング）。その後、キャンバスかエンジンに戻します。

---

AI画像ツールとの関係

Midjourney、Jimeng、GPT Image 2などはビジュアルの方向性には優れていますが、行き先がエンジンなら分割と階層が依然として必要です。よくある組み合わせ：

AI全画面UIコンセプト → デザイナーがFigmaでレイヤーを整理 → エンジンへ構造化書き出し

「ポスター級の単一画像」を最終的な引き継ぎ物として扱わないでください。ツール比較：AIゲームデザインアート生成ツール。

---

FAQ

PNGだけを引き継いでもよいですか？ デモなら問題ありませんが、製品UIは何度もやり直しになります。最低限、レイアウトのメモと命名規則を添付してください。

FigmaのAuto Layoutは完璧でなければなりませんか？ Web並みに完璧である必要はありませんが、グループ化と命名はピクセルの微調整より重要です。

エンジニアが言う「スライスが違う」とはどういう意味ですか？ 多くの場合、状態の欠落、誤った9スライス、ヒットエリア≠見た目、またはバラバラの画像で相対位置が失われている、という意味です。

リスキンとUIの作り直しの違いは？ リスキン：同じ構造で新しい見た目。作り直し：階層も変わる。ライブ運用はリスキンの道にとどめるべきです。

デザイナーはUnityを学ぶ必要がありますか？ スクリプトは不要ですが、Canvas / Anchor / Prefabの基本を知っておくとコミュニケーションコストが大幅に下がります。

VberAI StudioはGoogle AI Studioと同じですか？ いいえ。前者はゲームキャンバスとエンジン書き出し、後者はGoogleの汎用AI開発環境です。比較を参照してください。