glTF 2.1 のアップデートの内容が公開！複雑なシーンへの対応や利便性向上など

2026年6月11日（現地時間）- Khronos® 3D Formats Working Groupより、コア仕様の後方互換性を維持した改訂版となる「glTF 2.1」の計画が発表されました。

アップデートの目的と背景

2017年の「glTF™ 2.0」リリース以来、glTFフォーマットはメッシュ圧縮、テクスチャ最適化、3D Gaussian Splattingなど、豊かなエコシステムへと成長を遂げました。今回の「glTF 2.1」の最大の目的は、「単一のアセットで機能していたglTFの利便性を、大規模で複雑に構成されたシーンでも同様に発揮させること」にあるとのことです。

今回のリリースに含まれるすべての機能は、相互運用性を損なう独自ルールの採用や、回避策の使用を余儀なくされていた現場の課題を解決するものとなっています。

対象ユーザー別の主な改善点とメリット

• アセット制作者およびパイプラインチーム： サムネイル画像をglTFファイルに直接埋め込むことが可能になり、レンダラーを通さなくてもアセットライブラリを閲覧できるようになります。
• 大規模シーンの開発者： デジタルツイン、BIM（ビルディング・インフォメーション・モデリング）、スマートシティ、地理空間、シミュレーションなどにおいて、複数ファイルからなるシーングラフを構築・配信するための標準的な手段が提供されます。
• エンジンおよびランタイム開発者： ShapesやBVH（Bounding Volume Hierarchies）による空間プリミティブの標準化、拡張機能の構築に役立つアクセサコンポーネントタイプの拡充、ツール間でオブジェクトを安定して参照できるUnique IDs（一意のID）が提供されます。
• 3Dストリーミング開発者： OGC 3D Tilesの拡張機能で実証された空間分割、アベイラビリティマップ、LOD、ストリーミングヒントなどを活用し、複雑なシーンを基盤としたプログレッシブ配信を構築できるようになります。
• すべてのユーザー： 64ビットのGLBフォーマットにより、従来の4GiBというファイルサイズ上限が撤廃されます。また、ほとんど使用されていなかった「複数シーン（multiple-scenes）」パターンが正式に非推奨となり、仕様が整理されます。

glTFの基本理念を継承

glTF 2.1 の各機能は、「ランタイムにおける 3D アセットの効率的で確実な転送とロード」という、配信フォーマットとしての glTF の基本的な役割 に沿って設計されています。 オーサリング（制作）フォーマットへ用途を広げるのではなく、複数のアセットで構成される複雑なシーンを配信できるよう、拡張が行われています。

また、glTF は OpenUSD のような コンテンツ制作エコシステムを補完する位置づけにあり、制作パイプラインで構築されたシーンを、自己完結型で相互運用可能な glTF として配信することが可能になります。

複雑なシーンへの対応

工場のデジタルツインは多数の機器モデルから構成され、都市ブロックは建物やインフラ、地形といった複数の要素で成り立っています。こうしたシーンは単一ファイルとして作成されるのではなく、複数のアセットを組み合わせて構築されるのが一般的です。しかし、従来の glTF 2.0 では、これらを一つの大規模ファイルにまとめるか、独自仕様で複数ファイルを管理する必要があり、大規模プロジェクトで glTF を採用する際の課題となっていました。

glTF 2.1 では、連携する複数のコア機能によってこの課題に対応しています。

• External Assets：他の glTF ファイルを参照し、ロード時に階層内へインスタンスとして組み込むことが可能
• Packaging：構成されたシーンと依存関係を一つの自己完結型アセットとして配信
• Shapes：空間プリミティブがコア仕様に追加
• Bounding Volume Hierarchies（BVH）：Shapes を利用し、大規模シーンのカリング、ストリーミング、クエリ処理を効率化

これらすべての基盤として「Unified File References（統合ファイル参照）」が用意され、リソースの参照メカニズムが一貫したものになります。

外部アセット

