FigmaからGodotへ：手動ワークフローとAI Studioを使ったAIワークフローの比較

なぜFigma→Godotはまだほとんどのチームにとって手動に感じられるのか

インディーや中規模のGodotプロジェクトでは、HUD、メニュー、ショップ画面をFigmaでデザインし、その後エディターでControlノード（MarginContainer、VBoxContainer、TextureRect、Label、Button、テーマリソース）を使って同じレイアウトを再構築することがよくあります。

問題はFigmaがPNGをエクスポートできるかどうかではありません。問題はレイアウトを誰が所有するかです。デザイナーがFigmaのフレームで所有するのか、それともエンジニアがアンカーやコンテナをピクセル単位で再作成するのか。

この比較では2つのパスを扱います：

1. 手動ワークフロー — アセットをエクスポートし、Godotにインポートし、UIを手動で再構築
2. AIワークフロー — VberAI AI Studio（略称：AI Studio）を使用してFigmaの構造をエンジン対応の階層に変換し、必要に応じてGodot MCPで反復

画面ごとに適切なアプローチを選択するために活用してください。すべてのパネルに同じパイプラインが必要なわけではありません。

Figma→Godot画面における「完了」の意味

スプライトが表示されただけでは画面は完了しません。必要なもの：

• 意味のあるFigmaフレーム（ヘッダー、リスト、フッター）を反映したノードツリー
• 16:9、9:16、ウィンドウモードのデスクトップでも、すべてのスペーサーを手動調整せずに耐えられるレイアウト
• デザインシステムに近いフォントとテーマトークン
• シーン全体を書き直さずにFigmaの修正を取り込む方法

両方のワークフローで「完了」に到達できます。違いは最初のプレイ可能なUIまでの時間と次のデザイン修正のコストです。

手動ワークフロー：エクスポート、インポート、再構築

典型的な手順

1. Figmaでエクスポート可能な要素（アイコン、ナインスライスパネル、全画面背景）をマーク
2. 1xまたは2xでPNG/SVGをエクスポート；チーム用にスケールを文書化
3. アセットをres://ui/（またはArtフォルダの規約）にドロップ
4. CanvasLayerまたはビューポートUIシーンの下にControlルートを構築
5. HBoxContainer / VBoxContainer / GridContainerをFigmaの間隔に合うまでネスト
6. Themeフォント、色、StyleBoxを割り当て；GDScriptまたはC#でボタンシグナルを配線

手動がまだ勝る状況

状況	手動構築が役立つ理由
一回限りのプロトタイプ画面	チームに新しいツールを教えるより速い
ランタイムUIが重い（ライブデータバインディングのあるインベントリなど）	構造はほとんどコードが所有
厳格なStyleBox / テーマ作成基準	デザイナーはピクセルをエクスポート；エンジニアがテーマを所有
小さなUIサーフェス（ポーズオーバーレイのみ）	パイプラインのオーバーヘッドが報われない可能性

チームが過小評価しがちな実際のコスト

• レイアウト再調整の負担 — Figmaのオートレイアウト≠Godotのコンテナ；ネストされたフレームごとに判断が必要
• フォントのずれ — FigmaのInter≠DynamicFont / Themeフォント；行間やカーニングがQAを驚かせる
• ナインスライスのミス — ボタンの伸縮シームが週の途中で再スライスされるまで気づかれない
• 修正ループ — デザイナーがフッターを12px移動；エンジニアがツリーの半分を再デプロイ

中程度の複雑さのメインメニューでは、多くのチームがクリーンなFigmaフレームからスモークテスト済みのGodotシーンまで、シグナル配線とローカライゼーションの前に45〜120分を費やしています。

AI Studioを使ったAIワークフロー：構造を認識したインポート

典型的な手順

1. Figmaを準備：フレームに明確な名前を付ける（HUD_Root、Btn_Play、Panel_Shop）、匿名のFrame 128は避ける
2. VberAIでAI Studioを開く（VberAI AI Studio）
3. Figmaフレームをインポート（またはStudioパイプラインが受け入れるエクスポートパッケージ）
4. Studioキャンバスでレイヤーをプレビュー；スクラッチフレームを非表示にし、デコイをマージ
5. ターゲットエンジンをGodotに設定、出力をControl階層 / シーン対応ノードに（スプライトのみのダンプではない）
6. Godotプロジェクトにエクスポート；生成されたシーンを開き、UIルートの下にアタッチ
7. アスペクト比をスモークテスト；テーマフォントとシグナルをエンジン内でパッチ

