このページでは、REST API 規則の概要と、一般的な Google Health API タスクのインデックス、各タスクの例について説明します。
REST API の規則
Google Health API は、Google API Improvement Proposals(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 は含まれません。認可コードを交換した直後に getIdentity エンドポイントを呼び出して、legacyUserId と healthUserId の両方を取得し、ユーザーの Google アカウントが Google Health にリンクされていることを確認します。アカウントがまだリンクされていない場合、getIdentity は理由 ACCOUNT_NOT_LINKED で 400 Bad
Request を返します(リンクされていない Google アカウントを処理するをご覧ください)。
次に例を示します。
リクエスト
GET https://health.googleapis.com/v4/users/me/identity Authorization: Bearer access-token Accept: application/json
レスポンス(200 OK)
{
"name": "users/me/identity",
"legacyUserId": "A1B2C3",
"healthUserId": "111111256096816351"
}レスポンス(400 ACCOUNT_NOT_LINKED)
{
"error": {
"code": 400,
"message": "The account is not linked to Google Health.",
"status": "FAILED_PRECONDITION",
"details": [
{
"@type": "type.googleapis.com/google.rpc.ErrorInfo",
"reason": "ACCOUNT_NOT_LINKED",
"domain": "health.googleapis.com",
"metadata": {
"redirect_uri": "https://fitbit.google.com/auth/signup"
}
}
]
}
}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 エンドポイントを呼び出します。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 の詳細なガイドライン、サポートされているファミリー、リクエストとレスポンスの例については、データフィルタ ガイドのデータソース ファミリーでフィルタするをご覧ください。
間隔の市民開始時間でデータをフィルタする
list エンドポイントと filter パラメータを使用して、市民時間または間隔でデータをフィルタします。
次に例を示します。
リクエスト
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) |
JSON リクエスト本文のフィールドとして dataSourceFamily を渡します。 |
dailyRollUp(POST) |
JSON リクエスト本文のフィールドとして dataSourceFamily を渡します。 |
サポートされているデータソース ファミリー
次の表に、サポートされている 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)の 1 日の歩数をクエリします。
リクエスト
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 のすべてのファースト パーティ ソース(ウェアラブル + 手動入力)を含む、ユーザーの歩数の日次ロールアップを計算します。
リクエスト
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 範囲にわたって、秒単位のウィンドウ(windowSize)に基づいてデータポイントの集計を返します。
rollUp エンドポイントを呼び出すときに、必要な半開区間の時間 range と windowSize(少なくとも "1s")を表すリクエスト本文を指定します。windowSize の要件、ストレージ解像度の調整、バケット化ルール、リクエストとレスポンスの例に関する詳細なガイドラインについては、データ集計ガイドの物理的な時間間隔で集計するをご覧ください。
1 日または複数日のデータを集計する
dailyRollUp エンドポイントを使用して、1 日または複数日(windowSizeDays)にわたってデータを集計します。リクエスト本文で、必要な間隔のクローズド オープンな市民時間 range を指定します。データ型に応じて、エンドポイントは各ウィンドウの合計または平均を返します。
1 日の集計動作、常用時の処理、リクエストごとの範囲制限、リクエストとレスポンスの例については、集計データガイドの暦日をまたいで集計するをご覧ください。
ユーザーの健康に関するデータを更新する
patch エンドポイントを使用して、ユーザーの健康に関するデータを更新します。
patch エンドポイントは、リクエスト URL で指定された識別子に基づいて既存のレコードを更新します。以前に挿入されたデータポイントの ID を指定します。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
}
}
}既存のデータの更新間隔のタイムスタンプ
既存のデータポイントの間隔タイムスタンプ(REST JSON ペイロードの startTime と endTime、または gRPC の start_time と end_time)を更新するには、データポイントのリソース 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)が発生した場合は、厳格な指数バックオフ処理を実装します。失敗した大きなペイロードをすぐに再試行しないでください。即時再試行は、バックエンドの輻輳を増幅させ、システムの劣化を悪化させます。