大崎商会 大崎商会

軽量化へのこだわり

みんなが一緒に楽しめる空間を作るために。
技術で実現する「誰も置いていかない」世界。

なぜ軽量化にこだわるのか

KemonoBarずんどこには、毎週いろんな人が来てくれます。
ハイエンドPCの人も、Questの人も、みんな一緒に笑いたい。
だから、「誰も置いていかない」ために、軽量化にこだわっています。

目の前のできることからひとつずつ。日々、おおさきくん、がんばってます!

軽量化には、実は3つの側面がある

「軽量化」という言葉でひとくくりにされがちですが、実は3つの異なる側面があります。

1

ダウンロードの軽さ

アップロードサイズ

ワールドに入る時の待ち時間に関わる部分です。

2

動作の軽さ

快適化

入った後、カクカクしないこと。FPSの安定性に関わります。

3

データの軽さ

unitypackage容量

ワールドを作る人がBoothからダウンロードする際の快適さです。

大崎商会では、この3つ全てを意識しています
それぞれがトレードオフの関係にあることも多く、日々、バランスを考えながら取り組んでいます。

1. ダウンロードの軽さ:ワールド読み込みを早く

クランチ圧縮(品質50程度)

最近のアセットでは、テクスチャにクランチ圧縮をかけています。品質は50程度に設定し、ワールドアップロード時の容量削減を図っています。

テクスチャ解像度の調整

多くの画像は1024pxか512pxに設定しています。接近して見ても問題ない範囲で、適切な解像度を選んでいます。

オーディオ圧縮(Mono / 48kHz / OGG)

最近力を入れている部分です。ステレオである必要がないものはモノラルに変換しています。

メッシュ圧縮

インポート設定でFBX圧縮を有効にしています。

検証体制

VRWorld Toolkitというツールを使って、最適化状況を確認しています。
数値で見えると、改善すべき箇所がわかりやすくなります。

2. 動作の軽さ:幅広い環境で快適に

大崎商会の最優先事項

ジオメトリ系

ポリゴン数の最適化

モデリング時点で、必要最小限のポリゴン数を心がけています。

不可視面の削除

皿の裏側など、通常見えない部分は削除しています。

Mesh Colliderの最小化

プリミティブコライダー(Box、Sphere、Capsule)を中心に使用し、Mesh Colliderはなるべく避けています。

シェーダー/マテリアル系

VRC標準シェーダー中心の使用

基本的には「Standard」と「Toon Standard」というVRC SDKに含まれる標準シェーダーを使用しています。

Quest対応

モバイル対応シェーダーを使用し、Quest環境でも動作するよう配慮しています。

半透明の最小化(Cutout使用)

パフォーマンスへの影響を考慮し、半透明表現が必要な場合もCutoutで代用できないか検討しています。

スクリプト系:ネットワーク負荷への配慮

ここが大崎商会の特に力を入れている部分です。

Update()の最小化

毎フレーム実行されるUpdate()は、パフォーマンスへの影響を考慮して最小限にしています。
代わりに以下のような工夫をしています。

  • SendCustomEventDelayedSecondsでの代用
  • イベント駆動型設計(OnPickup、OnTriggerなど)
  • どうしても使う場合は、状態監視と早期returnで処理を軽減

APIコールのキャッシュ

GetComponent()などの処理は、Start()で一度だけ実行して変数に保存しています。
さらに、Editorで設定できないかも常に検討しています。

同期方式の工夫

大崎商会のアセットでは、SendCustomNetworkEventを中心に使用しています。これにより以下を実現しています。

  • 同期のタイミングの制御
  • 不要な同期の削減
  • 送信先の最適化によるネットワーク負荷軽減

ネットワーク環境を考慮した設計

VRChatのネットワーク環境は不安定なこともあるため、以下のような設計方針を採用しています。

  • 同期の失敗を想定した設計
  • リトライによるネットワーク混雑の回避
  • 間接同期の活用(別の情報から状態を推測できる場合は直接同期しない)
  • 必要最小限の情報のみの同期
  • Owner以外は状態判断をしないという設計ルール

