Cocos Creator AI アート素材整理実践：生成からインポートまでの完全ワークフロー

頭の中には無数のかっこいいキャラクター、シーン、小道具がある。でも予算と時間は、1 キャラのラフを描くのがやっと——そんな経験、ありませんか。アートリソースという、クリエイティブと完成品の間の巨大な溝のせいで、ゲームのアイデアが企画書のまま終わってしまうことも珍しくありません。

従来のフローでは、2D キャラクター 1 体を設計から使える状態までに、数千元のコストと数週間の期間がかかります。今は AI ツールで 10 分あれば、キャラクター生成、リギング、スキニング、アクションまで完了。コストは従来の 1/10 程度まで下がりました。しかし問題はここから——AI 生成素材を Cocos Creator で使えるリソースにどう変えるか。インポート後にディレクトリが散らかり、保守が地獄になり、Draw Call 過多でゲームがカクつく——これらの落とし穴、私も全部踏みました。

この記事では、AI でアート素材を生成するところから始め、Cocos Creator のリソースディレクトリ標準構造、命名規則、アトラス作成、パフォーマンスチューニングまで、完全フローを分解して解説します。読み終える頃には、コンセプトからエンジンで使える状態まで、再現可能な道筋が見えてくるはずです。

Cocos Creator リソースディレクトリ構造の基礎

Cocos Creator プロジェクトを開くと、assets、library、local、settings、temp など複数のフォルダが見えます。どれが「リソースライブラリ」なのか——迷いますよね。

答えは 1 つだけ。assets です。

assets ディレクトリだけが、エディタのリソースマネージャーに表示されます。画像、アニメーション、プレハブ、スクリプト——すべてここに置きます。他のフォルダ——library はキャッシュ、local はローカル設定、settings はプロジェクト設定、temp は一時ファイル——は触らなくて大丈夫。不用意に削除もしないでください。

meta ファイル：各リソースの「ID カード」

assets ディレクトリには、少し面倒なものがあります。各ファイルの横に必ず .meta ファイルが付くこと。knight.png があれば、隣に knight.png.meta があります。

meta ファイルは Cocos Creator がリソースを管理する中核メカニズムです。リソースの UUID（一意識別子）、バージョン情報、サブリソース情報を記録しています。meta を削除すると、エンジンはそのリソースを見つけられません。ファイル名変更や移動時も meta を同期しないと、参照がすべて切れます。

初めてプロジェクトを作ったとき、meta ファイルが散らかって見えて一気に全部削除しました。結果？プロジェクト全滅。すべてのリソース参照が「Missing」に——教訓は深く刻まれています。

resources ディレクトリ：動的ロード専用の特殊チャネル

assets 配下には特殊なサブディレクトリ resources があります。ここに置いたリソースは、コードから動的ロードできます。

resources.load('sprite-frames/background', cc.SpriteFrame, (err, spriteFrame) => {
    // 動的ロードした SpriteFrame
});

ただし resources には落とし穴があります。ビルド時に、このディレクトリ内のすべてのリソースがパッケージングされます。使っていなくてもです。だから、すべてを resources に入れないでください。多言語切り替えのテキスト、プレイヤーの進行度に応じて解放するシーンなど、本当に動的ロードが必要なものだけに限定しましょう。

避けるべき落とし穴

よくあるミス：

• project.json を手動編集——エディタが自動管理するファイル。手を入れると問題が起きます
• library フォルダを削除——再オープン時に再構築されますが、大規模プロジェクトでは数分かかることも
• すべてのリソースを resources に詰め込む——ビルドサイズが爆発し、ロード時間が延びます
• meta ファイルの同期を無視——参照が切れ、プレハブ内の画像がすべて Missing に

AI でアート素材を生成する実践ツール

市場には AI アートツールが溢れています。どれを選ぶか——実際の使用経験から、インディー開発者向けに 3 つを推薦します。

SOON プラットフォーム：スケルトンアニメーションをワンクリック生成

SOON はゲームキャラクターアニメーション専用の AI プラットフォームです。一文で説明を入力するだけ——例えば「鎧を着たカートゥーン騎士、剣を構えた戦闘ポーズ」——キャラクター生成、リギング、スキニング、アクションまで自動で行い、Spine 形式のスケルトンアニメーションをエクスポートできます。

従来フローでは、キャラクターデザイン、リギング、スキニング、アクション設計の各段階に専門家が必要で、周期は週単位。SOON はこれを 10 分に圧縮します。新浪网の報道によると、従来フローと比べコストを 80〜90% 削減できるとのこと。

私は SOON で横スクロールアクションゲームの主人公を作りました。10 分後、36 セットのアクションアニメーションが直接エクスポート——待機、歩行、走行、ジャンプ、攻撃、被弾、死亡……どれも滑らかで自然。美術師に依頼したら、見積もりを見て心が折れたでしょう。

