このダッシュボードとアラートのスイートを使用すると、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. クエリのレイテンシ（疑問文）
これは、Google がデバイスの現在の状態をリクエストしたときの Cloud-to-cloud の往復時間を測定します。
- 開始: Google が
action.devices.QUERYリクエストをフルフィルメント URL にディスパッチします。 - 測定ウィンドウ: クラウドが完全な HTTP レスポンスを受信、処理、Google に送信するのにかかる時間。
- 終了: Google がサービスから最終レスポンス ペイロードを受信して確認します。
2. EXECUTE レイテンシ（アクション）
これは、Google がデバイスに制御リクエストを送信したときのコマンド確認応答時間を測定します。
- 開始: Google が
action.devices.EXECUTEリクエストをフルフィルメント URL にディスパッチします。 - 測定ウィンドウ: クラウドがコマンドを受信して確認応答を返すまでに要した時間。
- 終了: 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 リソース不足
原因: 統合が割り当てられた割り当てを超過しました。
解決策: 割り当て管理のダッシュボードにある「ステップ 2a: 割り当ての問題をデバッグする」の手順をご覧ください。詳細については、スマートホームの割り当てと上限もご覧ください。
デバイスの稼働状況 - 状態の精度
状態の精度が 99.5%以上を満たすことで、ユーザーがデバイスの状態を確認したり、Home に相談するなどの AI 機能を使用したりする際に、正しい結果が表示されるようになります。状態の精度が低い場合、自動化が実行されず、履歴エントリが GHA の [アクティビティ] タブに適切なタイミングで表示されないことがあります。詳細については、レポートの状態をご覧ください。
品質ダッシュボードでは、全体的な精度と最低のタイプ/特徴の組み合わせという 2 つの異なる指標を使用して、このデータを 1 時間ごとに追跡します。
1. 精度コンポーネント
この指標は、報告された状態を既知のインテントの結果と照合できる「サンプル」から導出されます。
2. ダッシュボードの指標（1 時間ごとの計算）
ダッシュボードでは、1 時間間隔に基づいて精度が計算されます。1 時間の合計サンプル数が 100 未満（S_Total < 100）の場合、その時間の精度は N/A に設定されます。
ビュー 1: 全体的な精度（グローバル平均）
これは、すべてのデバイスタイプとトレイトを組み合わせた統合の合計精度を表します。エコシステム全体の健全性の加重平均が表示されます。
- 計算: すべてのデバイスの合計状態精度 / すべてのデバイスの合計状態合計。
ビュー 2: 最も低いタイプ/トレイトの組み合わせ
これにより、統合で最も信頼性の低い特定のカテゴリが特定されます。これにより、高品質の大音量デバイスが低品質の小音量デバイスを隠すのを防ぎます。たとえば、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 への配信の成功を確認し、デバイスが状態を常に同期してユーザー インターフェースと自動化エンジンを正確に保つことを確認します。