Resonite移行ガイド：VRChatからの実務手順と注意点

はじめに：Resoniteへの移行目的・想定読者・前提

VRChatからResoniteへの移行作業を、実務担当者が現場で使える形で整理します。
想定読者はアバター制作者・ワールド制作者・コミュニティ運用者で、元ソース（.blend/.fbx、テクスチャ等）を保有していることを前提とします。ResoniteとVRChatの差分を踏まえ、段階的に移行する方法を示します。

この記事で得られること（要点チェック）

以下を短時間で把握できることを目標とします。

• Resonite移行で優先すべき技術項目とリスクの一覧化。
• アバター1体を小規模で検証するための具体的手順と推奨設定。
• ワールドのノード化・同期・インベントリ設計の実務ポイント。
• 運用（バージョン管理・CI・ロールバック）と法的留意点の指針。

Resoniteの概要とVRChatからの主要な違い（実務観点）

ここではResoniteの主要機能と、VRChatと比べたときの実務上の差分を整理します。機能仕様は更新されるため、移行前に公式ドキュメントとリリースノートで裏取りしてください。

公式情報と仕様変更リスク

まず公式情報を常に参照してください。Resoniteの仕様や対応ハードウェアは更新される可能性があります。移行プロジェクトではバージョン固定（クライアント・ツール）とリリースノートの定期確認を組み込みます。

• Resonite 公式: https://resonite.com/
• Resonite（Steam 配布）: https://store.steampowered.com/app/2519830/Resonite/
• 重要：公式サイト／Steamページのリリースノートやドキュメントを移行前に必ず確認してください。

実務上の主な差分

ResoniteとVRChatではワークフローやランタイムの前提が異なります。現場で特に影響が出やすい点を挙げます。

• シェーダとマテリアル：Unityの標準シェーダやURP/HDRPはそのまま移行できない場合が多いです。ノードベースで再現が必要になります。
• スクリプト：UdonやC#スクリプトはResoniteのノードロジックに置換が必要です。
• アセットフォーマット：glTFが使いやすい一方で、エクスポータ/インポータ依存の差分が発生します。
• トラッキング/ハード対応：フルトラッキング等の対応状況は変わるため公式情報で要確認。
• コミュニティと外注エコシステム：利用可能なスキルセットや外注先が異なるため、要件定義を明確にします。

移行前に確認すべき事項（チェックリスト）

移行開始前に最低限クリアすべき事柄を整理します。ここを怠ると大きな手戻りが発生します。

要点チェックリスト

下記を最優先で確認・準備してください。

• Resoniteアカウントとクライアント入手方法を確認する。
• プラットフォーム利用規約と禁止事項を確認し、公開要件を整理する。
• 元データと依存ライブラリの完全バックアップを取得する。
• アセットの権利（購入/同意/商用利用可否）を確認する。
• テスト対象（アバター1体、限定ワールド等）と優先度を決める。
• ターゲットデバイスと性能目標（FPS、ポリゴン・テクスチャ予算）を決める。
• ロールバック手順と責任分担を明確にする。

バックアップとバージョン管理

作業はバージョン管理と大容量アセット管理を前提に行います。Git + Git LFSを推奨します。

• 元プロジェクトは必ずリポジトリ化し、差分で管理する。
• Git LFSでバイナリ（.blend/.fbx/.glb/.png/.exr等）を管理する。
• 例：.gitattributes の最小例（リポジトリルート）:

*.blend filter=lfs diff=lfs merge=lfs -text

*.fbx filter=lfs diff=lfs merge=lfs -text

*.glb filter=lfs diff=lfs merge=lfs -text

*.png filter=lfs diff=lfs merge=lfs -text

*.jpg filter=lfs diff=lfs merge=lfs -text

• ビルドアーティファクトはリリース番号付きでアーティファクトストレージ（S3等）へ保管する。

性能目標とテスト基準（数値例と測定方法）

目安値を示します。必ずターゲット環境で実測して調整してください。

• VR（6DoFヘッドセット）: 目標 72–90 FPS（目標はデバイスに合わせる）。アバター三角形数の目安 10k–30k。主要テクスチャは1024–2048を中心に調整。ドローコールは可能な限り減らし50未満を目標。
• デスクトップ（非VR）: 目標 60–120 FPS。アバター三角形数の目安 20k–50k。テクスチャは2048以上を許容。
• ワールド規模: シーン全体のアクティブ三角形（視界内）を200k以下に抑える設計を推奨。チャンク化とLODで実現。
• 測定ツール: Resoniteのクライアント（可能なら内蔵プロファイラ/ログ）、SteamVRフレームタイム表示、Windows Performance Recorder/RenderDoc/Unity Profiler（ローカル検証）。
• 合格基準例: 1) 単体クライアントで10分間目標FPS未満のドロップが1%未満。2) アバター読み込み後のメモリ使用量が事前予算内。

