2025年7月21日Kris

Blender からリリースまで：エンドツーエンド圧縮の実践

3D 圧縮パイプラインテクスチャ圧縮頂点圧縮glTF

シリーズもここまで来て、ツール、原理、選定はすべて解説しました。最後のこの記事では、すべてをひとつの実行可能なパイプラインにまとめます。実際のBlenderモデルから始めて、段階的に圧縮し、各ステップでファイルサイズ、VRAM使用量、ロード時間の変化を記録し、最終的に50MBの「デブ」がモバイルで一瞬で開ける5MBのモデルに痩せられるかを見ていきます。

対象読者：これまでの5記事を読んで、実際に手を動かす準備ができている方。この記事では新しい概念は出しません。再現可能な手順、コマンド、スクリプトだけを提供します。

スタート地点：実際のPBRモデル

非常に典型的なECショーケースモデルをサンプルとして使います。高精細なプロダクトモデルで、完全なPBRテクスチャを備えています。

初期指標	数値
Blender ソースファイル	~120MB（エクスポートしていないハイポリモデルを含む）
GLB エクスポート (float32 + PNG)	~50MB
頂点数	約18万
テクスチャ	6枚の4096×4096（albedo、normal、roughness、metallic、AO、emissive）
VRAM使用量（6枚フル解凍）	~520MB
目標	ファイル ≤ 5MB、VRAM制御可能、モバイルで一瞬で開く

50MBのファイル、520MBのVRAM——このモデルをそのままモバイルに載せれば確実にクラッシュします。段階的に進めていきましょう。

ステップ0：Blenderからの正しいエクスポート

圧縮の最初の関門は実はエクスポートです。多くの人がここで出血します。

BlenderからglTFをエクスポートする際の重要な設定：

フォーマット：glTF Binary (.glb)（単一ファイルで転送しやすい）
ジオメトリ：Normals、Tangents にチェック（PBR法線マップにはタンジェントが必要）
UV：エクスポートを確認（デフォルトでオン）
テクスチャ：Automatic または JPEG（この段階のテクスチャフォーマットは問わない。後で再圧縮するが、エクスポートされていることを確認）
圧縮：まだ Blender 標準のメッシュ圧縮にはチェックを入れない。より専門的なツールを使うため
変換：+Y Up（glTF標準）
データ：必要なものだけにチェック（アニメーション、カメラ、ライトは不要ならエクスポートしない。容量削減）

エクスポート後の model.glb：50MB、6枚のPNGテクスチャ、float32頂点。これがベースラインです。

ここでのよくある落とし穴：Blenderはデフォルトで不要なメッシュや非表示の補助オブジェクトも一緒にエクスポートします。エクスポート前に File > Clean Up > Purge Orphans を実行し、アウトライナーでエクスポートしたいオブジェクトだけを選択してください。

エンドツーエンドパイプライン全景

パイプライン全体を図にすると、全体像が見えます：

Blender ソースファイル
   │  エクスポート .glb（float32 + PNG）            50MB
   ▼
[1] 冗長除去＋重複頂点の溶接（gltf-transform）   ~45MB
   │
[2] 頂点圧縮：MeshOpt（gltfpack / gltf-transform） ~30MB
   │
[3] テクスチャ圧縮：PNG → KTX2（ETC1S/UASTC）     ~6MB
   │
[4] (オプション) ジオメトリ簡略化 LOD（simplify）         ~4-5MB
   ▼
最終 model-final.glb                          ~5MB
   │
エンジンロード（Three.js / Babylon.js）→ ランタイムトランスコード → リリース

各ステップの数値は以下の表でリアルタイムに追跡します。

ツールチェーン：どれを選ぶか

圧縮ツールはいくつかあるので、まず比較しておきます。選び間違えないように。

ツール	強み	弱み	適している
gltf-transform	オールラウンド、テクスチャ＋頂点を一括で扱える、API化・スクリプト化可能	極限の圧縮率は専用ツールに劣る	推奨メイン、ほとんどのシナリオ
gltfpack	頂点圧縮に特化、MeshOptネイティブ対応	テクスチャ圧縮機能は弱い	頂点が密集、MeshOptの細かい制御が必要
toktx	テクスチャ圧縮で最も専門的、パラメータが豊富	テクスチャのみ、モデル全体は扱えない	単一テクスチャの微調整
gltf-pipeline	老舗、Draco対応	メンテナンス不活発、機能が少ない	既存のDracoプロジェクト
オンラインツール（gltf.report）	インストール不要	自動化・大量処理には不向き	実験、単発タスク

メイン推奨：gltf-transform で全工程を進め、必要に応じて gltfpack で頂点を補完、toktx で単一テクスチャを調整します。以下のすべての手順は gltf-transform に基づきます。

ステップ1：冗長除去＋溶接

モデルには重複頂点、未使用のノードやマテリアルがよく含まれています。まずはクリーンアップします。

gltf-transform optimize model.glb step1.glb --weld --prune

