エンドポイント

このページでは、REST API の規約の概要と、一般的な Google Health API タスクのインデックス、各タスクの例について説明します。

REST API の規則

Google Health API は、Google API 改善提案（AIP）標準（特に AIP-127（HTTP と gRPC のコード変換）と AIP-131 ～ AIP-135（標準メソッド））に準拠しています。これらの標準は、proto メッセージから HTTP リクエストへのデータのマッピング方法を定義します。

クエリ パラメータ

クエリ パラメータは、データが URL の一部である場合に使用されます。これは主に GET リクエスト（リソースの取得）または LIST リクエスト（フィルタリング/ページネーション）に使用されますが、DELETE オペレーションにも使用されます。

  • プレースメント: ? の後に URL に追加されます。
  • 構文: & で区切られた Key-Value ペア。
  • マッピング: URL パス テンプレートの一部ではないリクエスト メッセージのすべてのフィールドは、クエリ パラメータにマッピングされます。
  • 最適なケース: 単純な型（文字列、整数、列挙型）と繰り返しフィールド。

構文の例:

GET https://health.googleapis.com/v4/users/me/dataTypes/data-type/dataPoints?page_size=10&filter=data_type.interval.start_time >= "2025-10-01T00:00:00Z"

リクエストの本文

リクエスト本文は、データがリソースの状態を変更する場合や、URL に収まらないほど大きい場合に使用されます。通常、本文はリソース自体の JSON 表現です。通常、POST、PATCH、PUT のオペレーションに使用されます。

  • 配置: HTTP ペイロード内（URL には表示されません）。
  • 構文: JSON オブジェクトとしてフォーマットされます。
  • マッピング: google.api.http アノテーションで定義されます。
    • body: "*" は、メッセージ全体が本文であることを意味します。
    • body: "resource_name" は、proto の特定のフィールドのみが本文であることを意味します。
  • 最適な用途: 複雑なオブジェクト、ネストされたメッセージ、センシティブ データ。

構文の例:

POST https://health.googleapis.com/v4/users/me/dataTypes/data-type/dataPoints:rollUp
Content-Type: application/json

{
  "range": {
    "startTime": "2025-11-05T00:00:00Z",
    "endTime": "2025-11-13T00:00:00Z"
  },
  "windowSize": "3600s"
}

ハイブリッド ケース

AIP-134 準拠の Update メソッドまたは PATCH オペレーションでは、両方が使用されます。URL にはリソース名が含まれ、本文には更新されたリソースデータが含まれます。クエリ パラメータ（通常は update_mask）で、変更するフィールドを指定します。

PATCH https://health.googleapis.com/v4/projects/project-id/subscribers/subscriber-id
Content-Type: application/json

{
  "endpointUri": "https://myapp.com/new-webhooks/health"
}

主な違いの概要

機能 クエリ パラメータ リクエストの本文
AIP ガイドライン 検索、フィルタリング、読み取りオペレーションに使用されます。 書き込みオペレーションに使用されます。
公開設定 ブラウザの履歴とサーバーログに表示されます。 URL には表示されません。
複雑さ フラット構造または繰り返し構造に限定されます。 深くネストされた JSON オブジェクトをサポートします。
エンコード URL エンコードする必要があります（たとえば、スペースは %20 になります）。 標準の JSON エンコード。

日付

Google Health API の日付はすべて YYYY-MM-DD 形式で表示されます。Nutrition API は、次の条件で日付値の ISO-8601 標準をサポートしています。

  • 4 桁の年 YYYY
  • 0000 ～ 9999 の範囲内の年値
  • ISO-8601 標準または他のエポックで示される開始日の制限は適用されません

ヘッダー

Google Health API エンドポイントを実行するには、適切なヘッダーとアクセス トークンを使用する必要があります。GET リクエストと POST リクエストの両方で、次のヘッダーを使用することをおすすめします。

Authorization: Bearer access-token
Accept: application/json

API タスク インデックス

このセクションでは、一般的な Google Health API タスクのインデックスと、各タスクの例を示します。

Fitbit または Google のユーザー ID を取得する

ユーザーが Google OAuth 2.0 を通じて同意した後、トークン レスポンスに Fitbit または Google のユーザー ID が含まれません。ユーザー ID を取得するには、getIdentity エンドポイントを呼び出します。getIdentity は、Fitbit の以前のユーザー ID と Google ユーザー ID の両方を返します。

新しいユーザーが OAuth を通じて同意したらすぐに getIdentity エンドポイントを呼び出し、両方のユーザー ID を保存することをおすすめします。これにより、統合で下位互換性と上位互換性が提供されます。

次に例を示します。

リクエスト

GET https://health.googleapis.com/v4/users/me/identity
Authorization: Bearer access-token
Accept: application/json

レスポンス

{
  "name": "users/me/identity",
  "legacyUserId": "A1B2C3",
  "healthUserId": "111111256096816351"
}

1 日を通して収集された日中データまたは詳細データを取得する

