LASSIC Media らしくメディア

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

HealthKit・Health Connectとは — ヘルスケア連携の2大プラットフォーム

アプリのヘルスケア連携（HealthKit・Health Connect）とは、iOS/Androidが公式に提供する健康データ管理フレームワークを通じて、歩数・心拍数・睡眠・ワークアウトなどのデータをアプリと連携させる実装形態を指します。ウェアラブルデバイスや標準ヘルスアプリに蓄積されたデータを、開発したアプリから許諾ベースで読み書きできるようにする機能です。

フィットネスアプリや健康管理サービスにとって、このデータ連携はサービスの中核機能となります。ただし、健康・医療データという機微情報を扱うため、通常のアプリ機能よりも厳格なプライバシー要件・審査基準が課されます。

iOSはHealthKit——歩数・心拍・睡眠を許諾ベースで管理

HealthKitは、AppleがiOS・iPadOS・Apple Watch・Apple Vision Proに提供する、健康・フィットネスデータの統一管理フレームワークです^*1。iPhone内の「ヘルスケア」アプリを中央リポジトリとして、各サードパーティアプリが許諾を得てデータを読み書きできる設計になっています。

扱えるデータ種別は多岐にわたります。日常活動では歩数・移動距離・階段上り・アクティブカロリー、心臓系では心拍数・心拍変動・血圧、睡眠段階（コア・深い・REM・覚醒）、ワークアウト種別と消費カロリーなどに加え、体重・BMI・血糖値などのバイタルサインも含まれます。

プライバシー設計において、HealthKitはユーザーの許諾を項目ごとに取得する仕組みです。アプリがデータにアクセスするには、Info.plistに「NSHealthShareUsageDescription」（読み取り目的）と「NSHealthUpdateUsageDescription」（書き込み目的）を設定し、ユーザーに用途を説明する必要があります。ユーザーは項目単位で「許可しない」を選択できるため、アプリ側は部分的な許諾を前提としたUX設計が欠かせません。

AndroidはHealth Connect——Google Fitの後継として2026年末に移行

Health ConnectはGoogleがAndroid向けに提供する健康・フィットネスデータ管理プラットフォームです^*2。Android SDK 28（Android 9 Pie）以上で動作し、複数のヘルスケアアプリが収集したデータをデバイス内で一元管理・共有できます。

対応データは歩数・心拍数（リアルタイム計測）・睡眠データ（セッション形式）・皮膚温度・マインドフルネス・運動ルート（GPS追跡）など幅広くあります。また、FHIR（Fast Healthcare Interoperability Resources）形式の医療記録にも対応しており、医療連携が必要なアプリにも使用できます。バックグラウンド読み取りをサポートしており、アプリが非アクティブな状態でも継続的にデータを取得できる点はウェアラブル連携で実用的な機能です。

Google Fit API（Androidの旧健康データAPI）は、2026年末をもってサポートが終了します^*2。Googleは新規アプリのヘルスケア連携においてHealth Connectへの統合を推奨しており、既存のGoogle Fit API利用アプリにも移行を促しています。なお、Google Fit APIからHealth Connectへの移行にはRecording API・History API・Sensor APIそれぞれで異なる対応が必要で、APIによっては代替手段がないものもあるため、早期の対応計画が大切です。

実装前に押さえるべき審査・プライバシー要件

HealthKit・Health Connectを使ったアプリは、App Store・Google Playの健康データポリシーによる厳格な審査の対象になります。通常の機能実装と同じ感覚で進めると、審査リジェクトという形で開発が止まります。実装前にプライバシー要件と審査基準を把握しておくことが、プロジェクト全体のリスク管理になります。

App Store審査ガイドライン5.1.3——広告利用禁止・医療アプリは法人申請

AppleはApp Store審査ガイドライン5.1.3において、HealthKitデータの用途を厳しく制限しています^*1。HealthKitから取得したデータを広告・マーケティング目的、または利用状況ベースのデータマイニングに使用することは明確に禁止されています。HealthKitデータを第三者へ提供することも、ユーザーが直接的な利益（例：保険料割引）を得る場合など限定的な例外を除いて禁止です。

医療判断に関わるアプリ（血圧測定・血糖値測定・X線撮影などをデバイスセンサーのみで行うと主張するもの）は、精度の検証データ提出と、医師への相談をユーザーに促す文言が必要です。また、HealthKitを活用した臨床研究アプリは法人申請が必須となり、IRB（倫理審査委員会）の承認書の提出が求められます。

開発側の実装として最低限必要なのは、①Info.plistへの利用目的記述、②ユーザー同意取得フローの実装、③プライバシーポリシーへの収集データ明記の3点です。これらが欠けていると審査段階でリジェクトされます。

Google Play健康データポリシー——ユーザー同意フローとデータ使用宣言

Google PlayもHealth Connectデータに関するポリシーを設けています。アプリがHealth Connectへのアクセス権限を要求する場合、Googleのデータセーフティフォームでの申告と、用途制限ポリシーへの準拠が必要です。