段階	ファイルサイズ	VRAM	変化
ベースライン	50MB	~520MB	—
Step 1 冗長除去	45MB	~520MB	-5MB（VRAMは変わらず、テクスチャはそのままなので）

VRAMはほとんど変わりません。これは予想通りです。冗長除去は主に頂点と構造を節約するもので、テクスチャがVRAMの大部分を占めています。

ステップ2：頂点圧縮 MeshOpt

gltf-transform optimize step1.glb step2.glb --meshopt --weld --prune

--meshopt は頂点を16ビットに量子化し、MeshOptのロスレス符号化を適用し、自動的に EXT_meshopt_compression 拡張を追加します。

段階	ファイルサイズ	VRAM	変化
Step 1	45MB	~520MB	—
Step 2 + MeshOpt	30MB	~520MB	-15MB（頂点部分）

VRAMはまだ約520MB？そうです。頂点はVRAMに占める割合が小さい（10-20%）ため、頂点を削ってもVRAMへの影響は限定的です。真のVRAMの大食いはテクスチャです。それは次のステップで解決します。

ステップ3：テクスチャ圧縮 PNG → KTX2

このステップがコストパフォーマンスの王者です。

gltf-transform optimize step2.glb step3.glb \
  --texture-compress basisu \
  --meshopt --weld --prune

--texture-compress basisu は各テクスチャを自動的に判別します。カラーテクスチャ（albedo、emissive）はETC1S、データテクスチャ（normal、roughness、metallic、AO）はUASTCを使用します。

段階	ファイルサイズ	VRAM	変化
Step 2	30MB	~520MB	—
Step 3 + KTX2	6MB	~70MB	-24MB ファイル / -450MB VRAM

このステップがパイプラインの転換点です：

ファイルが30MBから6MBに減少
VRAMが520MBから約70MBに減少——6枚の4096テクスチャが「解凍後の生ピクセル」から「ブロック圧縮」に変わり、各テクスチャが約87MBから約11-14MBに減少

VRAMが一桁減りました。これがモバイルで動作するかどうかの鍵です。

ステップ4：（オプション）ジオメトリ簡略化

さらに小さくしたい場合、かつシーンが頂点精度の低下を許容するなら、ジオメトリ簡略化を追加できます。

gltf-transform optimize step3.glb final.glb \
  --texture-compress basisu \
  --meshopt \
  --simplify --simplify-ratio 0.5 \
  --weld --prune

--simplify-ratio 0.5 は頂点の約50%を保持することを意味します。

段階	ファイルサイズ	VRAM	変化
Step 3	6MB	~70MB	—
Step 4 + 簡略化 0.5	4.5MB	~70MB	-1.5MB（VRAMはほぼ変わらず）

簡略化は主にファイルサイズを節約し、VRAMへの影響はほとんどありません。代償としてモデルの詳細が低下します。近くで見ると気づくでしょう。EC製品ページでは過度な簡略化は通常推奨されませんが、建築物や大規模シーンには適しています。

効果追跡総合表

4つのステップを重ねて全体像を見ます（上記サンプルに基づく数値で、規模感を示すためのものです）：

ステップ	ファイルサイズ	VRAM	累積削減率
ベースライン（float32 + PNG）	50MB	~520MB	—
+ 冗長除去溶接	45MB	~520MB	-10%
+ MeshOpt 頂点	30MB	~520MB	-40%
+ KTX2 テクスチャ	6MB	~70MB	-88% ファイル / -87% VRAM
+ ジオメトリ簡略化(0.5)	4.5MB	~70MB	-91% ファイル

結論：テクスチャ圧縮がファイルサイズとVRAMの大部分の削減に貢献しています。頂点圧縮は錦上添花（さらに良いもの）、テクスチャ圧縮は雪中送炭（緊急の助け）です。これは第1回の記事の診断と完全に一致します——テクスチャが体積の80%を占め、それを最適化するのが最も効果的です。

ワンコマンド版：面倒なら一発で

段階的に見たくない場合は、すべての最適化を一度に実行します：

gltf-transform optimize model.glb model-final.glb \
  --texture-compress basisu \
  --meshopt \
  --simplify --simplify-ratio 0.5 \
  --weld --prune

この1コマンド = 冗長除去 + 溶接 + 頂点MeshOpt + テクスチャKTX2 + ジオメトリ簡略化。90%のシナリオでこれで十分です。段階的に行うのは主に理解とパラメータ調整のためです。

環境を整えたくない？Any3D オンライン圧縮を使う

上記の gltf-transform コマンドとスクリプトをローカルで実行するには、Nodeのインストール、ツールチェーンの設定、多くのパラメータの記憶が必要です。Any3Dのオンライン圧縮ツールはこれらをすべて省きます：

スクリプトのダウンロード不要、環境設定不要——ブラウザを開くだけで使えます
モデルはサーバーにアップロードされない——すべてブラウザ内でローカル処理され、ファイルがデバイスから離れません
ビジュアル設定——テクスチャKTX2、頂点MeshOpt、ジオメトリ簡略化をスライダーで調整し、リアルタイムプレビュー
ワンクリックで複数バージョン——モバイル/デスクトップ/VRプラットフォームに応じて圧縮結果をエクスポート