数値はあくまで初期目安です。ユーザー数・デバイスによって最適値は変わります。

アバター移行の実務手順（エクスポート→変換→インポート→検証）

アバター移行は工程が多く、フォーマットとシェーダが肝になります。ここではツール推奨と具体設定、検証項目を示します。

元データの整理

まず現行アセットを検査・最小化します。作業しやすい状態にしてからエクスポートします。

• 使用ソフト・バージョン（例: Blender 3.5〜4.x、Unity 2020/2021 LTS等）を記録する。
• 元ファイル（.blend/.fbx）、テクスチャ、アニメーション、BlendShape一覧、IK/リグ情報をドキュメント化する。
• 不要な履歴・未使用素材は削除し、シーンは「テスト用最小構成」にする。
• 変換前にスケール・回転を適用（Blender: Ctrl+A で Location/Rotation/Scale を適用）する。

推奨エクスポート形式と具体的設定（glTFを優先）

glTF 2.0（.glb）を第一候補とします。PBRとモーフ（BlendShape）対応が標準化されており、移植性が高い場合が多いです。なお、モーフの保持はエクスポータとインポータの設定依存です。

• 推奨ツール/バージョン（例）: Blender 3.5〜4.x（安定リリースを使用）。glTFエクスポータはBlender標準を利用。
• Blender側エクスポート手順（代表的なチェック項目）:
• すべてのスケール・回転を適用する。
• アーマチュアはオブジェクトモードで一つのルートにまとめる。
• 形状キー（BlendShape）を整理し、Basis 名が存在することを確認する。
• マテリアルはPBR（Metallic-Roughness）に揃えるか、ベイクしてPBRマップに変換する。
• エクスポート設定（例）: Format = glTF Binary (.glb)、Include = Selected Objects、Apply Modifiers = ON、Export → Shape Keys = ON、Skinning = ON、Animations = ON、UVs & Normals = ON、Transform → Forward = -Z、Up = Y（BlenderのglTFデフォルト）。
• テクスチャは可能なら埋め込む（.glb）か同梱してパス管理を簡素化する。
• 検証: glTF-Validator（Khronos）で検証する。必須メタデータ・不整合を検知できます。
• glTF spec: https://www.khronos.org/gltf/
• Validator: https://github.com/KhronosGroup/glTF-Validator
• 注意点: glTFはmetallic-roughnessを前提とするため、specular-gloss等がある場合は変換が必要です。BlendShape が残るかはエクスポータのバージョンや設定で変わるため、必ずインポート先でモーフを確認してください。

FBXを使う場合の注意

FBXはアニメーションやリグの互換で広く使われますが、マテリアル表現やモーフで差異が出やすいです。

• 推奨FBXバージョン: FBX 2014/2015（FBX 7.4/7.5）互換でエクスポートするのが無難です。
• エクスポート時はスケール・回転の適用、アニメーションはBake、スキニング（Weights）を含める。
• Unity経由で変換するケース: Unity上でFBXを読み込み、必要に応じてglTFに変換するワークフローも検討する。

glTF最適化の流れ（推奨ツール）

容量・描画負荷を下げるための一般的なツールと用途を示します。各ツールの最新ドキュメントを参照してください。

• glTF-Transform（Prune/Weld/Quantize）: 不要データの削除、頂点結合、クォンタイズ。ドキュメント: https://gltf-transform.donmccurdy.com/
• gltfpack（メッシュ圧縮・meshopt）: サイズ削減とランタイム圧縮。ドキュメント: https://github.com/zeux/gltfpack
• Draco（必要時）: 高圧縮だがCPU負荷と互換性を考慮して使用。
• ワークフロー例: Blender → .glb export → glTF-Transform で prune/quantize → gltfpack で meshopt 圧縮 → Validatorで検証。

Resonite側でのインポートと再設定

ResoniteのインポータUIは変わる可能性があります。基本的な検証・再設定手順を示します。