Holopix AI：ゲーム向け AI 描画＋スマート背景除去

Holopix AI はゲーム開発向けに設計された AI 描画ツールです。特に実用的な 2 つの機能——ワンクリック成稿とワンクリック背景除去——があります。

ワンクリック成稿：キャラクター説明を入力すると、複数スタイルの候補を生成。欧米風、二次元風、ピクセル風など、専用モデルで訓練されており、汎用 AI ツールよりゲーム向け。

ワンクリック背景除去：生成された人物には背景が付いていますが、ゲームでは透過背景のスプライトが必要。Holopix AI の背景除去はワンクリックで完了。エッジもきれいで、PS で手作業する必要なし。美術が苦手なプログラマーにとっては救いです。

Anything XL：ローカルデプロイの SDXL

Anything XL（万象熔炉）は、ローカルにデプロイする Stable Diffusion XL ツールです。メリットは、プライバシーリスクがなく、使用回数制限もないこと。

プロジェクトに機密性があり、アートのアイデアをクラウドにアップロードしたくない場合、Anything XL は有力な選択肢。デプロイは少し手間がかかり GPU が必要ですが、完了後は生成速度が安定し、素材品質もコントロールしやすい。

ツール比較と選び方

ツール	機能	コスト	適用シーン
SOON	スケルトンアニメーションをワンクリック生成	プロジェクト課金	キャラクターアニメーションが必要なプロジェクト
Holopix AI	ゲーム向け描画＋スマート背景除去	無料基本機能＋有料上位	透過背景スプライトが必要
Anything XL	ローカル SDXL デプロイ	ハードウェアコスト＋無料利用	機密性が求められるプロジェクト

私の選び方：キャラクターアニメーションは SOON、静的スプライトは Holopix AI、機密素材は Anything XL。3 ツールを組み合わせれば、ほとんどのアート需要をカバーできます。

AI 生成から Cocos インポートまでの完全フロー

AI 生成素材ができたら、次はエンジンで使えるリソースに変える段階。ここが落とし穴最多区間です。順を追って分解します。

形式変換と背景処理

AI 生成画像は通常、背景付きです。ゲームでは透過背景のスプライトが必要なので、最初のステップは背景除去。

背景除去ツール：

• Transparify：Web 版。画像をアップロードしてワンクリック背景除去。エッジ処理もきれい
• SpriteCut AI：ゲームスプライト向け。キャラクター輪郭を認識し、余分な空白を自動裁切
• Holopix AI 内蔵背景除去：生成時に透過背景オプションを選択。一発で完了

処理後は PNG 形式、Alpha チャンネル付きでエクスポートすること。JPG は透過非対応——使わないでください。

アトラス作成の実践

スプライトを 1 枚ずつインポートすると、1 スプライト 1 回の Draw Call。10 スプライトで 10 回、100 スプライトで 100 回。低スペック端末では、カクつきが目に見えてわかります。

アトラス（Atlas） が解決策。複数スプライトを 1 枚の大きな画像にパッキングすれば、エンジンは 1 回の Draw Call で、そのアトラスを参照するすべてのスプライトをレンダリングできます。

TexturePacker 設定の要点：

1. TexturePacker を開き、スプライト画像を追加
2. Output 形式は cocos2d-x、plist + png をエクスポート
3. Trim Mode は trim——透過ピクセルを裁切するが、元画像のフレームサイズは変えない（crop、flush position は選ばない。アニメーションがズレます）
4. Max Size はターゲット端末に合わせて調整。一般に 2048x2048 で十分

Cocos Creator 3.0 は TexturePacker v4.x 未満の形式をサポートしません。古いバージョンを使っている場合は最新版にアップグレードしてください。

Cocos Creator へのインポート手順

TexturePacker は .plist と .png の 2 ファイルをエクスポートします。2 つセットで Cocos Creator にインポートする必要があります。

インポート方法：2 ファイルを assets ディレクトリにドラッグ＆ドロップ。リソースマネージャーに Atlas リソースが表示され、展開するとすべての SpriteFrame が見えます。

各 SpriteFrame は個別に使用可能。Sprite コンポーネントの SpriteFrame プロパティで対応フレームを選べば、そのスプライトが表示されます。

完全事例：2D 横スクロールアクションゲームのキャラクターインポート

SOON で騎士キャラクターを生成し、36 セットのアクションアニメーションがあると仮定。完全インポートフロー：

Step 1：AI 生成

• SOON プラットフォームに「鎧を着たカートゥーン騎士」と入力
• アクション種別を選択：待機、歩行、攻撃、ジャンプなど
• PNG シーケンスフレームをエクスポート（各アクション複数フレーム）

Step 2：背景除去

