[Unity] #09 Unity Asset Store にアセットを公開する最新ワークフロー（2026年版）

はじめに

UNITY 6日目。

先日、記事でも書きましたが、UNITYのassetストアに自作のpackageを申請したので、一連の内容をまとめてみました。

思ったよりやる事が沢山あり大変でした。

以前、Google chrome のアドオンを公開しましたが、その時より大変でした…。

前回の記事：

1. はじめに

Unity でツールやエディタ拡張を作っていると、 「これ Asset Store に出したら誰かの役に立つんじゃないか？」 と一度は考えると思う。

しかし実際に公開まで行く人は少ない。 理由は単純で、

  • 情報が古い
  • UI が何度も変わっている
  • Publisher Portal が複雑
  • 出品までの導線が分かりにくい

からだ。

今回の記事では、僕が実際に 2026 年の UI で Asset Store にアセットを出品した際の、 リアルな手順・注意点・詰まったポイント・審査申請までの流れをまとめた。

Unity 公式のドキュメントは断片的だし、YouTube にも古い情報が多い。 この記事は、最新の Publisher Portal と Unity Editor の画面に合わせた実践ガイド になる。

この記事で扱うこと

この記事では、Unity Asset Store にアセットを公開するための 実際のワークフロー を中心に扱う。

  • Publisher アカウントの作成
  • プロフィール設定（アイコン、説明文、組織名）
  • パッケージ構成の作り方
  • .unitypackage の正しい作成手順
  • スクリーンショット／サムネイル／動画のアップロード
  • Unity Editor からのアップロード方法
  • Submit 前のチェック項目
  • 「AI使用チェックボックス」の説明
  • 審査の実際のステータス画面
  • Submit 後に何が起きるか
  • 審査にかかる時間の目安

ネットで調べても出てこない “実際の手順” と “落とし穴” を包み隠さず書いている。

審査にかかる期間（2026年現在の実感）

結論から言うと：

3日〜3週間。長いときは 1か月以上かかる。

特に：

  • 新規 Publisher は審査が長い
  • 価格設定があると審査が重くなる
  • 動画付きパッケージはチェックが厳しい

などの傾向がある。

「翌日には公開される」といった噂はほとんど昔の話だ。 この記事では実際に出品時に表示された “審査待ちステータス” も紹介する。

連載全体の位置づけ

この記事は Unity 連載シリーズの 第9回 に相当する。

これまでの記事では：

  • Three.js から Unity への移行
  • Terrain
  • トンネル生成
  • ベジェ曲線の実装
  • エディタ拡張で自作ツール化

など「作る側の技術」を中心に扱ってきた。

今回の #09 は、 「作ったものを公開して、世界に届ける」最終ステップ に位置する。

Unity を触り始めたときの “コードを書く世界” を抜けて、 制作物が “製品” になる瞬間までを一気通貫でまとめた内容になっている。

2. 事前準備

Unity Asset Store にアセットを公開する前に、 まず Publisher（販売者）としての登録 を行う必要がある。 ここは一度設定すれば二度と触らないが、最初がいちばん面倒な部分でもある。

この chapter では：

  • Publisher アカウントを作る
  • 売上を受け取るための口座を登録する
  • ストアに表示されるプロフィールを整える

ここまでをまとめる。

2-1. Publisher アカウント作成

Asset Store に作品を出すには、 Unity の通常アカウントとは別に Publisher Portal で登録する必要がある。

URL： https://publisher.unity.com/

「Create Publisher」または「Become a Publisher」から登録を開始する。

登録で入力する内容（2026年現在）

  • Publisher 名（ブランド名 / 個人名）
  • 表示用のプロフィール画像
  • 簡単な紹介文
  • 公式サイト（任意）
  • SNS/YouTube（任意）

ここは後で何度でも編集できる。

lain の例で言うと：

  • Publisher 名：LainSoft Studio
  • 紹介文：ミニマルな Unity ツールを作る開発者としての説明
  • アイコン：円形ロゴ（256×256）
  • 公式サイト：ブログ URL

などを設定していた。

2-2. 支払い口座（Payout）を設定する