• アセットアップ: .glb をアップロードし、マテリアルがPBRで表示されるか確認する。色味とガンマ（sRGB/Linear）をチェックする。
• マテリアルとシェーダ: プラットフォーム固有のノード（Emissive、AlphaCutoff等）に置き換える。特殊表現はテクスチャベイクで代替する。
• BlendShape/表情: インポータでモーフが残るか確認し、Resonite側の表情システムにマップする。名前とインデックスの対応表を作成しておくと管理が楽です。
• リギング/IK: IKの再設定やリターゲットが必要な場合は小さなプロトタイプで確認する。
• 最終確認: 見た目、アニメ、表情、コライダー、物理の動作、パフォーマンスをチェックする。

受け入れテストとチェック項目

導入前に明文化された受け入れ基準で判定します。代表的なチェック項目は以下です。

• 見た目: テクスチャ欠落や法線反転がないこと。
• 挙動: BlendShape、アニメ、IK が期待通りに動くこと。
• 性能: 事前に定めたFPS/メモリ/ロード時間の基準を満たすこと。
• ファイル: ファイル形式・バージョン・メタデータが規約に合致していること。
• 権利: 使用素材の権利関係がクリアであること。

合格条件はプロジェクト毎に数値で定め、テストログを保存してください。

ワールド／シーン移行とノードベーススクリプトへの置換（Resonite）

ワールド移行は同期設計と負荷設計が鍵です。必須機能を見極め、段階的に移行します。

要素の棚卸し

移行対象となるワールド内の全要素を洗い出します。これにより優先度と工数見積りが可能になります。

• 動的要素（トリガー、ドア、UI、メディアプレイヤー、インベントリ、ネット同期オブジェクトなど）をリスト化する。
• 各要素に「必須度」「同期要否」「負荷推定」を付与する。

スクリプト→ノードへの置換戦略

既存のUdonやカスタムスクリプトは機能単位で分解し、ノード化します。段階的に進めて小さな検証を重ねます。

• 単純な状態遷移やUI操作はノードで移植しやすいです。
• ネットワーク同期が必要な場合はオーナーシップとイベント設計を明確にします。
• 複雑な処理は小さなプロトタイプで性能と同期を検証してから本実装に統合します。

メディア共有・同期再生・インベントリの扱い

メディアやインベントリは同期設計と永続化が重要です。特に外部DBを使う場合は運用と法的要件を満たす設計にします。

• メディア同期: リーダー（ホスト）＋タイムコード方式やシーク同期で再生ズレを抑える。遅延が許されない場合はリトライやバッファ管理を組み込む。
• インベントリ: アイテムID、所有権、永続化仕様（外部DBを使うか等）を決める。外部保存は個人情報保護と通信の暗号化を必須にする。
• 永続化の設計: スキーマは最小限の個人情報で済ませ、外部APIは認可（OAuthなど）とログ監査を導入する。

大規模最適化とストリーミング対策

大きなワールドはチャンク化とストリーミングで対応します。レンダリング負荷とネットワーク負荷を分離する設計が有効です。

• シーン分割（チャンク化）、インスタンス化、LOD、テクスチャ圧縮を組み合わせる。
• ベイクライトやライトプローブを活用してランタイム負荷を下げる。
• オクルージョンやバッチングでドローコールを削減する。

段階的テスト計画・トラブルシューティング・外注と運用

移行プロジェクトを安全に進めるためのテスト計画、トラブル対応、外注時の実務ポイントを示します。

段階的テストチェックリストと合格基準

段階を分けてリスクを最小化します。各フェーズで数値やログを基に合否判定します。

• フェーズ0（準備）: アカウント、ツール、元データのバックアップを確認。
• フェーズ1（小規模：アバター1体）: 表示、BlendShape、リップシンク、IK、トラッキングを個別検証。目標fpsを満たすことを合格基準にする。
• フェーズ2（ワールド／機能）: ノード挙動、同期再生、インベントリを限定ユーザーで検証。複数クライアントで整合性を確認する。
• フェーズ3（ベータ運用）: 招待ユーザーで運用しログとフィードバックを収集。重大バグはリリース前に修正する。
• フェーズ4（公開）: 監視とパッチ体制を整備する。

各フェーズでの合格基準はプロジェクトごとに明文化し、チェックリストをテスト実行ログに添付してください。

よくあるトラブルと対処法

頻出する問題と実務的な対応例を示します。