AI Studioはフレーム階層を保持するため、フラットなアトラスを逆解析してコンテナにする必要がありません。

AIパスが勝る状況

状況	AI Studioが役立つ理由
マルチ画面UIキット（設定、ショップ、ポーズ、HUD）	命名＋構造転送がセットアップを償却
リモートデザイナーからの頻繁なFigma修正	再インポートがボックスを何時間もやり直すより勝る
すでにVberAIをGodot MCPに使用しているチーム	同じスタック：デザイン入力、エディターエージェント後処理
ジュニアメンバーをUIシーンにオンボーディング	生成されたツリーは教えられるベースライン

オプションの次のステップ：Godot MCPを使用して、インポート後にCursorやClaudeにノードの名前変更、pressedシグナルのバインド、テクスチャの交換を依頼できます。特にFigmaレイヤーの名前が不十分だった場合に有効です。

比較表

次元	手動	AI Studio → Godot
最初のプレイ可能なレイアウトまでの時間	画面あたり45〜120分以上	Figmaが整っていれば多くの場合数分
ネストの忠実度	エンジニアの規律に依存	準備すれば名前付きフレームを反映
テーマ / StyleBoxの制御	最高（すべてを自分で作成）	エンジンでの軽い調整後は強力
修正コスト（レイアウト変更）	高い	再インポートにより低い
修正コスト（色/アイコンのみ）	低〜中	多くの場合再インポートせずにGodotでパッチ
ツールのオーバーヘッド	Figma + Godot以外なし	VberAIアカウント + AI Studioの習慣
最適な用途	スパースなUI、プロトタイプ、コード主体のUX	繰り返し発生するメニュー/HUDパイプライン

どちらのパスもエンジンでの調整を不要にするわけではありません。ボタンにはシグナルが必要ですし、ローカライゼーションには文字列キーが必要ですし、Godotテーマには調整が必要です。違いは、レイアウトの再作成にエンジニアリング時間を費やすか、それとも配線とフィーリングに費やすかです。

ほとんどのプロダクションチームが好むハイブリッドパターン

1. AI Studioをシェル画面（メインメニュー、設定の枠組み、ショップのシェル）に使用
2. インベントリやクエストから供給される動的リストには手動またはスクリプト駆動のUIを維持
3. レイアウトの枠組みについてはFigmaを信頼できる情報源とし、動作についてはGodotを信頼できる情報源とする
4. フレームが再構築されたら再インポート；マイクロビジュアルはGodotでパッチ

Figmaの変更	推奨
新しいタブ行 / 列の再フロー	AI Studioで再インポート
アイコン交換、ボタンの色合い	Godotでシーン/テーマをパッチ
新しい画面アートボード	新規インポート → 新しい.tscn
コピー / ロケール文字列	Godot + 翻訳ファイル

VberAIスタックとの統合方法

• VberAI AI Studio — Figma / PSD → Godot Control構造（タイトルや見出しではAI Studioと表記）
• Godot MCP — インポート後のエディター自動化（ノード名変更、シグナルフック、シーンチェック）
• AI Super Matting — アイコンレイヤーのクリーンなアルファをTextureRectアセットになる前に処理

これらが連携することで、アーティストをFigmaから引き離すことなく、デザインからプレイ可能なループを閉じます。

結論：どのワークフローを選ぶべきか？

手動を選ぶのは、小さな画面が1つだけの場合、コード主体のUXが重い場合、または共有インポート習慣に対する意欲がゼロの場合です。

AI Studioを選ぶのは、FigmaがすでにマルチフレームUIキットを保持している場合、デザイナーが毎週反復している場合、チームがPNGフォルダではなくフレーム名に一致するGodotシーンを必要としている場合です。

成長中のほとんどのGodotチームはハイブリッドに落ち着きます：AI Studioで枠組みを、ライブデータビューには手作業を。

1つの画面で両方を時間測定してみませんか？VberAI AI Studioを開き、名前付きのFigmaメニューフレームをインポートし、Godot Control階層をエクスポートして、最後の手動再構築と時間を比較してください。