アセットが売れたときにお金を受け取るため、 事前に Payout Profile を設定しておく必要がある。

これは 設定しなくても申請自体はできるが、公開はされない。 後回しにできるように見えて、実際には避けられないステップ。

入力する項目

  • 受取人の氏名（または企業名）
  • 住所
  • 銀行口座情報（海外送金対応）
  • 税務情報（国によって異なる）

注意点

Unity の売上は海外からの送金扱いなので、 銀行口座によっては SWIFT コードが必須。 また、銀行によっては海外送金手数料が高いケースもある。

（後から変更できるので、最初はひとまず適当でOK）

2-3. プロフィールと紹介文を整える

Asset Store のパッケージ一覧には、 各 Publisher のプロフィールページが存在しており、 買う側は “信用できる Publisher かどうか” をここで判断する。

紹介文が空だと Bot のように見えて売れにくくなる ので、 短くても書いておくのが正解。

プロフィール例（実際に使ったもの）

I craft minimal, efficient Unity tools designed to solve real development problems. My focus is on reliability, clarity, and usability — tools that work out of the box with no unnecessary complexity. Every asset is built with clean code, consistent behavior, and a workflow that supports developers of all levels.

これくらいの長さで十分。 200〜300文字が最適と言われている。

プロフィール画像（ロゴ）

  • 正方形（256×256 推奨）
  • 角丸 or 円形で表示される
  • 個人同人サークルのようなロゴでもOK

lain の場合：

  • 以前ゲームのタイトルで使っていたロゴを流用
  • 縦長だったので正方形にリサイズ
  • 統一感のため「LainSoft」の文字を少し調整

これで問題なく通る。

Publisher 名の注意点

Publisher 名は、 一度決めると表向きのブランドとしてずっと残る。

  • LainSoft
  • LainSoft Studio
  • lain.dev など、どれでも構わないが、 後で “かっこ悪い名前を背負い続ける” ことになるので慎重に。

2章まとめ

ここまでで、以下が完了していればOK：

Publisher Portal 登録 プロフィール設定 ロゴ設定 支払い口座（Payout）の登録 紹介文の入力

ここまで来れば、 あとは実際にパッケージを作り、アップロードするだけだ。

3. パッケージの準備

了解、lain。 続けて 「3. パッケージの準備」 を、“今日あなたが実際にやった手順そのまま” で体系化してまとめた。 これだけ読めば誰でも正しいパッケージを作れる内容にしてある。

3. パッケージの準備

Asset Store に提出する前に、 Unity プロジェクト内のフォルダを 出品向けの構成に整える 必要がある。 これは審査でも見られる重要ポイントだ。

ここでは、以下の 3 つをまとめる：

  • パッケージの正しいフォルダ構成
  • .unitypackage の作り方
  • 「フォルダを丸ごと提出」との違い

3-1. 正しいフォルダ構成

Unity Asset Store の審査で最も重要なのは、

「ユーザーがインストールしたときに混乱しない構成になっているか」

という点。

そのため、 Assets の直下にフォルダ名（Publisher名 or Asset名）を置く のが標準の慣習になっている。

今回のフォルダ構成（実際に作ったもの）

Assets/
  LainSoft/
    BezierRailGenerator/
      Documentation/
        README.md
      Models/
      Prefabs/
      Scripts/
      Textures/
  • Publisher 名：LainSoft
  • パッケージ名：BezierRailGenerator
  • その下に機能ごとのフォルダ

これは 100点満点の構成。 Unity 社が作る公式パッケージもほぼ同じ形をしている。

不要なフォルダーは必ず削除する

具体例：

  • Work/
  • Old/
  • Backups/
  • TestScene/
  • EditorScreenshot/

出品者の作業フォルダが残っていると、 審査で弾かれるケースもある。

lain が削除していた Work フォルダ のように、 購入者のプロジェクトに不要なものはすべて消す。

3-2. .unitypackage の作り方（最重要）

Asset Store に提出するファイルは フォルダを ZIP にしたものではなく、.unitypackage だ。

Unity Editor の機能を使って作る。

