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

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

その経験から、公開前のチェックには法則があることに気づきました。運ではなく、具体的な数値基準と明確な検出方法があるのです。その後、ハマった罠をリストに整理し、毎回提出前にチェックマークを入れています。現在、このリストは十数回改良を重ね、パフォーマンス、パッケージサイズ、互換性、審査の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過多、複雑なシーン切り替え時のカクつき、大量パーティクルの同時発生。以前のプロジェクトで、ボス死亡時に200個のパーティクルを爆発させたところ、ローエンド端末で15 FPSまで低下。その後、50個のパーティクルとイージングアニメーションに変更したところ、効果は逆に良くなりました。

自己テストのコツ：iPhone 7を1台用意し、実機で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%に最適化）

よくある問題：2重テクスチャ問題（同じリソースを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は各文字が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秒に。ローディング画像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. リソース圧縮率チェック

チェック基準：テクスチャ、音声、フォントの3種類のリソースがパッケージサイズの3大主力。実測データ：テクスチャが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で1枚のPNGを圧縮し、前後のサイズを比較してください。500KBの背景画像が、圧縮後150KBになることに驚くはずです。

8. 分包設定チェック

チェック基準：分包読み込み戦略が合理的で、起動体験に影響しないこと。初シーンは必ず分包を選択、不要なリソースはメインパッケージに配置しない。

検出方法：分包読み込み順序と初シーンの依存関係を確認。

数値指標：

• 初シーン分包選択：あり
• 初シーン読み込み時間：≤3000ms
• 不要リソースがメインパッケージにない：resourcesディレクトリをチェック

よくある問題：

• 初シーンがメインパッケージ外のリソースを参照：分包をダウンロードしてからシーンに入る必要がある
• 分包がビジネスロジックで区分されていない：あるゲームプレイに入ってから分包のダウンロードが完了していないことに気づく
• 分包読み込みタイミングが不適切：ローディング画面で後続分包のダウンロードを開始すべき

// 分包読み込み例
cc.assetManager.loadBundle('level-pack', (err, bundle) => {
  if (err) {
    console.error('分包読み込み失敗', err);
    return;
  }
  bundle.loadScene('level-1', (err, scene) => {
    cc.director.runScene(scene);
  });
});

自己テストのコツ：4Gネットワーク環境で分包読み込み速度をテスト。初画面分包のダウンロードが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（仮想ホームボタン領域）
• セーフエリア検出：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コンポーネントで直接端からの距離を設定し、数値を動的に取得したセーフエリア値にします。

よくある問題：

• タイトルがノッチで隠れる：ユーザーがゲーム名を見られない
• 下部ボタンが仮想ホームボタンで隠れる：タップ領域が重複
• 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ミドルレンジ機。この3種類で大部分のケースをカバーできます。

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つずつチェックし、名前と主体が完全に一致することを確認。

数値指標：

• ソフトウェア著作権：主体、名前がアカウントと完全に一致（1文字の違いも不可）
• ICP届出：審査通過（7-20営業日）
• ゲーム版号：課金ゲーム必須、広告収益のみは免除可能

よくある問題：

• ソフトウェア著作権の名前が1文字多い：例えばソフトウェア著作権が「比鄰消消楽」、ゲーム名が「比鄰消消楽ミニゲーム」、即座に却下
• ICP届出の審査通過を待たずに提出：審査期間は7-20日、早期提出は却下される
• ゲーム版号の主体不一致：ゲーム版号が会社A、ゲームアカウントが会社B、却下

自己テストのコツ：ソフトウェア著作権証明書、ICP届出スクリーンショット、ゲーム版号（ある場合）を一緒に置き、名前と主体を1文字ずつ照合。1文字多くても少なくてもダメです。ここは本当に注意が必要です。

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

チェック基準：プライバシー同意画面入口、実名認証、未成年保護システム。この3項目は未成年保護の強制要件で、2026年の審査では重点的にチェックされます。

検出方法：未成年ユーザーのログインフローをシミュレートし、未成年保護ロジックが有効かチェック。

数値指標：

• プライバシー同意：ホーム画面の目立つ位置に入口（ポップアップまたはボタン）
• 未成年保護：未成年者は1日1時間以下、22:00-8:00はプレイ禁止
• 年齢適性表示：ホーム画面に健康ゲーム警告を表示

