第7章: ファイル形式の地図 — OBJ・FBX・glTF・USD

なぜ3Dのファイル形式はこんなに多いのか

第6章では、頂点バッファとインデックスバッファがGPUに渡され、ラスタライズやレイトレーシングで画面に描かれるまでを追いました。 この章では一歩手前に戻り、「その頂点やマテリアルをディスク上でどう保存し、ツール間でどう受け渡すか」を扱います。

画像ならPNGとJPEGでほぼ足ります。3Dでは、OBJ、STL、PLY、FBX、COLLADA、glTF、USD、3MF、VRMと、現役の形式だけでも両手で数えきれません。 形式が多いのは、運ぶ中身が多いからです。第3章から第5章で見た「形（メッシュ）」「見た目（マテリアル）」「動き（リグとアニメーション）」に、シーン階層やカメラ、ライトまで加わります。 そのうちどこまで運ぶか、誰が読むかで、設計が大きく変わります。

形式を一つずつ暗記しても、新しい形式が出るたびに覚え直すことになります。 この章では、各形式が「何のために作られたか」を一本の軸で整理し、選び方を判断できるようになることを目指します。

整理の軸 — オーサリング用か、ランタイム用か

一番役に立つ軸は、その形式がオーサリング用かランタイム用かという区別です。

• オーサリング用（交換・編集）: MayaやBlenderなどのDCCツール（Digital Content Creation、3D制作ソフト）の間で、作りかけのデータを失わずに受け渡すための形式です。リグの構造やツール固有の設定も含め、情報をなるべく多く残すことを優先します。読み込みに時間がかかっても問題になりません。
• ランタイム用（配信・表示）: 完成品をブラウザやゲーム、ARアプリに届けて表示するための形式です。ファイルが小さく、読み込んだらすぐGPUに渡せることを優先します。編集に必要な情報は落としてもかまいません。

Web開発に例えると、オーサリング用はPhotoshopのPSD、ランタイム用は配信用に書き出したJPEGやWebPに近い関係です。 PSDをそのままWebページに載せる人はいないのと同じで、3Dでも「制作用の形式」と「配信用の形式」を分けて考えます。 同じ対立は形式に限らず、データ構造（編集向けのhalf-edge構造と描画向けのインデックスバッファ）やマテリアル（映像向けのOpenPBRとリアルタイム向けのglTF PBR）にも繰り返し出てきます。

graph LR
  subgraph A[オーサリング用]
    FBX[FBX]
    DAE[COLLADA]
    USD[USD]
  end
  subgraph R[ランタイム用]
    GLTF[glTF / GLB]
    USDZ[USDZ]
    VRM[VRM]
  end
  subgraph S[用途特化]
    OBJ[OBJ 単純交換]
    PLY[PLY 点群]
    STL[STL 3Dプリント]
    TMF[3MF 3Dプリント]
  end
  FBX -->|変換| GLTF
  USD -->|パッケージ| USDZ
  GLTF -->|拡張| VRM

  style GLTF fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style USD fill:#3b82f6,stroke:#1d4ed8,color:#fff

この地図で見ると、USDは制作現場の上流に、glTFは配信の末端に位置します。 両者は競合というより補完関係にあり、以降の節で詳しく見ていきます。

古典的な3形式 — OBJ・STL・PLY

まず、今でも頻繁に目にする古い形式を3つ見ます。どれも単純で、そのぶん運べる情報が限られます。

OBJ — 人が読めるテキストの共通語

OBJはWavefront Technologiesが自社のAdvanced Visualizer向けに使い始めた形式です。登場時期は資料によって1980年代とも1990年ごろともされ、はっきりしません。 中身はテキストで、v（頂点座標）、vt（UV）、vn（法線）、f（面）を1行ずつ並べます。 マテリアルは別ファイルの.mtlに書きます。

# cube.obj（抜粋）
mtllib cube.mtl
v  -1.0 -1.0  1.0
v   1.0 -1.0  1.0
v   1.0  1.0  1.0
vt  0.0 0.0
vt  1.0 0.0
vt  1.0 1.0
vn  0.0 0.0 1.0
usemtl red
f 1/1/1 2/2/1 3/3/1   # 頂点/UV/法線 のインデックス（1始まり）