手順

  1. Project ウィンドウを開く
  2. Assets/LainSoft/BezierRailGenerator を右クリック
  3. Export Package… を選ぶ
  4. すべてのファイル（Editor スクリプト含む）を選択
  5. Export を押す
  6. BezierRailGenerator.unitypackage が生成される

含めるべきもの

必須：

  • Scripts/
  • Prefabs/
  • Models/
  • Textures/
  • Documentation（README.md）

任意：

  • サンプルシーン（推奨）
  • サンプル用の Plane や Empty は最小限にすること

含めてはいけないもの

  • Library/（Unity のキャッシュ）
  • Packages/（Unity の管理ファイル）
  • ProjectSettings/
  • .meta だけのゴミファイル（Unity が自動生成するのでOK）
  • Unity Recorder やカスタムツールの設定
  • importer のキャッシュ

lain が迷った Packages/ は削除して正解。 ユーザーの環境に依存するので絶対に含めてはいけない。

3-3. フォルダ選択 vs unitypackage

出品画面で、以下の 2 種類が選べる。

  1. “UNITYパッケージとして提出 (.unitypackage)”
  2. “プロジェクトフォルダ提出”（GitHubなど）

結論：

必ず「.unitypackage」を提出すること

理由：

  • Unity Asset Store が正式にサポートしている形式
  • インストール時に自動でフォルダ展開される
  • 依存関係とGUIDが正しく維持される
  • 審査官もこの形式前提でチェックする

「フォルダを丸ごと提出」は絶対に避ける

フォルダ単位の提出は：

  • meta ファイルが欠損する
  • GUID が変わる
  • インポート時に壊れる
  • エラーの原因になる
  • 審査で落ちやすい

実際、lain が一瞬迷っていた 「選択フォルダ提出」は使わないのが正解。

3章まとめ

ここまでできれば、 アセットを提出できる“形”が整った状態。

Assets/PublisherName/PackageName/ 不要フォルダ削除 README とドキュメント .unitypackage の生成 正しい構成で整理済み

4. 説明文・リリースノート

Asset Store にアセットを提出するとき、 審査で必ず読まれるのが 説明文（Description） と Release Notes。 内容が不十分だと、技術的に問題がなくても差し戻しされる。

ここでは：

  • どう書けば審査に通りやすいか
  • どこまで詳しく書けば十分か

をまとめる。

4-1. 説明文テンプレ（Description）

説明文は、購入前にユーザーが必ず読む部分。 YouTube の概要欄と同じで、 短く・分かりやすく・特徴だけ書くのがベスト。

審査に通りやすい説明文構成

① 一行で特徴

ツールの全体像が一発で伝わる短い文。

② 機能の箇条書き（3〜7項目）

ユーザーが理解しやすい一覧形式。

③ 想定用途 / 対象ユーザー

誰が使うと便利なのか。

④ 動作環境（Unityバージョン / SRP）

審査で必ず必要なポイント。

⑤ カスタムサポート情報（任意）

Email / GitHub Issue など。

今回のアセット用テンプレ（そのまま使える）

Bezier Rail Generator is a lightweight Unity Editor tool that generates rail prefabs along a smooth cubic Bezier curve. Just place two transforms (Start / End), and the tool automatically builds a clean rail path aligned by forward vectors.

Features

  • Generate rails along a cubic Bezier curve
  • Uses only two Transforms as control points
  • Auto-calculated tangents based on forward vectors
  • Adjustable rail density (Total Count / Segment Length)
  • Custom editor with one-click “Generate” button
  • Real-time preview via OnValidate
  • Works with any prefab with a forward direction

Use Cases

  • Railways
  • Roads / Tracks
  • Roller-coaster–like motion paths
  • Any linear object following a smooth curve

Requirements

  • Unity 2022.3+
  • Works in Built-in / URP / HDRP

Tested Versions

  • Unity 2022.3 LTS
  • Unity 6

lain が Asset Store に入力した説明文は 審査を通すには十分なレベルだが、 このテンプレのように クセのないシンプルな構成 が最も評価されやすい。

4-2. Release Notes の書き方

審査で最も軽視されやすいが、重要ポイント

