バーチャル3Dクリエイター神部まゆみです(*^_^*)
この記事はUnitypackageエクスポートのやり方や注意点などについての記事です。
動作確認した最新バージョンは Unity 6000.2.7 です。
現在、300以上の人気Unityアセットが50%オフで買える Unity ブラックフライデーセールをやってるみたいです(2025/12/11 1:00まで)。
Unityブラックフライデーセール 対象アセット一覧 50%オフ
Very Animation や Umotion Pro などの人気Unityアセットも安く買える年数回の大規模セールなので、欲しいアセットはこの機会に買っておくと良いかも。
BOOTHでVRoidテクスチャやVRChat向けオブジェクトなどを販売しています。いいねしてくれると励みになります(*^-^*)
- Unitypackageをエクスポートしておくと配布したり他プロジェクトに渡したり便利
- ChatGPTパイセンにUnitypackageの概要や注意点を聞いてみる
- Unitypackageの作り方：アセットフォルダ内でエクスポートしたいものを右クリック ⇒ パッケージをエクスポート でOK
- Unitypackageを作る時の注意点など
- おわりに
Unitypackageをエクスポートしておくと配布したり他プロジェクトに渡したり便利
ファイルをUnitypackageにしておけば、別のプロジェクトにインポートして使えるので便利です。
自分用に使うのもいいし、どうせならバックアップがてらBOOTHあたりに無料や有料で置いておくと良いかもしれません。
人目にさらしておけば「ちゃんと使えるように動作確認しなきゃ」「最新バージョンで使えるかメンテナンスしなきゃ」という意識も働きやすいしｗ
自分用だと「適当でいいや」となってしまい、いざ後で使いたいとなった時に使えなかったり不具合が出たりしやすいかも？ｗ
しかし依存を加えるなどの設定があり、どこまでパッケージに含めるか？(^_^;)
「依存を加える」「Include all scripts」などのチェック項目があり、デフォルトだと大量のファイルが含まれてしまいますΣ(ﾟДﾟ)
特に有料アセットなどが含まれていると規約違反になってしまうので注意が必要。
あまり多いと容量も肥大化してしまうし、最小限に絞った方がいいと思います。
ChatGPTパイセンにUnitypackageの概要や注意点を聞いてみる
BOOTHでUnitypackage配布とかしてるけど、正直なところノリで使ってきたため(笑)、この機会に一から復習してみたいと思います。
馴れ馴れしくなったChatGPTパイセンに聞くのは少し不安だが…ｗ
unityをいじっています。他のプロジェクトで３Dモデルやアセットの設定、プレハブなどを使い回したい時にunitypackageにして渡すことが多いです。まぁまぁ良い感じに受け渡しはできているのですが、一応確認のためにunitypackageの詳しい説明や注意点などを教えてください。依存関係を含めるの設定など結構注意点があると思います。
おお、Unityいじってるんだね。あるあるだけど、「unitypackageにして渡したら相手のプロジェクトでなんか壊れてる…」みたいな地味に面倒な事故、たまに起きるよね。気持ちわかるわ。ここで一回ちゃんと確認しておくの、めっちゃ良い判断だと思う。
じゃあ、ざっくり〜丁寧めに「unitypackageってどういうものか／作るときの注意点」まとめておくね。
◆ unitypackage の基本
- Unity独自のアーカイブ形式。
選択したアセット（フォルダ・プレハブ・スクリプト・マテリアルなど）をまとめて再配布できる仕組み。 - Unityのパッケージマネージャーとは別物（.unitypackage ≠ UPM package）。
こっちは昔ながらの手動配布スタイル。
◆ 作る時によくある注意ポイント
1. 依存関係の含め忘れ
ここが一番みんなやらかすところ。
プレハブだけ選んだつもりでも、内部で参照してるスクリプト・マテリアル・テクスチャ・Animator Controller・ScriptableObjectなど、全部ひっくるめて入れないとプロジェクト側で Missing 祭り。
Unityの Export ダイアログには**
「Include dependencies（依存関係を含める）」**があるので、必ずチェック入れるのが基本。
ただし、ここで落とし穴があって…
2. Include dependencies を入れすぎ問題
依存を含めると、場合によっては想定外に大量のアセットが巻き込まれることがある。
例：
- Standard Assets の一部を使ってた → Standard Assets 全部入る
- ScriptableObject がプロジェクト共通の設定に紐づいてる → その設定ファイルごと入る
- UIコンポーネント参照 → 他の Prefab までズルズル連鎖する
回避テク：
- unitypackageにしたいフォルダ構造をなるべく独立させておく
→ /Assets/YourPackage/ 配下にまとめる - ScriptableObject など共通設定を専用のインスタンスに差し替えておく
- Animator の Controller や Material が外部を参照してないか確認
3. Editor拡張がある場合の注意
Editor フォルダはプロジェクトに必ず含めないといけないけど、
Runtime フォルダと混ざってると依存がややこしくなる。
扱いやすいのはこんな構造：
Assets/MyPackage/
Runtime/
Editor/
Resources/
etc.
UPMっぽい形にしておくと混乱が減る。
4. スクリプトの名前空間
他プロジェクトに持っていったとき、
- クラス名が衝突
- Editor拡張が他のアセットと干渉
などがあるので、namespace をちゃんと付けておくのが吉。
5. リソースのパス参照に注意
Resources.Load("xxx")AssetDatabase.xxx- Addressables を使ってないアセット参照
これらがパス前提だと、フォルダ構造が変わると壊れる。
unitypackageで配布する想定なら、フォルダは固定にするか、そういう参照を避けた方が安全。
6. 動作テストは別プロジェクトでやるべき
これめちゃ重要。
- 新規プロジェクトを作る
- 作った unitypackage を Import
- プロジェクト固有のものが残ってないか動作確認
- Missing Script / Missing Material 、オブジェクト名のズレをチェック
たまに「自分のプロジェクトだと動くのに相手側だと動かない」ってケースは
これをやるとかなり潰せる。
7. 外部アセット（有料含む）の混入に注意
自分が持ってるアセットでも、
相手が持ってない場合に一緒に入れちゃうとライセンス的にアウトなことがある。
普段うっかり同梱しがちなので、Export 時にちょっと気をつける。
◆ まとめ（要点ピックアップ）
- Include Dependencies は便利だけど暴発しがち
- アセットのフォルダ構造は独立させるのがベスト
- 名前空間や参照パスをちゃんと整理
- 別プロジェクトでの動作テストは必須
- 他アセットの無断同梱に注意
もし「今のプロジェクト構造で、どうフォルダ分けしたら依存が混ざらないか？」とかも相談したいなら、
あなたの状況に合わせてもっと具体的にアドバイスできるよ。気軽に投げてくれよな！😎
あーそうか、UPMパッケージっていうのもあったな…。
UPMも試してみたいけど、今回はUnitypackageの話なのでUPMは後でやってみようと思います。
Unitypackageの作り方：アセットフォルダ内でエクスポートしたいものを右クリック ⇒ パッケージをエクスポート でOK
Unitypackageを作るのはたったこれだけです！
作るだけなら誰にでもすぐできるｗ
しかし何も考えずに闇雲にエクスポートするとプレハブについてるスクリプトがそのままついてきたりして、移行先で重複したり欠如したりで不具合が出ます(-_-;)
他人様が作った有料アセットが含まれるとマズイですし。
ちゃんと設計というか、どこまでUnitypackageに含めるかを考えないとダメですね。
Unitypackageを作る時の注意点など
Unitypackageを作る時の注意点などをまとめておきます。
気付いたら後で加筆するかも。
上位のフォルダも含まれてしまうので、エクスポートするファイル(フォルダ)はAsset直下に置いた方がいいかも
例えば Assets/3D/VRoid/Mayumi.vrm みたいなファイル構造の場合、Mayumi.vrmをunitypackageにエクスポートしようとすると上位の3DとVRoidフォルダもくっついてきます(-_-;)
この場合はAsset直下に移動させた方がいいですね…。
できればAsset直下にunitypackageにする用のフォルダを作り、そのフォルダに含めたい中身を全部入れておくのがいいです。
含めたいものだけフォルダにまとめて、フォルダだけエクスポートするのが無難？
私はこうやってAssets直下の一つのフォルダにまとめてからエクスポートしてますね…。
このほうが使う人も見つけやすいし。
アセットストアやBOOTHで買ったアセットも、フォルダ一つだけにまとまっているやつのほうが見つけやすいので楽ですね(^_^;)
じゃないとAssetフォルダが散らかってしまうため、わざわざフォルダ作ってまとめたりしてます。
配布する場合、シェーダーやスクリプトなどUnitypackageに含めないものは明記しておくべき
例えばVRoidモデルを配布する場合、「UniVRM関連のファイルは同梱していないので、インポートする前に導入しておいてください」と明記したほうがいいです。
可能ならば「v.0.130.0 で動作確認済みです」とバージョンも明記してあると安心。
ファイルが重複するとエラーが出る可能性があるため、シェーダーなどは含めない方がいいかも…?
振り返ってみると、VRM関連のシェーダーファイルが同梱されてることが多かったけど、既にUniVRMを導入しているプロジェクトにそのUnitypackageをインポートすると重複でエラーが出た。
↓直し方はこちらを参照。
VRM関連に限らず、他のファイルでも起こる可能性があるため、外部で無料配布されてるアセットなら「ここからダウンロードしてインポートしてください」と書いておけば良いような？
あんまりファイルが多くなるとUnitypackageの容量も肥大化してしまいますからね…。
でも「UniVRMって何？」って人には入れておいた方が良いんだろうけど…どうだろ(^_^;)
無料配布のアセットだとクレジット表記すれば大丈夫なことが多いから、規約的には問題ないんだろうけども。
含めるなら分かりやすい場所に明記しておかないと、エラーで問い合わせが来てめんどくさい可能性がありますｗ
スクリプトをUnitypackageに含めないなら、有料アセットのスクリプト設定ファイルもいける(規約次第？)
Unitypackageに有料アセットのスクリプトを含めるのはNGだけど、スクリプトを含めなければ設定だけはエクスポートできるので、移行先でその有料アセットを購入して導入すればそのまま使えます。
BOOTHだとダイナミックボーンやPhysbone設定済みのモデルとかはよく売られてるけど、当然それらのアセットは含まれていないので「事前に購入して導入しておいてください」みたいな感じになってる。
導入していない場合↓みたいに 欠如(Missing) と表示されるけど、パラメーターの設定などはそのまま残っているため、該当のスクリプトを導入すればそのまま使えるようになります(不具合がなければ)。
The associated script can not be loaded <unknown>
This could be because the script has a compile error or because the script was deleted.
Fix any compile errors if present or assign a valid script.関連付けられたスクリプトを読み込むことができません <不明>
これは、スクリプトにコンパイルエラーがあるか、スクリプトが削除されたためです。
存在する場合はコンパイルエラーを修正するか、有効なスクリプトを割り当ててください。
まぁでも規約次第なのかな？本体は配布しないわけだから普通は大丈夫だと思うけど…。
アセットの宣伝にもなるわけだから悪い話ではないと思うけど、もしアセットの作者さんがダメと言う場合はそれに従う必要があります。
アセットを導入しても 欠如(Missing) のままの場合、アセットを再インポートすれば直るかも
あらかじめアセットを導入してからunitypackageをインポートしたら、欠如のままのことがあった。
けどアセットを再インポートしたらちゃんと読み込まれました。
メンテナンスを考えると、少なめのFBXと差分プレハブが無難か…
3DモデルをUnitypackageにする場合の話だけど、後でいじってメンテナンスする時のことを考えると、FBXオブジェクトを少数、あとはそれをプレハブ化して差分を作っていくと良いかもしれない。
これだと元のFBXを修正するとそこから派生したプレハブにも変更が適用されるのでラク。逆に適用されてしまうことで不具合が起きる可能性もあるけど。
そのあたりについてはこちらを参照。
動作確認は別プロジェクトで ※できれば新規プロジェクトで
Unitypackageがちゃんと動作するかの確認をするときは別プロジェクトで、できれば新規プロジェクトでやったほうが良いと思います。
自分で使うなら多少不具合があっても良いだろうけど、配布する場合は使う人のことを考えてやらないといけません。
新規にプロジェクト作ってUnitypackageをインポートして、必要なシェーダーをインポートしてみて…って感じで正常に動くなら、たぶん他のプロジェクトでも正常に動きます。
ファイルが重複していなければ。
こういうのは余裕がある時にやったほうが不具合に気付きやすいので、Unitypackageにできたからといってすぐ配布するよりは、後日落ち着いて動作確認してみたほうが良いかもしれません。
まぁとりあえず勢いでアップしてしまって後で修正してもいいけどもｗ
おわりに
Unitypackageについての理解が深まって良かった。
作るだけなら誰でもすぐ作れるけど、注意しないと有料アセットを含めてしまったり大変なことになりますね(^_^;)
また何かあれば追記します(*^_^*)