[Next.js #30] Triplex + React Three Fiber + WebXR — GUI編集からQuest2実行まで

はじめに

昨日の日曜日、Youtubeのおススメ動画に「WebXR JP」のコミュニティチャンネルの動画が出て何となく拝見したのですが、Triplexが面白そうだったので、インストールから、動作確認、そして、WebXRでQuest2でのVR体験まで一気にやってみたので、備忘録メモとして記事にまとめてみます。

私の記事よりは、コミュニティの方の公開記事の方が遥かに詳しいのでそちらを見られた方がいいと思います。

動作検証する際にも、此方のサイトを参考にさせてもらってます。

スクショ：

上記のOKボタンを押すだけで、Quest2上でブラウザのタブで起動して速確認できます。

つまり、triplexを使えば、WebXRの開発効率が爆速でアップします。

動画（Youtube）:

動画（VR）:

1. Triplexとは

Triplex は、React / React Three Fiber（R3F）製コンポーネントを視覚的に編集できるワークスペースです。VS Code 拡張として導入でき、3D シーンを GUI で触りながら、その変更をそのまま JSX / TSX のコードへ反映できます。公式ドキュメントでも、Triplex は “React / Three Fiber components を構築するための visual workspace” と説明されています。 (Triplex)

従来の Three.js / R3F 開発では、オブジェクトの位置や回転、スケールを調整するたびに、コードを書き換えて保存し、ブラウザへ戻って確認する必要がありました。Triplex ではこの往復を減らし、3D ビュー上でオブジェクトを直接動かして微調整し、その結果をコードへ保存することができます。Triplex の公式サイトでも、Visual Controls と Code Sync が主要機能として挙げられています。 (Triplex)

また、Triplex は単なる GUI エディタではなく、コンポーネントの props を入力UIとして扱えるのも特徴です。props を定義すると、エディタ側に対応する入力欄が自動生成され、コードを書かずに値を試しながら見た目や挙動を調整できます。これにより、R3F で作る 3D UI や商品モック、展示用コンポーネントの試作がかなり速くなります。 (Triplex)

さらに、Triplex には WebXR 連携 も用意されています。公式サイトでは、React Three Fiber と WebXR コンポーネントを使って、Meta Quest や Apple Vision Pro などで動く XR 体験を構築できると案内されています。今回試したように、GUI でシーンを調整したあと、そのまま Quest 側で挙動を確認できるのはかなり強力です。 (Triplex)

要するに Triplex は、「R3F のコードエディタ」と「3D シーンエディタ」と「WebXR 確認環境」をひとつにまとめたツールです。展示系の 3D コンテンツや XR プロトタイプを素早く作りたいとき、かなり相性が良いと感じました。

2. インストール

今回は、Triplex の公式 CLI を使って新規プロジェクトを作成し、VS Code 上で GUI エディタを起動するところまで進めました。基本的な流れはとてもシンプルで、プロジェクト作成 → 開発サーバー起動 → VS Code で開くだけです。公式でも、新しいプロジェクトを始める方法として create-triplex-project が案内されています。

プロジェクト作成

まずはターミナルで、以下のコマンドを実行します。

npx create-triplex-project@latest

すると、いくつか質問が表示されます。今回は最小構成で試したかったので、次のように選択しました。

project name
template: empty
package manager: npm

project name は任意の名前で問題ありません。 template は最初なので empty を選んでいます。最小構成で始めた方が、Triplex がどこまでやってくれるのかを把握しやすいからです。 package manager は普段使っているものでも大丈夫ですが、今回は npm を選びました。

この手順を終えると、新しい Triplex 用プロジェクトが作成され、必要な依存関係もまとめてセットアップされます。公式テンプレートは Vite ベースで構成されているため、作成直後からそのまま開発を始められる状態になります。

開発サーバー

プロジェクト作成後は、作成されたフォルダへ移動して開発サーバーを起動します。

npm run dev

これでローカル開発サーバーが立ち上がります。

今回は Vite の開発サーバーとして起動し、ブラウザ側ではローカル URL が表示されました。

Triplex は通常のブラウザアプリとして使うというより、VS Code 拡張からコンポーネントを開いて 3D ワークスペースとして扱うのが基本になるため、この段階では「開発サーバーが動いていること」を確認できれば十分です。

Triplex for VS Code の公式ドキュメントでも、VS Code からファイルを開いて使う流れが案内されています。

ここまでできたら、次は VS Code でプロジェクトを開き、Scene.tsx などのコンポーネントを Open in Triplex で開いて GUI エディタへ入っていきます。

3. Triplex GUIエディタ

Triplex の面白さが一番わかりやすいのが、この GUI エディタ画面です。 従来の Three.js / R3F 開発では、オブジェクトの位置や回転を調整するたびにコードを書き換え、保存して、ブラウザへ戻って確認する必要がありました。Triplex ではその往復がかなり減り、3Dビュー上で直接オブジェクトを動かしながらシーンを調整できます。

画面構成もかなり分かりやすく、役割は大きく3つに分かれています。

まず左側には、現在のシーンを構成している要素がツリー形式で表示されます。ここはいわば scene graph で、mesh、boxGeometry、meshStandardMaterial のように、JSX の構造がそのまま見える形になっています。どの要素を編集しているのかが明確なので、単なるプレビュー画面ではなく、シーン構造を意識しながら編集できるのが良いところです。

中央は、実際の 3D シーンを表示する ビューエリア です。ここでオブジェクトを選択し、位置や向きを視覚的に確認しながら調整できます。数値だけを見て座標をいじるのではなく、実際の見た目を基準に操作できるので、微妙な位置合わせやサイズ調整がかなり楽になります。

右側には、選択中オブジェクトの transform や props が表示されます。ここでは position、rotation、scale といった基本変形に加えて、コンポーネントが持つ props を入力欄として扱えます。つまり、視覚的に動かすだけでなく、必要に応じて数値で正確に詰めることもできます。

今回試したシーンは、かなりシンプルな箱1つの構成です。

export function Scene() {
  return (
    <>
      <mesh castShadow receiveShadow position={[0, 0.34, 0]}>
        <boxGeometry args={[2, 1, 1]} />
        <meshStandardMaterial />
      </mesh>
    </>
  )
}

このコードを Triplex で開くと、中央の 3D ビューに箱が表示され、選択したまま GUI 上で位置を動かせます。例えば、箱を少し上へドラッグすると、position={[0, 0.34, 0]} のような値が変化し、その結果が左側のソースコードにも反映されます。

ここが Triplex の大きな特徴で、GUI で触った結果がそのままコードへ保存されるようになっています。 つまり、

  • 3Dビューで調整する
  • 位置や回転を視覚的に確認する
  • 保存すると JSX が更新される

という流れで作業できます。

この体験はかなり強力で、感覚としては 「R3F 用のシーンエディタ」と「コードエディタ」が一体化している ような印象です。Three.js / R3F の座標調整は地味に時間を取られやすい部分ですが、Triplex を使うとこの工程がかなり軽くなります。

特に、商品モックや 3D UI、XR 用シーンのように、位置・距離感・見え方の微調整が重要なコンテンツでは、この GUI エディタの恩恵が大きいと感じました。

4. GUI編集 → コード更新

Triplex を触っていて一番驚いたのは、GUI でオブジェクトを編集すると、その結果がそのままソースコードへ反映されることでした。

通常の Three.js / R3F 開発では、オブジェクトの位置や回転を調整したいとき、まずコード側で position や rotation の値を書き換え、保存して、ブラウザへ戻って見た目を確認する必要があります。微調整が必要な場面では、この往復を何度も繰り返すことになります。

Triplex では、この流れがかなり変わります。

GUI操作
↓
props変更
↓
コード自動更新

つまり、中央の 3D ビューでオブジェクトを直接動かすと、その変更内容が position や rotation といった props に反映され、最終的に JSX / TSX のコードそのものが更新されます。

例えば、箱を少し上に動かした場合、コード上では次のように position の値が変化します。

<mesh castShadow receiveShadow position={[0, 0.34, 0]}>

この 0.34 は手打ちで入力した数値ではなく、GUI 上で実際にオブジェクトを動かした結果として反映されたものです。 この体験はかなり直感的で、感覚としては Blender のような 3D エディタで配置を決めながら、裏では React のコードが生成・更新されているような印象です。

つまり Triplex は、単なるビューアやプレビュー画面ではありません。 3D エディタとしての操作性と、コードエディタとしての再現性を両立しています。

この仕組みがあることで、特に次のような作業がかなり楽になります。

  • オブジェクトの微妙な位置合わせ
  • UI パーツや 3D モックの配置調整
  • 距離感やスケール感の確認
  • XR 空間での見え方を前提にした微修正

Three.js や R3F では、座標の微調整そのものは難しくありませんが、「ちょうどいい位置」を探す作業は地味に時間がかかります。Triplex はこの部分を GUI 操作に置き換えてくれるため、試行錯誤の速度がかなり上がります。

要するに Triplex は、 「3D エディタ」と「コードエディタ」を分離せず、一つのワークフローにまとめたツールです。

この仕組みのおかげで、見た目を詰めながら、その結果をそのままコード資産として残せるのが非常に強いと感じました。

5. WebXR体験

今回、Triplex を触っていて特に驚いたのが、GUI エディタで作った R3F シーンを、そのまま WebXR として Quest2 で確認できたことです。

Triplex の画面右上には XR icon が用意されていて、これを押すと WebXR 関連のメニューが表示されます。 従来の Three.js / WebXR 開発では、HTTPS の用意やローカルネットワーク越しの確認など、いくつか面倒な手順が必要でしたが、Triplex ではこの流れがかなり簡略化されています。

まず、右上の XR ボタンを押すと、次のようなメニューが出ます。

Open in WebXR

この時点で、すでに Triplex 側が WebXR 実行の導線を用意しているのが分かります。 単に 3D シーンを編集できるだけでなく、そのまま XR 環境へ繋げられるのはかなり強いです。

Quest2送信

さらに、このメニューから次の項目を使うことで、Quest2 側へ直接送ることができます。

Send to Meta Quest

これを押すと Meta 側のページへ遷移し、接続可能なデバイスが表示されます。 そこで Quest2 を選択し、次の操作を行います。

OPEN

ここまで来ると、PC 側で編集していたシーンを Quest 側へ送る流れができあがります。 従来のように URL を手動で探して入力する必要がなく、Triplex から Quest へそのまま橋渡しされる感覚です。

Questブラウザで起動

Quest2 側では、次の条件を満たしていれば WebXR が起動します。

  • 同一WiFi
  • Quest browser

つまり、PC と Quest2 が同じネットワークに接続されていて、Quest 側でブラウザを使える状態であれば、そのままシーンを開いて確認できます。

今回実際に試したところ、Quest2 のブラウザ上で R3F シーンがそのまま表示されました。 箱1つのシンプルな構成ではありましたが、GUI で編集した内容をすぐに XR 空間で確認できたのはかなり印象的でした。

この一連の流れを整理すると、次のようになります。

Triplexでシーン編集
↓
XRボタンを押す
↓
Send to Meta Quest
↓
Quest2でOPEN
↓
Quest browserでWebXR起動

ここまでのハードルが低いのはかなり大きく、少なくとも 「R3F のシーンを XR で試してみたい」 という用途に関しては、開発体験が大きく改善されると感じました。

特に、商品モックや展示用コンテンツ、3D UI のように、最終的な見え方を VR 空間で確認したいケースでは非常に便利です。 PC モニタ上では問題なく見えていても、実際に Quest で見るとサイズ感や距離感が大きく違って見えることは多いので、編集 → 送信 → 実機確認 を短いループで回せるのはかなり価値があります。

6. 従来のWebXRとの違い

前回の [Next.js #29] では、Three.js を使って WebXR を Quest2 で動かすところまでを、かなり低レイヤー寄りに組み立てました。 このときは、WebXR を自力で成立させるための手順を一つずつ整える必要がありました。

従来の流れをざっくり整理すると、次のようになります。

  • HTTPS
  • XRButton
  • XRSession
  • LANアクセス
  • URL共有

つまり、単に 3D シーンを作るだけでは足りず、WebXR を実機で動かすための周辺設定も含めて自分で面倒を見る必要がありました。 特に Quest2 実機確認では、HTTPS で配信できる状態を作り、同じネットワーク上からアクセスできるようにして、最終的にブラウザで URL を開く、という流れが必要になります。

この手順自体は WebXR の仕組みを理解するうえでとても重要ですが、開発フローとして見ると、やはり少し重いです。 「ちょっと Quest で見た目を確認したいだけ」でも、その前に越えるべき段階がいくつもあります。

一方、Triplex ではこの部分がかなり簡略化されていました。 今回試した範囲では、体感としてはほぼ次の流れです。

XRボタン
↓
Send to Quest
↓
完了

もちろん内部では WebXR に必要な仕組みが動いているはずですが、開発者側から見ると、複雑なセットアップを意識する場面がかなり減るのが大きいです。

この違いはかなり大きくて、前回の #29 が 「WebXR を理解しながら構築する記事」 だとすれば、今回の Triplex は 「WebXR を使った確認作業を一気に高速化するツール」 という位置づけになります。

つまり、

  • #29 は仕組みを掴むための土台
  • #30 は実際の開発ループを速くするための実践ツール

という関係です。

特に、商品モック、3D UI、展示用コンテンツのように、実機での見え方を何度も確認したい案件では、この差がかなり効いてきます。 手動で HTTPS や URL 共有を毎回意識するよりも、Triplex の GUI 上からそのまま Quest へ送れるほうが、試行回数を増やしやすいからです。

要するに Triplex の強みは、WebXR の仕組みそのものを置き換えることではなく、開発者が WebXR を試すまでの距離を極端に短くしてくれる点にあります。 このおかげで、XR の実機確認が「特別な作業」ではなく、日常的な開発ループの一部として扱いやすくなっていました。

7. 向いている用途

Triplex を触ってみて感じたのは、これは あらゆる 3D 開発を置き換える万能ツール というより、R3F がもともと強い領域をさらに加速するツールだということです。

特に相性が良いのは、「シーンを見せる」「体験させる」「距離感や配置を調整する」ことが重要なコンテンツです。 今回のように GUI でシーンを編集し、そのまま Quest2 で WebXR 確認まで進められる流れを考えると、Triplex + R3F が強い用途はかなりはっきりしています。

商品3D展示

一番分かりやすいのは、商品の 3D モックや展示ページです。 例えば、新商品のモデルをブラウザ上で回転させたり、分解表示したり、色違いを切り替えたりするような体験です。

こうした用途では、細かなシーン構築やライティング、カメラ位置の調整が重要になりますが、Triplex なら GUI で視覚的に詰めながら、その結果をコードへ保存できます。 さらに、そのまま Quest へ送って 「実際に VR 空間で手に取るように見たときどう感じるか」 まで確認できるので、商品訴求系の 3D コンテンツとはかなり相性が良いと感じました。

インタラクティブLP

ブランドサイトやランディングページのように、3D 表現を前面に出した インタラクティブLP にも向いています。 R3F はもともと React ベースなので、通常の UI と 3D 演出を同じプロジェクト内で扱いやすいのが強みです。

Triplex を使うと、その中でも特に面倒な

  • オブジェクト配置
  • カメラ調整
  • 距離感の確認
  • ちょっとした演出の位置合わせ

をかなり直感的に進められます。

結果として、「コードを書いて保存して確認してまた戻る」 という往復が減り、演出の試行錯誤がしやすくなります。 3D を使った LP は、完成までの調整コストが意外と高いので、この差は大きいです。

XRデモ

今回いちばん強さを感じたのは、やはり XR デモ用途です。 Quest2 へ送ってそのまま確認できる流れは、デモやプロトタイプ制作とかなり相性が良いです。

例えば、

  • VR空間に商品を置く
  • 3D UI を並べる
  • 展示ブースのような構成を作る
  • 小さな体験型コンテンツを試す

といった用途では、編集 → 送信 → 実機確認 のループを短く回せること自体が大きな価値になります。

従来の WebXR は、実機で確認するまでの導線が少し長くなりがちでしたが、Triplex はそこをかなり短くしてくれるので、XR を「特別な確認作業」ではなく、普通の開発フローの一部として扱いやすくなります。

UIプロトタイプ

もう一つ向いているのが、3D を含んだ UI プロトタイプ です。 R3F は React の流儀で UI と 3D を統合しやすいため、3D 空間上のボタンやパネル、視覚演出付きの UI モックを作る用途と相性が良いです。

Triplex の GUI エディタを使うと、こうした UI 要素の位置調整や見た目の確認をかなり楽に進められます。 特に、PC モニタで見たときと VR 空間で見たときでは、UI の大きさや距離感の印象が大きく変わるので、XR 実機で前提確認しながら詰められるのはかなり便利です。

要するに、Triplex + R3F が特に向いているのは、完成品としての「見え方」や「体験」が重要なコンテンツです。 ゲームエンジンのような重いロジックを組むというより、3D を使った体験設計やプロトタイピングを高速化するツールとして考えると、かなりしっくりきます。

8. 向いていない用途

Triplex はかなり便利でしたが、触ってみてはっきり感じたのは、すべての Three.js 開発を置き換えるものではないということです。 特に、自分が普段作っているような MMD 時計アプリ のような方向になると、R3F + Triplex の気持ちよさよりも、逆に手間の方が目立ってきます。

これは Triplex が悪いというより、R3F がもともと強い領域と、自分が作っているアプリの性質が違うからです。

MMDアプリ

まず、MMD 系のアプリはかなり相性が分かれると感じました。 PMX / VMD の読み込み、モーションの更新、表情制御、会話、ポーズ切り替え、UI 連携、時刻同期などが絡んでくると、単純な 3D シーン表示ではなく、複雑な状態管理を持つアプリケーションになります。

このあたりは、R3F の宣言的な書き方だけでは収まりきらず、結局

  • useRef
  • useEffect
  • useFrame

のようなフックを多用して、内部ではかなり imperative に制御することになります。

つまり、見た目は React でも、やっていることはほぼ Three.js を React の中で直接回している状態 に近くなります。 ここまで来ると、素直にバニラ Three.js で全体を握った方が楽だと感じる場面が増えてきます。

ゲームロジック重い

同じことは、ゲームロジックが重いケースでも起きます。 例えば、

  • 毎フレームの更新処理
  • 当たり判定
  • 状態遷移
  • 入力制御
  • 複雑なアニメーション制御

のような要素が増えてくると、R3F の React 的な構成よりも、ゲームループを中心にした設計の方が自然になります。

もちろん R3F でもゲームは作れますし、実際に小さなミニゲームなら十分可能です。 ただ、ロジックが重くなればなるほど、React コンポーネントとしての気持ちよさは薄れ、そこまでやるならバニラ Three.js の方が分かりやすいのではという感覚が強くなります。

独自ランタイム

さらに、独自ランタイムを持つタイプのアプリとも相性はあまり良くありません。 例えば、自作の更新処理やアニメーション制御、特殊なシーン管理を積み上げている場合、それをそのまま R3F の構成へ馴染ませるには追加のラッパーや橋渡しが必要になります。

自分のように、過去の資産や独自の実装を積み重ねてきたケースでは、Triplex を導入するための変換コストの方が大きくなる可能性があります。 そういう場合は、最初から Triplex / R3F に寄せるより、従来どおり Three.js 側で制御した方が結果的に早いです。

GPGPU

GPGPU 系も同様です。 パーティクル、流体、ノイズ計算、Ping-Pong バッファのような処理は、もともとかなり低レイヤー寄りの実装になります。 こうした領域では、Triplex の GUI 編集や props ベースの調整が活きる場面はそこまで多くありません。

もちろん、GPGPU の結果を可視化するシーン全体を R3F で包むことはできますが、本質的な複雑さはシェーダや GPU 側にあるため、Triplex が解決してくれる問題ではないと感じました。

要するに、Triplex + R3F が強いのは 「見せるシーン」「体験を組むシーン」 であって、 「ランタイムを深く作り込むアプリ」 や 「低レイヤー実装が主役のアプリ」 になると、バニラ Three.js の方が自然です。

自分の感覚としては、

  • 展示・XRデモ・プロトタイプ → Triplex + R3F
  • MMDアプリ・重いロジック・独自ランタイム → バニラ Three.js

という切り分けがかなりしっくりきました。

Triplex は非常に強いツールですが、万能ではなく、得意分野がはっきりしている。 だからこそ、用途に応じて使い分けるのが一番現実的だと思います。

9. まとめ

Triplex を実際に触ってみて感じたのは、これは単なる 3D ビューアではなく、React Three Fiber の開発フローそのものを軽くするツールだということです。

今回試した流れはとてもシンプルでした。

  • Triplex をインストールする
  • プロジェクトを作成する
  • GUI エディタでシーンを編集する
  • その結果をコードへ反映する
  • さらに Quest2 へ送って WebXR で確認する

この一連の流れが、思っていた以上にスムーズでした。 特に、GUI で配置を調整しながら、その結果がそのまま JSX / TSX に保存される点はかなり強力です。 Three.js / R3F では地味に時間を取られやすい座標調整や見た目の詰めが、かなり直感的に進められます。

さらに、WebXR までそのまま繋がるのも大きな特徴でした。 前回の #29 では HTTPS や XRButton、LAN アクセスなどを自前で整えながら Quest2 での確認まで進めましたが、Triplex では 「XRボタンを押して、そのまま Quest へ送る」 という感覚で使えます。 この差はかなり大きく、XR 実機確認のハードルが一気に下がると感じました。

一方で、すべての 3D 開発に最適というわけではありません。 MMD アプリのように、複雑な状態管理や独自ランタイム、重いゲームロジック、GPGPU 処理が中心になる場合は、やはりバニラ Three.js の方が扱いやすい場面も多いです。 その意味で Triplex は、Three.js 全体を置き換えるものというより、R3F が得意とする領域をさらに加速するツールとして捉えるのが自然だと思います。

自分の感覚としては、使い分けはかなりはっきりしています。

  • 商品展示
  • インタラクティブLP
  • XRデモ
  • UIプロトタイプ

このあたりは、Triplex + R3F とかなり相性が良いです。

逆に、

  • MMDアプリ
  • 重いゲームロジック
  • 独自ランタイム
  • GPGPU

のような方向は、従来どおりバニラ Three.js の方がしっくりきます。

とはいえ、インストールしてすぐに GUI 編集と WebXR 実機確認まで到達できたのは素直にすごい体験でした。 R3F で 3D コンテンツや XR プロトタイプを作る人にとって、Triplex はかなり面白い選択肢になりそうです。

今回は最小構成の箱だけで試しましたが、次はもう少し踏み込んで、

  • 3D モデル読み込み
  • ライトや床を含めたシーン構築
  • UI を含んだ XR モック

あたりも試してみたいと思います。