Google Home Vitals（クラウド）

このダッシュボードとアラートのスイートを使用すると、Google Home エコシステムとの高品質な統合をプロアクティブに維持できます。Google は、すべてのユーザーに高品質のエコシステムを提供できるよう、パートナー様をサポートすることに尽力しています。

ダッシュボードは 3 つのセクションで構成されており、それぞれが統合全体の品質に貢献する重要な部分をカバーしています。

1. Google からパートナーへの指標 - Google から クラウド バックエンドへの呼び出しの健全性を測定します。

2. システム ヘルス - パートナーから Google への指標 - システムから Google への呼び出しの健全性を測定します。

3. デバイスのヘルス - 状態の精度 - ユーザー クエリの処理に使用される Google システムに保存されている状態の精度を測定します。

指標が目標値を満たしていない場合は、ユーザー エクスペリエンスに影響する可能性がある問題を示すために赤でハイライト表示されます。次の情報では、各目標の詳細と、それがユーザーにとって重要な理由について説明します。

次のボタンをクリックしてもダッシュボードに直接移動しない場合は、[概要] ページを選択し、[ダッシュボード] を選択します。次に、[マイ ダッシュボード] リストから [Google Home Vitals ダッシュボード（Cloud）] を選択して、ダッシュボードを表示します。

[ダッシュボード] に移動

Google からパートナーへの指標

[クエリ/実行の成功率 >= 99.5%] 指標は、ユーザーのコマンドが正しく実行される頻度を測定します。これにより、「デバイスに接続できません」などのアシスタントのレスポンスや、実行されなかったコマンドを誤って確認するのを防ぐことができます。

「成功」の定義とは

Google Home プラットフォームが、目的のアクションが実行されたこと、またはリクエストされた状態が取得されたことを示す有効なレスポンスを受信した場合、トランザクションは成功としてマークされます。

実行をブロックしない例外（lowBattery 例外を伴う SUCCESS ステータスなど）を含むレスポンスは、成功したトランザクションとしてカウントされます。 警告が表示されたにもかかわらず、コマンドがデバイスに到達し、インテントが満たされました。

「失敗」の定義とは

一般的なプラットフォーム エラーコードに記載されているエラーで、[パートナーが対応可能] とマークされているものは、QUERY と EXECUTE の成功率を計算する際に「失敗」と見なされます。また、エラーと例外に記載されているエラーも「失敗」と見なされますが、次の例外があります。

[クエリ/実行のレイテンシ（p90）<= 1000 ミリ秒] 指標は、リクエストされたアクションの待ち時間を測定します。これにより、ユーザーが長時間待つ必要がないようにします（たとえば、ライトが消えるまで数秒待つなど）。

レイテンシの指標

レイテンシは、統合がエンドユーザーにどの程度応答しているかを示す重要な指標です。ダッシュボードには、90 パーセンタイル（P90）のレイテンシが表示されます。これは、「最も遅い」ユーザーのエクスペリエンスを表します（たとえば、P90 が 800 ミリ秒の場合、リクエストの 90% が 800 ミリ秒以内に確認されます）。

Google は、技術的な正確性を確保するため、ステータス チェックとデバイス コマンドでレイテンシを異なる方法で測定します。

1. QUERY レイテンシ（問い合わせ）

これは、Google がデバイスの現在の状態をリクエストしたときのCloud-to-cloudラウンドトリップ時間を測定します。

• 開始: Google は、フルフィルメント URL に action.devices.QUERY リクエストをディスパッチします。
• 測定期間: クラウドが完全な HTTP レスポンスを受信、処理して Google に送信するまでの時間。
• 終了: Google がサービスから最終的なレスポンス ペイロードを受信して確認します。

**2. EXECUTE レイテンシ（アクション）

これは、Google がデバイスに制御リクエストを送信したときのコマンド確認時間を測定します。

• 開始: Google は、フルフィルメント URL に action.devices.EXECUTE リクエストをディスパッチします。
• 測定期間: クラウドがコマンドを受信して確認レスポンスを返すまでの時間。
• 終了: Google が SUCCESS、PENDING、OFFLINE のステータス レスポンスを受信します。
• 技術的な範囲: この指標は、Google のクラウドとクラウド間の「レスポンス確認」時間を測定します。物理ハードウェア（電球など）が物理的な状態の変化を完了するまでの時間は測定されません。これは、クラウド間パスの外部にあるローカル メッシュ ネットワークのレイテンシが関係することが多いためです。