特定のデータタイプの list エンドポイントを使用すると、そのデータタイプでサポートされているインターバルで、1 日を通して収集されたイントラデイデータまたは詳細データを取得できます。

次に例を示します。

リクエスト

GET https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints
Authorization: Bearer access-token
Accept: application/json

レスポンス

{
  "dataPoints": [
    {
      "dataSource": {
        "recordingMethod": "PASSIVELY_MEASURED",
        "device": {
          "manufacturer": "",
          "displayName": "Charge 6"
        },
        "platform": "FITBIT"
      },
      "steps": {
        "interval": {
          "startTime": "2026-03-04T07:05:00Z",
          "startUtcOffset": "0s",
          "endTime": "2026-03-04T07:06:00Z",
          "endUtcOffset": "0s",
          "civilStartTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 4
            },
            "time": {
              "hours": 7,
              "minutes": 5
            }
          },
          "civilEndTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 4
            },
            "time": {
              "hours": 7,
              "minutes": 6
            }
          }
        },
        "count": "40"
      }
    },
...
  ],
  "nextPageToken": "Xm5h-6L0viZxIlRuWjx5bmvy98zj85uG34tuMn16mu2pntsnZI32iqhq"
}

期間データの調整済みビューを取得する

重複するレコードやマルチデバイスの競合なしで期間データを取得するには、reconcile エンドポイントを呼び出します。調整エンドポイントは、同期バッチと複数の記録デバイスにまたがる重複する間隔を自動的に重複除去し、アクティビティ タイムラインのレンダリングや期間の計算に適した、信頼できる連続ストリームを返します。

接続されたデバイスで重複する間隔が生成される理由と、list と reconcile の運用上の比較については、データ管理ガイドをご覧ください。

次の例は、2 つの重複するエクササイズ セッションがあるユーザーに対して、list（重複するレコードを両方返す）のレスポンスと reconcile（信頼できるレコードを返して競合を解決する）のレスポンスを比較しています。

未加工リスト

GET https://health.googleapis.com/v4/users/me/dataTypes/exercise/dataPoints
Authorization: Bearer access-token
Accept: application/json
 
{
  "dataPoints": [
    {
      "name": "users/111111256096816351/dataTypes/exercise/dataPoints/7797422996486764704",
      "exercise": {
        "interval": {
          "startTime": "2026-09-03T11:20:00Z",
          "endTime": "2026-09-03T11:50:00Z"
        },
        "exerciseType": "RUNNING"
      }
    },
    {
      "name": "users/111111256096816351/dataTypes/exercise/dataPoints/4389052750481144696",
      "exercise": {
        "interval": {
          "startTime": "2026-09-03T11:00:00Z",
          "endTime": "2026-09-03T11:30:00Z"
        },
        "exerciseType": "RUNNING"
      }
    }
  ]
}

調整済み

GET https://health.googleapis.com/v4/users/me/dataTypes/exercise/dataPoints:reconcile
Authorization: Bearer access-token
Accept: application/json
 
{
  "dataPoints": [
    {
      "dataPointName": "users/111111256096816351/dataTypes/exercise/dataPoints/7797422996486764704",
      "exercise": {
        "interval": {
          "startTime": "2026-09-03T11:20:00Z",
          "endTime": "2026-09-03T11:50:00Z"
        },
        "exerciseType": "RUNNING"
      }
    }
  ]
}

調整では、人工的な時間結合（11:00:00Z から 11:50:00Z など）を合成するのではなく、重複除去と信頼できるレコードの選択によって競合するセッションを解決します。調整されたレスポンスは、元の記録された間隔（11:20:00Z から 11:50:00Z）とともに、勝ったデータポイント（7797422996486764704）を返します。これにより、そのセッションの測定されたテレメトリーと指標の完全性が維持されます。

データをフィルタする

時間間隔、日付、測定時間などの条件に一致するデータポイント レコードの特定のサブセットを取得するには、filter パラメータを指定して list エンドポイントまたは reconcile エンドポイントを使用します。

詳細なガイドライン、形式ルール、検証エラー、クエリの例については、データをフィルタするガイドをご覧ください。

データソース ファミリーでフィルタする

特定のタイプのソース（物理的なウェアラブル デバイスと手動入力など）からデータを分離または集計するには、dataSourceFamily パラメータを使用します。

reconcile、rollUp、dailyRollUp の詳細なガイドライン、サポートされているファミリ、リクエストとレスポンスの例については、フィルタ データガイドのデータソース ファミリでフィルタするをご覧ください。

期間の民事訴訟開始時刻でデータをフィルタする

filter パラメータを指定した list エンドポイントを使用して、市民時間または間隔でデータをフィルタします。

次に例を示します。

リクエスト

GET https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints?filter=steps.interval.civil_start_time >= "2026-03-04T00:00:00"
Authorization: Bearer access-token
Accept: application/json

レスポンス