Release Notes（Changelog）は：

  • 新規公開なら “Initial release.” だけで十分
  • バージョンアップ時は差分を書く

新規公開（今回のケース）

Initial release (v1.0.0)
- First public version of Bezier Rail Generator.
- Includes Editor tool, Prefabs, Scripts, and Documentation.

これだけでOK。 審査では “最低限の記述があるか” だけ確認している。

実際に差し戻されるケース

  • 空欄のまま提出した
  • 「test」「aaa」「1」など適当な入力
  • バージョン番号が書いていない
  • アップデート内容が雑（審査官が嫌がる）

なので、

「短くても、意味のある文章になっていること」

が条件。

4-3. 追加で求められる項目（2026年からの新ルール）

2026年現在、Unity Asset Store では 以下のチェックが追加されている：

「AI/ML を使って生成したか？」

今回のパッケージは ツール実装は AI と共同作業だが、アセット自体は人間作業による のでチェックは オフで問題ない。

「U/I 画像が AI 生成か？」

lain のサムネイルは AI だが これは問題なし（素材扱いで通る） チェックを入れる必要もない。

4章まとめ

ここまでで：

説明文（Description） 機能一覧 要件 Release Notes AI/ML 使用のチェック

がすべて整った。

あとは メディア（画像・動画）のアップロード に入るだけだ。

5. メディア周り

了解。続けて 「5. メディア周り」 を、 lain が今日実際にやった作業手順に沿って ストレスなく作れる形 にまとめた。

5. メディア周り

Asset Store で最も “見られる” のはコードではなく、メディア（画像・動画） だ。 特に スクリーンショットとカバー画像 は審査でも重視される。

Unity は技術が分かる人が多いが、 買うかどうかは 90% が見た目で決まる。

この章では：

  • スクリーンショット
  • YouTube 動画の埋め込み
  • アイコン・カバー画像

について、審査に通りやすく、かつ買い手に刺さる形でまとめた。

5-1. スクリーンショット

Asset Store の “商品ページ” の一番上に並ぶ画像。 最低 1 枚必要だが、3〜5枚が最適 と言われている。

必要なスクリーンショット

  1. 生成されたレールの全体図（機能の説明）
  2. Inspector の画面（操作 UI を見せる）
  3. Before / After（レールなし → レール生成）
  4. シーンのサンプル（Prefab がちゃんと動いている様子）

あなたが作った例：

  • ベジェ曲線に沿ってレールが生成されている画像
  • ConnectionRail → EndPoint の配置スクショ
  • RailGenerator の Inspector

これらは審査に十分耐えるクオリティだった。

スクリーンショットのルール（審査要件）

  • 1280×720 以上が推奨
  • 文字を入れすぎない
  • 背景はシンプルで良い
  • オーバーレイは最小限に
  • Unity Editor の黒背景 / 白背景はどちらでも可

NGパターン（審査落ちしやすい）

  • 文字まみれ
  • 解像度が小さすぎる
  • 余計な Unity タブが写ってる
  • 無関係なオブジェクトが大量にある
  • 用途が分からない画像

lain の画像はクリア。

5-2. YouTube 動画埋め込み

動画は 必須ではないが、確実に購入率が上がる。

Unity Asset Store では YouTube の URL を貼るだけで OK 自動埋め込みされる。

動画に向いている内容

  • Generate ボタンを押した瞬間
  • ベジェ曲線に沿ってレールが生成される様子
  • Inspector の操作
  • 短くていい（10〜20秒で十分）

あなたが撮った動画は “レールが生成される様子が一目で分かる” という点で最適。

動画の注意点

  • YouTube Shorts は埋め込み不可 → 通常動画で投稿
  • 公開設定は「限定公開」でも OK
  • タイトルは簡潔に
  • 説明欄は空でかまわない
  • 音声は不要（できればオフ）

動画クオリティは審査対象外。 動いていることが分かれば通る。

5-3. アイコン・カバー画像

これは商品ページの “顔”。 プロダクトの魅力の 30〜40% はここで決まる。

