VRゴーグルの視野変更と複数人同期はできる？SDKの仕様と検証ポイント

Matterport SDKにはズームAPIがありますが、VRゴーグル内での動作は未確認です。

複数人の誘導にはブラウザ向け公式サンプルがありますが、VRの視界同期は別途検証が必要です。

視野変更と同期について、公式仕様で確認できる範囲と開発時の判断点を整理します。

3行まとめ

• 通常のInside表示にはズームAPIがありますが、没入型VRでの視野変更を保証するものではありません。
• ブラウザ向けの遠隔操作サンプルはありますが、複数VRゴーグルの同期品質は確認されていません。
• 開発前に「何を拡大するか」「何を同期するか」を決め、対象端末で実機検証する必要があります。

VRの視野変更・同期に関する2つの相談と回答

Matterport（マーターポート）SDKで検討できるのは、表示のズーム操作や、別の閲覧者を同じ撮影地点へ案内する仕組みです。ただし、通常のブラウザ表示で利用できる機能と、VRゴーグル内で動作が確認された機能は分けて判断する必要があります。

本記事の出発点は、2026年8月31日にAdvalayへ寄せられた技術相談です。内容を要約すると、次のような質問でした。

• Webで閲覧するときのように、VRゴーグル内でも視野率を変更できるか。
• プレゼンテーションで、複数のVRゴーグルに同じ空間を同期して見せられるか。

相談では、Webでの表示操作について「70%〜300%」という範囲が挙げられていました。ただし、これは問い合わせ時の表現であり、SDKが保証するズーム範囲ではありません。

また、「同じ空間を同期して見せる」という言葉にも、複数の意味があります。同じ部屋に案内したいのか、同じ方向を向かせたいのか、頭を動かしても同じ映像を見せたいのかで、実装の難しさは異なります。

現時点の回答を整理すると、次のとおりです。

相談内容	公式資料で確認できること	断言できないこと
空間を拡大・縮小したい	Insideモード用のズームAPIがある	同じAPIが没入型VRでも同様に動くこと
ゴーグルの視野角を変えたい	WebXRでは表示範囲が光学系などの条件に依存する	SDKでゴーグル自体の光学的視野を変更できること
複数人を同じ場所へ案内したい	撮影地点の取得・移動APIと、ブラウザ向け遠隔操作サンプルがある	複数VRゴーグルでの動作や同期品質
全員の視線まで一致させたい	通常のパノラマ表示には方向を指定するAPIがある	頭部追跡を含めた完全な視界の一致

確認の基準日は2026年10月28日です。本記事は公式仕様に基づく説明であり、VRゴーグルでの実装・実機検証の結果を示すものではありません。

SDK全体の拡張用途を先に把握したい方は、Matterport SDKでできることを紹介した記事もあわせてご覧ください。

VRの「視野率」は3つに分けると判断しやすい

VRの視野変更を検討するときは、「ページの拡大率」「空間表示のズーム」「ゴーグルの視野角」を分けることが重要です。見た目にはいずれも拡大や表示範囲の変化に関係しますが、操作対象も制御方法も同じではありません。

1．ブラウザのページ拡大率と空間のズームは別の操作

ブラウザのページ拡大は、ページ内の文字や操作ボタンなどを含む表示に関係する機能です。一方、空間ビューアのズームは、空間の見え方を拡大・縮小する操作を指します。

マウスやトラックパッドを使った操作でも、それだけでページ拡大か空間ズームかは判断できません。 どの画面で何が変化したかを確認する必要があります。

例えば、ボタンや文字も大きくなった場合と、操作画面はそのままで室内だけが拡大された場合では、再現すべき機能が異なります。開発相談では、操作前後の画面や操作手順を共有すると認識を合わせやすいでしょう。

問い合わせにあった「70%〜300%」についても、数値だけをSDKの仕様へ置き換えるのは避けてください。百分率を倍率に換算できても、その倍率をSDKが受け付けることや、同じ見え方になることの証明にはなりません。

2．SDKのズームは基準視野に対する倍率の指定

MatterportのCamera.zoomTo()は、基準となる視野に対するズーム倍率を指定するAPIです。APIとは、プログラムから機能を呼び出すための操作窓口を指します。