{
  "dataPoints": [
    {
      "dataSource": {
        "recordingMethod": "PASSIVELY_MEASURED",
        "device": {
          "manufacturer": "",
          "displayName": "Charge 6"
        },
        "platform": "FITBIT"
      },
      "steps": {
        "interval": {
          "startTime": "2026-03-04T07:05:00Z",
          "startUtcOffset": "0s",
          "endTime": "2026-03-04T07:06:00Z",
          "endUtcOffset": "0s",
          "civilStartTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 4
            },
            "time": {
              "hours": 7,
              "minutes": 5
            }
          },
          "civilEndTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 4
            },
            "time": {
              "hours": 7,
              "minutes": 6
            }
          }
        },
        "count": "40"
      }
...
  ],
  "nextPageToken": "Xm5h-6L0viZxIlRuQjp5bml1bZ4ve2dhNmZvMnt4Yn7qIGQhbHN3YQ"
}

サンプル観測の物理時間でデータをフィルタする

filter パラメータを指定して list エンドポイントを使用し、サンプル観測の物理時間でデータをフィルタします。

次に例を示します。

リクエスト

GET https://health.googleapis.com/v4/users/me/dataTypes/body-fat/dataPoints?filter=body_fat.sample_time.physical_time >= "2026-03-01T00:00:00Z"
Authorization: Bearer access-token
Accept: application/json

レスポンス

{
  "dataPoints": [
    {
      "name": "users/123456789/dataTypes/body-fat/dataPoints/1234567890",
      "dataSource": {
        "recordingMethod": "UNKNOWN",
        "application": {
          "packageName": "",
          "webClientId": "",
          "googleWebClientId": "google-web-client-id"
        },
        "platform": "GOOGLE_WEB_API"
      },
      "bodyFat": {
        "sampleTime": {
          "physicalTime": "2026-03-10T10:00:00Z",
          "utcOffset": "0s",
          "civilTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 10
            },
            "time": {
              "hours": 10
            }
          }
        },
        "percentage": 20
      }
    }
  "nextPageToken": ""
}

データソース ファミリーでフィルタして集計する

データソース ファミリーは、データソース（スマートウォッチ、モバイルアプリ、手動入力など）の論理的なグループです。これにより、特定の種類のソース（物理的なウェアラブル デバイスと手動入力など）のデータを分離または集計できます。

reconcile、rollUp、dailyRollUp エンドポイントはすべて dataSourceFamily パラメータをサポートしています。渡すメカニズムはエンドポイントによって異なります。

エンドポイント（HTTP メソッド） メカニズム
reconcile（GET） dataSourceFamily を URL クエリ パラメータとして渡します。
rollUp（POST） dataSourceFamily を JSON リクエスト本文のフィールドとして渡します。
dailyRollUp（POST） dataSourceFamily を JSON リクエスト本文のフィールドとして渡します。

サポートされているデータソース ファミリー

次の表に、サポートされている dataSourceFamily の値を示します。

オプション 説明
users/me/dataSourceFamilies/all-sources デフォルト値。登録されているすべてのファーストパーティ（1P）とサードパーティ（3P）のデータソースで調整されたデータポイントを返します。このオプションでは、サードパーティ製アプリのデータも返されます（スマートウォッチの歩数 + サードパーティ製アプリの歩数 + スマートフォンの歩数 + 手動入力の歩数など）。
users/me/dataSourceFamilies/google-wearables Google と Fitbit トラッカー デバイス（Fitbit ウェアラブル トラッカーや Google Pixel Watch など）で記録されたデータが含まれます。手動で記録されたデータとスマートフォンで推定されたデータは除外されます。このオプションは、ウェアラブル ハードウェアによって直接記録されたセンサーの生テレメトリーを統合で必要とする場合に使用します。
users/me/dataSourceFamilies/google-sources Google と Fitbit のファーストパーティ ソースが含まれます。これには、トラッカー デバイスの記録、ヘルスコネクトのデータ、ファーストパーティ製アプリ（Fitbit アプリや Google Fit など）を通じて記録された手動入力が含まれます。

特定のデータソース ファミリーから調整済みのデータストリームを取得するには、dataSourceFamily クエリ パラメータを使用して reconcile エンドポイントを呼び出します。

たとえば、次の GET リクエストは、2026 年 3 月 3 日の翌日のトラッカーで記録された睡眠データを取得します。

リクエスト

GET https://health.googleapis.com/v4/users/me/dataTypes/sleep/dataPoints:reconcile?dataSourceFamily=users/me/dataSourceFamilies/google-wearables&filter=sleep.interval.civil_end_time >= "2026-03-03"
Authorization: Bearer access-token
Accept: application/json

レスポンス