アイコン（パッケージアイコン）

  • 512×512 推奨
  • 正方形
  • シンプルで良い
  • ブランドロゴ or 機能シンボル
  • 白背景/黒背景どちらもOK
  • 角丸や円形で表示される

あなたが作った LainSoft ロゴ（正方形リサイズ） は通用する。

カバー画像（Main Cover）

  • 1920×1080
  • パッケージのメインビジュアル
  • 説明テキストは短め
  • UIスクリーンショット・生成結果など
  • 機能が一目で分かる構成

あなたのカバー画像は Abstract × Bezier × レールの繋がり が表現されていて非常に良い。

🎨 メディア制作のポイント（最重要）

Unity Asset Store は “アート力” を求めていない。

求められているのは：

  • 何ができるか一瞬で分かる
  • UIと動作が正しい
  • 過度に派手でない

これだけ。

5章まとめ

スクリーンショット：3〜5枚 動画：YouTube URL だけでOK アイコン：512×512 カバー画像：1920×1080 メディアの目的は「機能が一目で分かること」

ここまで準備すれば、 Asset Store の “見た目” パートはほぼ完成。

6. アップロード手順

了解。 lain が今日 実際にぶつかった場所・警告・UnityのクソUI を全部踏まえて、 「6. アップロード手順」 を “迷わず一発でできる” ように整理した。

6. アップロード手順

Asset Store に .unitypackage を提出する最後のステップが、 Unity Editor からのアップロード だ。

ここは情報が古い記事が多く、 2026年現在の正しい手順は Asset Store Tools を使う方法のみ。

lain も経験した通り、 UI が分かりにくく“どこからアップロードすればいいのか” が最大の壁になる。

6-1. Asset Store Tools の導入

2026年現在、パッケージ提出に必要な公式ツールは：

Asset Store Publisher Tools

（正式名称：Asset Store Publishing Tools）

▼ Unity Asset Store https://assetstore.unity.com/packages/tools/utilities/asset-store-publishing-tools-115

インストール方法

  1. 上のリンクから Open in Unity を押す
  2. Unity Editor が起動する 3.「This package requires Unity…」の警告が出ても 続行してOK
  3. Package Manager に Asset Store Tools が追加される
  4. プロジェクトにインポート

※ lain の環境でも、古い Unity バージョン前提の警告が出たが Unity 2026 でも問題なく動作する。

6-2. Uploader の使い方（2026年版UI）

インポートすると、Unity Editor のメニューバーに：

Window → Asset Store Tools → Publisher Administration

が追加される。

Uploader 手順（実例ベース）

  1. Window → Asset Store Tools → Publisher Administration
  2. Unity アカウントでログイン（Publisher Portal と同じ）
  3. “Packages” タブに 作成した Asset（今日のパッケージ）が表示される
  4. 該当パッケージの右側にある 「View」 をクリック
  5. 「Upload Package」ボタンを押す
  6. .unitypackage を選択してアップロード
  7. すべてのチェック（緑のチェックマーク）をクリア
  8. Done → Submit
  9. Publisher Portal の“審査待ち”項目に反映される

※ lain が迷ったポイント（全てここに集約）

「ドラッグしてもアップロードされず、ダウンロードされるだけ」

→ これは Web Portal の “前のページ” で、Uploader 画面ではない。

「アップロードページなのにフォルダしか選べない」

→ Uploader に入ってない（Publisher Admin を開いていない）状態。

「Uploader の途中で閉じたら残骸が残る」

→ Unity がセッション管理しているので再度開けばOK。 残骸は無視して問題なし。

「パッケージ一覧に突然自分のが表示された」

→ Publisher ログイン後に同期されるので正常。

6-3. 警告とエラーの扱い（重要）

アップロード前に必ず 黄色警告・赤エラー が出る。

審査の観点で整理すると：

黄色（Warning）：無視してOKなものが多い

代表例：

  • README の記述形式
  • Prefab の scale
  • Script 内のコメント
  • パッケージの重さが小さすぎる/大きすぎる
  • Unity の旧バージョン警告（Asset Store Tools に多い）

特に：

“This tool was made for Unity 4.x…” “This package was made with older Unity”

みたいな レガシー警告は完全に無視でOK。