• インポートでモーフやボーンが消える: エクスポート設定（Shape Keys/Skins/Animations）を確認し、別フォーマット（glTF/FBX）で再出力して比較する。
• マテリアル崩れ・色味差: PBRマップの割当と色空間（sRGB/Linear）を確認。特殊効果はベイクで代替する。
• 表示アーティファクト（法線/UV）: 法線の向き、UV重複、二重面を修正する。
• パフォーマンス低下: テクスチャ解像度、LOD、動的オブジェクトの削減、メッシュ圧縮を行う。
• 権利関係トラブル: ライセンスを再確認し、必要なら差し替えまたは権利者と合意を得る。

外注時の発注テンプレと費用の前提

外注に出す場合は成果物・前提条件を明確にします。費用目安は前提に大きく依存します。

• 発注時に含めるべき情報（必須）: 作業範囲、対象ファイル、出力形式（.glb/.fbx）、使用ツールとバージョン、テストケースと合格基準、納期、修正回数、成果物の定義（元ファイル必須）、権利移転の範囲。
• 成果物の例: 元ファイル、エクスポート済ファイル、マテリアルマッピング表、ノード構成図、テストログ、保証期間。
• 費用の目安（参考・前提付き）:
• 軽微なアバター移行（既存リグ良好、1回の修正を含む）: 約1万円〜5万円。
• 複雑なリグ／表情調整（複数BlendShape、カスタムリグ）: 約5万円〜20万円。
• ワールド移行・最適化（規模と同期要件に依存）: 20万円〜（大幅に増減）。
• 前提の明示: 上記は「既存データあり」「1回のリビジョンを含む」「納期2〜3週間」等の前提で変動します。必ずSOW（作業範囲定義）で前提を明文化してください。

運用・保守ワークフロー（CI/CD とロールバック）

運用は発注後も継続的に発生します。自動化と監視を組み込みます。

• ワークフロー例: 開発ブランチで作業 → CIでglTF/FBX検証・軽量化チェック → アーティファクト生成 → ステージングへデプロイ → 検証 → 本番デプロイ。
• ロールバック: 各リリースはタグ付きでアーティファクトを保管し、迅速に前バージョンへ戻せる運用を構築する。
• 監視: パフォーマンス指標（FPS、ロード時間、エラー率）を継続的に監視し、アラート閾値を決める。

CIの具体実装は組織の環境に依存しますが、必須チェックとしてglTF Validator、リソース容量チェック、簡易のパフォーマンステストは入れてください。

参考リソース（公式ドキュメント中心）

公式ドキュメントや信頼できるツールの参照を優先してください。

• Resonite 公式サイト: https://resonite.com/
• Resonite（Steam）: https://store.steampowered.com/app/2519830/Resonite/
• glTF（Khronos）仕様: https://www.khronos.org/gltf/
• glTF Validator: https://github.com/KhronosGroup/glTF-Validator
• Blender glTFエクスポータ（公式ドキュメント）: https://docs.blender.org/manual/en/latest/addons/import_export/scene_gltf2.html
• glTF-Transform（最適化ツール）: https://gltf-transform.donmccurdy.com/
• gltfpack（メッシュ圧縮）: https://github.com/zeux/gltfpack
• Git LFS ドキュメント: https://git-lfs.github.com/
• FBX 開発者情報（Autodesk）: https://www.autodesk.com/developer-network/platform-technologies/fbx-sdk-2020-2
• 法令・プライバシー（参考）: GDPR 一般解説 https://gdpr.eu/（国別法令は各国の公式情報を参照）

上記リンクは仕様根拠やツール使用方法の確認に有用です。Resonite固有の機能やUIは公式ドキュメントとリリースノートで随時確認してください。

まとめ：Resonite移行の要点整理

Resonite移行では、シェーダ・スクリプトの置換と互換性検証が主要な工数になります。小さなテストから段階的に進め、バージョン管理・受け入れ基準・法的確認を明文化して進行してください。

• まずは「アバター1体」で小規模検証し、エクスポート設定（glTF推奨）とインポータの挙動を確認する。
• シェーダはテクスチャベイクやノード再実装で代替する。BlendShapeはエクスポータ/インポータ依存のため必ず検証する。
• ワールドは機能を分解してノード化し、同期設計とチャンク化で負荷管理する。
• バージョン管理（Git + LFS）、CIでの自動検証、アーティファクト保管、ロールバック体制を整える。
• インベントリや外部DBを使う場合はプライバシー・セキュリティ・同意取得を必須にする。
• 仕様変更リスクを考え、公式ドキュメントとリリースノートを定期的に確認する運用を組み込む。

各項目はプロジェクト固有の要件で調整してください。実務での移行を確実にするには、上記チェックリストに沿った計画と段階的検証が有効です。