テキストエディタで開けばそのまま読めるうえ、ほぼすべてのDCCツールが読み書きできます。 「とにかく形だけ渡したい」ときの共通語としては今も現役です。 一方、アニメーションもリグも持てず、シーン階層はグループ分け程度しかありません。.mtlのマテリアルはPhong系の古いモデルで、PBRは非公式な拡張に頼ることになります。 テキストなのでファイルも大きくなります。 さらに単位を記録する仕組みがありません。1.0が1メートルなのか1ミリなのかは、読む側の解釈しだいです。

STL — 3Dプリンタのための三角形の羅列

STLは1987年に3D Systemsの光造形（Stereolithography）装置向けに作られた形式です。 中身は「法線1本と頂点3つ」からなる三角形をひたすら並べたものだけで、色もUVも単位もありません。 頂点を共有しないため、隣り合う三角形が同じ座標を何度も書き、データが冗長になります。

3Dプリントでは「中身が詰まった立体」として解釈できること、つまり第3章で見たウォータータイトなメッシュであることが前提です。 単位がないため、多くのスライサ（造形用ソフト）はミリとして読み、Blenderはメートルとして読みます。 同じファイルが1000倍の大きさで開かれる事故は、ここから起きます。

PLY — 自由な属性を持てる点群の器

PLYはスタンフォード大学で1990年代に作られた形式で、ASCIIとバイナリの両方があります。 特徴はヘッダで「頂点ごとにどんなプロパティを持つか」を自由に宣言できることです。 座標、法線、色に加えて任意の値を並べられるため、LiDARやフォトグラメトリで得た点群の保存に広く使われています。

この柔軟さが、第9章で扱う3D Gaussian Splattingで再び注目されました。 3DGSの学習結果は、ガウシアンの位置や不透明度、回転、スケールなどをPLYの汎用ヘッダに独自プロパティとして宣言して保存するのが、事実上の標準になっています。

FBX — 事実上の標準なのに仕様が非公開

FBXはKaydaraのモーションキャプチャソフトFilmbox（1996年）の保存形式として生まれました。 その後KaydaraはAliasに、Aliasは2006年にAutodeskに買収され、以来FBXはAutodeskが単独で所有するプロプライエタリ形式です。

メッシュ、マテリアル、スキン、ブレンドシェイプ、アニメーション、シーン階層と、何でも運べます。 MayaやMotionBuilderからUnity、Unreal Engineへキャラクターを持ち込む経路として、ゲーム業界では長く事実上の標準でした。

問題は、バイナリとASCIIのレイアウトが公式に文書化されていないことです。 Autodeskは無償のC++ライブラリ「FBX SDK」を配布していますが、利用は同梱のEULA（使用許諾契約）に従います。 オープンソースのライセンスでも、公開仕様でもありません。

オープンソースはFBXをどう読んでいるか

仕様もSDKも開かれていないことは、オープンソースのツールに直接影響します。 BlenderはGPLで配布されており、再配布の権利を制限するFBX SDKを同梱できません。 そのためBlenderのFBXインポータとエクスポータは、SDKを使わずにリバースエンジニアリングで実装されています。 Blenderの開発者は、解析したファイル構造を非公式仕様として公開しています。

ゲームエンジンのGodotも同じ壁に当たりました。 以前はFBXを読むために、プロプライエタリなFBX SDKにリンクする外部プログラム（FBX2glTF）を別途用意する必要がありました。 Godot 4.3からは、単一ファイルのオープンソースライブラリufbxによるネイティブ読み込みを標準にしています。

COLLADA — オープンな交換形式の試み

FBXに対するオープンな対抗馬として登場したのがCOLLADA（拡張子.dae）です。 ソニー・コンピュータエンタテインメントのRémi ArnaudとMark C. Barnesが中心となり、SIGGRAPH 2003で取り組みが始まり、2004年に1.0が出ました。 その後Khronos Groupの標準となり、1.5.0は2012年にISO/PAS 17506:2012になっています。