公式のCameraリファレンスでは、ズーム倍率を2倍にすると視野角が半分になると説明されています。ただし、この説明をそのままゴーグルの光学的な視野へ当てはめることはできません。

利用できるズーム関連APIと、その制約は次のとおりです。

API	操作内容	仕様上の注意点
Camera.zoomTo()	指定した倍率へズームする	基準視野に対する倍率を指定する
Camera.zoomBy()	現在の状態からズームを変更する	Insideモード以外では失敗する
Camera.zoomReset()	ズームを初期状態へ戻す	ズーム倍率を1.0倍に戻す

Insideモードとは、撮影地点に立って周囲を見回すパノラマ表示のモードです。ズーム関連APIはいずれも、このモードで使用する仕様になっています。

対応範囲外の倍率を指定すると警告が出ますが、公式リファレンスには倍率の上限・下限が掲載されていません。そのため、受託開発の仕様書に特定の範囲を記載する場合は、対象環境での確認が必要です。

3．ゴーグルの光学的視野はズームAPIの対象と同一ではない

視野角は、見えている範囲を角度で表す概念で、FOVとも呼ばれます。VRゴーグルでは、レンズやディスプレイなどの条件が、適切な表示範囲に関係します。

W3CのWebXR Device API仕様草案も、没入型XRの表示範囲が光学系やディスプレイなどによって決まると説明しています。WebXRとは、WebからVRなどのXR機器を利用するための仕組みです。

ここで大切なのは、映像を拡大することと、ゴーグル自体の見える範囲を広げることは別の要件という点です。SDKのズームAPIがあることだけでは、ゴーグルの光学的視野を変更できるとはいえません。

「視野を変えたい」の意味	主な操作対象	開発前に確認すること
ページ全体を大きくしたい	文字や操作画面を含むWebページ	ブラウザ操作の再現が目的か
室内の一部分を大きく見たい	空間ビューアの表示	ズームAPIで目的を満たせるか
ゴーグルで見渡せる範囲を変えたい	没入型VRの投影や光学条件	ハードウェア側の条件を含む要件か

この区別をせずに「視野率変更機能」として発注すると、完成後に期待との違いが生じかねません。「壁面の細部を見たい」「広く見渡したい」など、達成したい見え方から整理することをおすすめします。

VRゴーグル内のズームはXR仕様の3点を確認する

VRゴーグル内でのズーム可否は、Camera APIの存在だけでは判断できません。MatterportのXR文書は、SDKとの組み合わせを実験的と位置づけているため、利用方式、実機での動作、表示の快適さを分けて確認する必要があります。

1．XRとSDKの組み合わせは実験的な扱い

MatterportのUsing XRには、XRモードとSDKの組み合わせは実験的であり、すべてのSDK機能の動作は保証されないと明記されています。

したがって、通常のInside表示で使えるCamera.zoomTo()についても、没入型VRで同じ結果が得られるとは断言できません。「通常表示でAPIが使える」と「ゴーグル内で期待どおり動く」は別の確認事項です。

同じ文書には、開発用PCのWebXRエミュレーターで使えるAPIでも、ヘッドセットでは動かない場合があるという注意があります。エミュレーターは開発時にXR環境を模擬するもので、実機確認の代わりにはなりません。

検証結果を共有するときも、PC上で確認した結果と、実際にゴーグルを装着して確認した結果を分けて記録しましょう。

2．「VRにはBundle SDKが必須」とは限らない

Embed SDKは埋め込んだビューアを操作する方式、Bundle SDKは配布されたビューアを自らホストして組み込む方式です。XRの検討では、この違いも確認対象になります。

ただし、公式のXR文書はBundle SDKだけを対象としているわけではありません。Embed SDKアプリケーションについても記述があり、「VRを使うならBundle SDKが必須」とする根拠にはなりません。

文書では、Embed SDKや別オリジンでホストするBundleアプリケーションについて、iframeにallow='xr-spatial-tracking'を設定するよう案内しています。iframeとは、別のWebコンテンツをページ内へ埋め込むための枠です。

この設定は、XR利用に必要な埋め込み条件の確認に役立ちます。ただし、設定を追加しただけでズームや同期まで動作するという意味ではない点に注意してください。

対応端末についても、開発手順に機種名が出ていることと、全機能が保証されていることは異なります。利用予定の端末・ブラウザを決め、公式XRドキュメントと実機の両方で確認する必要があります。

