Cocos Creator ミニゲーム公開前チェックリスト：パフォーマンス・パッケージ・互換性・審査を完全網羅

初回審査提出の日、「審査却下」のポップアップを見て、頭が真っ白になりました。パッケージサイズ超過——メインパッケージ 6.8MB、WeChat の硬性制限は 4MB。3 日かけて、テクスチャ圧縮、音声トランスコード、エンジンモジュールの削減を重ね、ようやく 3.2MB まで圧縮して通過しました。

その経験で、公開前チェックには明確な型があると気づきました。運任せではなく、具体的な数値基準と検証方法がある。以来、踏んだ落とし穴をチェックリストに整理し、提出前に毎回項目を確認。今では 10 回以上イテレーションを重ね、パフォーマンス、パッケージサイズ、互換性、審査の 4 モジュール 15 項目を網羅しています。

この記事では、実際に使っているチェックリストを共有します。各項目に数値基準、検出ツール、よくある落とし穴を示します。読み終えれば、このリストを手元に置いて一つずつ確認でき、一発審査通過の確率を大きく上げられます。

一、パフォーマンスチェック：カクつきで体験を壊さない

パフォーマンス問題はプレイヤー離脱の主因の一つ。自分のスマホでは快適でも、実ユーザーは 3 年前の端末を使っているかもしれません。iOS ハイエンドとローエンドの性能差は 3〜4 倍——冗談ではありません。

1. FPS 安定性チェック

チェック基準：ハイエンド（iPhone X 以降）は 60 FPS、ローエンド（iPhone 6s/7/8）は 30 FPS を目標。ピークは目標値の 80% 以上——ハイエンド最低 48 FPS、ローエンド最低 24 FPS。

検出方法：Cocos Creator 内蔵の FPS 表示を cc.macro で有効化：

// 開発段階で FPS を表示
cc.macro.SHOW_FPS = true;

Stats.js を使うとより直感的。WeChat 開発者ツールの「パフォーマンスパネル」でもリアルタイム FPS 曲線が確認できます。

数値指標：

• ハイエンド端末：55〜60 FPS を安定維持
• ローエンド端末：28〜32 FPS を安定維持
• ピーク変動：20% 以内

よくある問題：DrawCall 過多、複雑なシーン切替のカクつき、大量パーティクルの同時発火。以前のプロジェクトでは、Boss 撃破時に 200 個のパーティクルを出し、ローエンド端末が 15 FPS まで落ち込みました。50 個＋イージングアニメに変更したら、見た目も良くなりました。

セルフテストのコツ：iPhone 7 で実機 10 分走行。FPS 線が 30 前後で安定なら問題なし。20 以下に頻繁に落ちるなら調査が必要。

2. メモリピークチェック

チェック基準：iOS にはメモリの硬性上限があります。ローエンド（iPhone 6s/7/8）は 1GB、ハイエンド（iPhone X/XR/11）は 1.4GB。ピークはデバイス上限の 70% 以内——ローエンド 700MB 以内、ハイエンド 1GB 以内。

検出方法：

• WeChat 開発者ツール：「デバッガー-Memory」パネルでメモリ曲線を確認
• Safari リモートデバッグ：実機を Mac に接続し、Safari 開発者メニューからデバイスを選択

// 定期的にメモリ使用状況を出力
const memoryInfo = cc.sys.getMemoryInfo();
console.log('現在のメモリ: ' + memoryInfo.used + 'MB');

数値指標：

• ローエンド端末ピーク ≤700MB
• ハイエンド端末ピーク ≤1000MB
• クラッシュ率 2% 以内（あるプロジェクトでは 15% から 2% に改善）

よくある問題：テクスチャの二重読み込み、リソース未解放、巨大アトラス未分割。Cocos 公式ドキュメントでは、アトラスは 1024x1024 以内が推奨。大きすぎるとローエンド端末でメモリ不足になりやすい。

セルフテストのコツ：ローエンド端末で同じシーンに 20 回出入り。メモリ曲線が上昇し続けて下がらなければ、リソースリークの疑い。

3. DrawCall 数チェック

チェック基準：DrawCall はレンダリング性能に直結。同一フレームの DrawCall が多いほど GPU 負荷が増大。初画面（ゲーム開始直後の画面）は 100 以下、ゲーム中は 200 以下。

検出方法：Cocos Creator の「ビルド公開」パネルでレンダリング統計にチェックを入れると、実行時に DrawCall 数が表示されます。

// 現在の DrawCall 数を確認
const stats = cc.game._renderStats;
console.log('DrawCall: ' + stats.drawCalls);

数値指標：

