LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

スマートグラスのアプリ開発外注とは

スマートグラスのアプリ開発外注とは、製造・物流・医療・建設などの現場DXを目的として、スマートグラスやAR（拡張現実）対応ウェアラブルデバイス向けのアプリケーションを、専門ベンダーに委託して開発する取り組みです。

XR/ARアプリ開発と通常のモバイルアプリ開発の違い

通常のスマホアプリ開発と比較したとき、スマートグラス向けXR（クロスリアリティ）アプリ開発が異なる点は3つあります。

第一に、対応するデバイスとSDK（ソフトウェア開発キット）が複数に分散しています。Android・iOSの2択とは異なり、デバイスメーカーごとに専用SDKや制約が存在します。

第二に、UI（ユーザーインターフェース）の設計思想が根本的に違います。タッチ操作を前提としたモバイルUIは転用できず、視野内に重畳する空間UI・ジェスチャー・音声入力を前提とした再設計が必要です。

第三に、実機検証の難易度が高い点が挙げられます。デバイスごとに光学系・センサー・発熱特性が異なるため、シミュレータだけでは再現できない問題が実機テストで初めて露見します。

製造・物流・医療で広がる外注ニーズの背景

スマートグラスの産業利用は、遠隔作業支援・AR作業指示・手術ナビゲーションなど現場DXの文脈で広がっています。経済産業省「2024年版ものづくり白書」でも、製造業の現場でのデジタル技術活用が重要課題として取り上げられています^*1。

一方、スマートグラス対応の開発経験を社内に持つ企業は少数です。XRエンジニアの採用難と技術の専門性の高さから、経験のある外注先への委託が現実的な選択肢となっています。

対応プラットフォームと開発フレームワーク — デバイスごとに異なる選択肢

代表的なスマートグラスデバイスと開発SDK

スマートグラスの産業用途では、デバイスカテゴリと用途によって選択肢が異なります。以下に代表的なデバイスと開発環境の特徴を示します。

いずれの場合も、発注前にターゲットデバイスを確定させ、そのSDKや開発環境での実装経験が外注先にあるかを確認する必要があります。

OpenXR・Unity XR・ARCoreで変わる実装コストと移植性

開発フレームワークの選択は、将来の移植性とコストに直結します。Khronos Groupが策定したOpenXR（オープンXR・複数デバイスに対応するクロスプラットフォームAPI規格）は、Meta・Microsoft・HTCなど主要ベンダーが採用しており、クロスデバイス対応を意識する場合に有力な選択肢です^*2。

Unity XR Interaction Toolkitは、OpenXRをベースにインタラクション設計を効率化するフレームワークです。3Dコンテンツの実装経験があるエンジニアに親和性が高く、PoC段階の素早い試作に向いています。

一方、ARCore（Google提供のARプラットフォーム）はAndroidデバイス向けで、平面認識・光推定・トラッキングなどの機能が標準化されています。Android系産業グラスとの親和性が高い反面、iOS・スタンドアロンMRデバイスには直接適用できません。

外注先に「どのフレームワークで開発するか」「特定デバイスのみか複数対応か」を発注前に合意しておくことで、後工程での移植対応コストを管理できます。

ハンズフリー・視野・音声 — UI/UX設計3つの特殊性

空間UIとタッチUIの根本的な違い

スマートグラス向けUIは、スマートフォンのタッチUI設計をそのまま流用できません。手が塞がった状態（ハンズフリー）での操作が前提となるため、主な入力手段はジェスチャー認識・視線追跡・音声コマンドに限られます。

操作の精度と認知負荷の観点から、次の3点が設計時の主要課題です。

• 誤操作リスク：グローブ装着・手の汚れなどの現場環境でジェスチャーが誤認識されると、作業中断・危険操作につながります。
• 認知負荷の集中：画面を凝視する必要があるUIは、現場作業の集中を妨げます。視線に追従するUI要素は最小限に抑える設計が求められます。
• フィードバックの限界：バイブレーションや大きな音が使えない環境では、完了・エラーの通知を視覚と音声の組み合わせで設計する必要があります。

外注先のUXデザイナーがスマートグラスの現場利用を想定した設計経験を持つかどうかは、プロトタイプ品質に大きく影響します。

視野角・輝度・文字サイズが制約するUI設計

スマートグラスのディスプレイは、スマートフォンとは根本的に異なる光学制約があります。

視野角（FOV）は機種によって水平30〜50度程度のものが多く、スマートフォンの画面全体に情報を広げる設計は転用できません。表示できる情報量を絞り込み、重要度に応じた階層化が必要です。

屋外や工場照明下での視認性確保のため、輝度・コントラストの最適化も設計工程に含まれます。ARオーバーレイは背景の明るさに影響を受けるため、環境光の変化を想定したテストが欠かせません。

文字サイズは視野内の相対位置と焦点距離によって決まります。「スマホで見やすいサイズ」をそのまま使うとグラス上では小さすぎたり、逆に視野を占有しすぎたりします。実機での視認性テストなしに確定することはできません。

発熱・バッテリー・プロセッサ — ハードウェア制約が実装を左右する