3．投影の書き換えを安易な代替策にしない

SDKで期待したズームができない場合でも、投影行列の書き換えを簡単な解決策として扱うのは適切ではありません。投影行列とは、立体空間を画面へ映す際の見え方を定める数値のまとまりです。

WebXRの仕様草案は、提供されるprojectionMatrixを変更・分解せず使用することを強く推奨しています。従わない場合は、表示の歪みや位置ずれによって不快感が生じる可能性があるためです。

また、inlineVerticalFieldOfViewは非没入型のinlineセッション向けで、没入型セッションではnullでなければなりません。この設定を、ゴーグル内の視野角を自由に変える手段と解釈することはできません。

一方で、WebXRの規定だけを根拠に、あらゆる拡大表現が不可能と断定するのも行き過ぎです。必要なのは、求める拡大表現を明確にしたうえで、対応する方法と快適性を検証することです。

複数人の同期表示は3段階に分けて設計する

複数人の同期表示には、「同じ場所へ移動する」「同じ方向へ案内する」「視界そのものを一致させる」という段階があります。ブラウザ向けには公式の遠隔操作サンプルがありますが、それだけで複数VRゴーグルの完全な視界同期が保証されるわけではありません。

1．同じ撮影地点へ案内する

スイープとは、空間を見回す基準となる撮影地点です。MatterportのSweep.moveTo()を使うと、指定したスイープへ移動できます。

案内役が選んだスイープを参加者側へ伝え、参加者のビューアにも移動を指示する構成が考えられます。プレゼンテーションで「同じ部屋へ移り、各自で周囲を見る」ことが目的なら、まず検討したい範囲です。

ただし、同じ撮影地点へ移動することは、同じ視界になることと同義ではありません。それぞれの参加者が別の方向を見れば、表示される対象も変わります。

2．同じ対象を見るように方向を案内する

Camera.setRotation()は、Panorama Viewで視点方向を指定するAPIです。通常のパノラマ表示では、案内役の回転情報をもとに、参加者へ方向を適用する構成が考えられます。

また、Sweep.moveTo()には移動時の回転を指定するオプションがあります。公式のSweepリファレンスによると、この回転はCamera.poseから取得する回転と同じ形式です。

一方、VRゴーグルでは、装着者の頭の動きに応じて視界が変わります。プログラムからの方向指定と頭部追跡がどう関係するかは、通常のブラウザ表示とは分けて確認しなければなりません。

「説明対象へ一度向きを合わせたい」のか、「説明中は向きを固定したい」のかも区別しましょう。後者は参加者の自然な閲覧を妨げる可能性があり、快適性を含む慎重な検討が必要です。

3．全員の視界を完全に一致させる

全員が常に同じ映像を見る要件では、場所や方向の共有だけでは不十分です。頭部追跡、表示タイミング、通信の遅れなども関係します。

公式資料では、複数VRヘッドセットでの頭部方向の同期や遅延、参加人数の上限は確認できません。そのため、「任意の人数へ遅延なく同じ視界を配信できる」とは案内できません。

同期の段階	プレゼンテーションでの目的	判断上の注意点
同じ撮影地点を共有	同じ部屋を各自で見回す	場所が同じでも視線は異なる
案内する方向を共有	説明対象へ注目してもらう	VRでは頭部追跡との関係を確認する
視界全体を一致	同じ映像を継続して見せる	SDK資料だけでは実現性や品質を保証できない

プレゼンテーションの目的が「参加者が説明場所を見失わないこと」なら、最初から視界全体を固定する必要はないかもしれません。同じ場所への移動と、注目してほしい対象の案内を分けると、必要な同期範囲を絞れます。

同期開発で根拠になる公式サンプルと4つのAPI

同期開発の根拠になるのは、MatterportのRemote Control公式サンプルと、閲覧状態の取得・移動・方向指定に関するAPIです。これらは設計の出発点になりますが、参加者間の通信やVRでの動作確認までを自動で提供するものではありません。

1．Remote Controlはブラウザ向けの公式サンプル

Remote Control公式サンプルは、Showcase Embed SDKを利用し、ホストの操作でほかのユーザーの体験を進行させるものです。