• 初画面 ≤100
• ゲーム内 ≤200
• ピーク 350 まで（極端なシーンのみ許容）

よくある問題：アトラス未統合、動的アトラス未有効、BMFont の多用。最適化前は DrawCall 350 だったプロジェクトで、小画像を大アトラスにまとめ、BMFont を TTF に替えたら 120 まで下がりました。

最適化のコツ：

• 静的アトラス：TexturePacker でパックし、断片画像を削減
• 動的アトラス：Cocos Creator はデフォルト有効。テクスチャサイズが 2048 未満であることを確認
• BMFont：可能なら TTF を使用。BMFont は char ごとに 1 DrawCall

4. 初画面読み込み時間チェック

チェック基準：初画面読み込みが 3 秒を超えると、ユーザー離脱率が 7% 上昇——業界データです。WeChat クラウドテストのデータでは、3.5MB パッケージのゲームで初画面 4500〜9000ms の区間で離脱率が明らかに上がります。

検出方法：

• WeChat 開発者ツール：「詳細-ローカルコード」でパッケージサイズを確認
• WeChat クラウドテスト：実機ネットワーク環境をシミュレートし、実際の初画面時間を取得

// 初画面読み込み時間を記録
const startTime = Date.now();
cc.director.loadScene('game', () => {
  const loadTime = Date.now() - startTime;
  console.log('初画面所要時間: ' + loadTime + 'ms');
});

数値指標：

• 初画面レンダリング ≤3000ms（理想は ≤1500ms）
• プログレスバー表示率 ≥80%（進捗が見えると待てる）

よくある問題：初シーンにリソースを詰め込みすぎ、初シーン未サブパッケージ、resources ディレクトリの全読み込み。以前は初シーンに 3 キャラ、2 背景、大量 UI を置き、初画面 5 秒。loading 画像 1 枚＋サブパッケージ読み込みに変更して 2 秒まで短縮。

最適化のコツ：

• 初シーンは背景 1 枚＋プログレスバーのみ
• 初シーンにサブパッケージをチェック
• 非必須リソースはリモート読み込み

二、パッケージサイズチェック：4MB の壁を越える

WeChat ミニゲームのメインパッケージは 4MB が硬性制限。全体（サブパッケージ含む）は 16MB 以下。これは赤線——超過は即却下、交渉の余地なし。私もここで躓きました——メイン 6.8MB、却下後 3 日かけて 3.2MB まで圧縮。

5. メインパッケージサイズチェック

チェック基準：メインパッケージ ≤3.8MB。200KB の余裕はなぜ？ビルド時に動的生成ファイルが入ること、WeChat の計量に微妙な誤差があること——自分に余地を。

検出方法：ビルド後、WeChat 開発者ツールの「詳細-ローカルコード」で正確なパッケージサイズを確認。

数値指標：

• メインパッケージ ≤3.8MB（安全ライン）
• メインパッケージ ≤4.0MB（赤線、必ず圧縮）

よくある問題：

• resources ディレクトリにリソース過多：このディレクトリのファイルはすべてメインにパック
• エンジンモジュール未削減：Cocos はデフォルト全モジュール。必要なものだけ使う
• 依存ライブラリが大きい：npm パッケージのサイズ未確認

セルフテストのコツ：ビルド前に resources を確認し、非必須を別ディレクトリへ。Cocos の「プロジェクト設定-モジュール設定」で不要モジュールのチェックを外す。

// モジュール削減設定例（project.json）
{
  "modules": [
    "base",
    "2d",
    "ui",
    "audio"
  ],
  // 不要なモジュールはチェックしない。例：
  // "physics" - 物理エンジン不要
  // "tween" - イージングシステム不要
}

6. 全体パッケージサイズチェック

チェック基準：全体（メイン＋サブパッケージ）≤16MB。サブパッケージはリモート読み込み可能ですが、ダウンロード速度はネットワーク依存。コアコンテンツはメインと初画面サブパッケージに。

検出方法：ビルド出力ログに各サブパッケージサイズが表示。合計が全体サイズ。

数値指標：

• 全体 ≤15MB（安全ライン）
• 全体 ≤16MB（赤線）

サブパッケージ戦略の提案：

• コアパッケージ（メイン＋初画面サブ）<10MB
• 機能パッケージ（サブモード）20〜50MB
• シーンパッケージ（リモート読み込み）30〜100MB

よくある問題：サブパッケージ分割が不合理、初画面サブが大きすぎてダウンロード待ちが長い。あるプロジェクトでは全キャラモデルを初画面サブに入れ、ゲーム開始まで 8 秒待たせました。

7. リソース圧縮率チェック