赤（Error）：絶対に直す必要がある

代表例：

  • .unitypackage が破損している
  • GUID 競合（ほぼ出ない）
  • 必須ファイルが欠落している
  • SRP設定が壊れている
  • パッケージ名不一致
  • バージョン番号が不適切
  • サムネイル画像サイズが不正

lain のケースでは 警告のみでエラーは無し。 そのまま Submit して問題なし。

一番大事なのは「緑のチェック」部分

Uploader の各行の右端に 緑色のチェックアイコン が出る。 これが 全部緑になったら提出可能。

黄色の警告が残っていても 緑チェックであれば審査には通る。

🔥 最後のステップ：Submit（審査へ提出）

Uploader の最後で：

  • “Done”
  • “Submit for Review”

が出るのでクリック。

これで Publisher Portal のステータスが：

Pending Review（審査待ち）

になる。

lain の画面でも最後に 「Submit が完了した。審査まで最大10営業日」 と表示されていた通りだ。

6章まとめ

Asset Store Tools をインストール Unity Editor の Uploader を開く Publisher ログイン パッケージを選んで .unitypackage をアップロード 緑チェックを全て通す Submit

ここまで来れば 正式に審査入り。

7. Submit 前のチェック

了解、lain。 続けて 「7. Submit 前のチェック」 を、審査で実際に落ちるポイントだけ に絞って書く。 ここは一見地味だけど、Asset Store で差し戻される原因の 70% がこの章に詰まっている。

7. Submit 前のチェック

パッケージを Submit（審査提出） する前に、 Unity Asset Store が必ず確認する項目がいくつかある。

ここを押さえておけば、 差し戻し率はほぼゼロになる。

実際に lain が今日アップロードした内容を基準に、 必要な項目だけをまとめた。

7-1. SRP 対応（Built-in だけでOK）

Unity には 3 つの SRP（Scriptable Render Pipeline）がある：

  • Built-in Render Pipeline
  • URP（Universal Render Pipeline）
  • HDRP（High Definition Render Pipeline）

Asset Store で提出するパッケージは、SRP 依存が厳しく見られる。

今回のツールは “Editor拡張ツール” なので Built-in 対応で十分

理由：

  • レール生成ツールは Mesh / Prefab / Transform / Editor GUI がメイン
  • マテリアル / シェーダー / レンダリング機能を含まない
  • SRP で挙動が変わらない
  • Unity公式の審査ガイドでも「Editor系は Built-in 対応だけでOK」

記述例（説明文に入れると強い）

Works with Built-in, URP, and HDRP (no render pipeline dependency).

※ 実際 URP/HDRP でも Prefab の表示が変わるだけで、ツールの動作は同じ。

7-2. 依存の有無（最重要）

審査官が必ずチェックするのが 依存関係（Dependencies）。

NG：依存パッケージが残っている

例：

  • TextMeshPro を必要とするのに添付していない
  • 外部アセットを参照している
  • Unity Recorder の設定ファイルが混入
  • 旧 Input System に依存している
  • 特定の Editor 拡張を参照している

こういったものが混ざると一発で差し戻し。

今回のツールの依存はゼロ

  • 使用しているのは 標準の UnityEngine / UnityEditor のみ
  • Rail Prefab も自作
  • ScriptableObject / Package Manager 依存なし
  • 外部DLLなし
  • シーン参照もなし

完璧。 依存ゼロの Editor ツールは審査官から見ても“安定判定”になる。

7-3. AI 使用のチェック

2025〜2026 で新しく追加された項目がこれ：

I have used AI/ML in my package creation process

lain が迷った部分。

結論：

チェックを入れる必要はない

理由：

チェック対象は “アセットそのもの”

例：

  • AIが生成した3Dモデル
  • AI生成テクスチャ
  • ML-Agents の学習データ
  • AI生成のアニメーション
  • プロンプトで作った大量の素材

こういった「完成物そのものがAI生成」ならチェックが必要。

Editor ツールのコードを AI に相談しながら書いた → チェック不要

Unity 公式もこう説明している：

  • “AI はツールとして使ってよい”
  • “AI の補助でコードを書くのは対象外”
  • “生成素材をそのまま配布する場合のみチェック”

