プラットフォームで運命が変わる：圧縮方式セレクションガイド

これまでの4記事では、頂点圧縮とテクスチャ圧縮のツールについて解説してきました。しかし、ツールを使えることと、どれを選ぶべきか、どのシナリオで使うべきかは別問題です。この記事がその問いに答えます——しかも、読んだらすぐに決断できるようにします。

この記事を読み終えると、次の問いに答えられるはずです：自分のプロジェクトはどのプラットフォームで動くのか、ファーストビューのボトルネックはダウンロード速度かVRAMか、テクスチャと頂点にはそれぞれどの方式を選ぶべきか。

まず基本方針：ツール駆動ではなく、シナリオ駆動

この記事全体を通してたった1つの核心原則があります。このシリーズで繰り返し強調してきたことです：

「最高の」圧縮方式は存在しない。「シナリオに最もマッチする」方式だけがある。

選択に影響する3つの変数：

1. プラットフォーム/デバイス：デスクトップPC、モバイルブラウザ、VRヘッドセット、ミニアプリ——能力は天と地ほど違う
2. 使用方法：一度きりの表示（EC商品ページ）か、長時間の没入（VRゲーム）か
3. 主要なボトルネック：ダウンロード速度が遅いのか、VRAMが足りないのか、デコードがファーストビューを詰まらせているのか

まずボトルネックを明確にしてから、ツールを選びに戻る。以下のマトリックスは、この考え方を具体化したものです。

核心となる決定マトリックス：プラットフォーム × 推奨方式

これはこの記事で最も重要な表です。プラットフォーム別に、テクスチャと頂点それぞれの推奨方式とその理由を示します。

プラットフォーム / シナリオ	テクスチャ方式	頂点方式	主要ボトルネック	重要な理由
デスクトップWeb（PCブラウザ）	KTX2 または WebP	MeshOpt / 量子化	ダウンロード速度	VRAMは余裕、重要なのはファイルサイズと読み込み速度
モバイルWeb（スマホブラウザ）	KTX2（必須）	MeshOpt	VRAM	スマホのVRAMは限られる、テクスチャはブロック圧縮必須
WebXR / VRヘッドセット	KTX2（必須）	MeshOpt + LOD	VRAM + フレームレート	VRAM不足はクラッシュ、フレーム落ちは酔いの原因
ミニアプリ（LINE等）	KTX2 / WebP	MeshOpt / 純量子化	パッケージサイズ + 互換性	パッケージサイズ制限、重いデコーダーは避ける
EC商品表示	WebP（軽）/ KTX2（精）	MeshOpt	ファーストビュー速度	即座に表示が必要、サイズを速度に換える
大規模シーン / デジタルツイン	KTX2（必須）	MeshOpt + Draco + LOD	VRAM + draw call	テクスチャ多数、モデル大、全方位で圧縮

覚えておくべき判断基準：

• VRAMがボトルネックなら、KTX2は必須（モバイル、VR、大規模シーンのすべて）
• ダウンロード速度がボトルネックでVRAMに余裕があるなら、WebPで十分（デスクトップ、EC）
• ミニアプリなどパッケージサイズに敏感な環境では、DracoよりMeshOptを優先——デコーダーが小さく、互換性が高い
• 超大規模モデルでのみDracoを検討、ほとんどの中小モデルではMeshOptの方がバランスが良い

テクスチャ形式の全次元比較

「KTX2を使う」だけでは不十分です。具体的なテクスチャ形式について、すべての次元を比較します：

形式	ファイルサイズ	VRAM使用量	アップロード速度	互換性	画質	適用シナリオ
PNG	大	大（解凍後）	遅い	極めて広い	可逆	正確な数値/透明が必要、または古いプラットフォームの保険
JPG	極小	大（解凍後）	遅い	極めて広い	非可逆	カラーマップ、ネットワーク転送優先
WebP	非常に小	大（解凍後）	遅い	比較的広い	高い	デスクトップWeb、ダウンロード速度重視
AVIF	さらに小	大（解凍後）	遅い	漸進的	高い	新しいプラットフォーム、極限圧縮
KTX2 (ETC1S)	小	極小	速い	変換が必要	中（色は十分）	カラーマップ、モバイル/VR
KTX2 (UASTC)	中	小	速い	変換が必要	高い	法線/データマップ

最初の3行（PNG/JPG/WebP/AVIF）のVRAM使用量がすべて「大」であることに注意してください——ディスク上でどれだけ小さくても、VRAMに入るときは元のピクセルに解凍されます。これは従来形式の根本的な制限です。

ハイブリッド戦略は一般的です：重要なカラーマップはKTX2でVRAMを確保し、二次的なマップ（小さなemissiveなど）はWebPで手軽に。すべてをKTX2にする必要はなく、ボトルネックに応じて割り当てます。

決定フローチャート：ステップバイステップで選ぶ

マトリックスは結果を示し、フローチャートはその結果にどうたどり着くかを示します。

