FitbitがGoogleに買収され、開発者向けプラットフォームがGoogle Health APIへ移行したことで、多くの個人開発者やヘルスケア愛好家が困惑しています。かつてのFitbit開発者ポータルは、数ステップで認証情報を発行し、自分の活動データを手軽に取得できる直感的な仕組みでした。しかし現在のGoogle Cloud Console（GCP）に統合された設定画面は、個人のデータ取得を拒絶するかのような難解さと複雑さに満ちています。単に自分の健康ログを扱いたいだけの一般ユーザーに対し、巨大なエンタープライズ向け開発基盤の作法をそのまま押しつける設計は、UIおよびUXの観点から大きな疑問を残しています。

個人を締め出すGoogle Cloud Consoleの迷宮

従来のFitbit開発ポータルでは、アカウントを作成してアプリケーションを登録すれば、即座にクライアントIDとシークレットを取得できました。対して現在のGoogle Health APIは、Google Cloud Platformの複雑な階層構造の中に完全に組み込まれています。

個人が自分自身のデータを可視化したいだけの場合であっても、まずプロジェクトを立ち上げ、無数のAPI一覧から該当のものを探し出して有効化しなければなりません。さらにOAuth同意画面の構築では、厳密なスコープ設定や連絡先情報の入力を求められ、公開ステータスがテスト中であれば自分のアカウントをわざわざテストユーザーとして個別に登録する作業まで発生します。リダイレクトURIや認証エンドポイントといったWeb開発の前提知識を持たないユーザーは、最初のエラー画面で完全に足止めを食らうことになります。

この設計がもたらす最大の問題は、一般ユーザーの手軽なデータ利活用を著しく阻害している点にあります。企業の大規模な商用サービスを開発するのと同等のセキュリティ手続きを、個人の趣味的なスクリプト作成にまで無差別に適用した結果、一般の愛好家が自力でデータに触れる自由が奪われています。

迷走するヘルスケア基盤：Google Fit、Fitbit、Health Connectの違い

設定の難解さに拍車をかけているのが、Googleのヘルスケア関連サービスが幾重にも重複している現状です。Google Fit、Fitbit、Google Health、そしてHealth Connectという似たような名称が乱立し、どの基盤が何を担当しているのかが外部から極めて見えにくくなっています。

この構造を理解するには、データの保管場所と提供フェーズを整理する必要があります。

• Google Fit（旧世代）：2014年から提供されていた従来のクラウドサービスですが、現在は段階的に廃止が進められています。従来のGoogle Fit REST APIもすでに役目を終えつつあります。
• Fitbit / Google Health（現行のクラウド主軸）：現在のGoogleにおけるヘルスケアの中核です。Pixel WatchやFitbitデバイスで計測された睡眠ステージや心拍変動、ストレス値などの高精度なデータは、このクラウドに集約されます。外部プログラムからWeb経由で直接アクセスする場合、今回問題視されているGoogle Health APIと向き合うことになります。
• Health Connect（端末内ローカル中継ハブ）：クラウドではなく、Android端末の内部で動作するOS標準のデータ共有機能です。Fitbitアプリ、体重計アプリ、サードパーティ製フィットネスアプリなどが、端末のローカル環境で相互に歩数や睡眠データをやり取りするために用いられます。

Google Fitの終了に伴い、クラウド上のデータを外部スクリプト等で継続的に吸い上げるためには、Fitbit基盤を引き継いだGoogle Health APIへの移行が避けられなくなりました。しかし、新旧の仕様変更に関する公式ドキュメントやネット上の解説記事は錯綜しており、開発者が正しい道筋を見つけ出すこと自体が困難な状況を生み出しています。

官僚主義とベンチャー気質の悪魔合体

なぜGoogleのAPIはこれほどまでに使いづらく、頻繁な仕様変更と廃止を繰り返すのでしょうか。その背景には、組織構造と評価制度の歪みがあります。