• PNG シーケンスフレームを Transparify にインポート
• ワンクリック背景除去、透過 PNG をエクスポート

Step 3：アトラスパッキング

• TexturePacker にすべての PNG フレームを追加
• Output 形式は cocos2d-x
• knight_atlas.plist と knight_atlas.png をエクスポート

Step 4：エンジンへインポート

• plist と png を assets/characters/hero/sprites/ にドラッグ
• meta ファイルが自動生成されるまで待つ

Step 5：シーンで使用

• Sprite ノードを作成
• SpriteFrame プロパティで knight_atlas 内の対応フレームを選択
• Animation コンポーネントでフレームアニメーションを再生し、異なるアクションを切り替え

このフローを完了すれば、騎士キャラクターがゲーム内で動き出します。36 セットすべて使え、Draw Call は 1 回だけ——同じアトラス由来だからです。

リソースディレクトリの命名規則とベストプラクティス

プロジェクトが半ばになると、assets ディレクトリがカオスに——画像、スクリプト、プレハブが混在し、命名も任意。リソース探しは骨の折れる作業。この光景、よく見ます。実プロジェクトの経験から、Cocos Creator 向けリソースディレクトリ規約を紹介します。

基本命名規則

核心原則：1 フォルダ 1 種類のファイル。

texture、prefab、animation を同じディレクトリに入れない。種別ごとに分ければ、探しやすく、保守も楽。

命名形式は Unity/Unreal の業界規約を参考に：

prefix_theme_description_suffix

例：

• char_knight_idle_a.png — キャラクター、騎士、待機、albedo（ベースカラー）
• char_knight_attack_01.png — キャラクター、騎士、攻撃、連番 01
• ui_btn_play_9slice.png — UI、ボタン、再生、9 スライス

各 suffix の意味：

• _a — albedo、ベースカラーテクスチャ
• _n — normal、法線テクスチャ
• _9 — 9slice、9 スライス画像

一見面倒に見えますが、メリットは明確。ファイル名を見れば何か、どこで使うかがわかります。チーム開発では、命名規約がコミュニケーションコストを最小化する最善の方法です。

推奨ディレクトリ構造テンプレート

リソース種別ではなく、ゲーム機能モジュールで分類。なぜか——開発中に考えるのは「キャラクターシステム」であって「すべてのテクスチャ」ではないから。

assets/
├── characters/
│   ├── hero/
│   │   ├── textures/         # キャラクターテクスチャ
│   │   ├── animations/       # アニメーションリソース
│   │   ├── sprites/          # SpriteFrame
│   │   └── prefab/           # キャラクタープレハブ
│   ├── enemies/
│   │   ├── textures/
│   │   ├── animations/
│   │   ├── sprites/
│   │   └── prefab/
│   ├── npcs/
│
├── scenes/
│   ├── level01/
│   │   ├── textures/         # シーンテクスチャ
│   │   ├── tilemaps/         # タイルマップ
│   │   ├── prefab/           # シーンプレハブ
│
├── ui/
│   ├── textures/             # UI テクスチャ
│   ├── fonts/                # フォント
│   ├── prefab/               # UI プレハブ
│
├── audio/
│   ├── effects/              # 効果音
│   ├── music/                # BGM
│
├── scripts/                  # TypeScript スクリプト
│   ├── components/           # カスタムコンポーネント
│   ├── utils/                # ユーティリティ
│
├── resources/                # 動的ロードリソース（慎重に使用）
│   ├── languages/            # 多言語テキスト
│   ├── unlock-scenes/        # 解放シーン

この構造のメリット：各モジュールが自己完結し、モジュール間の干渉なし。hero キャラクターを修正するときは characters/hero 配下だけ触ればよく、他リソースを誤って変更する心配がありません。

よくあるミスと回避策

私が踏んだ落とし穴：

落とし穴 1：ファイル混在
hero.png と hero.prefab を同じディレクトリに——後から整理地獄。分けて保管：textures に画像、prefab にプレハブ。

落とし穴 2：任意な命名
image1.png、new_picture.png、未命名.png……1 ヶ月後、自分でも何かわからない。規約に従えば、ファイル名自体がドキュメントになります。

落とし穴 3：meta ファイルを無視
リソースの改名・移動時に meta の同期を忘れる。結果：プレハブ内の参照がすべて Missing。再設定に時間と労力。

Cocos Creator には仕組みがあります。エディタ内で改名・移動すれば、meta は自動同期。すべてのリソース操作はエディタ内で——ファイルシステムを直接触らないでください。

meta ファイル管理の核心注意点

meta ファイルとリソースファイルはバインド関係。核心ルール：

