Google Health API は、ゼロから構築された包括的なソリューションであり、デベロッパーが同意済みのユーザーの健康に関するさまざまなデータと多様なデータ型に堅牢にアクセスできるようにします。Google Health API では、アプリの登録、Google OAuth 2.0、新しいデータ型、新しいエンドポイント スキーマ、新しいレスポンス形式に新しいコンソールが使用されます。
このガイドでは、既存の Fitbit Web API アプリを新しい Google Health API に移行する方法について説明します。ユーザーを維持しながらシームレスな移行を実現するための推奨事項が記載されています。
移行のメリット
これは単なるアップデートではなく、アプリのセキュリティを確保し、将来の医療技術の進歩に備えるための戦略的な動きです。Google Health API を使用するメリットは次のとおりです。
- 包括的なデータへのアクセス: 同意を得たユーザーの健康データやさまざまなデータ型に、強力にアクセスできます。
- セキュリティの強化: Google のセキュリティに関するベスト プラクティスに準拠し、Google のセキュリティ、プライバシー、ID の標準に沿っています。
- 一貫性: データ形式、タイムゾーン、測定単位、エラー処理における従来の不整合を解消し、より直感的なデベロッパー エクスペリエンスを実現します。
- スケーラビリティと将来性: 将来の需要に対応できるように設計されており、gRPC などの最新のプロトコルをサポートしています。
Fitbit Web API から Google Health API への移行には、技術的な変更以上のものが必要です。新しい OAuth ライブラリに切り替えたため、既存のアクセス トークンと更新トークンを転送できません。そのため、ユーザーは更新された統合に再度同意する必要があります。
両方のログイン方法をサポートする
Fitbit Web API と Google Health API ではユーザー ログインの処理に異なるシステムを使用するため、Fitbit Web API がまだ有効な間は、アプリで一時的に両方の方法を同時にサポートする必要があります。
アプリがデータを直接リクエストするのではなく、特定のユーザーに対して Fitbit Web API と Google Health API のどちらにアクセスするかを決定するレイヤを実装します。これにより、アプリの残りの部分で詳細を気にする必要がなくなります。
ユーザー データベースを更新して、どのログイン システムを使用しているかを識別するためのフラグ（oauth_type など）を含めます。
- 新規ユーザーの場合: 新しい Google Health API（
oauth_type: google）で自動的に設定されます。 - 既存のユーザーの場合: 同意（
oauth_type: fitbit）を更新するまで、Fitbit Web API を使用し続けます。
ユーザー エクスペリエンスを損なわないようにするため、すべてのユーザーにログアウトとログインを強制することはおすすめしません。この場合は次のように対応してください。
- Fitbit Web API に接続したままのユーザーがアプリを利用した場合は、接続の更新を促すわかりやすい通知を表示します。
- ユーザーが更新アクションを承認したら、すぐに Google Health ログインフローをトリガーします。
- Google ログインが成功したら、新しい Google 認証情報をユーザーのプロフィールに保存し、
oauth_typeフラグをfitbitからgoogleに切り替えます。設定で許可されている場合は、トークンを取り消すことで、古い Fitbit システムからプログラムでユーザーをログアウトさせ、整理された安全な状態を保ちます。
データの連続性を確保する
統合を以前の Fitbit Web API から Google Health API に移行する場合、デベロッパー アプリケーションはユーザー識別構造の変更を考慮する必要があります。
以前の Fitbit Web API では、6 文字の英数字文字列（A1B2C3 など）を使用してアカウントを識別しますが、Google Health API では、最大 63 桁の数字と文字の文字列としてフォーマットされた healthUserId を使用します。
ユーザー コンテキストを失うことなくこのギャップを埋めるために、デベロッパーは getIdentity エンドポイントにクエリを実行して Fitbit と Health のユーザー ID を取得できます。このエンドポイントは、legacyUserId と新しい healthUserId の両方を含むペイロードを返します。これにより、アプリケーションは既存のレコードと新しいアカウント システム間のマッピングを動的に作成できます。
過去のデータのバックフィル
ユーザーが以前のエンドポイントが停止される前に新しい Google Health API エンドポイントに対して認証を行わなかった場合、デバイスを Google Health アプリに同期し続ける限り、データは引き続き利用できます。ただし、このユーザーのデータにギャップが生じる可能性があります。
ユーザーが新しいエンドポイントに再認証すると、Google Health API を使用して過去のデータをバックフィルできます。ガイダンスについては、履歴データをクエリするをご覧ください。
コミュニケーションとタイミング
ユーザーが既存の Fitbit OAuth から新しい Google OAuth に移行できるようにするには、次のベスト プラクティスに沿って対応してください。
価値を優先したコミュニケーション
「API を更新しました」ではなく、Google ヘルスケアのデータをアプリに統合するメリットを最初に伝え、データを同期するには再認証が必要であることをユーザーに認識させます。
- 統合によって利用できるアプリの機能を明確に説明し、それらの機能からどのようなメリットが得られるかが伝わるようメッセージを工夫します。
- 技術的な実装の詳細ではなく、機能に焦点を当ててユースケースを提供します。
- 言わないでください: 「Fitbit API に接続できなくなります。」
- 推奨される表現: 「心拍数データを含む詳細なワークアウトを引き続き表示するには、Google Health API への再同意が必要です。」
ユーザーに通知するタイミング
ユーザーとのすべてのコミュニケーションで、Google Health のブランド ガイドラインに準拠し、非表示にできるバナー、カード、アラートを使用します。