中身はXMLで、メッシュ、マテリアル、アニメーション、シーン階層までを記述できます。 狙いはDCCツール間の交換で、オーサリング側の情報をなるべく残す設計でした。 ただ、XMLはファイルが大きく、読み込みにはパースが必要です。表現の自由度が高いぶん、ツールごとの書き方の差も出ました。 結果として、現在COLLADAを新規に採用する例は多くありません。

COLLADAを手がけたKhronosが次に作ったのがglTFです。 glTFは交換ではなく配信に目的を絞りました。COLLADAの経験から「交換用と配信用を一つの形式で兼ねない」という方向に舵を切った、と読むことができます。

glTF 2.0 — GPUにそのまま渡せる配信用フォーマット

glTF（GL Transmission Format）2.0は、Khronos Groupの3D Formats Working Groupが策定し、2017年に公開された形式です。 仕様はglTFを「API中立のランタイムアセット配信形式」と位置づけ、オーサリング形式とは違ってランタイムでの効率を目標にすると明記しています。 画像のJPEGになぞらえて「3DのJPEG」と呼ばれることもあります。

JSONとバイナリバッファの分業

glTFの構成は2つに分かれます。 ノード階層、メッシュ、マテリアル、カメラ、アニメーションといった「構造」はJSONで書き、頂点座標やインデックスなどの「大量の数値」はバイナリのバッファに入れます。 仕様によれば、このバイナリは多くの場合「追加のパースなしでGPUバッファに直接ロードできる」形になっています。 第3章で見た頂点バッファとインデックスバッファを、そのままファイルに書き出したものと考えると分かりやすいでしょう。

バイナリへの参照は3段階になっています。

• buffer: バイトの線形配列そのもの。外部の.binファイル、またはGLB内のバイナリ部分を指します。
• bufferView: bufferの中の区間（オフセットと長さ）。targetで頂点属性用（ARRAY_BUFFER）かインデックス用（ELEMENT_ARRAY_BUFFER）かを示します。
• accessor: bufferViewの中身を「何個の、どんな型の要素か」として解釈する記述。たとえば「float 3つ組（VEC3）が3個」のように指定します。

次のコードは、赤い三角形を1枚だけ描く最小限のglTFです。 WebGLでgl.bufferDataやgl.vertexAttribPointerを書いたことがあれば、accessorとbufferViewがその引数にほぼ対応していることが分かると思います。

{
  "asset": { "version": "2.0" },
  "scene": 0,
  "scenes": [ { "nodes": [0] } ],
  "nodes": [ { "name": "Triangle", "mesh": 0 } ],
  "meshes": [
    {
      "primitives": [
        {
          "attributes": { "POSITION": 1 },
          "indices": 0,
          "material": 0
        }
      ]
    }
  ],
  "materials": [
    {
      "pbrMetallicRoughness": {
        "baseColorFactor": [1.0, 0.0, 0.0, 1.0],
        "metallicFactor": 0.0,
        "roughnessFactor": 0.5
      }
    }
  ],
  "accessors": [
    {
      "bufferView": 0,
      "componentType": 5123,
      "count": 3,
      "type": "SCALAR"
    },
    {
      "bufferView": 1,
      "componentType": 5126,
      "count": 3,
      "type": "VEC3",
      "min": [0.0, 0.0, 0.0],
      "max": [1.0, 1.0, 0.0]
    }
  ],
  "bufferViews": [
    { "buffer": 0, "byteOffset": 0, "byteLength": 6, "target": 34963 },
    { "buffer": 0, "byteOffset": 8, "byteLength": 36, "target": 34962 }
  ],
  "buffers": [
    { "uri": "triangle.bin", "byteLength": 44 }
  ]
}