ホストはセッション名とモデルIDを入力し、参加者は稼働中のセッションを選んで参加します。複数のブラウザウィンドウを使い、同じ人がホストと参加者を試せることも説明されています。

このため、「SDKでは複数人の誘導が一切できない」という回答は正確ではありません。一方、説明ページだけでは通信方式やSDK以外の依存サービスまで確定できず、VRゴーグル向けの動作保証もありません。

ここではサンプルの存在と説明内容を紹介しています。サンプルを実行して性能や安定性を検証した結果ではない点は区別してください。

2．取得と操作に使うAPIを分ける

独自の同期を考える場合、まずは「案内役の状態を取得する機能」と「参加者の表示を操作する機能」を分けて整理します。

API・プロパティ	役割	確認しておきたい制約
Camera.pose	位置・回転・スイープ・表示モード・投影行列を購読する	取得できる情報すべてを、そのまま別端末へ適用できるわけではない
Sweep.current	現在のスイープを購読する	移動中や表示モードによってsidが空文字になる場合がある
Sweep.moveTo()	指定したスイープへ移動する	通信や別ユーザーとの同時実行を提供するAPIではない
Camera.setRotation()	パノラマ表示の視点方向を指定する	没入型VRでの頭部追跡との関係は別途確認が必要

購読とは、状態が更新されたときに通知を受け取る仕組みです。現在のCameraリファレンスでは、getPose()は非推奨とされ、Camera.poseの購読が案内されています。

ここで注意したいのは、取得できる項目が多いからといって、同じ状態を完全に再現できるとは限らないことです。例えば、投影行列を取得できることは、ほかのVRゴーグルへそのままコピーしてよい根拠にはなりません。

3．独自の同期層は設計候補として考える

同期層とは、案内役の操作や状態を参加者へ伝え、適用するための仕組みです。独自実装では、次のような流れが候補になります。

• 案内役のCamera.poseやSweep.currentから必要な状態を受け取る。
• 参加中のユーザーへ、対象モデルやスイープなどの情報を送る。
• 参加者側で受け取った情報を確認し、移動や方向指定を行う。
• 適用できなかった場合は、再試行や再参加の扱いを決める。

通信方法としてWebSocketなどを検討できますが、これは設計上の選択肢です。ここで参照した公式資料が、その方式を推奨構成として指定しているわけではありません。

また、状態を送る仕組みだけでなく、誰が案内役か、参加者が途中で自由閲覧へ切り替えられるか、といった操作ルールも必要です。通信と画面操作をつなぐだけでは、会議で使いやすい同期機能にはなりません。

VR同期で先に避けたい4つの実装上の落とし穴

VR同期では、移動中の状態、操作の競合、途中参加、検証環境の違いが問題になりやすい確認点です。いずれも実際の失敗事例として挙げるものではなく、公式APIの制約と同期構成から、設計時に備えておきたい項目です。

1．移動途中の空のスイープIDを送ってしまう

Sweep.currentのsidは、常に有効な撮影地点を示すとは限りません。スイープ間の移動中や、Dollhouse・Floorplan表示などでは空文字になる場合があります。

この状態を区別せず参加者へ送り、移動先として扱う設計は避けましょう。有効なスイープに到着してから通知するか、移動中であることを別の状態として扱う必要があります。

根拠となる条件は、Sweepリファレンスで確認できます。

2．案内役の指示と参加者の操作が競合する

参加者が自分で見回している最中に、案内役から方向指定が繰り返し届くと、意図しない表示変更につながる可能性があります。VRでは頭の動きも関係するため、操作の優先順位を決めておくことが重要です。

施設案内が目的なら、「場所は案内役に合わせるが、見回しは各自に任せる」という設計を優先して検討してみてください。説明対象へ向ける操作が必要な場合も、常時固定ではなく、参加者が追従を選べる方式が候補になります。

3．途中参加した人が現在地に追いつけない

同期を「操作が発生したときだけ送る」構成にすると、途中参加した人が直前の状態を受け取れない可能性があります。再接続した場合も同様です。

そのため、操作通知とは別に、現在の案内先を共有する方法を考えましょう。対象モデル、現在のスイープ、追従状態など、復帰時に必要な情報を整理すると設計しやすくなります。

モデルが異なる状態で移動指示だけを送らないことも確認点です。参加者が同じ空間に入れているかを、移動の前提条件として扱います。

