Google Health APIにCLIが登場：ghealthはFitbitデータ向けのオープンソースツール
ghealthは、Google Health API v4をラップする新しいオープンソースのコマンドラインツールです。Apache 2.0ライセンスの下で単一のGoバイナリとして提供され、Fitbitや接続デバイスのデータを一貫したJSONに変換します。このプロジェクトはhttps://github.com/ghealth/ghealthで公開されています。
このリリースは、完全なモバイルクライアントやWebクライアントを構築することなく、歩数、心拍数、睡眠、体重、血中酸素濃度、心拍変動へ確実にアクセスする必要がある開発者やAIエージェントを対象としています。
エージェント向け機能を内蔵した単一バイナリとして提供
ghealthは、クライアント全体を1つの実行ファイルにまとめています。ユーザーはバイナリをダウンロードし、macOS、Linux、またはWindows上で直接実行できます。
この設計には、決定論的な終了コード、--dry-runフラグ、--rawフラグが含まれています。リリースには2つのSKILL.mdファイルが同梱されているため、AIエージェントは追加のドキュメントなしで、サポートされているコマンドと出力形式を把握できます。
これらの機能により、エージェントベースのワークフローをヘルスデータソースに接続する際、通常は妨げとなるセットアップ手順が削減されます。
40種類のデータを構造化JSONで返す
このツールは現在、Google Health API v4の検証済みデータタイプ40種類をサポートしています。対応する指標には、1日の歩数、安静時心拍数、睡眠ステージ、体重、SpO2、HRVなどがあります。
各クエリは、データの取得元デバイスにかかわらず、同じJSONスキーマを返します。データはFitbitトラッカー、Pixel Watch、またはGoogle Health経由で同期する任意のサードパーティ製デバイスから取得できます。
この一貫性により、エージェントが複数のウェアラブルデバイスからデータを取り込む際に、カスタムパーサーが不要になります。Google Health API v4のドキュメントには、レスポンスは「ヘルスデータプラットフォームに登録されたすべてのデータタイプ」について統一されたスキーマに従う必要があると記載されています。
OAuthのセットアップにPKCE S256フローを使用
ユーザーはGoogle Cloudコンソールで独自のOAuth認証情報を作成する必要があります。その後、ツールはターミナル内でPKCE S256認可フローを実行します。
クライアントシークレットはバイナリ内に保存されません。フローはローカルで完了し、以降の呼び出しにツールが使用するリフレッシュトークンを返します。
このアプローチにより、Google Health APIのセキュリティ要件を満たしながら、ツールを軽量に保つことができます。
エージェントファーストの設計がコマンドの動作を決定
2つのSKILL.mdファイルには、サポートされているすべてのコマンドと、各コマンドが返す正確なJSON形式が記載されています。エージェントはこれらのファイルを読み、人の指示なしで有効な呼び出しを生成できます。
決定論的な終了コードにより、呼び出し元のスクリプトはテキスト出力を解析することなく、ゼロ以外の結果を失敗として扱えます。--dry-runフラグを使用すると、実際に送信せずに予定されているAPIリクエストを確認できます。
たとえば開発者は、ghealth fetch --type steps --start 2026-06-01 --end 2026-06-07 --output jsonのようなコマンドを実行し、構造化された週間歩数レポートを取得できます。たとえば、AIフィットネスコーチエージェントが毎週この呼び出しを実行し、返された歩数のJSONを同じツールから取得した睡眠ステージデータと組み合わせ、ユーザー向けに単一のパーソナライズされた回復スコアを生成できます。
これらの制御機能により、ghealthはヘルスデータを扱う際に予測可能な動作が求められる自動化パイプラインに適しています。追加のガイダンスは、Google Health API v4リファレンスおよびFitbit Web API変更履歴に掲載されています。
現在の制限と未解決の問題
このプロジェクトはまだ初期段階にあります。動作が保証されているのは、SKILL.mdファイルに記載された主要なデータタイプのみです。Google Health API全体に含まれる追加のデータタイプには、今後のアップデートが必要になる可能性があります。
公開ロードマップやコントリビューターガイドは、まだ公開されていません。現時点では、単独のメンテナーがすべてのマージとIssueのトリアージを担当しています。
基盤となるGoogle Health APIの変更にツールがどの程度迅速に追随できるのか、また初回リリース以降にコミュニティがどのように成長するのかは、依然として不透明です。
今後注目すべき点
ヘルス関連エージェントを構築するチームは、今後30日以内に既存のFitbitデータを使ってバイナリをテストするべきです。サポートされている40種類のデータタイプに不足があれば、すぐに明らかになるでしょう。
新しいデータタイプを追加する、コミュニティ初のプルリクエストに注目してください。その変更によって、現在のコマンド構造が既存のエージェント統合を壊すことなく拡張できるかどうかが分かります。
また、Google Health APIの変更履歴も監視してください。Googleが破壊的変更を発表すれば、少人数のメンテナー体制でghealthが最新状態を維持できるかどうかが、直ちに試されることになります。メンテナーは、「目標は、エージェントがOAuthやJSON解析を再実装せずに済むよう、ヘルスデータへアクセスするための信頼性が高く最小限のインターフェースを提供することでした」と述べています。