読み方を順に追います。scenesが描画対象のルートノードを列挙し、nodesの0番がメッシュ0番を持ちます。 メッシュのprimitiveは、頂点座標（POSITION）にaccessor 1番、インデックスにaccessor 0番、見た目にマテリアル0番を使います。 accessor 0番は「unsigned short（5123）のスカラーが3個」、accessor 1番は「float（5126）のVEC3が3個」です。 bufferView 0番はバッファの先頭6バイト（インデックス3個）、1番は8バイト目からの36バイト（頂点3個×12バイト）を指します。 6バイトのインデックスの後に2バイトの詰め物を入れ、頂点データの開始位置を4バイト境界にそろえています。

すべての参照が配列の添字（整数）で書かれている点に注目してください。 名前で探す必要がないので、読み込み側は配列を順にたどるだけでGPUへのアップロードまで進めます。

GLB — 1ファイルにまとめた形

.gltfはJSON、.bin、テクスチャ画像（PNG/JPEG）が別々のファイルになります。 これらを1つのバイナリファイルに詰めたのがGLBです。 JSON部分とバイナリ部分を1ファイルに並べ、テクスチャ画像もbufferViewを経由してバイナリ部分に格納できます。 HTTPリクエストが1回で済み、テクスチャのパスが切れる事故も起きないため、Web配信ではGLBが定番です。

graph LR
  subgraph J[JSONチャンク]
    SC[scene] --> ND[node]
    ND --> ME[mesh]
    ME --> PR[primitive]
    PR --> MA[material]
    MA --> TX[texture]
    TX --> IM[image]
    PR --> AC[accessor]
    AN[animation] --> AC
    AC --> BV[bufferView]
    IM --> BV
  end
  subgraph B[BINチャンク]
    BF["buffer<br/>頂点・画像のバイト列"]
  end
  BV --> BF

  style BF fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style BV fill:#3b82f6,stroke:#1d4ed8,color:#fff

マテリアルはPBRが標準

glTF 2.0は、第4章で扱ったmetallic-roughnessモデルのPBRをコア仕様に採用しています。 仕様は「宣言的なマテリアル表現によってプラットフォーム間で一貫した描画を可能にする」と述べています。 OBJの.mtlやFBXのように「書き出したツールのシェーダ次第」ではなく、どのビューアで開いても同じ見た目になることを狙った設計です。

座標系と単位も仕様で固定されています。右手系で+Yが上、+Zが前、-Xが右で、長さの単位はメートル、角度はラジアンです。 「単位なし」のOBJやSTLとの大きな違いです。

拡張機構 — KHR_ と EXT_

glTFはコア仕様を小さく保ち、新機能は拡張（extension）として足していく方針をとっています。 拡張名は接頭辞_スコープ_機能という命名規則で、接頭辞が出自を表します。

拡張は Proposal → Initial Draft → Review Draft → Release Candidate → Ratified という段階を踏んで成熟します。 Review Draftに進むにはJSONスキーマ、テストアセット、第三者による実装が1つ以上必要です。 Release Candidateではサンプルビューアとバリデータが対応したうえで、最終の公開レビューを受けます。

Webエンジニアにとっては、圧縮系の拡張が特に重要です。

• KHR_draco_mesh_compression: GoogleのDracoでメッシュの頂点データを圧縮します。
• EXT_meshopt_compression: meshoptimizerによる圧縮です。もとはEXT_でしたが、普及を受けて批准済みのEXT拡張として扱われています。
• KHR_mesh_quantization: 頂点属性をfloatより小さい整数型で持てるようにし、サイズを減らします。
• KHR_texture_basisu: KTX2コンテナとBasis Universalによる超圧縮テクスチャです。GPU向けの圧縮形式に変換して使えるため、ダウンロードサイズだけでなくGPUメモリも節約できます。

拡張の対象は圧縮以外にも広がっています。 第9章で扱う3D Gaussian Splattingを格納するKHR_gaussian_splattingは、2026年2月3日にKhronosがRelease Candidateを発表し、同年9月にGitHubの拡張レジストリ上で「Ratified」と表示されるようになりました。 glTFにノードベースの振る舞い（ビヘイビアグラフ）を埋め込むKHR_interactivityも、2026年7月に批准申請が発表され、8月末にレジストリ上で批准済みと表示されています。 どちらも批准を告げるプレスリリースは確認できていないため、ここではGitHub上のステータスとして紹介します。 メッシュだけでなく、スプラットや対話的な挙動までglTFが運ぶ方向に進んでいることが分かります。