ユーザー同意の取得フローも重要で、どの健康データに、どの目的でアクセスするかを明示したうえで、ユーザーが個別に許可・拒否を選択できる画面の実装が求められます。Health Connect APIを使用するアプリはGoogleによる審査プロセスを経る必要があり、申請時に利用目的・データ保管方針・第三者共有の有無などを詳細に説明する書類提出が発生します。

ヘルスケア連携の実装で起きやすい3つの失敗パターン

HealthKit・Health Connectの実装では、通常のアプリ開発では起きにくい固有の失敗パターンがあります。実際の開発プロセスで起きやすい3つのケースを整理します。

失敗1: パーミッション設計ミスでリジェクト——許諾粒度を誤ると審査通過不可

HealthKit・Health Connectでは、ユーザーが特定のデータ項目の許諾を拒否した場合でも、アプリが正常に動作し続ける設計が必要です。「心拍数の許諾を拒否されたら起動できない」という実装は、Appleの審査基準を満たさないため、リジェクト対象になります。

実装上の注意点として、HealthKitのAPIはユーザーが特定の健康データへのアクセスを拒否したかどうかをアプリに通知しない仕様です。許諾が得られなかった場合、データの読み取りは「データなし」として返ってくる動作になります。この仕様を理解しないまま実装すると、「データが取れない＝エラー」として扱ってしまい、意図しない挙動につながります。

「必要最小限の権限要求」と「許諾の有無に関わらず機能する実装」は、審査通過の基本条件です。設計フェーズでユースケースごとに必要な権限を精査し、どの権限がなくても動作する最低限の動作仕様を定義することが欠かせません。

失敗2: バックグラウンド更新の実装漏れ——ウォッチ連携で致命的なデータ欠損

Apple WatchやWear OSデバイスと連携するアプリでは、アプリがフォアグラウンドにない状態でも健康データを収集し続けることが求められます。この「バックグラウンド更新」の実装を後回しにすると、ウォッチで計測したデータがアプリに同期されない、というユーザー体験の重大な問題が発生します。

HealthKitではバックグラウンド配信（Background Delivery）の設定が必要で、特定のデータタイプに変更があった際にバックグラウンドでアプリを起動させる仕組みです。一方、Health ConnectのバックグラウンドReadはAndroid 13以降で利用可能で、適切なパーミッション宣言が必要です。バックグラウンド更新はバッテリー消費にも影響するため、更新頻度の設計もユーザー体験に直結します。

失敗3: Google Fit APIを前提にしたまま開発——2026年末廃止で作り直しリスク

Androidのヘルスケア連携について、既存の技術情報や古い参考コードにはGoogle Fit APIを使ったサンプルが多く残っています。新規開発でGoogle Fit APIを採用すると、2026年末のサポート終了後に大規模な作り直しが発生するリスクがあります。

Googleは公式に、新規アプリへのHealth Connect統合を推奨しています^*2。Google Fit APIからHealth Connectへの移行は、APIによって対応手順が異なります。Recording API（ステップ記録）・History API（データ読み書き）・Sensor API（リアルタイムデータ）それぞれに異なる移行先があり、Goals APIについては代替APIが提供されていません。現時点でGoogle Fit APIに依存した設計を選択することは、技術的負債を意図的に積み上げることになります。

外注発注の5ステップ——仕様確定からリリース審査対応まで

ヘルスケア連携の実装を外注する場合、通常のアプリ開発外注と異なる点があります。プライバシー設計・審査対応という専門性が要求されるため、発注側が要件を明確に定義し、外注先の経験を確認したうえで進めることが大切です。

ステップ1: データ種別と許諾フローをRFPに明記

ヘルスケア連携の外注では、RFP（提案依頼書）に必要なデータ種別を具体的に列挙することが出発点です。「ヘルスケアデータを使いたい」という要件では、外注先は範囲を判断できません。「歩数（HealthQuantityType.stepCount）・心拍数（heartRate）・睡眠段階（sleepAnalysis）を読み取る」という粒度で記載します。

同時に、ユーザーへの許諾フローのUX仕様も発注仕様に含めます。どのタイミングで許諾を求めるか（初回起動時 vs 機能使用時）、拒否された場合のフォールバック動作はどうするか、という設計を発注側が主導することで、後工程での手戻りを減らせます。

ステップ2: パートナー選定——HealthKit/Health Connect実績を確認

外注先の選定では、HealthKit・Health Connectの実装実績を具体的に確認します。「iOSアプリ開発の経験がある」という条件だけでは不十分で、審査ガイドライン5.1.3に準拠した実装・リリース経験があるかを確認することが大切です。

確認すべき具体的なポイントは、①過去にHealthKit/Health Connect連携でリリースしたアプリの数と種別、②审査リジェクト経験とその解決実績、③プライバシーレビュープロセスの有無、の3点です。医療・ウェルネスアプリ専門の開発会社でなくても、モバイルアプリ専門の外注先でこれらの実績があるかを見極めます。

