Matterport（マーターポート）SDKでできること・費用と依頼先の選び方【開発事例】

Matterport（マーターポート）で撮影した3D空間を、自社のシステムに組み込んで業務で使いたい。そう考えたときに出てくるのがSDKです。本記事では、SDKとは何かという前提から、どんなときに開発が必要になるのか、費用と依頼先の見極め方、そして実際の開発事例までを整理します。

1. Matterport SDKとは

1.1 Matterport SDKでできること

Matterport SDKは、Matterportで撮影した3Dバーチャル空間を自社のWebアプリケーションやシステムに組み込むための開発者向けツールキットです。撮影した空間を自社サイトに「埋め込む」だけなら不要ですが、空間の中でユーザーに何かを操作させたり、他システムのデータと連動させたりするにはSDKが必要になります。

できることは大きく5つ。

カスタムタグ・ホットスポットの設置とクリックイベントの検知、視点移動のプログラム制御、外部API・データベースとの連携、自社ブランドに合わせたUI/UXの実装、空間内の行動ログ取得と解析ツールへの統合です。

1.2 SDKは3種類。Embeds・Bundle・APIの使い分け

ツール	できること	向いているケース
SDK for Embeds	埋め込んだビューアをJavaScriptから制御。タグ操作、視点移動、イベント取得など	既存サイトに空間を組み込み、UIや導線を作り込む
SDK Bundle	SDK for Embedsの拡張。自社ドメイン上で動かし、3Dエンジン・レンダラー・シーングラフへ直接アクセスできる	3Dオブジェクトの配置や独自描画まで踏み込む
Model Data API	空間のメタデータ（間取り、タグ情報など）をプログラムから取得	自社DBや業務システムとデータを同期する

SDKはJavaScript（TypeScript）ベースのため、フロントエンド経験者なら着手自体は難しくありません。ただし3D空間特有のデータ構造やイベントモデルの理解が必要で、業務要件に合う実装まで持っていくには相応の知見が要ります。

1.3 Matterport SDKでもできないこと・制限

撮影済みの3Dモデルそのものの形状を作り変えることはできず、精度は撮影時の品質に依存します。空間の作り直しが必要な変更や、Matterport側の仕様に依存する挙動の書き換えもSDKの範囲外です。「どこまでがSDKで、どこからが撮影・運用の話か」を最初に切り分けておくと、要件定義の手戻りが減ります。

2. なぜSDK開発が必要になるのか

2.1 開発が必要になる3つのパターン

空間を見てもらうだけなら標準機能で足ります。SDK開発が必要になるのは、3D空間を「見せるもの」から「業務で使うもの」に変えようとしたときです。典型的なのは次の3パターンです。

• 他システムのデータと連動させたい：
  設備台帳や点検履歴、IoTのセンサー値を空間内に反映させる。CRMと連携して問い合わせ情報を自動登録する。BIMデータ（IFC等）を紐づけて表示する。

• 自社ブランドのUIで、自社ドメインで出したい：
  ビューアの見た目やナビゲーションを自社の仕様に合わせる。認証基盤と連携してアクセス制限付きで運用する。

• 現場の環境に合わせてチューニング・カスタマイズしたい：
  通信環境が厳しい現場や、タブレット・スマートフォンでの動作を前提に、読み込みや描画を最適化する。

逆に言えば、この3つに当てはまらない場合は開発せずに済む可能性があります。後述するように、施設・設備管理の用途は既存の製品で足りることが多い領域です。

2.2 開発支援の4つの形態

開発支援と一口に言っても、任せる範囲によって形態が分かれます。社内の体制と、SDKの知見を将来的に自社へ残したいかどうかで選ぶのが基本です。

支援形態	適している場面
受託開発型（要件定義〜納品まで一括）	社内にエンジニアがいない・不足している
技術顧問型（設計方針や実装方法の助言）	チームはあるがSDKの知見がない
ラボ型（一定期間チームに参画）	長期の機能拡張・保守が必要
PoC支援型（実現可能性の検証）	新規サービスの立ち上げ初期

国内では「撮影してデータ化する人」はたくさんいても、Matterport SDKの実装経験を持つエンジニアはまだ多くないため、ゼロから学習するより実績のある会社に任せたほうが早いケースが大半です。一方で、SDKを自社プロダクトのコア技術として育てたい場合は、受託開発と技術顧問型を組み合わせ、内製チームの育成と並走させる進め方も有効です。要件が固まっていない段階なら、まずPoC支援型で小さく検証してから範囲を広げると判断を誤りにくくなります。

2.3 依頼先を選ぶ3つの確認ポイント

開発会社の選定で見るべきは、料金の安さや会社の規模ではありません。SDKという狭い領域の経験値と、納品したあとまで並走できる体制があるかどうかです。初回の打ち合わせで、次の3点を聞いてみてください。

① SDK固有の実装実績があるか：
「Matterportを知っている」だけでは不十分です。SDK for Embeds・SDK Bundle・Model Data APIをそれぞれ実際に使った経験と、自社に近い業種・規模の実績を確認しましょう。件数より「どの機能をどう使い、どんな技術課題をどう解いたか」を聞くほうが実力が分かります。

② 周辺技術までカバーできるか：
実際の開発ではフロントエンド、バックエンド、DB、クラウドインフラが組み合わさります。「SDKしか対応できない」会社より、周辺技術まで見られる会社のほうが要件変化への対応力が高くなります。

③ 納品後の保守体制があるか：
SDKは継続的にバージョンアップされ、API仕様の変更も起こります。特に重要なのがソースコードと設計ドキュメントの所有権です。ここが曖昧なまま進むと、将来の乗り換えや内製化の障壁になります。