4．ブラウザで成功した結果をVRの動作保証にする

ブラウザウィンドウ同士で誘導できても、複数VRゴーグルで使えることの証明にはなりません。PCのエミュレーターについても、公式XR文書が実機との差を注意しています。

検証記録には、利用した端末・ブラウザ・表示方式と、確認した操作を残してください。「同期できた」という一言ではなく、「撮影地点の共有を確認したが、頭部方向の同期は対象外」と書き分けることが大切です。

VR視野変更・同期を検証する4ステップ

開発を始める前に、要件整理、通常表示での確認、VR実機での確認、複数端末での確認を順に進めることをおすすめします。一度にすべてを試すよりも、SDKの制約なのか、通信の問題なのか、XR特有の挙動なのかを切り分けやすくなります。

STEP1．見え方と同期の目的を文章にする

最初に「視野率を変更したい」を、具体的な利用場面へ置き換えます。室内の細部を拡大して見せたいのか、全体を広く見渡したいのかで、検討する方法が変わります。

同期についても、「同じ部屋に集まってほしい」と「同じ対象を見てほしい」を分けてください。全員の視界を固定しなくても目的を満たせるなら、必要な機能を限定できます。

相談前には、次の情報をまとめておくとよいでしょう。

整理する項目	記載する内容
利用場面	内覧、施設案内、プレゼンテーションなど
視野変更の目的	細部の拡大、広い範囲の確認など
同期する対象	撮影地点、案内方向、視界全体のどれか
参加者の自由度	自由閲覧の可否、追従の解除方法
利用環境	端末、ブラウザ、ネットワーク
運用条件	想定人数、途中参加、再接続の必要性

STEP2．通常のブラウザ表示でAPIを確認する

通常のInside表示でズーム操作を確認し、指定した倍率に対する結果や警告を記録します。問い合わせの数値をそのまま保証範囲にせず、必要な見え方を満たすかで判断しましょう。

同期については、公式Remote Controlサンプルを検証の候補にできます。ただし、サンプルを動かす際は、必要な設定や依存する仕組みを確認したうえで利用してください。

この段階では、通常表示での機能確認と、VR向けの検証を混ぜないことが重要です。

STEP3．対象のVRゴーグルで機能を切り分ける

次に、実際に使うゴーグルでXR表示を確認します。表示への移行、ズーム操作、撮影地点の移動、方向指定をそれぞれ分けて試すと、問題の所在を把握しやすくなります。

確認すべきなのは、API呼び出しがエラーにならないことだけではありません。装着者の見え方が意図どおりに変わるか、頭を動かしても不自然にならないかを確かめます。

表示に歪みや違和感がある場合は、機能が動作したという理由だけで採用しないようにしましょう。

STEP4．複数端末と実際の運用条件で確認する

個々のゴーグルで必要な操作を確認できたら、複数端末を使って案内の流れを試します。通常の参加だけでなく、途中参加や接続が切れた後の復帰も対象にしてください。

同じ場所へ移動するタイミングに差がある場合は、会議の進行上許容できるかを判断します。必要な同期品質は、説明内容や参加者の操作方法に合わせて決めることが大切です。

最終的には、確認済みの機能と未確認の機能を一覧に残します。採用判断は「技術的に呼び出せるか」だけでなく、「目的の環境で無理なく使えるか」を基準にしてください。

VR対応・同期開発の費用は3つに分けて確認する

VR対応や同期開発の費用は、SDKの利用条件、技術検証、本開発・運用を分けて確認する必要があります。現行料金や開発費用を裏づける情報がないため、一律の金額ではなく、見積もりの前提となる作業範囲を整理します。

1．SDKや関連サービスの利用条件

まず確認したいのは、対象モデルをどの契約・環境で表示し、どのSDK方式を利用するかです。SDKの利用条件や公開方法に加え、独自の同期機能に必要なサービスも整理します。

通信サーバーなどを別途用意する構成なら、その運用費はビューアの開発費と分けて扱いましょう。初期開発だけでなく、公開後の管理主体を決めておくことも大切です。

2．実現性を判断するための検証

VRゴーグル内のズームや方向指定には、未確認の部分が残っています。そのため、完成機能の実装を前提にするのではなく、実現性を確認する作業を先に切り分ける方法が適しています。

