このダッシュボードとアラートのスイートを使用すると、Google Home エコシステムとの高品質な統合をプロアクティブに維持できます。Google は、すべてのユーザーに高品質なエコシステムを提供できるよう、パートナー様をサポートすることに尽力しています。
ダッシュボードは 3 つのセクションで構成されており、それぞれが統合全体の品質に影響する重要な部分をカバーしています。
Google to Partner Metrics - Google からクラウド バックエンドへの呼び出しの健全性を測定します。
System Health - Partner to Google Metrics - システムから Google への呼び出しの健全性を測定します。
デバイスの健全性 - 状態の精度 - ユーザーのクエリの処理に使用される Google システムに保存された状態の精度を測定します。
指標が目標値を満たしていない場合は、ユーザー エクスペリエンスに影響する可能性のある問題を示すために、赤色でハイライト表示されます。次の情報では、各ターゲットの詳細と、それがユーザーにとって重要な理由について説明します。
以下のボタンでダッシュボードに直接移動できない場合は、[概要] ページを選択し、[ダッシュボード] を選択します。次に、[マイ ダッシュボード] リストから [Google Home Vitals ダッシュボード (Cloud)] を選択して、ダッシュボードを表示します。
Google からパートナーへの指標
クエリ/実行の成功率が 99.5%以上の指標は、ユーザーのコマンドが正しく実行される頻度を測定します。これにより、「デバイスにアクセスできません」などのアシスタントの応答や、まだ実行されていないコマンドを誤って確認することを回避できます。
「成功」の定義は何ですか？
Google Home プラットフォームが、目的のアクションが実行されたこと、またはリクエストされた状態が取得されたことを示す有効なレスポンスを受信した場合、トランザクションは成功としてマークされます。
実行をブロックしない例外（lowBattery 例外を伴う SUCCESS ステータスなど）を含むレスポンスは、成功したトランザクションとしてカウントされます。警告は表示されたものの、コマンドはデバイスに届き、インテントは満たされました。
「失敗」の定義
一般的なプラットフォーム エラーコードに記載されているエラーのうち、パートナーが対応可能とマークされているものは、QUERY と EXECUTE の成功率を計算する際に「失敗」とみなされます。また、エラーと例外に記載されているエラーも「失敗」となります。ただし、次の例外があります。
| 失敗の例外 | ||
|---|---|---|
| aboveMaximumLightEffectsDuration | armLevelNeeded | inOffMode |
| alreadyArmed | bagFull | lockedToRange |
| alreadyAtMax | belowMinimumLightEffectsDuration | lowBattery |
| alreadyAtMin | binFull | maxSpeedReached |
| alreadyClosed | cancelArmingRestricted | minSpeedReached |
| alreadyDisarmed | deadBattery | notSupported |
| alreadyDocked | degreesOutOfRange | オフライン |
| alreadyInState | deviceJammingDetected | percentOutOfRange |
| alreadyLocked | deviceNotMounted | rangeTooClose |
| alreadyOff | deviceNotReady | relinkRequired |
| alreadyOn | deviceOffline | remoteSetDisabled |
| alreadyOpen | deviceTurnedOff | safetyShutOff |
| alreadyPaused | discreteOnlyOpenClose | targetAlreadyReached |
| alreadyStarted | functionNotSupported | tooManyFailedAttempts |
| alreadyStopped | inAutoMode | valueOutOfRange |
| alreadyUnlocked | inEcoMode |
Query/Execute Latency (p90) <= 1000ms 指標は、リクエストされたアクションの待ち時間を測定し、ユーザーが長時間待つことがないようにします（たとえば、ライトが消えるまで数秒待つなど）。
レイテンシの指標
レイテンシは、統合の応答性がエンドユーザーにどのように感じられるかを示す重要な指標です。ダッシュボードでは、90 パーセンタイル（P90）レイテンシが追跡されます。これは、最も「遅い」ユーザーのエクスペリエンスを表します（たとえば、P90 が 800 ミリ秒の場合、リクエストの 90% が 800 ミリ秒以内に確認されたことを意味します）。
Google は、技術的な精度を確保するため、ステータス チェックとデバイス コマンドでレイテンシの測定方法を変えています。
1. QUERY Latency（疑問文）
これは、Google がデバイスの現在の状態をリクエストしたときの Cloud-to-cloud の往復時間を測定します。
- 開始: Google がフルフィルメント URL に
action.devices.QUERYリクエストを送信します。 - 測定ウィンドウ: クラウドが完全な HTTP レスポンスを受信、処理、Google に送信するのにかかる時間。
- 終了: Google がサービスから最終レスポンス ペイロードを受信して確認します。
2. 実行レイテンシ（アクション）
これは、Google がデバイスに制御リクエストを送信したときのコマンド確認時間を測定します。
- 開始: Google がフルフィルメント URL に
action.devices.EXECUTEリクエストを送信します。 - 測定ウィンドウ: クラウドがコマンドを受信して確認応答を返すまでに要した時間。
- 終了: Google が
SUCCESS、PENDING、またはOFFLINEのステータス レスポンスを受信します。 - 技術的な範囲: この指標は、Google のクラウドとユーザーのクラウド間の「応答確認」時間を測定します。物理ハードウェア（電球など）が物理状態の変化を完了するまでの時間は測定されません。これは、多くの場合、クラウド間のパス外のローカル メッシュ ネットワークのレイテンシが関係するためです。
レイテンシの低減オプション
地理的ルーティングのアーキテクチャに関する推奨事項
エニーキャスト IP の実装が実現できない場合は、ユーザーが最も近いリージョン データセンターでサービスを受けられるように、次の費用対効果の高い代替手段をおすすめします。
グローバル ロード バランシング（GLB）
静的ルーティングの代わりに、グローバル アプリケーション ロードバランサ（ほとんどの主要なクラウド プロバイダから利用可能）を使用します。
仕組み: ネットワーク エッジに配置される単一のグローバル エントリ ポイント（URL）を構成します。ロードバランサは、Google のフルフィルメント クラスタからのリクエストの地理的な送信元を自動的に検出し、最も近いリージョンの正常なバックエンドにトラフィックを転送します。
メリット: 構成の複雑さと費用を大幅に削減しながら、エニーキャストのパフォーマンスを実現します。
位置情報認識 DNS（GeoDNS）
仕組み: DNS クエリの地理的位置に基づいて、フルフィルメント URL を異なる IP アドレスに解決するように DNS プロバイダを設定します。
実装: DNS プロバイダが Google の下り（外向き）ポイント向けに最適化されていることを確認します。Google の地域別フルフィルメント サービス（米国、EU、アジアなど）がドメインを解決すると、その特定の地域のデータセンターの IP アドレスが返されます。
アプリケーション レイヤでの最適化戦略
インフラストラクチャ レベルのルーティングに加えて、アプリケーション レイヤで次の戦略を実装して、リクエスト処理のレイテンシを短縮できます。
「トランポリン」プロキシ メソッド
プライマリ データセンターを維持する必要がある場合は、リージョン ライトウェイト プロキシ サーバー（トランポリン）を使用して初期ハンドシェイクを処理します。
Google がグローバル URL にアクセスします。
リージョン プロキシ（軽量の Nginx や Lambda 関数など）がリクエストを受信します。
プロキシは、内部の高速バックボーンを介してペイロードをプライマリ データベースに転送します。
メリット: これにより、長距離リクエストのレイテンシの最大の原因となることが多い「TCP ハンドシェイク」の時間を短縮できます。
アクセス トークン リージョン ヒント
アカウント リンク（OAuth）プロセス中に、ユーザーのホーム リージョンを特定できます。
実装: Google に発行される
access_tokenにリージョン ID をエンコードします。Google がフルフィルメント リクエストを送信すると、ゲートウェイはトークンをすぐに検査し、データベース ルックアップを必要とせずにリクエストを正しいリージョン クラスタに転送できます。
システム健全性 - パートナーから Google への指標
成功率が 99.5%以上を維持することで、Google Home でデバイスのステータスが正しく表示され、デバイスの追加と削除、自動化のトリガー、履歴イベントの Google Home app (GHA) の [アクティビティ] タブへの表示が確実に行われるようになります。
成功率は、クラウドが状態の更新をプッシュしたときに Google から返される HTTP レスポンス コードに基づいて計算されます。Google 側のインフラストラクチャの問題でパートナーがペナルティを受けないようにするため、この指標では Google 内部エラーは失敗回数から除外されます。計算に含まれる API 呼び出しは、HomeGraph API リファレンスに記載されています。
「成功」の定義は何ですか？
2xx（成功）: 状態の更新が Home Graph によって正常に受信され、処理されました。
「失敗」の定義
4xx（パートナー エラー）は失敗を表し、クラウドから送信されたリクエストに問題があることを示します。一般的なコードは次のとおりです。
400 不正なリクエスト
原因: 構文が無効なため、サーバーがリクエストを処理できませんでした。一般的な原因としては、不正な形式の JSON や、文字列値に "" でなく null を使っていることなどが挙げられます。
解決策: リクエスト本文が有効な JSON（構造が不正でない、文字列フィールドの値が null でない）であることを確認し、agentUserId が 同期レスポンスの値と一致していることを確認します。
404 見つかりません
原因: HomeGraph で deviceId または agentUserId が見つかりません（まだ同期されていない、すでにリンクが解除されている、ID が一致しない）。
ソリューション:
agentUserIdが SYNC レスポンスで提供された値と一致していることを確認してください。- Home Graph SYNC API を使用して、404 Not Found エラーの原因が HomeGraph のデバイスまたはユーザーの欠落であるかどうかを判断します。
- デバイスまたはアカウントの追加、削除、名前変更、更新の後に
requestSyncをトリガーして、状態が最新の状態に保たれるようにしてください。 DISCONNECTインテントを適切に処理して、古いデバイスのレポートを停止します。DISCONNECTインテントを受け取ったら、クラウド サービスは Request Sync と Report State を使用して Google への変更の公開を停止する必要があります。
429 Resource Exhausted
原因: 統合が割り当てられた割り当てを超過しました。
解決策: 割り当て管理のダッシュボードにある「ステップ 2a: 割り当ての問題をデバッグする」の手順をご覧ください。詳細については、スマートホームの割り当てと上限もご覧ください。
デバイスの稼働状況 - 状態の精度
状態の精度が 99.5%以上を満たすことで、ユーザーがデバイスの状態を確認したり、Home に相談などの AI 機能を使用したりする際に、正しい結果が表示されるようになります。状態の精度が低い場合、自動化が実行されず、履歴エントリが GHA の [アクティビティ] タブに適切なタイミングで表示されないことがあります。詳細については、Report State をご覧ください。注意: 状態の正確性の目標は、サポートされているすべてのトレイトで達成する必要があります。
1. 精度コンポーネント
この指標は、Google が既知のインテントの結果に対して報告された状態を確認できる「サンプル」から導き出されます。技術的な精度については、次の 2 つの異なる経路で精度が評価されます。
- QUERY ベースの精度: ユーザーまたはシステムがデバイスの現在のステータスを積極的に問い合わせたときに検証されます。
- EXECUTE ベースの精度: 制御リクエストの後に報告されたコマンド後のデバイスの状態を評価することで検証されます。
2. ダッシュボードの指標（1 時間ごとの計算）
ダッシュボードでは、1 時間間隔に基づいて精度が計算されます。統計的な信頼性を確保し、シグナル ノイズの少ない統合にペナルティが課されないように、Google は最小トラフィック量のしきい値を適用しています。特定の特性とデバイスの組み合わせで、5 日間のローリング ウィンドウで合計サンプル数が 100 未満の場合、精度は統計的に有意ではないと見なされ、N/A に設定されます。
両方の経路で 1 時間あたりのサンプル数が十分な場合、特定の州の 1 時間あたりのベースライン精度は、2 つの独立した割合の平均として計算されます。
1 時間あたりの状態の精度 = （クエリの精度 % + 実行の精度 %）/ 2
各パスウェイは次のように定義されます。
- クエリの精度（%） = （1 時間あたりの正確なクエリのサンプル数） / （1 時間あたりのクエリの総サンプル数）
- 実行精度（%） = （1 時間あたりの実行精度サンプル数） / （1 時間あたりの実行サンプル総数）
特性精度スコア（特性ごとに計算） = SUM（クエリの正確なサンプル数 + 実行の正確なサンプル数） / SUM（クエリの合計サンプル数 + 実行の合計サンプル数）
品質スコアはエコシステム全体の厳密な最小パフォーマンスを評価するため、サポート対象のすべての適格な特性が、個別に 99.5% 以上の状態精度目標を満たしている必要があります（これは特性全体の平均ではありません）。
このビューでは、精度が非常に高い大容量デバイスが、容量の少ないデバイスの精度に関する問題を隠蔽することを防ぎます。使用率の低い特性がスコアを下げることを懸念しているパートナー様は、使用頻度の低い特性は最小トラフィック量のチェックによって自動的に保護され、必要なサンプルしきい値を満たさない限り、最低タイプと特性のスコアに反映されないことをご安心ください。
3. デバイスのヘルス ステータスと状態の精度を向上
不一致は、ホームグラフに保存されている状態がリアルタイムの QUERY の結果と一致しない場合に発生します。
「Missing Field」エラー
DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD の例
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" }
DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD の例
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 にトレイトが含まれている場合、対応するフィールドは、事前対応レポートと事後対応クエリの両方に存在し、一貫性がある必要があります。
「不正確」エラー
DETAILED_ACCURACY_RESULT_INACCURATE の例
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 と QUERY の両方で常に正確で最新の値とすべての必須フィールドが提供され、データの整合性が維持されるようにします。
DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE の例
"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 の更新を常に送信して、ホームグラフが新しいデバイスのステータスを受け取れるようにします。
DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED の例
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 に到達できていないか、デバイスが接続ステータスまたは動作ステータスの移行を正常に報告していないことを示します。
解決策: すべての状態変更でレポートの状態がトリガーされ、正常に送信されるようにします。バックエンド ロジックがステータスの更新を正しく処理し、Google HomeGraph への配信の成功を確認し、デバイスが状態を常に同期してユーザー インターフェースと自動化エンジンを正確に保つことを確認します。