チェック基準：テクスチャ、音声、フォントがパッケージの三大主力。実測：テクスチャ 45%、音声 25%、フォント 15%。この 3 つを圧縮すれば、パッケージは半分に。

検出方法：元ファイルサイズとビルド後サイズを比較。

数値指標：

• PNG → JPG（透明なし）：50〜70% 削減
• WAV → OGG：65〜70% 削減
• フォント抽出（fontmin）：80〜90% 削減

おすすめツール：

• TinyPNG：PNG 圧縮、Web 版、ドラッグ＆ドロップ
• TexturePacker：アトラスパック＋圧縮を一括
• Audacity：音声トランスコード、WAV → OGG が簡単
• fontmin：フォントサブセット、ゲームで使う文字だけ抽出

よくある問題：

• 背景を PNG：透明不要なら JPG で十分
• 音声を WAV：数倍のサイズ、OGG に
• フォント未抽出：フルフォント 10MB+、使う文字だけなら 100KB 程度

セルフテストのコツ：TinyPNG で PNG を 1 枚圧縮、前後を比較。500KB の背景が 150KB になることも。

8. サブパッケージ設定チェック

チェック基準：サブパッケージ読み込み戦略が起動体験を損なわないこと。初シーンは必ずサブパッケージにチェック。非必須リソースはメインに置かない。

検出方法：サブパッケージ読み込み順序と初シーン依存関係を確認。

数値指標：

• 初シーンサブパッケージ：チェック済み
• 初シーン読み込み時間：≤3000ms
• 非必須リソースがメインにない：resources ディレクトリを確認

よくある問題：

• 初シーンがメイン外リソースを参照：サブパッケージ DL 後でないとシーンに入れない
• サブパッケージが業務ロジックと合っていない：モードに入ってから DL 未完
• 読み込みタイミングが悪い：loading 画面で後続サブパッケージの DL を開始すべき

// サブパッケージ読み込み例
cc.assetManager.loadBundle('level-pack', (err, bundle) => {
  if (err) {
    console.error('サブパッケージ読み込み失敗', err);
    return;
  }
  bundle.loadScene('level-1', (err, scene) => {
    cc.director.runScene(scene);
  });
});

セルフテストのコツ：4G 環境でサブパッケージ DL 速度をテスト。初画面サブが 5 秒超なら戦略を見直す。

三、互換性チェック：特定機種で失敗しない

互換性問題は見落とされがち。テスト端末では快調でも、公開後に UI 遮断、黒帯、横画面切替ずれのクレーム。機種適応は体系的な問題——1 台だけでは足りない。

9. 画面適応チェック

チェック基準：設計解像度、適応戦略、黒帯処理。縦画面ゲームは 720x1280（9:16）または 750x1334、横画面は逆。

検出方法：最低 3 種類の画面比率で実機テスト：

• 16:9（従来比率、多くの Android）
• 18:9（現代比率、Xiaomi/Huawei 新機種）
• 19.5:9（iPhone X 系、ノッチ）

数値指標：

• 設計解像度：720x1280 または 750x1334
• 適応戦略：縦画面は高さ固定、横画面は幅固定
• 黒帯：なし、または均等分布

重要コード：

// 縦画面：高さ固定
cc.view.setDesignResolutionSize(720, 1280, cc.ResolutionPolicy.FIXED_HEIGHT);

// 横画面：幅固定
cc.view.setDesignResolutionSize(1280, 720, cc.ResolutionPolicy.FIXED_WIDTH);

// 実際の可視領域を取得
const visibleSize = cc.view.getVisibleSize();
console.log('可視領域: ' + visibleSize.width + 'x' + visibleSize.height);

よくある問題：

• 適応戦略の誤選択：縦画面で幅固定→上下黒帯
• Widget コンポーネント未活用：ノードが画面端に追従しない
• 設計解像度が広すぎ：一部機種で表示不全

セルフテストのコツ：Widget で重要 UI を画面端に固定。右上のコイン表示など、Widget で右上固定すれば画面比率に関係なくずれない。

10. ノッチ/水滴型ディスプレイチェック

チェック基準：セーフエリア処理、重要 UI の非遮断。iPhone X 系のノッチ、Android の水滴型ノッチ・パンチホールは画面上部を占有。

検出方法：iPhone X/XR/11 系、Android ノッチ端末（Huawei Mate 系、Xiaomi ハイエンド）で実機テスト。

数値指標：

• 重要 UI は上部から ≥50px
• 重要 UI は下部から ≥50px（仮想 Home キー領域）
• セーフエリア検出：SafeArea API を使用

適応のコツ：