「External Assets」により、glTFファイルから宣言的に他のglTFファイルを参照し、自身のシーングラフ内でモデルとしてインスタンス化することが可能になります。CADやBIMで馴染み深い「アセンブリファイルがパーツファイルを参照する」構造に似ており、glTF 2.1ではこの解決がロード時に行われます。

これにより、独立して制作・管理された多くのファイルから大規模なシーンを構成できます。同じアセットを何度でもインスタンス化できるため（例：1つの機器モデルを1回ロードして1000回再利用）、大規模で反復的なシーンをコンパクトに配信可能です。

また、宣言的な参照であるため、アプリケーションが必要と判断したタイミングでコンテンツを取得する「遅延ロード」が可能となり、プログレッシブなシーンストリーミングの基礎となります。なお、依存関係を予測可能にするため、アセット間の循環参照は厳しく禁止されています。

 詳細仕様はこちら: External Assets Explainer

外部アセットのパッケージ化

外部のglTFファイルをURI参照ではなく、バッファビューとして埋め込むことで、ファイルをパッケージ化することが可能です。ホストファイルの files 配列が仮想ファイルシステムとして機能し、埋め込まれたファイル内のURIは、実際のファイルシステムやネットワークではなく、この配列に対して解決されます。

これにより、テクスチャ、バッファ、ネストされたglTFファイルなどの依存関係をすべて保持したまま、完全に自己完結した単一のglTFファイルを作成できます。元のファイル構造やURIを変更することなく、配布やアーカイブに最適なアセットを構築でき、複数の機器モデルで共有されるテクスチャなども重複せず効率的に保存されます。

詳細仕様はこちら: Packaging External Assets Explainer

Shapes（形状）

物理パイプラインや空間クエリシステムで求められていた、Box（箱）、Sphere（球）、Capsule（カプセル）、Cylinder（円柱）、Plane（平面）などの暗黙的幾何学形状（Implicit geometric shapes）がコア仕様に導入されます。

従来は明示的なメッシュデータを用意する必要がありましたが、今後はトップレベルの shapes 配列で定義可能になり、保留中であったKHR_implicit_shapes拡張機能に代わって標準化されます。将来的には拡張機能によって、さらに複雑な形状が追加される余地も残されています。

詳細仕様はこちら: Shapes Explainer

Bounding Volume Hierarchies：BVH

効率的な空間クエリ（衝突判定、オクルージョンカリング、レイキャストなど）に不可欠なバウンディングボリューム（境界ボリューム）が標準化されます。新しい boundingVolume ノードプロパティを使用し、ノードのコンテンツを完全に囲む単純な幾何学形状（Shapes）を設定できます。

これらはメッシュだけでなく、ライトやカメラ、参照アセット全体を囲むことも可能で、階層化することでトラバース（走査）コストを大幅に下げることができます。アプリケーションは、このボリュームの画面上のサイズなどを基準にして、コンテンツの遅延ロードを制御することが可能になります。

詳細仕様はこちら: BVH Explainer

統合ファイル参照

glTF 2.0では、外部コンテンツの参照方法（URI）が buffers や images など複数箇所に分散しており、ツールがファイルの依存関係を正確に把握することが困難でした。

glTF 2.1では、新しいトップレベルの files 配列が導入され、参照方法が統一されます。ファイルタイプに依存せず、mimeType と共に管理されるため、ツールは buffers、images、files の3箇所を確認するだけで、glTFファイルのすべての外部依存関係を把握できるようになります。

 詳細仕様はこちら: Unified File References Explainer

複数シーンの非推奨化

glTF 2.0では、1つのファイルに複数のシーンを含めることが許可されていましたが、実際にはほとんど使用されず、ツールの実装においても曖昧さの要因となっていました。

今回追加された構成機能により、その役割が完全に代替されたため、glTF 2.1では複数シーンのパターンが正式に非推奨となります。これは破壊的変更ではなく、既存のファイルは引き続き有効ですが、新規コンテンツでの利用は推奨されません。

詳細仕様はこちら: Multiple scenes deprecation explainer

利便性と品質の向上