シリコンバレーの技術界隈では長年、GoogleのLaunch and Abandon（作って立ち上げ、放置する）と呼ばれる体質が指摘されてきました。社内の評価制度において、既存プラットフォームの地道な保守やドキュメントの改善よりも、新しいプロダクトを立ち上げた実績のほうが昇進において圧倒的に高く評価される傾向があるためです。結果として、エンジニアは新サービスを競って立ち上げ、昇進を果たすとプロジェクトを離れます。残された旧基盤はメンテナンスされないまま放置され、後任が刷新と銘打って別の新規格を作り、古いものが切り捨てられるという悪循環が常態化しています。

この体質は、MicrosoftやAmazon Web Services（AWS）の姿勢とは対照的です。Microsoftは長年にわたり過去のバイナリや後方互換性を死守することに心血を注ぎ、AWSは一度一般提供したサービスを原則として廃止しません。一方でGoogleは、自社が新しい設計を打ち出せば、外部の開発者が追従してコードを書き換えるのは当然であるという思想に傾きがちです。

その結果として立ち現れるのが、ベンチャーの無責任さと役所の融通の利かなさを煮詰めたような構造です。アジャイルや革新を掲げて未完成な仕様変更を乱発し、数年でサービスを打ち切る無責任さを持つ一方で、利用手続きには巨大官僚機構さながらの厳格な階層権限管理や電子手続きを強要してきます。利用者に役所のような煩雑な書類仕事を強いておきながら、ベンチャーのノリで数年後に窓口を閉鎖するような不条理が、現在の開発体験に直結しています。

生涯のログを実験場にするな：健康データと社風の致命的な不整合

検索履歴や動画の視聴履歴と異なり、ヘルスケアデータは本質的に人の一生に寄り添うべき生涯のログです。心拍数、睡眠パターン、体重、運動強度のログは、10年、20年という長期的なスパンで過去と比較して初めて、加齢に伴う身体の変化や疾患の兆候を捉える医学的な価値を持ちます。

数年単位の社内評価サイクルでスクラップ＆ビルドを繰り返すWebサービスの論理と、数十年単位の連続性を要する健康データの論理は、根本的に噛み合っていません。プラットフォームの都合でAPIを統廃合し、過去の連携手段を断絶させる行為は、個人の生きている証しとも言えるデータを自社の短期的な実験場として扱っているに等しい行為です。

さらに、厳格なOAuth認証や複雑な権限設定は、表向きは機密性の高い医療データの保護を名目に掲げています。しかしその実態は、各国の規制当局からの制裁を回避するための自己防衛と、データを自社エコシステム内に人質として囲い込むための障壁作りに偏っています。真にユーザーのデータ主権を尊重するのであれば、本人が手元の環境へ永続的にログを取り出せる平易なインターフェースを用意すべきです。

ユーザーに毎日身につけさせるハードウェアを販売しておきながら、それを支えるバックエンドにはWebサービスの気まぐれさを持ち込み続ける姿勢は、命や身体の記録を預かるプラットフォームとしての責務を著しく欠いています。

要点のまとめ

• Fitbitの開発者機能がGoogle Health APIへ移行したことで、個人利用のスクリプト作成であってもGCPの極めて難解なエンタープライズ向け設定を強要される事態に陥っている
• Google Fitは段階的廃止に向かっており、現行クラウドの主軸はFitbit基盤のGoogle Health、Android端末内のデータ中継はHealth Connectが担っているが、その役割分担は外部に極めて伝わりにくい
• 新規立ち上げが評価され既存機能の保守が軽視される社内文化により、後方互換性の切り捨てと仕様変更が常態化している
• 役所並みに厳格で煩雑な権限設定を求めながら、ベンチャーのように数年でサービスを改変・廃止するという、双方の悪い面を併せ持つ開発体験が生じている
• 数十年単位の連続性が不可欠な生涯の健康データを、短期的なWebサービスのスクラップ＆ビルド思想で扱うこと自体に、プラットフォームとしての根本的な不整合が存在する