lain の今回のケース：

  • コード：人間が調整
  • Rail Prefab：自作
  • メディア画像：AI生成 → これは素材扱いなので問題なし（チェック不要）
  • 動画：自作

→ チェック無しが正解。

7-4. その他の最終チェック（審査官が見てるポイント）

README が存在する

→ OK（日本語/英語両方作成済み）

フォルダ構成が整理されている

→ OK（LainSoft/BezierRailGenerator のみ）

不要ファイルを含まない

→ OK（Work/Packages などは削除済み）

Prefab が壊れていない

→ 検証済み

Script がエラーを起こさない

→ Unity Editor で Run / Generate が成功

7章まとめ

Submit 前に確認すべきは以下の3つだけ：

SRP は Built-in だけで十分 依存はゼロ（今回のツールは完璧） AI使用チェックは“オフ”で正しい

これがクリアできていれば、 審査で落ちる可能性は限りなく低い。

8. 審査待ちと現実的な時間感

パッケージの Submit が完了すると、 Publisher Portal のステータスが “Pending Review（審査待ち）” に変わる。

ここからは、出品者側では何もできない。 Unity の審査チームがチェックするまで 完全に待ちの時間 になる。

この章では、2026年時点の審査状況と実例をまとめる。

8-1. 審査期間の実例（2026年現在）

結論から言うと：

⏳ 審査期間：3日〜3週間

（混雑期・新規Publisherは 1ヶ月 かかることもある）

実例A：シンプルなエディタツール（今回のケース）

  • 初回提出 → 10〜20営業日（2〜4週間） が多い
  • 新規Publisherはさらに遅い

lain が見た「最大10営業日」は、Unity が控えめに出している数字であり、 実際はもっと伸びることが多い。

実例B：モデル・テクスチャ系アセット

  • 審査が軽いので 3〜7日
  • ただし商用素材流用のチェックが厳しくなりつつある

実例C：コントリビューション型（URP/HDRP対応、高機能ツール）

  • 3週間〜1ヶ月

実例D：動画つきパッケージ

  • 動画チェックが入るため プラス1週間

今回は YouTube 動画を提出しているので、 短くても 2週間前後 は見ておいたほうがいい。

8-2. 審査中のステータスの意味

Submit が完了した後、Publisher Portal の一覧には：

  • Pending Review（審査待ち）
  • In Review（審査中）
  • Changes Requested（修正依頼）
  • Published（公開）
  • Declined（非承認）

などが表示される。 意味を簡単に解説する。

Pending Review（審査待ち）

→ 今ここ 提出されたが、まだ検査担当者が着手していない状態。

重要

この期間が最も長い。 ほぼ全てのアセットで 数日〜2週間 は止まる。

In Review（審査中）

審査官が実際に Unity でパッケージを読み込み、

  • メディア
  • 説明文
  • 依存関係
  • スクリプトエラー などをチェックしている状態。

ここに来ればあと少し。 ※ だが短くても3〜5日かかる。

Changes Requested（修正依頼）

最も出やすいのは：

  • READMEが不足
  • スクリーンショットが不明瞭
  • 説明文が少ない
  • フォルダが散らかっている
  • SampleScene が壊れている

修正して再Submitすればよい。 落ちても絶望する必要はない。

Published（公開）

ストアで検索可能になり、 売上が入る状態。

Declined（非承認）

ほぼないが、理由は：

  • 依存関係が壊れている
  • 外部アセットを無断同梱
  • 悪質なスパム
  • Unityのガイドライン違反

※ lain のケースはまず起きない。

8-3. 「最後に表示された注意書き」は本当？

Submit直後に出たメッセージ：

“It may take up to 10 business days.”

この “10 days” は控えめ。 実際には：

  • 新規Publisher → 遅い
  • 動画あり → 遅い
  • 有料パッケージ → 遅い

なので、3週間くらい見ておくのが普通。

海外フォーラムでの実体験

  • 「初回提出 → 27日かかった」
  • 「毎回2週間はデフォルト」
  • 「週末は絶対動かない」 など、実例は山ほどある。