{
  "dataPoints": [
    {
      "name": "users/2515055256096816351/dataTypes/sleep/dataPoints/2724123844716220216",
      "dataSource": {
        "recordingMethod": "DERIVED",
        "device": {
          "displayName": "Charge 6"
        },
        "platform": "FITBIT"
      },
      "sleep": {
        "interval": {
          "startTime": "2026-03-03T20:57:30Z",
          "startUtcOffset": "0s",
          "endTime": "2026-03-04T04:41:30Z",
          "endUtcOffset": "0s"
        },
        "type": "STAGES",
        "stages": [
          {
            "startTime": "2026-03-03T20:57:30Z",
            "startUtcOffset": "0s",
            "endTime": "2026-03-03T20:59:30Z",
            "endUtcOffset": "0s",
            "type": "AWAKE",
            "createTime": "2026-03-04T04:43:40.937183Z",
            "updateTime": "2026-03-04T04:43:40.937183Z"
          },
          {
            "startTime": "2026-03-04T04:07:30Z",
            "startUtcOffset": "0s",
            "endTime": "2026-03-04T04:41:30Z",
            "endUtcOffset": "0s",
            "type": "AWAKE",
            "createTime": "2026-03-04T04:43:40.937183Z",
            "updateTime": "2026-03-04T04:43:40.937183Z"
          }
        ],
        "metadata": {
          "stagesStatus": "SUCCEEDED",
          "processed": true,
          "main": true
        },
        "summary": {
          "minutesInSleepPeriod": "464",
          "minutesAfterWakeUp": "0",
          "minutesToFallAsleep": "0",
          "minutesAsleep": "407",
          "minutesAwake": "57",
          "stagesSummary": [
            {
              "type": "AWAKE",
              "minutes": "56",
              "count": "12"
            },
            {
              "type": "LIGHT",
              "minutes": "198",
              "count": "19"
            },
            {
              "type": "DEEP",
              "minutes": "114",
              "count": "10"
            },
            {
              "type": "REM",
              "minutes": "94",
              "count": "4"
            }
          ]
        },
        "createTime": "2026-03-04T04:43:40.337983Z",
        "updateTime": "2026-03-04T04:43:40.937183Z"
      }
    }
  ],
  "nextPageToken": ""
}

特定のデータソース ファミリーに制限された特定のウィンドウ サイズでデータポイントを集計するには、rollUp エンドポイントを呼び出し、JSON リクエスト本文で dataSourceFamily フィールドを渡します。

次の POST リクエストは、ウェアラブル デバイスからのみ集計された、1 時間間隔（3600s）の歩数データをクエリします。

リクエスト

POST https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints:rollUp
Authorization: Bearer access-token
Accept: application/json

{
  "range": {
    "startTime": "2026-07-29T00:00:00Z",
    "endTime": "2026-07-29T23:59:59Z"
  },
  "windowSize": "3600s",
  "dataSourceFamily": "users/me/dataSourceFamilies/google-wearables"
}

レスポンス

{
  "rollupDataPoints": [
    {
      "startTime": "2026-07-29T08:00:00Z",
      "endTime": "2026-07-29T09:00:00Z",
      "steps": {
        "countSum": "1200"
      }
    },
    {
      "startTime": "2026-07-29T09:00:00Z",
      "endTime": "2026-07-29T10:00:00Z",
      "steps": {
        "countSum": "3450"
      }
    }
  ]
}

特定のソース ファミリーの日次データポイントを集計するには、dailyRollUp エンドポイントを呼び出し、リクエスト本文で dataSourceFamily フィールドを渡します。

たとえば、次のリクエストは、Google と Fitbit のすべてのファーストパーティ ソース（ウェアラブル + 手動入力）を含む、ユーザーの歩数の 1 日あたりのロールアップを計算します。

リクエスト

POST https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints:dailyRollUp
Authorization: Bearer access-token
Accept: application/json

{
  "range": {
    "start": {
      "date": {
        "year": 2026,
        "month": 7,
        "day": 28
      },
      "time": {
        "hours": 0,
        "minutes": 0,
        "seconds": 0,
        "nanos": 0
      }
    },
    "end": {
      "date": {
        "year": 2026,
        "month": 7,
        "day": 30
      },
      "time": {
        "hours": 0,
        "minutes": 0,
        "seconds": 0,
        "nanos": 0
      }
    }
  },
  "windowSizeDays": 1,
  "dataSourceFamily": "users/me/dataSourceFamilies/google-sources"
}

レスポンス

{
  "rollupDataPoints": [
    {
      "civilStartTime": {
        "date": {
          "year": 2026,
          "month": 7,
          "day": 28
        },
        "time": {}
      },
      "civilEndTime": {
        "date": {
          "year": 2026,
          "month": 7,
          "day": 28
        },
        "time": {
          "hours": 23,
          "minutes": 59,
          "seconds": 59
        }
      },
      "steps": {
        "countSum": "8430"
      }
    },
    {
      "civilStartTime": {
        "date": {
          "year": 2026,
          "month": 7,
          "day": 29
        },
        "time": {}
      },
      "civilEndTime": {
        "date": {
          "year": 2026,
          "month": 7,
          "day": 29
        },
        "time": {
          "hours": 23,
          "minutes": 59,
          "seconds": 59
        }
      },
      "steps": {
        "countSum": "11245"
      }
    }
  ]
}

一定期間のデータポイントを集計する

rollUp エンドポイントを使用して、ユーザーの物理時間（UTC）に基づく datetime 範囲で、秒単位のウィンドウに基づいてデータポイントの集計を返します。