1. 同名同ディレクトリ：knight.png.meta は knight.png と同じディレクトリに
2. 削除不可：meta を消すと UUID 消失、参照すべて切断
3. 手動改名不可：meta ファイル名を変えるとエンジンがリソースを見つけられない
4. エディタ内操作：改名、移動、削除——すべてエディタのリソースマネージャーで

ファイルシステム外で操作が必要な場合（一括インポートなど）、インポート後 meta ファイルの自動生成を待ち、途中で中断しない。大規模プロジェクトでは数分かかることも——辛抱強く待ちましょう。

パフォーマンスチューニング：アトラス作成と Draw Call 制御

ゲーム公開後、プレイヤーから「カクつく」「フレーム落ちする」とのフィードバック。調査すると Draw Call 120+。低スペック端末では到底耐えられません。

Draw Call とは？スプライトを 1 つレンダリングするたび、エンジンが GPU に描画命令を 1 回送ります。送信回数が多すぎると CPU-GPU 通信オーバーヘッドが爆発し、フレームレートが 30 以下に。

なぜアトラスが必要か：Draw Call の原理

直感的な例：

ゲームに UI 要素 50 個——背景、ボタン、アイコン、テキストボックス……各 UI 要素が独立 Sprite なら、エンジンは 50 回 Draw Call を送ります。

50 個すべてを 1 枚のアトラスにパッキングすれば、Draw Call は 1 回。1 回の描画命令で GPU がアトラス全体をロードし、SpriteFrame に応じて異なる領域を裁切表示。

データ比較：あるプロジェクトでは調整前 Draw Call 120+、調整後 10 以下。フレームレート 25fps から 60fps へ。低スペック端末での体験改善は目に見えてわかります。

動的アトラス（Dynamic Atlas）の仕組み

Cocos Creator には自動調整メカニズム 動的アトラス（Dynamic Atlas） があります。

原理：実行時にエンジンが散在画像を一時アトラスに自動マージ。手動パッキング不要、エンジンが代行。

制御方法：SpriteFrame に Packable プロパティ。Packable にチェックを入れると動的アトラスに参加、外すと不参加。

ただし動的アトラスには限界：

1. 32 枚未満の散在画像のみ対応。超えると無効
2. 実行時マージのオーバーヘッドあり
3. 不安定——散在画像数が変わるとアトラス再構築

正式プロジェクトでは手動アトラスパッキングを推奨。動的アトラスはプロトタイプ向け、本番リリースには不向き。

自動アトラス設定とビルドフロー

Cocos Creator 3.x には内蔵機能 自動アトラス（Auto Atlas） があります。

使い方：

1. assets ディレクトリに AutoAtlas リソースを作成
2. パッキングする SpriteFrame を追加
3. ビルド時に「自動アトラス」オプションをチェック
4. ビルド完了後、散在画像が自動的にアトラスにマージ

メリット：ビルド時に自動処理、手動パッキングの手間を省ける。

注意点：ビルド後のアトラスファイルはビルド出力ディレクトリにあり、assets にはありません。開発中は散在画像のまま見え、ビルド後にアトラス化——デバッグ時に忘れがちな点です。

パフォーマンス調整効果の定量化

アトラス調整の効果をどう検証するか？

Cocos Creator のデバッグパネルで Draw Call 数値を確認。調整前の数値を記録し、調整後と比較。

フレームレートが倍増、カクつき消失——これがアトラス調整の価値です。

さらに、アトラスはメモリオーバーヘッドも低減。テクスチャ切り替えが減り、GPU が異なるテクスチャデータを頻繁にロードする必要がなくなります。メモリ占有が安定し、GC プレッシャーも下がります。

まとめ

AI でアート素材を生成し、Cocos Creator で使えるリソースにするまでの道筋——核心は 標準化 と 自動化 です。

AI ツール——SOON、Holopix AI、Anything XL——がアートコストを従来の 1/10 程度まで下げてくれます。しかし素材生成は第一歩にすぎません。エンジンへのインポート、規範的なディレクトリ構造の構築、アトラスパッキング、Draw Call 制御——これらの段階が、プロジェクトの長期保守性を決めます。

覚えておく要点：

• assets ディレクトリが唯一のリソースライブラリ。他フォルダは不用意に削除しない
• meta ファイルはリソースの ID カード。すべての操作はエディタ内で
• ディレクトリ構造は機能モジュール別。1 フォルダ 1 種類
• アトラスパッキングはパフォーマンスチューニングの必須。Draw Call を 100+ から 10 以下へ

小さなプロジェクトから実践することをおすすめします。SOON か Holopix AI で 1 キャラクターを生成し、この記事のフローに沿って Cocos Creator にインポート、規範的なリソースディレクトリを構築。アートリソース管理は難題ではなく、再現可能なワークフローになるはずです。

このフローを一度通せば、大規模プロジェクトのリソース管理も自然と身についてきます。