--- title: "我々はXRデバイスのUIフレームワークとしてMRTKを使い続けるべきなのか？" emoji: "📝" type: "tech" topics: ["ホロラボ Advent Calendar 2024"] published: true published_at: "2024-12-18 10:09" cover: "./20241218115229.jpg" category: "info" author: "中村 薫" description: "ホロラボ Advent Calendar 2024、18日目は、林が担当します。 adventar.org この Advent Calendar 、執筆担当日とテーマタイトルは、ホロラボCEOの中村から打診があります。 今日の担当テーマは「" original_url: "https://blog.hololab.co.jp/entry/2024/12/18/100956" --- ![](./20241218115229.jpg) ホロラボ Advent Calendar 2024、18日目は、林が担当します。 [adventar.org](https://adventar.org/calendars/10905) この Advent Calendar 、執筆担当日とテーマタイトルは、ホロラボCEOの中村から打診があります。 今日の担当テーマは「ソフトウェア開発における技術トレンド」なのですが難しいテーマです。 たぶん、ChatGPTが提案したテーマだと思います。 悩んだのですが、今回はテーマに沿いつつ、「我々はXRデバイスのUIフレームワークとしてMRTKを使い続けるべきなのか？」というタイトルで記事を書きます。 ## そもそもMRTKって何? MRTK とは Mixed Reality Toolkitの略称で、Unity上でクロスプラットフォームでXRデバイス向けのUI構築を行う事ができるフレームワークです。 - Mixed Realityツールキット3 - [https://learn.microsoft.com/ja-jp/windows/mixed-reality/mrtk-unity/mrtk3-overview/](https://learn.microsoft.com/ja-jp/windows/mixed-reality/mrtk-unity/mrtk3-overview/) アプリケーション開発者はMRTK を利用することで、いろいろなXRデバイスで動作するユーザーインターフェースを比較的簡単に構築することができ、アプリが本来持つ価値の提供（PoCの早期実現やロジックの実装)に専念ができます。 MRTKはマイクロソフトが推進するオープンソースプロジェクトで、無料で利用する事ができます。 リリース当初は、HoloLens や Windows Mixed Reality などのMRデバイスに対応するアプリケーション開発のためには必須のものとして登場し、私自身も、ホロラボとしても多くのアプリケーションをMRTKを用いて、開発をしてきたした。 対応デバイスは順次拡充されつつ、開発者自身も自らカスタマイズできる事から、現在ではHoloLensのみならず多くのデバイスへの対応が行われています。 ### MRTKが対応しているデバイスの例 ※(非公式/実験的なものも含みます) - Meta Quest 3 - Apple Vison Pro - Think Reality A3/MiRZA (Snapdragon Spaces) - Magic Leap 2 - Microsoft HoloLens 2 - Varjo XR-3 ## MRTK、良いのだけど、ご利用は慎重に。 MRTKは素晴らしいツールキットなのですが、私自身、利用するのは慎重派です。 XRアプリ開発するなら利用して当然かというと、以下のデメリットもあると思っています。 1. 動作が重くなる/ビルドが遅くなる - リッチなUIフレームワークであり、半透明処理も採用されていて、簡単に見栄えのするアプリケーションが作れるのは良いが、導入した時点で、CPUやメモリリソースをある程度使ってしまい、本来の表示したいコンテンツに割り当てられるコンピューターリソースが減ってしまう。（ただし、最近のMRTKは改善しているという話も聞いてたりはするので、昔の印象かもしれません） 2. スマートフォンと共通のUIが作れない（一度使うと、やめられない） - 空間UIに特化した3D UIコンポーネントを利用した操作体系なので、iPadとXRデバイスなど、スマホとのクロスデバイスアプリケーションの場合は、共通UIが作れない。後からスマートフォン対応しようとしたときに苦労する。 3. UIとロジックが混ざってしまいがち - 大量の便利なサンプルシーンや使いやすいコンポーネントが揃っており、PoCやモックアプリを、素早く作ることができるのですが、その反面、ロジックとUIが混ざってしまいがち。簡単に実装できる分、設計が疎かになってしまい、移植性や拡張性に問題が発生することがあります。 2と3はいずれも、設計段階で考慮すれば、許容できる話で、便利さの裏返しの気もしますが、考えずに導入すると、のちのち、面倒なことになったりします。 いずれにせよ、長期にわたってメンテナンスするプロジェクトにおいては、ロジックとMRTK UIの分離を慎重に行なう必要があると考えています。 ## Apple Vision Pro の登場でXRデバイスのUIのスタンダードは劇的に変化した 仕事がら、様々なXRデバイスを同時に使う（かぶり変える)のですが、Apple Vision Proを装着して作業した後、Meta Quest 3を装着すると、操作体系の違いに、意識がついていかず、戸惑ってしまう事があります。 Apple Vision Proが登場するまでは、複数のXRデバイスを連続して装着してもほとんど気になりませんでした。 Apple Vision Pro は、高精度のアイトラッキングがついているので、操作対象を見つめて、膝の上で指を小さくタップすることで、UIの操作ができます。 それに対して、Meta Quest 3やMRTKなどの従来のXRの操作は、コントローラーからのレーザーで操作対象を選択して、トリガーを引いたり、腕を持ち上げて、ハンドトラッキングで、操作対象のボタンをケンシロウのように直接指でタップする必要があります。体を動かす量が全然違います。 Meta QuestやMRTKの操作フィールは、それまでは、あたりまえに思っていたのですが、Apple Vision Pro と併用していると、違和感を感じるようになってきました。大げさなのです。 Apple Vision Pro の登場でXRデバイスのユーザーインターフェースの正解/王道が変わりました。 Meta Horizon OSも、最近のアップデートではApple Vision Proを意識した機能追加や、UIのテイストも寄せてきているように思います。 先週発表された Android XR においても、その仕様やUIなど、Apple Vision Proをかなり意識/研究して作られたものであることがわかります。 Apple Vision Pro のUIデザインは当然ながらiOSなどのスマートフォンデバイスとの親和性も考慮して設計されているので、ビッグテックの既存資産やエコシステムの有効活用の観点からも、この流れは続くものと思われます。 ### Android XR - Android XR - [https://developer.android.com/xr](https://developer.android.com/xr) - Design for Android XR - [https://developer.android.com/design/ui/xr](https://developer.android.com/design/ui/xr) ### Meta Horizon - Meta Horizon OSのヒューマンインターフェイスガイドライン - [https://developers.meta.com/horizon/design/](https://developers.meta.com/horizon/design/) ### visonOS - visionOS向けのデザイン | Apple - [https://developer.apple.com/jp/design/human-interface-guidelines/designing-for-visionos](https://developer.apple.com/jp/design/human-interface-guidelines/designing-for-visionos) ## で、MRTKはこれからも使うべき？ ここまで書いて、冒頭のテーマに戻ります。 visionOSの登場でXRデバイスのユーザーインターフェースのトレンドは大きく変わりました。 MRTKは2016年に登場したHoloLens 1 からのデザイン思想を引き継いで既に8年、かなり古くなってきています。 これから新たに始まるプロジェクトで、MRTKを使うべきかというと、PoCならいざしらず、実利用のアプリケーション/スマートフォンとの連動性なども考えると、MRTKの導入は長期開発のリスクになると思います。 一方で、多様なデバイスにクイックに対応することが求めらるPoCなどでは積極的に採用することで、クロスプラットフォームで同一の操作体験を提供できることは大きなメリットであると考えます。 このようなケースでは、ロジック層をきちんと分離しておいて、将来的にMRTKの利用を取りやめられるように、設計段階で考慮しておくことがおすすめです。 ## そもそもコピペができないUnityはどうなのか？ 一方で、UIフレームワークとして考えた場合、そもそもゲームエンジンであるUnityを採用した時点で、オブジェクトや文字列のクリップボードへのコピー、右クリック（コンテキストメニュー）などのOSの基礎的な機能が使えなくなってしまい不便です。 Unity as a library (UaaL) などもあるのですが、気軽に、安心してクロスプラットフォームで使える状態ではありません。ゲーム系であれば、それで問題無いかもしれませんが、ビジネス系のツールアプリではこれが結構致命傷になったりします。 そう考えると、MRTKの導入をためらう程度に、ユーザーインターフェースにこだわりを持つのであれば、Unity Engineを利用せずに、KotlinやSwiftを利用したネイティブ言語での開発を検討した方が良いかもしれませんね。 - Introducing the Android XR SDK Developer Preview | Android XR - [https://developers.googleblog.com/en/introducing-android-xr-sdk-developer-preview/](https://developers.googleblog.com/en/introducing-android-xr-sdk-developer-preview/) - Meta Spatial SDK - [https://developers.meta.com/horizon/develop/spatial-sdk](https://developers.meta.com/horizon/develop/spatial-sdk) - vionOS Pathway - [https://developer.apple.com/jp/visionos/pathway/](https://developer.apple.com/jp/visionos/pathway/) ## 明日 明日は新規事業開発部 部長/執行役員の久保山さんが担当します。 お題は「空間コンピューティングとDX」の3日目です。