あわせて確認したいのが「SDKキーを誰が持つか」です。SDKを本番ドメインで動かすには管理者権限のアカウントで本番用キーを発行する必要があり、発行本数にも上限があります。さらにキーは発行した管理者ユーザーに紐づくため、その担当者が組織を離れるとキーが失効し、作り直しが必要になります。ここを開発会社任せにしていると、担当者の異動をきっかけに空間が表示されなくなる、という事故が起こり得ます。

3. Matterport SDK開発の費用と期間の目安

開発費は要件で大きく変わります。動くのは主に、連携する外部システムの数、対応デバイスの範囲、拠点・空間の数、権限設計の細かさの4つです。以下はArchiTwinが関わった案件をもとにした規模感の目安です。

※以下費用例

規模	主な内容	費用の目安	期間の目安
小規模	空間作成、タグ配置等、ArchiTwinの作業代行	50万〜100万円程度	1〜2か月
中規模	機能追加、外部API・DB連携、管理画面の開発	200万〜500万円程度	3〜6か月
大規模	基幹システム統合、アクセス解析実装、複数拠点対応など	500万円以上	6か月〜1年以上

時間がかかりやすいのは要件定義と結合テストです。要件が曖昧なまま着手すると手戻りで納期も費用も膨らみます。コストを抑えるにはコア機能から先に出すフェーズ分割型が有効です。なお開発費とは別に、Matterportのライセンス費と撮影費が発生します。ArchiTwinではMatterportの取り扱いもあるため、プラン選定から合わせてご相談いただけます。

4. ArchiTwinの開発事例

ArchiTwinは、Matterportの3D空間に機能・情報・管理を重ねるサービスです。開発事例では、標準機能では届かない業務要件を、SDKと3Dデータの両面から実装しています。対応範囲はMatterportのアプリ開発でも紹介しています。

4.1 株式会社梓設計様｜デジタルツインの共同構築から、プラットフォーム開発へ

羽田空港第2ターミナルなどの設計実績を持つ同社とは、創業75周年企画として実際のオフィスを歩けるデジタルツイン空間を共同構築しました。動画はストリーミング再生、パネルは2D画像で軽量化し、ウォークスルーが滑らかに動くよう画質を調整しました。地道なチューニングの積み重ねです。この取り組みは遠隔の建築現場・設備管理での活用へ広がりました。

4.2 ShipTwin｜通信環境が厳しい船内を、デジタル空間で共有する

大晃機械工業株式会社様との業務提携で船舶向けに展開しているのが「ShipTwin」です。機関室や配管まわりは構造が複雑で、陸上の担当者や新人に状況を伝えるのが難しい領域でした。しかも洋上では通信環境が厳しく、映像通話のような重い手段は現実的に使えません。

そこで、重い映像に頼らずに同じ空間を見ながら会話できる仕組みを実装し、船舶管理に特化したサービスとして構築しました。加えて、パートナー企業が自社ブランド・自社ドメインで展開できるOEM型の提供にも対応しています。自社の業界知見と3D空間を組み合わせて新しい事業を立ち上げたい、という相談から始まった案件です。

5. 施設・設備管理なら「ArchiTwin PRO」という選択肢

一方で、すべてが開発案件になるわけではありません。水処理施設やポンプ場の設計を手がける株式会社NJS様は、既存図面と現況の差による手戻りを減らすため、3Dオブジェクトの配置機能で構築イメージを提示し、工事後の維持管理動線の確認にも活用されています。これは開発ではなく、製品の標準機能で実現した例です。ほかの導入事例はお客様の声でご覧いただけます。

このように、施設・設備管理の用途は既存の製品でカバーできる範囲が広い領域です。現場で繰り返し求められる機能を製品化したのが、施設・設備管理特化のデジタルツインエンジン「ArchiTwin PRO」です。

• デジタル資産の統合：
  BIM/CAD・点群・既存図面・建物台帳を3D空間に集約するハブとして機能

• タグによる情報の空間化：
  点検内容や修繕計画を3Dモデル上のタグに紐づけ、情報の検索時間を削減

• 3D空間内チャット：
  「いつ・どこで・何が」を指定箇所に記録し、現場ナレッジを資産化

• エンタープライズ基準のアクセス管理：
  メールアドレスで招待された方のみが閲覧できる認証基盤に加え、空間単位・タグ単位での閲覧権限制御

インフラ・プラント・ビルメンテナンス・工場設備管理などでは、まずPROで運用を始め、自社固有の要件が出た部分だけカスタマイズ開発で足す進め方が、コスト・スピードの両面で現実的です。「どこまでが標準機能で、どこからが開発か」の切り分けから相談できる点が、製品と開発支援の両方を持つ強みです。

6. まとめ

SDK開発でつまずきやすいのは、要件が固まらないまま見積もりを取りに行くケースです。まずSDKでできることとできないことを切り分け、そのうえで実装実績と保守体制、SDKキーの管理まで含めて依頼先を選ぶ。費用は初期費用ではなく、運用・保守を含めた年間の総額で比較する。この順番を守るだけで、手戻りの大半は防げます。

そしてもう一つ、作る前に既にある製品で足りないかを確認する視点も忘れないでください。開発が必要なのは、他システムとの連動、自社ブランドでの展開、現場環境に合わせたチューニングのいずれかが要件に入るときです。

施設・設備管理ならArchiTwin PROから、それ以外の用途なら開発支援から。まだ要件が固まっていない段階でも構いません。想定している用途をお聞かせいただければ、実現可否と概算レンジ、標準機能で足りる範囲までを30分でお伝えします。