ISO標準へ

glTF 2.0は2022年8月にISO/IEC 12113:2022として国際標準になりました。 ISO/IEC JTC 1のPAS（公開仕様の提出）手続きを使い、技術的な変更なしで承認されています。 Khronosはロイヤリティフリーの仕様としてglTFを提供しており、誰でも追加費用なしで実装できます。

OpenUSD — 多人数で編集するシーン記述

USD（Universal Scene Description）はPixarが社内の映画制作パイプラインのために開発し、2016年7月26日にオープンソース化しました。 現在はOpenUSDと呼ばれています。 glTFが「完成品を届ける」形式なら、USDは「大勢が同時に手を入れるシーンを記述する」形式です。

ファイルの表現は3種類あります。人が読めるテキストの.usda、バイナリの.usdc、それらをzipでまとめた.usdzです。 USDZはAppleのAR Quick Lookが標準で読む形式でもあり、iPhoneやiPadでのAR表示に使われます。

レイヤーとコンポジション

USDの最大の特徴はコンポジションです。 1つのシーンを1つのファイルに書くのではなく、複数のレイヤー（ファイル）を重ね合わせて組み立てます。 レイヤー同士をつなぐ仕組みをコンポジションアークと呼び、subLayers、inherits、variantSets、references、payloads、specializesがあります。

たとえば映画のショットなら、レイアウト担当が配置を、ライティング担当が照明を、それぞれ別のレイヤーに書きます。 最終的なシーンは、それらを重ねた結果として決まります。 同じ属性に複数のレイヤーが値（USDの用語ではopinion）を書いた場合は、「最も強いopinionが勝つ」というルールで1つに決まります。 元のレイヤーを書き換えずに上から値をかぶせられるので、非破壊編集になります。 Gitに例えるなら、ファイルを直接書き換えるのではなく、パッチを重ねて最終状態を計算するイメージです。

強さの順番 — LIVRPS

どのopinionが強いかは、コンポジションアークの種類で決まります。強い順に頭文字を並べたのがLIVRPSです。

近年はrelocatesというアークが加わり、LIVERPSと表記されることもあります。 ローカルに書いた値が最も強いので、参照で取り込んだアセットの色をショット側で上書きしても、元のアセットファイルには影響しません。 この仕組みのおかげで、数百人規模の部署が同じシーンを並行して編集できます。

単位はステージごとに宣言する

USDは単位や上方向を固定せず、ステージ（シーン全体）ごとに宣言します。 単位はmetersPerUnit、上方向はupAxisで指定し、metersPerUnitを省略すると0.01、つまり1単位が1センチとして扱われます。 単位はステージ全体で1つしかなく、単位の異なるファイルを参照しても自動では換算されません。 メートルで作った高さ6メートルの木を、センチ単位のステージに取り込むと6センチになってしまいます。

AOUSDと標準化の歩み

USDは長くPixarの実装がそのまま事実上の仕様でした。 これを文書化された標準にするため、2023年8月1日にPixar、Adobe、Apple、Autodesk、NVIDIAの5社がAOUSD（Alliance for OpenUSD）を設立しました。 AOUSDはLinux Foundationの関連団体であるJoint Development Foundationの傘下にあります。

2025年12月17日にはCore Specification 1.0が発表されました。 データモデル、コンポジション、値の解決方法を初めて規範的に定義した仕様で、新機能の追加ではなく既存の振る舞いの標準化です。 議長のSteve May（Pixar CTO）はこれを「ISO標準化への重要な第一歩」と述べています。 さらに2026年7月21日のSIGGRAPH 2026で、AOUSDはCore Specification 1.1のISO認証手続きを開始し、仕様の公開GitHubリポジトリも開設しました。 ISO化が済んだglTFに対し、OpenUSDはこれから手続きを進める段階です。

なお、Pixarが公開しているOpenUSDの実装は、Apache License 2.0の商標条項だけを変更した独自ライセンス（Tomorrow Open Source Technology License 1.0）で配布されています。