rollUp エンドポイントを呼び出すときは、必要な期間と windowSize を表すリクエストの本文を指定します。windowSize の次の要件に注意してください。

  • 最小ウィンドウ サイズ: windowSize の期間は 1 秒以上（"1s"）でなければなりません。1 秒未満の期間、ゼロ、負の期間は 400 Bad Request（INVALID_ROLLUP_WINDOW）で拒否されます。
  • ストレージ解像度のアライメント: 集計データのサブバケット間の分布が不均一にならないように、データ型の基盤となるストレージ解像度（1 分間隔の "60s" など）以上の windowSize を選択します。詳細については、ロールアップ ウィンドウ サイズと基盤となるストレージの解像度をご覧ください。

たとえば、歩数を 1 分間隔（60s）でロールアップするには:

リクエスト

POST https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints:rollUp
Authorization: Bearer access-token
Accept: application/json

{
  "range": {
    "startTime": "2026-02-17T17:00:00Z",
    "endTime": "2026-02-17T17:59:59Z"
  },
  "windowSize": "60s"
}

レスポンス

{
  "rollupDataPoints": [
    {
      "startTime": "2026-02-17T17:55:00Z",
      "endTime": "2026-02-17T17:56:00Z",
      "steps": {
        "countSum": "72"
      }
    },
    {
      "startTime": "2026-02-17T17:54:00Z",
      "endTime": "2026-02-17T17:55:00Z",
      "steps": {
        "countSum": "85"
      }
    },
...
  ]
}

1 日または複数日のデータを集計する

dailyRollUp エンドポイントは、windowSize と呼ばれる 1 日または複数日にわたってデータを集計する場合に使用します。リクエスト本文で、必要な間隔の閉区間 / 開区間の民事時間範囲を指定します。データ型に応じて、期間の合計または平均が返されます。

次に例を示します。

リクエスト

POST https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints:dailyRollUp
Authorization: Bearer access-token
Accept: application/json

{
  "range": {
    "start": {
      "date": {
        "year": 2026,
        "month": 2,
        "day": 26
      },
      "time": {
        "hours": 0,
        "minutes": 0,
        "seconds": 0,
        "nanos": 0
      }
    },
    "end": {
      "date": {
        "year": 2026,
        "month": 2,
        "day": 26
      },
      "time": {
        "hours": 23,
        "minutes": 59,
        "seconds": 59,
        "nanos": 0
      }
    }
  },
  "windowSizeDays": 1
}

レスポンス

{
  "rollupDataPoints": [
    {
      "civilStartTime": {
        "date": {
          "year": 2026,
          "month": 2,
          "day": 26
        },
        "time": {}
      },
      "civilEndTime": {
        "date": {
          "year": 2026,
          "month": 2,
          "day": 26
        },
        "time": {
          "hours": 23,
          "minutes": 59,
          "seconds": 59
        }
      },
      "steps": {
        "countSum": "3822"
      }
    }
  ]
}

範囲がウィンドウ サイズの倍数でない場合のバケット化

リクエストされた範囲が windowSize（または windowSizeDays）の倍数でない場合、最後のバケットは範囲の上限で切り捨てられ、ウィンドウ サイズよりも短い期間をカバーします。API はリクエストをそのまま受け入れ、丸め、時間シフト、データ補間は行いません。

リクエストされた範囲全体をカバーするために、API は天井除算を使用して集計ウィンドウの合計数を計算します。

Number of windows = ceiling(Range duration / Window size)

各バケットは、範囲の先頭から順に開始されます。別のフルサイズのウィンドウを追加すると、リクエストされた終了時刻を超える場合は、最後のウィンドウが範囲の終了時刻で切り捨てられます（クランプされます）。

バケット化の仕組み

分割できない範囲でロールアップをリクエストすると、API は次のルールを適用します。

  • バケット化は、リクエストされた範囲の先頭（range.startTime または range.start）から始まり、ウィンドウ サイズ（windowSize または windowSizeDays）ずつ前進します。
  • 最後の時系列バケットは、リクエストされた範囲（range.endTime または range.end）の末尾でクランプされます。つまり、リクエストされたウィンドウ サイズよりも短い期間を対象とします。
  • 返された RollupDataPoint オブジェクトまたは DailyRollupDataPoint オブジェクトは、独自の開始タイムスタンプと終了タイムスタンプを明示的に指定します。これを使用して、切り捨てられたバケットの実際の期間を検査できます。
  • API はロールアップ データを逆の年代順（新しい順）で返すため、最後の年代順バケット（切り捨てられたバケット）は、返されるリストの最初の要素（index 0）として表示されます。

シナリオ: 12 分間の範囲と 5 分間のウィンドウ

クライアントが 5 分の windowSize で 12 分間の範囲のロールアップをリクエストしたとします。

  • range.startTime: 10:00:00
  • range.endTime: 10:12:00（合計時間: 12 分）
  • windowSize: 5 minutes