GLBを選び、ターゲットプラットフォームを選び、クリックするだけで圧縮されたモデルが得られます。内部では上記のコマンドラインと同じ（gltf-transform）ですが、ハードルがゼロで、ターミナルに触れる必要はありません。

よくある落とし穴 FAQ

圧縮後にモデルが真っ黒になる/テクスチャが表示されない

99%はカラースペースの問題：カラーテクスチャにsRGBが設定されていない。Three.jsでは texture.colorSpace = THREE.SRGBColorSpace。
toktxでカラーテクスチャに --srgb を付け忘れ。

法線マップを圧縮したらライティングがおかしい

法線マップにETC1Sを使ったので、UASTCに変更。
法線マップがDirectXスタイル（緑チャンネルが下向き）で、エンジンがOpenGLスタイルの場合、Gチャンネルを反転させる必要がある。

モバイルで最初の画面読み込みで止まる

Dracoデコーダーのwasm追加ロード（追加リクエスト）が発生していないか確認。モバイル環境ではMeshOptを優先。
KTX2トランスコーダーのパス設定ミスにより、トランスコードが失敗してCPU解凍にフォールバックしている可能性。

圧縮後にファイルサイズが逆に大きくなった

テクスチャが小さすぎる（< 128px）場合、ブロック圧縮の固定オーバーヘッドによりKTX2化でサイズが増加することがある。
すでに圧縮済みのモデルを再度圧縮しても効果はない（むしろ肥大化する）。

簡略化後にモデルのメッシュが破綻する

--simplify-ratio が低すぎる場合は0.7〜0.8に引き上げる。
簡略化はハードサーフェス（機械、建築）には適していますが、有機的な曲面（キャラクター）では破綻しやすい。

一部のブラウザでKTX2の読み込みに失敗する

古いSafariや古いWebViewでは非対応。PNG/WebPへのフォールバックを用意するか、KHR_texture_basisu の fallback フィールドを設定。

シリーズまとめクイックリファレンス

全6回の要点をまとめたクイックリファレンスです。

ファイル容量の構成

構成要素	割合	最適化ツール
テクスチャ	70-85%	KTX2（最大の効果）
頂点データ	10-20%	MeshOpt / 量子化 / Draco
アニメーション	0-15%	キーフレーム削減 / 圧縮
その他	< 2%	不要データの整理

VRAM計算式

従来のフォーマット: VRAM = 幅 * 高さ * 4バイト * 1.333（ミップマップ込み）
KTX2ブロック圧縮: VRAM ≈ 上記の計算式 / 4（ETC1S） または / 2（UASTC）

頂点圧縮の選定

シナリオ	おすすめ
依存関係ゼロ・最もシンプル	純粋な量子化（`KHR_mesh_quantization`）
Web標準・バランス重視	MeshOpt
限界までの圧縮率・デコード待ち可能	Draco
ミニプログラム / パッケージサイズ重視	純粋な量子化 / MeshOpt（Dracoは避ける）

テクスチャ圧縮の選定

テクスチャタイプ	おすすめのエンコード
albedo / emissive（カラー）	KTX2 ETC1S
normal / roughness / metallic / AO（データ）	KTX2 UASTC
デスクトップWeb、ダウンロード速度最優先	WebP / AVIF
小さなテクスチャ（< 128px）	PNGを維持（KTX2化しない）

ワンライナーコマンド

# 全体最適化（テクスチャ + 頂点 + 簡略化）
gltf-transform optimize model.glb model-final.glb \
  --texture-compress basisu --meshopt \
  --simplify --simplify-ratio 0.5 --weld --prune

プラットフォーム早見表

プラットフォーム	テクスチャ	頂点
デスクトップWeb	WebP / KTX2	MeshOpt
モバイルWeb	KTX2 必須	MeshOpt
VR	KTX2 必須	MeshOpt + LOD
ミニプログラム	KTX2 / WebP	MeshOpt / 量子化
大規模シーン	KTX2 必須	MeshOpt + Draco + LOD

シリーズの振り返り

全6回を通じて、完全なワークフローを構築しました：

なぜこんなに重いのか：ファイル構成とVRAMの真実を把握
頂点圧縮の基本：量子化、MeshOpt、Dracoの仕組みと選択
テクスチャVRAM問題：PNG/JPGがGPUにとって非効率な理由
KTX2の実践：ETC1S/UASTCの使い分け、ツールチェーン、エンジン読み込み
選定ガイド：プラットフォーム・ユースケース別意思決定フレームワーク
本稿：Blenderから本番公開までのエンドツーエンドパイプライン

結論は一つです：まずボトルネック（通信量 / VRAM / フレームレート）を明確にし、適切なツールを選ぶこと。テクスチャ圧縮が最大の効果を発揮し、頂点圧縮が仕上げとなります。

本稿のスクリプトとクイックリファレンスを活用すれば、50MBのモデルを5MBへ、520MBのVRAM消費を70MBへと再現性高く削減できます。ぜひ実践してみてください。