あなたのプロジェクトはどこで動く？
│
├─ デスクトップWeb（VRAM余裕あり）
│   └─ ファーストビューが遅い？
│       ├─ 遅い → WebP（またはAVIF）+ MeshOpt  [ダウンロード速度重視]
│       └─ 遅くないが、モデルが多い → KTX2 + MeshOpt [将来に備える]
│
├─ モバイルWeb / VR / 大規模シーン（VRAM逼迫）
│   └─ テクスチャはKTX2必須（カラーはETC1S、データはUASTC）
│       └─ モデルの頂点が超密？
│           ├─ はい → + Draco [極限圧縮、遅いデコードを受け入れる]
│           └─ いいえ → + MeshOpt [バランス型]
│
└─ ミニアプリ / 制限付きランタイム
    └─ パッケージサイズに敏感？
        ├─ 敏感 → 純量子化またはMeshOpt + WebP [デコーダーなし/小]
        └─ 許容 → MeshOpt + KTX2 [標準的な組み合わせ]

頂点圧縮 vs テクスチャ圧縮：どちらに投資すべきか

よく聞かれる質問：予算が限られている場合、どちらを先に最適化すべき？モデルの構成を見て判断します：

モデルの特徴	投資の重点	理由
PBRキャラクター/商品（テクスチャ多数）	テクスチャ圧縮	テクスチャが80%以上、頂点への投資はリターンが低い
CAD/スキャンモデル（頂点超密、テクスチャ少）	頂点圧縮	頂点が主要なボリューム
アニメーションキャラクター（ボーン+スキニング）	両方だが、頂点はDraco以外を優先	アニメーションデータも容量を食う、Dracoはアニメーション対応が弱い
建築/シーン（大規模、中程度のテクスチャ）	テクスチャ + LOD	テクスチャでVRAM節約、LODでdraw call節約

大まかな効果の順位：テクスチャKTX2 > 頂点MeshOpt/量子化 > ジオメトリ簡略化(LOD) > 頂点Draco。効果の高いものから先にやります。

ハイブリッド戦略：重要マップはKTX2、二次マップはWebP

すべてのテクスチャをKTX2に圧縮する価値があるわけではありません。典型的なPBRマテリアルには5〜6枚のマップがあり、すべてKTX2にすると工数がかかり、不要な場合もあります。

実用的な分類：

• KTX2必須：albedo（大きい、カラー）、normal（精度に敏感）、roughness/metallic（ライティングに影響）
• WebP/JPGで可：emissive（通常小さい）、AO（中低周波）、ディテール法線（ある場合）

判断基準：テクスチャが大きいか、高周波ディテールか、頻繁にサンプリングされるか。すべて該当 → KTX2；どれも該当しない → 従来形式で手軽に。

自動化セレクション：gltf-transformでワンクリック

gltf-transform の optimize コマンドは、ほとんどのシナリオで銀の弾丸です——テクスチャタイプを自動判定し、推奨戦略でテクスチャを圧縮し、オプションで頂点も処理します。

# インストール
npm install -g @gltf-transform/cli

# 標準最適化：テクスチャKTX2 + 頂点MeshOpt + 冗長データ除去
gltf-transform optimize model.glb model-optimized.glb \
  --texture-compress basisu \
  --meshopt

パラメータ説明：

パラメータ	機能	デフォルト
--texture-compress basisu	テクスチャをKTX2に圧縮（ETC1S/UASTC自動選択）	オフ
--meshopt	頂点にMeshOpt圧縮を有効化	オフ
--simplify	ジオメトリ簡略化（頂点削減、非可逆）	オフ
--weld	重複頂点をマージ	オン
--prune	未使用ノード/マテリアルを削除	オン

モバイル向けの「強力圧縮」組み合わせ：

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

デスクトップ向け「マイルド」組み合わせ（ディテール保持、テクスチャと頂点のみ圧縮）：

gltf-transform optimize model.glb model-desktop.glb \
  --texture-compress webp \
  --meshopt

スクリプトを書きたくない？Any3Dオンライン圧縮を使う

ローカルにNodeやツールチェーンをインストールしたくない？Any3Dオンライン圧縮 ならブラウザ内で直接処理できます——GLBを選んで、プラットフォーム（モバイル/デスクトップ/VR）に応じてビジュアルにパラメータ調整、モデルはサーバーにアップロードされず（すべてローカル処理）、ワンクリックで圧縮版をエクスポート。内部では上記のgltf-transformと同じエンジンですが、ゼロハードルです。次回のエンドツーエンド実践で完全なフローをまとめます。

一言メモ

• VRAMがボトルネック → KTX2、選択の余地なし
• ダウンロードがボトルネック、VRAM余裕あり → WebP/AVIFでも可
• デコーダーサイズに敏感 → MeshOpt > 純量子化 > Draco
• 超大規模モデル → その時だけDracoを検討
• 迷ったら → gltf-transform optimize をワンクリック実行、間違っていたら調整

次のステップ

選定フレームワークは完成しました。最終回は締めくくり：実際のモデルから始めて、Blenderエクスポート、テクスチャ圧縮、頂点圧縮、エンジン読み込みの全フローを完走し、完全な自動化スクリプトとシリーズのクイックリファレンス表を添付します。