// iOS SafeArea 取得
const safeArea = cc.sys.getSafeArea();
const topPadding = safeArea.top;
const bottomPadding = safeArea.bottom;

// ノード適応
this.topNode.y = -topPadding;  // 下方向オフセット
this.bottomNode.y = bottomPadding;  // 上方向オフセット

Widget で端距離を動的取得したセーフエリア値に設定する方法もあります。

よくある問題：

• タイトルがノッチに隠れる：ゲーム名が見えない
• 下部ボタンが仮想 Home キーに隠れる：タップ領域が重なる
• Android パンチホール未テスト：ブランドごとに位置が異なる

セルフテストのコツ：WeChat 開発者ツールシミュレータで「iPhone X」を選び、UI がノッチに隠れないか確認。Android ノッチ実機でも再テスト。

11. 機種互換性チェック

チェック基準：主流機種をカバーし、ローエンド端末で性能基準を満たす。クラウドテストで一括検証可能——大量の端末を買う必要なし。

検出方法：

• WeChat クラウドテスト：無料、WeChat ミニゲーム主流機種をカバー
• Testin クラウドテスト：有料、カバー範囲が広い

カバー機種の提案：

• iPhone 6s/7/8：ローエンド基準、性能下限
• iPhone X/XR/11：ミドル〜ハイエンド、ノッチ適応
• Huawei/Xiaomi/OPPO/vivo 主流 Android：機種互換

数値指標：

• ローエンド端末 FPS ≥30
• ローエンド端末メモリ ≤デバイス上限 70%
• クラッシュ率 ≤2%
• インストール成功率 ≥99%

よくある問題：

• iPhone のみテスト：Android 差が大きく、ローエンド Android は iPhone 6s より弱いことも
• 旧機種無視：2024 年も iPhone 7 ユーザーはいる
• WebGL 未テスト：一部機種は WebGL バージョンが低く、特定エフェクト非表示

セルフテストのコツ：3 種類の機種に集中——開発端末（ハイエンド）、iPhone 7（iOS ローエンド）、2019 年頃の Android ミドル。これで大半をカバー。

12. 縦横切替チェック

チェック基準：縦横適応の設計、切替の滑らかさ。一部ゲームは縦横切替対応（パズル系など）。切替時 UI は自動再配置。

検出方法：実機回転テスト、強制横/縦シーンテスト。

数値指標：

• 切替時間 ≤500ms
• UI 再配置にずれなし
• 切替後シーン正常レンダリング

よくある問題：

• 切替時ノード位置ずれ：Widget 未更新
• 切替後黒画面：シーン再読み込み失敗
• 切替カクつき：シーンが大きすぎて再レンダリング遅い

// 画面回転を監視
cc.view.on('resize', () => {
  const isLandscape = cc.view.getFrameSize().width > cc.view.getFrameSize().height;
  this.updateUILayout(isLandscape);
});

// UI 再配置ロジック
updateUILayout(isLandscape: boolean) {
  if (isLandscape) {
    // 横画面レイアウト
    this.scoreLabel.x = -200;
    this.scoreLabel.y = 300;
  } else {
    // 縦画面レイアウト
    this.scoreLabel.x = 0;
    this.scoreLabel.y = 600;
  }
}

セルフテストのコツ：縦または横のみ対応なら、プロジェクト設定で方向を固定。ユーザーが回転して画面が崩れるのを防ぐ。

四、審査チェック：資格・プライバシー・コンテンツの 3 関門

審査は開発者の頭痛の種。技術問題は自分でテストできるが、審査規範の細部は事前に分かりにくい。WeChat 審査規範は詳しいが、実運用では注意点が多い。2026 年から WeChat は AI 補助審査を導入。更新版は 2〜4 時間で完了することもあるが、初版審査は 1〜2 営業日。

13. 資格完備性チェック

チェック基準：ソフトウェア著作権、ICP 备案、版号（アプリ内課金必須）。3 つは硬性要件——1 つ欠けても却下。

検出方法：公式資格リストと照合し、名称・主体が完全一致しているか確認。

数値指標：

• ソフトウェア著作権：主体・名称がアカウントと完全一致（1 文字の差も不可）
• ICP 备案：審査通過（7〜20 営業日）
• 版号：アプリ内課金ゲーム必須、純広告収益化は免除可

よくある問題：

• ソフトウェア著作権名に余分な文字：著作権「比邻消消乐」、ゲーム名「比邻消消乐ミニゲーム」→却下
• ICP 备案審査未完了で提出：審査 7〜20 日、早すぎる提出は拒否
• 版号主体不一致：版号は会社 A、ゲームアカウントは会社 B→不通過