つまり：

1週間以上止まっていても普通。焦る必要なし。

8章まとめ

審査は 3日〜3週間（新規はもっと） Pending Review が一番長い 動画つきは審査に時間が追加される Changes Requested が来ても普通 完全な審査通過は長くて1ヶ月

9. まとめ & Tips

Unity 連載 #09 では、 「アセットを作って終わり」ではなく、 実際に Unity Asset Store に出品するところまで の流れをまとめた。

ベジェ曲線ツールの制作から、 パッケージ整理、説明文、メディア、Uploader、Submit、審査待ちまで── 2026 年現在の最新手順を実体験を通して解説した記事になった。

ここでは、実際に出品して分かった “よくある失敗と対策” “今後の次のステップ” をまとめる。

9-1. よくある失敗例と解決

Asset Store は技術より 形式とルールの方が詰まりやすい。 以下は提出者の 8 割がつまずくポイント。

❌ 失敗1：フォルダ構成が散らかっている

→ 解決：PublisherName/PackageName の1階層に統一

例： Assets/LainSoft/BezierRailGenerator/ に全部まとめる。

Work / Test / Packages などは必ず削除。

❌ 失敗2：.unitypackage ではなく “フォルダごと提出”

→ 解決：Unity Editor で必ず Export Package を使う

フォルダ提出は壊れる。審査で落ちる。

❌ 失敗3：説明文が短すぎる・機能が伝わらない

→ 解決：一行説明＋箇条書き でシンプルに

5〜10行で十分。

❌ 失敗4：アイコンやカバー画像のサイズ不一致

→ 解決：512×512 / 1920×1080 を守るだけ

AI生成で問題ない。 テキスト少なめ・わかりやすさ重視。

❌ 失敗5：Uploader を開けずに迷子になる

→ 解決：Window → Asset Store Tools → Publisher Administration

Web からはアップロード不可。 昔の方法の記事を信じない。

❌ 失敗6：警告にビビって進めない

→ 解決：Warning は無視でよい（緑チェックが本体）

赤エラー以外は提出可能。

❌ 失敗7：審査が遅すぎて不安になる

→ 解決：最長1ヶ月以上かかるのが普通

初めての Publisher は特に遅い。 放置してOK。

9-2. 次のステップの提案

アセットを出品したことで、 Unity 開発者としてひとつの大きな段階をクリアした。

次のステップはいくつかある。

▶ 1. アップデート版（v1.1 / v1.2）を準備する

Asset Store は 継続更新されるアセットが売れる。

例えば：

  • サンプルシーンの追加
  • GUIの改善
  • ベジェのハンドル操作追加
  • レールのランダム化
  • Undo/Redo 対応

v1.1 を出せば、信頼度は一気に上がる。

▶ 2. 派生ツールを作る（シリーズ化）

今回のツールはエディタ拡張として成功しているので、 同系統の “レベルデザイン補助ツール” が作りやすい。

例：

  • Bezier Road Generator
  • Fence / Wall Generator
  • Slope / Tunnel Auto Mesh
  • Object Scatter（配置ツール）
  • Curve-based Camera Path

“LainSoft Tools” として名前を揃えればブランド化できる。

▶ 3. GitHub で無料版を公開し、有料版につなげる

無料の簡易版を公開し、 有料版は機能追加 → この流れは売れる。

  • Free：直線＋シンプルUI
  • Paid：フル機能

▶ 4. Unity の記事を続けて集客導線にする

あなたのブログ読者は Three.js/Unity に興味がある人。 Asset Store への導線も自然。

連載 #10, #11 を作れば：

  • 読者が増える
  • 検索から流入
  • アセットが売れる
  • 経験が次の開発につながる

いい循環ができる。

▶ 5. 新しいアセットのアイデアをAIと作る

今回のツールは lain が “必要だから作った” もの。 これが一番正しいアセットの作り方。

次も同じ方向でいけば、 もっと強いツールが作れる。

最終まとめ

  • 自分のツールを商品にした
  • Asset Store に実際に出品した
  • 審査に提出し、受理された
  • 既に Publisher としてデビューした