Fitbit / Apple Watch 共にリアルタイムは厳しいっぽらしい。
Pixel / iPhone のAPIを使う方がまだ若干正確らしいっぽい。
---
一番現実的なのはこれです。
本命: Pixel 側で Android Sleep API を使う
Pixel 10XL 側の Google Play services Sleep API は、まさに「寝ていそうか」を推定するAPIです。SleepClassifyEvent に confidence 0..100、端末の動き、周囲の明るさが入ります。公式にも「約10分間隔の分類イベント」として説明されてい
ます。
これは Fitbit の睡眠ステージを読むAPIではなく、Android端末側の文脈推定です。Fitbitを腕につけている事実は直接使えませんが、Pixelが枕元にあるならかなり使いやすいです。
Fitbit
Fitbit Web API には睡眠ログAPIがありますが、基本は 睡眠後に同期された睡眠記録を読むものです。Sleep Logs は日付指定で睡眠ログを返します。Fitbit Subscriptions で sleep コレクションの更新通知を受ける構成は作れますが、それは
「睡眠ログが更新された」通知であって、「今寝ている」ライブイベントではありません。
心拍の intraday API はあります。個人利用なら自分の intraday heart rate へアクセスできる、と公式に書かれています。ただしこれもリアルタイム保証ではなく、同期遅延があります。サーバー側で「心拍低下 歩数ゼロ 深夜 Pixel
Sleep API confidence高い」を補強材料にする用途が現実的です。
Apple Watch / iPhone
HealthKit の sleepAnalysis には asleepCore、asleepDeep、asleepREM、awake などがあります。ただしこれも基本は 記録された睡眠サンプルを読む仕組みです。HealthKit の HKObserverQuery と background delivery で更新検知はできます
が、Apple公式にも「変更があったことを通知する。詳細は別クエリで読む」「通知頻度はシステム管理」という性質で、リアルタイム睡眠判定APIではありません。
Apple Watchからリアルタイム睡眠ステージや「現在睡眠中」をサードパーティが安定取得する公開APIは期待しない方がいいです。Sleep Focus のオン/オフやショートカットでサーバーに送ることはできますが、それは「寝るモード」や「ベッドに
いる」の代理指標です。
作るなら構造はこうです。
Pixel Android app
-> Android Sleep API SleepClassifyEvent
-> confidence / motion / light を5-10分ごとにサーバー送信
Fitbit Web API
-> sleep log は翌朝/同期後の検証用
-> heart rate intraday / steps は補助シグナル
iPhone app
-> HealthKit sleepAnalysis は事後検証用
-> Sleep Focus / 端末状態 / HealthKit更新を補助シグナル
Server
-> asleep / probably_asleep / awake / unknown の状態機械
-> asleep中だけ LLMタスクを実行
-> 起床検出で結果を通知
サーバー側の判定例:
asleep に入る条件:
- Android Sleep confidence >= 75 が2回以上連続
- motion <= 2
- light <= 2
- 直近20分 steps ほぼゼロ
- 深夜帯 or Sleep Focus on
awake に戻す条件:
- Sleep confidence < 40
- 端末アンロック
- 歩数/移動あり
- Sleep Focus off
- 朝の時間帯 Fitbit/Apple sleep log 終了が後から確認された
なので、面白い構造は十分作れます。精度を求めるなら Pixelの Sleep API を主センサー、Fitbit/Apple Watch/HealthKit は補助と翌朝の答え合わせにするのが一番堅いです。