12 分は 5 分の倍数ではないため（12 = 5 * 2 + 2）、API はリクエストを受け入れ、ウィンドウの数を ceiling(12 / 5) = 3 として計算します。

これにより、次の 3 つの時系列バケットが生成されます。

  1. バケット 1: [10:00:00, 10:05:00) - 期間: 5 分（全ウィンドウ）
  2. バケット 2: [10:05:00, 10:10:00) - 期間: 5 分（全ウィンドウ）
  3. バケット 3（切り捨て）: [10:10:00, 10:12:00) - 期間: 2 分（range.endTime で切り捨て）

集計値への影響

最後のウィンドウの期間が短いため、短縮されたバケットでは、期間が短いという理由だけで、加算指標（歩数の合計やカウントなど）が低くなります。

この 12 分間の範囲全体で、ユーザーが 1 分あたり 100 歩の一定のペースで歩いた場合:

  • バケット 1（10:00 ～ 10:05）: 500 歩（5 分 × 100 歩/分）
  • バケット 2（10:05 ～ 10:10）: 500 歩（5 分 × 100 歩/分）
  • バケット 3（10:10 ～ 10:12）: 200 歩（2 分 × 100 歩/分）

順序を示す API レスポンスの例

API は結果を逆の年代順で返すため、切り捨てられたバケットは返されたリストの最初の要素として表示されます。

{
  "rollupDataPoints": [
    {
      "startTime": "2026-08-20T10:10:00Z",
      "endTime": "2026-08-20T10:12:00Z",
      "steps": {
        "countSum": "200"
      }
    },
    {
      "startTime": "2026-08-20T10:05:00Z",
      "endTime": "2026-08-20T10:10:00Z",
      "steps": {
        "countSum": "500"
      }
    },
    {
      "startTime": "2026-08-20T10:00:00Z",
      "endTime": "2026-08-20T10:05:00Z",
      "steps": {
        "countSum": "500"
      }
    }
  ]
}

ロールアップ ウィンドウ サイズと基盤となるストレージの解像度

rollUp エンドポイントは 1 秒以上の任意の windowSize を受け入れますが、データ型ごとに異なるサンプリング レートまたは間隔で測定値を記録し、基盤となるストレージに保持します。たとえば、steps、distance、active-minutes、active-energy-burned などのウェアラブル デバイスの身体活動指標は、通常 1 分（60s）間隔で記録されます。

間隔データ型を集計する場合、rollUp エンドポイントは、記録された各データポイントを、そのデータポイントの startTime を含むバケットに配置します。API は、間隔データをスライスしたり、補間したり、サブ間隔バケットに分散したりしません。

基盤となるデータ ストレージ間隔よりも小さい windowSize を指定した場合（たとえば、1 分間隔で保存された steps の 10 秒間のウィンドウをリクエストした場合）:

  1. 間隔の startTime（10:00:00 から 10:00:10 など）に一致する最初のサブバケットは、1 分間の累積カウント全体（その 1 分間に記録された 100 歩など）を受け取ります。
  2. 同じ 1 分間の残りのサブバケット（10:00:10～10:00:20、10:00:20～10:00:30 など）には、そのウィンドウ内で開始される間隔がないため、データポイントは含まれません。

これにより、間隔全体の値が最初のサブウィンドウに集中する「スパイク」データが生成されます。

均等に分散された意味のある集計を取得するには、常に windowSize をターゲット データ型の基盤となるストレージ解像度以上の期間に設定します（たとえば、steps の場合は 60s 以上）。各データ型のストレージ解像度と最小推奨ロールアップ ウィンドウについては、Google Health API データ型のリファレンスをご覧ください。

ユーザーの健康に関するデータを更新する

patch エンドポイントを使用して、ユーザーの健康に関するデータを更新します。

patch エンドポイントは、リクエスト URL で指定された識別子に基づいて既存のレコードを更新します。以前に挿入されたデータポイントの識別子を指定します。API は既存のレコードを上書きします。

データポイントのインターバル タイムスタンプ（startTime と endTime）は、レコードの所有者によって更新することも、ヘルスコネクトなどのアップストリーム プラットフォームから伝播することもできます。タイムスタンプの可変性の詳細については、データ管理ガイドをご覧ください。間隔タイムスタンプの更新例については、既存のデータの期間タイムスタンプを更新するをご覧ください。

データポイント識別子を使用するタイミング

データポイント識別子は、次のシナリオで不可欠です。

  • 対象を絞った更新: 特定の測定を更新するには、patch リクエストでその識別子を指定します。
  • 削除: 識別子を保持することで、アプリケーションは後で batchDelete エンドポイントを使用してレコードを削除できます。

以下は、ユーザーが「Scales R Us」社の「HumanScale」という体重計で体脂肪率の測定値を更新する例です。ユーザーの新しい体脂肪率は、2026 年 3 月 10 日の時点で 20% です。

リクエスト

PATCH https://health.googleapis.com/v4/users/me/dataTypes/body-fat/dataPoints/1234567890
Authorization: Bearer access-token
Content-Type: application/json