レイテンシを短縮するオプション

地理的ルーティングに関するアーキテクチャの推奨事項

Anycast IP の実装が実現できない場合は、ユーザーが最も近いリージョンのデータセンターで処理されるように、費用対効果の高い代替手段をおすすめします。

1. グローバル ロード バランシング（GLB）

   静的ルーティングではなく、グローバル アプリケーション ロードバランサ （ほとんどの主要なクラウド プロバイダから入手可能）を使用します。

   • 仕組み: ネットワーク エッジに配置される単一のグローバル エントリ ポイント（URL）を構成します。ロードバランサは、Google のフルフィルメント クラスタからのリクエストの地理的な送信元を自動的に検出し、トラフィックを最も近いリージョンの正常なバックエンドにルーティングします。

   • メリット: Anycast のパフォーマンスを、構成の複雑さとコストを大幅に削減して実現できます。

2. 地理位置情報対応 DNS（GeoDNS）

   • 仕組み: DNS クエリの地理的な位置に基づいて、フルフィルメント URL を異なる IP アドレスに解決するように DNS プロバイダを構成します。

   • 実装: DNS プロバイダが Google のエグレス ポイント向けに最適化されていることを確認します。Google のリージョン フルフィルメント サービス（米国、EU、アジアなど）がドメインを解決すると、その特定のリージョンのデータセンターの IP アドレスが返されます。

アプリケーション レイヤでの最適化戦略

インフラストラクチャ レベルのルーティングに加えて、アプリケーション レイヤで次の戦略を実装して、リクエスト処理のレイテンシを短縮できます。

1. 「トランポリン」プロキシ メソッド

   プライマリ データセンターを維持する必要がある場合は、リージョンの軽量プロキシ サーバー（トランポリン）を使用して最初のハンドシェイクを処理します。

   1. Google がグローバル URL にアクセスします。

   2. リージョン プロキシ（軽量の Nginx 関数や Lambda 関数など）がリクエストを受信します。

   3. プロキシは、内部の高速バックボーンを介してペイロードをプライマリ データベースに転送します。

   メリット: これにより、「TCP ハンドシェイク」時間が短縮されます。これは、長距離リクエストのレイテンシの最大の要因となることがよくあります。

2. アクセス トークンのリージョン ヒント

   アカウント リンク（OAuth）プロセス中に、システムはユーザーのホーム リージョンを識別できます。

   実装: Google に発行された access_token にリージョン ID をエンコードします。Google がフルフィルメント リクエストを送信すると、ゲートウェイはトークンをすぐに検査し、データベース検索を行わずにリクエストを正しいリージョン クラスタにルーティングできます。

システム ヘルス - パートナーから Google への指標

[成功率 >= 99.5%] を維持すると、Google Home でデバイスの状態が 正しく表示され、デバイスの追加と削除、自動化のトリガー、 履歴イベントが Google Home app (GHA)'s アクティビティ タブに表示されるようになります。

成功率は、クラウドが状態の更新をプッシュしたときに Google から返される HTTP レスポンス コードに基づいて計算されます。Google 側のインフラストラクチャの問題でパートナーがペナルティを受けないようにするため、この指標では Google 内部エラーが失敗数から除外されます。計算に含まれる API 呼び出しは、 HomeGraph API リファレンスに記載されています。

「成功」の定義とは

2xx（成功）: 状態の更新が Home Graph によって正常に受信され、処理されました。

「失敗」の定義とは

4xx（パートナー エラー）は失敗を表し、クラウドから送信されたリクエストに問題があることを示します。一般的なコードは次のとおりです。

400 不正なリクエスト

原因: 無効な構文のため、サーバーがリクエストを処理できませんでした。 一般的な原因としては、不正な形式の JSON や、文字列値に "" でなく null を使っていることなどが挙げられます。

解決策: リクエスト本文が有効な JSON であること（形式が不正でない、文字列フィールドに null 値がない）を確認し、agentUserId が 同期レスポンスの値と一致していることを確認します。

404 見つかりません

原因: HomeGraph で deviceId または agentUserId が見つかりません（まだ同期されていない、すでにリンク解除されている、ID が一致しない）。

ソリューション:

1. agentUserId が SYNC レスポンスで提供された値と一致していることを確認してください。
2. Home Graph SYNC API を使用して、404 Not Found エラーの原因が HomeGraph のデバイス またはユーザーの欠落であるかどうかを判断します。
3. デバイスまたはアカウントの追加、削除、名前変更、更新後に requestSync `requestSync` をトリガーして、状態が 最新の状態に保たれるようにします。
4. DISCONNECT インテントを適切に処理して、古いデバイスの報告を停止します。`DISCONNECT` インテントを受信したら、 クラウド サービスは Request Sync と Report State を使用して Google への変更の公開を停止する必要があります。

429 リソースを使用済み

原因: 統合が割り当てられた割り当てを超えています。

解決策: 割り当ての管理については、ダッシュボードの「ステップ 2a: 割り当ての問題をデバッグする」セクションの手順をご覧ください。詳細については、 スマートホームの割り当てと上限をご覧ください。

デバイスのヘルス - 状態の精度

[状態の精度 >= 99.5%] を満たすか、それ以上の状態にすることで、ユーザーがデバイスの状態を表示したり、Home に相談 などの AI 機能を使用したりする際に、正しい結果が表示されるようになります。状態の精度が低い場合、自動化が実行されず、履歴エントリが GHAのアクティビティ タブに適切なタイミングで表示されないことがあります。詳細については、Report Stateをご覧ください。

品質ダッシュボードでは、[全体的な精度] と [最低のタイプ/トレイトの組み合わせ] という 2 つの異なる指標を使用して、1 時間ごとに追跡します。

1. 精度のコンポーネント

この指標は、Google が既知のインテントの結果に対して報告された状態を検証できる「サンプル」から導出されます。

2. ダッシュボードの指標（1 時間ごとの計算）

ダッシュボードでは、1 時間間隔 で精度が計算されます。1 時間の合計サンプル数が 100 未満（S_Total < 100）の場合、その時間の精度は [N/A] に設定されます。

ビュー 1: 全体的な精度（グローバル平均）

これは、すべてのデバイスタイプとトレイトを組み合わせた統合の全体的な精度を表します。エコシステム全体の健全性の加重平均を示します。

• 計算: すべてのデバイスの合計状態精度 / すべてのデバイスの合計状態

ビュー 2: 最低のタイプ/トレイトの組み合わせ

これにより、統合で最も信頼性の低い特定のカテゴリが特定されます。品質の高い大量のデバイスが、品質の低い少量のデバイスを隠すのを防ぎます。たとえば、ライトの数が多く、状態の精度が 99.5% を超えているが、スイッチの数が少なく、状態の精度が低い場合、平均値では見過ごされる可能性のあるスイッチの改善が必要であることを示します。

• 計算: すべてのトレイト / デバイス の組み合わせの状態精度/状態の合計の最小値。

3. デバイスのヘルスと状態の精度を改善する

Home Graph に保存されている状態がリアルタイムの QUERY の結果と一致しない場合に、不一致が発生します。

「フィールドが見つからない」エラー

reportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD"
    deviceId: "curtain"
    deviceType: "action.devices.types.CURTAIN"
    isMissingField: true
    isOffline: false
    queriedTime: "2026-04-13T12:20:26Z"
    queryReportStateDifferences: {
      queryState: "open_close    {
        open_percent: 0.0
        missing open_direction
      }"
      reportState: "open_close   {
        open_state {
          open_percent: 100.0
          open_direction: "LEFT"
        }
      }"
    }
    reportedTime: "2022-05-13T07:14:35Z"
    requestId: "123"
    result: "INACCURATE"
    snapshotTime: "2026-04-13T12:20:26Z"
    stateName: "open_state"
    traitName: "TRAIT_OPEN_CLOSE"
  }
  

reportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD"
    deviceId: "sensor"
    deviceType: "action.devices.types.SENSOR"
    isMissingField: true
    isOffline: false
    queriedTime: "2026-04-28T10:40:33Z"
    queryReportStateDifferences: {
      queryState: "temperature_setting {
         thermostat_mode: "off"
         thermostat_temperature_ambient: 20.0
         active_thermostat_mode: "none"
      }"
      reportState: "temperature_setting {
         thermostat_mode: "off"
         active_thermostat_mode: "none"
      }"
    }
    reportedTime: "2024-09-20T15:00:00Z"
    requestId: "123"
    result: "INACCURATE"
    snapshotTime: "2026-04-28T10:40:33Z"
    stateName: "thermostat_temperature_ambient"
    traitName: "TRAIT_TEMPERATURE_SETTING"
  }
  