スマートグラスが抱える3つのハードウェア制約

スマートグラスはコンパクトな筐体に多数のセンサーとプロセッサを搭載しているため、発熱・バッテリー・処理能力の3点が実装上の制約となります。

発熱：AR処理・カメラ処理・通信を同時に動かすと筐体温度が上昇します。長時間の連続使用を前提とする現場用途では、処理の軽量化・間引き処理・冷却設計を意識した実装が求められます。発熱による強制シャットダウンは現場作業を中断させる重大障害です。

バッテリー：産業グラスでも連続動作時間は数時間が限度です。常時カメラ稼働・常時通信を行うアーキテクチャは電力消費が大きく、バックグラウンド処理の設計を誤ると業務時間中にバッテリーが尽きます。

プロセッサ制限：スマートグラスのSoC（システムオンチップ）はスマートフォンのミドルレンジ相当か、それ以下のケースもあります。重いAI処理・高解像度レンダリングをデバイス単体に持たせる設計は動作しない可能性があります。

実機環境なしに品質保証できない3つの理由

スマートグラス開発での実機検証が不可欠な理由は、シミュレータでは再現できない問題が実機テストで露見するためです。

第一に、光学系の問題はシミュレータで確認できません。AR重畳のズレ・輝度・視野端の歪みは実デバイスでしか評価できません。

第二に、センサーとカメラの精度は個体差・環境依存があります。工場照明・屋外日光・暗所などの実環境でのトラッキング精度は、シミュレータ上の挙動と乖離します。

第三に、発熱・バッテリー消費は実機長時間稼働テストでしか計測できません。開発中は断続的な動作テストが中心となるため、連続運用での問題が出荷直前まで発見されないリスクがあります。

実機検証の体制（デバイス調達・テスト工程・検証担当者）を外注先との間で合意してから発注することが、品質リスク管理の基本となります。

PoC→量産フェーズの進め方と発注分割の考え方

PoC期間の目安とスコープ設定

スマートグラスアプリ開発においてPoC（概念実証）は、技術的実現可能性と現場適合性の両方を確認する重要工程です。先端ニッチ分野ゆえ、量産発注前にPoCを行うことは業界的にも標準的な進め方です。

PoCのスコープは「ターゲットデバイスで最も難易度の高い機能1〜2点を動かし、現場作業者が実際に評価できる状態にする」ことを目標にします。全機能の実装を目指すと期間が延び、方向転換の判断が遅れます。

PoCにかかる期間は開発規模・デバイス・機能の複雑さによって異なりますが、「デバイス調達・環境構築・試作・現場評価」を含めると、一般的なモバイルアプリのPoC以上のリードタイムを見込む必要があります。一次資料による具体的な期間数値は確認できないため、外注先との見積もり段階で確認してください（費用同様、市場参考値です）。

量産移行可否の3つの判断軸

PoCから量産フェーズへの移行を判断する際の主要な軸は次の3点です。

• 現場評価の合格：実際の業務環境で現場作業者がスムーズに使えるか。誤操作・視認性・体への負担が現場基準を満たしているか。
• 技術的実現可能性の確認：発熱・バッテリー・処理速度がターゲットデバイスで要件内に収まるか。PoC段階での限界値を把握できているか。
• スケーラビリティの見通し：バックエンド連携・ユーザー管理・端末管理（MDM）など量産に必要な仕組みをPoC外注先が設計できるか。

PoCと量産開発を別の外注先に切り替える場合は、技術引き継ぎコストが発生します。継続性を重視する場合は、PoC段階から量産まで一貫して対応できる外注先を選ぶことが、追加コストと品質リスクを抑えるうえで有利です。

発注の分割と契約形態の選択

スマートグラスアプリ開発では、要件の不確実性が高いためPoC段階は準委任契約（作業範囲・工数単位の委託）が適しています。本開発フェーズでは機能ごとのマイルストーンを設けた請負契約に切り替え、納品物と検収基準を明確にする進め方が一般的です。

PoC・本開発・運用保守を1社に一気通貫で発注することで、技術継続性は確保できます。一方、特定工程の品質に懸念がある場合はフェーズごとに外注先を評価しながら進める選択肢もあります。

外注先選定の3軸 — 実績・スキルセット・費用の考え方

実績確認の3点セット：デバイス・SDK・産業用途

スマートグラスアプリ開発の外注先を選定する際、最低限確認すべき実績は次の3点です。

①対象デバイスへの実装経験：採用予定デバイスと同等または類似の機種での開発・納品実績があるか。デモ機・サンプルアプリ・ドキュメントで確認します。

②採用SDKの開発経験：OpenXR・Unity XR・ARCore・メーカー固有SDKのうち、必要なSDKでの実装経験が確認できるか。GitHubリポジトリや技術ブログ等も参考になります。

③産業用途または現場向けの開発経験：コンシューマーゲームや一般ARアプリではなく、製造・物流・医療・建設など現場で使うアプリの開発経験があるか。現場環境テストの方法論を持っているかも確認します。