ステップ3: 設計・開発——プライバシーレビューを並走

設計フェーズでは、プライバシーバイデザイン（Privacy-by-Design）の観点から健康データの取得・保管・廃棄のフローを文書化します。この文書はApp Store・Google Playの審査でも参照されることがあるため、後工程で流用できる形で残しておくことが実用的です。

開発中はHealthKitのシミュレーターツールやHealth Connectのテストデータ挿入機能を使って、各データタイプの読み書きを結合テストします。本番の健康データを開発環境で使用することはプライバシー上問題があるため、テスト用のダミーデータを用意したうえでの検証が標準的な進め方です。

ステップ4: テスト——ヘルスデータの読み書き結合テスト

テストフェーズでは、ヘルスケア連携に固有のシナリオを追加します。具体的には、①全権限を許可した場合、②一部権限のみ許可した場合、③全権限を拒否した場合、のそれぞれでアプリが正常に動作するかを確認します。

Apple Watchや実機のウェアラブルとの連携が要件に含まれる場合、シミュレーターでは再現できない部分があるため、実機テストの工数を計画に含める必要があります。バックグラウンド更新の動作確認も実機でのみ検証できる項目です。このテスト工数を見落として、リリース直前に問題が発覚するケースは珍しくありません。

ステップ5: リリース審査——審査ノート（App Review Notes）の作成

App Storeへの申請では、審査チーム向けのApp Review Notesに「なぜHealthKitデータが必要か」「データをどのように使用するか」「広告・データマイニングには使用しないこと」を明記します。HealthKit利用のリジェクト理由として多いのは、データ利用目的の説明不足です。

Google Playでも同様に、Health Connect使用に関するデータセーフティセクションの申告と、利用目的説明文書の整備が必要です。外注先がこれらの審査書類作成経験を持っているかを事前に確認しておくと、審査期間の遅延リスクを下げられます。

内製vs外注の判断軸と必要スキル

ヘルスケア連携を内製で行うには、複数の専門領域にわたる知識が必要です。HealthKit APIおよびHealth Connect APIの実装スキルに加えて、各プラットフォームのプライバシーポリシー・審査ガイドラインの継続的な理解、医療・健康データの法的取り扱い（個人情報保護法・厚生労働省の医療情報管理ガイドライン）への対応が求められます。

さらに、バックグラウンド更新・ウェアラブル連携・FHIR対応まで範囲が広がると、iOSとAndroidの両プラットフォームでこれらを内製できる体制を整えるのは、専門チームを持たない企業には難しい状況です。

外注を選択する主なメリットは3点です。第一に、審査ノウハウの活用——HealthKit/Health Connect連携の審査リジェクト経験を持つ外注先であれば、よくある落とし穴を事前に回避できます。第二に、API変更への対応——Health Connect Jetpack Libraryのアップデートや、AppleのHealthKit APIの変更への追従コストを外注先が担います。第三に、プライバシーレビューの並走——実装と同時にプライバシー観点のレビューを行う体制を持つ外注先であれば、リリース後のリスクを下げられます。

一方、内製を選ぶべき場合もあります。ヘルスケアアプリがコアビジネスであり、長期的にAPIを継続的に進化させる必要がある場合、外注依存より内製チームの育成が事業上合理的です。この場合でも、初回の実装は経験ある外注先と協働して知見を移転するアプローチが現実的です。

まとめ——ヘルスケア連携外注の3つの判断軸

本稿では、HealthKit（iOS）・Health Connect（Android）を使ったアプリのヘルスケア連携実装と外注の進め方を整理しました。要点を3点に集約すると次の通りです。

第一に、プラットフォームの違いと最新状況の把握が出発点です。iOSはHealthKit、AndroidはHealth Connect（Google Fitの後継）という2本立てで、それぞれ異なるAPIと審査要件を持ちます。AndroidでGoogle Fit APIへの依存が残っている場合、2026年末のサポート終了に向けた移行計画を早期に立てることが大切です。

第二に、プライバシー設計と審査対応は開発の最初から組み込む必要があります。App Store審査ガイドライン5.1.3やGoogle Playの健康データポリシーを後付けで対応しようとすると、リリース直前のリジェクトというリスクが生じます。RFPの段階からプライバシー要件を明記し、設計・開発・テスト・審査の全フェーズで対応することが、プロジェクト全体のリスク管理につながります。

第三に、外注先の選定は「ヘルスケア連携の審査通過実績」を軸にします。通常のモバイルアプリ開発スキルと、HealthKit/Health Connectの審査対応経験は別物です。過去の実績・リジェクト解決実績・プライバシーレビュープロセスの有無を具体的に確認したうえで外注先を選ぶことが、プロジェクト成功の鍵になります。

よくある質問

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

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

1. *1　出典：Apple「HealthKit – Apple Developer」（参照2026年6月）
2. *2　出典：Google「Health Connect overview – Android Developers」（参照2026年6月）

Tweet