セルフテストのコツ：ソフトウェア著作権証、ICP 备案スクリーンショット、版号（あれば）を並べ、名称・主体を 1 文字ずつ照合。多くても少なくてもダメ——本当に慎重に。

14. プライバシーポリシーと未成年保護チェック

チェック基準：プライバシー同意画面、実名認証、防沉迷システム。2026 年審査では未成年保護が重点チェック。

検出方法：未成年ユーザーでログインフローをシミュレートし、防沉迷ロジックが動作するか確認。

数値指標：

• プライバシー同意：トップページ目立つ位置に入口（ポップアップまたはボタン）
• 防沉迷：未成年 1 日 ≤1 時間、22:00〜8:00 プレイ禁止
• 年齢適合表示：トップページに健康ゲーム忠告

よくある問題：

• プライバシー同意未表示：ゲーム開始直後にプレイ、同意画面なし
• 防沉迷ロジック欠如：実名認証入口なし、または認証後に防沉迷未実行
• 健康ゲーム忠告非表示：審査で追加要求

セルフテストのコツ：18 歳未満の身分証番号でログインフローをテスト。防沉迷制限が発動するか、22:00 以降ログインでプレイ禁止メッセージが出るか確認。

15. コンテンツコンプライアンスチェック

チェック基準：名称規範、広告コンプライアンス、コンテンツ赤線。名称は資格と一致、広告はコア機能を隠さない、コンテンツは赤線に触れない。

検出方法：審査規範と照合し、名称・広告・コンテンツ要素を項目確認。

数値指標：

• 名称：英語/ブランド語なし、資格と一致
• 広告比率：≤50%、コア機能を隠さない
• コンテンツ：暴力、ポルノ、ギャンブル、政治敏感要素なし

よくある問題：

• 名称に「ソフトウェア」：「XXソフトウェアミニゲーム」→却下
• 広告が重要ボタンを隠す：「ゲーム開始」を押したいのに広告をタップ
• 強制シェア：「友達にシェアしてステージ解放」→却下
• 名称に英語：「CocosGame」→中国語名に変更

よくある却下理由 TOP 5：

1. パッケージサイズ超過（メイン >4MB）
2. 名称とソフトウェア著作権不一致
3. プライバシー同意画面未表示
4. 強制シェア/フォロー
5. 広告によるコア機能の隠蔽

セルフテストのコツ：この TOP 5 を項目確認。5 つで却下事例の 80%——これを避ければ一発通過に近づく。

クイックチェック表：公開前 15 項目

以下は印刷して、審査提出前に項目を確認できます：

モジュール	チェック項目	基準	達成
パフォーマンス	FPS 安定性	ハイエンド≥55、ローエンド≥28	□
パフォーマンス	メモリピーク	ローエンド≤700MB、ハイエンド≤1000MB	□
パフォーマンス	DrawCall 数	初画面≤100、ゲーム≤200	□
パフォーマンス	初画面読み込み時間	≤3000ms	□
パッケージ	メインパッケージ	≤3.8MB	□
パッケージ	全体パッケージ	≤15MB	□
パッケージ	リソース圧縮率	PNG 50%+、音声 65%+	□
パッケージ	サブパッケージ設定	初シーンサブにチェック	□
互換性	画面適応	黒帯なし、遮断なし	□
互換性	ノッチ対応	UI は端から≥50px	□
互換性	機種互換	ローエンド FPS≥28	□
互換性	縦横切替	≤500ms ずれなし（対応時）	□
審査	資格完備	著作権+ICP 备案+版号（課金時）	□
審査	プライバシーと防沉迷	同意入口+防沉迷ロジック	□
審査	コンテンツコンプライアンス	名称/広告/コンテンツ規範	□

各項目達成後にチェック。15 項目すべて完了してから提出。運任せは禁物——1 項目でも未達なら却下、再修正で時間を失う。

まとめ

公開前チェックは省略できる手順ではなく、審査通過率に直結する重要工程。パフォーマンス問題はユーザー離脱、パッケージ超過は即却下、互換性問題はクレーム、審査不合規は 1 週間の修正。

このチェックリストの価値は 3 点：各項目に具体的数値基準があり推測不要、各項目に検出方法があり当てずっぽう不要、各項目によくある問題があり、他人の落とし穴を回避できる。

このリストを印刷してモニター横に貼る。提出前に 1 項目ずつ確認——面倒に感じても、却下後 3 日修正よりずっと得。

最後に：初回公開の緊張は普通。このチェックリストがあれば、体系的に点検でき、心に余裕が持てる。ミニゲームの一発審査通過と順調な公開を祈ります。