用途特化の新しい形式 — 3MFとVRM

3MF — STLの後継

3MFは3MF Consortiumが策定した3Dプリント向けの形式で、STLの後継と位置づけられています。 中身はXMLをzipでまとめたもので、STLが持てなかった色、材料、テクスチャ、単位、複数パーツの構成を保持できます。 2025年6月にISO/IEC 25422:2025として国際標準になりました。 Bambu Studio、PrusaSlicer、Curaといった主要なスライサが対応しています。 互換性を最優先するならSTL、情報を落としたくないなら3MF、というのが現在の使い分けです。

VRM — glTFの上に作られたアバター形式

VRMは人型アバターのための形式で、VTuberやメタバースで使われています。 中身はGLBそのものに、アバター用の情報を拡張として足したものです。 2019年4月に設立されたVRMコンソーシアムが管理し、VRM 1.0は2022年9月に公開されました。

VRMが追加するのは、第5章で触れたヒューマノイドのボーン定義、表情、髪や服の揺れもの（SpringBone）、トゥーン調のシェーダMToonなどです。 ボーンの名前と構造が決まっているので、どのアプリでも同じアバターを同じように動かせます。 もう一つの特徴は、アバターごとの利用許諾をメタデータとしてファイルに含めることです。 「誰がこのアバターを使ってよいか」「商用利用は可能か」といった条件が、モデルと一緒に運ばれます。 glTFの拡張機構があったからこそ、ゼロから形式を作らずにこうした用途特化の形式を作れたとも言えます。

座標系と単位の既定値

形式をまたいでデータを移すとき、もっとも事故が多いのが座標系と単位です。 モデルが90度倒れる、100倍に膨らむといった症状の多くは、次の表の食い違いから起きます。

たとえばBlender（Z-up）で作ったモデルをFBXでY-upのエンジンへ渡すときは、エクスポータで「-Z Forward, Y Up」のように軸を変換する設定が必要です。 glTFは座標系と単位が仕様で決まっているので、エクスポータが一度変換すれば、読む側は迷いません。 実際の失敗例と対処は、第8章でThree.jsを使いながら詳しく扱います。

形式の比較表

ここまでの内容を1枚の表にまとめます。

標準化の流れ

年表にすると、「ベンダー独自の形式」から「業界団体の標準」、さらに「ISOの国際標準」へという流れがはっきり見えます。 特にここ数年は、glTF、3MF、OpenUSDの標準化が立て続けに進みました。

条件別の選び方

最後に、目的から形式を選ぶ早見表です。迷ったら「誰がそのファイルを読むのか」を考えると決まります。

まとめと次章への橋渡し

3Dのファイル形式は、「オーサリング用（交換・編集）か、ランタイム用（配信・表示）か」で整理すると見通しがよくなります。 FBXは何でも運べる交換用の事実上標準ですが、仕様非公開という弱点を抱え、BlenderやGodotは独自実装で読み込んでいます。 COLLADAのオープンな交換形式としての試みを経て、Khronosは配信に目的を絞ったglTFを作り、ISO標準にまで育てました。 一方、PixarのUSDはレイヤーとLIVRPSによる非破壊のコンポジションで制作パイプラインを支え、AOUSDのもとでISO化に向けた手続きが進んでいます。 STL・3MF・PLY・VRMは、それぞれ3Dプリント、点群、アバターという特定の用途に特化した形式です。

次の第8章では、この章で見たglTF/GLBを実際にWebで扱います。 Three.jsとReact Three Fiberでglbを表示し、model-viewerでARに対応させ、gltf-transformで圧縮するところまでを実践します。 座標系、単位、色空間といった、この章の比較表に出てきた違いが実際にどんな失敗として現れるかも確認します。

主な参考資料

• glTF 2.0 Specification（Khronos）
• glTF Extension Registry（KhronosGroup/glTF）
• OpenUSD Glossary
• AOUSD Core Specification 1.0 発表（Linux Foundation）
• Introducing the improved ufbx importer in Godot 4.3
• VRM 1.0（vrm.dev）