glTF形式の3Dデータを別の3Dエンジンへ持っていくと、モデルとアニメーションは表示できても、「選ぶと色が変わる」「ボタンを押すと扉が開く」といった反応までは引き継がれません。こうした処理は3Dデータではなく、読み込む側のアプリに書かれているからです。
KHR_interactivityは、この隙間を埋めるためのglTF 2.0拡張です。モデル固有の状態や条件分岐、アニメーション制御をglTF／GLBに保存し、対応する環境へ一緒に持ち運べるようにします。
Khronos Groupは2026年7月16日、KHR_interactivityを批准手続きへ提出したと発表しました。ただし、発表時点ではまだ批准済みではなく、正式批准に向けた候補仕様（Release Candidate）という位置づけです。
KHR_interactivityが埋める「隙間」
たとえば、部品を選ぶと分解アニメーションが始まる製品モデルを考えてみます。
従来のGLBに入っているのは、製品の形状、質感、アニメーションです。どの部品が選ばれたかを調べ、どのアニメーションを再生するか決める処理は、three.jsやBabylon.js、Unityなどのアプリ側に実装します。
この構成では、モデルを別のエンジンへ移すたびに操作部分の書き直しが発生します。KHR_interactivityを使うと、選択後の状態変更やアニメーション制御を「ビヘイビアグラフ」としてGLBに含められます。
ここで、アプリ側のコードが不要になるわけではありません。マウスやXRコントローラーから入力を受け取る処理、画面上のUI、通信などは、引き続きアプリが担当します。GLBへ移せるのは、選択後に色を変える、部品を動かす、次の状態へ進むといった、そのモデルの中で意味が完結する反応です。
動作はノードをつないで記述する
ビヘイビアグラフでは、イベントや計算、条件分岐といった処理を「ノード」と呼ばれる箱で表し、線でつないで実行順を組み立てます。
信号機を選ぶたびに色が変わる処理なら、流れは次のようになります。
信号機が選ばれる
↓
現在の色を確認する
↓
次の色を決める
↓
新しい状態を保存する
↓
表示とアニメーションを更新するノードをつなぐ線は2種類あります。処理の順番を渡す「フロー」と、数値、色、真偽値、3Dモデル内の参照などを渡す「値」です。仕様書ではそれぞれFlow socket、Value socketと呼ばれています。
グラフの中には、現在の状態を覚えておく変数や、処理を始めるイベントも定義できます。信号機の現在色、選択中の商品カラー、操作説明がどこまで進んだか、といった情報です。
位置、回転、マテリアルなどの読み書きは、特定の3Dエンジンの内部機能ではなく、glTFのデータ構造を基準に行います。この共通の基準があることで、別の実行環境でも同じ結果を再現しやすくなります。
JavaScriptを埋め込む仕様ではない
KHR_interactivityは、JavaScriptやC#などのプログラムをGLB内で自由に実行する仕組みではありません。仕様で定義された処理をノードとして組み合わせます。
任意のプログラムを許可する形式に比べれば、実行できる処理を把握しやすくなります。ただし、処理負荷を気にしなくてよいわけではありません。ノードを輪のように直接つなぐことは禁止されていますが、繰り返しや遅延を扱う処理は用意されています。ビューアーや3Dエンジンは、長時間止まらない処理を防ぐため、1フレーム内の処理数や実行時間に上限を設けられます。
アニメーションの自動再生には注意
KHR_interactivityを含むデータでは、glTFのアニメーションはビヘイビアグラフから制御します。ビューアーがアニメーションを自動再生しないことも仕様で定められています。
既存のGLBへグラフを追加する場合は、読み込み直後の自動再生を前提にしていないか確認が必要です。複数のアニメーションが同じ位置やマテリアルを同時に変更すると結果が定まらないため、更新先が重ならないようにも設計します。
WebXRのAPIは変わらない
KHR_interactivityは、WebXR Device APIの拡張ではありません。ブラウザがXRデバイスへ接続する方法も、コントローラーやハンドトラッキング、ARのヒットテストを取得する方法も変わりません。
VRコントローラーで展示物を選ぶ体験なら、処理は次のように分かれます。
- WebXRアプリがコントローラーの入力を受け取る
- アプリが、どの展示物を選んだか判断する
- GLB内のビヘイビアグラフが、展示物の状態やアニメーションを切り替える
マウス、タッチ、コントローラー、視線入力の違いはアプリ側で吸収し、選択されたあとの反応をGLB側で共通化します。同じモデルをデスクトップ、スマートフォン、VRで使い回すときに、書き直す範囲を減らせる構成です。
仕様には、現在のカメラ位置や向きをグラフから参照する仕組みもあります。ただし、VRでは左右の目に別々のカメラがあります。実行環境によって、片方のカメラを使う場合、両目の中間を仮想的なカメラとする場合、プライバシーなどの理由で情報を渡さない場合があります。カメラとの距離を使う動作は、対象とする環境ごとに結果を確認する必要があります。
GLBへ入れる処理、アプリに残す処理
切り分けの目安は、「その3Dモデルだけで意味が通る処理かどうか」です。
| 用途 | GLBへ入れやすい処理 | アプリに残す処理 |
|---|---|---|
| 商品の色・部品変更 | 選択状態、色や表示の切り替え | 価格、在庫、購入画面、通信 |
| 展示物や教材 | 手順の状態、部品の強調、アニメーション | 言語切り替え、読み上げ、進捗の保存 |
| 近づくと動く仕掛け | 距離の判定、動作の開始 | カメラ情報の提供、XRセッション |
| 小さなゲーム要素 | 得点、条件分岐、物体の移動 | 入力の割り当て、通信、データの永続化 |
たとえば、グラフにcheckoutというイベントを作っても、それだけで決済はできません。認証、サーバー通信、複数ユーザー間の同期、HTMLで作る画面、アクセシビリティ対応などはアプリ側の仕事です。
「インタラクティブなGLB」という言葉から、ファイル単体でアプリ全体が動くように聞こえるかもしれません。実際には、GLBとアプリの境界を引き直すための仕様と捉えるほうが正確です。
「glTF対応」だけでは動かない
2026年7月20日時点で、KHR_interactivityは正式批准前のRelease Candidateです。glTF Extension Registryでも、批准済みではなくRelease Candidateの一覧に掲載されています。KHR_という接頭辞は、批准済みであることを示す印ではありません。
作成や検証に使える公開ツールには、次のものがあります。
- Interactivity Graph Authoring Tool：グラフの作成、確認、書き出し
- UnityGLTF：Unity Visual Scriptingで作成したグラフの書き出し
- Babylon.js glTF loader：
KHR_interactivityを読み込む実装
通常のGLBを表示できるビューアーでも、ビヘイビアグラフを実行できるとは限りません。製品ページに「glTF対応」と書かれているだけでは判断できないため、KHR_interactivityへの対応を別に確認します。
非対応環境では見た目だけ残す
動作に対応していない環境でもモデルを表示したいなら、拡張なしで成立する基本データをGLBに残しておきます。
glTFには、使用する拡張を示すextensionsUsedと、その拡張がなければデータを正しく扱えないことを示すextensionsRequiredがあります。動作がなくても商品や展示物として表示できるなら、KHR_interactivityを必須にする必要があるか検討します。
実行環境が知らない処理は、仕様上「何もしない処理」として扱われます。この挙動は、エラーで全体が止まらない代わりに、「モデルは見えるが途中から反応しない」という状態を生む可能性があります。静止モデルとして見せる、未対応であることを画面に出す、アプリ側の操作へ切り替えるなど、利用者が故障と勘違いしない見せ方が必要です。
試すなら信号機のサンプルから
最初に見るなら、公式発表でも紹介されたTraffic Lightのデモが手頃です。信号機を操作すると、GLBに保存された状態が順番に切り替わります。
デモを動かしたあとは、公式サンプル集から同じGLBを入手し、Interactivity Graph Authoring Toolで中身を開きます。画面上の反応と、イベント、変数、条件分岐、アニメーションのつながりを見比べると、グラフの役割を追いやすくなります。
書き出したGLBは、作成に使った環境だけで確認して終わらせず、別の対応環境でも開きます。仕様の狙いは持ち運べることにあるため、1つの環境で動いただけでは十分な検証になりません。
本番採用はまだ慎重に
公式サンプルや編集ツールが公開されているため、試作はすぐに始められます。一方、長く配布する商品データや教材へ採用できるかは、対応するビューアーと運用期間によって判断が分かれます。仕様が批准前で、実装も出揃っていないためです。
試作から先へ進める場合は、少なくとも次の項目を記録します。
- 使用した仕様、編集ツール、書き出し機能、実行環境のバージョン
- GLB側とアプリ側の責任範囲
- 2つ以上の対応環境で同じ結果になるか
- 非対応環境で表示する内容
- スマートフォンや一体型VRヘッドセットでの処理負荷
WebXRでは、処理の遅れが操作感や酔いやすさに直結します。デスクトップで動いたという理由だけで判断せず、公開対象のヘッドセットで一連の操作を確認する必要があります。
現時点での見方
KHR_interactivityの価値は、GLBだけでアプリを完成させることではなく、モデル固有の処理をアプリから切り離せる点にあります。同じ商品や展示物を複数の端末、ビューアー、3Dエンジンで使う案件では、重複していた実装を減らせる可能性があります。
ただし、入力、UI、通信、WebXRセッションまでGLBが引き受けるわけではありません。どこまでをモデル側の動作とするか決めないまま導入すると、今度はGLBとアプリのどちらに処理があるのか分かりにくくなります。
現段階では、公式サンプルを複数の対応環境で比較し、制作工程に合うかを確かめるところから始めるのが妥当です。正式批准後は、仕様の変更点と各ツールの対応状況を改めて確認する必要があります。