{
  "name": "users/me/dataTypes/body-fat/dataPoints/1234567890",
  "dataSource": {
    "recordingMethod": "ACTIVELY_MEASURED",
    "device": {
      "formFactor": "SCALE",
      "manufacturer": "Scales R Us",
      "displayName": "HumanScale"
    }
  },
  "bodyFat": {
    "sampleTime": {
      "physicalTime": "2026-03-10T10:00:00Z"
    },
    "percentage": 20
  }
}

レスポンス

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4main.DataPoint",
    "name": "users/123456789/dataTypes/body-fat/dataPoints/1234567890",
    "dataSource": {
      "recordingMethod": "ACTIVELY_MEASURED",
      "device": {
        "formFactor": "SCALE",
        "manufacturer": "Scales R Us",
        "displayName": "HumanScale"
      },
      "application": {
        "googleWebClientId": "618308034039.apps.googleusercontent.com"
      },
      "platform": "GOOGLE_WEB_API"
    },
    "bodyFat": {
      "sampleTime": {
        "physicalTime": "2026-03-10T10:00:00Z"
      },
      "percentage": 20
    }
  }
}

既存のデータの更新間隔のタイムスタンプ

既存の間隔データポイントの startTime または endTime を更新するには、データポイントのリソース URI に PATCH リクエストを送信します。レコードのフィールドを変更できるのは、レコードの元の作成者またはオーナーのみです。アプリケーションは、作成していないデータポイントを編集できません。

タイムスタンプの変更可能性、ヘルスコネクトからのアップストリーム更新、キャッシュ保存の影響については、データ管理ガイドをご覧ください。

次の例は、オーナー アプリが patch エンドポイントを使用して既存の水分補給ログの間隔タイムスタンプを更新する様子を示しています。

リクエスト

PATCH https://health.googleapis.com/v4/users/me/dataTypes/hydration-log/dataPoints/4093039283164890826
Authorization: Bearer access-token
Content-Type: application/json

{
  "hydrationLog": {
    "interval": {
      "startTime": "2026-09-03T10:05:00Z",
      "endTime": "2026-09-03T10:19:59Z"
    },
    "amountConsumed": {
      "milliliters": 350
    }
  }
}

レスポンス

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4.DataPoint",
    "name": "users/111111256096816351/dataTypes/hydration-log/dataPoints/4093039283164890826",
    "hydrationLog": {
      "interval": {
        "startTime": "2026-09-03T10:05:00Z",
        "endTime": "2026-09-03T10:19:59Z",
        "civilStartTime": {
          "date": {
            "year": 2026,
            "month": 9,
            "day": 3
          },
          "time": {
            "hours": 10,
            "minutes": 5
          }
        },
        "civilEndTime": {
          "date": {
            "year": 2026,
            "month": 9,
            "day": 3
          },
          "time": {
            "hours": 10,
            "minutes": 19,
            "seconds": 59
          }
        }
      },
      "amountConsumed": {
        "milliliters": 350
      }
    }
  }
}

食品を記録する

食品アイテムを記録するには、nutrition-log dataPoints エンドポイントに POST リクエストを送信します。リクエストの本文には、nutritionLog オブジェクトを含む DataPoint が含まれます。詳しくは、栄養ガイドをご覧ください。

次に例を示します。

リクエスト

POST https://health.googleapis.com/v4/users/me/dataTypes/nutrition-log/dataPoints
Authorization: Bearer access-token
Content-Type: application/json

{
  "nutritionLog": {
    "interval": {
      "startTime": "2026-06-16T12:00:00Z",
      "endTime": "2026-06-16T12:30:00Z"
    },
    "foodDisplayName": "Banana",
    "mealType": "LUNCH",
    "energy": {
      "kcal": 105
    },
    "totalCarbohydrate": {
      "grams": 27
    },
    "totalFat": {
      "grams": 0.3
    }
  }
}

レスポンス

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4.DataPoint",
    "name": "users/123456789/dataTypes/nutrition-log/dataPoints/567890",
    "dataSource": {
      "recordingMethod": "ACTIVELY_MEASURED",
      "platform": "GOOGLE_WEB_API"
    },
    "nutritionLog": {
      "interval": {
        "startTime": "2026-06-16T12:00:00Z",
        "startUtcOffset": "0s",
        "endTime": "2026-06-16T12:30:00Z",
        "endUtcOffset": "0s"
      },
      "energy": {
        "kcal": 105
      },
      "totalCarbohydrate": {
        "grams": 27
      },
      "totalFat": {
        "grams": 0.3
      },
      "mealType": "LUNCH",
      "foodDisplayName": "Banana"
    }
  }
}

ユーザーの健康に関するデータを削除する

batchDelete メソッドを使用して、ユーザーの Fitbit アプリデータの配列を削除します。

たとえば、以前に体重計で体脂肪率を記録したユーザーが、その記録を削除したい場合を考えてみましょう。元の挿入アクションの user-id と data-point-id を使用します。

リクエスト