よくある問題：

• プライバシー同意画面未表示：ユーザーがゲームに入ってすぐプレイ開始、プライバシー同意画面が表示されない
• 未成年保護ロジック欠落：実名認証入口がない、または認証後に未成年保護を実行していない
• 健康ゲーム警告未表示：審査時に追加を要求される

自己テストのコツ：未成年の身分証番号（18歳未満）でログインフローをテスト。未成年保護制限がトリガーされるか、22:00以降のログインでプレイ禁止メッセージが表示されるか確認。

15. コンテンツ適合性チェック

チェック基準：名前規範、広告適合性、コンテンツレッドライン。名前は資格と一致、広告はコア機能を隠さない、コンテンツはレッドラインに触れない。

検出方法：審査基準で自己チェックし、名前、広告、コンテンツ要素を1つずつチェック。

数値指標：

• 名前：英語/ブランド名を含まない、資格と一致
• 広告占有率：≤50%、コア機能を隠さない
• コンテンツ：暴力、ポルノ、ギャンブル、政治的センシティブ要素なし

よくある問題：

• 名前に「ソフトウェア」文字を含む：例えば「XXソフトウェアミニゲーム」、却下される
• 広告が重要ボタンを隠す：ユーザーが「ゲーム開始」をタップしようとして広告をタップ
• 強制シェア：「友達にシェアしてレベル解放」、審査で即座に却下
• 名前に英語を含む：例えば「CocosGame」、中国語に変更が必要

却下理由TOP 5：

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

自己テストのコツ：このTOP 5リストで1つずつ自己チェック。この5つの理由は却下ケースの80%を占めています。これらを避ければ、基本的に一発審査通過できます。

クイックチェックリスト：公開前15項目チェックシート

以下のリストは印刷して、審査提出前に1つずつチェックマークを入れられます：

モジュール	チェック項目	基準	達成
パフォーマンス	FPS安定性	ハイエンド≥55、ローエンド≥28	□
パフォーマンス	メモリピーク	ローエンド≤700MB、ハイエンド≤1000MB	□
パフォーマンス	DrawCall数量	初画面≤100、ゲーム≤200	□
パフォーマンス	初画面読み込み時間	≤3000ms	□
パッケージ	メインパッケージサイズ	≤3.8MB	□
パッケージ	全体パッケージサイズ	≤15MB	□
パッケージ	リソース圧縮率	PNG削減50%+、音声65%+	□
パッケージ	分包設定	初シーン分包選択	□
互換性	画面互換性	黒帯なし、隠蔽なし	□
互換性	ノッチスクリーン対応	UI端から≥50px	□
互換性	機種互換性	ローエンド端末FPS≥28	□
互換性	画面回転	≤500msでズレなし（対応の場合）	□
審査	資格完備	ソフトウェア著作権+ICP届出+ゲーム版号（課金）	□
審査	プライバシーと未成年保護	同意画面入口+未成年保護ロジック	□
審査	コンテンツ適合性	名前/広告/コンテンツ規範	□

各項目が達成されたらチェックを入れ、15項目全てチェック完了してから審査を提出してください。運を天に任せるのではなく、1項目でも未達成なら却下され、やり直しに時間を浪費する可能性があります。

まとめ

公開前のチェックは、あってもなくてもいい手続きではなく、審査通過率に直接影響する重要な工程です。パフォーマンス問題はユーザー離れを招き、パッケージサイズ超過は即座に却下、互換性問題はユーザーからの苦情を招き、審査不適合は1週間のやり直し時間を浪費します。

このリストの核心的価値は、各項目に具体的な数値基準があり、推測不要。各項目に検出方法があり、当てずっぽう不要。各項目によくある問題があり、他の人がハマった罠を回避できることです。

このリストを印刷して、モニターの横に貼っておくことをお勧めします。審査提出のたびに、1つずつチェックを入れてください。面倒に感じるかもしれませんが、却下されて3日間修正するのに比べれば、この時間の投資は間違いなく価値があります。

最後に：初めての公開で緊張するのは正常です。しかし、このリストがあれば、体系的にチェックでき、自信を持てます。あなたのミニゲームが一発審査通過し、順調に公開されることを願っています。