VberAI 比較
ゲームエンジン・デザインツール・AI エディタ・Google AI Studio との位置づけ
VberAI は Unity、Godot、Cocos Creator、Figma、Cursor、Google AI Studio の置き換えではなく、ゲーム制作ツールをつなぐ AI ネイティブ層です。以下はワークフロー別の比較と、VberAI Studio と Google AI Studio の違いです。
AI ゲーム開発ブログ · MCP / VberAI 用語集
VberAI vs ゲームエンジン
Unity・Godot・Cocos Creator はランタイムとエディタに強み。VberAI は AI 接続、デザイン→エンジン、素材準備を補完し、UI・シーンの反復作業を減らします。
| 比較軸 | VberAI | Unity / Godot / Cocos Creator |
|---|---|---|
| AI ↔ エンジン接続 | Engine MCP がライブシーン・ノード・プレハブを Cursor / Claude / Windsurf 等に公開。Unity / Godot / Cocos 2.x/3.x 対応。 | エンジンは API とエディタを提供；AI 連携は断片化しがちで、プロジェクト横断の共通プロトコルは稀。 |
| UI・画面制作 | AI Studio が PSD/Figma を取り込み、エンジン向け UI 階層・シーン・プレハブを書き出し。 | エディタ内の手作業またはフラット書き出しからの再構築が主流。 |
| 素材準備（切り抜き） | AI スーパー切り抜きがブラウザで髪の毛・ハロー・半透明を処理し、Studio→エンジンへ。 | 外部 DCC や汎用 cutout；複雑な縁は手直しが必要なことが多い。 |
| デザイン ↔ エンジン同期 | キャンバスとプロジェクトの双方向同期、コンポーネント化、プレハブ指向の反復更新。 | PNG/仕様の一方向引き渡しが多く、後からのデザイン変更はプレハブに自動反映されにくい。 |
| クロスエンジン・ツールチェーン | Unity / Godot / Cocos いずれでも MCP + AI Studio + 切り抜きの同じ考え方。 | エンジンごとに UI 体系とプラグインが異なり、パイプラインが重複しがち。 |
| 効率が上がる領域 | デザイン解析・素材準備・エディタ自動化を前倒しし、ゲームプレイ実装に集中。 | レンダリング・配信は強力；UI 骨組みとシーンのルーティン作業は依然ボトルネック。 |
VberAI vs デザインツール
Figma / Photoshop はビジュアル探索の標準。VberAI はゲーム向けレイヤーとして構造化インポート、対話的 UI 編集、切り抜き、エンジンへの損失の少ない配信と継続同期を追加します。
| 比較軸 | VberAI | Figma / Photoshop |
|---|---|---|
| 構造化デザインインポート | PSD/Figma のレイヤーをゲームキャンバスにマッピング（Canvas / Control / prefab ノード）。 | モックアップに優れるが、プレハブ階層や nine-slice は第一級の書き出し対象ではない。 |
| 対話的 UI 反復 | AI Studio でチャットによりレイアウト・リネーム・グループ化を意図レベルで変更。 | レイヤーの手作業；ライブエンジンシーンや MCP 一括修正とのネイティブ連携なし。 |
| 切り抜き・背景除去 | ゲーム素材向け AI スーパー切り抜きを UI 制作と同一ワークフローに統合。 | 別プラグインや remove.bg；エンジン投入前のクリーンアップが必要なことが多い。 |
| エンジン向けデリバリー | 階層を保持したシーン・プレハブ・バンドルを Unity / Godot / Cocos へ。 | ラスター切片やトークンが中心；RectTransform 等はエンジン側で再構築。 |
| 継続的イテレーション | キャンバス更新後にエンジンへ re-sync；Engine MCP で配線・検証・一括修正。 | 再エクスポートと手動統合のサイクル；Figma と本番 UI の乖離が起きやすい。 |
| デザイン ↔ エンジニアリング | エンジン連携構造をアートとプログラムが共有；スクリーンショット仕様の往復を削減。 | レッドラインとアセットドロップによる引き渡し。 |
VberAI vs AI コードエディタ
Cursor、Claude Code、Codex、Windsurf はリポジトリとターミナルに強い。Engine MCP は同じクライアントに実行中エディタへの read/write を与え、「ファイル編集」と「シーン編集」のギャップを埋めます。
| 比較軸 | VberAI | Cursor / Claude Code / Codex / Windsurf |
|---|---|---|
| エンジン状態の認識 | MCP が Unity / Godot / Cocos のライブツリー・選択・コンポーネントを返す（ディスク推測ではない）。 | デフォルトはリポジトリ；未保存シーン・選択・Play モードは見えない。 |
| エディタ内オペレーション | MCP 経由でノード作成・コンポーネント・シグナル・階層バッチを開いているエディタ内で実行。 | コード生成は可能だが、シーングラフ / Inspector を直接操作できない。 |
| プレビューとフィードバック | 変更が即 viewport に反映；実ランタイムでレイアウトと参照を検証。 | compile → run → inspect；UI 修正の成否は実行まで分からない。 |
| マルチエンジン MCP | Unity / Godot / Cocos 2.x/3.x 向け統一 MCP インターフェース。 | ゲームエディタ向けのクロスエンジン first-party MCP はない。 |
| デザイン + コードの一体ループ | AI Studio（PSD/Figma→prefab）と Engine MCP（インポート後）を同一 AI クライアントから。 | アプリコードに強い；UI インポート・切り抜き・prefab 作業は別ツール。 |
| ゲーム領域への拡張 | UI/レベル反復、ライブオプス prefab バッチ、シーン整備など file-only AI の外側。 | 汎用 SWE に最適；ノードグラフとエンジンアセット DB はスコープ外。 |
VberAI Studio vs Google AI Studio
「AI Studio」は混同されやすい名称です。Google AI Studio は Gemini と汎用プロトタイプ向けのクラウド Playground。VberAI Studio はゲームアセット用キャンバス（PSD/Figma、UI 翻訳/換装/スライス、エンジン書き出し）で Engine MCP と連携します。役割が異なり、代替関係ではありません。
| 比較軸 | VberAI Studio | Google AI Studio |
|---|---|---|
| 位置づけ | VberAI Studio：ゲーム UI/アート用キャンバス。構造化インポート、対話編集、翻訳/換装/スライス、Unity / Godot / Cocos 階層への書き出し。 | ブラウザの Gemini Playground + Build。汎用アプリ/プロトタイプ向け — アイデアと Web デモ向きで、エンジンネイティブ UI 納品は担わない。 |
| 実行形態 | クラウドキャンバス + 任意のローカル Engine MCP。成果物は既存のエンジンプロジェクトに入ります。 | 純クラウド Web、ゼロインストール — 起動は最速。ローカルのエンジンリポジトリとの結合は弱い。 |
| ゲーム UI / アセット | レイヤー付き PSD/Figma、ワンクリック翻訳/換装、インプレース・スライス、プレハブ/シーン向け書き出しでレイアウトを維持。 | 画像・コピー・Web UI を生成可能。RectTransform、アンカー、プレハブ、エンジン資産は手作業で再構築。 |
| エンジン連携 | Engine MCP と連携し、Studio 書き出し後も同じ AI クライアントでシーン・ノード・スクリプトを編集。 | Unity / Godot / Cocos を直接駆動しない。Web プロトタイプから量産への移行は再構築になりやすい。 |
| モデルとクライアント | アセットは Studio、編集器自動化は MCP クライアント（Cursor、Claude Code など）でモデル選択 — 単一の Google チャットに固定されない。 | Gemini / Google コンテンツモデルと aistudio.google.com に紐づく。 |
| 向いている用途 | すでに Unity / Godot / Cocos を使うチーム：デザイン→エンジン、イベント換装、多言語モック、エディタ内 AI。 | Jam、コンセプト検証、HTML5 / vibe coding デモ、エンジンパイプライン前の汎用マルチモーダル実験。 |