上記の実績が確認できない外注先への発注は、開発遅延・手戻りリスクが高まります。特にスマートグラスは実機が高価で評価に時間がかかるため、実績のない外注先では学習コストが発注者に転嫁されます。

LASSIC社内でのスマートグラスアプリ外注支援の実績も踏まえ、要件整理からご支援します。

必要スキルセットと内製の難しさ

スマートグラスアプリ開発を内製で行う場合、以下のスキルを持つ人材を複数確保する必要があります。

• XR/ARエンジニアリング（Unity XR・OpenXR・ARCore等）
• 空間UI/UXデザイン（ハンズフリー・視野制約・音声対応）
• Android/各デバイスネイティブ開発
• バックエンド連携・API設計
• 現場環境テスト・ハードウェア特性の理解

これだけのスキルを持つ人材を国内で採用するには、相応のリードタイムとコストが必要です。専門性の高さと採用難易度から、外注を選択するケースが多いのが実情です。

費用の考え方と市場参考レンジ

スマートグラスアプリの開発費用は、開発規模・デバイス数・機能複雑度・PoC有無によって大きく異なります。以下は市場参考値であり、一次資料に基づく確定数値ではありません。発注時は複数社から見積もりを取って検証してください。

費用を抑えるポイントとして、PoC段階で機能スコープを最小化すること、既存ARフレームワークの標準機能を積極活用してフルスクラッチ実装を避けることが挙げられます。

まとめ — スマートグラスアプリ外注の3つの判断軸

本稿では、スマートグラス・XRアプリ開発を外注する際に押さえるべき要点を整理しました。要点を3つに集約します。

第一に、プラットフォームと開発環境の確認です。デバイスごとにSDKや制約が異なるため、採用予定デバイスで実装経験を持つ外注先かどうかが選定の出発点になります。OpenXRやUnity XRなどフレームワーク選択も移植コストに影響します。

第二に、ハンズフリーUI設計とハードウェア制約への対応力です。空間UI設計・音声入力・視野制約はモバイルUIのノウハウでは対応できません。発熱・バッテリー・プロセッサ制限への対処も実機検証を含む専門知識が必要です。

第三に、PoCを起点とした段階的な発注です。先端ニッチゆえ要件の不確実性が高く、いきなり量産発注するリスクは高い分野です。PoC段階から実績・スキルを確認した外注先と進め、現場評価を経てから量産移行を判断する進め方が失敗リスクを下げます。

よくある質問

スマートグラスのアプリ開発は、通常のスマホアプリ開発の外注先に依頼できますか？

対応可能なケースもありますが、慎重な確認が必要です。スマートグラス向け開発にはOpenXR・Unity XR・ARCoreなどXR専用フレームワークへの理解と、ハンズフリーUI設計・実機検証の体制が求められます。通常のAndroid/iOS開発実績のみで対応できる範囲は限られますので、採用予定デバイスでの実装実績を事前に確認してください。

スマートグラスのアプリ開発でPoCを行う必要はありますか？

先端ニッチ分野ゆえ、PoC（概念実証）は強く推奨します。デバイスごとのハードウェア制約・光学系の制限・現場環境でのUI適合性は、設計段階では予測しきれない問題が実機テストで初めて露見します。いきなり量産規模で発注すると、手戻りコストがPoC費用を大きく上回るリスクがあります。主要機能1〜2点に絞ったスモールスタートが現実的な進め方です。

複数のスマートグラスデバイスに対応したアプリを外注する場合、費用は何倍にもなりますか？

デバイス追加ごとに一定のコストは増加します。OpenXRなどのクロスプラットフォームフレームワークを採用すると、共通実装部分の再利用で追加コストを抑えられます。一方、デバイスごとの光学系・入力方式・SDK制約に対応したカスタマイズと個別の実機検証は発生するため、「クロスプラットフォームだからほぼ0コスト」という期待は現実的ではありません。発注前に外注先から複数デバイス対応時の見積もりを出してもらい、費用対効果を比較してください。

スマートグラスアプリの運用・保守を外注する際に特有の注意点はありますか？

デバイスOS・SDKのバージョンアップ対応が定期的に必要になる点が主な注意点です。スマートグラスメーカーはアップデートサイクルが不規則なケースもあり、更新のたびにアプリ動作確認と修正対応が発生します。また、デバイスが製造終了になった場合の後継機対応も考慮が必要です。保守契約の範囲にSDK・OS更新対応を明示的に含めるよう、発注時に契約書で確認してください。

スマートグラスアプリ外注の発注失敗を防ぐうえで、最初に確認すべきことは何ですか？

外注先が「採用予定デバイスでの実装実績」を持つかどうかが最初の確認事項です。次に、現場環境での実機テスト体制を持っているか確認します。スマートグラス開発の失敗パターンとして多いのは、実機検証が不十分なまま量産フェーズに進んだケースです。デモ機・参考実装・テスト手順書の提示を求めることで、外注先の実力を事前に見極めることができます。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：経済産業省「2024年版ものづくり白書（ものづくり基盤技術振興基本法第8条に基づく年次報告）」（2024年）
2. *2　出典：Khronos Group「OpenXR Overview」（参照2024年）