検証の成果物は、動作する画面だけではありません。対応できた条件、動かなかった操作、代替案、採用しない場合の理由も、開発判断に必要な情報です。

3．本開発と継続運用

本開発では、同期そのものに加えて、参加画面、案内役の権限、追従の切り替え、再接続などが費用に関係します。利用目的に不要な機能まで含めないよう、対象範囲を定めましょう。

検討する構成・範囲	費用に関係する作業	金額を確認する前の条件
ブラウザ同士の案内	移動操作、参加管理、状態共有	同期対象と参加方法
VRゴーグルでの視野変更	XR環境の準備、ズームの実機確認	端末・ブラウザと求める見え方
複数VRゴーグルの案内	通信、移動、頭部追跡との関係の確認	想定人数と追従ルール
会議で継続利用する仕組み	再接続、権限管理、保守	運用担当と利用環境

利用台数が変われば、確認すべき接続や運用の条件も変わります。ただし、人数だけから開発費を決めることはできず、視界固定などの要件が加わるかどうかも重要です。

同じ場所への案内が目的なら、撮影地点の共有を優先して検討します。全員の視界固定が必須なら、採用判断の前に専用の実機検証を行います。 この順序なら、未確認機能を前提に開発範囲を広げずに済みます。

よくある質問

VRの視野変更と同期では、公式APIの有無と、対象ゴーグルでの動作保証を分けて考える必要があります。導入前に迷いやすい点について、仕様から回答できる範囲を整理します。

70%〜300%の範囲でズームできると考えてよいですか？

その範囲をSDKの保証値として扱うことはできません。問い合わせにあった数値と、SDKが受け付ける倍率の範囲は別に確認する必要があります。

Cameraリファレンスには、範囲外の指定で警告が出ることは記載されていますが、上限・下限は掲載されていません。通常表示での確認に加え、VRで使う場合は実機検証も必要です。

VR表示にはBundle SDKへの変更が必要ですか？

必須とは断言できません。Using XRはEmbed SDKも対象としており、iframeに必要な設定も案内しています。

既存サイトの埋め込み方式と、実装したい操作を照らし合わせて判断してください。Bundle SDKへ変更するだけで、ズームや同期の未確認事項が解消するわけではありません。

公式サンプルを使えば、複数のVRゴーグルをすぐ同期できますか？

そのまま使えるとは保証できません。Remote Control公式サンプルは、ブラウザでホストが参加者を誘導する構成の参考になります。

一方、複数VRヘッドセットでの動作、頭部方向の同期、遅延、参加人数上限は説明されていません。VR用途では、サンプルの確認と実機検証を別の作業として考えましょう。

案内役と同じ場所へ移動し、参加者は自由に見回せますか？

同じ撮影地点への移動にはSweep.moveTo()が設計上の候補になります。ただし、VRゴーグルで移動と自由な見回しを組み合わせた動作は、対象環境で確認が必要です。

要件としては、場所の追従と方向の追従を分ける方法がおすすめです。参加者の見回しを残せるなら、視界全体を固定するより目的に合う場合があります。

開発相談の前に何を用意すればよいですか？

利用予定の端末・ブラウザ、対象の3Dスペース、拡大したい対象、同期したい範囲を整理してください。Webで再現したい操作がある場合は、その手順や操作前後の画面も役立ちます。

「同じ部屋に案内できればよい」のか、「同じ方向まで揃える必要がある」のかを決めておくと、検証すべきAPIと運用条件を絞りやすくなります。

まとめ

Matterport SDKには、通常のInside表示で利用するズームAPIと、閲覧状態の取得・撮影地点の移動・方向指定に関するAPIがあります。ただし、その存在だけでVRゴーグル内の視野変更や、複数人の完全な視界同期を保証することはできません。

複数人の誘導にはブラウザ向けの公式サンプルがありますが、XRとSDKの組み合わせは実験的な扱いです。まずは「何を拡大するか」「場所と方向のどちらを同期するか」を整理し、必要な機能から実機で確かめましょう。

弊社Advalayへの技術的なご質問は、LINEやメールでお気軽にご相談ください。利用予定のゴーグルや、プレゼンテーションで実現したい見せ方を添えていただくと、確認したい論点を具体化しやすくなります。