POST https://health.googleapis.com/v4/users/me/dataTypes/body-fat/dataPoints:batchDelete
Authorization: Bearer access-token
Accept: application/json
content-length: 93

{
  "names": [
    "users/123456789/dataTypes/body-fat/dataPoints/1234567890"
  ]
}

レスポンス

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4main.BatchDeleteDataPointsResponse"
  }
}

デバイス情報を確認する

list エンドポイントを使用して、ユーザーのアカウントにペア設定されているデバイスのリストを取得します。これには、デバイスのモデル情報（deviceVersion）と、Google Health モバイルアプリと最後に同期した日時（lastSyncTime）が含まれます。

リストの構成と同期情報は、同期に関する問題のトラブルシューティングや、前回の同期時刻以降の履歴データの取得に役立ちます。

次に例を示します。

リクエスト

GET https://health.googleapis.com/v4/users/me/pairedDevices
Authorization: Bearer access-token
Accept: application/json

レスポンス

{
  "pairedDevices": [
    {
      "name": "users/me/pairedDevices/123456",
      "deviceType": "TRACKER",
      "batteryStatus": "High",
      "batteryLevel": 88,
      "lastSyncTime": "2026-03-04T07:05:00Z",
      "deviceVersion": "Charge 6",
      "macAddress": "00:11:22:33:44:55",
      "features": [
        "STEPS",
        "HEART_RATE"
      ]
    }
  ]
}

過去のデータにクエリを実行する

Google Health API の主なメリットの一つは、ユーザーのパフォーマンスを追跡し、健康状態を長期間にわたってモニタリングできることです。ユーザーのデータは、記録された時点まで遡ってクエリできます。API では、アプリケーションが使用できる過去のデータ量に制限は課されません。

ただし、過去のデータのクエリは、標準のレート制限の対象となります。システムの安定性を管理し、過剰なペイロードを防ぐため、Google Health API はエンドポイント固有のページサイズで自動ページネーションを使用します。次の境界と動作に注意してください。

  • 自動ページ設定: 長い期間のデータをクエリすると、API はそのエンドポイントのページサイズの上限までの結果の最初のページと nextPageToken のみを返します。後続のページをリクエストするには、nextPageToken を使用する必要があります。
  • 可変ページサイズ: 上限は、エンドポイントとデータ型によって異なります。ほとんどのデータ型では、ページサイズの上限は 10,000 です。ただし、exercise や sleep などの特定のデータ型では、デフォルトと最大ページサイズは 25 に制限されます。たとえば、クライアントが過去 10 年間のすべての睡眠データをリクエストした場合でも、API は最初のページに 25 件の睡眠セッションのみを返します。
  • ロールアップの日付範囲の制限: データ ロールアップと集計のエンドポイント（rollUp や dailyRollUp など）では、クエリの日付範囲はデータ型に基づいて制限されます。
    • calories-in-heart-rate-zone、heart-rate、active-minutes、total-calories の最大範囲は 14 日間です。
    • 他のすべてのロールアップ データ型の最大期間は 90 日間です。

アプリケーションに必要な過去のデータ量によっては、データセット全体を取得するために、ページを順番にページネーションする必要があります。アプリケーションのデータ同期プロセスを設計する際は、この点に留意してください。

最適なパフォーマンスを確保し、API エラーを回避するには、過去のデータをクエリする際に次のガイドラインに従ってください。

段階的なデータ同期（ホットロードとコールド スタートの読み込み）

  • 初期の「ホット」読み込み: メインの読み込みシーケンス中に、最新の 7 ～ 14 日間のデータのみを取得してレンダリングします。これにより、ユーザーは長時間実行されるクエリを待つことなく、データをすぐに確認できます。
  • バックグラウンドの「コールド」読み込み: メイン UI のレンダリング後に、古い履歴データの取得を非同期の優先度の低いキューまたはバックグラウンド プロセスに委任します。

集計のためのクエリのチャンク化

  • ロールアップ エンドポイントと毎日のロールアップ エンドポイントでは、最大期間の上限（データ型に応じて 14 日または 90 日）が適用されるため、過去の大きな集計クエリを、この上限内の小さな連続した間隔に分割する必要があります。
  • これらのサブクエリを安全にバッチ処理またはシーケンス処理して、同時実行制限を尊重し、UI の進行状況インジケーターを安定した状態に保ちます。

事前集計されたロールアップを活用する

事前集計された概要エンドポイント（DailyRollUpDataPoints など）を使用するように、概要ダッシュボードと傾向グラフを再構築します。これにより、バックエンドのコンピューティング オーバーヘッドとクライアントへのネットワーク転送時間が大幅に短縮されます。

復元力のあるエラー処理（スマート再試行）

  • レート制限（429 Too Many Requests）とサーバー ゲートウェイ タイムアウト（504 Gateway Timeout）が発生した場合は、厳密な指数バックオフ処理を実装します。失敗した大きなペイロードをすぐに再試行しないでください。即時再試行はバックエンドの輻輳を増大させ、システム劣化を悪化させます。