原因: DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD エラーまたは DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD エラーの場合、同じデバイスの QUERY レスポンスと Report State リクエストでペイロード フィールドのセットが異なります。

解決策: 両方のパスでデータ構造が同一であることを確認します。トレイトが SYNC に含まれている場合は、プロアクティブ レポートとリアクティブ クエリの両方で、対応するフィールドが存在し、一貫している必要があります。

「不正確」エラー

reportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_INACCURATE"
    deviceId: "outlet"
    deviceType: "action.devices.types.OUTLET"
    isMissingField: false
    isOffline: false
    queriedTime: "2026-04-12T16:02:58Z"
    queryReportStateDifferences: {
      queryState: "on_off    {
        on: false
      }"
      reportState: "on_off   {
        on: true
      }"
    }
    reportedTime: "2025-03-10T01:56:44Z"
    requestId: "abc"
    result: "INACCURATE"
    snapshotTime: "2026-04-12T16:02:58Z"
    stateName: "on"
    traitName: "TRAIT_ON_OFF"
  }
  

原因: DETAILED_ACCURACY_RESULT_INACCURATE エラーの場合、QUERY レスポンスで返された値と最後の Report State の値に不一致があります。

ソリューション: デバイスのステータスが変更されるたびに Report State がトリガーされるようにし、Report State と QUERY の両方で常に正確で最新の値と必要なすべてのフィールドが提供され、データの整合性が維持されるようにします。

"reportStateLog": {
   "isMissingField": false,
   "snapshotTime": "2026-04-13T07:56:21Z",
   "traitName": "TRAIT_ON_OFF",
   "detailedAccuracyResult": "DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE",
   "executionReportStateDifferences": {
      "expectedPostExecutionDeviceState": {
         "onOff": {
         "on": false
         }
      },
      "preExecutionDeviceState": {
         "onOff": {
         "on": true
         }
      },
      "executionCommand": {
         "requestId": "test001",
         "beginTimestamp": "2026-04-13T07:56:20Z",
         "action": {
         "trait": "TRAIT_ON_OFF",
         "actionType": "ONOFF_OFF"
         },
         "status": {
         "statusType": "SUCCESS_STATUS"
         },
         "endTimestamp": "2026-04-13T07:56:21Z",
         "executionType": "PARTNER_CLOUD"
      },
      "reportState": {}
   },
   "accuracy": "MISSING_REPORT_STATE",
   "deviceType": "action.devices.types.LIGHT",
   "agentId": "abc",
   "stateName": "on",
   "result": "MISSING_REPORT_STATE"
   }
  

原因: DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE エラーの場合、パートナーはコマンドを正常に実行しましたが、更新されたデバイスの状態を Google に報告しませんでした。

ソリューション: コマンドの実行後に常に Report State の更新を送信して、Home Graph が新しいデバイスの状態を受信できるようにします。

eportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED"
    deviceId: "switch"
    deviceType: "action.devices.types.SWITCH"
    isMissingField: false
    isOffline: true
    queriedTime: "2026-04-13T13:53:26Z"
    queryReportStateDifferences: {
      queryState: "online    {
        online: false
      }
      "
      reportState: ""
    }
    reportedTime: "1970-01-01T00:00:00Z"
    requestId: "test001"
    result: "INACCURATE"
    snapshotTime: "2026-04-13T13:53:26Z"
    stateName: "online"
    traitName: "TRAIT_ONLINE"
   }
  

原因: DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED エラーの場合、QUERY の結果で現在のステータスが提供されているにもかかわらず、このデバイスの Report State が受信されていません（状態が空で、報告されたタイムスタンプがエポックです）。これは、状態の更新がトリガーされていないか、HomeGraph に到達していないか、デバイスが接続または動作ステータスの移行を正常に報告していないことを示します。

解決策: すべての状態変更で Report State がトリガーされ、正常に送信されるようにします。バックエンド ロジックがステータスの更新を正しく処理し、Google HomeGraph への配信が成功したことを確認し、デバイスが状態を常に同期して、ユーザー インターフェースと自動化エンジンを正確に保つようにします。