AudioPool / ParticlePoolの活用

大崎商会の特徴的な仕組み

例えば、「おつまみ20」というアセットには、1000個以上の食べ物オブジェクトが存在します。
通常であれば、1000個分のAudioSourceとParticleSystemが必要になります。

大崎商会では、AudioPoolとParticlePoolという仕組みを作り、少数のコンポーネントを使い回すことで、メモリとCPU負荷を軽減しています。

レイトジョイナー対応

後から入ってきた人にも同じ世界を見てもらいたいという思いから、レイトジョイナー対応にも取り組んでいます。ただし、すべての情報を送るとネットワークに負荷がかかるため、以下のような工夫をしています。

  • 本当に必要な情報の選別(「なくても不自然でない情報」「他の情報から計算できる情報」は送らない)
  • 同期タイミングの分散(一度に送らず、時間をずらして送信)
  • データ形式の最適化(Int Packingなどの技術を使い、最小限のデータで同期)

LOD(Level of Detail)について

LODは遠くにあるときに低ポリゴン版に切り替える技術ですが、大崎商会では現時点では採用していません。

理由:
  • 大崎商会のアセットは「手に持つ小物」が中心で、常に近距離で見られるため、LODの効果が限定的
  • データ容量が増える(高ポリ版と低ポリ版の両方が必要)
  • 初期段階からポリゴン数を抑えた設計をしているため、必要性が低い

ただし、将来的に大型オブジェクトを扱う場合は、検討する可能性もあります。

3. データの軽さ:制作者の使いやすさ

Boothからダウンロードして、Unityに入れる際の快適さにも配慮しています。

画像の事前圧縮

Unityのインポート設定に合わせて、事前に画像を圧縮しています。

不要なファイルの除外

開発中専用のデータや、他のプランのデータが混ざらないように、専用のPackerツールを作成・運用しています。
これによって、制作者の混乱を防ぎ、容量も最小限にしています。

テクスチャの共有・再利用

規格化して、複数のオブジェクトで同じテクスチャを使うこともあります。

フォントファイルの最小化

可能な限りフォントファイルを使わない工夫をしています。

  • 画像で置き換えられないか
  • フォールバックフォントで対応できないか

といったことを常に検討しています。

シェーダーの依存関係の最小化

Unity標準+VRC標準で実現できることを優先しています。

プレハブの整理

不要なデータは削減しています。

トレードオフの判断

軽量化には、しばしば矛盾が生じます。

クランチ圧縮を強くすると、ワールド読み込み(1)は早くなりますが、画質への影響があります

LODを実装すると、動作(2)は軽くなる可能性がありますが、データ容量(3)は増えます

テクスチャを共有すると、データ容量(3)は減りますが、見た目のバリエーションには制約が生じます

大崎商会では、その都度、用途とバランスを考えて判断しています。

まだまだ改善の余地があります

正直に言うと、まだできていないこと、勉強中のこともたくさんあります。

LODの実装
テクスチャフォーマットの個別最適化
アセットをまたいだマテリアル統合

ただ、「KemonoBarずんどこ」で毎週20名以上の規模で実際に使っていただき、おおむね快適に動いているという実績があります。
それが、現時点での大崎商会の品質の目安です。

この技術を実際に体験してみませんか?

大崎商会のアセットは、この記事で紹介した工夫を実装しています。

アセットを使ってみる

おつまみ20
(AudioPool/ParticlePool実装)

Boothで見る

実際に触って確かめる

VRChatワールド
KemonoBarずんどこ

活動報告

質問・相談がある方へ

技術的な質問や、「こういう最適化はどうでしょう?」といった相談も歓迎です。

お問い合わせ

※この記事は2026年1月1日時点の情報です。過去のアセットは現在の基準を満たしていない場合があります。また、今後情報が古くなる可能性もありますので、ご了承ください。