LASSIC Media らしくメディア
Apple Watch/Wear OSコンパニオンアプリ開発を外注する進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Apple Watch（watchOS）とWear OSでは通信API・UI設計・ストア審査がまったく異なるため、開発経験者の見極めが重要です
- 2026年4月28日以降、App Store ConnectへのwatchOSアプリ提出にはwatchOS 26 SDK以降でのビルドが必須になりました
- 外注先の選定から要件定義・PoC・本開発・運用保守まで、5つのステップで進めることでリスクを抑えられます
目次
Apple Watch・Wear OSコンパニオンアプリ外注とは
ウェアラブル（Apple Watch/Wear OS）コンパニオンアプリ外注とは、既存のスマートフォンアプリに腕時計型デバイス対応を追加するために、watchOSまたはWear OS向けアプリの設計・開発・審査対応を外部パートナーに委託する取り組みです。
スマートフォンアプリと腕時計型アプリの関係は、大きく2つに分かれます。一方はコンパニオン型で、iPhoneまたはAndroidスマートフォンと常時通信しながら通知・操作・データ表示を担うタイプです。もう一方はスタンドアロン（独立）型で、スマートフォンがなくてもアプリが単独で動作します。
外注を検討する場合、最初にどちらのアーキテクチャを採用するかを決めることが、開発工数・技術スタック・費用のすべてに影響します。
| 比較項目 | Apple Watch（watchOS） | Wear OS（Android） |
|---|---|---|
| 主要言語・フレームワーク | Swift / SwiftUI | Kotlin / Jetpack Compose for Wear OS |
| スマホ連携API | Watch Connectivity フレームワーク | Data Layer API（Wearable Data Layer） |
| 最新SDK要件 | 2026年4月28日以降、watchOS 26 SDK以降でのビルドが必須*1 | Google Play services が管理。 定期的なTarget API Level更新が必要 |
| ストア審査 | App Store（Apple Review） | Google Play Store |
| iOS連携可否 | iPhoneとのペアが前提 | Data Layer APIはAndroid端末とのペアのみ対応。 iOSとの連携はクラウド経由が必要 |
watchOSアプリ開発の技術要件と外注時の確認事項
watchOSアプリ開発で外注先が習熟していなければならない技術の中心が、Watch Connectivityフレームワーク（Apple Developer Documentation）です。
Watch ConnectivityはiPhoneとApple Watchの双方向通信を担い、主に4つのAPIで構成されています。
- sendMessage：アプリがフォアグラウンドにある場合のリアルタイム通信。応答ハンドラーを設定できます。
- transferUserInfo：バックグラウンドでもキューイングされる非同期データ転送です。
- updateApplicationContext：最新の状態だけを保持するコンテキスト更新。過去の値は上書きされます。
- transferFile：画像・音声などファイル単位の転送に使います。
これらは用途によって使い分けが必要です。選択を誤るとバッテリー消費の増大やデータ欠損につながるため、外注先が各APIの特性を理解しているかを要件定義段階で確認してください。
watchOS 26 SDKビルド必須化（2026年4月28日以降）
Appleは2026年4月28日以降、App Store ConnectへのwatchOSアプリ提出にwatchOS 26 SDK以降（Xcode 26以降）でのビルドを必須としました*1。
既存アプリのアップデートも対象です。外注先が古いXcodeバージョンで開発を継続していると、審査提出時に却下される可能性があります。契約時に開発環境のバージョン管理方針を確認することが大切です。
バッテリー制約・コンプリケーション・常時表示
Apple Watchのバッテリー容量はiPhoneより大幅に小さいため、バックグラウンド処理は厳しく制限されています。外注先に対して、バックグラウンドリフレッシュのスケジュール設計やネットワーク通信の最小化の実績を確認してください。
コンプリケーション（ウォッチフェイスに表示されるデータウィジェット）や常時表示（Always-On）は、ユーザーの日常的な使用頻度に直結する機能です。これらの実装にはwatchKit・SwiftUIのウィジェット系APIへの習熟が必要です。
App Store審査の留意点
watchOSアプリはiOSアプリの審査と同時進行しますが、watchOS固有のHuman Interface Guidelinesへの準拠も審査されます。タップターゲットのサイズ・グランスビュー（ちら見え対応）・Digital Crownのインタラクションなど、スマートフォンとは異なるUXルールが存在します。
外注先にwatchOSのHIGレビュー経験があるかを選定の際に確認してください。
Wear OSアプリ開発の技術要件と外注時の確認事項
Wear OS向けアプリ開発では、Jetpack Compose for Wear OSがApple側のSwiftUIに相当するモダンなUIフレームワークです。スマートウォッチ向けに最適化されたTransformingLazyColumn・SwipeDismissableNavHostなどのコンポーネントを使いこなせるエンジニアが必要です。
スマートフォンとの通信にはData Layer API（Wearable Data Layer）を使います（Android Developers ドキュメント）。
Data Layer APIの特性と制約
Data Layer APIはBluetooth接続時は直接通信、Bluetooth圏外ではLTE/Wi-Fi経由のGoogle Cloudを介して通信します。転送されるデータはエンドツーエンドで暗号化されています。
重要な制約として、Data Layer APIはAndroid端末とWear OS端末のペアにのみ対応します。iPhoneとWear OS端末を組み合わせるユースケースでは、クラウドベースのAPI設計が別途必要になります。外注先がこの前提を把握していない場合、開発着手後に手戻りが発生します。
スタンドアロン vs コンパニオンの設計選択
Android Developersのドキュメント（Wear OS開発ガイド）では、アプリモデルを3つに分類しています。
- ハイブリッド（推奨）：コア機能はオフラインで動作し、接続時に拡張機能が有効になります。
- スタンドアロン：スマートフォンと完全に独立して動作します。
- 非スタンドアロン：コア機能にスマートフォン接続が必須です。
ハイブリッドモデルは実装コストが高くなりますが、ユーザー体験の連続性を保てます。外注先との要件定義でどのモデルを採用するかを決めることが費用と品質の両方に直結します。
タイル・コンプリケーションと消費電力
Wear OSでもタイル（ホーム画面のクイック情報ビュー）とコンプリケーション（ウォッチフェイスへのデータ表示）を実装できます。これらはアプリ本体とは別のAPI体系を使うため、開発工数の見積もり時に含まれているか確認してください。
外注先選定の3つの評価軸
ウェアラブルアプリの外注先を選ぶ際は、一般的なスマートフォンアプリ開発の実績とは別に確認すべき事項があります。以下の3つの評価軸で候補を絞ることを推奨します。
評価軸1：watchOS/Wear OSの納品実績（プラットフォーム経験）
「iOS開発実績あり」と「watchOS開発実績あり」は別物です。watchOS/Wear OS専任またはウェアラブル納品実績のある会社に絞り、RFP（提案依頼書）に具体的なwatchOS・Wear OSアプリの提出実績を問う質問を含めてください。
評価軸2：SwiftUI/Compose for Wear OSエンジニアの保有
watchOSアプリの現代的な開発はSwiftUIベースです。Wear OSアプリはJetpack Compose for Wear OSが標準です。UIKitのみ・古いWear OS APIのみ対応の会社では、保守性の低いコードが生まれるリスクがあります。
評価軸3：小画面UX設計とバッテリー最適化の知見
スマートウォッチの画面は直径38〜49mm前後と小さく、ユーザーの操作時間も数秒以内を想定したグランス設計が必要です。ハプティクス（触覚フィードバック）の効果的な活用やDark Mode対応なども含めたUX設計ができる会社かどうかを確認してください。
| 評価項目 | 確認方法 | 最低ライン |
|---|---|---|
| watchOS納品実績 | App Storeの公開アプリを提示してもらう | watchOS対応アプリが1件以上あること |
| Wear OS納品実績 | Google Play Storeの公開アプリを確認する | Wear OS対応アプリが1件以上あること |
| 使用フレームワーク | RFPで技術スタックを明示させる | SwiftUI / Compose for Wear OSを使用していること |
| SDK更新対応方針 | 年次のSDK対応計画を確認する | Appleの必須要件変更に追従できる体制があること |
| バッテリー最適化 | PoC段階で実機テストを実施する | バックグラウンドリフレッシュの設計方針を説明できること |
外注プロセス5ステップ：要件定義からリリースまで
ウェアラブルアプリの外注は、通常のスマートフォンアプリ外注より技術的な前提合意が多く必要です。以下の5ステップで進めることで手戻りを抑えられます。
ステップ1：要件定義（機能・プラットフォーム・アーキテクチャの確定）
まず「Apple Watchのみ」「Wear OSのみ」「両対応」のどれかを決めます。両対応は開発費が単純に2倍になるわけではありませんが、テストや審査対応の工数は増えます。
次に「コンパニオン型かスタンドアロン型か」を決めます。コンパニオン型はスマホアプリとの通信設計が複雑になりますが、既存アプリとのデータ共有がしやすいです。スタンドアロン型は単体完結の分、サーバーサイドとの直接通信設計が必要になります。
機能スコープについては、通知表示・コンプリケーション・ヘルスセンサーアクセス・操作コントロールなど、フェーズ1で提供する機能を絞ることを推奨します。ウェアラブル向けの過剰な機能実装はバッテリー消費増大と審査リジェクトのリスクを高めます。
ステップ2：RFP作成と技術審査
RFP（提案依頼書）には、使用するフレームワーク・対応するwatchOSおよびWear OSの最低バージョン・Watch ConnectivityまたはData Layer APIの使用API・バッテリー消費の設計方針を明記させる質問を含めてください。
技術審査ではコードサンプルまたは公開アプリの動作確認を行うことを推奨します。「watchOS開発経験あり」という記述だけでは実力の判断ができません。
ステップ3：PoC（概念実証）契約でリスクを先に潰す
本開発の前に短期PoC契約を結び、核心となる技術課題を先に検証することが得策です。たとえばWatch ConnectivityのsendMessageのレイテンシ確認・Wear OSのData Layer APIでのデータ同期精度・実機でのバッテリー消費測定などをPoCのスコープとします。
PoCで「この外注先では難しい」と判明した場合、本開発前に切り替えられます。PoC費用は本開発費用に比べて小さいため、この段階でのリスク検証は費用対効果が高いです。
ステップ4：本開発・ストア審査準備
本開発フェーズでは、少なくとも実機テストデバイスの確保とTestFlight（watchOS）またはGoogle Play内部テスト（Wear OS）を使ったベータ配信を経由してから審査提出します。
watchOS審査ではAppleのHuman Interface Guidelinesへの準拠が確認されます。タップターゲットの最小サイズ・Digital Crownの対応・通知の権限フローなど、スマートフォンとは異なるチェックポイントがあります。審査リジェクトへの対応は外注先のスコープに含めることを契約に明記してください。
ステップ5：運用保守体制の確立（SDK更新への追従）
AppleとGoogleは年次でOSとSDKを更新します。特にAppleは前述のとおり提出要件に最低SDKバージョンを設けており、対応が遅れるとアプリの提出自体ができなくなります。
外注先との保守契約にSDK更新対応・年次ビルド更新・継続的な実機テストを含めるかどうかを初期段階で合意しておくことが大切です。
内製兼務でよく起きる失敗と外注の優位点
「iOSエンジニアがいるからwatchOSも対応できるはず」という判断で内製を進めた場合、2つの失敗パターンが実務上よく見られます。
失敗1：iPhoneエンジニアがwatch対応を兼務→バッテリー最適化の見落とし
watchOSのバックグラウンド処理はiOSよりも厳格に制限されています。iOSの設計パターンをそのまま持ち込むと、バッテリー消費が著しく増大し、ユーザーレビューでの低評価につながります。
watchOS向けのバックグラウンドリフレッシュスケジューリング・Complications更新タイミング制御・Extended Runtime Sessions（Extended Runtimeセッション：心拍モニタリングなど特定ユースケースで長時間バックグラウンド動作を許可する仕組み）の設計は、watchOS専任経験がないと見落としが起きやすいポイントです。
失敗2：watchOS SDKバージョン対応遅れによるApp Store審査却下
2026年4月28日以降、watchOS 26 SDK以降でのビルドが必須となりました*1。内製チームがXcode更新・ビルド設定変更・依存ライブラリの互換性確認を後回しにしていると、アップデートの審査提出ができなくなります。
外注先との保守契約にこれらのSDK更新対応を含めることで、自社チームが対応コストを吸収しなくて済みます。
外注先に依頼することで得られる技術的メリット
ウェアラブル専門の外注先に依頼する場合、内製との差分は技術面以外にも及びます。実機テストデバイスの保有・App Store審査経験・年次SDK更新への追従体制は、外注先が既に持っている資産です。自社でゼロから構築する場合の初期投資と比較することが費用対効果の判断に役立ちます。
内製に必要なスキルセットを具体的に挙げると、Swift・SwiftUI・Watch Connectivity API・watchOS Human Interface Guidelines・Xcode年次更新対応・実機デバイス管理の合計6領域が必要です。Wear OS対応を加えると、Kotlin・Jetpack Compose for Wear OS・Data Layer APIが追加されます。
まとめ：外注判断の3つの軸
本稿では、Apple Watch（watchOS）とWear OS向けコンパニオンアプリ開発を外注する際の技術要件・外注先選定・進め方を整理しました。要点を3つに集約すると次のとおりです。
第一に、watchOSとWear OSは通信API・UIフレームワーク・ストア審査基準がそれぞれ異なるため、外注先にプラットフォーム固有の納品実績を確認することが欠かせません。第二に、2026年4月28日以降はwatchOS 26 SDK以降でのビルドが必須であり、外注先の開発環境管理方針を契約前に確認することが審査リジェクトを防ぐ実務上のポイントです。第三に、本開発の前にPoC契約でバッテリー消費・通信レイテンシを検証し、外注先の技術力を見極めてから本契約に進む進め方がリスクを抑えられます。
よくある質問
Apple WatchアプリとiOSアプリは別々に審査申請が必要ですか？
watchOSアプリはiOSアプリのターゲットとして同一のApp Store Connect提出に含まれます。ただし、審査基準はwatchOS固有のHuman Interface Guidelinesが適用されます。iOSアプリが審査を通過しても、watchOS部分の要件を満たしていない場合はwatchOS機能のみリジェクトされることがあります。
Wear OSのコンパニオンアプリはiPhoneユーザーでも使えますか？
Wear OSのData Layer APIはAndroid端末とのペアにのみ対応しています。iPhoneとWear OS端末を組み合わせるケースでは、クラウドAPIを経由した別設計が必要です。外注先にiOS連携を前提とする設計経験があるかを事前に確認することをお勧めします。
watchOS 26 SDK対応への切り替えはどのくらいの工数がかかりますか？
既存アプリの規模と使用しているサードパーティライブラリの互換性状況によって異なります。Xcode更新・ビルド設定変更・依存関係の互換性確認・実機テスト・審査再提出を含めると、小規模アプリでも数日から数週間のエンジニアリング工数が見込まれます。外注先との保守契約にSDK更新対応を含めることで、毎年の対応コストを事前に固定できます。
コンパニオンアプリとスタンドアロンアプリのどちらを選ぶべきですか？
既存のスマートフォンアプリとの密接なデータ連携が必要な場合はコンパニオン型が適しています。一方、時計単体でGPS・心拍センサーなどを使った独立したユースケースを提供したい場合はスタンドアロン型が向いています。Android Developersのドキュメントでは「ハイブリッド型（コア機能はオフラインで動作し、接続時に拡張機能が有効）」を推奨しています。どちらを選ぶかは要件定義の最初に決めることが開発工数と費用に直結します。
外注費用の目安を教えてください。
ウェアラブルアプリ開発の費用は、機能スコープ・プラットフォーム数（watchOSのみかWear OS両対応か）・コンパニオン型かスタンドアロン型かによって大きく異なります。一次資料による公表費用相場は現時点では存在しないため、具体的な数値は各外注先への個別見積もりをお勧めします。費用を正しく比較するには、機能要件・使用API・テスト範囲・審査対応の含否を揃えたRFPを複数社に送付することが有効です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Apple Inc.「Upcoming App Store Submission Requirements」（2026年）