複雑なシーンへの対応に加え、日常のパイプラインやワークフローの摩擦を減らす、実用的で堅実なアップデートが多数含まれています。

サムネイル機能

glTFファイルにサムネイル画像を直接宣言・埋め込むことが可能になります。これにより、アセット管理システム（DAM）やファイルブラウザにおいて、3Dエンジンを起動してレンダリングを行うことなくプレビューを表示できるようになります。モデルの一覧表示が高速化され、独自のポーズやブランディング画像を設定することも可能です。

詳細仕様はこちら: Thumbnails Explainer

64ビット バイナリフォーマット

従来のGLBバイナリコンテナはチャンクサイズが32ビットで管理されていたため、4GiBの容量制限がありました。高精細なコンテンツや大規模な点群データ、3D Gaussian Splattingなどに対応するため、glTF 2.1ではバイナリフォーマット バージョン3が定義され、制限が「8EiB（エクサバイト）」へと大幅に引き上げられました。ツールは互換性のためにバージョン2と3の両方をサポートする必要があります。

詳細仕様はこちら: 64-bit binary explainer

拡張機能のコア仕様への昇格

以下の拡張機能がglTF 2.1のコンプライアンス要件として必須化（コア昇格）されました。

• EXT_texture_webp (WebPテクスチャのサポート)
• KHR_materials_emissive_strength (発光強度の調整)
• KHR_mesh_quantization (メッシュの量子化)
• KHR_node_visibility (ノードの表示/非表示切り替え)

これにより、制作者はフォールバックを意識することなくWebPテクスチャを使用でき、ツール間のデータのやり取りがよりスムーズになります。

詳細仕様はこちら: Promoted Extension Functionality Explainer

非連続属性の許可

これまで、テクスチャ座標などの属性は TEXCOORD_0、TEXCOORD_1 のように0から始まる連続した数値である必要がありました。

glTF 2.1ではこの制限が緩和され、TEXCOORD_0 が存在しなくても TEXCOORD_1 を宣言できるようになります。これにより、他のフォーマットからの変換が容易になります。

詳細仕様はこちら: Non-Sequential Attributes Explainer

アクセサコンポーネントタイプの追加定義

科学的ビジュアライゼーションや高精度のエンジニアリングの需要に応えるため、アクセサのコンポーネントタイプに SIGNED_INT, DOUBLE, HALF_FLOAT, SIGNED_INT64, UNSIGNED_INT64 が定義されました。

これらは即座に標準メッシュなどで使えるわけではありませんが、将来の拡張機能（例：KHR_accessor_float16 や KHR_accessor_float64など）がこれらを共通基盤として利用できるようになります。

詳細仕様はこちら: Accessor Component Type Explainer

Unique IDs の導入

外部アセットの参照やクロスファイルでのオブジェクト指定を安定させるため、ファイル内で一意となる Unique IDs (UIDs) が導入されます。これまでの name プロパティは一意である保証がありませんでしたが、UIDを用いることで、ツールチェーンやインポーターは特定のオブジェクトを確実に特定・アドレス指定できるようになります。

詳細仕様はこちら: Unique IDs Explainer

今後の展開

以上で紹介した機能は、コミュニティ主導の設計プロセスを通じて合意されたglTF 2.1の確定的機能です。詳細な仕様やスキーマ定義については、引き続きglTF 2.1のGitHub Issue上でオープンに開発が進められています。

ロサンゼルスで開催される「SIGGRAPH 2026」において、7月23日に第7回「glTF Ecosystem Forum」が開催され、glTF 2.1に関するライブディスカッションが行われる予定です（詳細はこちら）。

glTF 2.1は、ファイルフォーマットを軽量かつ後方互換性を保ちながら、表現できる幅を大きく広げ、日々のワークフローの摩擦を解消します。Khronos 3D Formats Working Groupの活動や仕様策定に関心のある方は、公式ウェブサイト（khronos.org/gltf）をご覧ください。また、標準化活動に関心のある企業はKhronos Groupへの参加もご検討ください。

Introducing glTF 2.1 with Complex Scenes